[Bug middle-end/63926] [5 Regression] ICE in estimate_edge_growth, at ipa-inline.h:300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63926 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Depends on||63470 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- most likely dup, to be checked after the fix for PR63470
[Bug target/64030] New: some libiberty sources includes stdio.h prior to config.h causing redefined symbol warnings on i?86-*-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64030 Bug ID: 64030 Summary: some libiberty sources includes stdio.h prior to config.h causing redefined symbol warnings on i?86-*-solaris2.11 Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: richard at netbsd dot org Created attachment 34075 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34075action=edit patches to hex.c and xstrerror.c Please find two patches attached to reduce large-file related warnings on SunOS i386 when building the libiberty component...
[Bug tree-optimization/64031] New: Vectorization of max/min is not robust enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64031
Bug ID: 64031
Summary: Vectorization of max/min is not robust enough
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jacques-henri.jourdan at inria dot Fr
The following code is sucessfully vectorized (using the minps instruction):
const int SIZE = 115;
void test9(float * b)
{
unsigned i;
float *y =__builtin_assume_aligned(b, 16);
for (i = 0; i SIZE; i++)
{
float f = y[i];
float f2 = f f*f ? f : f*f;
y[i] = f2;
}
}
But not the following slightly modified version:
void test9(float * b)
{
unsigned i;
float *y =__builtin_assume_aligned(b, 16);
for (i = 0; i SIZE; i++)
{
float f = y[i];
float f2 = f f*f ? f : f*f;
y[i] = f2*f2;
}
}
Actually, it seems like vectorization of max/min operations fails as soon as
some computation is done with the result of this min/max operation.
[Bug c++/63905] redundant fields left in gcc/cp/cp-tree.h:lang_decl_fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63905 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-11-23 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug tree-optimization/64031] Vectorization of max/min is not robust enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64031 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- -ffast-math lets it vectorize (using min directly). Otherwise, for the first test, ifcvt gives (ab)?a:b which is vectorized as such, but for the second test, it doesn't unless we pass -fno-trapping-math. That seems a bit inconsistent.
[Bug c++/63959] G++ misreports volatile int as trivially copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63959 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|ville.voutilainen at gmail dot com | Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed then.
[Bug libstdc++/63497] std::regex can't handle [^class] correctly and cause runtime crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63497 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|moophy at foxmail dot com | Component|c++ |libstdc++ --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Tim, please either apply to 4_9-branch too (ask Jon?), or just close the bug as fixed for 5.0.
[Bug c++/63423] internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63423 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.9.0, 5.0 Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Already fixed for 4.9.0 and 5.0.
[Bug c++/63385] internal compiler error: in pop_binding, at cp/name-lookup.c for implicitly captured variable called closure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63385 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Jason, can we resolve this?
[Bug c++/63216] gcc crash: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63216 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Feedback not forthcoming.
[Bug c++/60943] [C++1y] Return type deduction interferes with ref-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60943 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-23 CC|Casey at Carter dot net| Ever confirmed|0 |1
[Bug c++/61019] ICE: incomplete type of class template as pseudo-destructor-name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61019 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-23 Ever confirmed|0 |1
[Bug c++/57758] gcc accepts incorrect in-class brace initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57758 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Dup then. *** This bug has been marked as a duplicate of bug 48483 ***
[Bug c++/48483] Construct from yourself w/o warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||lundberj at gmail dot com --- Comment #21 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 57758 has been marked as a duplicate of this bug. ***
[Bug c++/57919] [C++11] Alias templates cause partial specialization to erroneously fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57919 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-23 Ever confirmed|0 |1
[Bug c++/63875] Bogus unused-but-set-parameter warning when expanding a variadic template argument pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63875 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|tejohnson at google dot com|jakub at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Let's add Jakub.
[Bug ipa/63671] [5 Regression] 21% tramp3d-v4 performance hit due to -fdevirtualize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63671 --- Comment #12 from Jan Hubicka hubicka at gcc dot gnu.org --- Created attachment 34076 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34076action=edit Patch to fix aliases and dead code removal. One of problem was the abstract origin tracking already solved. Other problem is some implementation lazyness WRT aliases that are now used more pervasively (by ICF and also by visibility code). The attached patch makes -fdevirtualize -O3 run fast again, but now -fno-devirtualize -O3 regresses (and even with Martin's heap on sreals). What a fun! :)
[Bug c++/63786] crash on argument pack in switch case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63786 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-23 CC|rhainin1 at binghamton dot edu | Ever confirmed|0 |1
[Bug c++/63940] C++ constexpr errors on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63940 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2014-11-23 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #5 from David Edelsohn dje at gcc dot gnu.org --- The failures continue to appear on AIX. AIX defaults to 32 bit. Maybe the tests on x86-64 need -m32 to see additional causes of the problem?
[Bug c++/63472] transaction_atomic within while loop causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|spear at cse dot lehigh.edu| Severity|critical|normal
[Bug ipa/61324] [5 Regression] ICE: SIGSEGV at ipa-comdats.c:321 with -fno-use-cxa-atexit -fkeep-inline-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61324 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- It is caused by r210597.
[Bug c/64032] New: FAIL: gcc.dg/undefined-loop-2.c (test for warnings, line 18)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64032 Bug ID: 64032 Summary: FAIL: gcc.dg/undefined-loop-2.c (test for warnings, line 18) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdi r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/undefined-loop-2.c -fno-diag nostics-show-caret -fdiagnostics-color=never -O2 -Waggressive-loop-optimizatio ns -S -o undefined-loop-2.s(timeout = 300) spawn /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/ /home/ dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/undefined-loop-2.c -fno-diagnostics-show-c aret -fdiagnostics-color=never -O2 -Waggressive-loop-optimizations -S -o undefin ed-loop-2.s /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/undefined-loop-2.c: In function 'foo ': /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/undefined-loop-2.c:19:8: warning: lo op exit may only be reached after undefined behavior [-Waggressive-loop-optimiza tions] /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/undefined-loop-2.c:17:17: note: poss ible undefined statement is here /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/undefined-loop-2.c:16:17: note: poss ible undefined statement is here output is: /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/undefined-loop-2.c: In function 'foo ': /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/undefined-loop-2.c:19:8: warning: lo op exit may only be reached after undefined behavior [-Waggressive-loop-optimiza tions] /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/undefined-loop-2.c:17:17: note: possible undefined statement is here /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/undefined-loop-2.c:16:17: note: possible undefined statement is here PASS: gcc.dg/undefined-loop-2.c (test for warnings, line 16) PASS: gcc.dg/undefined-loop-2.c (test for warnings, line 17) FAIL: gcc.dg/undefined-loop-2.c (test for warnings, line 18) PASS: gcc.dg/undefined-loop-2.c (test for warnings, line 19) PASS: gcc.dg/undefined-loop-2.c (test for excess errors)
[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018 --- Comment #25 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #23) 2. we have so many versions, different layouts and version-specific issues, that I think it's time to reorganise our GCC extensions library to meet these different requirements than to limp along with kludge after kludge. As a first step to achieving this, we should decide what targets we support (building on, and compiling for via -mmacosx-version-min). Given the current state of OS X versions, I see two options: a) We keep PowerPC, and thus drop support for 10.4 and earlier (since 10.5 is the last OS X version to support ppc). This helps remove some old stuff (I'll attach a work-in-progress patch). b) We drop PowerPC, then it makes sense to drop support for 10.5 too. This would really simplify things in term of specs and those various support/ext libraries. Given that 10.5 and PowerPC have been vendor-unsupported for more than 3 years at this point, that we don't have regular testing (and bootstrap on those machines is quite slow), I'd say we should focus our energy on providing newer compilers for the newer machines/OSes. So I would suggest we mark powerpc-darwin as obsolete in GCC 5, and remove it for GCC 6. (Or maybe, we even skip the obsolete part and simply drop it?) What do you guys think?
[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018 --- Comment #26 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Created attachment 34077 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34077action=edit Patch removing 10.4 and earlier support from our specs/driver
[Bug rtl-optimization/64033] New: [5.0 Regression] ICE: in expand_expr_addr_expr_1, at expr.c:7741
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64033 Bug ID: 64033 Summary: [5.0 Regression] ICE: in expand_expr_addr_expr_1, at expr.c:7741 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++ -B/test/gnu /gcc/objdir/gcc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/tort ure/pr58369.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc+ + -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp- hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/t est/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/ backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O s-S -o pr58369.s(timeout = 300) spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++ -B/test/gnu/gcc/objdir/g cc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/torture/pr58369.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/test/gnu/g cc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/te st/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc /libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/tes t/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -Os -S -o pr58369.s /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/torture/pr58369.C: In function 'T ellint_ rj_imp(T, T, T, T, Policy) [with T = long double; Policy = PolicyA]': /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/torture/pr58369.C:59:3: internal compiler error: in expand_expr_addr_expr_1, at expr.c:7741 libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate.
[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018 --- Comment #27 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Francois-Xavier Coudert from comment #25) (In reply to Iain Sandoe from comment #23) 2. we have so many versions, different layouts and version-specific issues, that I think it's time to reorganise our GCC extensions library to meet these different requirements than to limp along with kludge after kludge. As a first step to achieving this, we should decide what targets we support (building on, and compiling for via -mmacosx-version-min). Given the current state of OS X versions, I see two options: a) We keep PowerPC, and thus drop support for 10.4 and earlier (since 10.5 is the last OS X version to support ppc). This helps remove some old stuff (I'll attach a work-in-progress patch). I have a patch in my Q that moves the only ppc-specific 10.4 stuff to a separate target fragment in libgcc/config/rs6000 - at that point, it becomes academic to the discussion on supporting old versions since it has 0 impact on work going forward. b) We drop PowerPC, then it makes sense to drop support for 10.5 too. This would really simplify things in term of specs and those various support/ext libraries. Given that 10.5 and PowerPC have been vendor-unsupported for more than 3 years at this point, that we don't have regular testing (and bootstrap on those machines is quite slow), I'd say we should focus our energy on providing newer compilers for the newer machines/OSes. I think we are (realistically) focussed on the newer versions - since we all have limited hardware resources. However, there's a bunch of perfectly function hardware out there that is more usable with older system installs. So I would suggest we mark powerpc-darwin as obsolete in GCC 5, and remove it for GCC 6. (Or maybe, we even skip the obsolete part and simply drop it?) The general approach here (as recommended by Mike) has been that we don't kill versions intentionally; having said that when stuff stops getting tested one can assume it's quite quickly broken. There's no work involved in supporting 10.2..10.4 since none of us making any attempt to keep them going (David Fang does still test releases on 10.4, for fink, but that's the only thing I know of). As for 10.5 - I have personally both ppc and x86 10.5 hardware in daily use ( and not just for compiler building ;) ) - these are machines which just don't have enough resources (or are ppc) to update further. I will continue to test (at a lower level) and fix stuff on ppc-darwin9 so long as the QuadG5 is still in use. Going forward - there are kind of three groupings: = 10.4 [this possibly requires support for stubs etc.] It's highly debatable whether 10.4 is supportable without using odcctools (i.e. 10.5's assembler and linker) - so, again, I'm not going to worry about it. Someone sufficiently interested in making it work can put the effort in. 10.5/10.6 - These are the remaining two gcc-based systems and we can deal with them with existing procedures. Likely we should emulate the way that the system libgcc_s does the forwarding of EH stuff to libSystem as well (10.6). 10.5 has EH hassles that can only realistically be solved by replacing the /usr/lib/libgcc_s.dylib (but I think anyone sufficiently enthusiastic to work there, will be willing to do that). I intend to post onto github a suitable replacement lib - it seems that they will allow binaries there. 10.7+ - (albeit 10.7 is somewhat transitionary) here we need to stop building the eh stuff into libgcc, we probably need to split the emultls stuff into a crt. We might want to consider not having a shared lib for the gcc crt at all here (i.e. do much like clang does with the compiler-rt and just append a libgcc.a). The only reason we *need* a dylib at present is the EH (which is unused for these systems) and emults bits (which could be dealt with differently). I don't think that the argument that the exes might grow by a few kb is terribly significant on modern systems. It's not been the case so far in gcc-5 that the old systems have been the painful ones to keep flying ;) I'm not a fan of supporting only N and N-1 that's one of the suckiest things about the vendor's tools. Maybe we should open an enhancement PR for rationalising libgcc and crts across the darwin editions.
[Bug bootstrap/63703] [4.9.2 Regression] cc1: internal compiler error: in init_reg_sets, at reginfo.c:178
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703 --- Comment #7 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Francois-Xavier Coudert from comment #6) There is no lldb here, and also no direct 'bt' available. I used gdb with a break point: % cd /tmp/lcl/tmp/gcc/obj % % grep -n 'gcc_assert (sizeof reg_names == sizeof initial_reg_names)' ../gcc-4.9.2/gcc/reginfo.c 178: fprintf(stderr, %s:%u %u %u\n, __FILE__, __LINE__, sizeof reg_names, sizeof initial_reg_names); gcc_assert (sizeof reg_names == sizeof initial_reg_names); % % cat test.c /* nothing */ % % /usr/bin/cc --version powerpc-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % % ./gcc/cc1 test.c /tmp/lcl/tmp/gcc/gcc-4.9.2/gcc/reginfo.c:178 596 468 cc1: internal compiler error: in init_reg_sets, at reginfo.c:178 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. % % /usr/bin/gdb ./gcc/cc1 GNU gdb 6.3.50-20050815 (Apple version gdb-967) (Tue Jul 14 02:15:14 UTC 2009) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-apple-darwin...Reading symbols for shared libraries .. done (gdb) break reginfo.c:178 Breakpoint 1 at 0xa4df88: file /tmp/lcl/tmp/gcc/gcc-4.9.2/gcc/reginfo.c, line 178. (gdb) run test.c Starting program: /Users/denis/darlcl/tmp/gcc/obj/gcc/cc1 test.c Reading symbols for shared libraries +. done Breakpoint 1, init_reg_sets () at /tmp/lcl/tmp/gcc/gcc-4.9.2/gcc/reginfo.c:178 178 fprintf(stderr, %s:%u %u %u\n, __FILE__, __LINE__, sizeof reg_names, sizeof initial_reg_names); gcc_assert (sizeof reg_names == sizeof initial_reg_names); (gdb) bt #0 init_reg_sets () at /tmp/lcl/tmp/gcc/gcc-4.9.2/gcc/reginfo.c:178 #1 0x00b5a074 in general_init (argv0=0xb70c /Users/denis/darlcl/tmp/gcc/obj/gcc/cc1) at /tmp/lcl/tmp/gcc/gcc-4.9.2/gcc/toplev.c:1169 #2 0x00b5bda0 in toplev_main (argc=2, argv=0xb644) at /tmp/lcl/tmp/gcc/gcc-4.9.2/gcc/toplev.c:1961 #3 0x010265fc in main (argc=2, argv=0xb644) at /tmp/lcl/tmp/gcc/gcc-4.9.2/gcc/main.c:36 Current language: auto; currently c++ (gdb) cont Continuing. /tmp/lcl/tmp/gcc/gcc-4.9.2/gcc/reginfo.c:178 596 468 cc1: internal compiler error: in init_reg_sets, at reginfo.c:178 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Program exited with code 04. (gdb) quit % Hope this helps, Denis Excoffier.
[Bug c++/63940] C++ constexpr errors on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63940 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com --- 32-bit x86 looks OK: https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg02534.html https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg02537.html
[Bug bootstrap/63703] [4.9.2 Regression] cc1: internal compiler error: in init_reg_sets, at reginfo.c:178
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703
Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed|2014-11-22 00:00:00 |2014-11-23
CC||edmarwjr at gcc dot gnu.org,
||rohitarulraj at gmail dot com
--- Comment #8 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
I've reproduced this with a cross-compiler targeting powerpc-apple-darwin9: the
cc1 built fails at startup, with any source file, as shown above.
Then bisection shows this 4.9.2 regression is due to revision 213597:
2014-08-04 Rohit rohitarul...@freescale.com
* config/rs6000/rs6000.c
(rs6000_reg_names) : Add SPE high register names.
(alt_reg_names) : Likewise.
(rs6000_dwarf_register_span) : For SPE high registers, replace
dwarf register numbers with GCC hard register numbers.
(rs6000_init_dwarf_reg_sizes_extra) : Likewise.
(rs6000_dbx_register_number): For SPE high registers, return dwarf
register number for the corresponding GCC hard register number.
* config/rs6000/rs6000.h
(FIRST_PSEUDO_REGISTER) : Update based on 32 newly added GCC hard
register numbers for SPE high registers.
(DWARF_FRAME_REGISTERS) : Likewise.
(DWARF_REG_TO_UNWIND_COLUMN) : Likewise.
(DWARF_FRAME_REGNUM) : Likewise.
(FIXED_REGISTERS) : Likewise.
(CALL_USED_REGISTERS) : Likewise.
(CALL_REALLY_USED_REGISTERS) : Likewise.
(REG_ALLOC_ORDER) : Likewise.
(enum reg_class) : Likewise.
(REG_CLASS_NAMES) : Likewise.
(REG_CLASS_CONTENTS) : Likewise.
(SPE_HIGH_REGNO_P) : New macro to identify SPE high registers.
I looked into reginfo.c: array initial_reg_names has 117 elements:
static const char *const initial_reg_names[] = { r0, r1, r2, r3, r4,
r5, r6, r7, r8, r9, r10, r11, r12, r13, r14, r15, r16,
r17, r18, r19, r20, r21, r22, r23, r24, r25, r26, r27,
r28, r29, r30, r31, f0, f1, f2, f3, f4, f5, f6, f7,
f8, f9, f10, f11, f12, f13, f14, f15, f16, f17, f18,
f19, f20, f21, f22, f23, f24, f25, f26, f27, f28, f29,
f30, f31, mq, lr, ctr, ap, cr0, cr1, cr2, cr3, cr4,
cr5, cr6, cr7, xer, v0, v1, v2, v3, v4, v5, v6, v7,
v8, v9, v10, v11, v12, v13, v14, v15, v16, v17, v18,
v19, v20, v21, v22, v23, v24, v25, v26, v27, v28, v29,
v30, v31, vrsave, vscr, spe_acc, spefscr, sfp, tfhar, tfiar,
texasr };
while reg_names (this_target_hard_regs-x_reg_names) has size
FIRST_PSEUDO_REGISTER, which equals 149.
[Bug target/53976] [SH] Unnecessary clrt/sett after bt/bf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53976 --- Comment #9 from Oleg Endo olegendo at gcc dot gnu.org --- Created attachment 34078 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34078action=edit Reduced problem from linux kernel This one exposes a problem of the sh_optimize_sett_clrt RTL pass, where it will try to visit/evaluate too many basic blocks/edges and eventually run out of memory.
[Bug middle-end/62247] [5.0 Regression] FAIL: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62247 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org --- We now have: FAIL: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)?[ \t]_?_ ZTI4Heya FAIL: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)?[ \t]_?_ ZTIN4Heya1AE FAIL: g++.dg/abi/anon3.C -std=c++11 scan-assembler .weak(_definition)?[ \t]_?_ ZTI4Heya FAIL: g++.dg/abi/anon3.C -std=c++11 scan-assembler .weak(_definition)?[ \t]_?_ ZTIN4Heya1AE FAIL: g++.dg/abi/anon3.C -std=c++14 scan-assembler .weak(_definition)?[ \t]_?_ ZTI4Heya FAIL: g++.dg/abi/anon3.C -std=c++14 scan-assembler .weak(_definition)?[ \t]_?_ ZTIN4Heya1AE FAIL: g++.dg/abi/rtti3.C -std=c++98 scan-assembler .weak[ \t]_?_ZTSPP1A FAIL: g++.dg/abi/rtti3.C -std=c++11 scan-assembler .weak[ \t]_?_ZTSPP1A FAIL: g++.dg/abi/rtti3.C -std=c++14 scan-assembler .weak[ \t]_?_ZTSPP1A as of r217956.
[Bug middle-end/62247] [5.0 Regression] FAIL: g++.dg/abi/anon3.C -std=c++98 scan-assembler .weak(_definition)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62247 --- Comment #2 from John David Anglin danglin at gcc dot gnu.org --- Created attachment 34079 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34079action=edit Assembler output
[Bug bootstrap/63703] [4.9.2/5 Regression] Bootstrap broken on powerpc-apple-darwin, cc1: internal compiler error: in init_reg_sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||iains at gcc dot gnu.org Summary|[4.9.2 Regression] cc1: |[4.9.2/5 Regression] |internal compiler error: in |Bootstrap broken on |init_reg_sets, at |powerpc-apple-darwin, cc1: |reginfo.c:178 |internal compiler error: in ||init_reg_sets --- Comment #9 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- This also affects trunk, rendering the compiler unusable and breaking bootstrap.
[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018 --- Comment #28 from howarth at bromo dot med.uc.edu --- (In reply to Iain Sandoe from comment #27) 10.7+ - (albeit 10.7 is somewhat transitionary) here we need to stop building the eh stuff into libgcc, we probably need to split the emultls stuff into a crt. We might want to consider not having a shared lib for the gcc crt at all here (i.e. do much like clang does with the compiler-rt and just append a libgcc.a). The only reason we *need* a dylib at present is the EH (which is unused for these systems) and emults bits (which could be dealt with differently). I don't think that the argument that the exes might grow by a few kb is terribly significant on modern systems. We should also consider what to do about the compact unwinder (which we currently disable by passing -no_compact_unwind to the LINK_GCC_C_SEQUENCE_SPEC in gcc/config/darwin10.h). I assume at some point, perhaps when the legacy libstdc++ support is removed from OS X, that the compatibility unwinder, which we currently use, will be fully deprecated.
[Bug middle-end/60102] [4.9/5 Regression] powerpc fp-bit ices at dwf_regno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-23 CC||fxcoudert at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #20 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- The commits from comments #16 and #17 broke the compiler (and bootstrap) on powerpc-apple-darwin9: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703
[Bug bootstrap/63703] [4.9.2/5 Regression] Bootstrap broken on powerpc-apple-darwin, cc1: internal compiler error: in init_reg_sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703 --- Comment #10 from Iain Sandoe iains at gcc dot gnu.org --- sorry I fixed this months ago locally.. I will push a patch to fix ASAP. note that there are 4 bootstrap breakers on PPC (trunk) 1. this 2. libcc1 (same fail as x86) 3. libiberty needs some options massage to build PIC properly (will also break i686-darwin*) 4. libada is currently looking for __environ and needs a modification to the makefile, affects at least 10.5, 10.6
[Bug bootstrap/63703] [4.9.2/5 Regression] Bootstrap broken on powerpc-apple-darwin, cc1: internal compiler error: in init_reg_sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63703 --- Comment #11 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #10) note that there are 4 bootstrap breakers on PPC (trunk) More annoying, I think, is that this one is also on 4.9, and actually made it into the 4.9.2 release.
[Bug libstdc++/63497] std::regex can't handle [^class] correctly and cause runtime crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63497 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, I think this is OK for the branch
[Bug target/55023] hppa: wrong code generated with tail call optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55023
--- Comment #12 from John David Anglin danglin at gcc dot gnu.org ---
Breakpoint 3, delete_dead_store_insn (insn_info=0x1b5ccf0)
at ../../gcc/gcc/dse.c:948
948 if (!dbg_cnt (dse))
(gdb) p *insn_info
$3 = {cannot_delete = false, wild_read = false, non_frame_wild_read = false,
frame_read = false, stack_pointer_based = false,
contains_cselib_groups = false, insn = 0xfad93f28, store_rec = 0x1b60288,
read_rec = 0x0, fixed_regs_live = 0x1b52234, prev_insn = 0x1b5ccd0,
next_local_store = 0x1b5ccb0}
(gdb) p debug_rtx (insn_info-insn)
(insn 31 27 50 2 (set (mem:SI (reg/f:SI 115) [0 S4 A64])
(reg:SI 125)) pr55023.c:17 40 {*pa.md:2204}
(expr_list:REG_DEAD (reg:SI 125)
(expr_list:REG_DEAD (reg/f:SI 115)
(nil
$4 = void
[Bug tree-optimization/64034] New: [5 regression] cc1 stack-overflow with -O2 -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64034 Bug ID: 64034 Summary: [5 regression] cc1 stack-overflow with -O2 -fsanitize=undefined Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sirl at gcc dot gnu.org Created attachment 34080 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34080action=edit testcase to reproduce the bug The attached testcase segfaults (valgrind says stack-overflow) when compiled for x86_64 with -O2 -fsanitize=undefined. gcc-4.9.2 compiles the testcase without problems. gdb backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00bf990c in copygeneric_wide_intwide_int_storage, generic_wide_intwide_int_ref_storagefalse (y=..., x=...) at ../../gcc/wide-int.h:1660 1660xval[i] = yval[i]; (gdb) bt #0 0x00bf990c in copygeneric_wide_intwide_int_storage, generic_wide_intwide_int_ref_storagefalse (y=..., x=...) at ../../gcc/wide-int.h:1660 #1 zextgeneric_wide_intwide_int_ref_storagefalse (offset=1023, x=...) at ../../gcc/wide-int.h:2067 #2 wi::fits_to_tree_pgeneric_wide_intwide_int_ref_storagefalse (x=..., type=type@entry=0x76931d20) at ../../gcc/tree.h:4760 #3 0x00bec36f in force_fit_type (type=0x76931d20, cst=..., overflowable=1, overflowed=optimized out) at ../../gcc/tree.c:1237 #4 0x006c2dbf in fold_negate_const (arg0=arg0@entry=0x7695c4f8, type=type@entry=0x76931d20) at ../../gcc/fold-const.c:15423 #5 0x006f76eb in fold_negate_expr (loc=loc@entry=0, t=t@entry=0x7695c4f8) at ../../gcc/fold-const.c:555 #6 0x006f8d28 in negate_expr (t=0x7695c4f8) at ../../gcc/fold-const.c:775 #7 0x006da1bc in fold_binary_loc (loc=loc@entry=0, code=code@entry=MINUS_EXPR, type=type@entry=0x76931d20, op0=op0@entry=0x7624d8c0, op1=op1@entry=0x7695c4f8) at ../../gcc/fold-const.c:10450 #8 0x006eaafb in fold_build2_stat_loc (loc=0, code=MINUS_EXPR, type=0x76931d20, op0=0x7624d8c0, op1=0x7695c4f8) at ../../gcc/fold-const.c:14231 #9 0x007786a9 in generic_simplify (loc=0, code=optimized out, type=0x76931d20, op0=0x7624d8a0, op1=optimized out) at generic-match.c:3194 #10 0x006d6852 in fold_binary_loc (loc=loc@entry=0, code=code@entry=PLUS_EXPR, type=type@entry=0x76931d20, op0=op0@entry=0x7624d8a0, op1=op1@entry=0x7624d880) at ../../gcc/fold-const.c:9729 #11 0x006eaafb in fold_build2_stat_loc (loc=loc@entry=0, code=code@entry=PLUS_EXPR, type=type@entry=0x76931d20, op0=0x7624d8a0, op1=op1@entry=0x7624d880) at ../../gcc/fold-const.c:14231 #12 0x006da203 in fold_binary_loc (loc=loc@entry=0, code=code@entry=MINUS_EXPR, type=type@entry=0x76931d20, op0=op0@entry=0x7624d860, op1=op1@entry=0x7695c4f8) at ../../gcc/fold-const.c:10450 #13 0x006eaafb in fold_build2_stat_loc (loc=0, code=MINUS_EXPR, type=0x76931d20, op0=0x7624d860, op1=0x7695c4f8) at ../../gcc/fold-const.c:14231 #14 0x007786a9 in generic_simplify (loc=0, code=optimized out, type=0x76931d20, op0=0x7624d840, op1=optimized out) at generic-match.c:3194 #15 0x006d6852 in fold_binary_loc (loc=loc@entry=0, code=code@entry=PLUS_EXPR, type=type@entry=0x76931d20, op0=op0@entry=0x7624d840, op1=op1@entry=0x7624d820) at ../../gcc/fold-const.c:9729 #16 0x006eaafb in fold_build2_stat_loc (loc=loc@entry=0, code=code@entry=PLUS_EXPR, type=type@entry=0x76931d20, op0=0x7624d840, op1=op1@entry=0x7624d820) at ../../gcc/fold-const.c:14231 ... a lot similar frames follow, seems like a folding recursion. $ gcc-5 -v Using built-in specs. COLLECT_GCC=gcc-5 COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/5/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,fortran --with-gxx-include-dir=/usr/include/c++/5 --enable-ssp --disable-libssp --disable-libvtv --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-5 --without-system-libunwind --enable-multilib --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux Thread model: posix gcc version 5.0.0 20141118 (experimental) [trunk revision 217715] (SUSE Linux) Might be related to bug 63879, but the backtrace looks totally different.
[Bug tree-optimization/64034] [5 regression] cc1 stack-overflow with -O2 -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64034 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- This one also seems to be fixed by r217766.
[Bug c++/63203] Self-initialization of reference not diagnosed if it occurs within a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63203 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug c++/63940] C++ constexpr errors on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63940 --- Comment #7 from David Edelsohn dje at gcc dot gnu.org --- HJ, The test was not failing on Linux x86-64 nor x86-32. I sent pre-processed testcase from AIX that Jason was able to reproduce on Linux. But the fix did not solve the failure on AIX.
[Bug target/53976] [SH] Unnecessary clrt/sett after bt/bf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53976 --- Comment #10 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sun Nov 23 21:16:26 2014 New Revision: 217987 URL: https://gcc.gnu.org/viewcvs?rev=217987root=gccview=rev Log: gcc/ PR target/53976 * config/sh/sh_optimize_sett_clrt.cc (sh_optimize_sett_clrt::find_last_ccreg_values): Return bool instead of void. Abort at complex edges. (sh_optimize_sett_clrt::execute): Do nothing if find_last_ccreg_values returned false. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh_optimize_sett_clrt.cc
[Bug c++/64035] New: [C++11] ICE in reshape_init_r when using initializer list aggregate initialization for default function parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64035 Bug ID: 64035 Summary: [C++11] ICE in reshape_init_r when using initializer list aggregate initialization for default function parameters Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mail at jonasplatte dot de Created attachment 34081 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34081action=edit Test case (not using preprocessor directives, so not precompiled) gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc/src/gcc-4.9.2/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-isl-version-check --disable-cloog-version-check --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 4.9.2 (GCC) My system is a x86_64 arch linux, with linux 3.17.3-1-ARCH. Compiler invocation for the test case: g++ -std=c++11 test2.cpp -Wall -Wextra The exact error message I get (also added it to the test case as comment): test1.cpp:21:7: internal compiler error: in reshape_init_r, at cp/decl.c:5481 I tried changing -std to c++14 and adding -pedantic to see if they make a difference, which both don't.
[Bug target/53976] [SH] Unnecessary clrt/sett after bt/bf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53976 --- Comment #11 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sun Nov 23 21:45:18 2014 New Revision: 217989 URL: https://gcc.gnu.org/viewcvs?rev=217989root=gccview=rev Log: gcc/ Backport from mainline 2014-11-23 Oleg Endo olege...@gcc.gnu.org PR target/53976 * config/sh/sh_optimize_sett_clrt.cc (sh_optimize_sett_clrt::find_last_ccreg_values): Return bool instead of void. Abort at complex edges. (sh_optimize_sett_clrt::execute): Do nothing if find_last_ccreg_values returned false. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/sh/sh_optimize_sett_clrt.cc
[Bug target/64036] New: [SH] Evaluate re-enabling scheduling before RA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64036 Bug ID: 64036 Summary: [SH] Evaluate re-enabling scheduling before RA Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target: sh*-*-* The first instruction scheduling pass before register allocation has been disabled to work around some problems in sh.c (sh_option_override). Re-enabling it should be evaluated to see if the problems are still there and whether it is beneficial for the generated code.
[Bug c++/64037] New: Miscompilation with LTO and enum class : char parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64037
Bug ID: 64037
Summary: Miscompilation with LTO and enum class : char
parameter
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: js at alien8 dot de
Created attachment 34082
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34082action=edit
Minimal test case
On Linux with the x86-64 target, code that contains a byte-sized enum class as
a function parameter is miscompiled when -Os and -flto is enabled. A minimal
example is attached. I also attached g++ --verbose --version output for both
compilers where this triggers (4.9.1 and 4.9.2).
To reproduce the problem compile the attached source with:
g++ -std=gnu++11 -Os -flto test.cc -o test
Run ./test and you get this output: deadbe02
Expected output: 0002
The problem boils down to the fact that the third parameter to foo (see below)
is passed in DL (the rest of RDX is not cleared). In the function, no code is
emitted to clear the rest of RDX, but it is obviously assumed to be zero.
enum class X : unsigned char {
V = 2,
};
// noinline and noclone are only there to reduce the example. This
// also triggers without these annotations in larger projects.
void foo(unsigned out, unsigned a, X b) __attribute__((noinline,noclone));
void foo(unsigned out, unsigned a, X b)
{
out = static_castunsigned(b);
}
int main()
{
// Load obvious value into EDX
unsigned deadbeef = 0xDEADBEEF;
asm volatile ( : +d (deadbeef));
unsigned out;
foo(out, 2, X::V);
...
00400500 main:
400500:48 83 ec 18 subrsp,0x18
400504:ba ef be ad de movedx,0xdeadbeef - EDX is loaded
with some garbage
400509:48 8d 7c 24 0c leardi,[rsp+0xc]
40050e:b2 02movdl,0x2 - Parameter is
put in DL, without clearing RDX first
400510:be 02 00 00 00 movesi,0x2
400515:e8 0c 01 00 00 call 400626 foo(unsigned int,
unsigned int, X)
00400626 foo(unsigned int, unsigned int, X):
400626:89 17movDWORD PTR [rdi],edx - EDX still
contains remnants of 0xDEADBEEF here!
400628:c3 ret
[Bug c++/64037] Miscompilation with LTO and enum class : char parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64037 --- Comment #1 from Julian Stecklina js at alien8 dot de --- Created attachment 34083 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34083action=edit gcc --verbose --version for 4.9.1
[Bug c++/64037] Miscompilation with LTO and enum class : char parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64037 --- Comment #2 from Julian Stecklina js at alien8 dot de --- Created attachment 34084 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34084action=edit gcc --verbose --version for 4.9.2
[Bug c++/64037] Miscompilation with LTO and enum class : char parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64037 --- Comment #3 from Julian Stecklina js at alien8 dot de --- Created attachment 34085 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34085action=edit Miscompiled binary (built with 4.9.2)
[Bug target/64037] Miscompilation with LTO and enum class : char parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64037 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Component|c++ |target --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- This sounds like the target is expanding the two sides of the function call foo inconsistent with each other.
[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option, !GCC$ diagnostic (pragmas) and color
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054 --- Comment #19 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Author: manu Date: Sun Nov 23 23:47:42 2014 New Revision: 217992 URL: https://gcc.gnu.org/viewcvs?rev=217992root=gccview=rev Log: gcc/fortran/ChangeLog: 2014-11-23 Manuel López-Ibáñez m...@gcc.gnu.org PR fortran/44054 * decl.c (gfc_verify_c_interop_param): Use gfc_error_now_2. (gfc_set_constant_character_len): Use gfc_warning_now_2. * resolve.c (resolve_ordinary_assign): Likewise. * gfortran.h (warn_character_truncation): Do not declare here. * error.c (gfc_format_decoder): Handle %L. * lang.opt (Wcharacter-truncation): Add Var and LangEnabledBy. * options.c (gfc_init_options): Do not handle warn_character_truncation explicitly. (set_Wall): Likewise. (gfc_handle_option): Likewise. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/error.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/resolve.c
[Bug c/59708] clang-compatible checked arithmetic builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708 --- Comment #21 from dave.anglin at bell dot net --- On 22-Nov-14, at 2:31 AM, jakub at gcc dot gnu.org wrote: Is that with r217946 or later? This is now fixed on hppa-unknown-linux-gnu. -- John David Anglindave.ang...@bell.net
[Bug bootstrap/64023] [5 Regression] r216964 breaks bootstrap on darwin when using gcc as the bootstrap compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64023 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Keywords||patch Last reconfirmed|2014-11-22 00:00:00 |2014-11-24 Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #3 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Partial patch submitted: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02955.html It restores bootstrap with gcc as system compiler (and I think is more generic that fixing the issue in libcc1/Makefile.in). Even with that patch, there remains the silent issue of not linking statically when clang is the system compiler.
[Bug target/55023] hppa: wrong code generated with tail call optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55023 --- Comment #13 from John David Anglin danglin at gcc dot gnu.org --- Created attachment 34086 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34086action=edit Patch Testing...
[Bug bootstrap/64023] [5 Regression] r216964 breaks bootstrap on darwin when using gcc as the bootstrap compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64023 --- Comment #4 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Francois-Xavier Coudert from comment #3) Even with that patch, there remains the silent issue of not linking statically when clang is the system compiler. The underlying issue is that ld64 will always pick a .dylib over a .a when both are available. So pointing at the libstdc++ .libs dir isn't enough - we'll still link with the dylib. AFAIK the only solution available is to mention the full path to the static lib on the command line. Since clang does not do this for us (no -static-libstdc++) we'd have to cook up our own and drive it from some config that determines we are bootstrapping with clang. [That might be a useful variable to have anyway]
[Bug testsuite/64038] New: FAIL: gcc.dg/ipa/ipa-icf-5.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64038 Bug ID: 64038 Summary: FAIL: gcc.dg/ipa/ipa-icf-5.c (test for excess errors) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/ipa/ipa-icf-5.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fdump-ipa-icf -S -o ipa-icf-5.s(timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gc c/gcc/testsuite/gcc.dg/ipa/ipa-icf-5.c -fno-diagnostics-show-caret -fdiagnostics -color=never -O2 -fdump-ipa-icf -S -o ipa-icf-5.s /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/ipa/ipa-icf-5.c:4:21: fatal error: comple x.h: No such file or directory compilation terminated. compiler exited with status 1 output is: /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/ipa/ipa-icf-5.c:4:21: fatal error: comple x.h: No such file or directory compilation terminated. FAIL: gcc.dg/ipa/ipa-icf-5.c (test for excess errors) Excess errors: /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/ipa/ipa-icf-5.c:4:21: fatal error: comple x.h: No such file or directory compilation terminated. gcc.dg/ipa/ipa-icf-5.c: dump file does not exist UNRESOLVED: gcc.dg/ipa/ipa-icf-5.c scan-ipa-dump icf Semantic equality hit:f2-f1 gcc.dg/ipa/ipa-icf-5.c: dump file does not exist UNRESOLVED: gcc.dg/ipa/ipa-icf-5.c scan-ipa-dump icf Equal symbols: 1 Similar fail: FAIL: gcc.dg/ipa/ipa-icf-5.c (test for excess errors)
[Bug middle-end/63790] [5 Regression] Tests XFAILed because of the match-and-simplify merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63790 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #11 from John David Anglin danglin at gcc dot gnu.org --- Also fails on hppa2.0w-hp-hpux11.11.
[Bug tree-optimization/64039] New: FAIL: gcc.dg/tree-ssa/ssa-dom-cse-2.c scan-tree-dump optimized return 28;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64039 Bug ID: 64039 Summary: FAIL: gcc.dg/tree-ssa/ssa-dom-cse-2.c scan-tree-dump optimized return 28; Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -fno-tree-fre -fno-tree-pre -fdump-tre e-optimized -S -o ssa-dom-cse-2.s(timeout = 300)spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -fno-tree-fre -fno-tree-pre -fdump-tree-optimized -S - o ssa-dom-cse-2.s PASS: gcc.dg/tree-ssa/ssa-dom-cse-2.c (test for excess errors)FAIL: gcc.dg/tree-ssa/ssa-dom-cse-2.c scan-tree-dump optimized return 28;
[Bug libstdc++/64040] New: FAIL: 23_containers/vector/ext_pointer/types/2.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64040 Bug ID: 64040 Summary: FAIL: 23_containers/vector/ext_pointer/types/2.cc execution test Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa*-*-* (32-bit) Executing on host: /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/test/gnu/gc c/objdir/./gcc -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc+ +-v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -B/opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/sys-include -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -D_GLIBCXX_ASSERT -fmessage-length=0 -g -O2 -DLOCALEDIR=. -nostdinc++ -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util /test/gnu/gcc/gcc/libstdc++-v3/testsuite/23_containers/vector/ext_pointer/types/2.cc -std=gnu++11 ./libtestc++.a -lm -o ./2.exe(timeout = 600) spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/test/gnu/gcc/objdir/./gcc -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src -L/t est/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -B/opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/gcc/gcc-5.0/hppa2.0w-hp-hpux11.11/sys-include -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -D_GLIBCXX_ASSERT -fmessage-length=0 -g -O2 -DLOCALEDIR=. -nostdinc++ -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util /test/gnu/gcc/gcc/libstdc++-v3/testsuite/23_containers/vector/ext_pointer/types/2.cc -std=gnu++11 ./libtestc++.a -lm -o ./2.exe PASS: 23_containers/vector/ext_pointer/types/2.cc (test for excess errors) Setting LD_LIBRARY_PATH to :/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/../libgomp/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs::/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/../libgomp/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs spawn [open ...] terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc FAIL: 23_containers/vector/ext_pointer/types/2.cc execution test extra_tool_flags are: -std=gnu++11
[Bug ipa/63852] [5 regression] acats failures on x86_64-apple-darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63852 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #2 from John David Anglin danglin at gcc dot gnu.org --- Also seen on hppa2.0w-hp-hpux11.11.
[Bug libstdc++/64040] FAIL: 23_containers/vector/ext_pointer/types/2.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64040 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Strange. Maybe some number is overflowing and trying to allocate a huge number of bytes. I'll try to look into it but not for a few days.
[Bug libstdc++/64040] FAIL: 23_containers/vector/ext_pointer/types/2.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64040 --- Comment #2 from John David Anglin danglin at gcc dot gnu.org --- Program received signal SIGABRT, Aborted. 0xc020e9d8 in ?? () from /usr/lib/libc.2 (gdb) bt #0 0xc020e9d8 in ?? () from /usr/lib/libc.2 #1 0xc01a9a74 in ?? () from /usr/lib/libc.2 #2 0xc01eadf8 in ?? () from /usr/lib/libc.2 #3 0xc01eae54 in ?? () from /usr/lib/libc.2 #4 0xc1cbc82c in __gnu_cxx::__throw_concurrence_unlock_error () at /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/ext/concurrence.h:106 #5 0xc1cb7194 in __gnu_cxx::__throw_concurrence_unlock_error () at /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/ext/concurrence.h:106 #6 0xc1cb7600 in __gnu_cxx::__throw_concurrence_unlock_error () at /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/ext/concurrence.h:106 #7 0xc1cb7e44 in __gnu_cxx::__throw_concurrence_unlock_error () at /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/ext/concurrence.h:106 #8 0xc1cb9eac in __gnu_cxx::__throw_concurrence_unlock_error () at /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/ext/concurrence.h:106 #9 0x4df0 in std::vectorN::X, __gnu_cxx::_ExtPtr_allocatorN::X ::_M_range_insert__gnu_cxx::__normal_iterator__gnu_cxx::_Pointer_adapter__gnu_cxx::_Relative_pointer_implN::X const , std::vectorN::X, __gnu_cxx::_ExtPtr_allocatorN::X (this=0x7eff0638, __position=..., __first=..., __last=...) ---Type return to continue, or q return to quit--- at /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/ext/new_allocator.h:104 #10 0x4f78 in std::vectorN::X, __gnu_cxx::_ExtPtr_allocatorN::X ::insert__gnu_cxx::__normal_iterator__gnu_cxx::_Pointer_adapter__gnu_cxx::_Relative_pointer_implN::X const , std::vectorN::X, __gnu_cxx::_ExtPtr_allocatorN::X , void (this=0x7eff0638, __position=..., __first=..., __last=...) at /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/bits/stl_vector.h:1377 #11 0x64e4 in main () at /test/gnu/gcc/gcc/libstdc++-v3/testsuite/23_containers/vector/ext_pointer/types/2.cc:58
[Bug target/64015] [5.0 Regression] AArch64 ICE due to conditional compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64015 --- Comment #2 from Zhenqiang Chen zhenqiang.chen at arm dot com --- You force it to register? In fact, I tend to not force it to register in gen_ccmp_next, since it will introduce more overhead for ccmp, which performance maybe worse. My patch to fix the issue is at: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02966.html For CCMP, we still miss two optimizations for it: 1) Change the order of compares. In the case, if you change it to b 252 a 10 You don't need mov w0, 252 uxtbw1, w1 uxtbw0, w0 cmpw1, 252 ccmpw0, 10, 0, hi csetw0, hi ret 2) How to justify it is valueable (the overhead of ccmp is OK) when generating ccmp?
[Bug target/64015] [5.0 Regression] AArch64 ICE due to conditional compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64015
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Zhenqiang Chen from comment #2)
2) How to justify it is valueable (the overhead of ccmp is OK) when
generating ccmp?
If we ignore the case for swapping.
Try this one:
int
test (int a, int b)
{
return (a 252) b 252;
}
With my patch to do the forcing:
test:
cmp w0, 252
mov w0, 252
ccmpw1, w0, 4, gt
csetw0, gt
ret
Without:
test:
cmp w0, 252
csetw2, gt
cmp w1, 252
csetw0, gt
and w0, w2, w0
ret
Or better yet take:
int
test (int a, int b)
{
return (a 321223) b 321224;
}
Without:
test:
mov w3, 59079
mov w2, 59080
movkw3, 0x4, lsl 16
movkw2, 0x4, lsl 16
cmp w0, w3
csetw3, gt
cmp w1, w2
csetw0, gt
and w0, w3, w0
ret
With forcing:
test:
mov w3, 59079
mov w2, 59080
movkw3, 0x4, lsl 16
movkw2, 0x4, lsl 16
cmp w0, w3
ccmpw1, w2, 4, gt
csetw0, gt
ret
--- CUT ---
Also take:
int
test (int a, int b)
{
return (a 33) b 33;
}
Without:
test:
cmp w0, 33
csetw2, gt
cmp w1, 33
csetw0, gt
and w0, w2, w0
ret
With forcing:
test:
cmp w0, 33
mov w0, 33
ccmpw1, w0, 4, gt
csetw0, gt
ret
See how with forcing is always the same size or smaller?
[Bug target/64015] [5.0 Regression] AArch64 ICE due to conditional compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64015 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #3) See how with forcing is always the same size or smaller? Actually is always smaller by at least one instruction. due to the need to do one extra cset and one and/or compared to one mov.
[Bug middle-end/64012] GCC-4.9.2 option -fcaller-saves in -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64012 --- Comment #4 from Airbak airbak.li at huawei dot com --- When I build toolchain with GNU gcc-4.9.2.tar.bz2, the problem also exist. -- lijianhui@key:~/hi3535/Hi3535_SDK_V2.0.3.1/osdrv/kernel/linux-3.4.y$ arm-unknown-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=arm-unknown-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/home/os/lijianhui/linaro/new-crosstool-ng/install-org-gcc/bin/../libexec/gcc/arm-unknown-linux-gnueabi/4.9.2/lto-wrapper Target: arm-unknown-linux-gnueabi Configured with: /home/os/lijianhui/linaro/new-crosstool-ng/.build/src/gcc-4.9.2/configure --build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu --target=arm-unknown-linux-gnueabi --prefix=/home/os/lijianhui/linaro/new-crosstool-ng/install ... Any suggestions?
[Bug target/64015] [5.0 Regression] AArch64 ICE due to conditional compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64015
--- Comment #5 from Zhenqiang Chen zhenqiang.chen at arm dot com ---
It seams you always win with ccmp. Please go ahead for your patch and make sure
the following case work.
int
test (unsigned short a, unsigned char b)
{
return a 0xfff2 b 252;
}
Thanks!
-Zhenqiang
[Bug middle-end/64012] GCC-4.9.2 option -fcaller-saves in -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64012 --- Comment #5 from Airbak airbak.li at huawei dot com --- I'm sorry for my mistake. GCC-4.8.3 also have this phenomenon. GCC 4.4.1 is OK.
[Bug fortran/63938] OpenMP atomic update does not protect access to automatic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63938 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-24 CC||Joost.VandeVondele at mat dot ethz ||.ch Ever confirmed|0 |1 Known to fail||4.7.2, 4.8.3, 4.9.2, 5.0 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- confirmed to affect all open branches, and at all optimization levels. It is triggered by the fact that the array index is a constant, i.e. this fails: !$omp atomic x(1) = x(1) + 1 this works: !$omp atomic x(j) = x(j) + 1
[Bug rtl-optimization/64041] New: wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64041
Bug ID: 64041
Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk and 4.9.x miscompile the following code on x86_64-linux
at -O2 and -O3 in both 32-bit and 64-bit modes.
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20141122 (experimental) [trunk revision 217971] (GCC)
$ gcc-trunk -Os small.c; a.out
0
$ gcc-4.8 -O2 small.c; a.out
0
$
$ gcc-trunk -O2 small.c; a.out
$ gcc-4.9 -O2 small.c; a.out
$
--
int printf (const char *, ...);
int a, b = 1, d;
union U1
{
unsigned int f0;
int f1;
};
union U2
{
int f2;
int f3;
} c;
int
fn1 (int p)
{
int t = p a || p a p;
return t ? t : a;
}
unsigned
fn2 (union U1 p1, union U2 p2)
{
if (p1.f1 = 0)
{
for (; p2.f2;)
c.f2 = 0;
p2.f2 = fn1 (d);
}
return p2.f3;
}
int
main ()
{
if (b)
{
union U1 f = { 0xU };
fn2 (f, c);
}
printf (%d\n, 0);
return 0;
}
[Bug go/64021] Empty struct vs libffi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64021 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #4 from Richard Henderson rth at gcc dot gnu.org --- If we decide to follow C++, this is an abi change, and thus should happen before gcc 5. Thus P1.
