[Bug bootstrap/45206] [4.6 regression] ICE in ix86_expand_epilogue compiling libgcc
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2010-08-11 03:48 --- Subject: Re: [4.6 regression] ICE in ix86_expand_epilogue compiling libgcc On Tue, Aug 10, 2010 at 05:49:40AM -, ebotcazou at gcc dot gnu dot org wrote: Does anyone know which combination of recent commits is causing this problem? The set of RTH's patches. Configure --with-tune=i686 to work around it. Thanks, Eric. The --with-tune=i686 has me back in the hacking business. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45206
[Bug fortran/45005] gfortran.dg/allocate_with_typespec.f90 failed
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu 2010-07-20 23:35 --- Subject: Re: gfortran.dg/allocate_with_typespec.f90 failed On Tue, Jul 20, 2010 at 02:41:01PM -, burnus at gcc dot gnu dot org wrote: gfortran.dg/allocate_with_typespec.f90 shows on x86-64-linux (-m64): gfortran.dg/allocate_with_typespec.f90:25:0: internal compiler error: Segmentation fault ==11535== Invalid read of size 8 ==11535==at 0x542506: gfc_delete_symtree (symbol.c:2390) ==11535==by 0x543506: gfc_undo_symbols (symbol.c:2862) ==11535==by 0x5127E4: decode_statement (parse.c:272) ==11535==by 0x5143C4: next_statement (parse.c:727) ==11535==by 0x517EAE: gfc_parse_file (parse.c:4307) ==11535==by 0x54E447: gfc_be_parse_file (f95-lang.c:236) ==11535==by 0x83E279: toplev_main (toplev.c:978) ==11535==by 0x6569B7C: (below main) (in /lib64/libc-2.11.2.so) The attached patch restores the order of the old match_type_spec. It uses gfc_match( %n , name) to retrieve the next symbol from the file and uses strcmp to check against intrinsics types. Thus, for allocate_with_typespec.f90, when name=real_type the comparison fails, and we fall through to the matching for a derived type by match_derived_type_spec(). I did not write match_derived_type_spec() and have no idea how it works. The prolific valgrind output that I see I believe is related to match_derived_type_spec(). I've also attached the valgrind log. --- Comment #4 from sgk at troutmask dot apl dot washington dot edu 2010-07-20 23:35 --- Created an attachment (id=21272) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21272action=view) --- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2010-07-20 23:35 --- Created an attachment (id=21273) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21273action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45005
[Bug fortran/44556] [4.5/4.6 Regression] incorrect error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE statement
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu 2010-06-16 17:10 --- Subject: Re: [4.5/4.6 Regression] incorrect error: Stat-variable at (1) shall not be DEALLOCATEd within the same DEALLOCATE statement On Wed, Jun 16, 2010 at 02:34:34PM -, kargl at gcc dot gnu dot org wrote: --- Comment #2 from kargl at gcc dot gnu dot org 2010-06-16 14:34 --- (In reply to comment #1) The following check is to simplistic, it does not work for structures but only for simple object names. - with structures, it gets more complicated as also comparing the name of the last part-ref won't work - but one needs to walk through the whole structure references. Not sure how I got added to the CC list. Remove myself. BTW, this won't work either. program oh_my type a integer, allocatable :: b(:), d(:) character(len=80) :: err integer :: src end type a integer j type(a) :: c c%err = 'ok' allocate(c%b(2), errmsg=c%err, stat=j) deallocate(c%b, errmsg=c%err, stat=j) end program oh_my gfortran does not walk the components of a derived type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44556
[Bug fortran/44504] DEALLOCATE aborts program even with STAT=
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2010-06-11 20:16 --- Subject: Re: DEALLOCATE aborts program even with STAT= On Fri, Jun 11, 2010 at 06:22:57PM -, remko dot scharroo at me dot com wrote: --- Comment #3 from remko dot scharroo at me dot com 2010-06-11 18:22 --- I fully agree that the second deallocate (p2, stat=ios) is a violation. That is the actual intend of this program. You know, this is not arbitrary code. You can often have multiple pointers pointing to allocated memory, and then you want to deallocate the memory. Then you need to do multiple deallocate statements. You cannot do it any other way, since you cannot test if (allocated) since the pointer is not allocatable. Therefore, the best try is to simply deallocate all the pointers, i.e., deallocate (p2, stat=ios) You deallocate the memory once and nullify the pointers. program deallocate_test integer, pointer :: p1,p2,a integer :: ios allocate (a) p1 = a p2 = a print *, associated(a), associated(p1), associated(p2) deallocate (a, stat=ios) p1 = null() p2 = null() print *, associated(a), associated(p1), associated(p2) end program deallocate_test The text from the F2003 standard that I quoted is neither a constraint or restriction on the fortran processor. It is a prohibition on the programmer. I don't have any other F2003 compiler available to me. What happens if you compile your code with other compilers? Reading your excerpt from the F2003 standards, it does, of course, shows the violation. But then I expect ios simply to be non-zero, not get an abort. That's an unrealistic expectation. You've violated the standard, which allows a compiler to anything (including what you expect). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44504
[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu 2010-06-02 01:57 --- Subject: Re: [4.6 Regression] STOP parsing rejects valid code On Wed, Jun 02, 2010 at 12:42:11AM -, kargl at gcc dot gnu dot org wrote: } #if 0 if (gfc_match_eos () != MATCH_YES) goto syntax; #endif If the first gfc_match_eos () does not match an end-of-statement, gfortran immediate calls gfc_match_eos () again. With the #if 0 above the code in comment #1 compiles and executes. So, why is there a 2nd call to gfc_match_eos(). Removing this chunk of code causes no testsuite regressions on x86_64-*-freebsd. Is leftover from the STOP/ALL_STOP churn? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44371
[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu
2010-06-02 04:36 ---
Subject: Re: [4.6 Regression] STOP parsing rejects valid code
On Wed, Jun 02, 2010 at 04:17:56AM -, jvdelisle at gcc dot gnu dot org
wrote:
I plan to commit the following as simple and obvious. Sorry for the breakage.
Index: match.c
===
--- match.c (revision 160130)
+++ match.c (working copy)
@@ -2018,10 +2018,11 @@
goto cleanup;
if (m == MATCH_NO)
goto syntax;
+
+ if (gfc_match_eos () != MATCH_YES)
+ goto syntax;
}
- if (gfc_match_eos () != MATCH_YES)
-goto syntax;
if (gfc_pure (NULL))
{
I assume that you will add appropriate testcases as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44371
[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code
--- Comment #9 from sgk at troutmask dot apl dot washington dot edu 2010-06-02 04:52 --- Subject: Re: [4.6 Regression] STOP parsing rejects valid code On Wed, Jun 02, 2010 at 04:46:56AM -, jvdelisle at gcc dot gnu dot org wrote: URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160134 Log: 2010-06-01 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/44371 * gfortran.dg/error_stop_1.f08: New test. * gfortran.dg/error_stop_2.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/error_stop_1.f08 trunk/gcc/testsuite/gfortran.dg/error_stop_2.f08 Neither testcase includes the original problem report. In error_stop_2.f08, you have if (c=='x') stop size(i); if (c=='X') stop which contains and initialization expression. Please the original test without the expression, ie., if (c=='x') stop ; if (c=='X') stop -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44371
[Bug fortran/44371] [4.6 Regression] STOP parsing rejects valid code
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu 2010-06-02 04:53 --- Subject: Re: [4.6 Regression] STOP parsing rejects valid code On Wed, Jun 02, 2010 at 04:52:03AM -, sgk at troutmask dot apl dot washington dot edu wrote: Neither testcase includes the original problem report. In error_stop_2.f08, you have if (c=='x') stop size(i); if (c=='X') stop which contains and initialization expression. Please the original test without the expression, ie., Grr. s/Please/Please add/ if (c=='x') stop ; if (c=='X') stop -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44371
[Bug fortran/44354] incorrect output at run time
--- Comment #15 from sgk at troutmask dot apl dot washington dot edu 2010-06-01 03:07 --- Subject: Re: incorrect output at run time On Tue, Jun 01, 2010 at 02:09:38AM -, jvdelisle at gcc dot gnu dot org wrote: My take on this as I was reading through this thread before I got to comment #13 is that the code has to be illegal. I vote for the error. I think it would be bad practice too introduce this as an extension or for some other reason. Note that i = 5 print *, (i,i=1,i) end is valid Fortran and gfortran currently gives the expected result. The distinction is the above is an io-implied-do. The original code contains an ac-implied-do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug lto/43823] [lto] ICE during linking in testsuite
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu 2010-04-22 17:38 --- Subject: Re: [lto] ICE during linking in testsuite On Wed, Apr 21, 2010 at 08:22:26PM -, rguenth at gcc dot gnu dot org wrote: I guess you have to debug it - I do not have a freebsd system available. This appears to be an incompatibility with with FreeBSD's libelf implementation. After downloading libelf-0.8.12.tar.gz as listed in the Prerequites webpage, I get troutmask:sgk[203] bash [...@troutmask ~/gcc/obj4x/gcc]$ gmake check-gfortran RUNTESTFLAGS=lto.exp === gfortran Summary === # of expected passes124 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43823
[Bug lto/43823] [lto] ICE during linking in testsuite
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2010-04-22 18:54 --- Subject: Re: [lto] ICE during linking in testsuite On Thu, Apr 22, 2010 at 05:38:18PM -, sgk at troutmask dot apl dot washington dot edu wrote: This appears to be an incompatibility with with FreeBSD's libelf implementation. After downloading libelf-0.8.12.tar.gz as listed in the Prerequites webpage, I get troutmask:sgk[203] bash [...@troutmask ~/gcc/obj4x/gcc]$ gmake check-gfortran RUNTESTFLAGS=lto.exp === gfortran Summary === # of expected passes124 Well, I'm stumped. In the directory 'bad' I use a gfortran built with FreeBSD's libelf and in the directory 'good' I use a gfortran built with libelf-0.8.12.tar.gz's libelf. troutmask:sgk[360] md5 bad/h.o good/h.o MD5 (bad/h.o) = 4909b937854f99007f0115ceba7a3ffc MD5 (good/h.o) = 4909b937854f99007f0115ceba7a3ffc troutmask:sgk[361] md5 bad/m.o good/m.o MD5 (bad/m.o) = 43269e48702cfe26c28a2d07ff5d1d9d MD5 (good/m.o) = 43269e48702cfe26c28a2d07ff5d1d9d The md5 checksums are identical from the commands gfc4x -flto -save-temps -c h.f90 gfc4x -flto -save-temps -c m.f90 but when I do the linking I see troutmask:sgk[365] gfc4x -flto -save-temps -o z h.o m.o ./z Hello world! in the 'good' directory and the ICE in the 'bad' directory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43823
[Bug lto/43823] [lto] ICE during linking in testsuite
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu 2010-04-21 19:14 --- Subject: Re: [lto] ICE during linking in testsuite On Wed, Apr 21, 2010 at 10:01:43AM -, rguenth at gcc dot gnu dot org wrote: --- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-21 10:01 --- It works for me on x86_64-linux. Even a trivial program generates an ICE. troutmask:sgk[216] gfc4x -c -flto sub.f90 troutmask:sgk[217] gfc4x -o z -flto sub.o main.f90 lto1: internal compiler error: compressed stream: data error Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /home/sgk/work/4x/bin/gfortran returned 1 exit status collect2: lto-wrapper returned 1 exit status troutmask:sgk[218] cat sub.f90 main.f90 ! ! sub.f90 ! subroutine hello print *, 'hello world!' end subroutine hello ! ! main.f90 ! program a call hello end program a troutmask:sgk[231] ldd ~/work/4x/libexec/gcc/x86_64-unknown-freebsd9.0/4.6.0/lto1 /home/sgk/work/4x/libexec/gcc/x86_64-unknown-freebsd9.0/4.6.0/lto1: libcloog.so.0 = /usr/local/lib/libcloog.so.0 (0x201033000) libppl_c.so.3 = /usr/local/lib/libppl_c.so.3 (0x201154000) libppl.so.8 = /usr/local/lib/libppl.so.8 (0x2014d7000) libgmpxx.so.6 = /usr/local/lib/libgmpxx.so.6 (0x2016a) libmpc.so.2 = /usr/local/lib/libmpc.so.2 (0x2017a4000) libmpfr.so.3 = /usr/local/lib/libmpfr.so.3 (0x2018b6000) libgmp.so.10 = /usr/local/lib/libgmp.so.10 (0x201a01000) libz.so.6 = /lib/libz.so.6 (0x201b6b000) libelf.so.1 = /usr/lib/libelf.so.1 (0x201c81000) libc.so.7 = /lib/libc.so.7 (0x201d99000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x201fd4000) libm.so.5 = /lib/libm.so.5 (0x2021dd000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x2022ff000) libz and libelf are in the FreeBSD base system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43823
[Bug libfortran/42763] internal compiler error: in instantiate_virtual_regs_lossage ERROR 1
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu 2010-01-16 00:22 --- Subject: Re: internal compiler error: in instantiate_virtual_regs_lossage ERROR 1 On Sat, Jan 16, 2010 at 12:04:27AM -, hcolella at gmail dot com wrote: --- Comment #2 from hcolella at gmail dot com 2010-01-16 00:04 --- I was advised to upgrade g77. I did so, to 4.3, and it did not fix my problem. What to you mean by 'did not fix my problem'? I can compile your code with 4.3.5, 4.4.3, and 4.5.0. Make sure you have completely removed the 4.0.1 version of the software. You may be picking up the wrong version. What does 'gfortran -v' report? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42763
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #15 from sgk at troutmask dot apl dot washington dot edu 2009-12-18 15:52 --- Subject: Re: Complex division by zero in gfortran returns wrong results On Fri, Dec 18, 2009 at 02:42:15PM -, pault at gcc dot gnu dot org wrote: Do you want to suspend this PR or to junk it? Let's get it out of the unconfirmed list. Now that MPC is required by gcc, I'll take a look at making gfortran give a consistent result when comparing its constant folding with generated code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug fortran/42112] overloaded function with allocatable result problem
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu
2009-11-20 00:20 ---
Subject: Re: overloaded function with allocatable result problem
If the code is compiled with -fdump-tree-original one
immediately see the cause of the runtime error. Eliminating
the common code in the dumps, I find this code
pure function f() result(i)
integer :: i
integer, allocatable :: loc_ar(:)
allocate(loc_ar(1))
loc_ar = gen_g() ! does not work
deallocate(loc_ar)
i = 1
end function f
generates
f ()
{
g (loc_ar);
}
loc_ar has been allocated and the pointer to it is passed
to g() where is becomes associated with the result variable j.
You then try to allocate j, which is already allocated.
When you call g() directly in
pure function f() result(i)
integer :: i
integer, allocatable :: loc_ar(:)
allocate(loc_ar(1))
loc_ar = g() ! no problem here
deallocate(loc_ar)
i = 1
end function f
the dump shows
f ()
{
{
integer(kind=8) D.1398;
struct array1_integer(kind=4) atmp.1;
integer(kind=8) D.1393;
integer(kind=8) D.1392;
integer(kind=8) D.1391;
integer(kind=4)[0:] * restrict D.1390;
D.1390 = (integer(kind=4)[0:] * restrict) loc_ar.data;
D.1391 = loc_ar.offset;
D.1392 = loc_ar.dim[0].lbound;
D.1393 = loc_ar.dim[0].ubound;
atmp.1.dtype = 265;
atmp.1.data = 0B;
atmp.1.offset = 0;
g (atmp.1);
g() is called with a unallocated temporary variable, so
your allocation in g() works. The next several lines
copy atmp into loc_ar.
D.1398 = NON_LVALUE_EXPR D.1392;
{
integer(kind=8) S.2;
S.2 = 0;
while (1)
{
if (atmp.1.dim[0].ubound - atmp.1.dim[0].lbound S.2) goto L.2;
(*D.1390)[(S.2 + D.1398) + D.1391]
= (*(integer(kind=4)[0:] * restrict) atmp.1.data)[S.2];
S.2 = S.2 + 1;
}
L.2:;
}
Here, the temporary variable is destroyed.
{
void * D.1397;
D.1397 = (void *) atmp.1.data;
if (D.1397 != 0B)
{
__builtin_free (D.1397);
}
}
}
}
I need to go read the Fortran standard to determine the
semantics of a function returning an allocatable entity.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #17 from sgk at troutmask dot apl dot washington dot edu 2009-11-17 06:03 --- Subject: Re: [4.5/4.4 Regression] data statement with nested type constructors On Tue, Nov 17, 2009 at 05:35:33AM -, jvdelisle at gcc dot gnu dot org wrote: - Comment #16 from jvdelisle at gcc dot gnu dot org 2009-11-17 05:35 --- I propose fixing this at gfc_consant_ac which has the following comment: /* Given an array constructor, determine if the constructor is constant or not by expanding it and making sure that all elements are constants. This is a bit of a hack since something like (/ (i, i=1,1) /) will take a while as* opposed to a more clever function that traverses the expression tree. FIXME. */ We should just be able to traverse the expression tree. I have manually done so with a few test cases and one does indeed end up with a BT_CONSTANT. I will see what I can come up with. Be careful, if I remember correctly, this can be an O(n**2) problem. OTOH, nice sleuthing! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu
2009-11-15 19:26 ---
Subject: Re: [4.5/4.4 Regression] data statement with nested type
constructors
On Sun, Nov 15, 2009 at 07:04:42PM -, jvdelisle at gcc dot gnu dot org
wrote:
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-11-15 19:04
---
When we simplify start[i], we turn that expression into a constant. Then I
believe the traverse_data_var can no longer increment the index since we made
it a constant. I don't think the start[i] expression should be used to
increment the offset, but I think it is. I am wondering if we don't need a
temporary expression to use for this to traverse for the offset. Still
thinking
...
Changed the instrumentaion of the code a little. In the for-loop
of get_array_index, I added
printf(i = %d -- , i);
gmp_printf (start = %Zd , e-value.integer);
gmp_printf (lower = %Zd , ar-as-lower[i]-value.integer);
gmp_printf (upper = %Zd , ar-as-upper[i]-value.integer);
gmp_printf (offset= %Zd\n, *offset);
REMOVE:kargl[252] gfc4x -o z pr41807.f90 -fdump-tree-original
i = 0 -- start = 1 lower = 1 upper = 3 offset= 0
i = 0 -- start = 2 lower = 1 upper = 3 offset= 1
i = 0 -- start = 3 lower = 1 upper = 3 offset= 2
i = 0 -- start = 1 lower = 1 upper = 3 offset= 0
i = 0 -- start = 0 lower = 1 upper = 3 offset= -1
i = 0 -- start = 0 lower = 1 upper = 3 offset= -1
The first 3 lines are from
data (z(i), i = 1, n) / 1, 2, 3/
with z integer. The next 3 are from the array of derived type b.
So, you appear to be on the right track. The start value appears
to be junk. What's disconcerting is that the dump shows (with
the check for /*|| (gfc_is_constant_expr (e) == 0)*/ disabled)
REMOVE:kargl[253] more pr41807.f90.003t.original
MAIN__ ()
{
static struct a b[3] = {{.x={7.0e+0, 8.0e+0, 9.0e+0}}, {.x={1.0e+0, 2.0e+0,
3.0e+0}}};
integer(kind=4) i;
static integer(kind=4) z[3] = {1, 2, 3};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug libfortran/41335] VOLATILE in Fortran does not take effect
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2009-09-11 18:57 --- Subject: Re: VOLATILE in Fortran does not take effect - Comment #6 from denis_scherbakov at yahoo dot com 2009-09-11 18:38 --- By saying works I mean that on my system program with real, volatile :: a returns nonzero result. This is correct, because 80-bit floating point gets truncated to 64-bit and then loaded again into FPU. double precision, volatile :: a returns zero result. It means that variable a stays in FPU registers. I am not sure about your code, but when I compile both versions of a sample program on my machine real, volatile is stored and then fetched again, double precision, volatile stays in FPU. If you want -ffloat-store semantics then use that option. The Fortran 2003 standard does not require anything about fetching and storing a volatile entity to memory. The standard states: The VOLATILE attribute specifies that an object may be referenced, defined, or become undefined, by means not specified by the program. An object may have the VOLATILE attribute in a particular scoping unit without necessarily having it in other scoping units. If an object has the VOLATILE attribute, then all of its subobjects also have the VOLATILE attribute. NOTE 5.21 The Fortran processor should use the most recent definition of a volatile object when a value is required. Likewise, it should make the most recent Fortran definition available. It is the programmer's responsibility to manage the interactions with the non-Fortran processes. Note 5.21 is only informative text. However, gfortran is essentially doing what 5.21 states. You're most recent definition of a is given by a = Ua * Ua, then when you compute c = a - b it uses the most recent definition. There is no requirement that a had to be written to and retrieved from memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41335
[Bug libfortran/41335] VOLATILE in Fortran does not take effect
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu
2009-09-11 19:45 ---
Subject: Re: VOLATILE in Fortran does not take effect
Ok, but then real and double precision datatypes should
behave in the same way? No?
They do behave the same at least from the Fortran front-end
perspective. I've already posted the generated intermediate
code. Here it is again with the REAL(4) on the left and
the REAL(8) on the right.
volatiletest ()
{
volatile real(kind=4) ra; volatile real(kind=8) a;
real(kind=4) rb; real(kind=8) b;
real(kind=4) rc; real(kind=8) c;
real(kind=4) rua; real(kind=8) ua;
real(kind=4) rub; real(kind=8) ub;
a=(volatile real(kind=8))(ua*ua); ra=(volatile real(kind=4))(rua*rua);
b = (real(kind=8)) (ub * ub); rb = (real(kind=4)) (rub * rub);
c = (real(kind=8)) (a - b);rc = (real(kind=4)) (ra - rb);
}
I'll simply note that on my hardware I get
troutmask:sgk[204] ./z
0.1 0.1 0.1 0.1
0.0.000
forall options that I tried.
You've already mentioned the infamous PR 324, so I suspect
you're familiar with the pitfalls of floating point math
and the I387 behavior. I won't rehash that here. If you
want the middle-end and back-end to do what you want, then
you'll need to convince others that there is a problem. See
PR 324 for the joy.
Now, what volatile should be doing is inhibiting the optimizer
from optimizing
real, volatile :: a
real b
a = 0.1
call sub1
b = a
to
call sub1
b = 0.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41335
[Bug libfortran/41335] VOLATILE in Fortran does not take effect
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu 2009-09-11 20:26 --- Subject: Re: VOLATILE in Fortran does not take effect What is your hardware? x86 or something else? Opteron. I have Atlon 2000 MP and Intel Quad and on both of these systems I get differences in output for real and double precision. What I can do to prove that I do have differences and what to do to find out why? Have you tried -ffloat-store? This should save/load a FPU register after every operation. There is the -fpmath= option, but I'm not sure which switches are appropriate for your cpu. There is also the -msse set of options. To find out why you have differences, print out intermediate values to 16 and 7 significant figures for real and double precision. It may also be helpful to read Goldberg's paper if you haven't (see the gfortran wiki, manuals section). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41335
[Bug libfortran/41335] VOLATILE in Fortran does not take effect
--- Comment #16 from sgk at troutmask dot apl dot washington dot edu 2009-09-11 21:08 --- Subject: Re: VOLATILE in Fortran does not take effect On Fri, Sep 11, 2009 at 08:39:38PM -, mikael at gcc dot gnu dot org wrote: I get: pr41335.f:3.23: volatile double precision a 1 Error: Syntax error in VOLATILE statement at (1) Is this for fixed-form or free-form source code? For fixed-form, the above should parse as 'volatile doubleprecisiona' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41335
[Bug libfortran/41335] VOLATILE in Fortran does not take effect
--- Comment #19 from sgk at troutmask dot apl dot washington dot edu 2009-09-11 22:39 --- Subject: Re: VOLATILE in Fortran does not take effect On Fri, Sep 11, 2009 at 06:18:35PM -, kargl at gcc dot gnu dot org wrote: program VolatileTest double precision, volatile :: a double precision :: uA, uB, b, c real, volatile :: ra real :: ruA, ruB, rb, rc read(*,*) uA, uB, ruA, ruB a = uA * uA b = uB * uB c = a - b ra = ruA * ruA rb = ruB * ruB rc = ra - rb print *, c, rb end program VolatileTest Minor correction. The print statement should be print *, c, rc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41335
[Bug fortran/41192] NAMELIST input with just a comment (NAME ! comment \) fails
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2009-08-30 17:58 ---
Subject: Re: NAMELIST input with just a comment (NAME ! comment \) fails
On Sun, Aug 30, 2009 at 05:48:15PM -, kargl at gcc dot gnu dot org wrote:
--- Comment #2 from kargl at gcc dot gnu dot org 2009-08-30 17:48 ---
(In reply to comment #1)
Thanks for report , I will fix this.
It's not broken.
Here's my analysis, which could be wrong.
From the Fortran 2003 standard;
10.10.1 Namelist input
Input for a namelist input statement consists of
(1) Optional blanks and namelist comments,
(2) The character followed immediately by the namelist-group-name
as specified in the NAMELIST statement,
(3) One or more blanks,
(4) A sequence of zero or more name-value subsequences separated
by value separators, and
(5) A slash to terminate the namelist input.
10.10.1.6Namelist Comments
Except within a character literal constant, a ! character after a
value separator or in the first nonblank position of a namelist input
record initiates a comment.
In Section 10.9, one finds
A value separator is
(1) A comma optionally preceded by one or more contiguous blanks
and optionally followed by one or more contiguous blanks, unless
the decimal edit mode is COMMA, in which case a semicolon is
used in place of the comma,
(2) A slash optionally preceded by one or more contiguous blanks
and optionally followed by one or more contiguous blanks, or
(3) One or more contiguous blanks between two nonblank values or
following the last nonblank value, where a nonblank value is
a constant, an r *c form, or an r * form.
The namelist that appears to be causing an error in gfortran is
cmd
! change no values
/
The comment does not follow a value separator, so it comes down to
or in the first nonblank position of a namelist input record initiates
a comment. Now, going back to 10.10.1, the first nonblank position
in a namelist input record would need to come before the . That is,
the namelist should be
! change no values
cmd
/
This modification to the program suggests that my reading of the
Standard may be correct (although I have been known to get it wrong).
program cmdline
call process(' ', .false.)
call process('I=10 , J=20 K=30 ! change all three values', .false.)
call process(' ', .false.)
call process('! change no values', .true.) ! CAUSES ERROR IN GFORTRAN, NOT
G95
contains
subroutine process(string, invert)
implicit none
logical :: invert
character(len=*) :: string
character(len=132), save :: lines(3)
character(len=255) :: message
INTEGER :: I=1,J=2,K=3
integer ios
NAMELIST /CMD/ I,J,K
save cmd
if (invert .eqv. .true.) then
lines(2)='cmd'
lines(1)=string
lines(3)='/'
else
lines(1)='cmd'
lines(2)=string
lines(3)='/'
end if
READ(lines,NML=CMD,IOSTAT=ios,IOMSG=message)
if(ios.ne.0)then
write(*,*)'E-R-R-O-R: PROCESSING COMMAND LINE, IOSTAT=',IOS
write(*,*)message
endif
write(*,NML=CMD)
end subroutine process
end program cmdline
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41192
[Bug fortran/41192] NAMELIST input with just a comment (NAME ! comment \) fails
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2009-08-30 18:54 --- Subject: Re: NAMELIST input with just a comment (NAME ! comment \) fails On Sun, Aug 30, 2009 at 06:15:07PM -, jvdelisle at gcc dot gnu dot org wrote: Strictly speaking, Steve, I think you are correct. I have not finished my review of the standard. This is the first time I have seen namelist used like this for command line input. I suspect because it allows one to try many variations easily it will be a useful quick test tool. The embedded comment seems natural and in our code base we have a comment asking, should we allow '!' as a separator as an extension. We have thought about this issue before. I am going to give it some thinking time before doing anything here. Allowing a comment within a namelist to be the only entity on a line seems to be a logical extension to add. But, to claim that gfortran has an error seems to be erroneous. This extension should probably issue a warning with -std=f95 or f2003. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41192
[Bug fortran/41192] NAMELIST input with just a comment (NAME ! comment \) fails
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2009-08-31 00:30 --- Subject: Re: NAMELIST input with just a comment (NAME ! comment \) fails On Mon, Aug 31, 2009 at 12:07:34AM -, urbanjost at comcast dot net wrote: --- Comment #6 from urbanjost at comcast dot net 2009-08-31 00:07 --- Subject: Re: NAMELIST input with just a comment (NAME ! comment \) fails Because of 10.11.3.3-4 There isn't a Section 10.11.3.3 in the Final Committee Draft of the Fortran 2003 standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41192
[Bug regression/40800] libcpp breaks bootstrap
--- Comment #18 from sgk at troutmask dot apl dot washington dot edu 2009-07-20 17:56 --- Subject: Re: libcpp breaks bootstrap On Mon, Jul 20, 2009 at 05:42:50PM -, jlquinn at optonline dot net wrote: --- Comment #16 from jlquinn at optonline dot net 2009-07-20 17:42 --- (In reply to comment #14) Can you commit your fix http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01109.html or revert your change that is causing the problem? I posted the fix yesterday. I'm write-after-approval, and I thought I needed to wait for someone to OK the patch. The actual patch makes the change to configure.ac and regenerates configure from there. Given that your subject line includes freebsd8.0. I doubt anyone will jump up and review your patch unless you specifically ping the person who approved your original patch. I also doubt write-after-approval applies in a situation where your previous commit has completely broken the ability for more than one OS to bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40800
[Bug regression/40800] libcpp breaks bootstrap
--- Comment #20 from sgk at troutmask dot apl dot washington dot edu 2009-07-20 18:28 --- Subject: Re: libcpp breaks bootstrap On Mon, Jul 20, 2009 at 06:09:46PM -, jlquinn at gcc dot gnu dot org wrote: Author: jlquinn Date: Mon Jul 20 18:09:33 2009 New Revision: 149826 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149826 Log: 2009-07-20 Jerry Quinn jlqu...@optonline.net PR regression/40800 * configure.ac: Use = instead of == for testing ENABLE_BUILD_WITH_CXX. * configure: Rebuild. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40800
[Bug regression/40800] libcpp breaks bootstrap
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu 2009-07-19 05:30 --- Subject: Re: libcpp breaks bootstrap On Sun, Jul 19, 2009 at 05:09:31AM -, jlquinn at optonline dot net wrote: --- Comment #10 from jlquinn at optonline dot net 2009-07-19 05:09 --- (In reply to comment #9) Looks like the configure is broken. One thing I can see from the log is that configure is acting as if ENABLE_BUILD_WITH_CXX is enabled. Can you try the following patch on libcpp/configure, and see if that fixes the problem? Index: configure === --- configure (revision 149777) +++ configure (working copy) @@ -3342,7 +3342,7 @@ ac_config_commands=$ac_config_commands depdir -if test $ENABLE_BUILD_WITH_CXX == no; then +if test $ENABLE_BUILD_WITH_CXX = no; then depcc=$CC am_compiler_list= am_depcomp=$ac_aux_dir/depcomp @@ -3674,7 +3674,7 @@ # AC_CHECK_HEADERS is repeated to work around apparent autoconf 2.59 bug. If # AC_CHECK_HEADERS comes after the if clause, the last AC_LANG call gets used, # no matter which branch is taken. -if test $ENABLE_BUILD_WITH_CXX == no; then +if test $ENABLE_BUILD_WITH_CXX = no; then ac_ext=c ac_cpp='$CPP $CPPFLAGS' ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext 5' This patch appears to fix the problem. At least, bootstrap has made it past the initial build of libcpp. I don't know if this is the correct fix in that I know very little about autoconf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40800
[Bug bootstrap/40439] [4.5 Regression] Bootstrap broken on FreeBSD in tree.c
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu 2009-06-14 22:09 --- Subject: Re: [4.5 Regression] Bootstrap broken on FreeBSD in tree.c On Sun, Jun 14, 2009 at 06:02:26PM -, rguenth at gcc dot gnu dot org wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-14 18:02 --- Sth like Index: gcc/tree.c === --- gcc/tree.c (revision 148472) +++ gcc/tree.c (working copy) @@ -8499,7 +8499,8 @@ widest_int_cst_value (const_tree x) #if HOST_BITS_PER_WIDEST_INT HOST_BITS_PER_WIDE_INT gcc_assert (HOST_BITS_PER_WIDEST_INT = 2 * HOST_BITS_PER_WIDE_INT); - val |= TREE_INT_CST_HIGH (x) HOST_BITS_PER_WIDE_INT; + val |= (((unsigned HOST_WIDEST_INT)TREE_INT_CST_HIGH (x)) + HOST_BITS_PER_WIDE_INT); #else /* Make sure the sign-extended value will fit in a HOST_WIDE_INT. */ gcc_assert (TREE_INT_CST_HIGH (x) == 0 should fix this. The above patch fixes bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40439
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #9 from sgk at troutmask dot apl dot washington dot edu 2009-06-01 14:56 --- Subject: Re: Complex division by zero in gfortran returns wrong results On Mon, Jun 01, 2009 at 08:35:05AM -, ghazi at gcc dot gnu dot org wrote: --- Comment #2 from ghazi at gcc dot gnu dot org 2009-06-01 08:35 --- (In reply to comment #1) Kaveh, After looking into the problem, I think (nan + i nan) is an acceptable result for z = (-0.1,-2.2)/(0.0,0.0) because of the standard definition of complex division. For z2 = (0.1,1)/0, I think that you are correct, and gfortran should give (inf + i inf). Why is one different than the other? I don't know fortan promotion rules, but in C, the latter case promotes to (0.1,1.0)/(0.0,0.0) which looks very much like the first case. Does fortran handle type promotion differently? Regardless, I don't know that any standard definition of complex division applies here. The canonical algebraic formula is undefined mathematically in the presence of division by zero. So at least in C there are rules telling us what to do, and they say return Inf. Does fortran follow a standard here we can compare against or are we guessing? :-) Let's deal with the z = (-0.1,-2.2)/(0.0,0.0) case. This program, IMHO, needs to give a consistent answer. subroutine sub(z1, z2) implicit none complex z1, z2 print *, z1 / z2 end subroutine sub program a implicit none complex :: z1 = (-0.1,-2.2), z2 = (0.0,0.0) complex :: z3 = (-0.1,-2.2) / (0.0,0.0) call sub(z1, z2) print *, z3 end program a If one wants z3 to be inf or (inf + i inf) or anything other than (nan + i nan), then the complex division in sub() will cause an unacceptably large drop in performance because GCC would need to generate code to check all the special cases i.e., subroutine sub(z1, z2) implicit none complex z1, z2 if (real(z2) == 0. .and. aimag(z2) == 0.) then if (real(z1) == 0. .and. aimag(z1) then nan + i nan else if (aimag(z1) == 0.) then inf + i nan else if (real(z1) == 0.) then nan + i inf end if else print *, z1 / z2 end if end subroutine sub As for the second case of z = (0.1, 1) / 0, Fortran indeed has promotion rules (see Sec. 7.1.2 in Fortran 2003). This is transformed to z = (0.1, 1) / (0., 0.), so once again my above argument for a consistent result applies. PS: Please do not consider -ffast-math as a method to disable all of the checking. -ffast-math has too much baggage to be used with impunity. If MPC returns inf or (inf + i inf) and the MPC developers do not consider this to be a bug in their library, then gfortran will need to handle the division by zero during constant folding as a special case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu 2009-06-01 19:16 --- Subject: Re: Complex division by zero in gfortran returns wrong results On Mon, Jun 01, 2009 at 06:14:52PM -, ghazi at gcc dot gnu dot org wrote: - Comment #10 from ghazi at gcc dot gnu dot org 2009-06-01 18:14 --- (In reply to comment #9) If MPC returns inf or (inf + i inf) and the MPC developers do not consider this to be a bug in their library, then gfortran will need to handle the division by zero during constant folding as a special case. I believe the goals for MPC are to follow C99 rules for special cases. Thus the return value of (inf + i inf) is intentional for MPC and not a bug in their thinking. I entirely agree that the compile-time and runtime results should be identical. If it is your intention to preserve the existing runtime behavior, then we should do the same in the fortran folder and special case this if/when converting complex division to use MPC. Oh yuck. I just checked n1124.pdf In Annex G.5.1, it explicitly defines this behavior: if the first operand is a nonzero finite number or an infinity and the second operand is a zero, then the result of the / operator is an infinity. Combining this with G.3: A complex or imaginary value is a zero if each of its parts is a zero. What is disturbing is Example 2 in G.5.1 on page 470! Does gcc's runtime implementation of complex division mirror Example 2? I can understand the need to avoid under/overflow, but _Cdivd() seems overly complicated. Does this mean this PR should be closed as invalid ? I think we should leave it open, perhaps in a suspended state, as a reminder (to me) that soemthing needs to be done with gfortran an z/(0,0). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu 2009-04-30 16:09 --- Subject: Re: gfortran support for non-standard sind,cosd and friends intrinsics On Thu, Apr 30, 2009 at 07:38:31AM -, ruben at tapir dot caltech dot edu wrote: --- Comment #9 from ruben at tapir dot caltech dot edu 2009-04-30 07:38 --- Someone suggested multiplying or dividing the argument by a factor. That does not do - the floating point precision achieved would be insufficient. Yep. I even wrote the necessary code. You're more than welcomed to improve it. http://gcc.gnu.org/ml/fortran/2006-12/msg00329.html You need to (1) Treat special cases. (2) Add argument reduction in degrees. (3) Treat special cases of the reduced argument. (4) Convert to radians and use the hardware FPU, or implement a Remes polynomial approximation to evaluation the function in degrees. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452
[Bug fortran/39893] gfortran ICE on invalid program
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2009-04-26 03:29 --- Subject: Re: gfortran ICE on invalid program On Sat, Apr 25, 2009 at 08:47:19PM -, kargl at gcc dot gnu dot org wrote: --- Comment #4 from kargl at gcc dot gnu dot org 2009-04-25 20:47 --- I have a patch. I've come up with 2 different patches. Unfortunately, both have a few regressions. :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39893
[Bug fortran/38822] Compile-time simplification of x**(real)
--- Comment #14 from sgk at troutmask dot apl dot washington dot edu 2009-04-04 21:42 --- Subject: Re: Compile-time simplification of x**(real) On Sat, Apr 04, 2009 at 08:44:36PM -, dominiq at lps dot ens dot fr wrote: At revision 145521, the test from comment #2 returns: T F on (powerpc|i686)-apple-darwin9. Since I am not really interesting in this way to split hairs, do what ever you like. There are 2 URL's in comment #2. Specifically, see http://groups.google.com/group/comp.lang.fortran/msg/97c3ce6e98432ae9 That code on FreeBSD gives REMOVE:kargl[128] gfc4x -o z j2.f90 REMOVE:kargl[129] ./z T T The correct answer according to James van Buskirk is T F. The PR that fixed the ICE is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823 See the audit trail. I have no plans to back port this because it changes the underlying semantics of the design of arith.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822
[Bug fortran/39312] parameter (constant) and initialization with hex values
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu 2009-02-26 15:09 --- Subject: Re: parameter (constant) and initialization with hex values On Thu, Feb 26, 2009 at 02:59:05PM -, rvatne at gmail dot com wrote: running: gfortran -g -std=f95 -ffree-form -frange-check -c rv1.f90 -o rv1.o rvp.mnc:3.43: Included at rv1.f90:2: PARAMETER (SL_I4NOVALUE = Z'8000') 1 Error: Fortran 2003: BOZ used outside a DATA statement at (1) You got exactly what you asked the compiler to do. Remove the -std=f95 option if you don't want to enforce the Fortran 95 standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39312
[Bug target/39296] ICE in cselib_hash_rtx with -O -fPIC -mcmodel=large
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu 2009-02-25 22:38 --- Subject: Re: ICE in cselib_hash_rtx with -O -fPIC -mcmodel=large On Wed, Feb 25, 2009 at 01:47:45AM -, hjl dot tools at gmail dot com wrote: --- Comment #1 from hjl dot tools at gmail dot com 2009-02-25 01:47 --- I can't reproduce it on Linux with revision 144417. I believe it is a dup of PR 38988. Reopen it if it isn't fixed in trunk. *** This bug has been marked as a duplicate of 38988 *** Testing shows that the bug was fixed by revision 144417. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39296
[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2009-01-13 19:43 --- Subject: Re: New: Diagnose and treat (-2.0)**2.0 properly On Tue, Jan 13, 2009 at 11:08:40AM -, burnus at gcc dot gnu dot org wrote: Fortran 2003 in the second sentence of the second paragraph of 7.1.8 Evaluation of Operations: Raising a negative-valued primary of type real to a real power is prohibitted. The question is whether one needs to reject it completely or only with -std=f95. Steve (see thread) thinks the constant folding gets it wrong (- gives 4.0). For constant folding, it will be rejected because it can be detected at compile time. Current results: - Runtime and compile time evaluation (ifort, gfortran, g95): -2.0**2.0 = 4.0 -2.0**1.9 = NaN I believe you're missing ( ) around -2.0 because ** has higher precedence than unary minus. - Mathematica: -2^2 = 4, -2.0^2.0 = -4.0 2.0^1.9 = -3.73213 Try putting ( ) around -2 in the above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823
[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu 2009-01-13 19:44 --- Subject: Re: Diagnose and treat (-2.0)**2.0 properly On Tue, Jan 13, 2009 at 11:28:05AM -, pinskia at gmail dot com wrote: -2.0^1.9 will be a complex number. Maybe we can define it as taking the real part. I don't know if that is better than generating a nan here. The ** operator has higher precedence than unary minus. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823
[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2009-01-13 19:55 ---
Subject: Re: Diagnose and treat (-2.0)**2.0 properly
On Tue, Jan 13, 2009 at 11:30:40AM -, dominiq at lps dot ens dot fr wrote:
--- Comment #2 from dominiq at lps dot ens dot fr 2009-01-13 11:30
---
The question is whether one needs to reject it completely or only with
-std=f95.
I vote for only with -std=f95 with may be a warning otherwise.
It will be a compile time error during constant folding. The compiler
can detect (-2.)**some_real_entity.
I think it is a legitimate optimization to replace A**B by A**I (with I=B)
when B is known to be an integer, hence to accept negative values for A
in this case.
I have no plans to change this optimization.
I find upsetting to have to cheat with variables when constant folding
does not give the same result as a similar code with variables.
In the general case,
function my_pow(x,y)
real my_pow
real x, y
my_pow = x**y
end function my_pow
we have
my_pow (real(kind=4) x, real(kind=4) y)
{
real(kind=4) __result_my_pow;
{
real(kind=4) D.1525;
D.1525 = *x;
__result_my_pow = __builtin_powf (D.1525, *y);
}
return __result_my_pow;
}
I intend to change this, conditional on perhaps -ffast-math and/or -pedantic,
to
D.1525 = *x;
if (D.1525 0)
runtime_error( )
else
__result_my_pow = __builtin_powf (D.1525, *y);
gfortran's default behavior in this instance should be conformance to
the Standards.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823
[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu 2009-01-13 19:58 --- Subject: Re: Diagnose and treat (-2.0)**2.0 properly On Tue, Jan 13, 2009 at 11:37:25AM -, dominiq at lps dot ens dot fr wrote: --- Comment #3 from dominiq at lps dot ens dot fr 2009-01-13 11:37 --- - Mathematica: -2^2 = 4, -2.0^2.0 = -4.0 2.0^1.9 = -3.73213 --- probably -2.0^1.9! Apparently Mathematica parse -2.0^a as -(2.0^a). (-2.0)^1.9 gives 3.54947- 1.15329 I. I don't know if the fortran standard says how -a**b should be parsed (nor have the time right now to decipher the legalese). See Note 7.30 in the Fortran 2003 Standard. -a**b is parsed as if it were written as -(a**b). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823
[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu 2009-01-13 21:30 --- Subject: Re: Diagnose and treat (-2.0)**2.0 properly On Tue, Jan 13, 2009 at 09:13:57PM -, dominiq at lps dot ens dot fr wrote: --- Comment #10 from dominiq at lps dot ens dot fr 2009-01-13 21:13 --- I intend to change this, conditional on perhaps -ffast-math and/or -pedantic, I don't understand the and/or: -ffast-math and -pedantic at the same time does not make any sense for me, -ffast-math allows some sloppiness with respect to the standard, while -pedantic does not. I haven't decided how I want to handle the general case. There are few possibilities: gfortran file.f90 Do nothing, ie., the status quo gfortran -pedantic file.f90 Add a runtime check that x in x**y is not 0. or gfortran file.f90 Add a runtime check that x in x**y is not 0. gfortran -ffast-math file.f90 Do not add a runtime check. or gfortran -fsome_new_option file.f90 Add a runtime check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823
[Bug fortran/38763] [4.3/4.4 Regression] Yet another TRANSFER ICE
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu 2009-01-08 17:23 --- Subject: Re: [4.3/4.4 Regression] Yet another TRANSFER ICE On Thu, Jan 08, 2009 at 04:42:52PM -, pault at gcc dot gnu dot org wrote: gfc_target_encode_expr has no means to deal with EXPR_NULL. It's quite easy to change that, so I have assigned myself. I haven't had time to look at the code. Thanks for the report. Yet another don't be so hard! Making TRANSFER work has been a balls-breaker of a job. It was meant in jest. I'll change the summary to something more pleasing. BTW, James claims that some other failures occur, but I can't reproduce those. See http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/01722ebb249bdb26# -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38763
[Bug libgomp/38724] Segfault caused by derived-type with allocatable component in private clause
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu 2009-01-05 02:32 --- Subject: Re: Segfault caused by derived-type with allocatable component in private clause On Sun, Jan 04, 2009 at 09:31:20PM -, jakub at gcc dot gnu dot org wrote: --- Comment #5 from jakub at gcc dot gnu dot org 2009-01-04 21:31 --- OpenMP 3.0 doesn't cover types with allocatable components, so this is undefined. If anything IMHO we should reject any attempts to privatize types with allocatable components, because it isn't clear what will OpenMP 4.0 require for them and if we now implement something different, it might be a compatibility problem. OK. Thanks for the info concerning OpenMP 3.0 and allocatable components. I agree gfortran should reject the program until we have some idea of the behavior with regards to OpenMP 4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38724
[Bug fortran/37961] [F2003] random_seed - allow integer(8) for the arguments
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu 2008-10-31 06:57 --- Subject: Re: [F2003] random_seed - allow integer(8) for the arguments On Fri, Oct 31, 2008 at 06:44:07AM -, burnus at gcc dot gnu dot org wrote: INVALID - only default integers are allowed Tobias, thanks. In reviewing my previous post, the post may have appeared confrontational. That was completely unintention. I was just trying to convey what the various standards say. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37961
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #24 from sgk at troutmask dot apl dot washington dot edu 2008-10-31 14:37 --- Subject: Re: gfortran error and ICE at automatic type conversion with transfer intrinsic On Fri, Oct 31, 2008 at 01:10:21PM -, burnus at gcc dot gnu dot org wrote: --- Comment #23 from burnus at gcc dot gnu dot org 2008-10-31 13:10 --- in any case NaN can be unambiguously converted from one real/complex to another real/complex kind. I disagree with the last sentence since there in not a single (or dual if you take into account signaling NaN's) NaN entity, but a whole class of them. Still IEEE 754-2008 defines what a signalling/quiet NaN is; with regards to a programmer, NaN is NaN and the exact bit pattern should not matter; and for qNaN and sNaN - if you don't have IEEE trapping turned on, you effectively have a quiet NaN in either case. Independent of the bit pattern x /= x is always true if x is NaN and if x is NaN, y = x*5 will assign NaN to y. Thus I don't see any ambiguity. First, gfortran (especially the constant folding) doesn't follow IEEE754 for NaN. AFAIK, there is no distinction between qNaN and sNaN. That being said, from Draft 1.2.5 of the revised standard, section 8.2.3 states: Conversion of a quiet NaN to a floating-point format of the same or a different radix that does not allow the payload to be preserved, should return a quiet NaN that should provide some language-defined diagnostic information. It appears that gfortran's error message is providing some language-defined diagnostic information. I'll also note that the diagnostic information tells you how to disable the range checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #26 from sgk at troutmask dot apl dot washington dot edu 2008-10-31 22:14 --- Subject: Re: gfortran error and ICE at automatic type conversion with transfer intrinsic On Fri, Oct 31, 2008 at 09:43:13PM -, burnus at gcc dot gnu dot org wrote: I'll also note that the diagnostic information tells you how to disable the range checking. That is actually not true: For ARITH_NAN and ARITH_UNDERFLOW there is no -fno-range-check mentioned - only for ARITH_OVERFLOW is. I don't use -fno-range-check unless I'm debugging some PR, so I forgot the details. ARITH_UNDERFLOW doesn't require any special handling (ie., they are set to zero). We could extend -fno-range-check to allow the conversion of a REAL NaN to a DOUBLE PRECISION NaN. I'm not too excited by that idea. Question: Is this bug now fixed or remains something else to do? (Besides mentioning -fno-range-check in the error message and implementing F2003's IEEE functions.) Personally, I think the bug is fixed, and this PR can be closed. I thought FX had opened a PR for the IEEE module, but a quick scan did not find it. I guess it doesn't make much sense opening a PR for every unimplemented F2003 feature. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug fortran/37961] [F2003] random_seed - allow integer(8) for the arguments
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu 2008-10-31 01:02 --- Subject: Re: [F2003] random_seed - allow integer(8) for the arguments I just checked the F2008 draft for the next standard. It says 13.7.95 RANDOM SEED ([SIZE, PUT, GET]) Description. Restarts or queries the pseudorandom number generator used by RANDOM_NUMBER. Class. Subroutine. Arguments. There shall either be exactly one or no arguments present. SIZE (optional) shall be scalar and of type default integer. It is an INTENT (OUT) argument. It is assigned the number N of integers that the processor uses to hold the value of the seed. PUT (optional) shall be a default integer array of rank one and size N . It is an INTENT (IN) argument. It is used in a processor-dependent manner to compute the seed value accessed by the pseudorandom number generator. GET (optional) shall be a default integer array of rank one and size N It is an INTENT (OUT) argument. It is assigned the current value of the seed. I think this PR should be closed with a WONTFIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37961
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #20 from sgk at troutmask dot apl dot washington dot edu 2008-10-31 04:55 --- Subject: Re: gfortran error and ICE at automatic type conversion with transfer intrinsic On Fri, Oct 31, 2008 at 04:27:23AM -, deji_aking at yahoo dot ca wrote: From comment 1: Adw_xabcd_8(1:n) = transfer(-1,1.0) ! Adw_xabcd_8 is REAL That makes sense: One assigns NaN to a real variable (though a comment would be helpful). However Does this mean gfortran shouldn't give an error message on the first part (with the real variable) of the bug report? It seems the patch to fix this only deals with the integer variable assignment. No. gfortran is giving you an error because you are trying to convert a NaN for a REAL type to a DOUBLE PRECISION value. This also makes no sense. If you want a DOUBLE PRECISION NaN, then use transfer(-1,1.d0). The conversion code for REAL to DOUBLE PRECISION properly handled this problem. The patch I submitted for INTEGER was for a code path into the REAL to INTEGER routine that no one had ever triggered. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu 2008-10-28 14:03 --- Subject: Re: gfortran error and ICE at automatic type conversion with transfer intrinsic On Tue, Oct 28, 2008 at 01:30:28PM -, dominiq at lps dot ens dot fr wrote: --- Comment #5 from dominiq at lps dot ens dot fr 2008-10-28 13:30 --- On *-Darwin9 I get: i = transfer(-1,1.0) 1 Error: Arithmetic overflow converting REAL(4) to INTEGER(4) at (1). This check can be disabled with the option -fno-range-check What does program test print *, transfer(-1,1.0) end program test print? I have not tested the patch in http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01183.html, but I am afraid that it will just hide the bug. The actual bug is in the Fortran code! My patch simply fixes the ICE in gfortran. By itself, transfer(-1,1.0) is valid and it so happens to be an NaN. i = NaN is invalid (although I doubt the standard will actually say i = NaN is invalid in a straight forward manner). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu 2008-10-28 15:03 --- Subject: Re: gfortran error and ICE at automatic type conversion with transfer intrinsic On Tue, Oct 28, 2008 at 02:36:07PM -, dominiq at lps dot ens dot fr wrote: What does ... print? NaN on both ppc/intel-Darwin9. My patch simply fixes the ICE in gfortran. I think the conversion of NaN to int is buggy since the behavior is platform/option dependent. Your patch just prevents to reach the bug. It always make me nervous when a bug is hidden without being understood. i = NaN is an assignment not a bitwise copy. This isn't platform dependent nor option dependent. You simply can't assign a NaN to an INTEGER. In thinking about transfer(-1,1.0), this may also be invalid because the standard forbids calling an intrinsic procedure if it will return a result outside the representable range of the return type. There is probably some argument on whether NaN is this range. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu 2008-10-28 16:19 --- Subject: Re: gfortran error and ICE at automatic type conversion with transfer intrinsic On Tue, Oct 28, 2008 at 03:47:30PM -, deji_aking at yahoo dot ca wrote: --- Comment #9 from deji_aking at yahoo dot ca 2008-10-28 15:47 --- (In reply to comment #7) What does ... print? NaN on both ppc/intel-Darwin9. My patch simply fixes the ICE in gfortran. I think the conversion of NaN to int is buggy since the behavior is platform/option dependent. Your patch just prevents to reach the bug. It always make me nervous when a bug is hidden without being understood. When I run program test integer i i = transfer(-1,1.0) print *, i end I get -2147483648 with gcc-4.2, ifort, and pgf90 on x86_64 Linux, and same value with xlf on AIX with power5. What does program test print *, transfer(-1,1.0) end program test print with those compilers? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug fortran/37930] gfortran error and ICE at automatic type conversion with transfer intrinsic
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu 2008-10-28 18:40 --- Subject: Re: gfortran error and ICE at automatic type conversion with transfer intrinsic On Tue, Oct 28, 2008 at 05:51:06PM -, dominiq at lps dot ens dot fr wrote: i = NaN is an assignment not a bitwise copy. This isn't platform dependent nor option dependent. You simply can't assign a NaN to an INTEGER. Before the assignment, there is an attempt to convert the real 'NaN' to a default integer. i = 1.23456 -- i = 1 i = 3.14149 -- i = 3 i = NaN -- i = what goes here? This conversion is platform dependent. Now consider the following code: i = -huge(1.0) print *, i, -huge(1.0) end which compiles without problem with the option -fno-range-check and gives at As soon as you used the -fno-range-check option, you are telling gfortran to violate the standard. gfortran can do whatever it pleases. troutmask:kargl[213] gfc -o z -fno-range-check -fdump-parse-tree j.f90 ASSIGN MAIN__:i 340282346638528859811704183484516925440 WRITE UNIT=6 FMT=-1 TRANSFER MAIN__:i TRANSFER 3.40282347e38 DT_END Looks like the well-known integer wrap around issue. What is mod(34028..., 2^32)? Could also be 2^31 - 1; too lazy to investigate any farther. run time: 0 -3.40282347E+38 Is -3.40282347E+38 more valid than NaN or -Inf? Or is that the extension has not been defined for the later real values? What happens without -fno-range-check? In thinking about transfer(-1,1.0), this may also be invalid because the standard forbids calling an intrinsic procedure if it will return a result outside the representable range of the return type. There is probably some argument on whether NaN is this range. My point of view has always been that +/-Inf and NaN's should abort the executable, but I seems alone to think so! See -ffpe-trap option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37930
[Bug fortran/19925] Implied do-loop in an initialization expression is broken
--- Comment #28 from sgk at troutmask dot apl dot washington dot edu 2008-09-07 16:33 --- Subject: Re: Implied do-loop in an initialization expression is broken On Sun, Sep 07, 2008 at 08:25:54AM -, linuxl4 at sohu dot com wrote: somebody fix it please. If it were easy to fix, someone would have done this already. Please read the audit trail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
[Bug fortran/37399] gfortran.dg/size_kind.f90 doesn't work
--- Comment #1 from sgk at troutmask dot apl dot washington dot edu 2008-09-06 18:14 --- Subject: Re: New: gfortran.dg/size_kind.f90 doesn't work On Sat, Sep 06, 2008 at 06:10:58PM -, hjl dot tools at gmail dot com wrote: On Linux/ia32, revision 140065 gave FAIL: gfortran.dg/size_kind.f90 -O (test for excess errors) The tesst should be removed. It requires 8 GB of memory and on small memory system it will swap itself to death. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37399
[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc
--- Comment #29 from sgk at troutmask dot apl dot washington dot edu 2008-09-04 06:15 --- Subject: Re: [4.4 Regression] Bootstrap failure compiling libgcc On Thu, Sep 04, 2008 at 05:53:28AM -, hjl dot tools at gmail dot com wrote: --- Comment #28 from hjl dot tools at gmail dot com 2008-09-04 05:53 --- (In reply to comment #27) I now get on i586-linux at revision 139953 I'll investigate tomorrow. Can you try ira-merge branch? It will help determine if it is caused by IRA merge. Thanks. HJ, I think you meant to respond to Eric instead of me. Vlad's patch fixed the original problem for me and Eric, but Eric is now see a new problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296
[Bug tree-optimization/37310] gfortran errors in compilation and the making for upgraded compilers
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu 2008-09-02 16:57 --- Subject: Re: gfortran errors in compilation and the making for upgraded compilers On Tue, Sep 02, 2008 at 12:11:23PM -, petermorgan at grapevine dot net dot au wrote: gfortran -O -Wuninitialized -fno-automatic -fno-backslash tssum.f ../gen_util/gen_util_lib.a ../../libraries/matrix/kinv_lib.a ../../libraries/comlib/com_lib.a -o tssum tssum.f: In function 'remove_ejmp': tssum.f:712: internal compiler error: in set_uids_in_ptset, at tree-ssa-structalias.c:4789 I cannot reproduce this problem with troutmask:sgk[225] gfortran42 --version GNU Fortran (GCC) 4.2.5 20080702 (prerelease) troutmask:sgk[226] gfortran43 --version GNU Fortran (GCC) 4.3.2 20080717 (prerelease) troutmask:sgk[227] gfc4x --version GNU Fortran (GCC) 4.4.0 20080829 (experimental) [trunk revision 139774] Of coures, I can only do a compile test because I do not have the source code for the kinv_lib.a so I can't link a final executable. Can you email me off-list a gzipped tar ball of all the need files? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37310
[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc
--- Comment #14 from sgk at troutmask dot apl dot washington dot edu 2008-09-01 16:56 --- Subject: Re: Bootstrap failure due to __muldi3 On Mon, Sep 01, 2008 at 10:30:27AM -, graham dot stott at btinternet dot com wrote: --- Comment #10 from graham dot stott at btinternet dot com 2008-09-01 10:30 --- From the backtrace I very doubt this is a IRA issue. I looks to be related to the recent IPA/CGRAPG changes so it's one for Honza to look at While Vlad's IRA patches may not be directly responsible, the evidence shows that if I revert Vlad's patches my tree then builds. I'll put Vlad's stuff back into my tree and see if I can locate if it is one of Honza's patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296
[Bug fortran/35299] scope of variables in statement function do not acquire rank from host
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu 2008-08-08 23:46 --- Subject: Re: scope of variables in statement function do not acquire rank from host On Fri, Aug 08, 2008 at 09:06:37PM -, jv244 at cam dot ac dot uk wrote: --- Comment #9 from jv244 at cam dot ac dot uk 2008-08-08 21:06 --- what is the 'rejects-valid' testcase here? apart from ifort, all compilers I can access right now reject the program in the initial comment. -- Well, to start with, the code in comment #1 is valid Fortran 95. See comment #3. In checking, F2003 the exact same text appears. I suppose you need to file bug reports with the other compiler vendors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35299
[Bug fortran/36251] PUBLIC and PRIVATE abuse
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu 2008-05-16 22:01 --- Subject: Re: PUBLIC and PRIVATE abuse I have a patch for this. It simply issues a warning because it appears to be benign. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36251
[Bug fortran/36251] PUBLIC and PRIVATE abuse
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2008-05-16 22:10 ---
Subject: Re: PUBLIC and PRIVATE abuse
On Fri, May 16, 2008 at 09:58:47PM -, burnus at gcc dot gnu dot org wrote:
And using
bind(C) :: a
Nice catch.
gives even an ICE. For PUBLIC and PRIVATE, see the patch below. save
and value are not needed they give already the error Cannot change
attributes of USE-associated symbol a. (My hope was that one gets a
better error message, but one does not.)
Your patch is similar to my initial patch, and I also found the
error message to be less than informative. Here, my alternative.
Index: symbol.c
===
--- symbol.c(revision 135407)
+++ symbol.c(working copy)
@@ -361,6 +361,13 @@
if (where == NULL)
where = gfc_current_locus;
+ if (attr-flavor == FL_MODULE
+ (attr-access == ACCESS_PUBLIC || attr-access == ACCESS_PRIVATE))
+{
+ a1 = attr-access == ACCESS_PUBLIC ? public : private;
+ gfc_warning (%s attribute applied to MODULE %s at %L, a1, name,
where);
+}
+
I chose a warning instead of an error because this issue doesn't
seem to effect anything.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36251
[Bug fortran/35299] scope of variables in statement function do not acquire rank from host
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu 2008-02-29 20:15 --- Subject: Re: scope of variables in statement function do not acquire rank from host On Fri, Feb 29, 2008 at 05:53:40PM -, fxcoudert at gcc dot gnu dot org wrote: I disagree. In Fortran 2003 12.5.4, C1263/R1238 says The function-name and each dummy-arg-name shall be specified, explicitly or implicitly, to be scalar.. Intel accepts it, but IBM, g95 and (most importantly) Lahey think it's invalid. However, the error message should point to the statement function. The patch below gives, in my opinion, a better error message: HSTAR(E,B)=B**.4*((1.25*FUN(-E/40)+.18)) ! Doesn't work. 1 Error: Argument 'e' of statement function 'hstar' at (1) must be scalar I disagree with your disagreement. :-) Gordon Sande and Richard Maine also disagrees with you (see c.l.f threads I've never seen this before in 30 years - what is this? and What is this). From Fortran 95, Sec. 12.5.4, lines 38 and 39: The dummy arguments have a scope of the statement function. Each dummy argument has the same type and type parameters as the entity of the same name in the scoping unit containing the statement function. Note, this passage does not include rank. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35299
[Bug fortran/35299] scope of variables in statement function do not acquire rank from host
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2008-02-29 20:41 --- Subject: Re: scope of variables in statement function do not acquire rank from host On Fri, Feb 29, 2008 at 08:23:16PM -, fxcoudert at gcc dot gnu dot org wrote: (In reply to comment #3) The dummy arguments have a scope of the statement function. Each dummy argument has the same type and type parameters as the entity of the same name in the scoping unit containing the statement function. Note, this passage does not include rank. No, but it does not say that they are scalar either. It does not say Each dummy argument is a scalar of the same type and type parameters If we follow this interpretation, then what does The function-name and each dummy-arg-name shall be specified, explicitly or implicitly, to be scalar mean? In your (and Richard Maine's and ...) reading, the dummy arguments are by definition scalar, and so how can they be specified, explicitly or implicitly, to be scalar. Or, to say it the other way around, let's say that I want to break this particular constraint, how do I explicitly specify one of my dummy arguments not to be a scalar? I'm thoroughly confused. Don't worry, I share your confusion (when I read the standard). :) I think the passage you quote applies to the following code: program z real :: y = 2. real :: x(5) = 1. f(x(2:4)) = 2 * sum(x) ! dummy arg is an array. g(y) = y * x ! function g is an array because of x. end program z I just found the definition of type parameters in 2.4.1.1. The type parameters are KIND and LEN. All other attributes are irrelevant. PS: I see you just found the c.l.f threads. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35299
[Bug fortran/35299] scope of variables in statement function do not acquire rank from host
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2008-02-29 23:05 --- Subject: Re: scope of variables in statement function do not acquire rank from host On Fri, Feb 29, 2008 at 10:55:31PM -, fxcoudert at gcc dot gnu dot org wrote: --- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-02-29 22:55 --- I've thought about it more, and it's probably going to be tricky to solve: after we have matched the formal arglist, we need to fill the namespace with replacement symbols for all the dummy args (stripping them from their attributes other than type and kind), then match the body of the statement function, then remove these symbols and go on with our life. I don't know the resolution code well enough to do that :( This bug pre-dates gfortran (at least it is also in g95). gfortran has compiled a ton of F77 code, and this is the first instance that I've seen. I think this bug is way down the priority list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35299
[Bug fortran/35299] scope of variables in statement function do not acquire rank from host
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu 2008-02-29 23:52 --- Subject: Re: scope of variables in statement function do not acquire rank from host Don't worry, I share your confusion (when I read the standard). :) I think the passage you quote applies to the following code: program z real :: y = 2. real :: x(5) = 1. f(x(2:4)) = 2 * sum(x) ! dummy arg is an array. g(y) = y * x ! function g is an array because of x. end program z Well, Richard Maine shot these down from other considerations. The x(2:4) isn't a dummy-arg-name, so that one's out. In 'g(y) = y * x', the RHS is not a scal-expr, so that one's out. BTW, I don't use statement function, and I've come to dislike them even more after thinking about this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35299
[Bug testsuite/34878] fast-math-pr33299.f90 failure with illegal instruction due to -ffast-math.
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2008-02-26 18:00 --- Subject: Re: fast-math-pr33299.f90 failure with illegal instruction due to -ffast-math. On Tue, Feb 26, 2008 at 05:53:52PM -, ghazi at gcc dot gnu dot org wrote: --- Comment #6 from ghazi at gcc dot gnu dot org 2008-02-26 17:53 --- Isn't this a dup of 34168? It appears to be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34878
[Bug fortran/35223] IBITS gives compiler error
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu 2008-02-17 18:09 --- Subject: Re: IBITS gives compiler error On Sun, Feb 17, 2008 at 01:10:06PM -, dominiq at lps dot ens dot fr wrote: I dont want to rant again about gfortran feature, but nevertheless I'll repeat that this error should not be the default behavior (even a warning will an overkill that should be restricted to -std=f* -pedantic). You're more than welcomed to submit a patch. Now I think the gfortran behavior is inconsistent with this respect. The following code print *, not(0), iand(-1,-1)!, ibits (-1, 0, bit_size (0)) print *, ibset(2147483647, bit_size(0)-1) end compiles silently and the executable prints: -1 -1 -1 Why 2**32-1 should give an error as the result of ibits(-1, 0, bit_size (0)) and -1 as the result of ibset(2147483647, bit_size(0)-1)? I don't remember the details for NOT() other than the simplification isn't simply because of the internal representation with GMP and GMP does not have a mpz_not function. So, NOT() may accidentally get the expected answer. I'm unfamiliar with the other functions you mentioned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223
[Bug fortran/35223] IBITS gives compiler error
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu 2008-02-17 19:59 --- Subject: Re: IBITS gives compiler error On Sun, Feb 17, 2008 at 07:10:19PM -, jvdelisle at gcc dot gnu dot org wrote: --- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-02-17 19:10 --- We do need to fix some things here. The runtime perhaps should catch the invalid of pos + len 32 for bit_size being 32. (snip) So I support removing the range check just for these bit manipulation procedures. Yes, that is probably a good compromise, then let the middle-end deal with possible out of range values. One probably needs to check the expansion of i = -1 i = ibits(i,0,32) -fdump-tree-original shows i = -1; i = i 0 ~(-1 32); for the above, which of course gives the user desired result of -1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35223
[Bug fortran/19925] Implied do-loop in an initialization expression is broken
--- Comment #26 from sgk at troutmask dot apl dot washington dot edu 2008-02-02 16:38 --- Subject: Re: Implied do-loop in an initialization expression is broken On Sat, Feb 02, 2008 at 11:09:36AM -, dominiq at lps dot ens dot fr wrote: A short term solution could be to improve the error message when the 65535 limit is reached: Initialization expression didn't reduce does not point clearly to this limit. An error (if correct?) such that Array constructors cannot have more than 65535 elements will give a better diagnostic of what's going wrong. 65535 was arbitrarily chosen by me. This value allowed the fmlib package to compile and run. 65535 should actually be spelled as 100 (or maybe even smaller). Short term solutions have the uncanny nature of becoming long term bandaids. See PR 19925 for an example. Erik suggested in comment #6 one possible solution to the problem. In the mailing list or IRC, Paul Brook suggested that a CTOR/DTOR methods should be considered. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
[Bug fortran/19925] Implied do-loop in an initialization expression is broken
--- Comment #21 from sgk at troutmask dot apl dot washington dot edu 2008-02-01 16:04 --- Subject: Re: Implied do-loop in an initialization expression is broken On Fri, Feb 01, 2008 at 03:31:49PM -, dominiq at lps dot ens dot fr wrote: With the patch in comment #18, on a Core2Duo 2.16Ghz I get: 5000 0.54 secs 1 1.82 2 6.74 436.5 6 206 65535 258 65536 68 -- Error: Initialization expression didn't reduce (1) 8 149Ditto 10 281Ditto So the threshold seems to be 2**16. 'grep ChangeLog-2005 6553'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
[Bug target/34878] fast-math-pr33299.f90 failure with illegal instruction due to -ffast-math.
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu 2008-01-20 04:17 --- Subject: Re: fast-math-pr33299.f90 failure with illegal instruction due to -ffast-math. On Sun, Jan 20, 2008 at 04:09:19AM -, pinskia at gcc dot gnu dot org wrote: What instructions is causing the crash? Are you testing on a machine which has SSE2 ? Nope. From FreeBSD's dmesg: CPU: AMD Athlon(tm) Processor (1208.75-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x642 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc0440800SYSCALL,b18,MMX+,3DNow!+,3DNow! SSE2 isn't one of the listed features. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34878
[Bug fortran/34533] DTIME returns total process time and not since last invocation
--- Comment #9 from sgk at troutmask dot apl dot washington dot edu 2007-12-20 22:27 --- Subject: Re: DTIME returns total process time and not since last invocation On Thu, Dec 20, 2007 at 09:39:29PM -, dfranke at gcc dot gnu dot org wrote: Daniel, are you working on this PR? Sort of. Finished the library part. Btw, CPU_TIME has a fallback implementation using times(2). As times() returns the number of clock ticks that have elapsed since an arbitrary point in the past, it is IMO unsuitable to be used with CPU_TIME. CPU_TIME is supposed to return a value representing the elapsed CPU time in seconds [since start of the program]. Thus, I ditched this fallback for the common implementation. Actually, you don't need to remove the fallback because Niote 13.8 in the F95 standard makes it clear that the initialize time does not need to be referenced to zero. From Note 13.8: The start time is left imprecise because the purpose is to time sections of code, as in the example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34533
[Bug fortran/34230] Expressions of parameters evaluated with too high precision
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu 2007-11-28 20:08 --- Subject: Re: Expressions of parameters evaluated with too high precision On Wed, Nov 28, 2007 at 07:23:57PM -, fxcoudert at gcc dot gnu dot org wrote: To sum up my point of view: -fno-range-check is about accepting code which is, strictly speaking, invalid. It is thus an extension and we should be guided by a) what other compilers do, b) consistency, c) least surprise. Moreover, I don't think changing that behaviour would hurt maintainability much (but I might be wrong; we'll know when someone starts working on it). I have a patch that does what people seem to want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34230
[Bug fortran/33544] Spurious warning in TRANSFER intrinsic in Sept 24 snapshot of gfortran
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2007-09-24 19:59 ---
Subject: Re: Spurious warning in TRANSFER intrinsic in Sept 24 snapshot of
gfortran
On Mon, Sep 24, 2007 at 07:17:54PM -, burnus at gcc dot gnu dot org wrote:
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-24 19:17
---
We may want to hide the warning behind a -Wshort-transfer option
(or some other appropriate name).
Maybe; I think having a warning by default would be more reasonable but it
should be hideable.
I don't fell strongly either way, but I do agree one should be able to
turn off/on the warning.
Afterall, if a programmer wrote 'rft = transfer(' ', 0.0)',
then s/he probably meant it.
I sincerely doubt that the programmer meant that this piece of code produces
different results depending on the compiler and possibly some random value in
memory.
It may not produce random values each time (see below). Michael (a user)
did file a bug report, and knowing him for previous bug reports and posts
elsewhere on the net, I suspect he did intend the short transfer.
For the given example, many compilers seem to initialize the result
with zero; example:
PROGRAM printd
REAL :: rft
rft = TRANSFER(' ', 0.0)
print *, rft
rft = TRANSFER(' '//achar(0)//achar(0)//achar(0), 0.0)
print *, rft
END PROGRAM printd
The second transfer produces: 4.4841551E-44
g95, ifort and openf95 seem to produce the same result also for the first
TRANSFER.
gfortran, NAG f95 and sunf95 have, however, a different result every time.
Thus, if one wants to argue that the programmer intended a certain value, I
would argue that it is the one using a zero-padded SOURCE.
The programmer for whatever reason could be using rft as temporary storage.
Yes, I know it's a hypothetical situation, but the following is legal code
and should not give a warning.
program m
character c
real rft
rft = transfer(' ', 0.)
! print *, rft -- Uncommenting may make this invalid code
c = transfer(rft, c)
if (c .eq. ' ') print *, 'space'
end program
Note, if I uncomment the print statement, on x86_64-*-freebsd, it prints
a NaN every time I execute the program.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33544
[Bug fortran/33544] Spurious warning in TRANSFER intrinsic in Sept 24 snapshot of gfortran
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2007-09-24 21:49 --- Subject: Re: Spurious warning in TRANSFER intrinsic in Sept 24 snapshot of gfortran On Mon, Sep 24, 2007 at 09:26:01PM -, pinskia at gmail dot com wrote: On 24 Sep 2007 19:59:37 -, sgk at troutmask dot apl dot washington dot edu [EMAIL PROTECTED] wrote: The programmer for whatever reason could be using rft as temporary storage. Yes, I know it's a hypothetical situation, but the following is legal code and should not give a warning. Though I will argue that is just bad coding. It doesn't matter if it's bad coding (which I can agree). AFAIK, the standard says the code is legal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33544
[Bug fortran/31244] data initialization with more than 2**32 elements
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu
2007-09-18 18:02 ---
Subject: Re: data initialization with more than 2**32 elements
On Tue, Sep 18, 2007 at 05:56:36PM -, kargl at gcc dot gnu dot org wrote:
The problem is found in decl.c(top_val_list) at lines 404-411, which
are
signed int tmp;
msg = gfc_extract_int (expr, tmp);
gfc_free_expr (expr);
if (msg != NULL)
{
gfc_error (msg);
return MATCH_ERROR;
}
gfc_extract_int is trying to put 4294967296_8 into a signed int.
This probably needs to be changed to accommodate the type of
an array index.
For completeness, the line 412 is 'tail-repeat = tmp'
where tail-repeat is an unsigned int.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31244
[Bug fortran/31244] data initialization with more than 2**32 elements
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2007-09-18 19:16 ---
Subject: Re: data initialization with more than 2**32 elements
On Tue, Sep 18, 2007 at 06:02:03PM -, sgk at troutmask dot apl dot
washington dot edu wrote:
The problem is found in decl.c(top_val_list) at lines 404-411, which
are
signed int tmp;
msg = gfc_extract_int (expr, tmp);
gfc_free_expr (expr);
if (msg != NULL)
{
gfc_error (msg);
return MATCH_ERROR;
}
gfc_extract_int is trying to put 4294967296_8 into a signed int.
This probably needs to be changed to accommodate the type of
an array index.
Ugh. I have a patch that would allow a repeat count of
2**32-1. For this program:
program main
integer(kind=1), dimension(4294967294_8) :: i
data i /4294967294_8 * 1_1/
print *,i(1)
end program main
and 'gfc4x -o z -O p.f90', I see
51879 sgk 1 1210 554M 554M RUN1 5:48 92.24% as
in top(1). Do we really want to support this large of a repeat count?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31244
[Bug fortran/31244] data initialization with more than 2**32 elements
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu 2007-09-18 19:26 --- Subject: Re: data initialization with more than 2**32 elements On Tue, Sep 18, 2007 at 07:16:42PM -, sgk at troutmask dot apl dot washington dot edu wrote: Ugh. I have a patch that would allow a repeat count of 2**32-1. For this program: program main integer(kind=1), dimension(4294967294_8) :: i data i /4294967294_8 * 1_1/ print *,i(1) end program main and 'gfc4x -o z -O p.f90', I see 51879 sgk 1 1210 554M 554M RUN1 5:48 92.24% as in top(1). Do we really want to support this large of a repeat count? Ugh**2. If I'm not mistaken, this will create an executable with 4 GB of static data in it. I think we should but a sane limit on the value. Btw, I'm sitting at 51879 sgk 1 1220 1302M 1304M CPU1 1 14:17 93.41% as 51878 sgk 1 -80 17684K 12924K pipewr 0 7:58 48.78% f951 in top(1). So, it memory grows to rough 4GB, then it will take about an hour to compile this program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31244
[Bug fortran/31244] data initialization with more than 2**32 elements
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2007-09-18 20:07 ---
Subject: Re: data initialization with more than 2**32 elements
On Tue, Sep 18, 2007 at 07:26:22PM -, sgk at troutmask dot apl dot
washington dot edu wrote:
If I'm not mistaken, this will create an executable with
4 GB of static data in it. I think we should but a sane
limit on the value. Btw, I'm sitting at
51879 sgk 1 1220 1302M 1304M CPU1 1 14:17 93.41% as
51878 sgk 1 -80 17684K 12924K pipewr 0 7:58 48.78% f951
in top(1). So, it memory grows to rough 4GB, then it will take
about an hour to compile this program.
:)
Mem: 5365M Active, 1779M Inact, 222M Wired, 341M Cache, 214M Buf, 10M Free
Swap: 17G Total, 17G Free
PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND
51879 sgk 1 1170 4254M 4261M CPU1 1 53:25 96.53% as
51878 sgk 1 1040 17684K 12860K RUN1 26:01 39.45% f951
troutmask:sgk[312] gfc4x -o z -pipe -O p.f90
/tmp: write failed, filesystem is full
/tmp/ccdu52FQ.o: No space left on device
{standard input}: Assembler messages:
{standard input}:87: FATAL: Can't write /tmp/ccdu52FQ.o: No space left on
device
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31244
[Bug fortran/33339] GFORTRAN OPTIMIZATION ERROR ABOVE -O0 FOR MPICH2 TEST F90_RMA/BASEATTRWINF90.F90
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2007-09-10 18:28 --- Subject: Re: GFORTRAN OPTIMIZATION ERROR ABOVE -O0 FOR MPICH2 TEST F90_RMA/BASEATTRWINF90.F90 On Mon, Sep 10, 2007 at 04:03:21PM -, longb at cray dot com wrote: gcc version 4.2.1 20070719 (rpm:3) Note: The version of gcc we are using is not the same as the one you noted, and for the XT systems all linking is static. I checked my version again, and it was 4.2.1 20070523. There aren't many significant changes between this version and yours to at least the Fortran front-end. I just rebuild 4.2.2 (note it's been marked for a release) and get GNU F95 version 4.2.2 20070905 (prerelease) (x86_64-portbld-freebsd7.0) Your program with my addition and static linking gives node10:kargl[254] ../mpich2/bin/mpiexec -machinefile mf1 -n 1 ./long Got right value for WIN_DISP_UNIT ( 4 , should be 4 ) node10:kargl[255] ./long Got right value for WIN_DISP_UNIT ( 4 , should be 4 ) Our version of mpich2 appears to be older. I can ask the MPI group for a newer version. The mpich2 changelog suggests that there may be some changes which effect gfortran+mpich2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
[Bug fortran/33339] GFORTRAN OPTIMIZATION ERROR ABOVE -O0 FOR MPICH2 TEST F90_RMA/BASEATTRWINF90.F90
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu 2007-09-08 19:17 --- Subject: Re: GFORTRAN OPTIMIZATION ERROR ABOVE -O0 FOR MPICH2 TEST F90_RMA/BASEATTRWINF90.F90 ftn -o x -O2 bug2867.f90 aprun -n 1 ./x Got incorrect value for WIN_SIZE ( 140733193389056 , should be 1024 ) Got wrong value for WIN_DISP_UNIT ( 140733193388036 , should be What is ftn? On my system, when I build MPICH2 I get mpf90. ftn is a script that allows the user to see a common interface for all the compilers we document. Which compiler is used is controlled by the module facility. Library sets are selected based on the compiler and OS combinations. The same command is used for both serial and parallel programs. Any chance that you can skip the script and use mpif90 directly? Also, I have MPICH2 1.05p4. Can you this version? Is the version of MPICH2 that you used patched by Cray? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
[Bug fortran/32987] TAB in FORMAT: accept extension, warn with -std=f*
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu 2007-08-30 22:24 --- Subject: Re: TAB in FORMAT: accept extension, warn with -std=f* On Thu, Aug 30, 2007 at 09:52:56PM -, fago at caltech dot edu wrote: --- Comment #12 from fago at caltech dot edu 2007-08-30 21:52 --- A stupid question: why cannot gfortran detect this invalid code at compile time? I was quite surprised by a runtime error. See comment #9 in bugzilla. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32987
[Bug fortran/32987] TAB in FORMAT: accept extension, warn with -std=f*
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu 2007-08-10 03:50 --- Subject: Re: TAB in FORMAT: accept extension, warn with -std=f* On Fri, Aug 10, 2007 at 03:27:33AM -, satyaakam at yahoo dot co dot in wrote: Any plans to backport. No. Please fix your BROKEN code so gfortran doesn't need to grow any further questionable extension. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32987
[Bug fortran/32987] TAB in FORMAT: accept extension, warn with -std=f*
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2007-08-04 17:00 --- Subject: Re: TAB in FORMAT: accept extension, warn with -std=f* On Sat, Aug 04, 2007 at 04:53:33PM -, burnus at gcc dot gnu dot org wrote: I therefore suggest: - Silently accept the tab in libgfortran I disagree on this point. gfortran has been around for a long time now and this is the first report of the tab-in-format runtime error. gfortran should complain loudly that the code is invalid. - Give a warning or an error with -std=f95/f2003. What about -std=f66, f77, or f90? Yes, I know gfortran doesn't have these levels, but the tab violates all fortran standards. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32987
[Bug fortran/32979] Implement vendor-specific ISNAN() intrinsic function
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu 2007-08-03 20:33 --- Subject: Re: Implement vendor-specific ISNAN() intrinsic function On Fri, Aug 03, 2007 at 08:25:08PM -, burnus at gcc dot gnu dot org wrote: If we're going to implement isnan, then we should implement all of the FP classification functions (isfinite, isinf, isnan, isnormal, and maybe fpclassify). I'm not sure if this is needed. For instance, isnan() is implemented by g95 and ifort, but the other intrinsics are not. Note that using Fortran 2003's IEEE_* modules, the functionality will be available albeit under a different name. I then believe that we do not need isnan. A person can use either IEEE_* when it becomes available or bind(c). I don't see why isnan is special in comparison to isinf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32979
[Bug testsuite/32956] Compiling equiv_7_db.f90 gives an error with -fdefault-integer-8
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2007-08-02 20:32 --- Subject: Re: Compiling equiv_7_db.f90 gives an error with -fdefault-integer-8 On Thu, Aug 02, 2007 at 08:26:44PM -, tkoenig at gcc dot gnu dot org wrote: If we use -fdefault-integer-8 on code which includes common or equivalences, we should also include -fdefault-real-8. It doesn't help in this case. The equivalence statement is a double precision variable and a 2 element integer array. It's the old trick of using the array to access the hi and lo word of the double precision. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32956
[Bug fortran/32968] selected_(int|real)_kind fail with -fdefault-integer-8
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2007-08-02 21:06 ---
Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8
On Thu, Aug 02, 2007 at 10:55:45PM +0200, Dominique Dhumieres wrote:
I applied your patch, but on PPC Darwin I get 10 times 1 for int, instead of:
1 1 2 2 4 4 4 4 4 8
What is the -fdump-tree-original for
i = 4
print *, selected_int_kind(i)
print *, selected_real_kind(i)
end
without -fdefault-integer-8 I get
{
int4 D.996;
D.996 = _gfortran_selected_int_kind (i);
_gfortran_transfer_integer (dt_parm.1, D.996, 4);
}
{
int4 D.998;
D.998 = _gfortran_selected_real_kind (i, 0B);
_gfortran_transfer_integer (dt_parm.2, D.998, 4);
}
with it I get
{
int8 D.996;
D.996 = (int8) _gfortran_selected_int_kind (i);
_gfortran_transfer_integer (dt_parm.1, D.996, 8);
}
{
int8 D.998;
D.998 = (int8) _gfortran_selected_real_kind (i, 0B);
_gfortran_transfer_integer (dt_parm.2, D.998, 8);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
[Bug fortran/32968] selected_(int|real)_kind fail with -fdefault-integer-8
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2007-08-02 21:42 ---
Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8
On Thu, Aug 02, 2007 at 11:17:02PM +0200, Dominique Dhumieres wrote:
look to yours, but with -fdefault-integer-8, I get '1 4' instead of
'2 4'.
We probably wanted to use 'i = 10', which should gives '8 8'.
In looking at the dump again (removing the stuff from PRINT), we have
int8 i;
i = 10;
{
{
int8 D.996;
D.996 = (int8) _gfortran_selected_int_kind (i);
_gfortran_transfer_integer (dt_parm.1, D.996, 8);
}
I bet I need to force 'i' to int4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
[Bug fortran/32968] selected_(int|real)_kind fail with -fdefault-integer-8
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu 2007-08-02 22:29 --- Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8 On Thu, Aug 02, 2007 at 11:17:02PM +0200, Dominique Dhumieres wrote: look to yours, but with -fdefault-integer-8, I get '1 4' instead of '2 4'. Dominique, Can you try the attached patch? --- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2007-08-02 22:29 --- Created an attachment (id=14012) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14012action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
[Bug fortran/32968] selected_(int|real)_kind fail with -fdefault-integer-8
--- Comment #9 from sgk at troutmask dot apl dot washington dot edu 2007-08-02 23:49 --- Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8 On Thu, Aug 02, 2007 at 11:02:55PM -, dominiq at lps dot ens dot fr wrote: --- Comment #8 from dominiq at lps dot ens dot fr 2007-08-02 23:02 --- Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8 Can you try the attached patch? It fixes the problem for -fdefault-integer-8, but without it, it gives on your test (and others) the infamous: intrinsic_sir_kind_red.f90:4.3: end 1 Internal Error at (1): intrinsic_sir_kind_red.f90:3.28: print *, selected_real_kind(i) 1 Can't convert INTEGER(4) to INTEGER(4) at (1) I think you need the same kind of machinery as for PR32954, i.e., change to 4 only if it is different from 4. That's next. :-) BTW, did you consider the second optional argument for selected_real_kind(i)? Yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
[Bug fortran/32968] selected_(int|real)_kind fail with -fdefault-integer-8
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu 2007-08-03 00:04 --- Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8 On Thu, Aug 02, 2007 at 11:02:55PM -, dominiq at lps dot ens dot fr wrote: I think you need the same kind of machinery as for PR32954, i.e., change to 4 only if it is different from 4. BTW, did you consider the second optional argument for selected_real_kind(i)? I think that we may be converging on a patch. Can you test the attached diff? --- Comment #11 from sgk at troutmask dot apl dot washington dot edu 2007-08-03 00:04 --- Created an attachment (id=14013) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14013action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32968
[Bug fortran/32942] Wrong code with with -fdefault-integer-8
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu
2007-07-31 18:40 ---
Subject: Re: Wrong code with with -fdefault-integer-8
On Tue, Jul 31, 2007 at 06:04:02PM -, kargl at gcc dot gnu dot org wrote:
I have reduced the failure for intrinsic_rrspacing.f90 to:
integer i
real x
x = 3.0
print *, exponent (x)
i = exponent (x)
print *, i
end
which gives with -fdefault-integer-8
8589934720
2
trans-types.c(gfc_get_int_type) is used to build the
gfc_int4_type_node in trans-io.h. -fdefault-integer-8
is probably causing gfc_int4_type_node to be set to 8
instead of 4.
Ugh! It's worse than the above. In iresolve.c, we have
void
gfc_resolve_exponent (gfc_expr *f, gfc_expr *x)
{
f-ts.type = BT_INTEGER;
f-ts.kind = gfc_default_integer_kind;
f-value.function.name = gfc_get_string (__exponent_%d, x-ts.kind);
}
If I change gfc_default_integer_kind to 4, gfortran produces the right
result. So, we need to review every unilateral use of gfc_default_integer_kind
in the frontend to determine if the promotion of 4 to 8 via -fdefault-integer-8
is correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32942
[Bug fortran/32942] Wrong code with with -fdefault-integer-8
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu
2007-07-31 19:37 ---
Subject: Re: Wrong code with with -fdefault-integer-8
On Tue, Jul 31, 2007 at 06:56:33PM -, dominiq at lps dot ens dot fr wrote:
So, we need to review every unilateral use of gfc_default_integer_kind
in the frontend to determine if the promotion of 4 to 8 via
-fdefault-integer-8
is correct.
Would not it be simpler to promote (cast?) to gfc_default_integer_kind
the results of the intrinsic functions such as exponent?
That appears to work.
Index: trans-intrinsic.c
===
--- trans-intrinsic.c (revision 127065)
+++ trans-intrinsic.c (working copy)
@@ -720,7 +720,7 @@ gfc_conv_intrinsic_lib_function (gfc_se
static void
gfc_conv_intrinsic_exponent (gfc_se * se, gfc_expr * expr)
{
- tree arg, fndecl;
+ tree arg, fndecl, tmp;
gfc_expr *a1;
gfc_conv_intrinsic_function_args (se, expr, arg, 1);
@@ -744,7 +744,8 @@ gfc_conv_intrinsic_exponent (gfc_se * se
gcc_unreachable ();
}
- se-expr = build_call_expr (fndecl, 1, arg);
+ tmp = gfc_get_int_type (gfc_default_integer_kind);
+ se-expr = fold_convert (tmp, build_call_expr (fndecl, 1, arg));
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32942
[Bug fortran/32942] Wrong code with with -fdefault-integer-8
--- Comment #9 from sgk at troutmask dot apl dot washington dot edu 2007-07-31 20:50 --- Subject: Re: Wrong code with with -fdefault-integer-8 On Tue, Jul 31, 2007 at 08:32:56PM -, dominiq at lps dot ens dot fr wrote: --- Comment #7 from dominiq at lps dot ens dot fr 2007-07-31 20:32 --- Subject: Re: Wrong code with with -fdefault-integer-8 This part of the problem for intrinsic_rrspacing.f90 now works, but there is another one with rrspacing(x): I've committed the fix for exponent(), so I'm closing this PR. The rrspacing problem is something besides -fdefault-integer-8 because I get the expected results on my system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32942
[Bug fortran/32942] Wrong code with with -fdefault-integer-8
--- Comment #12 from sgk at troutmask dot apl dot washington dot edu 2007-07-31 21:48 --- Subject: Re: Wrong code with with -fdefault-integer-8 On Tue, Jul 31, 2007 at 09:39:28PM -, dominiq at lps dot ens dot fr wrote: The rrspacing problem is something besides -fdefault-integer-8 because I get the expected results on my system. Is your system big or little endian? If it is the latter, then we are back to PR32770 It is an opteron, so little endian. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32942
[Bug fortran/32942] Wrong code with with -fdefault-integer-8
--- Comment #14 from sgk at troutmask dot apl dot washington dot edu 2007-07-31 22:29 --- Subject: Re: Wrong code with with -fdefault-integer-8 On Tue, Jul 31, 2007 at 10:04:55PM -, dominiq at lps dot ens dot fr wrote: It is an opteron, so little endian. So rrspacing is another instance of PR32770 yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32942
[Bug fortran/32613] [4.3 regression] Different results depending on unnecessary variable declaration
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu 2007-07-04 20:08 --- Subject: Re: [4.3 regression] Different results depending on unnecessary variable declaration On Wed, Jul 04, 2007 at 08:06:08PM -, pault at gcc dot gnu dot org wrote: --- Comment #7 from pault at gcc dot gnu dot org 2007-07-04 20:06 --- (In reply to comment #6) I read this as: Works in 4.2.x, fails in 4.3, which is also what I get; I therefore changed the summary from 4.2 regression to 4.3 regression. Thanks, Tobias. I was about to check whether this was so. I suspect that Al meant wrt 4.2. I am just about to submit the fix. I marked it as the 4.2 regression, and yes, I meant a regression in trunk with respect to 4.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #21 from sgk at troutmask dot apl dot washington dot edu
2007-03-20 01:47 ---
Subject: Re: Bad IOSTAT values when readings NAMELISTs past EOF
On Mon, Mar 19, 2007 at 10:59:25PM -, anlauf at gmx dot de wrote:
--- Comment #20 from anlauf at gmx dot de 2007-03-19 22:59 ---
(In reply to comment #19)
Jerry,
I tried FX's snapshot from today (20070319) and the example
above works. A somewhat more twisted example which I have
not yet been able to reduce leads to an IOSTAT value of 5001
(BTW: what does that value mean?) in the namelist read, although
the subroutine position_nml succeeds.
The file libgfortran is not in that distribution. Could you
please put here these IOSTAT values? Nor are these in the
.info files. Thanks!
typedef enum
{
ERROR_FIRST = -3, /* Marker for the first error. */
ERROR_EOR = -2,
ERROR_END = -1,
ERROR_OK = 0, /* Indicates success, must be zero. */
ERROR_OS = 5000, /* Operating system error, more info in errno. */
ERROR_OPTION_CONFLICT,
ERROR_BAD_OPTION,
ERROR_MISSING_OPTION,
ERROR_ALREADY_OPEN,
ERROR_BAD_UNIT,
ERROR_FORMAT,
ERROR_BAD_ACTION,
ERROR_ENDFILE,
ERROR_BAD_US,
ERROR_READ_VALUE,
ERROR_READ_OVERFLOW,
ERROR_INTERNAL,
ERROR_INTERNAL_UNIT,
ERROR_ALLOCATION,
ERROR_DIRECT_EOR,
ERROR_SHORT_RECORD,
ERROR_CORRUPT_FILE,
ERROR_LAST/* Not a real error, the last error # + 1. */
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2007-03-16 04:07 --- Subject: Re: Warn with -std=f95/f2003 when BOZ is used at invalid places On Fri, Mar 16, 2007 at 03:46:30AM -, jkrahn at nc dot rr dot com wrote: --- Comment #5 from jkrahn at nc dot rr dot com 2007-03-16 03:46 --- BOZ processing was recently broken in gfortran. No, it was fixed. I assume it relates to the issues here. The current problem is shown in this bit of code: write(*,*)'NaN(8)=',real(z'FFF8',8) end gfortran, even with -std=f2003, claims that the BOZ data is too big. Do you have an INTEGER(16)? Apparently, it is first converting to an UNSIGNED integer, then trying to cast to a SIGNED Fortran integer. Not even close to the truth. With F2003, this form of BOZ should do a 'reinterpret-cast' of raw binary bits directly to the destination type. gfortran implements the F95 behavior and extensions. The extension conflict with F2003. Even without the reinterpret cast problem, integer BOZ is not handled correctly. This expression also claims the BOZ is too large: int(z'',8) Do you have INTEGER(16)? Again, it is being intepreted as an UNSIGNED int then static-cast to a signed in, thus overflowing. Not even close to the truth. The traditional behavior is for all BOZ to be initially interpreted as the largets integer type supported. Do you have an INTEGER(16)? F95 dropped BOZ because of the lame definition Huh? but F2003 brought it back for use mainly within REAL() and INT(), which allow the raw initial interpretation in a sensible way. No, it isn't sensible. It is *processor dependent*. Think big versus little endian to start. Next consider that F2003 does not define the underlying floating representation. This was a very broken attempt to fix TRANSFER. A related problem is that I am trying to create a NaN constant (parameter). I can't use REAL+BOZ, but I also cannot define real :: NaN = 0.0/0.0. In this case, divide-by-zero is invalid math, but should only be a warning and not an error. (I am speaking practically; I don't know what the standards say.) program rtfm x = 0. / 0. end program rtfm gfc -fno-range-check -o z rtfm.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug fortran/29471] Warn with -std=f95/f2003 when BOZ is used at invalid places
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu 2007-03-16 04:09 --- Subject: Re: Warn with -std=f95/f2003 when BOZ is used at invalid places On Fri, Mar 16, 2007 at 03:53:57AM -, jkrahn at nc dot rr dot com wrote: I have not checked F2008 yet. My vote is to just ignore the standards when it comes to negative BOZ, the way Intel has done it, which I HOPE is what F2008 says. gfortran doesn't have that luxury. it can't ignore the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29471
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu 2007-03-06 15:53 --- Subject: Re: Bad IOSTAT values when readings NAMELISTs past EOF On Tue, Mar 06, 2007 at 08:20:23AM -, anlauf at gmx dot de wrote: --- Comment #3 from anlauf at gmx dot de 2007-03-06 08:20 --- (In reply to comment #2) The value 5008 is listed in libgfortran.h as ERROR_ENDFILE. The -1 corresponds to ERROR_END. So, the return value of 5008 is telling you that you are trying to (initiate a?) read beyond the end of the file, which you admit to doing. I actually do not want to read beyond the end of file, I want gfortran to stay at the end of the file when trying to read the next record or namelist. All other compilers I have checked (xlf, ifort 7.x-9.x, g95) stay at the end of file. I find their behavior consistent with the F2003 standard, section 9.10.4: Execution of an input/output statement containing the IOSTAT= specifier causes the scalar-int-variable in the IOSTAT= specifier to become defined with (3) The processor-dependent negative integer value of the constant IOSTAT_END (13.8.2.5) if an end-of-file condition occurs and no error condition occurs, or (...) AFAIK, the IOSTAT values aren't documented in gfortran.texi. Someday, someone will get around to documenting them. The standard separates end-of-file, end-of-record, and error conditions. I don't think that EOF is necessarily an error condition. It would be nice if gfortran would conform with these other compilers. For whatever reason, you are hitting (2). (2) A processor-dependent positive integer value if an error condition occurs. At a guess, you get a -1 if you start a read from within the the file, and you hit the EOF. Once the EOF is hit, the file is probably positioned at a point beyond the EOF, the next attempt of a read is considered an error condition, so the 5008 is return. I saw your other email about BACKSPACE. I don't know what the expected behavior is with BACKSPACE and a file position that is at or exceeds the EOF marker. At a guess and knowing the vagueness of the Standard, this is probably processor-dependent. I think you're getting hit by 9.10.2(4) for F2003: (4) If the file specified in the input statement is an external record file, it is positioned after the endfile record. and BACKSPACE isn't doing its job with respect to Note 9.54. This is an area that Jerry knows. Perhaps, he has an opinion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
