[Bug tree-optimization/68522] [6 Regression] SPEC CPU2006 435.gromacs miscomparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68522 --- Comment #4 from Jeffrey A. Law --- And just to be clear, I'm actually referring to myself...
[Bug tree-optimization/68522] [6 Regression] SPEC CPU2006 435.gromacs miscomparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68522 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 --- Comment #3 from Jeffrey A. Law --- I don't think the reporter should be necessarily responsible for generating a testcase here since the author of the offending patch has access to spec2k6 :-) It's on my list and I can't see any path by which it won't be addressed before gcc-6.
[Bug ipa/69075] ICE when setting early-inlining-insns to other than default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69075 Mikhail Maltsev changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-30 CC||miyuki at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Mikhail Maltsev --- The "--enable-checking=yes" version of GCC 5 branch (20151222 snapshot) fails in tree_check: miyuki@gcc-build1:~$ /opt/gcc-5-latest/bin/g++ -w -std=c++14 -flto -O3 -fdevirtualize-at-ltrans --param early-inlining-insns=15 ./test.ii In file included from ../../../../src/theme/fix_engine/tests/../Book.hpp:1:0, from ../../../../src/theme/fix_engine/tests/../Gateway_Base.hpp:1, from ../../../../src/theme/fix_engine/tests/../Gateway.hpp:1, from ../../../../src/theme/fix_engine/tests/Gateway_With_Client_T.hpp:4, from ../../../../src/theme/fix_engine/tests/Gateway_With_Client_And_Failover_Gateway.hpp:1, from ../../../../src/theme/fix_engine/tests/Gateway_With_Client_And_Failover_Gateway.cpp:1: ../../../../src/theme/fix_engine/tests/../Book_Entry.hpp: In member function 'theme::fix::Book_Entry::Book_Entry(theme::Order_Id const&, theme::Client_Order_Id const&, theme::Fix_Sequence_Number)': ../../../../src/theme/fix_engine/tests/../Book_Entry.hpp:108:34: internal compiler error: Segmentation fault 0xd3b116 crash_signal /home/jenkins/workspace/build-gcc-snapshot/src/gcc-5-20151222/gcc/toplev.c:383 0x6df210 tree_check(tree_node*, char const*, int, char const*, tree_code) /home/jenkins/workspace/build-gcc-snapshot/src/gcc-5-20151222/gcc/tree.h:2850 0x6df210 is_really_empty_class(tree_node*) The trunk is OK. I'll post the reduced test-case when reduction finishes.
[Bug c++/67081] FAIL: g++.dg/cpp0x/nsdmi-template14.C (test for errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67081 Mikhail Maltsev changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #2 from Mikhail Maltsev --- I didn't notice this bug and instead reopened PR58583. Probably one of them should be closed. Also note https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58583#c7.
[Bug debug/69077] [6 Regression] omnetpp ICEs with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69077 --- Comment #7 from Andrew Pinski --- Created attachment 37191 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37191&action=edit tar file with simplified testcase
[Bug debug/69077] [6 Regression] omnetpp ICEs with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69077
--- Comment #6 from Andrew Pinski ---
Here is the simplified testcase:
t.h:
struct cStdDev
{
long ns;
virtual double mean() const { return ns; }
};
t1.cc:
#include "t.h"
struct cWeightedStdDev : public cStdDev {
virtual int netPack();
};
int cWeightedStdDev::netPack() { }
t2.cc:
#include "t.h"
struct sf
{
void recordScalar(double value);
cStdDev eedStats;
virtual void finish();
};
void sf::finish() {
recordScalar(eedStats.mean());
}
--- CUT
# g++ -flto -c -O3 -g t1.cc t2.cc
# g++ -flto -O3 -g -r -nostdlib t1.o t2.o
t2.cc: In member function 'finish':
t2.cc:10:1: internal compiler error: in gen_inlined_subroutine_die, at
dwarf2out.c:21329
}
^
0x6b67bf gen_inlined_subroutine_die
/home/apinski/src/local/gcc/gcc/dwarf2out.c:21328
0x6b67bf gen_block_die
/home/apinski/src/local/gcc/gcc/dwarf2out.c:22813
0x69ba1b decls_for_scope
/home/apinski/src/local/gcc/gcc/dwarf2out.c:22886
0x69c067 gen_subprogram_die
/home/apinski/src/local/gcc/gcc/dwarf2out.c:20601
0x69a28f gen_decl_die
/home/apinski/src/local/gcc/gcc/dwarf2out.c:23293
0x69aeb7 dwarf2out_decl
/home/apinski/src/local/gcc/gcc/dwarf2out.c:23776
0x69b3a3 dwarf2out_function_decl
/home/apinski/src/local/gcc/gcc/dwarf2out.c:23791
0x71123b rest_of_handle_final
/home/apinski/src/local/gcc/gcc/final.c:4473
0x71123b execute
/home/apinski/src/local/gcc/gcc/final.c:4515
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/home/apinski/local-binutils-gdb/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug lto/69082] Final link fails on ARM using lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69082 PeteVine changed: What|Removed |Added URL||http://ufoai.org/wiki/Getti ||ng_the_source --- Comment #3 from PeteVine --- Thanks for the prompt reply. I'll need some pointers in narrowing the problem down however - as you can see from the final command line the number of object files is very large and I have no idea which one(s) is to blame.
[Bug lto/69082] Final link fails on ARM using lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69082 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-29 Ever confirmed|0 |1 Severity|critical|normal --- Comment #2 from Andrew Pinski --- We need a testcase that can be compiled. This is only the final assembly file which shows the issue rather than the source which can then debugged.
[Bug debug/69077] [6 Regression] omnetpp ICEs with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69077 --- Comment #5 from Andrew Pinski --- Down to two files (netpack.ii and EtherAppSrv.ii). Reducing it further too.
[Bug debug/69077] [6 Regression] omnetpp ICEs with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69077 --- Comment #4 from Andrew Pinski --- Down to 12 files now and still removing them.
[Bug c++/67081] FAIL: g++.dg/cpp0x/nsdmi-template14.C (test for errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67081 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-29 Ever confirmed|0 |1
[Bug tree-optimization/68356] FAIL: gcc.dg/torture/pr68264.c -O* execution test on x86_64-apple-darwin1(0|4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356 --- Comment #10 from dave.anglin at bell dot net --- On 2015-12-29, at 5:25 PM, dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356 > > --- Comment #9 from dave.anglin at bell dot net --- > On 2015-12-29, at 5:05 PM, dominiq at lps dot ens.fr wrote: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356 >> >> --- Comment #8 from Dominique d'Humieres --- >>> You might want to double check that it's not a bug in the HP-UX libm. >> >> AFAIU Joseph (comment 2) the test should be skipped on platforms defaulting >> to >> -fno-math-errno as Darwin. Is it the case for HP-UX? > > > I believe that is the case for hpux. No errors are defined for exp2. Man > page > says: > > If the correct value after rounding would be smaller in magnitude than > MINDOUBLE, exp2() returns zero. It looks like the lack of an ERANGE error is specific to exp2. The other tests pass okay, so I think I'll do the same skip as __sun__ around exp2 and expm1 even though I think expm1 would pass since it supports ERANGE errors. Dave -- John David Anglin dave.ang...@bell.net
[Bug fortran/67779] Strange ordering with strings in extended object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779 --- Comment #18 from paul.richard.thomas at gmail dot com --- It works for me - a mystery for tomorrow :-) Paul On 29 December 2015 at 23:10, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779 > > --- Comment #17 from Dominique d'Humieres --- >> Now sorting the right-hand part of the array fails: > > Confirmed, starting with > >2 9 8 7 6 5 >4 3 10 1 > > I get > >1 2 3 4 5 6 >7 8 10 9 > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug.
[Bug fortran/69080] No automatic deallocation of allocatable function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080 --- Comment #6 from Dominique d'Humieres --- > However, I don't think this is a solution. If you, for example, think > of a string class as the derived type instead of "dummy", there could > be a function returning an allocatable string_class derived type. > This string function result could be used somewhere in a subroutine > as input, but the subroutine doesn't know if the string will still be > used outside of the subroutine. So there is no way the subroutine should > deallocate the string. > > I know that allocatables that are declared in the program itself aren't > deallocated automatically because of the implicit save attribute. > But my thinking was that Fortran will take care of deallocating allocatable > in all other cases. Of course, I may be mistaken. Well, if the user is unable to decide when and where something should be deallocate, how can you expect the compiler to do better? AFAIU this should be handled through finalization, but I am still learning and I am not in position to give advice in this area.
[Bug tree-optimization/68356] FAIL: gcc.dg/torture/pr68264.c -O* execution test on x86_64-apple-darwin1(0|4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356 --- Comment #9 from dave.anglin at bell dot net --- On 2015-12-29, at 5:05 PM, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356 > > --- Comment #8 from Dominique d'Humieres --- >> You might want to double check that it's not a bug in the HP-UX libm. > > AFAIU Joseph (comment 2) the test should be skipped on platforms defaulting to > -fno-math-errno as Darwin. Is it the case for HP-UX? I believe that is the case for hpux. No errors are defined for exp2. Man page says: If the correct value after rounding would be smaller in magnitude than MINDOUBLE, exp2() returns zero. Dave -- John David Anglin dave.ang...@bell.net
[Bug fortran/69080] No automatic deallocation of allocatable function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080 kargl at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |INVALID --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to sv.mueller from comment #3) > Thanks for testing this out! > > Indeed there aren't any leaks with your changes. Actually, leaving the > module save statement uncommented produces the same positive result for me. > > However, I don't think this is a solution. If you, for example, think of a > string class as the derived type instead of "dummy", there could be a > function returning an allocatable string_class derived type. This string > function result could be used somewhere in a subroutine as input, but the > subroutine doesn't know if the string will still be used outside of the > subroutine. So there is no way the subroutine should deallocate the string. > > I know that allocatables that are declared in the program itself aren't > deallocated automatically because of the implicit save attribute. But my > thinking was that Fortran will take care of deallocating allocatables in all > other cases. Of course, I may be mistaken. When the execution of a procedure is terminated by execution of a RETURN or END statement, an allocatable variable that is a named local variable of the procedure retains its allocation and definition status if it has the SAVE attribute or is a function result variable or a subobject thereof; otherwise, it is deallocated.
[Bug fortran/67779] Strange ordering with strings in extended object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779 --- Comment #17 from Dominique d'Humieres --- > Now sorting the right-hand part of the array fails: Confirmed, starting with 2 9 8 7 6 5 4 3 10 1 I get 1 2 3 4 5 6 7 8 10 9
[Bug fortran/69080] No automatic deallocation of allocatable function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080 --- Comment #4 from sv.muel...@tu-braunschweig.de --- Addendum to my last post: I refered to scalar allocatables, not arrays
[Bug fortran/69080] No automatic deallocation of allocatable function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080 --- Comment #3 from sv.muel...@tu-braunschweig.de --- Thanks for testing this out! Indeed there aren't any leaks with your changes. Actually, leaving the module save statement uncommented produces the same positive result for me. However, I don't think this is a solution. If you, for example, think of a string class as the derived type instead of "dummy", there could be a function returning an allocatable string_class derived type. This string function result could be used somewhere in a subroutine as input, but the subroutine doesn't know if the string will still be used outside of the subroutine. So there is no way the subroutine should deallocate the string. I know that allocatables that are declared in the program itself aren't deallocated automatically because of the implicit save attribute. But my thinking was that Fortran will take care of deallocating allocatables in all other cases. Of course, I may be mistaken.
[Bug tree-optimization/68356] FAIL: gcc.dg/torture/pr68264.c -O* execution test on x86_64-apple-darwin1(0|4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356 --- Comment #8 from Dominique d'Humieres --- > You might want to double check that it's not a bug in the HP-UX libm. AFAIU Joseph (comment 2) the test should be skipped on platforms defaulting to -fno-math-errno as Darwin. Is it the case for HP-UX?
[Bug tree-optimization/68356] FAIL: gcc.dg/torture/pr68264.c -O* execution test on x86_64-apple-darwin1(0|4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #7 from Eric Botcazou --- > Also fails on hppa64-hp-hpux11.11. You might want to double check that it's not a bug in the HP-UX libm.
[Bug debug/69077] [6 Regression] omnetpp ICEs with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69077 --- Comment #3 from Andrew Pinski --- I Have it down to 42 files down from 83 files. One file was taking longer so I moved it to the end of the list. Should be down to a few files by the end of the day.
[Bug fortran/67779] Strange ordering with strings in extended object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779 --- Comment #16 from Thomas Koenig --- Created attachment 37190 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37190&action=edit Test case that still fails Hi Paul, > (i) To fix the ICE in trans.c. This is fixed by the change to trans-stmt.c. > Note that I have not checked to see if this has been cured - my tree is > somewhat out of date. In anycase, expr3 should never be coming back as a > NOP_EXPR; and Andre already fixed this one (PR 69011). > (ii) Fix the original problem in sorting. As noted previously, this is > associated with the array offset being zero, rather than -1. Setting > parmse.use_offset = 0; rather than one does the job. I tried out this part of your patch (with Andre's fix) and got yet another failure on a modification of the original test case. Now sorting the right-hand part of the array fails: Sorting ... Array on entry 0.997559547 0.566824675 0.965915322 0.747927666 0.367390871 0.480636895 0.737542510E-01 0.535517931E-02 0.347081244 0.342243791 Array after shuffling 0.342243791 0.347081244 0.535517931E-02 0.737542510E-01 0.367390871 0.480636895 0.747927666 0.965915322 0.566824675 0.997559547 Left part, pivot=0.367390871 Array on entry 0.342243791 0.347081244 0.535517931E-02 0.737542510E-01 Array after shuffling 0.342243791 0.737542510E-01 0.535517931E-02 0.347081244 Left part, pivot=0.347081244 Array on entry 0.342243791 0.737542510E-01 0.535517931E-02 Array after shuffling 0.535517931E-02 0.737542510E-01 0.342243791 Right part, pivot=0.367390871 Array on entry 0.535517931E-02 0.737542510E-01 0.342243791 0.347081244 0.367390871 Array after shuffling 0.535517931E-02 0.737542510E-01 0.342243791 0.347081244 0.367390871 Left part, pivot=0.342243791 Array on entry 0.480636895 0.747927666 Array after shuffling 0.480636895 0.747927666 Right part, pivot=0.342243791 Array on entry 0.480636895 0.747927666 Array after shuffling 0.480636895 0.747927666 Result: 0.535517931E-02 0.737542510E-01 0.342243791 0.347081244 0.367390871 0.480636895 0.747927666 0.965915322 0.566824675 0.997559547
[Bug tree-optimization/68356] FAIL: gcc.dg/torture/pr68264.c -O* execution test on x86_64-apple-darwin1(0|4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356 John David Anglin changed: What|Removed |Added Target|x86_64-apple-darwin1* |x86_64-apple-darwin1* ||hppa*-*-hpux* Last reconfirmed|2015-11-15 00:00:00 |2015-12-29 Host|x86_64-apple-darwin1* |x86_64-apple-darwin1* ||hppa*-*-hpux* Build|x86_64-apple-darwin1* |x86_64-apple-darwin1* ||hppa*-*-hpux* --- Comment #6 from John David Anglin --- First fail on hpux is: Breakpoint 2, test () at /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/pr68264.c:86 86TEST (exp2 (d), POWER_ERANGE); (gdb) p d $1 = -1e+80
[Bug fortran/69080] No automatic deallocation of allocatable function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080 --- Comment #2 from Dominique d'Humieres --- The leak seems gone with module dummy_module implicit none ! save type, public :: dummy_class contains procedure, public :: trigger => dummy_trigger end type contains function dummy_create_allocatable() result(result_object) class(dummy_class), allocatable :: result_object allocate(result_object) end function dummy_create_allocatable subroutine dummy_do_nothing(a_dummy) !class(dummy_class), allocatable, intent(in) :: a_dummy class(dummy_class), allocatable :: a_dummy print *, allocated(a_dummy) if (allocated(a_dummy)) deallocate(a_dummy) end subroutine dummy_do_nothing subroutine dummy_trigger(this) class(dummy_class), intent(inout) :: this call dummy_do_nothing(dummy_create_allocatable()) end subroutine dummy_trigger end module dummy_module program prog use dummy_module implicit none save class(dummy_class), allocatable :: dummy allocate(dummy) call dummy%trigger() deallocate(dummy) end program prog
[Bug fortran/69080] No automatic deallocation of allocatable function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-29 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- From 4.8 up to trunk (6.0), I see ==22973== 1 bytes in 1 blocks are definitely lost in loss record 1 of 65 ==22973==at 0x18EA1: malloc (vg_replace_malloc.c:303) ==22973==by 0x10B34: __dummy_module_MOD_dummy_create_allocatable (in ./a.out) ==22973==by 0x10AC5: __dummy_module_MOD_dummy_trigger (in ./a.out) ==22973==by 0x10BFE: MAIN__ (in ./a.out) ==22973==by 0x10CD0: main (in ./a.out) > Is this correct behavior? If so, why? I don't know, however you allocate result_object, but never deallocate it. I have no idea about how and when this deallocation can be done.
[Bug lto/69082] Final link fails on ARM using lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69082 PeteVine changed: What|Removed |Added CC||tulipawn at gmail dot com --- Comment #1 from PeteVine --- The -O flags used here don't matter
[Bug lto/69082] New: Final link fails on ARM using lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69082 Bug ID: 69082 Summary: Final link fails on ARM using lto Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: tulipawn at gmail dot com Target Milestone: --- Created attachment 37189 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37189&action=edit The offending assembly file Only when compiling with -flto the final link fails (all goes fine without lto): ===> LD [ufo] /tmp/ccUuOyr9.s: Assembler messages: /tmp/ccUuOyr9.s:11199: Error: offset out of range /tmp/ccUuOyr9.s:11208: Error: offset out of range /tmp/ccUuOyr9.s:11487: Error: offset out of range /tmp/ccUuOyr9.s:11521: Error: offset out of range /tmp/ccUuOyr9.s:11788: Error: offset out of range /tmp/ccUuOyr9.s:11797: Error: offset out of range lto-wrapper: /usr/bin/g++-4.9.real returned 1 exit status /usr/bin/ld.gold.real: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status Flags that were given explicitly: -O3 -mcpu=cortex-a5 -mfpu=neon -mfloat-abi=hard -fsigned-char -ffast-math -ftree-vectorize -Ofast -save-temps -v -flto -ffat-lto-objects The full command line for the binaries being compiled: ===> LD [ufo2map] COLLECT_GCC_OPTIONS='-D' 'HAVE_CONFIG_H' '-g' '-Winline' '-Wcast-qual' '-Wcast-align' '-Wmissing-declarations' '-Wpointer-arith' '-Wno-long-long' '-Wpedantic' '-Wall' '-Wextra' '-Wno-sign-compare' '-Wno-unused-parameter' '-Wreturn-type' '-Wwrite-strings' '-Wno-variadic-macros' '-Wno-format-zero-length' '-D' 'NDEBUG' '-D' 'SHARED_EXT="so"' '-D' '_GNU_SOURCE' '-D' '_BSD_SOURCE' '-D' '_XOPEN_SOURCE' '-O3' '-mcpu=cortex-a5' '-mfpu=neon' '-mfloat-abi=hard' '-fsigned-char' '-ftree-vectorize' '-Ofast' '-save-temps' '-v' '-flto' '-ffat-lto-objects' '-D' 'PANDORA' '-D' 'ARM' '-D' 'NEON' '-D' 'HAVE_GLES' '-ffast-math' '-funroll-loops' '-D' '_FORTIFY_SOURCE=2' '-D' 'NDEBUG' '-Wnon-virtual-dtor' '-D' 'COMPILE_MAP' '-D' '_REENTRANT' '-I' '/usr/include/SDL2' '-c' '-o' 'release-openpandora-armv7l/ufoslicer/ports/unix/unix_main.cpp.o' '-MP' '-MD' '-MT' 'release-openpandora-armv7l/ufoslicer/ports/unix/unix_main.cpp.o' '-shared-libgcc' '-mthumb' '-mtls-dialect=gnu' as -v -I /usr/include/SDL2 -mcpu=cortex-a5 -mfloat-abi=hard -mfpu=neon -meabi=5 -o release-openpandora-armv7l/ufoslicer/ports/unix/unix_main.cpp.o unix_main.s GNU assembler version 2.24 (arm-linux-gnueabihf) using BFD version (GNU Binutils for Ubuntu) 2.24 COMPILER_PATH=/usr/lib/gcc/arm-linux-gnueabihf/4.9/:/usr/lib/gcc/arm-linux-gnueabihf/4.9/:/usr/lib/gcc/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/4.9/:/usr/lib/gcc/arm-linux-gnueabihf/ LIBRARY_PATH=/usr/lib/gcc/arm-linux-gnueabihf/4.9/:/usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../../lib/:/lib/arm-linux-gnueabihf/:/lib/../lib/:/usr/lib/arm-linux-gnueabihf/:/usr/lib/../lib/:/usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-D' 'HAVE_CONFIG_H' '-g' '-Winline' '-Wcast-qual' '-Wcast-align' '-Wmissing-declarations' '-Wpointer-arith' '-Wno-long-long' '-Wpedantic' '-Wall' '-Wextra' '-Wno-sign-compare' '-Wno-unused-parameter' '-Wreturn-type' '-Wwrite-strings' '-Wno-variadic-macros' '-Wno-format-zero-length' '-D' 'NDEBUG' '-D' 'SHARED_EXT="so"' '-D' '_GNU_SOURCE' '-D' '_BSD_SOURCE' '-D' '_XOPEN_SOURCE' '-O3' '-mcpu=cortex-a5' '-mfpu=neon' '-mfloat-abi=hard' '-fsigned-char' '-ftree-vectorize' '-Ofast' '-save-temps' '-v' '-flto' '-ffat-lto-objects' '-D' 'PANDORA' '-D' 'ARM' '-D' 'NEON' '-D' 'HAVE_GLES' '-ffast-math' '-funroll-loops' '-D' '_FORTIFY_SOURCE=2' '-D' 'NDEBUG' '-Wnon-virtual-dtor' '-D' 'COMPILE_MAP' '-D' '_REENTRANT' '-I' '/usr/include/SDL2' '-c' '-o' 'release-openpandora-armv7l/ufoslicer/ports/unix/unix_main.cpp.o' '-MP' '-MD' '-MT' 'release-openpandora-armv7l/ufoslicer/ports/unix/unix_main.cpp.o' '-shared-libgcc' '-mthumb' '-mtls-dialect=gnu' The final link commands: /usr/lib/gcc/arm-linux-gnueabihf/4.9/collect2 -plugin /usr/lib/gcc/arm-linux-gnueabihf/4.9/liblto_plugin.so -plugin-opt=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper -plugin-opt=-fresolution=/tmp/ccx67lBs.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --sysroot=/ --build-id --eh-frame-hdr -dynamic-linker /lib/ld-linux-armhf.so.3 -X --hash-style=gnu --as-needed -m armelf_linux_eabi -z relro -o ufo /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../arm-linux-gnueabihf/crt1.o /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../arm-linux-gnueabihf/crti.o /usr/lib/gcc/arm-linux-gnueabihf/4.9/crtbegin.o -L/usr/lib/gcc/arm-linux-gnueabihf/4.9 -L/usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../arm-linux-gnueabihf -L/usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../../lib -L/lib/arm-linux-gnuea
[Bug ipa/69075] ICE when setting early-inlining-insns to other than default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69075 --- Comment #2 from Charles --- Created attachment 37188 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37188&action=edit 2/2 the preprocessed file (*.i*) that triggers the bug
[Bug ipa/69075] ICE when setting early-inlining-insns to other than default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69075 --- Comment #1 from Charles --- Created attachment 37187 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37187&action=edit 1/2 the preprocessed file (*.i*) that triggers the bug
[Bug libstdc++/69081] New: forward_list::splice_after does not handle the case of first<=last properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69081
Bug ID: 69081
Summary: forward_list::splice_after does not handle the case of
first<=last properly
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: wli2008ms at outlook dot com
Target Milestone: ---
In this API,
void splice_after( const_iterator pos, forward_list& other,
const_iterator first, const_iterator last )
It supposes to transfer elements [first, last). If the last is before the
first, then [first, last) shall be empty set mathematically. So, the list of
pos shall not be touched. However, with the current implementation, the list
of pos is left undefined after the call in such case.
--
#include
#include
int main()
{
std::forward_list l1 = {1,2,3,4,5};
std::forward_list l2 = {10,11,12};
l2.splice_after(l2.cbefore_begin(), l1, l1.cbegin(), l1.cbegin());
for(int n : l1)
std::cout << n << ' ';
std::cout << '\n';
for(int n : l2)
std::cout << n << ' ';
std::cout << '\n';
}
Output:
1
2 3 4 5
[Bug fortran/69080] New: No automatic deallocation of allocatable function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080 Bug ID: 69080 Summary: No automatic deallocation of allocatable function results Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sv.muel...@tu-braunschweig.de Target Milestone: --- Created attachment 37186 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37186&action=edit Test program and module Note: This is my first bug report I noticed that allocatable function results are not always deallocated. I'm actually not sure if this is correct behavior or not. See code attachment for test prog. Architecture is Debian GNU/Linux 8.2 (jessie) x86_64, gfortran has only been called with "gfortran dummy_module.f90 prog.f90". "valgrind --leak-check=full ./a.out" then tells me: ==26772== Memcheck, a memory error detector ==26772== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==26772== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info ==26772== Command: ./a.out ==26772== ==26772== ==26772== HEAP SUMMARY: ==26772== in use at exit: 1 bytes in 1 blocks ==26772== total heap usage: 25 allocs, 24 frees, 12,832 bytes allocated ==26772== ==26772== 1 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==26772==at 0x4C28C20: malloc (vg_replace_malloc.c:296) ==26772==by 0x400828: __dummy_module_MOD_dummy_create_allocatable (in /a.out) ==26772==by 0x4007C4: __dummy_module_MOD_dummy_trigger (in /a.out) ==26772==by 0x4008CA: MAIN__ (in /a.out) ==26772==by 0x400990: main (in /a.out) ==26772== ==26772== LEAK SUMMARY: ==26772==definitely lost: 1 bytes in 1 blocks ==26772==indirectly lost: 0 bytes in 0 blocks ==26772== possibly lost: 0 bytes in 0 blocks ==26772==still reachable: 0 bytes in 0 blocks ==26772== suppressed: 0 bytes in 0 blocks ==26772== ==26772== For counts of detected and suppressed errors, rerun with: -v ==26772== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Is this correct behavior? If so, why? Thanks in advance.
[Bug bootstrap/66521] xgcc: cc1plus segfaults when compiling libstdc++-v3/src/c++11/ostream-inst.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521 --- Comment #18 from Eric Gallager --- (In reply to Andrew Pinski from comment #17) > Is this working now? Uh... essentially. As originally reported, yes. I should probably open a different bug for the other issue(s) that have arisen since fixing the original one...
[Bug target/67710] FAIL: gcc.dg/darwin-*version-*.c (test for excess errors) with Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67710 --- Comment #8 from mrs at gcc dot gnu.org --- Ok.
[Bug fortran/67779] Strange ordering with strings in extended object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #15 from Paul Thomas --- Created attachment 37185 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37185&action=edit A provisional patch for the PR This patch has two objectives: (i) To fix the ICE in trans.c. This is fixed by the change to trans-stmt.c. Note that I have not checked to see if this has been cured - my tree is somewhat out of date. In anycase, expr3 should never be coming back as a NOP_EXPR; and (ii) Fix the original problem in sorting. As noted previously, this is associated with the array offset being zero, rather than -1. Setting parmse.use_offset = 0; rather than one does the job. Rather alarmingly, in my opinion, the patch regtests OK. This begs the question as to why parmse.use_offset was set in the first place. In the absence of any explanation, it might be judicious to only set it for full arrays; ie. not to set it for array sections, as is the case here. s/write( string_array(i)%value, '(a,i0)' ) "String = ", 11 - i /write( string_array(i)%value, '(a,i2)' ) "String = ", 11 - i / Allows the original testcase not only to run but to sort string_array correctly. Is this indicative of a bug in LLT? I'll take the PR. Paul
[Bug c++/69079] shared library does not load for variable initializations with important code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079 --- Comment #9 from Denis Sherstennikov --- Perhaps, this was a distro compilation inaccuracy of ubuntu package maintainer.
[Bug c++/69079] shared library does not load for variable initializations with important code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079 --- Comment #8 from Denis Sherstennikov --- I doubt that ccache changes g++ flags somehow: without it the discussed behavior still was present - under g++ 5.2.1.
[Bug c++/69079] shared library does not load for variable initializations with important code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079 --- Comment #7 from Denis Sherstennikov --- I used default bundled g++ update from ubuntu 14.04.02 repo, however it works through ccache.
[Bug c++/69079] shared library does not load for variable initializations with important code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > Did you compile GCC yourself or using different distro's compilers? That is Debian/Ubuntu sets --as-needed as the default while Fedora/Redhat and SUSE don't.
[Bug c++/69079] shared library does not load for variable initializations with important code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079 --- Comment #5 from Andrew Pinski --- Did you compile GCC yourself or using different distro's compilers?
[Bug c++/69079] shared library does not load for variable initializations with important code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079 --- Comment #4 from Denis Sherstennikov --- Yes, it does. That clearly ain't an obvious fix. If you hadn't told me, I don't know how I would figure this out in short time. I'd appreciate a compiler warning on this issue with direct designation of the choices and corresponding g++ flags. Also, is there a record on this change-of-behavior in g++ 5.2/5.3 changelog? I did not see any.
[Bug c++/69079] shared library does not load for variable initializations with important code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079 --- Comment #3 from Andrew Pinski --- Can see if adding -Wl,--no-as-needed fixes the problem? If so then there is no bug here.
[Bug c++/69079] shared library does not load for variable initializations with important code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079 --- Comment #2 from Denis Sherstennikov --- Problem does not occure under: g++ 5.1.0
[Bug c++/69079] shared library does not load for variable initializations with important code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079 --- Comment #1 from Denis Sherstennikov --- Problem confirmed under: g++ 5.3.0 20151204 g++ 5.2.1 20151031
[Bug fortran/67779] Strange ordering with strings in extended object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779 --- Comment #14 from Thomas Koenig --- The error occurs for class arrays only. Changing class(myclass), dimension(:) :: array to type(mysortable), dimension(:) :: array in the more simplified test case results in correct behavior.
[Bug target/68698] [6 regression] FAIL: gcc.target/i386/avx512vl-vmovap[sd]-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68698 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-29 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed on x86_64-apple-darwin15.
[Bug c++/69079] New: shared library does not load for variable initializations with important code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69079 Bug ID: 69079 Summary: shared library does not load for variable initializations with important code Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ddsherstennikov at ya dot ru Target Milestone: --- WTR: https://github.com/ddsherstennikov/training/tree/master/Test/C%2B%2B/gcc_5.3_static_template_init_bug gcc 5.3, cmake In main.cpp compare with and without load_lib*() lines. Description: Lib loading behavior changed between 5.1 and 5.3. Have to force load so/dlls via dummy method calls now. Not transparent and not expected behavior. Hope for an insight and/or a fix. Similar: issue BUG_ID 4342.
[Bug c++/60585] Virtual function related memory access errors with multiple virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60585 Andris Pavenis changed: What|Removed |Added Known to fail|4.8.2, 4.9.0|4.8.5, 4.9.3 --- Comment #2 from Andris Pavenis --- I cannot reproduce problem with: - gcc-versio 6.0.0 20151222 (experimental) (GCC) - gcc-versio 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC) on Fedora 23 x86_64 (tried also -m32) I can still reproduce it with my builds of gcc-4.8.5 and gcc-4.9.3. So it seems that the problem is fixed
[Bug target/67710] FAIL: gcc.dg/darwin-*version-*.c (test for excess errors) with Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67710 Iain Sandoe changed: What|Removed |Added Attachment #37060|0 |1 is obsolete|| --- Comment #7 from Iain Sandoe --- Created attachment 37184 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37184&action=edit revised fix So this is based on Rainer's patch… A/ Newer versions of ld64 check the min_version command, and newer versions of the system assembler inserts this in response to "-mmacosx-version-min=" on the assembler line. Unless one makes sensible versions, some object is bound to conflict. B/ Additionally, there's a difference in behaviour between "as" and "ld" when presented with xx.yy.zz (ld truncates to xx.yy, as doesn't); net result is that one needs to pass a truncated version to "as". So (if the assembler supports minversion commands) (a) provide a truncated minversion (as asm_macosx_version_min, which is a driver-only var). (b) pass this to "as" (c) Update tests to determine 'HAVE_AS_MMACOSX_VERSION_MIN_OPTION' (Rainer's patch) (d) For some reason the testcases are "run" (it's not obvious they need to be, they are checking compile-time issues) - anyway, to preserve the status quo, I've left them as exec. However, the minimum version that can be code-gened for is target-dependent (there are no x86 versions before 10.4, for example). To avoid conflicts where the "as" is assuming some minimum, I've set the testversion to 10.5 (which is supported by all the archs we have) (e) We need to ensure that libgcc and crts are generated with a sufficiently old minversion not to conflict. Works For Me(™) on 10.10 with XC7.2 and 10.8.5 with XC5.1.1
[Bug fortran/67779] Strange ordering with strings in extended object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779
--- Comment #13 from Paul Thomas ---
(In reply to Thomas Koenig from comment #11)
> Created attachment 37182 [details]
> More simplified test case
>
> This illustrates the problem - the array is passed wrong on
> the first call to the subroutine.
>
> Output:
>
> array on input
> 5 1 4 3 2
> array on input
> 1 4 3 2
> array on input
> 1 4 3
> array on input
> 1 4
> array on input
> 1
The call to quicksort from the main program generates:
class.15._vptr = (struct __vtype_myclass_def_Myclass * {ref-all})
&__vtab_myclass_def_Mysortable;
parm.16.dtype = 297;
parm.16.dim[0].lbound = 1;
parm.16.dim[0].ubound = 5;
parm.16.dim[0].stride = 1;
parm.16.data = (void *) &array[0];
parm.16.offset = -1;
class.15._data = parm.16;
quicksort (&class.15);
whereas the recursive call to self is:
parm.11.dim[0].lbound = 1;
parm.11.dim[0].ubound = D.3501;
parm.11.dim[0].stride = NON_LVALUE_EXPR ;
parm.11.data = NON_LVALUE_EXPR _data.data>;
parm.11.offset = 0;
class.12._data = VIEW_CONVERT_EXPR(parm.11);
class.12._vptr = array->_vptr;
quicksort (&class.12);
It is the offset being set to zero, rather than -1, that does the damage.
Paul
[Bug tree-optimization/69070] [6 Regression] ICE: tree check: expected real_cst, have ssa_name in gimple_expand_builtin_pow, at tree-ssa-math-opts.c:1541 with -fsignaling-nans and powl()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69070 Jakub Jelinek changed: What|Removed |Added CC||ssaraswati at gcc dot gnu.org Target Milestone|--- |6.0
[Bug tree-optimization/69070] [6 Regression] ICE: tree check: expected real_cst, have ssa_name in gimple_expand_builtin_pow, at tree-ssa-math-opts.c:1541 with -fsignaling-nans and powl()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69070 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-12-29 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 37183 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37183&action=edit gcc6-pr69070.patch Caused by r231901. Untested fix attached. IMHO if the first argument is not a REAL_CST, then the optimization might transform the pow into say sqrt, cbrt, multiplication etc., but all those should still raise exceptions on sNaN.
[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69011 --- Comment #10 from vehre at gcc dot gnu.org --- Author: vehre Date: Tue Dec 29 13:20:37 2015 New Revision: 231992 URL: https://gcc.gnu.org/viewcvs?rev=231992&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2015-12-29 Andre Vehreschild PR fortran/69011 * gfortran.dg/allocate_with_source_16.f90: New test. gcc/fortran/ChangeLog: 2015-12-29 Andre Vehreschild PR fortran/69011 * trans-stmt.c (gfc_trans_allocate): Unwrap a NOP_EXPR to make sure the actual type of the source=-expr is used when it is of class type. Furthermore prevent an ICE. Added: trunk/gcc/testsuite/gfortran.dg/allocate_with_source_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/69078] New: [C++14] function local static not initialized when only used in a generic/variadic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69078
Bug ID: 69078
Summary: [C++14] function local static not initialized when
only used in a generic/variadic lambda
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mar-bwTmhx at uchuujin dot de
Target Milestone: ---
The following reduced testcase shows that g++ doesn't initialize the local
static "instance". The original testcase is from a embedded arm usecase with
gcc 5.1.2 but this testcase is for a standard environment. As i don't have a
recent enough gcc for desktop i tested via
http://melpon.org/wandbox/permlink/gl8MdzUusCZtO7Ru with gcc version set to 6.0
HEAD
compilation: g++ prog.cc -Wall -Wextra -O2 -march=native -std=gnu++1z
Of interest might be that g++ also emits a wrong warning:
prog.cc: In function 'int main()':
prog.cc:20:18: warning: variable 'instance' set but not used
[-Wunused-but-set-variable]
static Class instance = { probe };
^~~~
This program outputs:
0x600ba8 data: (nil)
While expected output would with the '(nil)' replaced by a address of the probe
function.
When enabling the commented use of 'instance' in the normal function body (1)
of main the output is an even stranger:
0x600bd8 data: 0x400710
0x600bc8 data: (nil)
Only when rewriting the code to use an non generic lambda the bug disappears.
(http://melpon.org/wandbox/permlink/MUbb2tHz9EJCOF44) (i.e. funUser([](int p) {
user(instance, p); });
#include
struct Class {
Class(void (*_param)()) : data(_param) {}
void (*data)();
};
void funUser(void (*test)(int)) {
test(60);
}
void user(Class& c, int i) {
(void)i;
printf("%p data: %p\n", &c, c.data);
}
void probe() {}
int main() {
static Class instance = { probe };
//user(instance, 0); // (1)
funUser([](auto... p) {
user(instance, p...);
});
}
[Bug fortran/67779] Strange ordering with strings in extended object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779 --- Comment #12 from vehre at gcc dot gnu.org --- That rings a bell. I feel like already have done some work on a similar issue. I will take a look, when I have some time left.
[Bug fortran/67779] Strange ordering with strings in extended object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779 --- Comment #11 from Thomas Koenig --- Created attachment 37182 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37182&action=edit More simplified test case This illustrates the problem - the array is passed wrong on the first call to the subroutine. Output: array on input 5 1 4 3 2 array on input 1 4 3 2 array on input 1 4 3 array on input 1 4 array on input 1
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
--- Comment #37 from Sergei Trofimovich ---
The patch also fixes this old bug:
https://bugzilla.redhat.com/show_bug.cgi?id=33354
Despite being marked as fixed it fails on modern toolchain with slight
overflow.
Address of local constant was done over .got as well:
.c source:
static char *s90;
void f() { s90 = "string 90"; }
Compiled as gcc -fpic -S.
before:
.sbss
s90:
.skip 8
.section.rodata
.LC0:
stringz "string 90"
.text
f:
...
addl r14 = @gprel(s90#), gp
addl r15 = @ltoffx(.LC0), r1
ld8.mov r15 = [r15], .LC0
st8 [r14] = r15
...
after:
.sbss
s90:
.skip 8
.section.rodata
.LC0:
stringz "string 90"
.text
f:
...
addl r14 = @gprel(s90#), gp
movl r15 = @gprel(.LC0)
add r15 = r1, r15
st8 [r14] = r15
[Bug tree-optimization/61203] [4.9/5/6 Regression] g++.old-deja/g++.jason/rvalue2.C FAILs with -O2 -fno-inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61203 --- Comment #10 from Zdenek Sojka --- (In reply to Zdenek Sojka from comment #9) > (In reply to Andrew Pinski from comment #8) > > This does not fail on the trunk or 5.3 on aarch64-linux-gnu. > > It is failing for me on 4.7 and newer for all tested targets, that is: > Ah yes, sorry, the original testcase is still failing, but the reduced testcase does not fail for 5 and trunk.
[Bug tree-optimization/61203] [4.9/5/6 Regression] g++.old-deja/g++.jason/rvalue2.C FAILs with -O2 -fno-inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61203 --- Comment #9 from Zdenek Sojka --- (In reply to Andrew Pinski from comment #8) > This does not fail on the trunk or 5.3 on aarch64-linux-gnu. It is failing for me on 4.7 and newer for all tested targets, that is: for 4.9, 5, trunk: aarch64-unknown-linux-gnu armv7a-hardfloat-linux-gnueabi x86_64-pc-linux-gnu i686-pc-linux-gnu powerpc-unknown-linux-gnu powerpc64-unknown-linux-gnu sparc-unknown-linux-gnu sparc64-unknown-linux-gnu x86_64-pc-linux-gnux32 for 4.7, 4.8: x86_64-pc-linux-gnu The command line is: $ $CXX -O2 -fno-inline rvalue2.ii $ ./a.out # QEMU userspace emulation for non-x86 targets $ echo $? 2 The branches are from around r231954. $ aarch64-unknown-linux-gnu-g++ -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-g++ COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-231954-checking-yes-rtl-df-nographite-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/6.0.0/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld --with-as=/usr/bin/aarch64-unknown-linux-gnu-as --with-sysroot=/usr/aarch64-unknown-linux-gnu --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-231954-checking-yes-rtl-df-nographite-aarch64 Thread model: posix gcc version 6.0.0 20151225 (experimental) (GCC)
[Bug tree-optimization/67781] [5/6 Regression] wrong code generated on big-endian with -O1 -fexpensive-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67781 --- Comment #10 from Mikael Pettersson --- (In reply to Thomas Preud'homme from comment #9) > I have a patch that seems to be working. Running regression testing and > bootstrap now. Is there any progress on that patch?
