headers
Jerry DeLisle | 1 Apr 06:30
Picon

Re: [patch, fortran]PR25829 Add support for F2003 I/O features

On Sat, 2008-03-29 at 14:44 +0100, Tobias Burnus wrote: 
> > - the matchers and checks for asynchronous, decimal, encoding,
> > pending, round, sign, size, id for OPEN, READ, WRITE, and INQUIRE.
> > - New WAIT statement.
> 
> 
> Remarks regarding diagnostics in the front end
> (Might go beyond your patch and might also regarding unimplemented
> things.)
> 
> You should add checks which reject those with -std=f95: Both WAIT and
> DECIMAL= etc. are accepted with -std=f95.
> 
> You should add checks for the arguments, the following is not rejected:
>   write(99,asynchronous='yesS')
> (They are checked for OPEN not for READ/WRITE)
> 
> The following is invalid. Asynchronous I/O is only allowed if io-unit is
> a file-unit-number (C925):
>   character(10) :: aa
>   WRITE(aa,'(a)',asynchronous='yes')
> 
> The following is rejected because the ID= is not recognized:
>    WRITE(99,asynchronous='no',id=j)
> (It should be rejected since ID= is invalid for asynchronous='NO')
> 
> The following is invalid:
>   WRITE(99,decimal="comma")
> The reasons is that only formatted I/O (including namelists) are allowed
> when DECIMAL=, BLANK= (blank is actually not recognized!), PAD=, SIGN=
(Continue reading)

Permalink | Reply | 6 comments |
headers
Paul Richard Thomas | 1 Apr 07:30
Picon

Re: [Patch, fortran] PR35759 - WHERE with overlap with ELSEWHERE error

Dominique,

Thank you for being stubborn!

On Mon, Mar 31, 2008 at 11:38 PM, Dominique Dhumieres
<dominiq <at> lps.ens.fr> wrote:
> Paul,
>
>  Since I am very stuborn, I tried the following test:
>
>  logical :: la(6) = (/(2*(i/2) /= i, i = 1, 6)/), lb(6)
>  lb = la
>  print *, la
>  where(la)
>   la = .false.
>  elsewhere
>   la = .true.
>  end where
>  print *, la
>  if (any(la .eqv. lb)) call abort()
>  end
>
>  ifort, gfortran 4.3, and g95 give:
>
>   T F T F T F
>   F T F T F T
>
>  with your patch, I get:
>
>   T F T F T F
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tobias Burnus | 1 Apr 11:14
Picon

Re: [PATCH] Fix hpux10 string to real conversion defficiences

John David Anglin wrote:
> The change could be improved if a check were added to configure to
> test the capability of strtod and friends to handle nan, inf and
> infinity.  However, it's not clear to me how to do this except by
> hard coding the result.
>   
It think one can test it in configure along these lines
  a = strtod ("nan", NULL); if(a == a) abort();
  a = strtod("+inf", NULL); if(a != a || a != a + 1.0 || a < 0.0) abort();
  a = strtod("-inf", NULL); if(a != a || a != a - 1.0 || a > 0.0) abort();

(The disadvantage of a run test is of cause that it does not work if you 
build for a target which is different from your system used for building 
gcc.)

Besides, I somehow fear that your current version is rather slow for big 
ascii files. (It is not uncommon to read relatively large ascii files 
with data in numerics.) Somehow I think something similarly to the 
following is faster, especially since NaN and INF are the exception and 
not the norm. In your case there are 9 calls to strcasecmp for non 
NAN/INF numbers, in my case there are only 5 character comparisons. 
Actually, in the if branches one could use strcasecmp as there speed 
does not matter as much and only a single or two strcmp calls are needed.

sign = 1.0;
if (s[0] == '+')
  i++
elseif(s[0] == '-'){
  sign = -1.0; i++;
}
(Continue reading)

Permalink | Reply | 22 comments |
headers
FX Coudert | 1 Apr 12:35
Picon
Gravatar

Re: [PATCH] Fix hpux10 string to real conversion defficiences

>> The change could be improved if a check were added to configure to
>> test the capability of strtod and friends to handle nan, inf and
>> infinity.  However, it's not clear to me how to do this except by
>> hard coding the result.
> It think one can test it in configure along these lines
>  a = strtod ("nan", NULL); if(a == a) abort();
>  a = strtod("+inf", NULL); if(a != a || a != a + 1.0 || a < 0.0)  
> abort();
>  a = strtod("-inf", NULL); if(a != a || a != a - 1.0 || a > 0.0)  
> abort();

I also am in favour of a configure test. You can look into  
libgfortran/acinclude.m4 to see how LIBGFOR_CHECK_FOR_BROKEN_ISNAN  
works, for example.

> (The disadvantage of a run test is of cause that it does not work  
> if you build for a target which is different from your system used  
> for building gcc.)

But... you can give target-specific sensible defaults for cross- 
compilers. In LIBGFOR_CHECK_FOR_BROKEN_ISNAN, for example, the  
default is:

> case "${target}" in
>   hppa*-*-hpux*) have_broken_isnan=yes ;;
>   *) have_broken_isnan=no ;;
> esac

In LIBGFOR_CHECK_CRLF, we have:
(Continue reading)

Permalink | Reply | 20 comments |
headers
Sa Liu | 1 Apr 12:57
Picon
Favicon

[PATCH, fortran] Interoperability with C int128_t types

This patch adds c_int128_t, c_int_lease128_t and c_int_fast128_t as GNU 
extensions. This will enable interoperability with their C variants. The 
types are rejected if standard-checking is enabled.

OK for mainline?

Thanks!
Sa

Index: gcc/gcc/ChangeLog
===================================================================
--- gcc.orig/gcc/ChangeLog
+++ gcc/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2008-04-01  Sa Liu  <saliu <at> de.ibm.com>
+
+       * fortran/iso-c-binding.def: Add definition for c_int128_t, 
+       c_int_least128_t and c_int_fast128_t as GNU extensions.
+       * fortran/symbol.c (generate_isocbinding_symbol): Generate symbols 
for 
+       c_int128_t, c_int_least128_t and c_int_fast128_t only when 
-std=gnu.
+
 2008-04-01  Jan Hubicka  <jh <at> suse.cz>

        * function.c (free_after_compilation): Free epilogue_delay_list.
Index: gcc/gcc/fortran/iso-c-binding.def
===================================================================
--- gcc.orig/gcc/fortran/iso-c-binding.def
+++ gcc/gcc/fortran/iso-c-binding.def
(Continue reading)

Permalink | Reply | 23 comments |
headers
FX Coudert | 1 Apr 13:07
Picon
Gravatar

Re: [PATCH, fortran] Interoperability with C int128_t types


> Index: gcc/gcc/fortran/iso-c-binding.def
> +       /* c_int128_t, c_int_least128_t and c_int_fast128_t are gnu
> extensions.  */
> +       if (gfc_notification_std (GFC_STD_GNU) == FAILURE
> +           && (s == ISOCBINDING_INT128_T || s ==
> ISOCBINDING_INT_LEAST128_T
> +               || s == ISOCBINDING_INT_FAST128_T))
> +         break;

I'd prefer adding a new argument named "standard" to the NAMED_INTCST  
macro, which says what standard the named constant conforms to. It  
would be GFC_STD_F2003 for all current intrinsics, and GFC_STD_GNU  
for your extensions. It would then be checked against exactly as you  
do it currently.

> Index: gcc/gcc/testsuite/gfortran.dg/c_kind_int128_test2.f03
> ===================================================================
> --- /dev/null
> +++ gcc/gcc/testsuite/gfortran.dg/c_kind_int128_test2.f03
> @@ -0,0 +1,12 @@
> +! { dg-do compile }
> +! { dg-options "-std=gnu" }
> +!
> +! Note: int_fast*_t currently not supported.
> +
> +subroutine c_kind_params
> +  use, intrinsic :: iso_c_binding
> +  integer(c_int128_t) :: a
> +  integer(c_int_least128_t) :: b
(Continue reading)

Permalink | Reply | 22 comments |
headers
Tobias Burnus | 1 Apr 13:47
Picon

Re: [patch, fortran]PR25829 Add support for F2003 I/O features

Jerry DeLisle wrote:
> The attached updated patch incorporates all constraints and checks
> listed above in the front end.  It also implements the DP and DC format
> specifiers.
>   
Thanks. Some more issues and remarks. I will try to review the patch later.

* There should be a "Fortran 2003:" in the error message.
+         if (gfc_notify_std (GFC_STD_F2003, "DP format specifier not 
allowed "

* decimal= in INQUIRE does not seem to be supported:
  inquire(unit=99, decimal=d)
Same for:
  inquire(99,encoding=str)
I also think the error messages can be improved:
  inquire(99, BLANK='foo')
            1
  Error: Syntax error in INQUIRE statement at (1)
NAG has a better error message: "Item for i/o keyword BLANK is not a 
variable"

* write(99,decimal=foo) 4.4, 3.3
This gives a run-time error message, but it can be detected at compile 
time. NAG f95 has:
   Error: DECIMAL= is incompatible with unformatted i/o
Actually, the run-time error message is also a bit misleading:
   Fortran runtime error: Missing format for FORMATTED data transfer

* Analogously for the following:
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jerry DeLisle | 1 Apr 16:00
Picon

Re: [patch, fortran]PR25829 Add support for F2003 I/O features


On Tue, 2008-04-01 at 13:47 +0200, Tobias Burnus wrote:
> Jerry DeLisle wrote:
> > The attached updated patch incorporates all constraints and checks
> > listed above in the front end.  It also implements the DP and DC format
> > specifiers.
> >   
> Thanks. Some more issues and remarks. I will try to review the patch later.
> 
OK, I will work through these. The checks in place now are for EXPR_CONSTANT and not addressing the broader case.

Thanks for continued review.

Jerry
> * There should be a "Fortran 2003:" in the error message.
> +         if (gfc_notify_std (GFC_STD_F2003, "DP format specifier not 
> allowed "
> 
> 
> * decimal= in INQUIRE does not seem to be supported:
>   inquire(unit=99, decimal=d)
> Same for:
>   inquire(99,encoding=str)
> I also think the error messages can be improved:
>   inquire(99, BLANK='foo')
>             1
>   Error: Syntax error in INQUIRE statement at (1)
> NAG has a better error message: "Item for i/o keyword BLANK is not a 
> variable"
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jerry DeLisle | 1 Apr 16:11
Picon

Re: [patch, fortran]PR25829 Add support for F2003 I/O features


On Tue, 2008-04-01 at 13:47 +0200, Tobias Burnus wrote: 
> Jerry DeLisle wrote:
> > The attached updated patch incorporates all constraints and checks
> > listed above in the front end.  It also implements the DP and DC format
> > specifiers.
> >   
> Thanks. Some more issues and remarks. I will try to review the patch later.
> 
OK, I will work through these.

Thanks for continued review.

Jerry 
> * There should be a "Fortran 2003:" in the error message.
> +         if (gfc_notify_std (GFC_STD_F2003, "DP format specifier not 
> allowed "
> 
> 
> * decimal= in INQUIRE does not seem to be supported:
>   inquire(unit=99, decimal=d)
> Same for:
>   inquire(99,encoding=str)
> I also think the error messages can be improved:
>   inquire(99, BLANK='foo')
>             1
>   Error: Syntax error in INQUIRE statement at (1)
> NAG has a better error message: "Item for i/o keyword BLANK is not a 
> variable"
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dennis Wassel | 1 Apr 16:56

_gfortran_pow_r4_i4 library calls

Hi everyone,

I have compiled Lapack with gfortran 4.2.2 and am now trying to link
against that library with gfortran 4.3.0.
This results in my linker whining:
slamch.f:(.text+0xaf): undefined reference to `_gfortran_pow_r4_i4'

Checking this I found that the 3.0.0 Fortranlib does supply
"_gfortran_pow_r4_i8" but not "_gfortran_pow_r4_i4", as the 2.0.0
still does. Is this a bug or a feature? :-)
I am rather reluctant to recompile Lapack because of the trouble I've
had with the [sd]lartg functions getting caught in infinite loops
sometimes, so is there a preferred workaround, like using 4.2.n with
Fortranlib-2 instead of the 4.3 stuff?

Cheers,
Dennis

PS: No, I did not file a bugreport about my Lapack issues because that
problem was such an elusive Heisenbug that I didn't dare ...
Permalink | Reply | 1 comment |

Gmane