[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org --- I disagree. DECL_SIZE and .size are IMHO correct here at this point, and component sizes (FIELD_DECL) can't match, because we shouldn't be changing the type of the decl to some other type just because it got an initializer. The bug is IMHO really just in miscounting the size of the padding of the initializer and thus emitting into the data/rodata etc. section more bytes of data from what .size/arrays/-fsection-anchors assumes. Outside of arrays on non-fsection-anchors target this is just ugly (except where you e.g. put the structs into named sections and use it as a kind of array say through beginning/end of the named section), for -fsection-anchors it is of course a wrong-code (well, wrong-data) bug.
[Bug lto/47888] [4.6 Regression] tree check: expected array_type, have record_type in array_ref_low_bound, at expr.c:6249 / Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47888 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org --- The things to do are to add the testcase to the testsuite and to close the PR.
[Bug target/55036] Compiler fails with message internal compiler error: in reg_save_code, at caller-save.c:158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55036 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.8.0 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- 2012-07-09 Steven Bosscher ste...@gcc.gnu.org * gensupport.c (init_rtx_reader_args_cb): Start counting code generating patterns from 1 to free up 0 for CODE_FOR_nothing. * gencodes.c (main): Give CODE_FOR_nothing the value 0. Add the LAST_INSN_CODE marker at the end. * genoutput.c (nothing): New static struct data. (idata): Initialize to nothing. (idata_end): Initialize to nothing.next. (init_insn_for_nothing): New function to create dummy 'nothing' insn. (main): Use it. * genpeep.c (insn_code_number): Remove global variable. (gen_peephole): Take it as an argument instead. (main): Take insn_code_number from read_md_rtx. * optabs.h: Revert r161809: (optab_handlers): Change type of insn_code back to insn_code. (optab_handler, widening_optab_handler, set_optab_handler, set_widening_optab_handler, convert_optab_handler, set_convert_optab_handler, direct_optab_handler, set_direct_optab_handler): Remove int casts. Revert to treating the insn_code field as insn_code.
[Bug fortran/58470] [4.9 Regression] [OOP] ICE on invalid with FINAL procedure and type extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58470 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[OOP] ICE on invalid with |[4.9 Regression] [OOP] ICE |FINAL procedure and type|on invalid with FINAL |extension |procedure and type ||extension --- Comment #2 from janus at gcc dot gnu.org --- I think the problem is that generate_finalization_wrapper is called before gfc_resolve_finalizers. I am marking this as a regression, since 4.8 gives the correct error message.
[Bug c++/58252] [4.9 Regression] ice in gimple_get_virt_method_for_binfo with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58252 Bug 58252 depends on bug 58585, which changed state. Bug 58585 Summary: [4.9 Regression] ICE in ipa with virtual inheritance http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226 Bug 59226 depends on bug 58585, which changed state. Bug 58585 Summary: [4.9 Regression] ICE in ipa with virtual inheritance http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/58585] [4.9 Regression] ICE in ipa with virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #22 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed, finally.
[Bug fortran/51637] Add compile-time error if array is too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51637 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-11 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Compiling the test with 4.7.4, 4.8.2, or 4.9.0 (no error with -Wall -Wextra at compile time) with -fcheck=all gives the following error at run time: At line 4 of file pr51637.f90 Fortran runtime error: Index '1' of dimension 1 of array 'a' above upper bound of -1
[Bug fortran/58470] [4.9 Regression] [OOP] ICE on invalid with FINAL procedure and type extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58470 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org --- The following patch fixes it and is free of testsuite regressions: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c(revision 206552) +++ gcc/fortran/resolve.c(working copy) @@ -12455,10 +12455,6 @@ resolve_fl_derived0 (gfc_symbol *sym) /* Add derived type to the derived type list. */ add_dt_to_dt_list (sym); - /* Check if the type is finalizable. This is done in order to ensure that the - finalization wrapper is generated early enough. */ - gfc_is_finalizable (sym, NULL); - return true; }
[Bug fortran/41143] Support DW_TAG_common_inclusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41143 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-11 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Any point to keep this PR open? IMO it should be closed as WONTFIX (over four years without any activity)?
[Bug fortran/58470] [4.9 Regression] [OOP] ICE on invalid with FINAL procedure and type extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58470 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- The following patch fixes it and is free of testsuite regressions: ... I am not sure (as in I am pretty sure) that the finalization coverage in the test suite (as well as in the real world) is enough. Removing a block which was clearly written on purpose makes me nervous.
[Bug fortran/57042] [4.7/4.8 Regression] ICE/Segfault with -fdump-parse-tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57042 --- Comment #7 from janus at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #4) Other functions returning characters have a bogus typespec: Huh. Problem with implicit typing? Adding 'implicit none' yields an unknown type for 'adjustl': Namespace: A-Z: (UNKNOWN 0) procedure name = main symtree: 'adjustl' || symbol: 'adjustl' type spec : (UNKNOWN 0) attributes: (PROCEDURE FUNCTION) result: adjustl symtree: 'main'|| symbol: 'main' type spec : (UNKNOWN 0) attributes: (PROGRAM PUBLIC SUBROUTINE) code: WRITE UNIT=6 FMT=-1 TRANSFER 'a ' DT_END
[Bug fortran/58470] [4.9 Regression] [OOP] ICE on invalid with FINAL procedure and type extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58470 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #4) The following patch fixes it and is free of testsuite regressions: ... I am not sure (as in I am pretty sure) that the finalization coverage in the test suite (as well as in the real world) is enough. That is probably true. Removing a block which was clearly written on purpose makes me nervous. Well, I guess all code is written on purpose. What makes me nervous is keeping code that serves no clear purpose. In particular the comment does not really clarify the question early enough for *what* ? Overall that line seems rather hackish to me. In any case it comes from: http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=194104
[Bug libstdc++/59687] The description of ios::noreplace is hilarious
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59687 Christopher Yeleighton giecrilj at stegny dot 2a.pl changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED |--- --- Comment #4 from Christopher Yeleighton giecrilj at stegny dot 2a.pl --- (In reply to Jonathan Wakely from comment #2) Author: redi Date: Fri Jan 10 14:30:27 2014 New Revision: 206525 trunk/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml You: Because iostream modes correspond to functionfopen(3)/function modes these flags are not supported. Me: The implication is 1⇒1, so this is formally valid. But correlation is not causation; in this case, you have (fopen (path, wx)) both implemented in GNU and standardised. So your statement is misleading, at least for (noreplace). You: If you need to check for existence and open a file as a single operation then you will need to use OS-specific facilities outside the C++ standard library, such as functionopen(2)/function Me: Maybe it would be worth mentioning how you can construct a stream from a file descriptor so as to avoid a resource leak (the constructor must not throw for this scheme to work). It seems (noreplace) is more important in practice than (nocreate). Now that it is standardised, could you consider providing (__noreplace) instead? See also URL: https://groups.google.com/a/isocpp.org/d/msg/std-proposals/I5z9QIo7KHU/D3eC_NRlMjMJ Meta: I admit the bug is sort-of fixed but still I tentatively reopen to see if you would reconsider the text given the remarks above. Please forgive me if it is too much disruption for you.
[Bug libstdc++/59687] The description of ios::noreplace is hilarious
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59687 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- I'm not spending any more time on documentation for features that we don't support, and that most compilers have not supported since last century. That chapter of the libstdc++ manual is not the place for people to learn how to write correct programs.
[Bug libstdc++/59687] The description of ios::noreplace is hilarious
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59687 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- And if you want to request __noreplace as an enhancement then please open a separate enhancement request.
[Bug libstdc++/59768] [4.8 Regression] std::thread constructor not handling reference_wrapper correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59768 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-01-11 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug plugins/59335] Plugin doesn't build on trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59335 --- Comment #7 from Uroš Bizjak ubizjak at gmail dot com --- Can someone please test following patch: --cut here-- Index: config/i386/t-i386 === --- config/i386/t-i386 (revision 206552) +++ config/i386/t-i386 (working copy) @@ -16,6 +16,9 @@ # along with GCC; see the file COPYING3. If not see # http://www.gnu.org/licenses/. +PLUGIN_HEADERS += $(srcdir)/config/i386/x86-tune.def \ + $(srcdir)/config/i386/stringop.def + i386-c.o: $(srcdir)/config/i386/i386-c.c i386-builtin-types.inc $(COMPILE) $ $(POSTCOMPILE) --cut here--
[Bug libstdc++/59769] New: please add ios_base::__noreplace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59769 Bug ID: 59769 Summary: please add ios_base::__noreplace Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: giecrilj at stegny dot 2a.pl This flag, combined with out or append should have the effect of (fopen (path, wx)). Now that the syntax (fopen (path, wx)) is standard, there is no excuse for denying the equivalent functionality to a C++ programmer.
[Bug libstdc++/59768] [4.8 Regression] std::thread constructor not handling reference_wrapper correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59768 --- Comment #1 from Casey Carter Casey at Carter dot net --- This behavior would appear to NOT be erroneous. I was operating under the assumption that the behavior of the std::thread constructor and std::bind were identical by design given that both use the INVOKE machinery defined by the standard in [func.require]/1. However, the replacement of reference_wrapperA with its stored reference is specified only for std::bind in [func.bind.bind]/10: The values of the bound arguments v1, v2, ..., vN and their corresponding types V1, V2, ..., VN depend on the types TiD derived from the call to bind and the cv-qualifiers cv of the call wrapper g as follows: — if TiD is reference_wrapperT, the argument is tid.get() and its type Vi is T; This would then not be a regression in the 4.8 line, but a correction to a long-standing bug. I apologize for wasting your time with an erroneous bug report.
[Bug bootstrap/59770] New: [4.9 Regression] bootstrap failure for arm-linux-gnueabi targeting armv4t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59770 Bug ID: 59770 Summary: [4.9 Regression] bootstrap failure for arm-linux-gnueabi targeting armv4t Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org trunk 20140111, arm-linux-gnueabi targeting armv4t ftbfs, arm-linux-gnueabihf targeting armv7 succeeds to build. configure -v --with-pkgversion='Debian 4.9-20140111-1' --with-bugurl='file:///usr/share/doc/gcc-4.9/README.Bugs' --enable-languages=c,c++,java,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armel/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armel --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armel --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-sjlj-exceptions --with-arch=armv4t --with-float=soft --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi make[5]: Entering directory `/home/doko/gcc/4.9/armel/gcc-4.9-4.9-20140111/build/gcc' build/genpreds -c ../../src/gcc/config/arm/arm.md tmp-constrs.h /bin/bash: line 1: 31819 Segmentation fault build/genpreds -c ../../src/gcc/config/arm/arm.md tmp-constrs.h make[5]: *** [s-constrs-h] Error 139 make[5]: Leaving directory `/home/doko/gcc/4.9/armel/gcc-4.9-4.9-20140111/build/gcc' make[4]: *** [all-stage3-gcc] Error 2 make[4]: Leaving directory `/home/doko/gcc/4.9/armel/gcc-4.9-4.9-20140111/build' make[3]: *** [stage3-bubble] Error 2 make[3]: Leaving directory `/home/doko/gcc/4.9/armel/gcc-4.9-4.9-20140111/build' make[2]: *** [bootstrap] Error 2
[Bug fortran/59700] [4.8/4.9 Regression] Misleading/buggy runtime error message: Bad integer for item 0 in list input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59700 --- Comment #20 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sat Jan 11 18:57:20 2014 New Revision: 206553 URL: http://gcc.gnu.org/viewcvs?rev=206553root=gccview=rev Log: 2014-01-11 Jerry DeLisle jvdeli...@gcc.gnu Dominique d'Humieres domi...@lps.ens.fr Steven G. Kargl ka...@gcc.gnu.org PR libfortran/59700 PR libfortran/59764 * io/io.h (struct st_parameter_dt): Assign expanded_read flag to unused bit. Define new variable line_buffer_pos. * io/list_read.c (free_saved, next_char, l_push_char, read_logical, read_real): Replace use of item_count with line_buffer_pos for line_buffer look ahead. (read_logical, read_integer, parse_real, read_real, check_type): Adjust location of free_line to after generating error messages to retain the correct item count for the message. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c
[Bug libfortran/59764] Read logicals, line buffer, item_count, and error message consistancy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59764 --- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sat Jan 11 18:57:20 2014 New Revision: 206553 URL: http://gcc.gnu.org/viewcvs?rev=206553root=gccview=rev Log: 2014-01-11 Jerry DeLisle jvdeli...@gcc.gnu Dominique d'Humieres domi...@lps.ens.fr Steven G. Kargl ka...@gcc.gnu.org PR libfortran/59700 PR libfortran/59764 * io/io.h (struct st_parameter_dt): Assign expanded_read flag to unused bit. Define new variable line_buffer_pos. * io/list_read.c (free_saved, next_char, l_push_char, read_logical, read_real): Replace use of item_count with line_buffer_pos for line_buffer look ahead. (read_logical, read_integer, parse_real, read_real, check_type): Adjust location of free_line to after generating error messages to retain the correct item count for the message. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c
[Bug target/58115] testcase gcc.target/i386/intrinsics_4.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58115 --- Comment #15 from David Edelsohn dje at gcc dot gnu.org --- Author: dje Date: Sat Jan 11 18:57:56 2014 New Revision: 206554 URL: http://gcc.gnu.org/viewcvs?rev=206554root=gccview=rev Log: PR target/58115 * config/rs6000/rs6000.h (SWITCHABLE_TARGET): Define. * config/rs6000/rs6000.c: Include target-globals.h. (rs6000_set_current_function): Instead of doing target_reinit unconditionally, use save_target_globals_default_opts and restore_target_globals. * config/rs6000/rs6000-builtin.def (mffs, mtfsf): Add builtins for FPSCR. * config/rs6000/rs6000.c (rs6000_expand_mtfsf_builtin): New. (rs6000_expand_builtin): Handle mffs and mtfsf. (rs6000_init_builtins): Define mffs and mtfsf. * config/rs6000/rs6000.md (UNSPECV_MFFS, UNSPECV_MTFSF): New. (rs6000_mffs): New pattern. (rs6000_mtfsf): New pattern. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000-builtin.def trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.h trunk/gcc/config/rs6000/rs6000.md
[Bug libstdc++/59768] [DR 2219] std::thread constructor not handling reference_wrapper correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59768 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|SUSPENDED Summary|[4.8 Regression]|[DR 2219] std::thread |std::thread constructor not |constructor not handling |handling reference_wrapper |reference_wrapper correctly |correctly | --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, I introduced __bind_simple specifically to provide the functionality needed by std::thread (and other components) because it's not the same as std::bind, which we were using previously. I've actually reported a defect against the standard saying this *should* work (but currently it's not allowed to), see http://cplusplus.github.io/LWG/lwg-active.html#2219
[Bug fortran/57042] [4.7/4.8 Regression] ICE/Segfault with -fdump-parse-tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57042 --- Comment #8 from janus at gcc dot gnu.org --- Author: janus Date: Sat Jan 11 20:34:48 2014 New Revision: 206556 URL: http://gcc.gnu.org/viewcvs?rev=206556root=gccview=rev Log: 2014-01-11 Janus Weil ja...@gcc.gnu.org Backport from mainline 2013-12-29 Janus Weil ja...@gcc.gnu.org PR fortran/59612 PR fortran/57042 * dump-parse-tree.c (show_typespec): Check for charlen. * invoke.texi: Fix documentation of -fdump-fortran-optimized and -fdump-parse-tree. Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/dump-parse-tree.c branches/gcc-4_8-branch/gcc/fortran/invoke.texi
[Bug fortran/59612] [F03] iso_fortran_env segfaults with -fdump-fortran-original
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59612 --- Comment #8 from janus at gcc dot gnu.org --- Author: janus Date: Sat Jan 11 20:34:48 2014 New Revision: 206556 URL: http://gcc.gnu.org/viewcvs?rev=206556root=gccview=rev Log: 2014-01-11 Janus Weil ja...@gcc.gnu.org Backport from mainline 2013-12-29 Janus Weil ja...@gcc.gnu.org PR fortran/59612 PR fortran/57042 * dump-parse-tree.c (show_typespec): Check for charlen. * invoke.texi: Fix documentation of -fdump-fortran-optimized and -fdump-parse-tree. Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/dump-parse-tree.c branches/gcc-4_8-branch/gcc/fortran/invoke.texi
[Bug lto/59723] [4.9 Regression] ICE: in lto_output_tree, at lto-streamer-out.c:1390 when compiling some Fortran tests with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59723
--- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr ---
This untested patch gets rid of the majority of the failures, although
I still see 2-3 errors in the dwarf code in tests like namelist_70.cf90:
Using
time make -k -j8 check-gfortran
RUNTESTFLAGS=--target_board=unix'{-m32/-flto,-m64/-flto}'
I see the following (26) failures
FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 scan-assembler (DW_AT_name:
label|label[^\n]*[^\n]*DW_AT_name)
FAIL: gfortran.dg/debug/pr35154-dwarf2.f -gdwarf-2 -g3 scan-assembler
(DW_AT_name: label|label[^\n]*[^\n]*DW_AT_name)
FAIL: gfortran.dg/bind_c_array_params_2.f90 -O scan-assembler-times myBindC
1
FAIL: gfortran.dg/bind_c_vars.f90 -O0 (test for excess errors)
FAIL: gfortran.dg/bind_c_vars.f90 -O1 (test for excess errors)
FAIL: gfortran.dg/bind_c_vars.f90 -O2 (test for excess errors)
FAIL: gfortran.dg/bind_c_vars.f90 -O3 -fomit-frame-pointer (test for excess
errors)
FAIL: gfortran.dg/bind_c_vars.f90 -O3 -fomit-frame-pointer -funroll-loops
(test for excess errors)
FAIL: gfortran.dg/bind_c_vars.f90 -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions (test for excess errors)
FAIL: gfortran.dg/bind_c_vars.f90 -O3 -g (test for excess errors)
FAIL: gfortran.dg/bind_c_vars.f90 -Os (test for excess errors)
FAIL: gfortran.dg/data_namelist_conflict.f90 -O0 (internal compiler error)
FAIL: gfortran.dg/data_namelist_conflict.f90 -O0 (test for excess errors)
FAIL: gfortran.dg/data_namelist_conflict.f90 -O3 -g (internal compiler error)
FAIL: gfortran.dg/data_namelist_conflict.f90 -O3 -g (test for excess errors)
FAIL: gfortran.dg/namelist_14.f90 -O3 -g (internal compiler error)
FAIL: gfortran.dg/namelist_14.f90 -O3 -g (test for excess errors)
FAIL: gfortran.dg/namelist_51.f90 -O3 -g (test for excess errors)
FAIL: gfortran.dg/namelist_69.f90 -O3 -g (internal compiler error)
FAIL: gfortran.dg/namelist_69.f90 -O3 -g (test for excess errors)
FAIL: gfortran.dg/namelist_70.f90 -O3 -g (internal compiler error)
FAIL: gfortran.dg/namelist_70.f90 -O3 -g (test for excess errors)
FAIL: gfortran.dg/pr48636-2.f90 -O scan-ipa-dump cp Creating a specialized
node of bar/[0-9]*\\.
FAIL: gfortran.dg/pr52835.f90 -O scan-tree-dump optimized bar
FAIL: gfortran.dg/pr53787.f90 -O scan-ipa-dump cp Creating a specialized
node of init
FAIL: gfortran.dg/pr53787.f90 -O scan-ipa-dump-times cp Aggregate
replacements 2
The failures for gfortran.dg/bind_c_vars.f90 are PR54852.
The ICEs for gfortran.dg/namelist_(14|69|70).f90, triggered by -g, are at
default:
gcc_unreachable ();
(missing case NAMELIST_DECL: ?).
On darwin13, the excess error for gfortran.dg/namelist_51.f90 is
warning: invalid DWARF generated by the compiler: DIE 0x01f0 has multiple
AT_calling_convention attributes in
'/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccD0Z3SE.ltrans0.ltrans.o'.
The ICE for gfortran.dg/data_namelist_conflict.f90 at -O or with -g is
lto1: internal compiler error: in lto_fixup_prevailing_decls, at lto/lto.c:2601
at
gcc_checking_assert (code != CONSTRUCTOR code != TREE_BINFO);
I have not looked at the scan issues nor at the debug capabilities with/without
the patch.
Concerning the time, the full regtesting of gfortran with -m32 and -m64 takes
~18' without -flto and ~35' with it. The full testing of all languages but go
is ~2h. Is the saving of 17' of CPU over 2h worth the missed testing and the
man power required to handle the problems?
Thanks for working on this PR.
[Bug lto/59723] [4.9 Regression] ICE: in lto_output_tree, at lto-streamer-out.c:1390 when compiling some Fortran tests with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59723 --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr --- I see the following (26) failures The same 26 failures for -m32 and -m64 (i.e., 52 total).
[Bug libfortran/59419] [4.9 Regression] Failing OPEN with FILE='xxx' and IOSTAT creates the file 'xxx' after revision 196783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Fixed on 4.9.
[Bug fortran/59700] [4.8/4.9 Regression] Misleading/buggy runtime error message: Bad integer for item 0 in list input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59700 --- Comment #21 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sat Jan 11 21:38:30 2014 New Revision: 206559 URL: http://gcc.gnu.org/viewcvs?rev=206559root=gccview=rev Log: 2014-01-11 Steven G. Kargl ka...@gcc.gnu.org PR fortran/59700 * gfortran.dg/pr59700.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr59700.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #41 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Closing this long PR and opening a new one for the cleanup mentioned in comment #38
[Bug libfortran/59771] New: Cleanup handling of Gw.0 and Gw.0Ee format
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59771
Bug ID: 59771
Summary: Cleanup handling of Gw.0 and Gw.0Ee format
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assignee: jvdelisle at gcc dot gnu.org
Reporter: jvdelisle at gcc dot gnu.org
Carried over from PR48906 Comment 38
If d is zero, kPEw.0 or kPEw.0Ee editing is used for Gw.0 editing or Gw.0Ee
editing respectively.
Possible patch needs more testing:
Index: write_float.def
===
--- write_float.def(revision 206545)
+++ write_float.def(working copy)
@@ -1046,7 +1046,8 @@
rexp_d = calculate_exp_ ## x (-d);\
if ((m 0.0 ((m 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) =
1.0)))\
|| ((m == 0.0) !(compile_options.allow_std\
- (GFC_STD_F2003 | GFC_STD_F2008\
+ (GFC_STD_F2003 | GFC_STD_F2008)))\
+ || d == 0)\
{ \
newf.format = FMT_E;\
newf.u.real.w = w;\
[Bug libfortran/59771] Cleanup handling of Gw.0 and Gw.0Ee format
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59771 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-11 Ever confirmed|0 |1 --- Comment #1 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- A simple test case: PRINT '(6(1X,1PG9.0e2))', 0.0, 0.04, 0.06, 0.4, 0.6, 243.0 PRINT '(6(1X,1PE9.0e2))', 0.0, 0.04, 0.06, 0.4, 0.6, 243.0 end Without patch: ./a.out At line 1 of file pr48906.f90 (unit = 6, file = 'stdout') Internal Error: Unspecified precision With patch: ./a.out 0.E+004.E-026.E-024.E-016.E-012.E+02 0.E+004.E-026.E-024.E-016.E-012.E+02
[Bug fortran/59612] [F03] iso_fortran_env segfaults with -fdump-fortran-original
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59612 --- Comment #9 from janus at gcc dot gnu.org --- Author: janus Date: Sat Jan 11 22:47:25 2014 New Revision: 206560 URL: http://gcc.gnu.org/viewcvs?rev=206560root=gccview=rev Log: 2014-01-11 Janus Weil ja...@gcc.gnu.org Backport from mainline 2013-12-29 Janus Weil ja...@gcc.gnu.org PR fortran/59612 PR fortran/57042 * dump-parse-tree.c (show_typespec): Check for charlen. * invoke.texi: Fix documentation of -fdump-fortran-optimized and -fdump-parse-tree. Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/dump-parse-tree.c branches/gcc-4_7-branch/gcc/fortran/invoke.texi
[Bug fortran/57042] [4.7/4.8 Regression] ICE/Segfault with -fdump-parse-tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57042 --- Comment #9 from janus at gcc dot gnu.org --- Author: janus Date: Sat Jan 11 22:47:25 2014 New Revision: 206560 URL: http://gcc.gnu.org/viewcvs?rev=206560root=gccview=rev Log: 2014-01-11 Janus Weil ja...@gcc.gnu.org Backport from mainline 2013-12-29 Janus Weil ja...@gcc.gnu.org PR fortran/59612 PR fortran/57042 * dump-parse-tree.c (show_typespec): Check for charlen. * invoke.texi: Fix documentation of -fdump-fortran-optimized and -fdump-parse-tree. Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/dump-parse-tree.c branches/gcc-4_7-branch/gcc/fortran/invoke.texi
[Bug ada/59772] New: Floating point constants are not correctly encoded on AVR target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59772
Bug ID: 59772
Summary: Floating point constants are not correctly encoded on
AVR target
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: j-etienne at users dot sourceforge.net
In code compiled for AVR target, the floating point constants are not correct
in the generated code.
Sample code (specification first, then body) :
-
package Float_Test is
function Div_Test (Value : Float) return Float;
function Perimeter_Test (Value : Float) return Float;
end Float_Test;
package body Float_Test is
K_Denominator : constant Float := Float (4096);
K_Pi : constant Float := 3.1415927;
function Div_Test (Value : Float) return Float
is
begin
return (Value / K_Denominator);
end Div_Test;
function Perimeter_Test (Value : Float) return Float
is
begin
return (Value * K_Pi);
end Perimeter_Test;
end Float_Test;
-
When I commpile this sample code, with the following command :
avr-gcc -Wall -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -mmcu=at90usb1287 -Os -S -gnatp -I
~/Programmation/Unix/gcc-4.8.2/gcc/ada float_test.adb -fdump-tree-original
-gnatD
It generates wrong values for both floating point constants :
-
.filefloat_test.adb
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__RAMPZ__ = 0x3b
__tmp_reg__ = 0
__zero_reg__ = 1
.global__divsf3
.text
.globalfloat_test__div_test
.typefloat_test__div_test, @function
float_test__div_test:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
ldi r18,0
ldi r19,0
movw r20,r18
call __divsf3
ret
.sizefloat_test__div_test, .-float_test__div_test
.global__mulsf3
.globalfloat_test__perimeter_test
.typefloat_test__perimeter_test, @function
float_test__perimeter_test:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
ldi r18,0
ldi r19,lo8(-80)
ldi r20,lo8(125)
ldi r21,lo8(58)
call __mulsf3
ret
.sizefloat_test__perimeter_test, .-float_test__perimeter_test
.globalfloat_test_E
.data
.typefloat_test_E, @object
.sizefloat_test_E, 2
float_test_E:
.zero2
.identGCC: (GNU) 4.8.2
.global __do_copy_data
-
The denominator provided as argument to divsf3 is 0.0 instead of 4096, and the
constant term provided as argument to mulsf3 is 0.000967741 instead of
3.12415927
I'm using a cross GCC for AVR target hosted on MacOSX 10.9. avr-gcc -v gives :
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/opt/avr-ada-test/libexec/gcc/avr/4.8.2/lto-wrapper
Target: avr
Configured with: ../gcc-4.8.2/configure --prefix=/opt/avr-ada-test --target=avr
--program-prefix=avr- --disable-shared --disable-nls --disable-libssp
--with-system-zlib --disable-libada --enable-languages=ada,c --enable-cpp
--with-dwarf2 --enable-version-specific-runtime-libs --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local
Thread model: single
gcc version 4.8.2 (GCC)
Please note that I reproduced the same behaviour on a x86-linux host.
I first stumbled upon this bug when migrating my application to AVR GCC 4.7.2
using the RTS from AVR-Ada.
With GCC 4.8.2, I tried several system.ads locations : the one from the AVR
Ada RTS, from the native compiler, from the GCC source tree, and always got the
same result.
I noticed that in the GNAT debug file float_test.adb.dg , the constants are
correct :
-
float_test__k_denominator : constant float := [8388608.0*2**(-11)];
float_test__k_pi : constant float := [13176795.0*2**(-22)];
function float_test__div_test (value : float) return float is
begin
return (value / float_test__k_denominator);
end float_test__div_test;
function float_test__perimeter_test (value : float) return float is
begin
return (value * float_test__k_pi);
end float_test__perimeter_test;
-
While in the original tree dump float_test.adb.003t.original, they are not
(and have the values that are eventually found in the machine code) :
-
Float_Test.Div_Test (const float value)
{
return (float) value / 0.0;
Float_Test.Perimeter_Test (const float value)
{
return (float) value * 9.677410125732421875e-4;
-
The encoding was correct with GCC 4.5
[Bug fortran/57042] ICE/Segfault with -fdump-parse-tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57042 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8 Regression]|ICE/Segfault with |ICE/Segfault with |-fdump-parse-tree |-fdump-parse-tree | --- Comment #10 from janus at gcc dot gnu.org --- The ICE regression has been fixed on 4.7, 4.8 and trunk. Todo: comment 4/7.
[Bug c/59773] New: Mixing pointers to different memory spaces shows no warning (gcc for AVR)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59773 Bug ID: 59773 Summary: Mixing pointers to different memory spaces shows no warning (gcc for AVR) Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: visenri at yahoo dot es I'll explain it with an example. Having these strings declared: const char __flash strF[] = Flash; const char strR[] = RAM; And a function with a 24 bit flat pointer like this: Foo( const char __memx * str ); Calling it like this is ok (16 bit pointer is enlarged to 24 generating correct code): Foo(strF); Foo(strR); But using functions with 16 bit pointer: FooR( const char * str ); //16 bit pointer to RAM FooF( const char _flash * str ); //16 bit pointer to FLASH And these variables: const char __memx * pstr; const char * pstrR; const char __flash * pstrF; These lines should show at least a warning: FooR(strF); // same size, different memory space FooF(strR); // same size, different memory space FooR(pstr); // pstr is 24 bit, bigger than 16 bit ram pointer in function FooF(pstr); // pstr is 24 bit, bigger than 16 bit flash pointer in function pstrR = strF; // same size, different memory space pstrF = strR; // same size, different memory space pstrR = pstr; // pstr is 24 bit, bigger than 16 bit ram pointer pstrF = pstr; // pstr is 24 bit, bigger than 16 bit flash pointer Because we are going to use a ROM/FLASH pointer as a RAM pointer or the other way.
[Bug libfortran/59774] New: Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 Bug ID: 59774 Summary: Inconsistent rounding between -m32 and -m64 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: jvdelisle at gcc dot gnu.org Reporter: jvdelisle at gcc dot gnu.org With the following (Found by Dominiq) we get bad results: print (ru,g11.2), 99. $gfc -m32 pr59771.f90 $ ./a.out 10. Its rounding up to 100 and then chopping the result. I don't think this is the same as pr48906 which I just closed.
[Bug libfortran/59774] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-12 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Other problems extracted form pr48906 [Book15] f90/bug% cat pr48906_4.f90 print (ru,g15.2), .099d0 ! 0.10E+00 expected 0.10 print (rc,g15.1), .095d0 ! 0.1E+00 expected 0.1 print (rc,g15.2), .0995d0 ! 0.10E+00 expected 0.10 print (ru,g15.3), .0999d0 ! 0.100E+00 expected 0.100 end [Book15] f90/bug% gfc pr48906_4.f90 [Book15] f90/bug% a.out 0.10 0.1 0.10 0.100 [Book15] f90/bug% gfc pr48906_4.f90 -m32 [Book15] f90/bug% a.out 0.10E+00 0.1E+00 0.10E+00 0.100E+00 [Book15] f90/bug% cat pr48906_1_red.f90 print (rc,g10.2,''), 99.5 ! 10. expected 0.10E+03 end [Book15] f90/bug% gfc pr48906_1_red.f90 [Book15] f90/bug% a.out 0.10E+03 [Book15] f90/bug% gfc pr48906_1_red.f90 -m32 [Book15] f90/bug% a.out 100. Note that the numerical values are correct for these tests.
[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Summary|Inconsistent rounding |[Regression] Inconsistent |between -m32 and -m64 |rounding between -m32 and ||-m64 --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- I think this gets back to: http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=185433 Using: print (ru,g11.2), 99._8 print (ru,g11.2), 99._4 end Looking at the buffer in output_float we get: $ gfc -m32 pr59771.f90 $ ./a.out buffer=+999e+01 0.99E+02 buffer=+99. 10. $ gfc -m64 pr59771.f90 $ ./a.out buffer=+999e+01 0.99E+02 buffer=+999e+01 0.99E+02 Notice the '.' in the buffer for kind=4 vs kind=8 I don't know all the reasons for the changes made, but think . needs to get stripped out before we ever get to output_float and the exponent needs to be there. I do recall the reason gfortran does its own rounding is because the C implementations across platforms are not consistent.
[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- I instrumented using: printf(buffer=%s\n, buffer); in output_float () to see what is going on.
[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- I see the problem back to 4.7. In 4.6 the results are numerically correct but not right. Si Ma not sure this is a regression or not. With 4.6: $ gfc46 -m32 pr59771.f90 $ ./a.out 100. 100.
