[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #26 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-10 14:38:03 UTC --- Is this caused by http://gcc.gnu.org/viewcvs?view=revisionrevision=180701 ? Maybe we need to remember if we have a special file after all, or just ignore the error on the truncate.
[Bug fortran/53824] ICE with ALLOCATE of coarrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53824 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-11 15:08:55 UTC --- Applying the patch from http://gcc.gnu.org/viewcvs?root=gccview=revrev=189549 runs into another problem: ig25@linux-fd1f:~/Krempel/Co gdb ~/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/f951 GNU gdb (GDB) 7.5 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/f951...done. (gdb) r coarray_allocate_1.f90 Starting program: /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/f951 coarray_allocate_1.f90 coarray_allocate_1.f90:20.31: type(Domain),allocatable :: D[:,:,:] 1 Schwerwiegender Fehler: Coarray bei (1) ausgeschaltet, -fcoarray= zum Einschalten verwenden [Inferior 1 (process 1073) exited with code 01] (gdb) r ^CQuity_allocate_1.f90 (gdb) q ig25@linux-fd1f:~/Krempel/Co gdb ~/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/f951 GNU gdb (GDB) 7.5 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/f951...done. (gdb) r -fcoarray=single coarray_allocate_1.f90 Starting program: /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.7.3/f951 -fcoarray=single coarray_allocate_1.f90 jac Program received signal SIGSEGV, Segmentation fault. 0x0058ddd5 in gfc_build_array_ref (base=0x75df8968, offset=0x0, decl=0x0) at ../../4-7/gcc/fortran/trans.c:341 341 STRIP_TYPE_NOPS (offset); (gdb) bt #0 0x0058ddd5 in gfc_build_array_ref (base=0x75df8968, offset=0x0, decl=0x0) at ../../4-7/gcc/fortran/trans.c:341 #1 0x00590936 in gfc_conv_descriptor_ubound (desc=optimized out, dim=optimized out) at ../../4-7/gcc/fortran/trans-array.c:364 #2 0x00591b07 in gfc_conv_descriptor_ubound_get (dim=0x0, desc=0x75d03c80) at ../../4-7/gcc/fortran/trans-array.c:377 #3 get_full_array_size (block=0x7fffd2c0, decl=0x75d03c80, rank=optimized out) at ../../4-7/gcc/fortran/trans-array.c:7141 #4 0x00598e40 in structure_alloc_comps (der_type=0x1496a90, decl=0x75d03c80, dest=dest@entry=0x0, rank=0, purpose=purpose@entry=2) at ../../4-7/gcc/fortran/trans-array.c:7313 #5 0x0059972f in gfc_nullify_alloc_comp (der_type=optimized out, decl=optimized out, rank=optimized out) at ../../4-7/gcc/fortran/trans-array.c:7618 #6 0x0059a0cb in gfc_array_allocate (se=optimized out, expr=0x14c44b0, status=0x0, errmsg=0x0, errlen=0x0, label_finish=0x0, expr3_elem_size=0x75e0e840, nelems=0x7fffd798, expr3=0x0) at ../../4-7/gcc/fortran/trans-array.c:5147 #7 0x005d77f2 in gfc_trans_allocate (code=optimized out) at ../../4-7/gcc/fortran/trans-stmt.c:4849 #8 0x0058ee58 in trans_code (code=0x14a19e0, cond=0x0) at ../../4-7/gcc/fortran/trans.c:1462 #9 0x005ab3f8 in gfc_generate_function_code (ns=optimized out) at ../../4-7/gcc/fortran/trans-decl.c:5344 #10 0x00550dd7 in translate_all_program_units (main_in_tu=true, gfc_global_ns_list=0x1493120) at ../../4-7/gcc/fortran/parse.c:4455 #11 gfc_parse_file () at ../../4-7/gcc/fortran/parse.c:4668 #12 0x0058b256 in gfc_be_parse_file () at ../../4-7/gcc/fortran/f95-lang.c:250 #13 0x00838f30 in compile_file () at ../../4-7/gcc/toplev.c:557 #14 do_compile () at ../../4-7/gcc/toplev.c:1938 #15 toplev_main (argc=3, argv=0x7fffdca8) at ../../4-7/gcc/toplev.c:2014 #16 0x7643723d in __libc_start_main () from /lib64/libc.so.6 #17 0x004e6f41 in _start () at ../sysdeps/x86_64/elf/start.S:113 so it seems more than this patch is needed to fix this. Therefore, no backport to 4.7 (since it is fixed on trunk). Closing.
[Bug fortran/55314] New: [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55314 Bug #: 55314 Summary: [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE statements Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org Test case by Jacob Weisman Poulsen: jwp@wrapcrap:~$ cat test.f90 program main implicit none integer :: max_nb type comm_mask integer(4), pointer :: mask(:) end type comm_mask type (comm_mask), allocatable, save :: encode(:,:) max_nb=2 allocate( encode(1:1,1:max_nb)) allocate( encode(1,1)%mask(1),encode(1,2)%mask(1)) end program main jwp@wrapcrap:~$ gfortran test.f90 test.f90:10.12-32: allocate( encode(1,1)%mask(1),encode(1,2)%mask(1)) 1 2 Error: Allocate-object at (1) also appears at (2)
[Bug fortran/55314] [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55314 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-11-13 AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.4 Ever Confirmed|0 |1
[Bug fortran/55314] [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55314
--- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-13
22:59:22 UTC ---
Here's a tentative patch:
Index: resolve.c
===
--- resolve.c (Revision 192894)
+++ resolve.c (Arbeitskopie)
@@ -7618,12 +7618,18 @@ resolve_allocate_deallocate (gfc_code *code, const
if (pr-next qr-next)
{
+ int i;
gfc_array_ref *par = (pr-u.ar);
gfc_array_ref *qar = (qr-u.ar);
- if ((par-start[0] != NULL || qar-start[0] != NULL)
- gfc_dep_compare_expr (par-start[0],
- qar-start[0]) != 0)
- break;
+
+ for (i=0; ipar-dimen; i++)
+ {
+ if ((par-start[i] != NULL
+ || qar-start[i] != NULL)
+ gfc_dep_compare_expr (par-start[i],
+ qar-start[i]) != 0)
+ goto break_label;
+ }
}
}
else
@@ -7635,6 +7641,8 @@ resolve_allocate_deallocate (gfc_code *code, const
pr = pr-next;
qr = qr-next;
}
+ break_label:
+ ;
}
}
}
[Bug fortran/54932] Invalid loop code generated by Fortran FE for loops with bounds in HIGH(type)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54932 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #11 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-18 16:24:27 UTC --- (In reply to comment #9) Thus, I close the bug as INVALID. ... in wich case could you, please, update the testcase to be valid and remove the XFAIL I introduced? We jump through some hoops in or DO loop code generation to execute a loop until HUGE(i) in a way that somebody who did not read the standard well might expect, but which is actually invalid. If we do not do this any more, then we can probably simplify our DO loops considerably. We should also warn about invalid code in the FE.
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #28 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-24 12:05:57 UTC --- (In reply to comment #27) (In reply to comment #26) Is this caused by http://gcc.gnu.org/viewcvs?view=revisionrevision=180701 ? Maybe we need to remember if we have a special file after all, or just ignore the error on the truncate. IMHO the correct fix is to not seek and/or truncate the file unless the Fortran semantics require it; that way libgfortran does not need to care whether the file is special or not. As explained in #c23, special files are special in different ways (also different on different OS'es), and trying to enumerate all the ways in which they are special is bound to fail. I think Tobias comment #c24 pinpoints the place which needs to be fixed, but unfortunately I haven't had time to look into it. Well, we need to make sure that the (very basic) program program main character*10 x open(10,file=foo.dat) write (10,'(A)') '' write (10,'(A)') '' close (10) open(10,file=foo.dat) write (10,'(A)') '' close (10) open(10,file=foo.dat) 100 continue read (10,'(A)',end=200) x write (*,'(A)') x goto 100 200 continue close(10,status=delete) end continues to work as expected: That probably means truncating on close and rewind. I can see what I can do, but I have little time... (as always)
[Bug fortran/55314] [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55314 --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-24 15:00:23 UTC --- Author: tkoenig Date: Sat Nov 24 15:00:16 2012 New Revision: 193778 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193778 Log: 2012-11-24 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55314 * resolve.c (resolve_allocate_deallocate): Compare all subscripts when deciding if to reject a (de)allocate statement. 2012-11-24 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55314 * gfortran.dg/allocate_error_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocate_error_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55314] [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55314 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-24 17:13:31 UTC --- Author: tkoenig Date: Sat Nov 24 17:13:25 2012 New Revision: 193780 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193780 Log: 2012-11-24 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55314 Backport from trunk * resolve.c (resolve_allocate_deallocate): Compare all subscripts when deciding if to reject a (de)allocate statement. 2012-11-24 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55314 Backport from trunk * gfortran.dg/allocate_error_4.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/allocate_error_4.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/resolve.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/55314] [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55314 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-24 22:17:40 UTC --- Author: tkoenig Date: Sat Nov 24 22:17:35 2012 New Revision: 193784 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193784 Log: 2012-11-24 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55314 Backport from trunk * resolve.c (resolve_allocate_deallocate): Compare all subscripts when deciding if to reject a (de)allocate statement. 2012-11-24 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55314 Backport from trunk * gfortran.dg/allocate_error_4.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/allocate_error_4.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/resolve.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/55314] [4.6/4.7/4.8 Regression] Rejects some valid ALLOCATE statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55314 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-24 22:20:23 UTC --- Fixed on all affected branches, closing.
[Bug fortran/30146] Redefining do-variable in excecution cycle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30146 --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-25 17:24:14 UTC --- Author: tkoenig Date: Sun Nov 25 17:24:09 2012 New Revision: 193793 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193793 Log: 2012-11-25 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/30146 * frontend-passes.c (doloop_warn): New function. (doloop_list): New static variable. (doloop_size): New static variable. (doloop_level): New static variable. (gfc_run_passes): Call doloop_warn. (doloop_code): New function. (doloop_function): New function. (gfc_code_walker): Keep track of DO level. 2012-11-25 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/30146 * gfortran.dg/do_check_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/do_check_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/30146] Redefining do-variable in excecution cycle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30146 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution||FIXED --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-11-25 18:29:00 UTC --- I think this can be counted as fixed with the addition of -fcheck=do and the recent fixes for INTENT(OUT) and INTENT(INOUT) dummy arguments. Please reopen if you think othrwise.
[Bug fortran/30609] Calculating masks twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30609 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-12-01 10:31:41 UTC --- Probably something for front-end optimization, or improved scalarization, or both.
[Bug fortran/51589] Modification of loop index variable by intent(out) or intent(inout) procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51589 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-12-01 10:37:43 UTC --- Fixed with http://gcc.gnu.org/viewcvs?root=gccview=revrev=193793 which sailed under the flag of PR 30146.
[Bug fortran/55593] [4.8 Regression] Bogus error on passing DO LOOP variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55593 --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-12-06 22:02:01 UTC --- (In reply to comment #1) From frontend-passes.c's doloop_code case EXEC_CALL: f = co-symtree-n.sym-formal; I think one should use in this case co-value.function.esym I believe co-value.function.* should always exist, Not for a subroutine call ;-) The following patch seems to work: Index: frontend-passes.c === --- frontend-passes.c (Revision 193793) +++ frontend-passes.c (Arbeitskopie) @@ -1277,8 +1277,12 @@ doloop_code (gfc_code **c, int *walk_subtrees ATTR break; case EXEC_CALL: - f = co-symtree-n.sym-formal; + if (co-resolved_sym == NULL) + break; + + f = co-resolved_sym-formal; + /* Withot a formal arglist, there is only unknown INTENT, which we don't check for. */ if (f == NULL) given that it comes after resolution (if not, the symtree can be used as fall back). In any case, one needs to be careful if it isn't an isym instead. This is checked for in the code already. I could not come up with a test case which fails for a function, so I don't think this regression also applies to generic function calls.
[Bug fortran/55593] [4.8 Regression] Bogus error on passing DO LOOP variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55593 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-12-09 09:15:42 UTC --- Author: tkoenig Date: Sun Dec 9 09:15:36 2012 New Revision: 194329 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194329 Log: 2012-12-09 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55593 * frontend-passes.c (doloop_code): Use resolved_sym instead of n.sym-formal for formal argument list to get the correct version for all generic subroutines. 2012-12-09 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55593 * gfortran.dg/do_check_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/do_check_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55593] [4.8 Regression] Bogus error on passing DO LOOP variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55593 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-12-09 09:17:07 UTC --- Fixed on trunk, closing. Thanks a lot for the bug report!
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
--- Comment #30 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-12-14
23:07:34 UTC ---
This seems to do the trick.
Index: unix.c
===
--- unix.c (Revision 194507)
+++ unix.c (Arbeitskopie)
@@ -344,7 +344,15 @@
static gfc_offset
raw_tell (unix_stream * s)
{
- return lseek (s-fd, 0, SEEK_CUR);
+ gfc_offset x;
+ x = lseek (s-fd, 0, SEEK_CUR);
+
+ /* Non-seekable files should always be assumed to be at
+ current position. */
+ if (x == -1 errno == ESPIPE)
+x = 0;
+
+ return x;
}
static gfc_offset
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|ASSIGNED AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org |
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #31 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-12-21 20:50:52 UTC --- Author: tkoenig Date: Fri Dec 21 20:50:48 2012 New Revision: 194679 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194679 Log: 2012-12-21 Thomas Koenig tkoe...@gcc.gnu.org PR libfortran/30162 * io/unix.c (raw_tell): If the lseek is done on a non-seekable file, return 0. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 --- Comment #32 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-12-22 10:46:42 UTC --- Author: tkoenig Date: Sat Dec 22 10:46:37 2012 New Revision: 194694 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194694 Log: 2012-12-22 Thomas Koenig tkoe...@gcc.gnu.org PR libfortran/30162 Backport from trunk * io/unix.c (raw_tell): If the lseek is done on a non-seekable file, return 0. Modified: branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/io/unix.c
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #33 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-12-22 10:49:08 UTC --- Fixed on trunk and 4.7, closing.
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-apple-darwin10 Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #39 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-12-22 22:14:48 UTC --- Unfortunately, I cannot really debug this without access to a machine where it fails. Does this also fail on another BSD-based machine? Is such a machine available on the gcc compile farm?
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|NEW AssignedTo|tkoenig at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #42 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-12-25 15:26:24 UTC --- I'll try to find a system I have access to where this also fails; unassigning myself until then.
[Bug fortran/55806] New: Missed optimization with ANY or ALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806
Bug #: 55806
Summary: Missed optimization with ANY or ALL
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tkoe...@gcc.gnu.org
Mike Metcalf complains (correctly) in
44daf54c-3de5-4b1c-a1f7-cb7bf0d49...@googlegroups.com
that using ANY as an idiom instead of .or. for a small number of conditions.
Look at this:
module mymod
contains
subroutine bar(a,b,c)
integer, dimension(3,3), intent(in) :: a,b
integer, intent(out) :: c
real, parameter :: acc = 1e-4
integer :: i
c = 0
do i=1,3
if (any([abs(a(i,1) - b(i,1)) acc,
abs(a(i,2) - b(i,2)) acc,
abs(a(i,3) - b(i,3)) acc])) cycle
c = c + 1
end do
end subroutine bar
end module mymod
This generates a logical array, assigns the values to them,
and then loops over the array to generate the values:
atmp.1.dtype = 273;
atmp.1.dim[0].stride = 1;
atmp.1.dim[0].lbound = 0;
atmp.1.dim[0].ubound = 2;
atmp.1.data = (void * restrict) A.2;
atmp.1.offset = 0;
(*(logical(kind=4)[3] * restrict) atmp.1.data)[0] =
(real(kind=4)) ABS_EXPR (*a)[(integer(kind=8)) i + -1] -
(*b)[(integer(kind=8)) i + -1] 9.9974737875163555145263671875e-5;
(*(logical(kind=4)[3] * restrict) atmp.1.data)[1] =
(real(kind=4)) ABS_EXPR (*a)[(integer(kind=8)) i + 2] - (*b)[(integer(kind=8))
i + 2] 9.9974737875163555145263671875e-5;
(*(logical(kind=4)[3] * restrict) atmp.1.data)[2] =
(real(kind=4)) ABS_EXPR (*a)[(integer(kind=8)) i + 5] - (*b)[(integer(kind=8))
i + 5] 9.9974737875163555145263671875e-5;
{
integer(kind=8) S.4;
S.4 = 0;
while (1)
{
if (S.4 2) goto L.5;
if (NON_LVALUE_EXPR (*(logical(kind=4)[3] * restrict)
atmp.1.data)[S.4])
{
test.0 = 1;
goto L.4;
}
S.4 = S.4 + 1;
}
L.5:;
}
L.4:;
if (test.0) goto L.1;
}
L.3:;
*c = *c + 1;
L.1:;
D.1907 = i == 3;
i = i + 1;
if (D.1907) goto L.2;
}
The middle-end then fails to remove this array.
Compare this to the result of
module mymod
contains
subroutine bar(a,b,c)
real, dimension(3,3), intent(in) :: a,b
integer, intent(out) :: c
real, parameter :: acc = 1e-4
integer :: i
c = 0.
do i=1,3
if (abs(a(i,1) - b(i,1)) acc .or.
abs(a(i,2) - b(i,2)) acc .or.
abs(a(i,3) - b(i,3)) acc) cycle
c = c + 1
end do
end subroutine bar
end module mymod
What the Fortran FE generates here isn't very idiomatic when you
write in a language like C. Should we tackle this in the middle
end, or would issuing the version with .or instead of the ANY
to the middle end be preferred?
[Bug middle-end/55814] New: Missed optimization with short-circuit evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55814
Bug #: 55814
Summary: Missed optimization with short-circuit evaluation
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tkoe...@gcc.gnu.org
See PR 55806.
The Fortran front end generates code for intrinsics like ANY and ALL
which looks like (after loop unrolling)
_Bool foo(int *a, int *b)
{
_Bool f0, f1, f2, f3;
f0 = a[0] b[0];
f1 = a[1] b[1];
f2 = a[2] b[2];
f3 = a[2] b[2];
return f0 || f1 || f2 || f3;
}
There should be no need to perform the second comparison if the
first one is true.
[Bug middle-end/55814] Missed optimization with short-circuit evaluation of always evaluated comparisons/loads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55814
--- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-12-27
17:23:54 UTC ---
An even more pronounced test case, where we could sink
a lot more stores, which in fact could lead to moving
a whole loop:
logical function bar(a,b,c)
logical, intent(in) :: a, b
logical, intent(in), dimension(3) :: c
bar = a .and. b .and. any(c)
end
This is translated by the Fortran FE to
bar (logical(kind=4) restrict a, logical(kind=4) restrict b,
logical(kind=4)[3] * restrict c)
{
logical(kind=4) __result_bar;
{
logical(kind=4) test.0;
test.0 = 0;
{
integer(kind=8) S.1;
S.1 = 1;
while (1)
{
if (S.1 3) goto L.2;
if (NON_LVALUE_EXPR (*c)[S.1 + -1])
{
test.0 = 1;
goto L.1;
}
S.1 = S.1 + 1;
}
L.2:;
}
L.1:;
__result_bar = (*a *b) test.0;
}
return __result_bar;
}
which the middle-end then doesn't optimize - there would
be no need to evaluate the loop if either a or b were false.
[Bug fortran/55789] [4.6/4.7/4.8 Regression] Needless realloc with array constructor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Target Milestone|--- |4.6.4 Summary|Needless realloc|[4.6/4.7/4.8 Regression] ||Needless realloc with array ||constructor. --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-01 14:25:27 UTC --- Looks like a regression, then.
[Bug fortran/55839] New: Inefficiency with array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55839 Bug #: 55839 Summary: Inefficiency with array constructor Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org This idiom subroutine foo(a,b,c,n) integer, intent(in) :: n real, intent(in), dimension(n) :: a,b real, intent(out), dimension(2*n) :: c c(1:2*n) = [a(1:n), b(1:n)] end subroutine foo builds an array using malloc and copies the data two times. It would be better to express this as c(1:n) = a(1:n) c(n+1:2*n) = b(1:n) Looks like a job for front-end optimization; it would be a bit hard to expect the middle-end to optimize away all the calls to malloc etc.
[Bug objc/55840] New: valgrind errors in sparseset.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55840 Bug #: 55840 Summary: valgrind errors in sparseset.h Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org Created attachment 29068 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29068 valgrind errors from test case in initial comment Compiling the following test case with COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Ziel: x86_64-unknown-linux-gnu Konfiguriert mit: ../trunk/configure --prefix=/home/ig25 --enable-languages=c,fortran --with-mpfr=/usr/local --with-gmp=/usr/local --with-mpc=/usr/local Thread-Modell: posix gcc-Version 4.8.0 20121231 (experimental) (GCC) module m_task implicit none private public tad_elemen, gele, vecino ! integer, parameter :: ngl = 3, nca = 4 ! integer, dimension (nca) :: koe, koi, koj integer, dimension (2*nca) :: coe, coi, coj ! type tad_elemen integer, dimension (nca) :: iele end type tad_elemen type (tad_elemen), dimension (:), pointer :: gele ! contains ! subroutine vecino (gele) type (tad_elemen), dimension (:), intent (inout) :: gele call troubletask (gele) end subroutine vecino ! subroutine troubletask (gele) type (tad_elemen), dimension (:), intent (in):: gele integer :: nel, nci, ncj integer :: l1, l2, h1, h2 integer :: lado, i, j ! nel = size (gele,dim=1) do i = 1, (nel - 1) koi = gele (i) % iele (1:nca) nci = count (koi0) coi (1:2*nci) = [ koi(1:nci) , koi(1:nci) ] do j = (i+1), nel koj = gele (j) % iele (1:nca) ncj = count (koj 0) coj (1:2*ncj) = [ koj(1:ncj), koj(1:ncj) ] lado = 0 ! !problematic loops do h1 = 1, nci if (coi (h1) 1) cycle ! ICE if both are uncommented l1 = h1 + 1 do h2 = 1, ncj if (coj (h2) 1) cycle ! ICE if both are uncommented l2 = h2 + 1 if (coi (h1) == coj (l2) .and. coi (l1) == coj (h2)) then lado = 1 exit end if end do ! h1 if (lado == 1) exit end do ! h2 ! end do ! j end do ! i ! end subroutine troubletask ! end module m_task ! program test use m_task implicit none print *, trace 1 allocate (gele(10)) call vecino (gele) print *, trace 2 end program gets a lot of valgrind errors in sparseset.h, which are attached. A few samples: static-varAssembling functions: vecino==6337== Conditional jump or move depends on uninitialised value(s) ==6337==at 0xD70C6B: register_active_defs(df_ref_d**) (sparseset.h:147) ==6337==by 0xD70D02: _ZL14update_df_initP7rtx_defS0_.isra.15 (fwprop.c:895) ==6337==by 0xD71F1E: try_fwprop_subst(df_ref_d*, rtx_def**, rtx_def*, rtx_def*, bool) (fwprop.c:963) ==6337==by 0xD72388: forward_propagate_into(df_ref_d*) (fwprop.c:1337) ==6337==by 0xD728C7: fwprop() (fwprop.c:1474) ==6337==by 0x8C6D17: execute_one_pass(opt_pass*) (passes.c:2335) ==6337==by 0x8C7124: execute_pass_list(opt_pass*) (passes.c:2383) ==6337==by 0x8C7136: execute_pass_list(opt_pass*) (passes.c:2384) ==6337==by 0x696791: expand_function(cgraph_node*) (cgraphunit.c:1641) ==6337==by 0x698556: compile() (cgraphunit.c:1745) ==6337==by 0x698BF9: finalize_compilation_unit() (cgraphunit.c:2120) ==6337==by 0x861550: write_global_declarations() (langhooks.c:323) ==6337== ==6337== Use of uninitialised value of size 8 ==6337==at 0xD70C70: register_active_defs(df_ref_d**) (sparseset.h:147) ==6337==by 0xD70D02: _ZL14update_df_initP7rtx_defS0_.isra.15 (fwprop.c:895) ==6337==by 0xD71F1E: try_fwprop_subst(df_ref_d*, rtx_def**, rtx_def*, rtx_def*, bool) (fwprop.c:963) ==6337==by 0xD72388: forward_propagate_into(df_ref_d*) (fwprop.c:1337) ==6337==by 0xD728C7: fwprop() (fwprop.c:1474) ==6337==by 0x8C6D17: execute_one_pass(opt_pass*) (passes.c:2335) ==6337==by 0x8C7124: execute_pass_list(opt_pass*) (passes.c:2383) ==6337==by 0x8C7136: execute_pass_list(opt_pass*) (passes.c:2384) ==6337==by 0x696791: expand_function(cgraph_node*) (cgraphunit.c:1641) ==6337==by 0x698556: compile() (cgraphunit.c:1745) ==6337==by 0x698BF9: finalize_compilation_unit() (cgraphunit.c:2120) ==6337==by 0x861550: write_global_declarations() (langhooks.c:323)
[Bug other/55840] valgrind errors in sparseset.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55840 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Component|objc|other --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-01 15:02:43 UTC --- Reassigning to correct component.
[Bug fortran/54678] second call to get_environment_variable gives valgrind warning with 8-byte integers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54678 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-05 CC||tkoenig at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-05 20:54:57 UTC --- Hi Tobias, do you plan to commit the patch from Comment #1? It looks obvious to me.
[Bug fortran/55852] [4.6/4.7/4.8 regression] internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55852 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-06 20:56:20 UTC --- The problem is that gfc_get_sym_tree is asked to get size, but that is not available in the current namespace. The ICE goes away if intrinsic:: size is added. We could simply remove the assert, but that would be a bad idea in case the user specifies something called size for something else. So, we need to generate a different name, like in the frontend optimization pass, where we use __internal_foo for an intrinsic named foo.
[Bug fortran/55852] [4.6/4.7/4.8 regression] internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55852
--- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-06
21:59:13 UTC ---
This patch works (not regression-tested yet), but the method
using the state variable seems hackish and error-prone.
What do you think?
Index: expr.c
===
--- expr.c (Revision 194850)
+++ expr.c (Arbeitskopie)
@@ -4623,7 +4623,8 @@
want to add arguments but with a NULL-expression. */
gfc_expr*
-gfc_build_intrinsic_call (const char* name, locus where, unsigned numarg, ...)
+gfc_build_intrinsic_call (const char* name, const char *symtree_name,
+ locus where, unsigned numarg, ...)
{
gfc_expr* result;
gfc_actual_arglist* atail;
@@ -4641,11 +4642,17 @@
result-value.function.name = name;
result-value.function.isym = isym;
- result-symtree = gfc_find_symtree (gfc_current_ns-sym_root, name);
- gcc_assert (result-symtree
- (result-symtree-n.sym-attr.flavor == FL_PROCEDURE
- || result-symtree-n.sym-attr.flavor == FL_UNKNOWN));
+ if (symtree_name == NULL)
+{
+ result-symtree = gfc_find_symtree (gfc_current_ns-sym_root, name);
+ gcc_assert (result-symtree
+ (result-symtree-n.sym-attr.flavor == FL_PROCEDURE
+ || result-symtree-n.sym-attr.flavor == FL_UNKNOWN));
+}
+ else
+gfc_get_sym_tree (symtree_name, gfc_current_ns, result-symtree, true);
+
va_start (ap, numarg);
atail = NULL;
for (i = 0; i numarg; ++i)
Index: simplify.c
===
--- simplify.c (Revision 194850)
+++ simplify.c (Arbeitskopie)
@@ -33,6 +33,7 @@
gfc_expr gfc_bad_expr;
+bool artificial_call = false;
/* Note that 'simplification' is not just transforming expressions.
For functions that are not simplified at compile time, range
@@ -3248,7 +3249,10 @@
gfc_expr* dim = result;
mpz_set_si (dim-value.integer, d);
+ artificial_call = true;
result = gfc_simplify_size (array, dim, kind);
+ artificial_call = false;
+
gfc_free_expr (dim);
if (!result)
goto returnNull;
@@ -5512,7 +5516,10 @@
{
mpz_set_ui (e-value.integer, n + 1);
+ artificial_call = true;
f = gfc_simplify_size (source, e, NULL);
+ artificial_call = false;
+
gfc_free_expr (e);
if (f == NULL)
{
@@ -5584,11 +5591,18 @@
/* Otherwise, we build a new SIZE call. This is hopefully at least
simpler than the original one. */
if (!simplified)
- simplified = gfc_build_intrinsic_call (size, array-where, 3,
- gfc_copy_expr (replacement),
- gfc_copy_expr (dim),
- gfc_copy_expr (kind));
+ {
+ const char *symtree_name;
+ if (artificial_call)
+ symtree_name = __internal_size;
+ else
+ symtree_name = NULL;
+ simplified = gfc_build_intrinsic_call (size, symtree_name,
array-where, 3,
+gfc_copy_expr (replacement),
+gfc_copy_expr (dim),
+gfc_copy_expr (kind));
+ }
return simplified;
}
Index: gfortran.h
===
--- gfortran.h (Revision 194850)
+++ gfortran.h (Arbeitskopie)
@@ -2797,7 +2797,8 @@
bool gfc_has_ultimate_allocatable (gfc_expr *);
bool gfc_has_ultimate_pointer (gfc_expr *);
-gfc_expr* gfc_build_intrinsic_call (const char*, locus, unsigned, ...);
+gfc_expr* gfc_build_intrinsic_call (const char*, const char *, locus,
+ unsigned, ...);
gfc_try gfc_check_vardef_context (gfc_expr*, bool, bool, bool, const char*);
[Bug bootstrap/55957] New: [4.8 Regression] Bootstrap error in prop_value_t evaluate_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55957 Bug #: 55957 Summary: [4.8 Regression] Bootstrap error in prop_value_t evaluate_stmt Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org With rev. 195125: make[3]: Entering directory `/home/ig25/Gcc/trunk-bin/gcc' g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/bid -I../libdecnumber -I../../trunk/gcc/../libbacktrace ../../trunk/gcc/tree-ssa-ccp.c -o tree-ssa-ccp.o ../../trunk/gcc/tree-ssa-ccp.c: In function 'prop_value_t evaluate_stmt(gimple)': ../../trunk/gcc/tree-ssa-ccp.c:1594:60: error: cannot convert 'built_in_class' to 'built_in_function' for argument '2' to 'bool gimple_call_builtin_p(gimple, built_in_function)' else if (gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
[Bug bootstrap/55957] [4.8 Regression] Bootstrap error in prop_value_t evaluate_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55957 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-12 22:08:26 UTC --- This is on x86_64-unknown-linux-gnu .
[Bug bootstrap/55957] [4.8 Regression] Bootstrap error in prop_value_t evaluate_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55957 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-13 12:14:38 UTC --- Created attachment 29154 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29154 Typescript from compilation Bootstrap compiler is Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../trunk/configure --prefix=/home/ig25 --enable-languages=c,fortran --with-mpfr=/usr/local --with-gmp=/usr/local --with-mpc=/usr/local Thread model: posix gcc version 4.8.0 20130103 (experimental) (GCC) Status of the tree is ! . ? C:\nppdf32Log\debuglog.txt ! gcc M gcc/fortran/frontend-passes.c ? gcc/svn-commit.tmp ? gcc/testsuite/gfortran.dg/array_constructor_40.f90 ? gcc/testsuite/gfortran.dg/auto_dealloc_3.f90 ? gcc/testsuite/gfortran.dg/real_compare_2.f90 M libgfortran/io/unix.c ? libgfortran/runtime/environ.c.orig ig25@linux-fd1f:~/Gcc/trunk svn info Path: . Working Copy Root Path: /home/ig25/Gcc/trunk URL: svn+ssh://tkoe...@gcc.gnu.org/svn/gcc/trunk Repository Root: svn+ssh://tkoe...@gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 195125 Node Kind: directory Schedule: normal Last Changed Author: rguenth Last Changed Rev: 194850 Last Changed Date: 2013-01-03 13:34:34 +0100 (Thu, 03 Jan 2013) ig25@linux-fd1f:~/Gcc/trunk/gcc grep gimple_call_builtin_p gimple.h extern bool gimple_call_builtin_p (gimple, enum built_in_function); ig25@linux-fd1f:~/Gcc/trunk/gcc The grep loooks different: Path: gimple.h Name: gimple.h Working Copy Root Path: /home/ig25/Gcc/trunk URL: svn+ssh://tkoe...@gcc.gnu.org/svn/gcc/trunk/gcc/gimple.h Repository Root: svn+ssh://tkoe...@gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 194850 Node Kind: file Schedule: normal Last Changed Author: rguenth Last Changed Rev: 193882 Last Changed Date: 2012-11-28 10:27:10 +0100 (Wed, 28 Nov 2012) Text Last Updated: 2012-12-14 21:47:35 +0100 (Fri, 14 Dec 2012) Checksum: c875cee5ce972de491ce7dca1e9da7a232d5a2ee Looks like a problem with my SVN tree, then. I will have time to re-check this evening; will close as INVALID if cleaning up my tree will make things work again.
[Bug bootstrap/55957] [4.8 Regression] Bootstrap error in prop_value_t evaluate_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55957 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-13 18:19:05 UTC --- As suspected, it was a problem in my local SVN tree. Sorry for the noise.
[Bug fortran/55978] New: [4.8 Regression] class_optional_2.f90 -Os fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978 Bug #: 55978 Summary: [4.8 Regression] class_optional_2.f90 -Os fails Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org This is for Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../trunk/configure --prefix=/home/ig25 --enable-languages=c,fortran --with-mpfr=/usr/local --with-gmp=/usr/local --with-mpc=/usr/local Thread model: posix gcc version 4.8.0 20130113 (experimental) (GCC) FAIL: gfortran.dg/class_optional_2.f90 -Os execution test May be related to PR 55483.
[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978
--- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-14
21:29:25 UTC ---
For -O0, valgrind complains about
==15263== Conditional jump or move depends on uninitialised value(s)
==15263==at 0x4F26355: _gfortran_internal_pack (in_pack_generic.c:54)
==15263==by 0x403762: a3a1.2119 (in /home/ig25/Krempel/Os/a.out)
==15263==by 0x400B26: MAIN__ (in /home/ig25/Krempel/Os/a.out)
==15263==by 0x408F0E: main (in /home/ig25/Krempel/Os/a.out)
and
==15263==
==15263== Conditional jump or move depends on uninitialised value(s)
==15263==at 0x4F26447: _gfortran_internal_pack (in_pack_generic.c:159)
==15263==by 0x403762: a3a1.2119 (in /home/ig25/Krempel/Os/a.out)
==15263==by 0x400B26: MAIN__ (in /home/ig25/Krempel/Os/a.out)
==15263==by 0x408F0E: main (in /home/ig25/Krempel/Os/a.out)
which is
size = GFC_DESCRIPTOR_SIZE (source);
switch (type_size)
and
dim = GFC_DESCRIPTOR_RANK (source);
respectively.
Reduced test case (run with -fcoarray=single):
! { dg-do run }
! { dg-options -fcoarray=single }
!
! PR fortran/50981
! PR fortran/54618
!
implicit none
type t
integer, allocatable :: i
end type t
type, extends (t):: t2
integer, allocatable :: j
end type t2
call a3a()
contains
subroutine a3a(z, z2, z3)
type(t2), optional :: z(4)
type(t2), optional, pointer :: z2(:)
type(t2), optional, allocatable :: z3(:)
type(t2), allocatable :: x(:)
type(t2), pointer :: y(:)
y = null()
call a4t2(y)
end subroutine a3a
subroutine a4t2(x)
type(t2), intent(in), optional :: x(4)
if (present (x)) call abort ()
!print *, present(x)
end subroutine a4t2
end
[Bug fortran/55806] Missed optimization with ANY or ALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806 --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-14 21:50:35 UTC --- Author: tkoenig Date: Mon Jan 14 21:50:28 2013 New Revision: 195179 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195179 Log: 2013-01-14 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55806 * frontend-passes.c (optimize_reduction): New function, including prototype. (callback_reduction): Likewise. (gfc_run_passes): Also run optimize_reduction. (copy_walk_reduction_arg): New function. (dummy_code_callback): New function. 2013-01-14 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/55806 * gfortran.dg/array_constructor_40.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_constructor_40.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55806] Missed optimization with ANY or ALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-14 22:29:37 UTC --- Now for something harder (which is Michael Metcalf's original idiom): if (any([a(1),a(2)]acc) then... This can be done by converting [a1, a2, ...] binop scalar to [a1 binop scalar, a2 binop scalar, ...] in general, followed by what has been committed already.
[Bug fortran/55978] [4.8 Regression] class_optional_2.f90 -Os fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978
--- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-14
23:03:04 UTC ---
A reduced test case which shows the problem in the dump:
! { dg-do run }
! { dg-options -fcoarray=single }
!
! PR fortran/50981
! PR fortran/54618
!
program main
implicit none
type t
integer, allocatable :: i
end type t
type, extends (t):: t2
integer, allocatable :: j
end type t2
call a3a()
contains
subroutine a3a(z, z2, z3)
type(t2), optional :: z(4)
type(t2), optional, pointer :: z2(:)
type(t2), optional, allocatable :: z3(:)
type(t2), allocatable :: x(:)
type(t2), pointer :: y(:)
y = null()
call a4t2(y)
end subroutine a3a
subroutine a4t2(x)
type(t2), intent(in), optional :: x(4)
if (present (x)) call abort ()
!print *, present(x)
end subroutine a4t2
end program
ig25@linux-fd1f:~/Krempel/Os gfortran -fcoarray=single -fdump-tree-original
c.f90
ig25@linux-fd1f:~/Krempel/Os cat c.f90.003t.original
a4t2 (struct t2[4] * restrict x)
{
if (x != 0B)
{
_gfortran_abort ();
}
L.1:;
}
a3a (struct t2[4] * restrict z, struct array1_t2 * z2, struct array1_t2 * z3)
{
struct array1_t2 y;
y.data = 0B;
y.data = 0B;
{
void * D.1914;
D.1914 = _gfortran_internal_pack (y);
a4t2 (D.1914);
if ((struct t2[0:] *) y.data != (struct t2[0:] *) D.1914)
{
{
void * D.1915;
D.1915 = D.1914;
if (D.1915 != 0B)
{
__builtin_free (D.1915);
}
}
}
}
}
_gfortran_internal_pack is called without setting up the array descriptor.
[Bug fortran/55806] Missed optimization with ANY or ALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-01-19 AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-19 21:32:37 UTC --- Created attachment 29223 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29223 Patch for demonstrating the concept Here's a patch which partially does the job. It converts [foo, bar] binop baz into [foo binop baz, bar binop baz] (but only going this way).
[Bug tree-optimization/56049] New: [4.8 Regression] Simplification to constants not done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049
Bug #: 56049
Summary: [4.8 Regression] Simplification to constants not done
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tkoe...@gcc.gnu.org
From http://gcc.gnu.org/ml/fortran/2013-01/msg00158.html :
program inline
integer i
integer a(8,8), b(8,8)
a = 0
do i = 1, 1000
call add(b, a, 1)
a = b
end do
print *, a
contains
subroutine add(b, a, o)
integer, intent(inout) :: b(8,8)
integer, intent(in) :: a(8,8), o
b = a + o
end subroutine add
end program inline
is simplified all the way to the final constant with 4.6 and
4.7 (example for 4.6.2):
;; Function inline (MAIN__) (executed once)
inline ()
{
struct array2_integer(kind=4) parm.3;
struct __st_parameter_dt dt_parm.2;
integer(kind=4) a[64];
bb 2:
a = {};
MEM[(integer(kind=4)[64] *)a] = 1000;
MEM[(integer(kind=4)[64] *)a + 4B] = 1000;
MEM[(integer(kind=4)[64] *)a + 8B] = 1000;
MEM[(integer(kind=4)[64] *)a + 12B] = 1000;
MEM[(integer(kind=4)[64] *)a + 16B] = 1000;
MEM[(integer(kind=4)[64] *)a + 20B] = 1000;
MEM[(integer(kind=4)[64] *)a + 24B] = 1000;
MEM[(integer(kind=4)[64] *)a + 28B] = 1000;
MEM[(integer(kind=4)[64] *)a + 32B] = 1000;
... and so on. Current trunk converts this to
;; Function inline (MAIN__, funcdef_no=0, decl_uid=1874, cgraph_uid=1)
(executed once)
inline ()
{
vector(4) integer(kind=4) vect_var_.16;
vector(4) integer(kind=4) vect_var_.15;
vector(4) integer(kind=4) vect_var_.14;
struct array2_integer(kind=4) parm.3;
struct __st_parameter_dt dt_parm.2;
integer(kind=4) b[64];
integer(kind=4) a[64];
unsigned int ivtmp_153;
unsigned int ivtmp_154;
bb 2:
a = {};
bb 3:
# ivtmp_154 = PHI 1000(2), ivtmp_153(4)
vect_var_.14_1 = MEM[(integer(kind=4)[64] *)a];
vect_var_.15_42 = MEM[(integer(kind=4)[64] *)a + 16B];
vect_var_.16_43 = vect_var_.14_1 + { 1, 1, 1, 1 };
vect_var_.16_44 = vect_var_.15_42 + { 1, 1, 1, 1 };
MEM[(integer(kind=4)[64] *)b] = vect_var_.16_43;
MEM[(integer(kind=4)[64] *)b + 16B] = vect_var_.16_44;
vect_var_.14_71 = MEM[(integer(kind=4)[64] *)a + 32B];
vect_var_.15_77 = MEM[(integer(kind=4)[64] *)a + 48B];
vect_var_.16_78 = vect_var_.14_71 + { 1, 1, 1, 1 };
vect_var_.16_79 = vect_var_.15_77 + { 1, 1, 1, 1 };
[Bug tree-optimization/56049] [4.8 Regression] Simplification to constants not done
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56049 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |4.8.0
[Bug fortran/54033] gfortran: Passing file as include directory - add diagnostic and ICE with -cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54033 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-20 12:33:50 UTC --- Really closing.
[Bug fortran/55806] Missed optimization with ANY or ALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Attachment #29223|0 |1 is obsolete|| --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-20 14:55:50 UTC --- Created attachment 29225 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29225 Better patch This one is not yet symmetrical, but it does not cause regressions.
[Bug fortran/56052] [4.7/4.8 Regression] ICE in omp_add_variable, at gimplify.c:5606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56052 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Target Milestone|--- |4.7.3
[Bug fortran/55919] [4.8 Regression] Bogus warning with -J directory/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55919 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-21 19:37:14 UTC --- Fixed on trunk, closing.
[Bug fortran/56079] New: [4.8 Regression] ICE with C_PTR renaming
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56079
Bug #: 56079
Summary: [4.8 Regression] ICE with C_PTR renaming
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tkoe...@gcc.gnu.org
Maybe related to PR 51578 and PR 55574.
program gar_nichts
use ISO_C_BINDING
use ISO_C_BINDING, only: C_PTR
use ISO_C_BINDING, only: abc = C_PTR
use ISO_C_BINDING, only: xyz = C_PTR
type(xyz) nada
nada = transfer(C_NULL_PTR,nada)
end program gar_nichts
ig25@linux-fd1f:/tmp gfortran nada6.f90
f951: interner Compiler-Fehler: Speicherzugriffsfehler
0x96349f crash_signal
../../trunk/gcc/toplev.c:332
0x5ab741 tree_check
../../trunk/gcc/tree.h:3668
0x5ab741 encode_derived
../../trunk/gcc/fortran/target-memory.c:242
0x5ab741 gfc_target_encode_expr(gfc_expr*, unsigned char*, unsigned long)
../../trunk/gcc/fortran/target-memory.c:319
0x5a2158 gfc_simplify_transfer(gfc_expr*, gfc_expr*, gfc_expr*)
../../trunk/gcc/fortran/simplify.c:6056
0x542f31 do_simplify
../../trunk/gcc/fortran/intrinsic.c:3817
0x550146 gfc_intrinsic_func_interface(gfc_expr*, int)
../../trunk/gcc/fortran/intrinsic.c:4160
0x58c0f6 resolve_unknown_f
../../trunk/gcc/fortran/resolve.c:2613
0x58c0f6 resolve_function
../../trunk/gcc/fortran/resolve.c:3214
0x58c0f6 gfc_resolve_expr(gfc_expr*)
../../trunk/gcc/fortran/resolve.c:6549
0x591699 resolve_code
../../trunk/gcc/fortran/resolve.c:10120
0x59421e resolve_codes
../../trunk/gcc/fortran/resolve.c:14963
0x585282 gfc_resolve
../../trunk/gcc/fortran/resolve.c:14991
0x579bc2 resolve_all_program_units
../../trunk/gcc/fortran/parse.c:4395
0x579bc2 gfc_parse_file()
../../trunk/gcc/fortran/parse.c:4662
0x5b5995 gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:189
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
ig25@linux-fd1f:/tmp gdb ~/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/f951
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-unknown-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from
/home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/f951...done.
(gdb) r nada6.f90
Starting program: /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/f951
nada6.f90
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need set solib-search-path or set sysroot?
Program received signal SIGSEGV, Segmentation fault.
encode_derived (buffer_size=8, buffer=0x7fffd6c0 , source=optimized
out) at ../../trunk/gcc/fortran/target-memory.c:242
242 ptr = TREE_INT_CST_LOW(DECL_FIELD_OFFSET(cmp-backend_decl))
(gdb) p cmp-backend_decl
$1 = (tree) 0x0
(gdb) p *cmp
$2 = {name = 0x76d5b310 __xyz_c_address, ts = {type = BT_INTEGER, kind =
8, u = {derived = 0x0, cl = 0x0, pad = 0},
interface = 0x0, is_c_interop = 1, is_iso_c = 0, f90_type = BT_INTEGER,
deferred = false}, attr = {allocatable = 0, dimension = 0,
codimension = 0, external = 0, intrinsic = 0, optional = 0, pointer = 0,
target = 0, value = 0, volatile_ = 0, temporary = 0,
dummy = 0, result = 0, assign = 0, threadprivate = 0, not_always_present =
0, implied_index = 0, subref_array_pointer = 0,
proc_pointer = 0, asynchronous = 0, contiguous = 0, class_pointer = 0, save
= SAVE_NONE, data = 0, is_protected = 0, use_assoc = 0,
use_only = 0, use_rename = 0, imported = 0, host_assoc = 0, in_namelist =
0, in_common = 0, in_equivalence = 0, function = 0,
subroutine = 0, procedure = 0, generic = 0, generic_copy = 0, implicit_type
= 0, untyped = 0, is_bind_c = 0, extension = 0,
is_class = 0, class_ok = 0, vtab = 0, vtype = 0, is_c_interop = 0, is_iso_c
= 0, sequence = 0, elemental = 0, pure = 0,
recursive = 0, unmaskable = 0, masked = 0, contained = 0, mod_proc = 0,
abstract = 0, public_used = 0, implicit_pure = 0,
noreturn = 0, entry = 0, entry_master = 0, mixed_entry_master = 0,
always_explicit = 0, artificial = 0, referenced = 0,
is_main_program = 0, access = ACCESS_UNKNOWN, intent = INTENT_UNKNOWN,
flavor = FL_UNKNOWN, if_source = IFSRC_UNKNOWN,
proc = PROC_UNKNOWN, cray_pointer = 0, cray_pointee = 0, alloc_comp = 0,
pointer_comp = 0,
[Bug fortran/56079] [4.8 Regression] ICE with C_PTR renaming and TRANSFER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56079 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|[4.8 Regression] ICE with |[4.8 Regression] ICE with |C_PTR renaming |C_PTR renaming and TRANSFER --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-22 20:03:39 UTC --- Shortened a bit: program gar_nichts use ISO_C_BINDING, only: C_NULL_PTR use ISO_C_BINDING, only: xyz = C_PTR type(xyz) nada nada = transfer(C_NULL_PTR,nada) end program gar_nichts
[Bug fortran/56079] [4.8 Regression] ICE with C_PTR renaming and TRANSFER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56079 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug fortran/56079] [4.7/4.8 Regression] ICE with C_PTR renaming and TRANSFER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56079 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-25 22:56:43 UTC --- This also fails in the same place (without renaming): program gar_nichts use ISO_C_BINDING, only :: C_PTR, C_NULL_PTR type(c_ptr) nada call foo(transfer(C_NULL_PTR,nada)) end program gar_nichts
[Bug fortran/56079] [4.7/4.8 Regression] ICE with C_PTR renaming and TRANSFER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56079 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-25 23:10:28 UTC --- (In reply to comment #3) Sorry, an error in the test case. This has the same error: program gar_nichts use ISO_C_BINDING type(c_ptr) nada call foo(transfer(C_NULL_PTR,nada)) ! call foo(transfer(0_8, nada)) end program gar_nichts The test case works if the constant 0_8 is used instead.
[Bug fortran/50627] [4.6/4.7/4.8 Regression] Error recovery: ICE in gfc_free_namespace after diagnosing missing end of construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org |
[Bug fortran/55806] Missed optimization with ANY or ALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Attachment #29225|0 |1 is obsolete|| --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-31 19:48:25 UTC --- Created attachment 29321 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29321 Patch that works This time, both for any([a,b,c] eps) and any(eps [a,b,c]).
[Bug fortran/33341] array temporaries for array constructors (unnecessary stores)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33341 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-31 21:01:58 UTC --- I sometimes should read my own old PRs. Closing this one as a duplicate of PR 55806 (which has a patch :-) *** This bug has been marked as a duplicate of bug 55806 ***
[Bug fortran/55806] Missed optimization with ANY or ALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-01-31 21:01:58 UTC --- *** Bug 33341 has been marked as a duplicate of this bug. ***
[Bug fortran/55839] Inefficiency with array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55839 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-02-01 AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-02-01 17:47:54 UTC --- I'll give it a shot once trunk reopens.
[Bug fortran/45159] Unnecessary temporaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45159 --- Comment #27 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-02-01 18:16:30 UTC --- To allow expressions like a(n:2*n:2) = a(n+1:2*n+1:2) to be optimized, I will try to write a function which calculates the difference between two gfc_expr() for easy cases. This could also help in other cases, such as determining string lenghts for expressions like c(n:n+2).
[Bug fortran/56054] [4.6/4.7/4.8 Regression] f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3337
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56054 --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-02-02 09:51:03 UTC --- Author: tkoenig Date: Sat Feb 2 09:50:58 2013 New Revision: 195684 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195684 Log: 2013-02-02 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/50627 PR fortran/56054 * decl.c (gfc_match_end): Remove half-ready namespace from parent if the end of a block is missing. * parse.c (parse_module): Do not put namespace into gsymbol on error. 2013-02-02 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/50627 PR fortran/56054 * gfortran.dg/block_12.f90: New test. * gfortran.dg/module_error_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/block_12.f90 trunk/gcc/testsuite/gfortran.dg/module_error_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50627] [4.6/4.7/4.8 Regression] Error recovery: ICE in gfc_free_namespace after diagnosing missing end of construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-02-02 09:51:03 UTC --- Author: tkoenig Date: Sat Feb 2 09:50:58 2013 New Revision: 195684 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195684 Log: 2013-02-02 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/50627 PR fortran/56054 * decl.c (gfc_match_end): Remove half-ready namespace from parent if the end of a block is missing. * parse.c (parse_module): Do not put namespace into gsymbol on error. 2013-02-02 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/50627 PR fortran/56054 * gfortran.dg/block_12.f90: New test. * gfortran.dg/module_error_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/block_12.f90 trunk/gcc/testsuite/gfortran.dg/module_error_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50627] [4.6/4.7 Regression] Error recovery: ICE in gfc_free_namespace after diagnosing missing end of construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.3 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] Error |Error recovery: ICE in |recovery: ICE in |gfc_free_namespace after|gfc_free_namespace after |diagnosing missing end of |diagnosing missing end of |construct |construct --- Comment #8 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-02-02 09:52:38 UTC --- Fixed on trunk so far.
[Bug fortran/45159] Unnecessary temporaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45159 --- Comment #28 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-02-02 21:31:37 UTC --- Created attachment 29340 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29340 patch which implements comment #27 Still have to verify that this one is correct in all cases.
[Bug fortran/56054] [4.6/4.7/4.8 Regression] f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3337
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56054 --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-02-02 22:38:22 UTC --- Author: tkoenig Date: Sat Feb 2 22:38:14 2013 New Revision: 195687 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195687 Log: 2013-02-02 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/50627 PR fortran/56054 * decl.c (gfc_match_end): Remove half-ready namespace from parent if the end of a block is missing. * parse.c (parse_module): Do not put namespace into gsymbol on error. 2013-02-02 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/50627 PR fortran/56054 * gfortran.dg/block_12.f90: New test. * gfortran.dg/module_error_1.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/block_12.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/module_error_1.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/decl.c branches/gcc-4_7-branch/gcc/fortran/parse.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/50627] [4.6/4.7 Regression] Error recovery: ICE in gfc_free_namespace after diagnosing missing end of construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627 --- Comment #9 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-02-02 22:38:22 UTC --- Author: tkoenig Date: Sat Feb 2 22:38:14 2013 New Revision: 195687 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195687 Log: 2013-02-02 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/50627 PR fortran/56054 * decl.c (gfc_match_end): Remove half-ready namespace from parent if the end of a block is missing. * parse.c (parse_module): Do not put namespace into gsymbol on error. 2013-02-02 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/50627 PR fortran/56054 * gfortran.dg/block_12.f90: New test. * gfortran.dg/module_error_1.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/block_12.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/module_error_1.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/decl.c branches/gcc-4_7-branch/gcc/fortran/parse.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/50627] [4.6/4.7 Regression] Error recovery: ICE in gfc_free_namespace after diagnosing missing end of construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627 --- Comment #10 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-02-03 13:15:24 UTC --- Author: tkoenig Date: Sun Feb 3 13:15:18 2013 New Revision: 195695 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195695 Log: 2013-02-03 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/50627 PR fortran/56054 * decl.c (gfc_match_end): Remove half-ready namespace from parent if the end of a block is missing. * parse.c (parse_module): Do not put namespace into gsymbol on error. 2013-02-03 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/50627 PR fortran/56054 * gfortran.dg/block_12.f90: New test. * gfortran.dg/module_error_1.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/block_12.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/module_error_1.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/decl.c branches/gcc-4_6-branch/gcc/fortran/parse.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/56054] [4.6/4.7/4.8 Regression] f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3337
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56054 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-02-03 13:15:24 UTC --- Author: tkoenig Date: Sun Feb 3 13:15:18 2013 New Revision: 195695 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195695 Log: 2013-02-03 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/50627 PR fortran/56054 * decl.c (gfc_match_end): Remove half-ready namespace from parent if the end of a block is missing. * parse.c (parse_module): Do not put namespace into gsymbol on error. 2013-02-03 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR fortran/50627 PR fortran/56054 * gfortran.dg/block_12.f90: New test. * gfortran.dg/module_error_1.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/block_12.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/module_error_1.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/decl.c branches/gcc-4_6-branch/gcc/fortran/parse.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/50627] [4.6/4.7 Regression] Error recovery: ICE in gfc_free_namespace after diagnosing missing end of construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-02-03 13:16:30 UTC --- Fixed on all affected and supported branches, closing.
[Bug fortran/59023] [4.9 regression] ICE in gfc_search_interface with BIND(C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59023 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org --- Valgrind backtrace: ==19413== Memcheck, a memory error detector ==19413== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==19413== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==19413== Command: /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/f951 foo.f90 ==19413== ==19413== Invalid read of size 4 ==19413==at 0x57708A: gfc_search_interface(gfc_interface*, int, gfc_actual_arglist**) (interface.c:3439) ==19413==by 0x5BD333: gfc_resolve_expr(gfc_expr*) (resolve.c:2480) ==19413==by 0x5C1C03: resolve_code(gfc_code*, gfc_namespace*) (resolve.c:9775) ==19413==by 0x5C4BBE: resolve_codes(gfc_namespace*) (resolve.c:14566) ==19413==by 0x5C4AC7: resolve_codes(gfc_namespace*) (resolve.c:14552) ==19413==by 0x5C4CA2: gfc_resolve(gfc_namespace*) [clone .part.45] (resolve.c:14594) ==19413==by 0x5B0BEF: gfc_parse_file() (parse.c:4672) ==19413==by 0x5EE8C5: gfc_be_parse_file() (f95-lang.c:188) ==19413==by 0x9F9E55: compile_file() (toplev.c:547) ==19413==by 0x9FBE27: toplev_main(int, char**) (toplev.c:1887) ==19413==by 0x5A54BE4: (below main) (in /lib64/libc-2.18.so) ==19413== Address 0x8b4853fd89495554 is not stack'd, malloc'd or (recently) free'd ==19413==
[Bug fortran/58003] internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:165
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58003 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||tkoenig at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org --- I have a patch.
[Bug fortran/59604] New: Constant comparisons with -fno-range-check and int(z'...')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 Bug ID: 59604 Summary: Constant comparisons with -fno-range-check and int(z'...') Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Trying out a fix for PR 58003, I found that the following program was of the opinion that -1 does not equal -1: ig25@linux-fd1f:~/Krempel/NoRange cat bar.f90 program test use iso_fortran_env implicit none integer, parameter :: wt = int32 print *, int(z'',wt) print *, int(z'',wt) /= -1 end program test ig25@linux-fd1f:~/Krempel/NoRange gfortran -fno-range-check bar.f90 ig25@linux-fd1f:~/Krempel/NoRange ./a.out -1 T
[Bug fortran/59604] Constant comparisons with -fno-range-check and int(z'...')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org --- TRANSFER gets this right.
[Bug fortran/59604] Constant comparisons with -fno-range-check and int(z'...')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Blocks||58003 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org --- (In reply to kargl from comment #2) (In reply to Thomas Koenig from comment #1) TRANSFER gets this right. It is unclear what you mean here. What I mean is that program test if (transfer(z'',1) /= -1) call abort end program test does not call abort. Also setting this as blocking 58003, because an obvious fix to that bug would replace an ICE with a wrong-code bug for some corner cases (not preferable :-)
[Bug fortran/59612] New: iso_fortran_env segfaults with -fdump-fortran-original
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59612
Bug ID: 59612
Summary: iso_fortran_env segfaults with -fdump-fortran-original
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
ig25@linux-fd1f:~/Krempel/NoRange cat iso.f90
program main
use iso_fortran_env
end program main
ig25@linux-fd1f:~/Krempel/NoRange gfortran -fdump-fortran-original iso.f90
Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = main
symtree: 'Lock_type' || symbol: 'lock_type'
type spec : (UNKNOWN 0)
attributes: (DERIVED USE-ASSOC(iso_fortran_env))
symtree: 'atomic_int_kind'|| symbol: 'atomic_int_kind'
type spec : (INTEGER 4)
attributes: (PARAMETER USE-ASSOC(iso_fortran_env))
value: 4
symtree: 'atomic_logical_kind'|| symbol: 'atomic_logical_kind'
type spec : (INTEGER 4)
attributes: (PARAMETER USE-ASSOC(iso_fortran_env))
value: 4
symtree: 'character_kinds'|| symbol: 'character_kinds'
type spec : (INTEGER 4)
attributes: (PARAMETER DIMENSION USE-ASSOC(iso_fortran_env))
value: (/ 1 , 4 /)
Array spec:(1 [0] AS_EXPLICIT 1 2 )
symtree: 'character_storage_size'|| symbol: 'character_storage_size'
type spec : (INTEGER 4)
attributes: (PARAMETER USE-ASSOC(iso_fortran_env))
value: 8
symtree: 'compiler_options'|| symbol: 'compiler_options'
f951: interner Compiler-Fehler: Speicherzugriffsfehler
0x9f9dff crash_signal
../../trunk/gcc/toplev.c:336
0x5635bc show_typespec
../../trunk/gcc/fortran/dump-parse-tree.c:113
0x566a3c show_symbol
../../trunk/gcc/fortran/dump-parse-tree.c:841
0x566a3c show_symtree
../../trunk/gcc/fortran/dump-parse-tree.c:1000
0x5dcdc9 do_traverse_symtree
../../trunk/gcc/fortran/symbol.c:3581
0x566571 show_namespace
../../trunk/gcc/fortran/dump-parse-tree.c:2284
0x5b09ee gfc_parse_file()
../../trunk/gcc/fortran/parse.c:4728
0x5ee895 gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:188
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
bearbeiten Sie die Quellen zunächst mit einem Präprozessor, wenn es
dienlich ist.
Please include the complete backtrace with any bug report.
Siehe http://gcc.gnu.org/bugs.html für nähere Anweisungen.
ig25@linux-fd1f:~/Krempel/NoRange gfortran -v
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Ziel: x86_64-unknown-linux-gnu
Konfiguriert mit: ../trunk/configure --prefix=/home/ig25
--enable-languages=c,fortran,c++
Thread-Modell: posix
gcc-Version 4.9.0 20131225 (experimental) (GCC)
valgrind shows:
==13350== Invalid read of size 8
==13350==at 0x5635BC: show_typespec(gfc_typespec*) (dump-parse-tree.c:113)
==13350==by 0x566A3C: show_symtree(gfc_symtree*) (dump-parse-tree.c:841)
==13350==by 0x5DCDC9: do_traverse_symtree(gfc_symtree*, void
(*)(gfc_symtree*), void (*)(gfc_symbol*)) (symbol.c:3581)
==13350==by 0x566571: show_namespace(gfc_namespace*)
(dump-parse-tree.c:2284)
==13350==by 0x5B09EE: gfc_parse_file() (parse.c:4728)
==13350==by 0x5EE895: gfc_be_parse_file() (f95-lang.c:188)
==13350==by 0x9F9E25: compile_file() (toplev.c:547)
==13350==by 0x9FBDF7: toplev_main(int, char**) (toplev.c:1887)
==13350==by 0x5A54BE4: (below main) (in /lib64/libc-2.18.so)
==13350== Address 0x0 is not stack'd, malloc'd or (recently) free'd
gdb shows that the typespec for compiler_options is NULL:
symtree: 'compiler_options'|| symbol: 'compiler_options'
Program received signal SIGSEGV, Segmentation fault.
0x005635bc in show_typespec (ts=0x0) at
../../trunk/gcc/fortran/dump-parse-tree.c:113
113 show_expr (ts-u.cl-length);
(gdb) up
#1 0x00566a3d in show_symbol (sym=0x184ee10) at
../../trunk/gcc/fortran/dump-parse-tree.c:841
841 show_typespec (sym-ts);
(gdb) p sym
$1 = (gfc_symbol *) 0x184ee10
(gdb) p *sym
$2 = {name = 0x76c53738 compiler_options, module = 0x76d33340
iso_fortran_env, declared_at = {nextc = 0x17dcb68, lb = 0x17dcb30}, ts = {
type = BT_CHARACTER, kind = 1, u = {derived = 0x0, cl = 0x0, pad = 0},
interface = 0x0, is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN,
deferred = false}, attr = {allocatable = 0, dimension = 0, codimension = 0,
external = 0, intrinsic = 1, optional = 0, pointer = 0, target = 0,
value = 0, volatile_ = 0, temporary = 0, dummy = 0, result = 0, assign = 0,
threadprivate = 0, not_always_present = 0, implied_index = 0,
subref_array_pointer = 0, proc_pointer = 0, asynchronous = 0, contiguous =
0, class_pointer = 0, save = SAVE_NONE, data = 0, is_protected = 0,
use_assoc = 1, use_only = 0, use_rename = 0, imported = 0, host_assoc = 0,
in_namelist = 0, in_common
[Bug fortran/59604] Constant comparisons with -fno-range-check and int(z'...')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-12-28 Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org --- I have a patch.
[Bug fortran/59604] Constant comparisons with -fno-range-check and int(z'...')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|UNCONFIRMED Ever confirmed|1 |0 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org --- (In reply to Steve Kargl from comment #5) On Fri, Dec 27, 2013 at 07:53:00PM +, tkoenig at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Blocks||58003 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org --- (In reply to kargl from comment #2) (In reply to Thomas Koenig from comment #1) TRANSFER gets this right. It is unclear what you mean here. What I mean is that program test if (transfer(z'',1) /= -1) call abort end program test does not call abort. I suspect that the above is not portable as transfer() simply copies bits. z'FFF' is an integer(8) (or integer(16)) entity. Transfer() is copying 32-bits from that entity. It is clear from the -fdump-tree-original that middle-end is converting the resulting 32-bit thing into -1. So, you're relying on twos-complement wrap around semantics. As gcc supports only twos complement arithmetic, I think this is OK.
[Bug fortran/54234] -Wconversion or -Wconversion-extra should warn for CMPLX(dp,dp)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54234 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-12 16:23:19 UTC --- This is certainly a mistake made by lots of people, so I think a warning would be appropriate.
[Bug fortran/54298] Add warning when doing equal/nonequal floating-point comparisons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54298 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-08-17 CC||tkoenig at gcc dot gnu.org AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-17 16:07:43 UTC --- Sounds doable. I'll give it a shot.
[Bug fortran/54298] Add warning when doing equal/nonequal floating-point comparisons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54298 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-19 15:05:49 UTC --- Author: tkoenig Date: Sun Aug 19 15:05:41 2012 New Revision: 190516 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190516 Log: 2012-08-19 Thomas König tkoe...@gcc.gnu.org PR fortran/54298 * gfortran.h (struct gfc_option_t): Add warn_compare_reals. * lang.opt: Add Wcompare-reals. * invoke.texi: Document -Wcompare-reals. * resolve.c (resolve_operator): If -Wcompare-reals is in effect, warn about equality/inequality comparisions for REAL and COMPLEX. * options.c (gfc_init_options): Set warn_compare_reals. (set_Wall): Include warn_compare_reals in Wall. (gfc_handle_option): Handle Wcompare_reals. 2012-08-19 Thomas König tkoe...@gcc.gnu.org PR fortran/54298 * gfortran.dg/real_compare_1.f90: New test case. * gfortran.dg/bessel_5.f90 Add -Wno-compare-reals to options. Added: trunk/gcc/testsuite/gfortran.dg/real_compare_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bessel_5.f90
[Bug fortran/54298] Add warning when doing equal/nonequal floating-point comparisons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54298 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-19 16:08:37 UTC --- Fixed on trunk, closing.
[Bug fortran/54302] Add optional warning when declaring a identifier in a nested scope, which matches on otherwise available one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54302 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-19 Ever Confirmed|0 |1 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-19 17:01:37 UTC --- In other words, implement -Wshadow in gfortran. Makes sense. Confirmed.
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-19 Ever Confirmed|0 |1 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-19 17:10:28 UTC --- (In reply to comment #3) Given the potential badness, I still think one should warn for (a) to (d). Though, one probably should think of not warning if the target has the SAVE attribute. If the target has the SAVE attribute or is allocatable, we shouldn't warn. The other question is whether the warning should be enabled by -Wall or not. (I would enable it with -Wall.) At least. Because the behavior is very likely to lead to difficult to detect bugs, I would even consider warning by default.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #10 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-09-01 19:20:26 UTC --- Also fails with x86_64-unknown-linux-gnu, with tkoenig@gcc14:~/trunk-bin$ as -v GNU assembler version 2.18.0 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.18.0.20080103 This is on gcc14.fssfrance.org, so this breaks automated testing for me.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Severity|normal |blocker --- Comment #11 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-09-01 19:30:22 UTC --- Revision 190769 was fine. It looks like this is the cause: Author: drepper Date: Wed Aug 29 22:05:41 2012 New Revision: 190787 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190787 Log: * include/bits/random.h (random_device): Move implementation to... * src/c++11/random.cc: ...here. New file. * config/abi/pre/gnu.ver: Add new version GLIBCXX_3.4.18. Export std::random_device::* symbols. * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Generated. * src/c++11/Makefile.am (sources): Add random.cc. * src/c++11/Makefile.in: Regenerated. Added: trunk/libstdc++-v3/src/c++11/random.cc Modified: trunk/libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/include/bits/random.h trunk/libstdc++-v3/src/c++11/Makefile.am trunk/libstdc++-v3/src/c++11/Makefile.in
[Bug fortran/54465] New: Implement -Wextra for Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54465 Bug #: 54465 Summary: Implement -Wextra for Fortran Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org It would be nice to define some Fortran warnings under -Wextra. (Just to keep track of this). Initial patch: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00022.html
[Bug fortran/54599] Issues found in gfortran by the Coverity Scan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54599 --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-09-22 10:32:58 UTC --- Author: tkoenig Date: Sat Sep 22 10:32:51 2012 New Revision: 191640 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191640 Log: 2012-09-22 Thomas König tkoe...@gcc.gnu.org PR fortran/54599 * dependency.c (gfc_dep_compare_expr): Clarify logic, remove dead code. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c
[Bug fortran/54599] Issues found in gfortran by the Coverity Scan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54599 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-22 Ever Confirmed|0 |1 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-09-22 10:34:22 UTC --- The dependency.c issue is fixed.
[Bug fortran/54687] New: Use gcc option machinery for gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687 Bug #: 54687 Summary: Use gcc option machinery for gfortran Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org CC: m...@gcc.gnu.org It would be nice if gfortran used the normal gcc option machinery (including the generated variables). See http://gcc.gnu.org/ml/fortran/2012-09/msg00090.html for some details.
[Bug fortran/52724] Internal read with character(kind=4) data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52724
--- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-09-24
18:07:17 UTC ---
This patch looks promising:
Index: list_read.c
===
--- list_read.c (Revision 191649)
+++ list_read.c (Arbeitskopie)
@@ -199,9 +199,16 @@ next_char (st_parameter_dt *dtp)
if (is_internal_unit (dtp))
{
- char cc;
- length = sread (dtp-u.p.current_unit-s, cc, 1);
- c = cc;
+ /* Check for kind=4 internal unit. */
+ if (dtp-common.unit)
+ length = sread (dtp-u.p.current_unit-s, c, sizeof (gfc_char4_t));
+ else
+ {
+ char cc;
+ length = sread (dtp-u.p.current_unit-s, cc, 1);
+ c = cc;
+ }
+
if (length 0)
{
generate_error (dtp-common, LIBERROR_OS, NULL);
Index: unix.c
===
--- unix.c (Revision 191649)
+++ unix.c (Arbeitskopie)
@@ -959,7 +959,7 @@ open_internal4 (char *base, int length, gfc_offset
s-buffer = base;
s-buffer_offset = offset;
- s-active = s-file_length = length;
+ s-active = s-file_length = length * sizeof (gfc_char4_t);
s-st.vptr = mem4_vtable;
[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54736 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-09-28 CC||tkoenig at gcc dot gnu.org AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-09-28 18:38:13 UTC --- Mine.
[Bug fortran/52724] Internal read with character(kind=4) data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52724 --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-09-29 17:38:50 UTC --- Author: tkoenig Date: Sat Sep 29 17:38:46 2012 New Revision: 191854 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191854 Log: 2012-09-29 Thomas König tkoe...@gcc.gnu.org PR fortran/52724 * list_read.c (next_char): Handle kind=4 characters. * unix.c (open_internal4): Correct lenth of internal file. 2012-09-29 Thomas König tkoe...@gcc.gnu.org PR fortran/52724 * gfortran.dg/internal_readwrite_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/internal_readwrite_3.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c trunk/libgfortran/io/unix.c
[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54736 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-09/msg01962.htm ||l --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-09-30 16:38:10 UTC --- Patch posted.
[Bug fortran/54833] New: Don't wrap __builtin_free(a) in if (a != NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54833
Bug #: 54833
Summary: Don't wrap __builtin_free(a) in if (a != NULL)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: tkoe...@gcc.gnu.org
ReportedBy: tkoe...@gcc.gnu.org
The Fortran front end at the moment generates many calls
to __builtin_free with
if (a.data != 0B)
{
__builtin_free ((void *) a.data);
}
a.data = 0B;
This is not necessary, because free(NULL) is well-defined no-op.
[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54736 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-10-06 13:04:38 UTC --- Author: tkoenig Date: Sat Oct 6 13:04:35 2012 New Revision: 192158 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192158 Log: 2012-10-06 Thomas König tkoe...@gcc.gnu.org PR libfortran/54736 * runtime/environ.c (search_unit): Correct logic for binary search. (mark_single): Fix index errors. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/runtime/environ.c
[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54736 --- Comment #8 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-10-12 18:56:23 UTC --- Author: tkoenig Date: Fri Oct 12 18:56:16 2012 New Revision: 192408 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192408 Log: 2012-10-06 Thomas König tkoe...@gcc.gnu.org PR libfortran/54736 Backport from trunk * runtime/environ.c (search_unit): Correct logic for binary search. (mark_single): Fix index errors. Modified: branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/runtime/environ.c
[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54736 --- Comment #9 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-10-12 19:38:09 UTC --- Author: tkoenig Date: Fri Oct 12 19:38:04 2012 New Revision: 192411 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192411 Log: 2012-10-12 Thomas König tkoe...@gcc.gnu.org PR libfortran/54736 libgfortran/Changelog: Fix date of last commit. Modified: branches/gcc-4_7-branch/libgfortran/ChangeLog
[Bug fortran/48636] Enable more inlining with -O2 and higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 --- Comment #29 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-10-20 12:10:49 UTC --- Another approach (not for the benchmarks) would be to make inlining tunable by the user, e.g. support !GCC$ ATTRIBUTES always_inline :: procedure_name See PR 41209.
