[Bug fortran/50404] New: SIGSEGV in gfc_resolve_close
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404 Bug #: 50404 Summary: SIGSEGV in gfc_resolve_close Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25280 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25280 just compile it SIGSEGV in gfc_resolve_close
[Bug fortran/50405] New: allocation LOOP or SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50405 Bug #: 50405 Summary: allocation LOOP or SIGSEGV Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25281 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25281 just compile it allocation LOOP or SIGSEGV
[Bug fortran/50406] New: ld undefined reference to __MOD_str
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50406 Bug #: 50406 Summary: ld undefined reference to __MOD_str Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25282 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25282 just compile and link ld undefined reference to __MOD_str
[Bug fortran/50407] New: compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 Bug #: 50407 Summary: compiler confused by .operator. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25283 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25283 just compile it compiler confused by .operator.
[Bug fortran/50408] New: ICE in transfer_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50408 Bug #: 50408 Summary: ICE in transfer_expr Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25284 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25284 just compile it ICE in transfer_expr
[Bug fortran/50409] New: SIGSEGV in gfc_simplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50409 Bug #: 50409 Summary: SIGSEGV in gfc_simplify_expr Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25285 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25285 just compile it SIGSEGV in gfc_simplify_expr
[Bug fortran/50410] New: ICE in record_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 Bug #: 50410 Summary: ICE in record_reference Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25286 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25286 just compile it ICE in record_reference
[Bug fortran/50411] New: gfortran -Ofast SIGSEGV in vect_recog_dot_prod_pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50411 Bug #: 50411 Summary: gfortran -Ofast SIGSEGV in vect_recog_dot_prod_pattern Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25287 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25287 please compile it with -Ofast gfortran -Ofast SIGSEGV in vect_recog_dot_prod_pattern
[Bug fortran/50412] New: gfortran -Ofast ICE in vect_do_peeling_for_loop_bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50412 Bug #: 50412 Summary: gfortran -Ofast ICE in vect_do_peeling_for_loop_bound Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25288 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25288 please compile it with -Ofast gfortran -Ofast ICE in vect_do_peeling_for_loop_bound
[Bug fortran/50415] New: gfortran -Ofast SIGSEGV in find_uses_to_rename_use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50415 Bug #: 50415 Summary: gfortran -Ofast SIGSEGV in find_uses_to_rename_use Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25291 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25291 please compile it with -Ofast gfortran -Ofast SIGSEGV in find_uses_to_rename_use
[Bug fortran/50414] New: gfortran -Ofast SIGSEGV in store_constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414 Bug #: 50414 Summary: gfortran -Ofast SIGSEGV in store_constructor Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25290 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25290 please compile it with -Ofast gfortran -Ofast SIGSEGV in store_constructor
[Bug fortran/50416] New: gfortran -O1 ICE MPFR assertion failed: 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50416 Bug #: 50416 Summary: gfortran -O1 ICE MPFR assertion failed: 0 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25292 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25292 please compile it with -O1 gfortran -O1 ICE MPFR assertion failed: 0 I have mpfr 2.4.2-1
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #2 from Vittorio Zecca zeccav at gmail dot com 2011-09-15 20:21:04 UTC --- I believe the code is valid, and it has nothing to do with recursive I/O. If you comment out the write in the mul function gfortran still fails, so it does not depend on recursive I/O. gfortran only fails on 2.ip.8 while it correctly recognizes i.ip.2 and i.ip.j, if you run the code commenting out print 2.ip.8 you get ok 6 ok 12 Oracle Solaris compiler sunf95 correctly compiles and run displaying ok 16 ok 6 ok 12 Remember 2.ip.8 must be a format string in this context.
[Bug fortran/50403] SIGSEGV in gfc_use_derived
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50403 --- Comment #4 from Vittorio Zecca zeccav at gmail dot com 2011-09-15 20:26:18 UTC --- I created it.
[Bug fortran/50426] New: gfortran -O1 ICE in estimate_function_body_sizes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50426 Bug #: 50426 Summary: gfortran -O1 ICE in estimate_function_body_sizes Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25297 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25297 Please compile it with -O1 gfortran -O1 ICE in estimate_function_body_sizes. Sorry this is a long and old fixed format code. Please compile it with -O1
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #4 from Vittorio Zecca zeccav at gmail dot com 2011-09-15 20:36:54 UTC --- I disagree, the Fortran 95 standard at R911 allows PRINT format and R913 says that format may be a default-char-expr Now, 2.ip.8 is a default character expression, or not? Again, the .ip. operator appears in a format, not in an output-item-list. g95 is wrong.
[Bug fortran/50403] SIGSEGV in gfc_use_derived
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50403 --- Comment #6 from Vittorio Zecca zeccav at gmail dot com 2011-09-16 07:12:52 UTC --- You asked where do I get such an enormous amount of invalid fortran code. Probably I was too terse in my answer. I created invalid codes to check corner or extreme cases. I do believe that to prevent is better than to cure.
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #11 from Vittorio Zecca zeccav at gmail dot com 2011-09-16 07:22:09 UTC --- If you add character(9) s s=2.ip.8 gfortran, and g95, compile successfully. On the contrary gfortran fails to parse write(6,fmt=2.ip.8) To me, it looks like the parser does not handle correctly the format specification as a default-char-expression defined in fortran 95 R913 By the way, the following fails as well, should I open a new bug? write(6,fmt=1_'()') Again, in my opinion, recursive I/O, allowed or not, has nothing to do with parsing format specifications.
[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #2 from Vittorio Zecca zeccav at gmail dot com 2011-09-18 17:38:10 UTC --- The following produces a Segmentation fault in gfc_conv_structure (r178925) type t integer g end type type(t) :: u=t(1) data u%g /2/ end
[Bug fortran/50514] New: gfortran should check ISHFT ISHFTC aruments (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50514 Bug #: 50514 Summary: gfortran should check ISHFT ISHFTC aruments (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran should check ISHFT ISHFTC aruments (r178939) ! gfortran should not accept SHIFTBIT_SIZE(I) print *,ishft(I=m,SHIFT=640) print *,ishftc(I=m,SHIFT=640) ! abs(SHIFT) must be = SIZE print *,ishftc(I=m,SHIFT=1,SIZE=0) end
[Bug fortran/50515] New: gfortran should not accept an external that is a common (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50515 Bug #: 50515 Summary: gfortran should not accept an external that is a common (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran should not accept an external that is a common (r178939) common/sub/ a external sub end
[Bug fortran/50516] New: gfortran must detect illegal statements in a block data (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50516 Bug #: 50516 Summary: gfortran must detect illegal statements in a block data (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran must detect illegal statements in a block data (r178939) block data common x ! illegal f(x)=x ! illegal interface end interface ! illegal 1 format() en
[Bug fortran/50517] New: gfortran must detect that actual argument type is different from dummy argument type (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50517 Bug #: 50517 Summary: gfortran must detect that actual argument type is different from dummy argument type (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran must detect that actual argument type is different from dummy argument type (r178939) module m type t integer g end type type u integer g end type end module program main use m interface subroutine sub(tfunction) use m ! this is a type(t) function type(t), external :: tfunction end subroutine end interface ! this is a type(u) function type(u), external :: ufunction call sub(ufunction) ! gfortran should emit an error message here end program
[Bug fortran/50524] New: *** glibc detected *** invalid free() pointer on illegal code (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50524 Bug #: 50524 Summary: *** glibc detected *** invalid free() pointer on illegal code (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com !*** glibc detected *** invalid free() pointer on illegal code (r178939) !*/home/vitti/gcc-trunk/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/f951: !*free(): invalid pointer: 0x0001 *** ! before compilation must export MALLOC_CHECK_=1 print *,'qwe'(1:1e0) end
[Bug fortran/50525] New: gfortran should not allow early reference to entry dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50525 Bug #: 50525 Summary: gfortran should not allow early reference to entry dummy argument (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran should not allow early reference to entry dummy argument (r178939) subroutine sub f(y)=x ! this is wrong entry e(x) end
[Bug fortran/50535] New: transformational intrinsic functions not allowed in statement functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50535 Bug #: 50535 Summary: transformational intrinsic functions not allowed in statement functions Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! transformational intrinsic functions not allowed in statement functions ! (r178939) logical g,l(2) ! gfortran should complain because all() is transformational g(x)=all(l) end
[Bug fortran/50536] New: an input item shall not appear as the do-variable of any io-implied-do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50536 Bug #: 50536 Summary: an input item shall not appear as the do-variable of any io-implied-do Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! an input item shall not appear as the do-variable of any io-implied-do ! gfortran should reject this one ! (r178939) read *,(l,l=1,2) end
[Bug fortran/50537] New: explicit interface required (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50537 Bug #: 50537 Summary: explicit interface required (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! explicit interface required (r178939) ! this program violates Fortran 95 12.3.1.1 number (2) letter (e) ! this program violates Fortran 2003 12.3.1.1 number (3) letter (c) ! this program violates Fortran 2008 12.4.2.2 number (3) letter (c) character(2) f print *,f(1) ! erroneous end character(n) function f(n) f='az' end
[Bug fortran/50538] New: formal argument cannot be same as procedure name (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50538 Bug #: 50538 Summary: formal argument cannot be same as procedure name (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! formal argument cannot be same as procedure name(r178939) subroutine sub entry e(sub) end
[Bug fortran/50539] New: Internal error gfc_match_entry(): Bad state (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50539 Bug #: 50539 Summary: Internal error gfc_match_entry(): Bad state (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! Internal error gfc_match_entry(): Bad state (r178939) function f entry e(f) end
[Bug fortran/50540] New: Internal Error: Can't convert UNKNOWN to INTEGER(4) (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50540 Bug #: 50540 Summary: Internal Error: Can't convert UNKNOWN to INTEGER(4) (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! Internal Error: Can't convert UNKNOWN to INTEGER(4) (r178939) implicit none integer i,dest(10) forall (i=2:ix) dest(i)=i end
[Bug fortran/50541] New: gfortran should not accept a pointer as a generic-name (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50541 Bug #: 50541 Summary: gfortran should not accept a pointer as a generic-name (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran should not accept a pointer as a generic-name (r178939) pointer s! gfortran should complain here interface s ! or here function f() ! this is the right place to specify the pointer attribute pointer f end function end interface end
[Bug fortran/50542] New: gfortran should detect violation of Fortran 95 R536 (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50542 Bug #: 50542 Summary: gfortran should detect violation of Fortran 95 R536 (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran should detect violation of Fortran 95 R536 (r178939) ! Fortran 2003 R528 ! Fortran 2008 R538 type t integer g end type type(t) u data (u%g,j=1,1) /1/! violates R536: data-i-do-object cannot be a scalar data (ii,j=1,1) /1/ ! ditto end
[Bug fortran/50546] New: gfortran should not accept missing operator (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50546 Bug #: 50546 Summary: gfortran should not accept missing operator (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran should not accept missing operator (r178939) module m interface assignment(=) end interface end module use m, only : operator(+) end
[Bug fortran/50547] New: dummy procedure argument of PURE shall be PURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50547 Bug #: 50547 Summary: dummy procedure argument of PURE shall be PURE Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! dummy procedure argument of PURE shall be PURE ! Fortran 95 12.6 at page 212 lines 23-24 ! Fortran 2003 C1269 ! Fortran 2008 C1279 pure function f(proc) interface function proc() end end interface end
[Bug fortran/50548] New: gfortran -fcheck=all run time would be nice to detect different shapes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50548 Bug #: 50548 Summary: gfortran -fcheck=all run time would be nice to detect different shapes Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! gfortran -fcheck=all run time would be nice to detect different shapes type t character,pointer :: c(:) end type type(t) :: u allocate(u%c(1)) u%c(1)='q' if(all(u%c==(/'q','w'/))) stop 'error' ! here end
[Bug fortran/50549] New: should detect different type parameters in structure constructors (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50549 Bug #: 50549 Summary: should detect different type parameters in structure constructors (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! should detect different type parameters in structure constructors (r178939) interface function f1() character(1),pointer :: f1 end end interface type t character(2), pointer :: p2 end type character(1), pointer :: p1 type(t) u u=t(p1)! different character length u=t(f1()) ! type parameters are different (Fortran 95 section 4.4.4) end
[Bug fortran/50550] New: does not recognize pointer variable at initialization (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550 Bug #: 50550 Summary: does not recognize pointer variable at initialization (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! does not recognize pointer variable at initialization (r178939) pointer pi,pr,pl,pc,pcmplx integer :: pi=null() real :: pr=null() logical :: pl=null() character :: pc=null() complex :: pcmplx=null() end
[Bug fortran/50551] New: Argumentless NULL() cannot be used with assumed-length dummy (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50551 Bug #: 50551 Summary: Argumentless NULL() cannot be used with assumed-length dummy (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! Argumentless NULL() cannot be used with assumed-length dummy (r178939) ! Fortran 95 corrigendum 2 page 91 line 41 interface subroutine sub(x) pointer x character(*) x end subroutine end interface call sub(null()) ! null() cannot be used with assumed length dummy argument end
[Bug fortran/50552] New: type name cannot be statement function dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50552 Bug #: 50552 Summary: type name cannot be statement function dummy argument (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! type name cannot be statement function dummy argument (r178939) type t real g end type f(t)=0 ! this should not be accepted end
[Bug fortran/50553] New: statement function cannot be target (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50553 Bug #: 50553 Summary: statement function cannot be target (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! statement function cannot be target (r178939) f(x)=x target f end
[Bug fortran/50554] New: INQUIRE cannot redefine DO index (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50554 Bug #: 50554 Summary: INQUIRE cannot redefine DO index(r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! INQUIRE cannot redefine DO index(r178939) do I=1,10 inquire(iolength=I) n end do end
[Bug fortran/50555] New: synonymous namelist/statement function dummy argument not allowed (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555 Bug #: 50555 Summary: synonymous namelist/statement function dummy argument not allowed (r178939) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! synonymous namelist/statement function dummy argument not allowed (r178939) namelist /i/ j f(i)=0 end
[Bug fortran/50556] New: cannot save namelist group name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50556 Bug #: 50556 Summary: cannot save namelist group name Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com ! cannot save namelist group name namelist /i/ ii save i end
[Bug fortran/50514] gfortran should check ISHFT ISHFTC aruments (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50514 --- Comment #2 from Vittorio Zecca zeccav at gmail dot com 2011-09-28 09:20:40 UTC --- I meant checking static expressions at compilation time, as in my example. This has no cost at run time. You proposed a run time check that still should be done if requested with a kind of -fcheck option. By the way, gfortran is already checking consistency of static arguments to intrinsic functions, it is that just these one are left unchecked.
[Bug fortran/50514] gfortran should check ISHFT ISHFTC aruments (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50514 --- Comment #4 from Vittorio Zecca zeccav at gmail dot com 2011-09-29 06:58:24 UTC --- About run time checking: I believe the bit size of k is known at compile time, and the overhead to check n against it is negligible as compared to computing ishft itself and maybe n. Of course when I am asking -fcheck I am prepared to slower execution, but it may well pay off, if I find a bug. I believe programmer (debugging) time is now costlier than hardware time.
[Bug fortran/50552] type name cannot be statement function dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50552 --- Comment #3 from Vittorio Zecca zeccav at gmail dot com 2011-10-18 13:55:31 UTC --- I am traveling in Korea, and I cannot look at the standard now. If you believe this is a non-issue then please close it.
[Bug testsuite/44343] New: malloc check in libstdc++-v3/testsuite/22_locale/codecvt/unshift/char/1.cc
Hi there, I have Fedora 13, just installed gcc 4.5.0 and running the make check command with export MALLOC_CHECK_=1 (or 2 or 3) I get the summary. This is at line 77 of 1.cc: delete [] c_arr; The malloc check message I receive is free(): invalid pointer I have no idea if it is a libstdc++ bug or just a bug in 1.cc. Can you please look into it? Best regards Vittorio Zecca -- Summary: malloc check in libstdc++- v3/testsuite/22_locale/codecvt/unshift/char/1.cc Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44343
[Bug fortran/44345] New: ICE in fold_convert_loc
The attached source provokes the summary: pointer p target q q(i)=i p=q(110) print *,p end Best regards Vittorio Zecca -- Summary: ICE in fold_convert_loc Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44345
[Bug fortran/44346] New: gfortran accepts illegal arguments to intrinsics
gfortran should not accept the following: character s,ss(1),pad(1),order(1) integer nn(7) c gfortran should complain that POS and LEN are negative print *,ibits(i,-1,-1) c POS+LENBIT_SIZE(i) print *,ibits(i,100,100) c 30+332 call mvbits(n,30,3,n,1) c 31+232 call mvbits(n,30,2,n,31) c LEN negative call mvbits(n,30,-2,n,30) c TOPOS negative call mvbits(n,30,2,n,-3) c FROMPOS negative call mvbits(n,-1,2,n,3) end Best regards Vittorio Zecca -- Summary: gfortran accepts illegal arguments to intrinsics Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44346
[Bug fortran/44347] New: gfortran segmentation violation in gfc_conv_scalarized_array_ref
The following provokes the summary: dimension ip(1),ir(1) print *,selected_real_kind(ip,i) print *,selected_real_kind(i,ir) end Best regards Vittorio Zecca -- Summary: gfortran segmentation violation in gfc_conv_scalarized_array_ref Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44347
[Bug fortran/44348] New: ICE in build_function_decl
The following provokes the summary: subroutine sub(ff) contains subroutine ff end subroutine end Best regards Vittorio Zecca -- Summary: ICE in build_function_decl Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44348
[Bug fortran/44349] New: ICE Bad IO basetype (1)
The following provokes the summary: print *,null() end Best regards Vittorio Zecca -- Summary: ICE Bad IO basetype (1) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44349
[Bug fortran/44350] New: accepts illegal fortran in BLOCK DATA
The following provokes the summary: block data common x c illegal f(x)=x c illegal interface end interface c illegal 1 format() end Best regards Vittorio Zecca -- Summary: accepts illegal fortran in BLOCK DATA Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44350
[Bug fortran/44351] New: ICE in gfc_assign_data_value_range
The following provokes the summary: INTEGER TYPE ( -20 : 20 , 0: 40 ) DATA TYPE /1681 * 5 / DATA TYPE( -20,0) / 7 / end Best regards Vittorio Zecca -- Summary: ICE in gfc_assign_data_value_range Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44351
[Bug fortran/44352] New: ICE in string_to_single_character
The following provokes the summary: implicit real*8 (a-h,o-z) character*32 ddname,dname dname(x)= 'h810 e=0.01 ' ddname=dname(0.d0) END Best regards Vittorio Zecca -- Summary: ICE in string_to_single_character Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44352
[Bug fortran/44353] New: rejects legal fortran
The following provokes the summary: subroutine sub(i) intent(in) i integer ii(10) data (ii(i),i=1,10) /10*0/ ! here the scope of i is the data statement end Best regards Vittorio Zecca -- Summary: rejects legal fortran Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44353
[Bug fortran/44354] New: incorrect output at run time
The following provokes the summary, must be compiled and run: c gfortran run time only displays 1 I=5 print *,(/(i,i=1,I)/) end Best regards Vittorio Zecca -- Summary: incorrect output at run time Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug fortran/44345] ICE in fold_convert_loc
--- Comment #2 from zeccav at gmail dot com 2010-05-31 18:37 --- Subject: Re: ICE in fold_convert_loc In that case gfortran should emit an error message, but it should not crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44345
[Bug fortran/44354] incorrect output at run time
--- Comment #9 from zeccav at gmail dot com 2010-05-31 21:37 --- Subject: Re: incorrect output at run time In my example 'i' is local to the array constructor, while 'I' is global and is initialized with value 5, so that the statement should display '1 2 3 4 5'. I agree that this is a pathological example, but still gfortran should follow the standard and output the correct data. 2010/5/31, mikael at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org: --- Comment #7 from mikael at gcc dot gnu dot org 2010-05-31 21:31 --- (In reply to comment #6) because in the above 'i' and 'I' are in the same scoping unit. I couldn't find what mandates in the standard that i and I are in a different scoping unit/are different variables. Are they ? If you write 'i = 5; j = [(i,i=1,I)]' then the 'i' here is in a different scoping unit. I agree that the scalar-int-expr '1' and 'I' need to be evaluated to establish the the loop start and stop values. The question again based on scoping unit is whether 'I' is uninitialized. How could it be ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug fortran/44360] New: gfortran gets confused by synonymous procedure names
The following provokes the summary, must be compiled and run: module m1 contains subroutine sub(pvec) dimension :: pvec(5) print *,'good compiler!' end subroutine end module m2 contains subroutine submain use m1 dimension :: qvec(5) call sub(qvec) ! here must call sub in module m1 end subroutine c subroutine sub(scal) ! if uncommented complains rank mismatch subroutine sub(vec) ! this one is mistakenly called dimension :: vec(5) print *,'bad compiler!' end subroutine end use m2 call submain end Best regards Vittorio Zecca -- Summary: gfortran gets confused by synonymous procedure names Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44360
[Bug c/44395] New: ICE verify_stmts failed with --enable-checking=yes
In the testsuite/gcc.dg compiling test cases pr34668-1.c and pr34668-2.c with options -combine -O2 with --enable-checking=yes I got an ICE as in the following: NOTICE --enable-checking=yes AND -O2 necessary for bug to appear [vitti gcc.dg]$gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/home/vitti/local/gcc-4.5.0/libexec/gcc/x86_64-redhat-linux/4.5.0/lto-wrapper Target: x86_64-redhat-linux Configured with: /home/vitti/gcc-4.5.0/configure --prefix=/home/vitti/local/gcc-4.5.0 --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=yes --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,fortran --enable-java-awt=gtk --disable-dssi --disable-lto --without-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.5.0 (GCC) [vitti gcc.dg]$gcc pr34668-1.c pr34668-2.c -c -combine [vitti gcc.dg]$gcc pr34668-1.c pr34668-2.c -c -combine -O0 [vitti gcc.dg]$gcc pr34668-1.c pr34668-2.c -c -combine -O1 [vitti gcc.dg]$gcc pr34668-1.c pr34668-2.c -c -combine -O [vitti gcc.dg]$gcc pr34668-1.c pr34668-2.c -c -combine -O2 pr34668-2.c: In function ‘set_conv_libfunc’: pr34668-2.c:5:15: error: type mismatch in array reference struct optab struct optab # .MEM_3 = VDEF .MEM_1(D) optab_table[0].code = 57005; pr34668-2.c:5:15: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Can you please look into it? Best regards Vittorio Zecca -- Summary: ICE verify_stmts failed with --enable-checking=yes Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44395
[Bug testsuite/44791] New: data_3.f90 accesses uninitialized variable
data_3.f90 IF statement at line 15 accesses B, but B(1:1) is undefined. -- Summary: data_3.f90 accesses uninitialized variable Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44791
[Bug testsuite/44792] New: data.f90 accesses undefined variable
data.f90 line 28 accesses TMP2(1)%T1(1)%A(2:4:2) which is undefined -- Summary: data.f90 accesses undefined variable Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44792
[Bug testsuite/44792] data.f90 accesses undefined variable
--- Comment #2 from zeccav at gmail dot com 2010-07-03 09:15 --- Subject: Re: data.f90 accesses undefined variable I believe it should be + if (any(tmp2(1)%t1(1)%a(1:3:2) .ne. (/111,113/))) call abort or (1:4:2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44792
[Bug testsuite/44797] New: INQUIRE EXIST variable must be default LOGICAL
INQUIRE_5.f90 lines 22, 26, and 28 use an EXIST variable which is not default LOGICAL. I believe this is not standard. Best regards Vittorio Zecca -- Summary: INQUIRE EXIST variable must be default LOGICAL Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44797
[Bug testsuite/44798] New: inconsistent interfaces
INTRINSIC_ASSOCIATED.f90 lines 38 and 124 are inconsistent. I believe the same array bounds should be specified. Best regards Vittorio Zecca -- Summary: inconsistent interfaces Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44798
[Bug testsuite/44799] New: MAX arguments should have same kind
INTRINSIC_MINMAX.f90 line 26 seems to me to have different kinds in MAX arguments. R has different kind from 4D0? Should it be MAX(r,4E0) ? What if in the same source you have MAX(real4var,4D0) and MAX(real8var,4E0) ? Best regards Vittorio Zecca -- Summary: MAX arguments should have same kind Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44799
[Bug testsuite/44797] INQUIRE EXIST variable must be default LOGICAL
--- Comment #5 from zeccav at gmail dot com 2010-07-08 14:49 --- Subject: Re: INQUIRE EXIST variable must be default LOGICAL By the way, the NUMBER variable must be default INTEGER as well. Do you agree there is the same problem as with the EXIST variable? Vittorio -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44797
[Bug testsuite/44873] New: array function not fully defined
In test case retarray.f90 at line 10 the array TEST is not fully defined. I propose to put TEST=0 at line 31 and FOO=0 at line 39. Best regards Vittorio Zecca -- Summary: array function not fully defined Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44873
[Bug testsuite/44922] New: undefined variable in execute/921202-1.c
It seems that at line 28 of execute/921202-1.c the variable cyx is used undefined. Can you look into it? Vittorio Zecca -- Summary: undefined variable in execute/921202-1.c Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44922
[Bug testsuite/44923] New: Access beyond array limit in execute/921202-1.c
It seems that at line 23 of execute/921202-1.c the array element dy[size] is accessed beyond thelimit of dy. This is because size=2055 and VLEN=2055. Can you look into this? Vittorio Zecca -- Summary: Access beyond array limit in execute/921202-1.c Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44923
[Bug testsuite/44873] array function not fully defined
--- Comment #2 from zeccav at gmail dot com 2010-07-25 22:14 --- Subject: Re: array function not fully defined The undefined elements of test are accessed at instruction a = test(6, 5) - a however. It is just that the code probably violates any Fortran standard. If the test case is fine with you it is fine with me, anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44873
[Bug fortran/61907] load of invalid value for 'bool' in trans-array.c trans_array_constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61907 --- Comment #3 from Vittorio Zecca zeccav at gmail dot com --- Same behaviour in 4.9.2 in trans-array.c line 2206 typespec_chararray_ctor = (expr-ts.u.cl expr-ts.u.cl-length_from_typespec); It seems length_from_typespec is wrong, OR the sanitizer -fsanitize=undefined is wrong. Trying the following: ! taken from pr43808.f90 type :: a integer, allocatable :: i(:) end type a type :: b type (a), allocatable :: j(:) end type b type(a) :: x(1) type(b) :: y(1) y(1) = b((/x(1)/)) end I get /home/vitti/gcc-4.9.2-sanitize/test/f951 p.f90 MAIN__../../gcc-4.9.2/gcc/fortran/trans-array.c:2206:44: runtime error: load of value 172, which is not a valid value for type 'bool' main Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups *free_inline_summary whole-program inlineAssembling functions: MAIN__ main
[Bug fortran/61907] load of invalid value for 'bool' in trans-array.c trans_array_constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61907 --- Comment #4 from Vittorio Zecca zeccav at gmail dot com --- Still in 5.1.0 at trans-array.c:2223
[Bug fortran/61908] load of invalid value for 'expr_t' in interface.c compare_actual_formal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61908 --- Comment #4 from Vittorio Zecca zeccav at gmail dot com --- Stiil in 5.1.0 at interface.c:2701
[Bug fortran/61908] load of invalid value for 'expr_t' in interface.c compare_actual_formal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61908 --- Comment #3 from Vittorio Zecca zeccav at gmail dot com --- I still have the same runtime error message in 4.9.2 Trying compilation of !from unlimited_polymorphic_16.f90 !../../gcc-4.9.2/gcc/fortran/interface.c:2667:43: runtime error: load of value 1818451807, which is not a valid value for type 'expr_t' contains subroutine FWRite(S) class(*) :: S end subroutine subroutine IO_OutputMargeStats() character tag call FWrite(tag) end subroutine end I get ./../gcc-4.9.2/gcc/fortran/interface.c:2667:43: runtime error: load of value 1818451807, which is not a valid value for type 'expr_t' MAIN__ __copy_character_1 io_outputmargestats fwrite main Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups *free_inline_summary whole-program inlineAssembling functions: __copy_character_1 MAIN__ main
[Bug fortran/58233] null pointer cm in gfc_conv_structure at fortran/trans-expr.c:6132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58233 --- Comment #3 from Vittorio Zecca zeccav at gmail dot com --- Still there on 4.9.2 at trans-expr.c:6193 if (!c-expr || (cm-attr.allocatable cm-attr.flavor != FL_PROCEDURE)) /home/vitti/gcc-4.9.2-sanitize/test/f951 p.f MAIN__ p.f:1:0: internal compiler error: in gfc_conv_structure, at fortran/trans-expr.c:6193 type t ^ 0x7c45c2 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc-4.9.2/gcc/fortran/trans-expr.c:6193 0x7c20c0 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc-4.9.2/gcc/fortran/trans-expr.c:5718 0x78e78f gfc_get_symbol_decl(gfc_symbol*) ../../gcc-4.9.2/gcc/fortran/trans-decl.c:1540 0x7a0846 generate_local_decl ../../gcc-4.9.2/gcc/fortran/trans-decl.c:4847 0x726945 do_traverse_symtree ../../gcc-4.9.2/gcc/fortran/symbol.c:3630 0x726a73 gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*)) ../../gcc-4.9.2/gcc/fortran/symbol.c:3655 0x7a178d generate_local_vars ../../gcc-4.9.2/gcc/fortran/trans-decl.c:5019 0x7a38ce gfc_generate_function_code(gfc_namespace*) ../../gcc-4.9.2/gcc/fortran/trans-decl.c:5595 0x75761d gfc_generate_code(gfc_namespace*) ../../gcc-4.9.2/gcc/fortran/trans.c:1945 0x6a2737 translate_all_program_units ../../gcc-4.9.2/gcc/fortran/parse.c:4953 0x6a2ebd gfc_parse_file() ../../gcc-4.9.2/gcc/fortran/parse.c:5150 0x7392c6 gfc_be_parse_file ../../gcc-4.9.2/gcc/fortran/f95-lang.c:212 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. Compiling type t integer g end type type(t) :: u=t(1) data u%g /2/ ! should emit diagnostic here end
[Bug c/67279] New: -fsanitize=undefined spurious error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67279
Bug ID: 67279
Summary: -fsanitize=undefined spurious error: initializer
element is not constant
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
/* gcc -fsanitize=undefined issues spurious error message */
/* OK without sanitizer */
/* Target: x86_64-unknown-linux-gnu */
void test(void)
{
int dec_good = 1 31; /* good */
static int dec_BAD = 1 31; /* error: initializer element is not constant*/
}
[Bug c/67279] -fsanitize=undefined spurious error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67279 --- Comment #2 from Vittorio Zecca zeccav at gmail dot com --- UB = undefined behaviour? Why then it is only signaled if static attribute is requested? This is accepted:int dec_1 = 1 31; Isn't UB as well if it is not static? I believe gcc should deliver a warning, and then a runtime error message at runtime. In other words codes that compile with gcc should still compile with -fsanitize=undefined This example comes from wine and it is annoying to recompile the codes that exhibit this error message. Also, the message is misleading, it should say that the initializer is undefined.
[Bug c/67279] -fsanitize=undefined spurious error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67279
--- Comment #3 from Vittorio Zecca zeccav at gmail dot com ---
The following code has UB at lines 4 and 5 but compiles with
-fsanitize=undefined
int main()
{
int test[1],t;
t=test[1];
return test[1];
}
Its execution it delivers four runtime errors from the sanitizer and I
am happy with that
ps.c:4:7: runtime error: index 1 out of bounds for type 'int [1]'
ps.c:4:2: runtime error: load of address 0x7ffcb21195f4 with
insufficient space for an object of type 'int'
0x7ffcb21195f4: note: pointer points here
e0 96 11 b2 fc 7f 00 00 00 00 00 00 00 00 00 00 70 07 40 00 00 00
00 00 e0 ff a1 0d 39 00 00 00
^
ps.c:5:12: runtime error: index 1 out of bounds for type 'int [1]'
ps.c:5:8: runtime error: load of address 0x7ffcb21195f4 with
insufficient space for an object of type 'int'
0x7ffcb21195f4: note: pointer points here
e0 96 11 b2 fc 7f 00 00 00 00 00 00 fc 7f 00 00 70 07 40 00 00 00
00 00 e0 ff a1 0d 39 00 00 00
In short: I like to see gcc -fsanitize=undefined to compile codes it
compiles without sanitation
[Bug rtl-optimization/61657] Undefined behavior in loop-iv.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61657
--- Comment #6 from Vittorio Zecca zeccav at gmail dot com ---
A shorter source file displaying the same bug:
// from pr42049.c
// gcc -funroll-loops -O
// ../../gcc-5.2.0/gcc/loop-iv.c:2670:14: runtime error:
// signed integer overflow: 7 - -9223372036854775808 cannot be represented in
type 'long int'
// loop-iv.c source line max = (uint64_t) (up - down) / inc + 1;
// Target: x86_64-unknown-linux-gnu
// COLLECT_GCC_OPTIONS='-funroll-loops' '-O' '-mtune=generic' '-march=x86-64'
void
foo (void)
{
long int i;
for (i = 1; i i 8; i++);
}
[Bug rtl-optimization/61657] Undefined behavior in loop-iv.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61657 --- Comment #8 from Vittorio Zecca zeccav at gmail dot com --- Maybe the easiest way to reproduce the issue is as in the following; gdb ~/local/gcc-5.2.0-sanitized/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1 GNU gdb (GDB) Fedora 7.8.2-39.fc21 Copyright (C) 2014 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-redhat-linux-gnu. Type show configuration for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type help. Type apropos word to search for commands related to word... Reading symbols from /home/vitti/local/gcc-5.2.0-sanitized/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1...done. (gdb) break ../../gcc-5.2.0/gcc/loop-iv.c:2671 Breakpoint 1 at 0x153209e: file ../../gcc-5.2.0/gcc/loop-iv.c, line 2671. (gdb) run gccerr14.c -O -quiet -funroll-loops Starting program: /home/vitti/local/gcc-5.2.0-sanitized/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1 gccerr14.c -O -quiet -funroll-loops Missing separate debuginfos, use: debuginfo-install glibc-2.20-8.fc21.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library /lib64/libthread_db.so.1. Breakpoint 1, iv_number_of_iterations (loop=0x2aaab633f360, insn=0x2aaab635e400, condition=0x2aaab6362d98, desc=0x7fffa810) at ../../gcc-5.2.0/gcc/loop-iv.c:2671 2671 max = (uint64_t) (up - down) / inc + 1; Missing separate debuginfos, use: debuginfo-install gmp-6.0.0-9.fc21.x86_64 libmpc-1.0.2-3.fc21.x86_64 mpfr-3.1.2-8.fc21.x86_64 (gdb) print up $1 = 7 (gdb) print down $2 = -9223372036854775808 But you need an unoptimized version of cc1
[Bug middle-end/64327] ../../gcc/gcc/rtlanal.c:4881:48: runtime error: shift exponent 4294967295 is too large for 64-bit type 'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64327 --- Comment #6 from Vittorio Zecca zeccav at gmail dot com --- I fixed this one by substituting rtlanal.c:4907 if (bitwidth HOST_BITS_PER_WIDE_INT ) with if (bitwidth HOST_BITS_PER_WIDE_INT || !bitwidth)
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 61943, which changed state. Bug 61943 Summary: tree-ssa-loop-ivopts.c:4148 signed integer overflow https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61943 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME
[Bug tree-optimization/61943] tree-ssa-loop-ivopts.c:4148 signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61943 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Vittorio Zecca zeccav at gmail dot com --- Just tried with gcc-5.2.0 and the bug has disappeared.
[Bug middle-end/64920] bootstrap-ubsan [build/gengtype -r gtype.state]: libiberty/regex.c:6970:11: runtime error: left shift of negative value -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64920 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #1 from Vittorio Zecca zeccav at gmail dot com --- I have the same messages during gcc 5.2.0 generation Fixing directory /usr/include into /home/vitti/gcc-5.2.0-sanitize-all/gcc/include-fixed ../../../gcc-5.2.0/libiberty/regex.c:6972:11: runtime error: left shift of negative value -1 ../../../gcc-5.2.0/libiberty/regex.c:7167:4: runtime error: left shift of negative value -1 Applying machine_name to slang.h I believe this is because at line 688 (destination) += SIGN_EXTEND_CHAR (*((source) + 1)) 8; (*((source) + 1)) is negateive (-1)
[Bug other/66827] [6 Regression] left shifts of negative value warnings due to C++14 switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66827 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #2 from Vittorio Zecca zeccav at gmail dot com --- The warnings in regex.c are already described in issue 64920
[Bug c/67338] New: fold-const sanitizer runtime error in roundup_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67338
Bug ID: 67338
Summary: fold-const sanitizer runtime error in roundup_loc
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
Running a sanitized version of gcc 5.2.0 I get the following:
// ../../gcc-5.2.0/gcc/fold-const.c:16036:8: runtime error: negation of
-2147483648 cannot be represented in type 'int'; cast to an unsigned type to
negate this value to itself
// fold-const.c:16036 val = - (int) divisor;
// int should be wide_int?
// Target: x86_64-unknown-linux-gnu
// COLLECT_GCC_OPTIONS='-mtune=generic' '-march=x86-64'
struct { __attribute__((aligned (1 28))) double a; };
[Bug tree-optimization/62058] Undefined behaviour in tree-data-ref.c with options -O1 -ftree-loop-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62058 --- Comment #4 from Vittorio Zecca zeccav at gmail dot com --- Still there in GCC 5.2.0
[Bug c++/50184] Segmentation fault. Copy Constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50184
Vittorio Zecca zeccav at gmail dot com changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment #4 from Vittorio Zecca zeccav at gmail dot com ---
I still have the same bug in g++ 5.2.0 in the following:
#include map
#include string
using namespace std;
struct CData
{
struct CItem
{
string m_str1;
};
mapstring, CItem m_map;
std::string m_strDFName;
int m_nDFMsgTimeout;
};
CData func()
{
CData data;
data.m_map[Test].m_str1 = Data;
return data;
}
class B : public CData
{
public:
B()
: CData(func())
{
std::string s;
mapstring, CItem::iterator it = m_map.begin();
for (; it != m_map.end(); it++) // loops past the end
{
s += it-second.m_str1 + it-first;;
}
}
};
int main()
{
B b1;
return 0;
}
[Bug c/67279] -fsanitize=undefined spurious error: initializer element is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67279 --- Comment #6 from Vittorio Zecca zeccav at gmail dot com --- On my side it has to do with the C standard. Compilation with -ansi or -std=c90 is successful. Compilation with -std=c99 fails. Compiling with g++ is OK. The behaviour I would like to see is a warning at compile time and a runtime error: message at run time.
[Bug sanitizer/65828] [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #6 from Vittorio Zecca zeccav at gmail dot com --- (In reply to Steven Noonan from comment #1) If you want a nice tarball with a ready-to-go repro case, I've put it here: https://www.uplinklabs.net/files/lto-65828.tar.xz Should just be able to run something like: $ /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto1 -quiet -dumpdir .libs/ -dumpbase libglib-2.0.so.0.4400.0.wpa -mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase libglib_2_0_la-gallocator -O2 -O2 -version -fno-trapv -fPIC -fltrans-output-list=libglib-2.0.so.0.4400.0.ltrans.out -fwpa -fresolution=libglib-2.0.so.res @ccWGeoup.args from inside the extracted directory and see the issue. I just run it with gcc-5.2.0 and I got the following error: ./repro.sh + /home/vitti/local/gcc-5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto1 -quiet -dumpdir .libs/ -dumpbase libglib-2.0.so.0.4400.0.wpa -mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase libglib_2_0_la-gallocator -O2 -O2 -version -fno-trapv -fPIC -fltrans-output-list=libglib-2.0.so.0.4400.0.ltrans.out -fwpa -fresolution=libglib-2.0.so.res @ccWGeoup.args GNU GIMPLE (GCC) version 5.2.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU GIMPLE (GCC) version 5.2.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 lto1: fatal error: bytecode stream generated with LTO version 3.0 instead of the expected 4.0 compilation terminated.
[Bug ipa/66896] ipa-prop.c:2479 runtime error: member call on null pointer of type 'struct ipa_polymorphic_call_context'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66896 --- Comment #13 from Vittorio Zecca zeccav at gmail dot com --- I see only two NULL dereferencing in ipa-prop.c my lines 2479 and 2545 same statement dst_ctx-combine_with (ctx); Did you take care of both of them?
[Bug fortran/44348] ICE in build_function_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44348 --- Comment #9 from Vittorio Zecca zeccav at gmail dot com --- No, it is not valid, but gfortran should signal this with an error message. Not with a crash.
[Bug fortran/66942] trans-expr.c:5701 runtime error: member call on null pointer of type 'struct vec'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66942 --- Comment #9 from Vittorio Zecca zeccav at gmail dot com --- I should have written that I tried it not only on the test case I sent but on the whole fortran testsuite in gcc/testsuite.
[Bug rtl-optimization/61657] Undefined behavior in loop-iv.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61657 --- Comment #5 from Vittorio Zecca zeccav at gmail dot com --- Just confirmed adding printf(up=%li down=%li up-down=%li\n, up,down,up-down); before line 2670. Output is up=123 down=-9223372036854775808 up-down=-9223372036854775685 You could probably get an ICE with gcc_assert(up-down0);
[Bug fortran/66942] trans-expr.c:5701 runtime error: member call on null pointer of type 'struct vec'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66942 --- Comment #7 from Vittorio Zecca zeccav at gmail dot com --- I confirm the patch works
[Bug rtl-optimization/61657] Undefined behavior in loop-iv.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61657
--- Comment #4 from Vittorio Zecca zeccav at gmail dot com ---
I am having the same problem in 5.2.0:
/* must be compiled with -O[1] -funroll-loops -foptimize-sibling-calls
-finline-small-functions */
/* target x86_64-unknown-linux-gnu */
/* Fedora 21 */
/*gcc-5.2.0/gcc/loop-iv.c:2670:25: runtime error: signed integer overflow: 123
- -9223372036854775808 cannot be represented in type 'long int'*/
/* source line max = (uint64_t) (up - down) / inc + 1; */
long level = 0;
extern long foo (void);
extern long bar (void);
long
foo (void)
{
long tmp = ++level;
return bar () + tmp;
}
long
bar (void)
{
long tmp = level;
return tmp 123 ? -42 - tmp : foo () - tmp;
}
[Bug ipa/66896] ipa-prop.c:2479 runtime error: member call on null pointer of type 'struct ipa_polymorphic_call_context'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66896 --- Comment #11 from Vittorio Zecca zeccav at gmail dot com --- I have a version of gcc 5.2.0 compiled with the -fsanitize=undefined option. This sanitized version gave me a runtime error due to dereferencing the pointer dst_ctx which was NULL. After the change I suggested the message disappeared. You may double check my finding, as I did myself, by putting assert(dst_ctx) before its dereferencing in ipa-prop.c as in assert(dst_ctx),dst_ctx-combine_with (ctx); It happens twice in isa-prop.c Then try it with the two C codes I sent, with option -O2
