[Bug fortran/55272] [4.8 Regression] ICE on passing coarray argument between files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55272
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|--- |4.8.0
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-12
09:21:16 UTC ---
The culprit seems to be Rev. 189881.
Untested patch:
--- module.c(Revision 193396)
+++ module.c(Arbeitskopie)
@@ -2395,7 +2395,7 @@ mio_array_spec (gfc_array_spec **asp)
if (iomode == IO_INPUT as-corank)
as-cotype = (as-type == AS_DEFERRED) ? AS_DEFERRED : AS_EXPLICIT;
- if (as-rank 0)
+ if (as-rank + as-corank 0)
for (i = 0; i as-rank + as-corank; i++)
{
mio_expr (as-lower[i]);
[Bug fortran/55272] [4.8 Regression] ICE on passing coarray argument between files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55272 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-12 11:03:46 UTC --- Author: burnus Date: Mon Nov 12 11:03:42 2012 New Revision: 193429 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193429 Log: 2012-11-12 Tobias Burnus bur...@net-b.de PR fortran/55272 * module.c (mio_array_spec): Correctly handle coarray scalars. 2012-11-12 Tobias Burnus bur...@net-b.de PR fortran/55272 * gfortran.dg/coarray_29_1.f90: New. * gfortran.dg/coarray_29_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/coarray_29_1.f90 trunk/gcc/testsuite/gfortran.dg/coarray_29_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55272] [4.8 Regression] ICE on passing coarray argument between files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55272 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-12 11:09:50 UTC --- FIXED on the 4.8 trunk (which was only affected).
[Bug fortran/55272] [4.8 Regression] ICE on passing coarray argument between files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55272 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-12 11:10:16 UTC --- really mark as fixed
[Bug fortran/55282] [OOP] openmp directive and classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55282 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-13 10:44:14 UTC --- (In reply to comment #1) Note that Fortran 2003 is not supported in OpenMP 3.1. This may change with OpenMP 4, but I'm not sure of that. The OpenMP ARB wasn't as active as I had hoped for, cf. Fortran 2003 in 1.6 Normative References in the OpenMP 4.0 RC, available at http://openmp.org/wp/openmp-specifications/ At a glance, it looks as if almost none of the Fortran 2003 features have been taken care of.
[Bug fortran/55297] [4.8 Regression] type-bound operator clashes with abstract interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55297 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid CC||burnus at gcc dot gnu.org Target Milestone|--- |4.8.0 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-13 11:19:24 UTC --- Seems to be due to http://gcc.gnu.org/viewcvs?root=gccview=revrev=189022 for PR fortran/41951 and PR fortran/49591. In the resolve.c's resolve_typebound_intrinsic_op: 11546 if (gfc_check_new_interface (derived-ns-op[op], target_proc, 11547 p-where) == FAILURE) Here target_proc-name == negative and target_proc-ns-proc_name-name == athlete_module The symbol (i.e. derived type) is resolved twice: Once for the module athlete_module (= gfc_current_ns-proc_name) and then again for the abstract interface procedure sum_interface (= gfc_current_ns-proc_name). In either case, one has derived-ns-proc_name-name == athlete_module, which causes the symbol be added twice added to the same namespace. The question is whether it should be fixed by adding if (derived-ns != gfc_current_ns) return; Or using gfc_current_ns instead of derived-ns. Or what's the most appropriate fix.
[Bug objc/55291] libsanitizer doesn't build multilib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55291 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-13 11:57:13 UTC --- See also http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00766.html
[Bug fortran/55395] [4.8 Regression] libgfortran bootstrap failure on powerpc-linux-gnu and arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55395 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-19 23:09:57 UTC --- Untested: --- a/libgfortran/io/list_read.c +++ b/libgfortran/io/list_read.c @@ -2377,3 +2377,3 @@ nml_query (st_parameter_dt *dtp, char c) static const index_type endlen = 3; - static const char endl[] = \r\n; + static const char endline[] = \r\n; static const char nmlend[] = end\r\n; @@ -2381,3 +2381,3 @@ nml_query (st_parameter_dt *dtp, char c) static const index_type endlen = 2; - static const char endl[] = \n; + static const char endline[] = \n; static const char nmlend[] = end\n; @@ -2415,3 +2415,3 @@ nml_query (st_parameter_dt *dtp, char c) memcpy ((char*)(p + 1), dtp-namelist_name, len); - memcpy ((char*)(p + len + 1), endl, endlen - 1); + memcpy ((char*)(p + len + 1), endline, endlen - 1); for (nl = dtp-u.p.ionml; nl; nl = nl-next) @@ -2426,3 +2426,3 @@ nml_query (st_parameter_dt *dtp, char c) memcpy ((char*)(p + 1), nl-var_name, len); - memcpy ((char*)(p + len + 1), endl, endlen - 1); + memcpy ((char*)(p + len + 1), endline, endlen - 1); }
[Bug libquadmath/55225] Fail to build lgammaq.c from trunk with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55225 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-21 13:46:41 UTC --- Author: burnus Date: Wed Nov 21 13:46:34 2012 New Revision: 193695 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193695 Log: 2012-11-21 Tobias Burnus bur...@net-b.de PR libquadmath/55225 * math/lgammaq.c (lgammaq): Use local variable if math.h does not provide signgam. * acinclude.m4 (LIBQUAD_CHECK_MATH_H_SIGNGAM): New check. * configure.ac: Use it. * configure: Regenerate. * config.h.in: Regenerate. Modified: trunk/libquadmath/ChangeLog trunk/libquadmath/acinclude.m4 trunk/libquadmath/config.h.in trunk/libquadmath/configure trunk/libquadmath/configure.ac trunk/libquadmath/math/lgammaq.c
[Bug libquadmath/55225] Fail to build lgammaq.c from trunk with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55225 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||burnus at gcc dot gnu.org Resolution||FIXED --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-21 13:48:48 UTC --- FIXED on the trunk (4.8), which was only affected. While POSIX requires that signgam is used for lgamma and, hence, math.h includes it. C99 doesn't have signgam. Thus, even if MinGW-w64 now supports it, a configure check makes sense as other systems might not (yet?) support it.
[Bug fortran/55427] [OOP] ICE with class-array-pointer result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55427 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-21 18:44:45 UTC --- For trans-expr.c:6350 in gfc_trans_pointer_assignment: 6349 gfc_add_modify (block, lse.expr, 6350 fold_convert (TREE_TYPE (lse.expr), rse.expr)); TREE_TYPE(LHS) is: pointer_type 0x2c29b1f8 type record_type 0x2c29b150 __vtype_base_types_Base_type BLK And RHS is: call_expr 0x2c1986c0 type record_type 0x2c29b930 __class_base_types_Base_type_1_0p type_4 BLK size integer_cst 0x2c270e20 constant 448
[Bug fortran/55444] New: Rejects valid code with USE ISO_C_BINDING in BLOCK DATA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55444 Bug #: 55444 Summary: Rejects valid code with USE ISO_C_BINDING in BLOCK DATA Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Reported by at Henrik Holst athttps://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/aOMi2iZ-2c8 The following program prints bogus errors of the form: USE ISO_C_BINDING ! FAILS 1 Error: INTENT attribute not allowed in BLOCK DATA program unit at (1) Error: EXTERNAL attribute not allowed in BLOCK DATA program unit at (1) BLOCKDATA ! USE ISO_C_BINDING, ONLY: C_INT, C_FLOAT ! WORKS USE :: ISO_C_BINDING ! FAILS INTEGER(C_INT) X REAL(C_FLOAT) Y COMMON /FOO/ X,Y BIND(C,NAME='fortranStuff') /FOO/ DATA X /1/ DATA Y /2.0/ END BLOCKDATA * * * The message is printed in check_conflict where the following is true: if (gfc_current_state () == COMP_BLOCK_DATA) The caller is resolve_contained_functions – the question is why the symbols end up there (seemingly also functions like c_backspace of flavour parameter)? The message is printed for the SHAPE= argument of c_f_pointer.
[Bug libquadmath/55462] [4.8 Regression] FAIL: gfortran.dg/quad_2.f90 -O* execution test after revision 193770
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55462 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-25 19:59:11 UTC --- Author: burnus Date: Sun Nov 25 19:59:07 2012 New Revision: 193796 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193796 Log: 2012-11-25 Tobias Burnus bur...@net-b.de PR libquadmath/55462 * strtod/strtod_l.c (round_and_return): Use HAVE_FENV_H instead of nonexisting HAVE_GET_ROUNDING_MODE. Modified: trunk/libquadmath/ChangeLog trunk/libquadmath/strtod/strtod_l.c
[Bug libquadmath/55462] [4.8 Regression] FAIL: gfortran.dg/quad_2.f90 -O* execution test after revision 193770
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55462 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-25 20:02:46 UTC --- FIXED. At least on systems which have fenv.h and thus fegetround(). If they don't one might end up using - for READ - round to zero/round down instead of round nearest which was use for WRITE.
[Bug fortran/55469] memory leak on read with istat.ne.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-26 09:26:46 UTC --- Untested: --- a/libgfortran/io/list_read.c +++ b/libgfortran/io/list_read.c @@ -1966,8 +1966,8 @@ list_formatted_read_scalar (st_parameter_dt *dtp, bt type, void *p, } +cleanup: if (--dtp-u.p.repeat_count = 0) free_saved (dtp); -cleanup: if (err == LIBERROR_END) hit_eof (dtp);
[Bug fortran/55469] memory leak on read with istat.ne.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-26
10:23:54 UTC ---
Didn't help. The following should work. The crucial part is free_line. At a
glance free_saved(dtp) (here and in comment 2) seems also to be sensible, but
one should read through the file to check that it is indeed correct - and to
find other places where free_line is missing.
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -1757,8 +1757,9 @@ read_real (st_parameter_dt *dtp, void * dest, int length)
bad_real:
+ free_line (dtp);
+ free_saved (dtp);
if (nml_bad_return (dtp, c))
return;
- free_saved (dtp);
if (c == EOF)
{
[Bug fortran/55465] Name collision in C binding (calling C from Fortran)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid CC||burnus at gcc dot gnu.org Depends on||48858 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-26 17:40:49 UTC --- (In reply to comment #3) I'm not sure if this is legal. In any case, here is a reduced test case: The issue is in related to PR 48858; I think the code is valid on most 32bit (e.g. x32-gnu-linux, i386-gnu-linux) systems. I also find the standard a bit confusing, but I think it is supposed to be valid - cf. bug 48858 comment 9. Regarding the specific issue: integer(c_int), value :: value vs. type(c_ptr), value :: value On a 64 bit system it is invalid as int (integer(c_int),value) is a 32 bit value and void* (type(c_ptr),value) is a 64 bit pointer. If value is supposed to be a pointer address, it should use integer(c_intptr_t). I think that's the case as I find SQLPOINTER ValuePtr in the references to SQLSetEnvAttr.
[Bug fortran/55475] heap-buffer-overflow in fortran/error.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55475 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-26 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-26 21:59:32 UTC --- Draft patch: --- a/gcc/fortran/scanner.c +++ b/gcc/fortran/scanner.c @@ -1070,6 +1070,8 @@ restart: int maxlen = gfc_option.free_line_length; + gfc_char_t *current_nextc = gfc_current_locus.nextc; + gfc_current_locus.lb-truncated = 0; - gfc_current_locus.nextc += maxlen; + gfc_current_locus.nextc = gfc_current_locus.lb-line + maxlen; gfc_warning_now (Line truncated at %L, gfc_current_locus); - gfc_current_locus.nextc -= maxlen; + gfc_current_locus.nextc = current_nextc; }
[Bug fortran/55476] Bogus warning Pointer might outlive the pointer target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55476 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-26 Summary|[4.8 Regression] Bogus |Bogus warning Pointer |warning Pointer might |might outlive the pointer |outlive the pointer target |target Ever Confirmed|0 |1 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-26 22:06:53 UTC --- Well, the warning is perfectly correct: The pointer *might* outlive the target - it doesn't say that it has to ;-) The problem is that: lvalue-symtree-n.sym-attr.host_assoc is true. Draft patch: --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -3695,3 +3695,5 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue) || lvalue-symtree-n.sym-attr.function -|| lvalue-symtree-n.sym-attr.host_assoc +|| (lvalue-symtree-n.sym-attr.host_assoc + lvalue-symtree-n.sym-ns + != rvalue-symtree-n.sym-ns) || lvalue-symtree-n.sym-attr.use_assoc
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572
--- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-27
09:32:55 UTC ---
(In reply to comment #6)
Created attachment 28779 [details]
Patch to use libbacktrace
I have to apply the following patch on your patch in order to be able to
compile it. (MULTIBUILDTOP is empty here and the library is not in
/libbacktrace.)
--- libgfortran-backtrace-pr54572.diff.orig 2012-11-27 10:09:13 +0100
+++ libgfortran-backtrace-pr54572.diff 2012-11-27 10:12:05 +0100
@@ -51 +51 @@ index abc23cd..dd325bd 100644
-+-I$(MULTIBUILDTOP)/../libbacktrace \
++-I$(MULTIBUILDTOP)../libbacktrace \
Additionally, I wonder whether one should have:
--- a/Makefile.def
+++ b/Makefile.def
languages = { language=fortran;gcc-check-target=check-fortran;
lib-check-target=check-target-libquadmath;
+ lib-check-target=check-target-libbacktrace;
lib-check-target=check-target-libgfortran; };
languages = { language=java; gcc-check-target=check-java;
And in the same file, I wonder which of the following two is correct:
+dependencies = { module=all-target-libgfortran; on=all-target-libbacktrace; };
or
+dependencies = { module=configure-target-libgfortran;
on=all-target-libbacktrace; };
[Bug fortran/54572] Use libbacktrace library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-27 10:05:50 UTC --- After compiling comment 5 with my changes of comment 10, I get: Backtrace for this error: 0x2b9567c7ca0d _gfortrani_show_backtrace /projects/tob/gcc-git/gcc/libgfortran/runtime/backtrace.c:92 0x2b9567c7d017 _gfortrani_backtrace_handler /projects/tob/gcc-git/gcc/libgfortran/runtime/compile_options.c:129 0x2b95687503ef ??? ???:0 0x40086b __test_MOD_c /dev/shm/foo.f90:5 0x400847 __test_MOD_b /dev/shm/foo.f90:10 0x40081a __test_MOD_a /dev/shm/foo.f90:15 0x400897 bt /dev/shm/foo.f90:22 0x40092f main /dev/shm/foo.f90:20 And before (i.e with addr2line), I got: Backtrace for this error: #0 0x2AC1DC8D7AE7 #1 0x2AC1DC8D80F2 #2 0x2AC1DD3A43EF #3 0x40086B in __test_MOD_c at foo.f90:5 #4 0x400847 in __test_MOD_b at foo.f90:10 #5 0x40081A in __test_MOD_a at foo.f90:15 #6 0x400897 in bt at foo.f90:22
[Bug fortran/55476] Bogus warning Pointer might outlive the pointer target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55476 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-27 19:21:09 UTC --- Too simple patch. It won't work in the following case: module m integer, pointer :: p contains subroutine test integer, target :: t p = t contains subroutine sub() if (p /= 0) return end subroutine end subroutine end module m
[Bug fortran/55476] Bogus warning Pointer might outlive the pointer target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55476 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-27 19:23:34 UTC --- (In reply to comment #4) Too simple patch. It won't work in the following case: … and it shouldn't: That's actually a case where the warning is correct!
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #14 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-27 20:04:21 UTC --- (In reply to comment #13) class(child),allocatable :: infant allocate(infant,source=new_child()) ... the finalizer is called twice: Once at the end of the main program, and once through the _copy procedure (which is invoked by the ALLOCATE statement), I think. Not sure if this is the expected behavior. The invocation through the _copy wrapper is a bug for ALLOCATE. However, it's fine for a = b which invoke _copy. I believe _copy should use intent(inout) dst instead of intent(out) dest – and if needed (e.g. intrinsic assignment), _final should be called directly. Then one can also replace calloc and memset '\0' by a simple malloc. (Caveat: One should check that coarray components are properly handled; possibly, _copy also needs a coarray argument as _final has.) * * * Current FINAL-wrapper patch (submitted) - it is still preparatory and doesn't call finalization subroutines: http://gcc.gnu.org/ml/fortran/2012-11/msg00086.html See also draft patches at https://userpage.physik.fu-berlin.de/~tburnus/final/ and http://gcc.gnu.org/ml/fortran/2012-11/msg9.html
[Bug fortran/55476] [4.8 Regression] Bogus warning Pointer might outlive the pointer target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55476 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-27 22:20:49 UTC --- Author: burnus Date: Tue Nov 27 22:20:44 2012 New Revision: 193872 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193872 Log: 2012-11-27 Tobias Burnus bur...@net-b.de PR fortran/55476 * expr.c (gfc_check_pointer_assign): Fix check pointer-might-outlive-target check for host_assoc. 2012-11-27 Tobias Burnus bur...@net-b.de PR fortran/55476 * gfortran.dg/warn_target_lifetime_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55476] [4.8 Regression] Bogus warning Pointer might outlive the pointer target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55476 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-27 22:24:29 UTC --- FIXED on the 4.8 trunk. Thanks for the report!
[Bug fortran/55501] [F03] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-28 10:48:58 UTC --- (In reply to comment #2) type(MPI_Datatype) :: MPI_INTEGER = merge(MPI_Datatype(4), MPI_Datatype(8), .false.) The problem is related to having array PARAMETERs. For normal parameters, simply their value is stored in the .mod file and always inserted when used. For array parameters, a static array in read-only memory is created, which can then be accessed at run time. That avoids replicating the information several times. In addition, the expression is also stored in the .mod file. Especially if constructors are involved, the current compile-time simplification doesn't work that well. Additionally, the question is also whether it always makes sense to expand constructors if one wants to simplify code. In any case, there is room for improvement. See also PR 44856 and PR 51260. * * * In gfc_simplify_merge, the compiler gives up when the type is not an EXPR_CONSTANT: 3976 if (tsource-expr_type != EXPR_CONSTANT 3977 || fsource-expr_type != EXPR_CONSTANT 3978 || mask-expr_type != EXPR_CONSTANT) 3979return NULL; For the test case of this PR, one has an EXPR_STRUCTURE. Maybe replacing the check by calls to gfc_is_constant_expr() is sufficient.
[Bug fortran/55501] [F03] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-28 10:54:56 UTC --- (In reply to comment #5) +tsource-expr_type != EXPR_STRUCTURE) That's not okay: If you have integer, allocatable :: a(:), b(:) one has an EXPR_STRUCTURE for [a,b] but not a constant expression. One has to do a deep check. Well, gfc_is_constant_expr() is supposed to do this. (Or should gfc_check_init_expr be used? I always confuse the two. For F90/F95 it makes a difference, for F200x it doesn't, and gfortran's usage is a mess.)
[Bug fortran/55501] [F03] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-28 11:03:34 UTC --- (In reply to comment #7) - if (tsource-expr_type != EXPR_CONSTANT - || fsource-expr_type != EXPR_CONSTANT - || mask-expr_type != EXPR_CONSTANT) + if (mask-expr_type != EXPR_CONSTANT) return NULL; That makes sense: If mask is a constant scalar, tsource or fsource can be used. That patch is pre-approved. However, at some point one has also to simplify: MERGE([1,2],[11,22], [.true.,.false.]) and for that case, all arguments have to be gfc_is_constant_expr(). At least Fortran 2008 requires that the processor can do such a simplification. (One could also handle the special case that mask is an array of only .true. or only .false.)
[Bug fortran/55501] [F03] ICE using MERGE in constant expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501 --- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-28 14:54:33 UTC --- (In reply to comment #10) integer :: i(-1:1) = 0 print *, lbound(merge(i,i,.true.)) Without the patch, this prints: 1 And with the patch: -1 Makes perfectly sense: For lbound(array,dim): If ARRAY is a whole array and either ARRAY is an assumed-size array of rank DIM or dimension DIM of ARRAY has nonzero extent, LBOUND (ARRAY, DIM) has a value equal to the lower bound for subscript DIM of ARRAY. Otherwise the result value is 1. With whole array array component or array name without further quali cation (6.5.2) Thus lbound(i) is a whole-array, lbound(i(:)) or lbound(merge(i,i,.true)) is not. I think the simplest it to replace lbound (merge(i,i,.true.) by lbound( (i) ) [e-expr_type = EXPR_OP e-value.op.op == INTRINSIC_PARENTHESES]. Possibly only if expr_type == EXPR_VARIABLE as otherwise the INTRINSIC_PARENTHESES will hamper further optimization (unless -fno-protect-parens).
[Bug fortran/52161] Internal compiler errors with -fcheck=bounds in coarray tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52161 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-28 16:03:46 UTC --- Untested patch: --- a/gcc/fortran/trans-stmt.c +++ b/gcc/fortran/trans-stmt.c @@ -797,3 +797,3 @@ gfc_trans_sync (gfc_code *code, gfc_exec_op type) %d in SYNC IMAGES, - fold_convert (integer_type_node, se.expr)); + fold_convert (integer_type_node, images)); }
[Bug fortran/52161] Internal compiler errors with -fcheck=bounds in coarray tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52161 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-28 21:42:21 UTC --- Author: burnus Date: Wed Nov 28 21:42:17 2012 New Revision: 193908 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193908 Log: 2012-11-28 Tobias Burnus bur...@net-b.de PR fortran/52161 * trans-stmt.c (gfc_trans_sync): Fix bound checking. 2012-11-28 Tobias Burnus bur...@net-b.de PR fortran/52161 * coarray/sync_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/coarray/sync_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/52161] Internal compiler errors with -fcheck=bounds in coarray tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52161 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-28 21:57:53 UTC --- FIXED (on the 4.8 trunk). Thanks for the report!
[Bug fortran/52161] Internal compiler errors with -fcheck=bounds in coarray tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52161 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-29 08:43:57 UTC --- Author: burnus Date: Thu Nov 29 08:43:48 2012 New Revision: 193924 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193924 Log: 2012-11-28 Tobias Burnus bur...@net-b.de PR fortran/52161 * trans-stmt.c (gfc_trans_sync): Fix bound checking for -fcoarray=lib. 2012-11-28 Tobias Burnus bur...@net-b.de PR fortran/52161 * coarray/sync_3.f90: Extend test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray/sync_3.f90
[Bug fortran/55469] memory leak on read with istat.ne.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-11-29 AssignedTo|unassigned at gcc dot |burnus at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-29 11:39:40 UTC --- (In reply to comment #5) Memory leaks are still present for other choices of the string t. For instance t=. or t=./ is still causing memory leaks Missed a failure as it was hidden behind a function call (convert_real, in a different file). (In reply to comment #6) BTW, wrong PR number in that message. Both issues have been fixed in the new patch at: http://gcc.gnu.org/ml/fortran/2012-11/msg00092.html
[Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55539 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P4 CC||burnus at gcc dot gnu.org, ||jb at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|[4.8 Regression]|[4.8 Regression] |-fno-sign-zero may generate |-fno-sign-zero may generate |wrong formatted output |output with the wrong sign --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-11-30 21:47:55 UTC --- Janne, I think it is due to your commit for PR 52434, PR 48878, PR 38199, http://gcc.gnu.org/viewcvs?root=gccview=revrev=185433 (Rev. 185486, PR 52608 is a minor follow up, but not causing the problem.)
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-03 08:54:26 UTC --- Author: burnus Date: Mon Dec 3 08:54:18 2012 New Revision: 194075 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194075 Log: 2012-11-03 Tobias Burnus bur...@net-b.de PR fortran/37336 * class.c (finalizer_insert_packed_call): New static function. (finalize_component, generate_finalization_wrapper): Fix coarray handling and packing. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c
[Bug fortran/55475] heap-buffer-overflow in fortran/error.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55475 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-03 08:56:22 UTC --- Author: burnus Date: Mon Dec 3 08:56:11 2012 New Revision: 194076 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194076 Log: 2012-12-03 Tobias Burnus bur...@net-b.de PR fortran/55475 * scanner.c (gfc_next_char_literal): Fix setting locus to free_line_length for the error message. * error.c (show_locus): Fix potential out-of-bounds read. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/error.c trunk/gcc/fortran/scanner.c
[Bug fortran/55475] heap-buffer-overflow in fortran/error.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55475 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-03 09:59:41 UTC --- FIXED thanks for the report!
[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46897 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-03 10:02:05 UTC --- The patch of comment 9 fixes most of the issues. However, some are still left. Cf. http://gcc.gnu.org/ml/fortran/2012-11/msg00072.html
[Bug fortran/55574] [4.7/4.8 Regression] C binding access to c_ptr type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55574 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid, diagnostic Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-03 Target Milestone|--- |4.7.3 Summary|c binding access to c_ptr |[4.7/4.8 Regression] C |type|binding access to c_ptr ||type Ever Confirmed|0 |1 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-03 15:39:49 UTC --- (In reply to comment #1) Starting at revision 181425, the test compiles without error. That's the constructor patch (= generic function name might be the same as a derived-type name) for PR 39427 / PR 37829, http://gcc.gnu.org/viewcvs?root=gccview=revrev=181425
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 --- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-03 21:13:50 UTC --- Author: burnus Date: Mon Dec 3 21:13:42 2012 New Revision: 194104 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194104 Log: 2012-12-03 Tobias Burnus bur...@net-b.de Janus Weil ja...@gcc.gnu.org PR fortran/37336 * class.c (gfc_is_finalizable): New function. * gfortran.h (gfc_is_finalizable): Its prototype. * module.c (mio_component): Read initializer for vtype's _final. * resolve.c (resolve_fl_derived0): Call gfc_is_finalizable. * trans-expr.c (gfc_vtable_final_get): New function. (conv_parent_component_references): Fix comment. (gfc_conv_variable): Fix for scalar coarray components. * trans-intrinsic.c (conv_intrinsic_move_alloc): For BT_CLASS, pass the BT_CLASS type and not the declared type to gfc_deallocate_scalar_with_status. * trans.h (gfc_vtable_final_get): New prototype. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans.h
[Bug fortran/55593] [4.8 Regression] Bogus error on passing DO LOOP variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55593 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Keywords||diagnostic, rejects-valid Last reconfirmed||2012-12-04 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 Summary|Bogus error on passing DO |[4.8 Regression] Bogus |LOOP variable |error on passing DO LOOP ||variable Target Milestone|--- |4.8.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-04 14:49:14 UTC --- 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, 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.
[Bug fortran/55591] strict-aliasing Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-04 17:05:45 UTC --- Untested (but successfully compiled) patch: --- a/gcc/fortran/options.c +++ b/gcc/fortran/options.c @@ -170,4 +170,6 @@ gfc_init_options (unsigned int decoded_options_count, set_default_std_flags (); + flag_strict_aliasing = -1; + /* Initialize cpp-related options. */ gfc_cpp_init_options (decoded_options_count, decoded_options); @@ -275,4 +277,8 @@ gfc_post_options (const char **pfilename) gfc_option.flag_whole_file = 1; + /* By default use strict-aliasing semantics. */ + if (flag_strict_aliasing == -1) +flag_strict_aliasing = 1; + /* Fortran allows associative math - but we cannot reassociate if we want traps or signed zeros. Cf. also flag_protect_parens. */
[Bug libfortran/55601] libgfortran build fails with --disable-libquadmath
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55601 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-05 08:52:25 UTC --- If you don't want libgfortran to use libquadmath, you should also disable the READ(16) support in the frontend by configuring with: --disable-libquadmath-support I think the proper solution for this PR is to add a libgfortran configure check which fails with: Cannot find libquadmath but the compiler has been compiled with REAL(16) support. Ensure that libquadmath is available or configure GCC with --disable-libquadmath-support
[Bug fortran/55534] -Wno-missing-include-dirs does not work with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
||tkoenig at gcc dot gnu.org
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-05
09:29:08 UTC ---
(See PR 54033 for the patch which originally added this feature.)
Untested patch.
--- a/gcc/fortran/cpp.c
+++ b/gcc/fortran/cpp.c
@@ -471,2 +471,3 @@ gfc_cpp_post_options (void)
cpp_option-preprocessed = gfc_option.flag_preprocessed;
+ cpp_option-warn_missing_include_dirs =
gfc_option.warn_missing_include_dirs;
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index bf767b2..6f3515f 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2236,2 +2236,3 @@ typedef struct
int warn_target_lifetime;
+ int warn_missing_include_dirs;
int max_errors;
diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c
index e05b935..489d1ff 100644
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -117,2 +117,3 @@ gfc_init_options (unsigned int decoded_options_count,
gfc_option.warn_target_lifetime = 0;
+ gfc_option.warn_missing_include_dirs = 0;
gfc_option.max_errors = 25;
@@ -478,2 +485,3 @@ set_Wall (int setting)
gfc_option.warn_target_lifetime = setting;
+ gfc_option.warn_missing_include_dirs = setting;
@@ -686,2 +694,6 @@ gfc_handle_option (size_t scode, const char *arg, int
value,
+case OPT_Wmissing_include_dirs:
+ gfc_option.warn_missing_include_dirs = value;
+ break;
+
case OPT_Wrealloc_lhs:
diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c
index 765c0f9..2bdd87f 100644
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@ -327,4 +327,3 @@ add_path_to_list (gfc_directorylist **list, const char
*path,
{
- /* FIXME: Also support -Wmissing-include-dirs. */
- if (warn)
+ if (warn gfc_option.warn_missing_include_dirs)
gfc_warning_now (Nonexistent include directory \%s\, path);
[Bug fortran/55603] Memory leak in intrinsic assignment of a scalar allocatable function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-05 CC||burnus at gcc dot gnu.org Summary|Memory leak in intrinsic|Memory leak in intrinsic |assignment of allocatable |assignment of a scalar |derived type function |allocatable function result |result | Ever Confirmed|0 |1 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-05 10:00:09 UTC --- The issue seems to only occur with scalars. Generated code a = *bar (); Expected: One uses a temporary as in tmp = bar (); a = *tmp; free (tmp); The same issue occurs with reallocate LHS, were also a temporary should be used. [Check that the allocation/freeing is properly done for variables with length type parameter (currently only deferred-length CHARACTER strings).]
[Bug fortran/55603] Memory leak in intrinsic assignment of a scalar allocatable function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-05 10:14:03 UTC --- (In reply to comment #1) The problem seems to be that we fail to do auto-deallocation of the function result (after the assignment). One should check the standard, if and where this is actually demanded. Nowhere. It only falls into the category quality of implementation. But a reasonable place would be after the place where finalization would occur. Btw, this will also be important for the future FINAL implementation. Yes, after the function has evaluated, its result has to be finalized. I think it should be as following: tmp = bar(); final_wrapper (a); ! must be after bar() a = *tmp; final_wrapper (*tmp); free (tmp); With an allocatable LHS it gets messier due to the length type parameter (and shape). In addition, it seems as if one had always to finalize the LHS in an intrinsic assignment while the (re)allocation is only allowed if the shape doesn't match. From F2008, 4.5.6.3 When finalization occurs: If an executable construct references a function, the result is finalized after execution of the innermost executable construct containing the reference. When an intrinsic assignment statement is executed, the variable is finalized after evaluation of expr and before the definition of the variable. By the way, the latter implies that a temporary variable has to be used if there is a finalizer and the RHS doesn't return a pointer/allocatable. Otherwise one had to finalize the LHS before evaluating the RHS expr.
[Bug fortran/55534] -Wno-missing-include-dirs does not work with gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-06 00:04:34 UTC --- (In reply to comment #3) I addition to the patch in comment #2 tried: That piece I also had, but I forgot to include it in the diff. (I have too many patches on that tree. Now the above warning is gone, but some piece is still missing... * The -I/foo/bar might come before -Wno-missing-include-dirs in gfc_handle_option; thus, the warning in add_path_to_list doesn't trigger. * With the patch and the warning activated, the compiler crashes in gcc/incpath.c's remove_duplicates for cur-name == /no/such/dir.
[Bug fortran/55618] New: [4.6/4.7/4.8 Regression] Failures with ISO_Varying_String test suite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55618 Bug #: 55618 Summary: [4.6/4.7/4.8 Regression] Failures with ISO_Varying_String test suite Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: pa...@gcc.gnu.org The test suite is available at http://quatramaran.ens.fr/~coudert/gfortran/vst.tar.bz2 The following test succeed with GCC 4.4 and fail with GCC 4.5/4.6/4.7/4.8. As all versions use - here - the same libgfortran, the bug is in the compiler itself. a) gfortran iso_varying_string.f90 auxmod.f95 Vst17.f95 *ERROR* elemental SPLIT(string_array,word_array,CHAR(set),separator_array) set=ic} back=absent b) gfortran iso_varying_string.f90 auxmod.f95 vst30.f95 *ERROR* elemental REPLACE(string_array,CHAR(target),substring_array) element= 1 1 result=-?( 3) exp.reslt=- ++'$?( 8) etc. c) gfortran iso_varying_string.f90 auxmod.f95 vst31.f95 *ERROR* elemental REPLACE(char_array,CHAR(target),subchar_array) element= 1 1 result=?36/*#837= ( 40) exp.reslt=8,/ ++'$= = ( 71) etc.
[Bug fortran/55618] [4.6/4.7/4.8 Regression] Failures with ISO_Varying_String test suite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55618 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-07 21:13:57 UTC --- Created attachment 28898 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28898 Test case (still depends on the iso_varying_string module) Slightly reduced test case - still needs the iso_varying_string module. Compiling with 4.4/4.8 and 4.8/4.4 shows that the attached file miscompiled while the big iso_varying_string module is correctly handled. If one compares the dump between 4.4 and 4.8 for the second (the array) SPLIT call, one finds for 4.4 and 4.8, respectively: split_ch (strar[S.14 + D.1624], wrdar[S.14 + D.1625], D.1621, separ[S.14 + D.1626], 0B, MAX_EXPR D.1616, 0); split_ch (strar[S.14 + D.1624], wrdar[S.14 + D.1625], D.1621, separ[S.14 + D.1626], 0B, MAX_EXPR D.1616, 0); Note the before D.1621. The latter is: character(kind=1)[1:MAX_EXPR D.1616, 0] * pstr.12; D.1964 = set; D.1619 = __builtin_malloc () char_auto (pstr.12, MAX_EXPR D.1616, 0, D.1964); pstr.12 = (character(kind=1)[1:MAX_EXPR D.1616, 0] *) D.1619; The called function is defined as: elemental subroutine split_CH (string, word, set, separator, back) type(varying_string), intent(inout) :: string type(varying_string), intent(out) :: word character(LEN=*), intent(in):: set type(varying_string), intent(out), optional :: separator logical, intent(in), optional :: back
[Bug fortran/55636] [4.8 Regression] Fortran name mangling collides with user namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55636 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-10 08:12:39 UTC --- See thread starting at http://gcc.gnu.org/ml/fortran/2012-10/msg6.html
[Bug libfortran/55601] libgfortran build fails with --disable-libquadmath
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55601 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-10 08:41:36 UTC --- Hmm, seemingly, the check ignores --disable-libquadmath-support by only testing for C's __float support, cf. libgfortran/acinclude.m4's LIBGFOR_CHECK_FLOAT128. gfortran itself is checked via libgfortran/acinclude.m4's LIBGFOR_WORKING_GFORTRAN. One probably should augment the C test by a Fortran REAL(16) test. Additionally, one could directly honour --disable-libquadmath-support, which I think is also passed to libgfortran's configure. Regarding the --disable-libquadmath combined with --enable-libquadmath-support: Some warning would be useful, but the question is how to trigger it.
[Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-10 08:57:04 UTC --- Can you pin-point which version causes the regression? BIT_SIZE(m) is (correctly) 64 while ma is (wrongly) 0. And NOT returns the bitwise Boolean inverse of I. Can you run the following code? It matches the failing code but contains some debugging printout. Can you also try kind=4? That seems to work while kind=8 seems to fail. integer(kind=8) m, ma ma = 0 m = 0 print '(m =,i21,z17, ma=,i2,z13)', m, m, ma, ma m = not(m) print '(m =,i21,z17, ma=,i2,z13)', m, m, ma, ma do while ( (m.ne.0) .and. (ma.lt.127) ) ma = ma + 1 m = ishft(m,-1) print '(m =,i21,z17,, ma=,i2,z13)', m, m, ma, ma end do print *, BIT_SIZE(m), ma if (BIT_SIZE(m) /= ma) error stop end
[Bug fortran/55618] [4.6/4.7/4.8 Regression] Failures with ISO_Varying_String test suite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55618 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-10 09:45:45 UTC --- Reduced test case: module m implicit none type t character :: str(11) end type t interface char module procedure char_auto end interface char contains pure function char_auto (string) result (char_string) type(t), intent(in) :: string character(LEN=size(string%str)) :: char_string integer :: i_char forall(i_char = 1:size(string%str)) char_string(i_char:i_char) = string%str(i_char) end forall end function char_auto elemental subroutine split_CH (string, set) type(t), intent(inout) :: string character(LEN=*), intent(in):: set integer :: i do i = 1, min(len(set),size(string%str)) string%str(i) = set(i:i) end do end subroutine split_CH end module m use m type(t) :: mdt, mdt2(2),setdt mdt%str = ['H', 'e', 'l', 'l', 'o', ' ', 'W','o', 'r', 'l', 'd'] mdt2 = [ mdt, mdt ] setdt%str = ['F', 'o', 'r', 't', 'r', 'a', 'n','R', 'u', 'l', 'z'] call split_CH(mdt2, char(setdt)) print '(11a)', mdt2(1)%str print '(11a)', mdt2(2)%str if (any (mdt2(1)%str /= setdt%str)) call abort () if (any (mdt2(2)%str /= setdt%str)) call abort () end
[Bug fortran/55638] New: Wrongly accepts INTENT + VALUE - and wrongly requires it for PURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55638 Bug #: 55638 Summary: Wrongly accepts INTENT + VALUE - and wrongly requires it for PURE Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: accepts-invalid, rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org C558 An entity with the VALUE attribute shall not have the ALLOCATABLE, INTENT (INOUT), INTENT(OUT), POINTER, or VOLATILE attributes. (F2008) C1276 The specification-part of a pure function subprogram shall specify that all its nonpointer dummy data objects have the INTENT (IN) or the VALUE attribute. However, gfortran allows to combine INTENT with VALUE. Additionally, for PURE (and PURE ELEMENTAL) procedures, it even requires the INTENT besides the VALUE. Namely: elemental subroutine foo(x,y) 1 Error: Argument 'y' of elemental procedure 'foo' at (1) must have its INTENT specified elemental subroutine foo(x,y) integer, intent(inout) :: x !integer, VALUE, INTENT(in) :: y integer, VALUE :: y x = y end subroutine foo
[Bug fortran/55618] [4.6/4.7/4.8 Regression] Failures with ISO_Varying_String test suite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55618
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.6.4
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-10
11:43:34 UTC ---
In trans-expr.c's gfc_conv_procedure_call, one calls:
3997else if (se-ss se-ss-info-useflags)
3998 {
...
4007if (ss-dimen 0 e-expr_type == EXPR_VARIABLE
4008 ss-info-data.array.ref == NULL)
...
4016else
4017 gfc_conv_expr_reference (parmse, e);
* * *
Even shorter example. Note the VALUE attribute (cf. PR55638 for the wrong
INTENT(IN)):
integer :: A(3)
call foo(a, f())
print *, a
contains
elemental subroutine foo(x,y)
integer, intent(inout) :: x
integer, VALUE, intent(in) :: y
x = y
end subroutine foo
function f()
integer :: f
f = 42
end function f
end
[Bug fortran/55362] [4.6/4.7/4.8 Regression] ICE with size() on character pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55362
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
CC||burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-11
14:46:03 UTC ---
Untested patch. However, I think we need to do more. I think it won't cover the
DIM= argument and other intrinsics are presumably also affected.
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -3593,4 +3593,11 @@ gfc_try
gfc_check_size (gfc_expr *array, gfc_expr *dim, gfc_expr *kind)
{
+ if (array-ts.type == BT_PROCEDURE)
+{
+ gfc_error ('%s' argument of '%s' intrinsic at %L may not be a
procedure,
+gfc_current_intrinsic_arg[0]-name, gfc_current_intrinsic,
+array-where);
+ return FAILURE;
+}
if (array_check (array, 0) == FAILURE)
return FAILURE;
[Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55539 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-12 11:16:33 UTC --- (In reply to comment #3) Strangely enough I needed to add some epsilon to 0.5 so that the second test passes, because the exact value 0.5 appears to get rounded down to 0 in formatted output. That should depend on the rounding mode; you have the choice between RD (round down), RC (compatible), RN (nearest), RP (processor dependent), RU (round up), RZ (round towards zero). The default (RD) in gfortran is NEAREST, which has to match IEEE 754-1985 (alias IEC 60559:1989), namely (cf. Note 10.14 in Fortran 2008): On processors that support IEEE rounding on conversions, the I/O rounding modes COMPATIBLE and NEAREST will produce the same results except when the datum is halfway between the two representable values. In that case, NEAREST will pick the even value, but COMPATIBLE will pick the value away from zero. The I/O rounding modes UP, DOWN, and ZERO have the same e ect as those speci ed in IEC 60559:1989 for round toward +oo, round toward -oo, and round toward 0, respectively. And 0.5 rounded to even rounds down to 0 and not up to 1. (Seemingly, decimal 0.5 is exactly representable in binary FP while decimal 0.1 isn't.)
[Bug c++/55664] New: Missing diagnostic dependent using declaration resolved to type without 'typename'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55664
Bug #: 55664
Summary: Missing diagnostic dependent using declaration
resolved to type without 'typename'
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: accepts-invalid, diagnostic
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
The following code is rejected by CLANG with:
test.cxx:17:24: error: dependent using declaration resolved to type
without 'typename'
using super_t::base_type;
^
I think the error is correct, but g++ doesn't diagnose it.
namespace std
{
namespace thrust
{
template typename Derived
class iterator_adaptor { typedef Derived base_type; };
template typename Derived
struct pointer_base_base {
typedef thrust::iterator_adaptor Derived type;
};
template typename Derived
class pointer_base : public pointer_base_base Derived :: type
{
typedef typename pointer_base_base Derived :: type super_t;
using super_t::base_type;
};
template unsigned int DummyParameterToAvoidInstantiation
void mymalloc (thrust::pointer_base void ) { };
}
}
[Bug fortran/55638] Wrongly accepts INTENT + VALUE - and wrongly requires it for PURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55638 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-14 16:56:59 UTC --- Fortran 2008 Corr 1 has the following wording; otherwise, the intent would be needed for IMPURE ELEMENTAL: C1290a The specification-part of an elemental subprogram shall specify the intents of all of its dummy arguments that do not have the VALUE attribut As C558 implies, VALUE, INTENT(IN) is okay; the value+intent check works correctly (cf. symbol.c). Sorry for claiming otherwise. Patch: http://gcc.gnu.org/ml/fortran/2012-12/msg00082.html
[Bug fortran/55638] Wrongly accepts INTENT + VALUE - and wrongly requires it for PURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55638 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-15 23:25:41 UTC --- Author: burnus Date: Sat Dec 15 23:25:36 2012 New Revision: 194525 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194525 Log: 2012-12-16 Tobias Burnus bur...@net-b.de PR fortran/55638 * resolve.c (resolve_formal_arglist): Allow VALUE without INTENT for ELEMENTAL procedures. 2012-12-16 Tobias Burnus bur...@net-b.de PR fortran/55638 * gfortran.dg/elemental_args_check_3.f90: Update dg-error. * gfortran.dg/elemental_args_check_7.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/elemental_args_check_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/elemental_args_check_3.f90
[Bug fortran/55638] Wrongly accepts INTENT + VALUE - and wrongly requires it for PURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55638 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-16 10:54:36 UTC --- FIXED on the 4.8 trunk.
[Bug fortran/55197] Use statement for omp_lib causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55197 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-16 14:36:58 UTC --- Author: burnus Date: Sun Dec 16 14:36:54 2012 New Revision: 194537 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194537 Log: 2012-12-16 Tobias Burnus bur...@net-b.de PR fortran/55197 * module.c (gfc_use_module): Free rename list only for internally generated intrinsic modules. 2012-12-16 Tobias Burnus bur...@net-b.de PR fortran/55197 * gfortran.dg/gomp/use_intrinsic_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/gomp/use_intrinsic_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55197] Use statement for omp_lib causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55197 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-16 14:38:34 UTC --- FIXED for GCC 4.8 (trunk). Thanks for the bugreport!
[Bug fortran/54818] [4.7/4.8 Regression] error: type mismatch in binary expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54818 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-17 20:57:19 UTC --- Untested patch: --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -2207 +2207,3 @@ gfc_conv_concat_op (gfc_se * se, gfc_expr * expr) -lse.string_length, rse.string_length); +lse.string_length, +fold_convert (TREE_TYPE (lse.string_length), + rse.string_length)); @@ -2234,0 +2237 @@ gfc_conv_concat_op (gfc_se * se, gfc_expr * expr) +
[Bug fortran/55732] New: -fno-automatic: Doesn'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55732 Bug #: 55732 Summary: -fno-automatic: Doesn' Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org subroutine foo(i) integer :: i integer, allocatable :: j if (i == 1) j = 42 if (.not. allocated (j)) call abort () if (j /= 42) call abort () end call foo(1) call foo(2) end
[Bug fortran/55733] New: -fno-automatic: Fails for scalar allocatables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55733 Bug #: 55733 Summary: -fno-automatic: Fails for scalar allocatables Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org -fno-automatic implies SAVE. However, it doesn't work for scalar allocatables: subroutine foo(i) integer :: i integer, allocatable :: j if (i == 1) j = 42 if (.not. allocated (j)) call abort () if (j /= 42) call abort () end call foo(1) call foo(2) end
[Bug fortran/55733] -fno-automatic: Fails for scalar allocatables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55733 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-18 15:20:40 UTC --- *** Bug 55732 has been marked as a duplicate of this bug. ***
[Bug fortran/55732] -fno-automatic: Doesn'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55732 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-18 15:20:40 UTC --- Stupid bugzilla! *** This bug has been marked as a duplicate of bug 55733 ***
[Bug fortran/55733] -fno-automatic: Fails for scalar allocatables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55733
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-18
15:24:16 UTC ---
The following test case also fails; I think the problem is the string
components which isn't marked as TREE_STATIC:
! { dg-do run }
! { dg-options -fno-automatic }
!
subroutine foo()
logical, save :: first = .false.
character(len=:), allocatable :: str(:)
if (first) then
if (allocated (str)) call abort ()
str = [ABCDEF, ABCDEF ]
end if
if (.not. allocated (str)) call abort ()
if (len (str) /= 6) call abort ()
if (any (str(:)(1:6) /= ABCDEF)) call abort ()
end subroutine foo
call foo()
call foo()
end
[Bug fortran/55735] New: ICE with deferred-length strings in COMMON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735 Bug #: 55735 Summary: ICE with deferred-length strings in COMMON Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org I think the following test case it valid. In any case, an ICE is a bug. Vaguely related is PR 55733. block data character(len=:), pointer :: str(:) common /foo/ str end block data subroutine bar() character(len=:), pointer :: str common /foo/ str ! print *, len(str), ''//str//'' !ICE in gfc_conv_intrinsic_len print '(3a)', '',str(1:6),'' ! ICE in gfc_conv_variable end character(len=:), pointer :: str(:) common /foo/ str allocate (character(len=6) :: str(1)) str = ABCDEF call bar() end
[Bug fortran/55733] -fno-automatic: Fails for scalar allocatables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55733 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-18 15:59:28 UTC --- Maybe for BLOCK DATA something similar has to be done. Cf. PR 55735.
[Bug fortran/55735] ICE with deferred-length strings in COMMON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-18 16:06:14 UTC --- Postscript: The example in comment 0 mixes a scalar and an array pointers. While the ICE occurs with either, the declaration should be consistent.
[Bug fortran/55729] Problem with sum intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55729 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-18 16:12:59 UTC --- Works for me with GCC 4.1 to 4.8: It compiles without any warning/error on x86-64-linux. What exactly is your GCC 4.7 version and which platform are you using? (gfortran -v shows this data. For instance, I used 4.7.2 20120920 [gcc-4_7-branch revision 191568] on x86_64-gnu-linux.) GCC 4.7.0 can is either the 4.7.0 version, released on 2012-03-22, or to any developer version between 2011-03-14 and that date. You could additionally re-check whether a newer GCC 4.7 or current GCC 4.8 fixes the issue.
[Bug fortran/55735] ICE with deferred-length strings in COMMON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-18 20:04:12 UTC --- (In reply to comment #2) (In reply to comment #1) Postscript: The example in comment 0 mixes a scalar and an array pointers. While the ICE occurs with either, the declaration should be consistent. I could be wrong, but I believe that the program in comment 0 is invalid. Mixing scalars and arrays is invalid. But as written, the same ICE occurs if one has only arrays or only scalars (which I intended but didn't post). And do I believe the program(s) is (are) valid in that case. I doubt that it is possible to catch the rank mismatch Well, the compiler does warn that the named common blocks have a different size.
[Bug fortran/54818] [4.7/4.8 Regression] error: type mismatch in binary expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54818 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-19 09:03:46 UTC --- My patch is wrong. It might lead to passing an integer(8) instead of integer(4) as hidden argument when calling a procedure. The proper way it to use gfc_charlen_type_node. However, the following works: --- a/gcc/fortran/trans-intrinsic.c +++ b/gcc/fortran/trans-intrinsic.c @@ -5664,3 +5664,3 @@ scalar_transfer: se-expr = tmpdecl; - se-string_length = dest_word_len; + se-string_length = fold_convert (gfc_charlen_type_node, dest_word_len); }
[Bug fortran/55733] -fno-automatic: Fails for scalar allocatables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55733 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-19 09:21:20 UTC --- Author: burnus Date: Wed Dec 19 09:21:17 2012 New Revision: 194604 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194604 Log: 2012-12-19 Tobias Burnus bur...@net-b.de Jakub Jelinek ja...@redhat.com Janus Weil ja...@gcc.gnu.org PR fortran/55636 PR fortran/55733 * gfortran.h (GFC_PREFIX): Define. * trans-decl.c (gfc_create_string_length): For VAR_DECLs that will be TREE_STATIC, use GFC_PREFIX to mangle the names. Handle -fno-automatic (gfc_trans_deferred_vars): Don't free variables SAVEd via -fno-automatic. 2012-12-19 Tobias Burnus bur...@net-b.de PR fortran/55733 * gfortran.dg/save_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/save_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55636] [4.8 Regression] Fortran name mangling collides with user namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55636 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-19 09:21:21 UTC --- Author: burnus Date: Wed Dec 19 09:21:17 2012 New Revision: 194604 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194604 Log: 2012-12-19 Tobias Burnus bur...@net-b.de Jakub Jelinek ja...@redhat.com Janus Weil ja...@gcc.gnu.org PR fortran/55636 PR fortran/55733 * gfortran.h (GFC_PREFIX): Define. * trans-decl.c (gfc_create_string_length): For VAR_DECLs that will be TREE_STATIC, use GFC_PREFIX to mangle the names. Handle -fno-automatic (gfc_trans_deferred_vars): Don't free variables SAVEd via -fno-automatic. 2012-12-19 Tobias Burnus bur...@net-b.de PR fortran/55733 * gfortran.dg/save_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/save_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55733] -fno-automatic: Fails for scalar allocatables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55733 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-19 09:26:46 UTC --- FIXED on the trunk (4.8).
[Bug fortran/55636] [4.8 Regression] Fortran name mangling collides with user namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55636 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-19 09:28:12 UTC --- FIXED on the trunk (4.8). The mangling now uses: #if !defined (NO_DOT_IN_LABEL) # define GFC_PREFIX(x) _F. x #elif !defined (NO_DOLLAR_IN_LABEL) # define GFC_PREFIX(x) _F$ x #else # define GFC_PREFIX(x) _F_ x #endif
[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2012-12-19 Resolution|FIXED | Ever Confirmed|0 |1 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-19 18:20:10 UTC --- First: I think one should add a pass to frontend-passes.c, similar to doloop_code. The reason is that resolve comes too early for some checks. Quoting from resolve.c: /* If a PRIVATE variable is used in the specification expression of the result variable, it might be accessed from outside the module and can thus not be TREE_PUBLIC() = 0. TODO: sym-attr.public_used only has to be set for the result variable's type-parameter expression and not for dummies or automatic variables. Additionally, it only has to be set if the function is either PUBLIC or used in a generic interface or TBP; unfortunately, proc_name-attr.public_used can get set at a later stage. */ Secondly, a reducted test case for the FoX issue of comment 7 is the following: module m private public :: foo interface foo module procedure bar end interface foo contains pure function mylen() integer :: mylen mylen = 42 end function mylen subroutine bar(x) character(len=mylen()) :: x end subroutine bar end module m The following line in resolve.c's resolve_function should take care of setting the public_use attribute, but it doesn't work: 3128 if (sym specification_expr sym-attr.function 3129 gfc_current_ns-proc_name 3130 gfc_current_ns-proc_name-attr.flavor == FL_MODULE) 3131sym-attr.public_used = 1; The reason is that (gdb) p gfc_current_ns-proc_name-name $6 = 0x76725fe0 bar
[Bug fortran/55733] -fno-automatic: Fails for scalar allocatables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55733 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-19 23:05:54 UTC --- Author: burnus Date: Wed Dec 19 23:05:49 2012 New Revision: 194621 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194621 Log: 2012-12-19 Tobias Burnus bur...@net-b.de PR fortran/55733 * trans-decl.c (gfc_create_string_length): Avoid setting TREE_STATIC for automatic variables with -fno-automatic. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c
[Bug fortran/54818] [4.7/4.8 Regression] error: type mismatch in binary expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54818 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-20 08:13:29 UTC --- Author: burnus Date: Thu Dec 20 08:13:21 2012 New Revision: 194628 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194628 Log: 2012-12-20 Tobias Burnus bur...@net-b.de PR fortran/54818 * trans-intrinsic.c (gfc_conv_intrinsic_transfer): Ensure that the string length is of type gfc_charlen_type_node. 2012-12-20 Tobias Burnus bur...@net-b.de PR fortran/54818 * gfortran.dg/transfer_intrinsic_4.f: New. Added: trunk/gcc/testsuite/gfortran.dg/transfer_intrinsic_4.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55745] [4.8 regression] FAIL: gfortran.dg/pr26246_2.f90 -O scan-tree-dump-times original static int 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55745 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-20 08:15:52 UTC --- CLOSE AS FIXED. (In reply to comment #1) Confirmed, cris-elf too. Authors in ChangeLog entry CC:ed. The bug fix is older than the bug report ;-) I believe it has been fixed by the following commit. Sorry for the breakage. Date: Wed Dec 19 23:05:49 2012 New Revision: 194621 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194621 Log: 2012-12-19 Tobias Burnus bur...@net-b.de PR fortran/55733 * trans-decl.c (gfc_create_string_length): Avoid setting TREE_STATIC for automatic variables with -fno-automatic. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c
[Bug fortran/54818] [4.7/4.8 Regression] error: type mismatch in binary expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54818 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-20 10:48:15 UTC --- Author: burnus Date: Thu Dec 20 10:48:11 2012 New Revision: 194632 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194632 Log: 2012-12-20 Tobias Burnus bur...@net-b.de PR fortran/54818 * trans-intrinsic.c (gfc_conv_intrinsic_transfer): Ensure that the string length is of type gfc_charlen_type_node. 2012-12-20 Tobias Burnus bur...@net-b.de PR fortran/54818 * gfortran.dg/transfer_intrinsic_4.f: New. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/transfer_intrinsic_4.f Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/54818] [4.7/4.8 Regression] error: type mismatch in binary expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54818 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-20 10:50:47 UTC --- FIXED on the 4.8 trunk and the 4.7 branch. (4.6 does not seem to be affected and 4.5/4.6 aren't maintained anymore.) Thanks for the bug report!
[Bug fortran/55758] New: LOGICAL and BIND(C): Reject kind=2/4/8/16 with -std=f2008, improve warning, switch to nonBOOLEAN_TYPE for those
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55758 Bug #: 55758 Summary: LOGICAL and BIND(C): Reject kind=2/4/8/16 with -std=f2008, improve warning, switch to nonBOOLEAN_TYPE for those Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org See http://gcc.gnu.org/ml/fortran/2012-12/threads.html#00135 In the Fortran standard, only LOGICALs of kind C_BOOL interoperate with C; namely, with C99's _Bool/bool. In C, also integers - in particular int - are used in Boolean expressions, allows for the whole range of integral values - all are true except for 0 which is false. gcc's _Bool and gfortran's LOGICAL all assume a binary state (BOOLEAN_TYPE) which is either 0 or 1 such that .NOT. can be implemented by flipping a single bit. Hence, regarding an int as BOOLEAN_TYPE leads to .NOT.(-1) = -2. Currently, LOGICAL(kind=C_INT) (c_int == 4) is accepted by gfortran and C binding, but it might lead to wrong results with .NOT. Expected: * With -std=f95/f2003/f2008/f2008tr, only LOGICAL with kind=C_BOOL (C_BOOL == 1) is accepted * With -std=gnu, also the others (2,4,8,16) are accepted but a warning is printed for them. * Consider replacing internally BOOLEAN_TYPE by a signed-integer type LOGICAL with kind /= C_BOOL in procedures with C binding
[Bug fortran/55756] [4.8 regression] FAIL: gfortran.dg/same_type_as_1.f03 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55756 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-12-20 CC||burnus at gcc dot gnu.org AssignedTo|unassigned at gcc dot |pault at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-20 15:28:54 UTC --- Side effect of the patch http://gcc.gnu.org/ml/fortran/2012-12/msg00115.html - hence assigned to Paul. The dg-error string hadn't been updated after the message has been improved. Sorry for the breakage.
[Bug fortran/55762] New: Diagnostic: Passing a procedure to LEN should tell that one has passed a procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55762 Bug #: 55762 Summary: Diagnostic: Passing a procedure to LEN should tell that one has passed a procedure Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Reported at http://gcc.gnu.org/ml/fortran/2012-12/msg00145.html s is declared as CHARACTER, but it is also used as s(i), hence, it is marked as function. That leads to the error message: n = len(s) 1 Error: 'string' argument of 'len' intrinsic at (1) must be CHARACTER It would be more helpful to state that S is a function (procedure) in this case - as NAG or g95 do: Error: Argument STRING to the LEN intrinsic is a procedure Type of argument 'string' in call to 'len' at (1) should be CHARACTER(1), not PROCEDURE
[Bug fortran/55763] New: Issues with some simpler CLASS(*) programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55763 Bug #: 55763 Summary: Issues with some simpler CLASS(*) programs Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: pa...@gcc.gnu.org There are some known bigger issues of CLASS(*) which are tracked elsewhere. This is about simpler issues. The following program by Reinhold Bader fails with a bogus: type is (integer) 1 alloc_scalar_01_pos.f90:27.15: class default 2 Error: The DEFAULT CASE at (1) cannot be followed by a second DEFAULT CASE at (2) ! module mod_alloc_scalar_01 contains subroutine construct(this) class(*), allocatable, intent(out) :: this integer :: this_i this_i = 4 allocate(this, source=this_i) end subroutine end module program alloc_scalar_01 use mod_alloc_scalar_01 implicit none class(*), allocatable :: mystuff call construct(mystuff) call construct(mystuff) select type(mystuff) type is (integer) if (mystuff == 4) then write(*,*) 'OK' else write(*,*) 'FAIL 1' end if class default write(*,*) 'FAIL 2' end select end program ! While the following program by the same author causes an ICE (segmentation fault) at 0x5573ac get_unique_type_string ../../gcc/fortran/class.c:447 0x557ef8 get_unique_hashed_string ../../gcc/fortran/class.c:470 0x558087 gfc_find_derived_vtab(gfc_symbol*) ../../gcc/fortran/class.c:1833 0x625d18 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vectree_node*, va_gc, vl_embed*) ../../gcc/fortran/trans-expr.c:4308 ! module mod_alloc_scalar_02 contains subroutine construct(this) class(*), allocatable, intent(out) :: this integer :: this_i this_i = 4 allocate(this, source=this_i) end subroutine subroutine out(this) class(*) :: this select type(this) type is (integer) if (this == 4) then write(*,*) 'OK' else write(*,*) 'FAIL 1' end if class default write(*,*) 'FAIL 2' end select end subroutine end module program alloc_scalar_02 use mod_alloc_scalar_02 implicit none class(*), allocatable :: mystuff call construct(mystuff) call out(mystuff) end program ! And the following MOVE_ALLOC code, which moves TYPE(integer) to CLASS(*) fails with: call move_alloc(i2, i1) 1 Error: The FROM and TO arguments of the MOVE_ALLOC intrinsic at (1) must be of the same kind 4/0 ! program mvall_03 implicit none integer, parameter :: n1 = 100, n2 = 200 class(*), allocatable :: i1(:) integer, allocatable :: i2(:) allocate(real :: i1(n1)) allocate(i2(n2)) i2 = 2 call move_alloc(i2, i1) if (size(i1) /= n2 .or. allocated(i2)) then write(*,*) 'FAIL' else write(*,*) 'OK' end if end program ! And finally, the following program - again by Reinhold Bader - gives an ICE (segfault) at vector_comp = field 0x62d477 gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*) ../../gcc/fortran/trans-expr.c:6523 ! program change_field_type use, intrinsic :: iso_c_binding implicit none TYPE, BIND(C) :: scalar_vector REAL(kind=c_float) :: scalar REAL(kind=c_float) :: vec(3) END TYPE TYPE, BIND(C) :: scalar_vector_matrix REAL(kind=c_float) :: scalar REAL(kind=c_float) :: vec(3) REAL(kind=c_float) :: mat(3,3) END TYPE CLASS(*), ALLOCATABLE, TARGET :: one_d_field(:) real, pointer :: v1(:) allocate(one_d_field(3), source = (/ scalar_vector( 1.0, (/ -1.0, 0.0, 1.0 /) ), scalar_vector( 1.1, (/ -1.2, 0.2, 0.9 /) ), scalar_vector( 1.2, (/ -1.4, 0.4, 0.8 /) ) /) ) call extract_vec(one_d_field, 1, v1, 2) print *, v1 deallocate(one_d_field) ! v1 becomes undefined allocate(one_d_field(1), source = (/ scalar_vector_matrix( 1.0, (/ -1.0, 0.0, 1.0 /), reshape( (/ 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0 /), (/3, 3/) ) ) /) ) call extract_vec(one_d_field, 2, v1, 1) print *, v1 deallocate(one_d_field) ! v1 becomes undefined contains subroutine extract_vec(field, tag, vector_comp, ic) use, intrinsic :: iso_c_binding
[Bug fortran/55763] Issues with some simpler CLASS(*) programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55763 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-20 16:30:23 UTC --- Another follow up: The following code causes an ICE (segfault): 0x5989bc select_type_set_tmp ../../gcc/fortran/match.c:5299 0x5a0015 gfc_match_type_is() ../../gcc/fortran/match.c:5556 If one changes the commented lines, one gets the bogus error message: type is (integer) 1 Error: Assumed shape array at (1) must be a dummy argument ! module mpi_f08_f implicit none abstract interface subroutine user_function( inoutvec ) class(*), dimension(:), intent(inout) :: inoutvec end subroutine user_function end interface end module module mod_test use mpi_f08_f implicit none contains subroutine my_function( invec ) ! ICE ! subroutine my_function( inoutvec ) ! BOGUS ERROR class(*), dimension(:), intent(inout) :: inoutvec select type (inoutvec) type is (integer) inoutvec = 2*inoutvec end select end subroutine my_function end module !
[Bug fortran/55765] New: Remaining issues with unlimited polymorphic (CLASS(*))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55765
Bug #: 55765
Summary: Remaining issues with unlimited polymorphic (CLASS(*))
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: pa...@gcc.gnu.org
Depends on: 55763
Issues related to CLASS(*)
- Smaller bugs, cf. PR 55763
- As mentioned in the submittal email,
http://gcc.gnu.org/ml/fortran/2012-12/msg00090.html
Some parts of the code, relating to the handling of intrinsic
expressions, are near duplicates of exiting code for derived types;
for example class.c( gfc_find_intrinsic_vtab). I did this in order to
maximise the separation of the treatment of unlimited polymorphism
from existing code in the compiler in order that the risk of
regression be minimised. This new code can be absorbed later on; eg.
gfc_find_intrinsic_vtab into gfc_find_derived_vtab.
- CLASS(*) currently doesn't handle nonconstant strings. Currently, for each
string a new __vtab is generated which encodes the string length. The proper
way is to store the information in the variable itself. There are two
possibilities: (a) Either extend the class container to store this information
(b) Use an array descriptor or similar to store this information
(b) requires the new array descriptor and is in line of TR 29113:2012, where at
least for strings the full array descriptor is passed (with BIND(C)), cf.
ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1942.pdf See 8.7, (6) (b) and (c) and
8.3 - in particular size_t elem_len which together with the type (char(kind=1
or 4)) can be used to determine the length.
(a) requires an additional field in the class container. In principle, it could
come last, but that will prevent the extension of the rank. Currently, one has
{ _data, _vtpr } and for assumed-rank, one passes a max-rank (rank-7) array to
make sure the offset to _vptr is correct. With {_vptr, _data}, the last item
could remain the actual size; but with {_vptr, _data, int string_len } that
won't work. Cf. PR 53971.
[Bug fortran/55765] Remaining issues with unlimited polymorphic (CLASS(*))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55765 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-21 10:52:51 UTC --- One probably should audit all calls to gfc_find_derived_vtab whether also CLASS(*) could occur in that context; e.g. TRANSFER comes into my mind.
[Bug fortran/55763] Issues with some simpler CLASS(*) programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55763 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2012-12-21 Resolution|FIXED | Ever Confirmed|0 |1 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-21 14:42:56 UTC --- REOPEN. 'Only' the two issues of the follow up (comment 1) are fixed. None of the 4 issues of comment 0. (Additionally MOVE_ALLOC for two CLASS(*) variables fails, which I hadn't tested before.) (In reply to comment #3) Fixed on trunk... Thanks for fixing the issues quickly! blow me if I did not remember to attribute the testcase properly. Blast! Well, you have still the chance to do so for the other test cases ;-)
[Bug fortran/55763] Issues with some simpler CLASS(*) programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55763 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-21 22:59:27 UTC --- To the last test case of comment 0: gives an ICE (segfault) at vector_comp = field 0x62d477 gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*) ../../gcc/fortran/trans-expr.c:6523 The problem is that the LHS is: expr1-symtree-n.sym-attr.subref_array_pointer The ICE occurs for: gfc_add_modify (lse.post, GFC_DECL_SPAN(decl), tmp); The problem is that DECL_LANG_SPECIFIC(decl) is NULL; hence, DECL_LANG_SPECIFIC(decl)-span causes the ICE. In principle, gfc_get_symbol_decl takes care of that. However, as the symbol is a dummy argument, the backend_decl is already set and gfc_get_symbol_decl returns early.
[Bug fortran/55763] Issues with some simpler CLASS(*) programs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55763 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-22 17:27:06 UTC --- Author: burnus Date: Sat Dec 22 17:27:03 2012 New Revision: 194696 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194696 Log: 2012-12-21 Tobias Burnus bur...@net-b.de PR fortran/55763 * module.c (mio_component): Don't skip _hash's initializer. * resolve.c (resolve_select_type): Add an assert. * trans-expr.c (gfc_conv_procedure_call): Handle INTENT(OUT) for UNLIMIT_POLY. 2012-12-21 Tobias Burnus bur...@net-b.de PR fortran/55763 * gfortran.dg/unlimited_polymorphic_6.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55789] Needless realloc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-12-22
CC||burnus at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-22
18:24:45 UTC ---
(In reply to comment #0)
In trying to understand some memory leak reported by mtrace (which turns out,
I think, to be a bug in glibc
http://sourceware.org/bugzilla/show_bug.cgi?id=14981)
Using GLIBC 2.17, no memleak is reported here for neither the C program nor
this PR's Fortran code.
I noticed that the following code
performs both an allocate and a reallocate in cp_1d_i4_sort.
Confirmed. With GCC 4.5, only a simple malloc is done; ltrace shows:
malloc(4)
but starting from GCC 4.6 both malloc and realloc are invoked; ltrace has:
malloc(4)
realloc(0xafbf90, 8)
With 4.8, one has (slightly simplified):
ubound.0 = (arr-dim[0].ubound - arr-dim[0].lbound) + 1;
atmp.4.dim[0].lbound = 0;
atmp.4.dim[0].ubound = ubound.0-1;
D.1907 = ubound.0 = 0 ? 0 : ubound.0 * 4;
atmp.4.data = __builtin_malloc (MAX_EXPR D.1907, 1);
...
D.1919 = MAX_EXPR(D.1918-dim[0].ubound - D.1918-dim[0].lbound) + 1, 0;
shadow_loopvar.7 = 1;
atmp.4.dim[0].ubound = atmp.4.dim[0].ubound
+ MAX_EXPR (D.1919 - shadow_loopvar.7) + 1, 0;
atmp.4.data = __builtin_realloc (atmp.4.data,
(atmp.4.dim[0].ubound + 1) * 4);
while (1)
{
if (shadow_loopvar.7 D.1919) goto L.1;
(*atmp.4.data)[offset.5] = shadow_loopvar.7;
offset.5 = offset.5 + 1;
shadow_loopvar.7 = shadow_loopvar.7 + 1;
}
L.1:;
[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-23 18:43:36 UTC --- Author: burnus Date: Sun Dec 23 18:43:32 2012 New Revision: 194706 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194706 Log: 2012-12-23 Tobias Burnus bur...@net-b.de PR fortran/54884 * module.c (write_symbol1_recursion): Set attr.public_use. * interface.c (check_sym_interfaces, check_uop_interfaces, gfc_check_interfaces): Remove attr.public_use code. * resolve.c (resolve_function, resolve_variable, resolve_typebound_procedure): Ditto. 2012-12-23 Tobias Burnus bur...@net-b.de PR fortran/54884 * gfortran.dg/public_private_module_8.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/public_private_module_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54884] [4.8 Regression] Externally used PRIVATE module procedure wrongly marked as TREE_PUBLIC()=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54884 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2012-12-23 18:44:52 UTC --- FIXED on the 4.8 trunk. Thanks Andrew for the report. (The new patch is much nicer: It's much shorter, should be more reliable and fixes also some missed-optimization cases :-)
