[Bug other/39374] reload is too earer to re-use reload registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39374 --- Comment #1 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Created attachment 35011 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35011action=edit gcc14:/home/amylaar/pr39374/pr39374-diff
[Bug c++/65390] New: ICE in strip_typedefs, at cp/tree.c:1361
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65390
Bug ID: 65390
Summary: ICE in strip_typedefs, at cp/tree.c:1361
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alserkli at inbox dot ru
Created attachment 35013
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35013action=edit
preprocessed source
g++ (GCC) 5.0.0 20150311 (experimental)
=== e.cc ===
#include memory
auto f(int n){
return std::make_sharedint[n]();
}
===
$ g++ -std=c++14 e.cc
In file included from /opt/include/c++/5.0.0/memory:82:0,
from e.cc:1:
/opt/include/c++/5.0.0/bits/shared_ptr.h: In substitution of 'templateclass
_Tp, class ... _Args std::shared_ptr_Tp1 std::make_shared(_Args ...) [with
_Tp = int [n]; _Args = {}]':
e.cc:3:35: required from here
/opt/include/c++/5.0.0/bits/shared_ptr.h:626:5: internal compiler error: in
strip_typedefs, at cp/tree.c:1361
make_shared(_Args... __args)
^
0x7bbc4d strip_typedefs(tree_node*)
/gcc/gcc/cp/tree.c:1361
0x6534d2 canonicalize_type_argument
/gcc/gcc/cp/pt.c:6500
0x67f7fa coerce_template_parms
/gcc/gcc/cp/pt.c:7171
0x681789 lookup_template_class_1
/gcc/gcc/cp/pt.c:7780
0x681789 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/gcc/gcc/cp/pt.c:8096
0x684cd8 tsubst_aggr_type
/gcc/gcc/cp/pt.c:10460
0x67704b tsubst(tree_node*, tree_node*, int, tree_node*)
/gcc/gcc/cp/pt.c:11909
0x68bc6f tsubst_function_type
/gcc/gcc/cp/pt.c:11624
0x677186 tsubst(tree_node*, tree_node*, int, tree_node*)
/gcc/gcc/cp/pt.c:12357
0x6a219d fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
/gcc/gcc/cp/pt.c:16259
0x615479 add_template_candidate_real
/gcc/gcc/cp/call.c:3057
0x615f0c add_template_candidate
/gcc/gcc/cp/call.c:3154
0x615f0c add_candidates
/gcc/gcc/cp/call.c:5285
0x6163d3 perform_overload_resolution
/gcc/gcc/cp/call.c:4003
0x6188ca build_new_function_call(tree_node*, vectree_node*, va_gc,
vl_embed**, bool, int)
/gcc/gcc/cp/call.c:4080
0x7907d1 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, bool,
bool, int)
/gcc/gcc/cp/semantics.c:2407
0x7147e1 cp_parser_postfix_expression
/gcc/gcc/cp/parser.c:6368
0x71c349 cp_parser_unary_expression
/gcc/gcc/cp/parser.c:7438
0x71d047 cp_parser_binary_expression
/gcc/gcc/cp/parser.c:8172
0x71d87f cp_parser_assignment_expression
/gcc/gcc/cp/parser.c:8430
[Bug middle-end/65391] unnecessary load of conditionally updated pointer in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65391 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-11 Ever confirmed|0 |1 Known to fail||4.1.0, 4.5.0, 4.6.0, 4.7.0, ||4.8.0 --- Comment #1 from David Edelsohn dje at gcc dot gnu.org --- Confirmed.
[Bug other/39374] reload is too earer to re-use reload registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39374 --- Comment #2 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Created attachment 35012 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35012action=edit gcc14:/home/amylaar/pr39374/pr39374-r14476
[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65242 --- Comment #14 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Wed Mar 11 16:57:41 2015 New Revision: 221350 URL: https://gcc.gnu.org/viewcvs?rev=221350root=gccview=rev Log: [gcc] 2015-03-09 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65242 * config/rs6000/rs6000.c (rs6000_preferred_reload_class): Do not allow reloads of PLUS in floating point/VSX registers. [gcc/testsuite] 2015-03-09 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65242 * g++.dg/pr65242.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr65242.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/57059] [4.8/4.9/5 Regression] Host configuration of loose_warn breaks for build components for Canadian crosses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57059 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #7 from Aldy Hernandez aldyh at gcc dot gnu.org --- I can't reproduce this on mainline. I'm building: /source/gcc/configure --host=ppc64-linux --target=i386-elf --build=x86-64-linux-gnu I am cheating with the cross tools by setting links to native compilers to speed up the process. My x86-64 build compilers are 4.6 based (gcc, g++, x86-64-unknown-linux-gnu-gcc, etc in the list below) and do not have support for -Wnarrowing. My cross compiler is ppc64-linux-g* which is the system compiler and supports -Wnarrowing: -rwxr-xr-x. 4 aldyh aldyh 1027379 Mar 11 08:16 c++ -rwxr-xr-x. 1 aldyh aldyh 1024943 Mar 11 08:16 cpp -rwxr-xr-x. 4 aldyh aldyh 1027379 Mar 11 08:16 g++ -rwxr-xr-x. 3 aldyh aldyh 1022232 Mar 11 08:16 gcc -rwxr-xr-x. 1 aldyh aldyh 135016 Mar 11 08:16 gcov lrwxrwxrwx. 1 aldyh aldyh 11 Mar 11 09:36 ppc64-linux-ar - /usr/bin/ar lrwxrwxrwx. 1 aldyh aldyh 11 Mar 11 09:36 ppc64-linux-as - /usr/bin/as lrwxrwxrwx. 1 aldyh aldyh 12 Mar 11 09:51 ppc64-linux-g++ - /usr/bin/g++ lrwxrwxrwx. 1 aldyh aldyh 12 Mar 11 09:51 ppc64-linux-gcc - /usr/bin/gcc lrwxrwxrwx. 1 aldyh aldyh 11 Mar 11 09:36 ppc64-linux-ld - /usr/bin/ld lrwxrwxrwx. 1 aldyh aldyh 11 Mar 11 09:36 ppc64-linux-nm - /usr/bin/nm lrwxrwxrwx. 1 aldyh aldyh 16 Mar 11 09:36 ppc64-linux-objcopy - /usr/bin/objcopy lrwxrwxrwx. 1 aldyh aldyh 16 Mar 11 09:36 ppc64-linux-objdump - /usr/bin/objdump lrwxrwxrwx. 1 aldyh aldyh 15 Mar 11 09:36 ppc64-linux-ranlib - /usr/bin/ranlib lrwxrwxrwx. 1 aldyh aldyh 16 Mar 11 09:36 ppc64-linux-readelf - /usr/bin/readelf lrwxrwxrwx. 1 aldyh aldyh 14 Mar 11 09:36 ppc64-linux-strip - /usr/bin/strip -rwxr-xr-x. 4 aldyh aldyh 1027379 Mar 11 08:16 x86_64-unknown-linux-gnu-c++ -rwxr-xr-x. 4 aldyh aldyh 1027379 Mar 11 08:16 x86_64-unknown-linux-gnu-g++ -rwxr-xr-x. 3 aldyh aldyh 1022232 Mar 11 08:16 x86_64-unknown-linux-gnu-gcc -rwxr-xr-x. 3 aldyh aldyh 1022232 Mar 11 08:16 x86_64-unknown-linux-gnu-gcc-4.6.4 # build compiler with no support for -Wnarrowing: reynosa:/build/gcc46/install/bin$ gcc -c -Wnarrowing a.c cc1: error: unrecognized command line option ‘-Wnarrowing’ # cross compiler with support for -Wnarrowing: reynosa:/build/gcc46/install/bin$ ppc64-linux-gcc -c -Wnarrowing a.c reynosa:/build/gcc46/install/bin$ I see the GCC configury correctly determining that -Wnarrowing is available for the cross compiler: [gcc/config.log] configure:6367: checking whether ppc64-linux-gcc supports -Wnarrowing configure:6384: ppc64-linux-gcc -c -Wnarrowing conftest.c 5 configure:6384: $? = 0 configure:6393: result: yes ... ... acx_cv_prog_cc_warning__Wnarrowing=yes However, building build/genconstants.o with the x86-64-linux 4.6 compiler does not use -Wno-narrowing, and is being compiled correctly: g++ -c -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -DGENERATOR_FILE -I. -Ibuild -I/s ource/gcc/gcc -I/source/gcc/gcc/build -I/source/gcc/gcc/../include -I/source/gc c/gcc/../libcpp/include \ -o build/genconstants.o /source/gcc/gcc/genconstants.c Further in the build process, the cross compiler is being used correctly, but this time with -Wno-narrowing as expected: ppc64-linux-g++ -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Ic -I/source/gcc/gcc -I/source/gcc/gcc/c -I/source/gcc/gcc/../include -I/source/gcc/gcc/../libcpp/include -I/source/gcc/gcc/../libdecnumber -I/source/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/source/gcc/gcc/../libbacktrace -o c/c-parser.o -MT c/c-parser.o -MMD -MP -MF c/.deps/c-parser.TPo /source/gcc/gcc/c/c-parser.c This was last confirmed by Andrew Pinski on 4.8. I am inclined to remove this as a regression on GCC 5.
[Bug middle-end/65391] unnecessary load of conditionally updated pointer in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65391 --- Comment #2 from Aaron Sawdey acsawdey at linux dot vnet.ibm.com --- Asm for the test case as in the description (load/store of *o_ptr for every update): compute_object_gain: ld 9,0(3) li 10,0 std 10,0(4) cmpdi 7,9,0 beqlr 7 .p2align 5,,31 .L6: cmpd 7,5,9 blt 7,.L3 ld 10,0(4) add 9,10,9 std 9,0(4) .L3: ldu 9,8(3) cmpdi 7,9,0 bne 7,.L6 blr Same test case, but with __restrict__ removed (essentially no difference): compute_object_gain: li 9,0 std 9,0(4) ld 9,0(3) cmpdi 7,9,0 beqlr 7 .p2align 5,,31 .L6: cmpd 7,5,9 blt 7,.L3 ld 10,0(4) add 9,10,9 std 9,0(4) .L3: ldu 9,8(3) cmpdi 7,9,0 bne 7,.L6 blr Remove the if() and add __restrict__ back (no load or store of *o_ptr in the loop): compute_object_gain: ld 9,0(3) li 8,0 li 10,0 std 8,0(4) cmpdi 7,9,0 beqlr 7 .p2align 4,,15 .L5: add 10,10,9 ldu 9,8(3) cmpdi 7,9,0 bne 7,.L5 std 10,0(4) blr Remove both the if() and __restrict__ (now store to *o_ptr is in the loop but no load): compute_object_gain: li 9,0 li 10,0 std 9,0(4) ld 9,0(3) cmpdi 7,9,0 beqlr 7 .p2align 5,,31 .L5: add 10,10,9 std 10,0(4) ldu 9,8(3) cmpdi 7,9,0 bne 7,.L5 blr
[Bug middle-end/65391] New: unnecessary load of conditionally updated pointer in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65391
Bug ID: 65391
Summary: unnecessary load of conditionally updated pointer in
loop
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: acsawdey at linux dot vnet.ibm.com
CC: dje at gcc dot gnu.org, pthaugen at us dot ibm.com
When compiling for powerpc64 or powerpc64le with -O3, a load and store of
*o_ptr is done inside the loop.
If you remove the if statement and make the update unconditional, then the load
goes away and the store is deferred until after the loop.
If you remove the __restrict__ keywords, then the store remains in the loop in
either case as expected. However the load is still done in the loop if the
update is conditional.
void compute_object_gain(long * __restrict__ p_ptr, long * __restrict__ o_ptr,
long g_order)
{
long a_binding;
*o_ptr = 0;
while(*p_ptr!=0) {
a_binding = *p_ptr;
if(a_binding = g_order)
*o_ptr += a_binding;
p_ptr++;
}
}
This behavior is consistent on 4.1, 4.5, 4.6, 4.7, 4.8, and 5.0 (trunk 220806).
[Bug tree-optimization/65177] [5 Regression]: extend jump thread for finite state automata causes miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177 --- Comment #14 from Sebastian Pop spop at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #13) But you can need updates that extend beyond the scope of the SEME I would think. That was my recollection from looking at ways to minimize the number of blocks the renamer had to examine after threading. You are right, we need to update all uses of ssa_names defined in the SEME. We currently only fix all the phi nodes on all the exits of the SEME by adding one more operand to the phis. I think we would also need to add phi nodes for all the definitions that we copied as now we may reach the destination of an SEME exit through at least two paths: the original path and the copied one. I do not know whether update_ssa has enough information to correctly add these phi nodes.
[Bug tree-optimization/65310] vectorizer uses wrong alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65310 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Mar 11 15:09:51 2015 New Revision: 221348 URL: https://gcc.gnu.org/viewcvs?rev=221348root=gccview=rev Log: 2015-03-11 Richard Biener rguent...@suse.de PR tree-optimization/65310 * tree-sra.c (build_ref_for_offset): Also preserve larger alignment. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-sra.c
[Bug preprocessor/65387] [4.8/4.9/5 Regression] cpp -C emits extraneous comment header on every file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65387 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- https://gcc.gnu.org/gcc-4.8/porting_to.html suggests to use -ffreestanding Of course, the real fix for this and future issues arising from such mis-use is to make libcpp more general and enable cpp to have a Fortran mode (-x fortran) or even compile a Fortran version of cpp (fpp?). This would be a very valuable contribution to GCC and gfortran and, technically, it should be not very difficult: https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps
[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65242 --- Comment #13 from Michael Meissner meissner at gcc dot gnu.org --- My gut feeling is we don't want to change ?m to !m, because it might impact floating point conversions - integer, where we need the DI mode in a floating point register. In addition, I might worry that it could impact breaking apart _Decimal128 values, which I believe uses DImode for the two parts. I was also trying to make the minimal change, and I didn't want an iteration where we fix up any collateral damage.
[Bug preprocessor/65387] [4.8/4.9/5 Regression] cpp -C emits extraneous comment header on every file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65387 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Well, IMHO if you do not want comments or are not prepared to handle them, just don't use -C. Fortran these days has integrated preprocessor, I doubt fpp would be of any use and you'd need to define how exactly should fortran preprocessing behave (e.g. how it is different from assembly preprocessing). Note that even -E -xassembler-with-cpp preprocessing includes stdc-predef.h by default, you need to use -nostdinc to avoid that. In any case, not a bug IMHO.
[Bug other/65384] Intel MPX does not support x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65384 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-11 Assignee|unassigned at gcc dot gnu.org |enkovich.gnu at gmail dot com Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug tree-optimization/65177] [5 Regression]: extend jump thread for finite state automata causes miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177 --- Comment #15 from Jeffrey A. Law law at redhat dot com --- Basically the way this works is we record the SSA_NAMEs that are being duplicated during block copying. For any duplicated SSA_NAME, if 1 instance of it is live at a join point in the CFG, then update_ssa will create a PHI and merge the values. I can't offhand think of any reason why it wouldn't work here if the names were properly marked. But I haven't looked at the before/after CFGs to see if there's something unique in this case. In fact, I haven't looked at it at all at this point.
[Bug libfortran/65200] Handle EPERM when opening files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65200 --- Comment #7 from Janne Blomqvist jb at gcc dot gnu.org --- Author: jb Date: Wed Mar 11 21:34:22 2015 New Revision: 221361 URL: https://gcc.gnu.org/viewcvs?rev=221361root=gccview=rev Log: PR 65200 Handle EPERM in addition to EACCES. gcc/fortran ChangeLog: 2015-03-11 Janne Blomqvist j...@gcc.gnu.org PR libfortran/65200 * gfortran.texi: Document behavior when opening files without explicit ACTION= specifier. libgfortran ChangeLog: 2015-03-11 Janne Blomqvist j...@gcc.gnu.org PR libfortran/65200 * io/open.c (new_unit): Use gf_strerror rather than hardcoding error messages for different errno values. * io/unix.c (regular_file2): Handle EPERM in addition to EACCES. gcc/testsuite ChangeLog: 2015-03-11 Janne Blomqvist j...@gcc.gnu.org PR libfortran/65200 * gfortran.dg/open_errors.f90: Update checks for iomsg string. * gfortran.dg/open_new_segv.f90: Fix error message pattern. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/open_errors.f90 trunk/gcc/testsuite/gfortran.dg/open_new_segv.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/io/open.c trunk/libgfortran/io/unix.c
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 --- Comment #7 from Martin Sebor msebor at gcc dot gnu.org --- The cause of the failing tests observed on RHEL 7.1 is in the second definition of nettle's HAVE_NATIVE_64_BIT configuration macro: $ grep HAVE_NATIVE_64_BIT config.* config.h:# define HAVE_NATIVE_64_BIT 1 config.h:# define HAVE_NATIVE_64_BIT (SIZEOF_LONG * CHAR_BIT = 64) The macro relies on CHAR_BIT. Uses of HAVE_NATIVE_64_BIT of the form #if !HAVE_NATIVE_64_BIT in files that don't include limits.h that defined CHAR_BIT end up compiling the conditional blocks that are intended to be included only when the target has no native support for 64 bit arithmetic. One such file that comes into play in the failing tests is camellia-absorb.c. Since ppc64le obviously does have such support, the code is unnecessary and, as it turns out, introduces errors. Once limits.h is included (I simply added the include directive to macros.h), all of nettle's tests pass even on ppc64le-redhat-linux with the default -O2. However, after rebuilding at -O3 I see the following failure: hash input address: 0x10007410471 Got: dd4111dd66913ae2 f39adfbc438214d6 Expected: e33b4ddc9c38f219 9c3e7b164fcc0536 /src/nettle-3.0/run-tests: line 57: 57170 Aborted $1 $testflags FAIL: md4 The failure disappears and is replaced by the errors below if I rebuild everything with -fsanitize=address -fsanitize=bounds -fsanitize=undefined: ... /src/nettle-3.0/blowfish.c:363:19: runtime error: left shift of 244 by 24 places cannot be represented in type 'int' PASS: blowfish ... /src/nettle-3.0/des.c:176:42: runtime error: index 42 out of bounds for type 'int8_t [26][4]' PASS: des /src/nettle-3.0/des.c:176:42: runtime error: index 52 out of bounds for type 'int8_t [26][4]' PASS: des3 /src/nettle-3.0/des.c:176:42: runtime error: index 35 out of bounds for type 'int8_t [26][4]' PASS: des-compat ... /src/nettle-3.0/twofish.c:200:54: runtime error: left shift of 184 by 24 places cannot be represented in type 'int' PASS: twofish
[Bug tree-optimization/65355] [4.8/4.9 Regression] vectorizer increase alignment of symbols already placed in anchors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65355 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #3 from Pat Haugen pthaugen at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #1) Author: hubicka Date: Tue Mar 10 04:24:21 2015 New Revision: 221297 URL: https://gcc.gnu.org/viewcvs?rev=221297root=gccview=rev Log: PR tree-optimization/65355 * varasm.c (notice_global_symbol): Do not produce RTL. * symtab.c (symtab_node::can_increase_alignment_p): Check for section anchor. * tree-vect-data-refs.c (vect_compute_data_ref_alignment): Do not check for section anchors. * gcc.dg/vect/section-anchors-vect-69.c: Update template. Modified: trunk/gcc/ChangeLog trunk/gcc/symtab.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/section-anchors-vect-69.c trunk/gcc/tree-vect-data-refs.c trunk/gcc/varasm.c This change introduced the following failures on powerpc64[le]: FAIL: g++.dg/vect/pr36648.cc -std=c++11 scan-tree-dump-times vect vectorized 1 loops 1 FAIL: g++.dg/vect/pr36648.cc -std=c++11 scan-tree-dump-times vect vectorizing stmts using SLP 1 FAIL: g++.dg/vect/pr36648.cc -std=c++14 scan-tree-dump-times vect vectorized 1 loops 1 FAIL: g++.dg/vect/pr36648.cc -std=c++14 scan-tree-dump-times vect vectorizing stmts using SLP 1 FAIL: g++.dg/vect/pr36648.cc -std=c++98 scan-tree-dump-times vect vectorized 1 loops 1 FAIL: g++.dg/vect/pr36648.cc -std=c++98 scan-tree-dump-times vect vectorizing stmts using SLP 1
[Bug middle-end/40060] [4.8/4.9/5 Regression] casts loose alignment info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40060 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||aldyh at gcc dot gnu.org --- Comment #20 from Aldy Hernandez aldyh at gcc dot gnu.org --- The testcases were deemed invalid and changed on mainline by r219061, and thus no longer fail. Can we close this PR, remove the GCC 5 regression tag, or is perhaps another similar testcase (??) still exhibiting a regression? See discussion here: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01856.html
[Bug tree-optimization/65388] Wrong comparison in same_succ_def::equal() tree-ssa-tail-merge.c:590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65388 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Mar 11 20:36:56 2015 New Revision: 221359 URL: https://gcc.gnu.org/viewcvs?rev=221359root=gccview=rev Log: PR tree-optimization/65388 * tree-ssa-tail-merge.c (same_succ_def::equal): Fix typo in comparison. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-tail-merge.c
[Bug c/65395] New: compiler crash, -ftree-pre leads to SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65395 Bug ID: 65395 Summary: compiler crash, -ftree-pre leads to SSA corruption Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jens.gustedt at inria dot fr Created attachment 35015 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35015action=edit code to reproduce compiler crash The attached, very contrived code, has gcc crashing with gcc -c -O3 orwl_proc_symbols-prepro.c the code compiles fine with gcc -c -O3 -fno-tree-pre orwl_proc_symbols-prepro.c As indicated the code is very contrived and the result of reducing a complicated macro expanded code to a minimal example. So the one I give here seems to be minimal to reproduce the crash. It has - nested for loops of a depth 15 or so - uses setjmp (but no longjmp) - uses an inline function that does not much but calling a _Noreturn function conditionally without any of these components the bug goes away ... BTW, I observed the bug already for earlier versions of gcc 4.9. gcc 4.8 works fine. My system is a x86_64 with debian jessie, nothing fancy.
[Bug libstdc++/64847] [5 Regression] FAIL: 30_threads/shared_lock/requirements/explicit_instantiation.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64847 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-03-11 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Summary|FAIL: |[5 Regression] FAIL: |30_threads/shared_lock/requ |30_threads/shared_lock/requ |irements/explicit_instantia |irements/explicit_instantia |tion.cc (test for excess|tion.cc (test for excess |errors) |errors) Ever confirmed|0 |1
[Bug c++/65127] [5 Regression] internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'addr_expr' in parsing_nsdmi, at cp/parser.c:18311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65127 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug ipa/65394] New: r221327 causes gcc.dg/ipa/pr63569.c to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65394 Bug ID: 65394 Summary: r221327 causes gcc.dg/ipa/pr63569.c to fail Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: bergner at gcc dot gnu.org, dje at gcc dot gnu.org, hubicka at gcc dot gnu.org Host: powerpc64-unknown-linux-gnu Target: powerpc64-unknown-linux-gnu Build: powerpc64-unknown-linux-gnu Following failures started occurring on powerpc64 with r221327. FAIL: gcc.dg/ipa/pr63569.c scan-ipa-dump icf different operand volatility
[Bug tree-optimization/62173] [5 Regression] 64bit Arch can't ivopt while 32bit Arch can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #35 from Jiong Wang jiwang at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #34) Any progress on this? This is a P1 PR, but no comments have been added for more than a month... from what I known: Bin was working on some tree level fix while I was working on RTL level fix. And I was told this has been deffered to next stage 1.
[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65242 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed, thanks.
[Bug libstdc++/65392] Bad mangled names in Debug Mode assertions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65392 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-11 Ever confirmed|0 |1
[Bug bootstrap/57059] [4.8/4.9/5 Regression] Host configuration of loose_warn breaks for build components for Canadian crosses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57059 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Aldy Hernandez aldyh at gcc dot gnu.org --- Aha, this is no longer reproducible on neither 4.8 nor the 4.9 branch. It was fixed for 4.9, and backported to the 4.8 branch with r205803: commit b1009c8da943bcfe84455313dff13dfbd998bd57 Author: amodra amodra@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Mon Dec 9 11:30:39 2013 + 2013-12-09 Alan Modra amo...@gmail.com Apply from mainline 2013-12-05 Alan Modra amo...@gmail.com * configure.ac (BUILD_CXXFLAGS) Don't use ALL_CXXFLAGS for build != host. recursive call for build != host: Clear GMPINC. Don't bother saving CFLAGS. * configure: Regenerate. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@205803 138bc75d-0d04-0410-961f-82ee72b054a4 Closed as fixed everywhere. Yeehaw.
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Wed Mar 11 18:35:52 2015 New Revision: 221354 URL: https://gcc.gnu.org/viewcvs?rev=221354root=gccview=rev Log: gcc/ PR target/65296 * configure.ac [avr]: Check as for option -mrmw. * configure: Regenerate. * config.in: Regenerate. * config/avr/driver-avr.c (avr_device_to_as): Don't add -mrmw to assembler options if not HAVE_AS_AVR_MRMW_OPTION. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config.in branches/gcc-4_9-branch/gcc/config/avr/driver-avr.c branches/gcc-4_9-branch/gcc/configure branches/gcc-4_9-branch/gcc/configure.ac
[Bug libstdc++/65393] std::thread shared_ptr inefficiency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65393 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-03-11 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Klemens from comment #0) could be changed to _M_start_thread(std::move(__b), nullptr); or alternatively take __shared_base_type by universal reference and forward it into the other _M_start_thread overload. (They're called forwarding references now) That would require making the function a template, for no benefit. It should be moved. In general, these inefficiencies are pretty tiny compared to the cost of launching a new thread that happens immediately after.
[Bug rtl-optimization/64366] Segmentation fault in remove_pseudos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64366 --- Comment #2 from Vladimir Makarov vmakarov at gcc dot gnu.org --- I've reproduced the bug. As the bug is in LRA inheritance, it will take some time to fix it. I hope to make a patch on next week.
[Bug libstdc++/65392] New: Bad mangled names in Debug Mode assertions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65392
Bug ID: 65392
Summary: Bad mangled names in Debug Mode assertions
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
#include deque
int main()
{
std::dequeint d;
auto it = d.begin();
it - 2;
}
/usr/include/c++/4.8.3/debug/safe_iterator.h:378:error: attempt to retreat
a past-the-end iterator 2 steps, which falls outside its valid range.
Objects involved in the operation:
iterator @ 0x0x7fff3e6b1930 {
type =
N11__gnu_debug14_Safe_iteratorINSt9__cxx199815_Deque_iteratorIiRiPiEENSt7__debug5dequeIiSaIiE
(mutable iterator);
state = past-the-end;
references sequence with type `NSt7__debug5dequeIiSaIiEEE' @ 0x0x7fff3e6b1930
}
Aborted (core dumped)
The types shown are not valid symbol names and cannot be demangled. They are
missing the _Z prefix.
We should not bother printing out mangled names if users can't demangle them to
get something meaningful. Ideally we should be demangling them automatically.
[Bug libstdc++/63711] can not compile llvm in debug mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63711 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- This is a dup of PR 63500 *** This bug has been marked as a duplicate of bug 63500 ***
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 --- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Wed Mar 11 18:51:09 2015 New Revision: 221355 URL: https://gcc.gnu.org/viewcvs?rev=221355root=gccview=rev Log: gcc/ PR target/65296 * configure.ac [avr]: Check as for options -mrmw, --mlink-relax. * configure: Regenerate. * config.in: Regenerate. * doc/invoke.texi (AVR Options) [-mrmw]: Document it. [-mn-flash]: Document it. [__AVR_ARCH__]: Document avrtiny. * config/avr/gen-avr-mmcu-specs.c (config.h): Include it. (*asm_relax): Only define spec if HAVE_AS_AVR_MLINK_RELAX_OPTION. (*asm_rmw): Only define spec if HAVE_AS_AVR_MRMW_OPTION. gcc/testsuite/ PR target/65296 * gcc.target/avr/tiny-memx: Use -mmcu instead of -march. * gcc.target/avr/tiny-caller-save.c: Same. Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/config/avr/gen-avr-mmcu-specs.c trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/avr/tiny-caller-save.c trunk/gcc/testsuite/gcc.target/avr/tiny-memx.c
[Bug libstdc++/65393] New: std::thread shared_ptr inefficiency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65393 Bug ID: 65393 Summary: std::thread shared_ptr inefficiency Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: klemensbaum at gmail dot com The std::thread implementation passes around shared_ptr instances by value in multiple places where they could be moved: 1) in the function void thread::_M_start_thread(__shared_base_type __b) the line _M_start_thread(__b, nullptr); could be changed to _M_start_thread(std::move(__b), nullptr); or alternatively take __shared_base_type by universal reference and forward it into the other _M_start_thread overload. 2) in the function void thread::_M_start_thread(__shared_base_type __b, void (*)()) the lines __b-_M_this_ptr = __b; int __e = __gthread_create(_M_id._M_thread, execute_native_thread_routine, __b.get()); could be changed to auto __p = __b.get(); __b-_M_this_ptr = std::move(__b); int __e = __gthread_create(_M_id._M_thread, execute_native_thread_routine, __p); 3) Finally, the use of shared_ptr seems wholly unnecessarily. This can likely be implemented more cleanly with unique_ptr, and more efficiently, since it avoids the extra heap space for the reference count and all of the atomic ops.
[Bug tree-optimization/62173] [5 Regression] 64bit Arch can't ivopt while 32bit Arch can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 --- Comment #34 from Jakub Jelinek jakub at gcc dot gnu.org --- Any progress on this? This is a P1 PR, but no comments have been added for more than a month...
[Bug libstdc++/63711] can not compile llvm in debug mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63711 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|unknown |4.9.1 Resolution|--- |FIXED Target Milestone|--- |4.9.2 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed then.
[Bug libstdc++/63500] [4.9/5 Regression] bug in debug version of std::make_move_iterator?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63500 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||dushistov at mail dot ru --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 63711 has been marked as a duplicate of this bug. ***
[Bug libgomp/65385] New: [libgomp] omp task untied test case fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65385 Bug ID: 65385 Summary: [libgomp] omp task untied test case fails Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de CC: jakub at gcc dot gnu.org Created attachment 35006 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35006action=edit Test program. The task untied test case of the OpenMP Validation SuiteV 3.0a fails on Linux. http://web.cs.uh.edu/~openuh/download/
[Bug libgomp/65385] [libgomp] omp task untied test case fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65385 --- Comment #1 from Sebastian Huber sebastian.hu...@embedded-brains.de --- Created attachment 35008 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35008action=edit Test program.
[Bug libgomp/65385] [libgomp] omp task untied test case fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65385 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- That test is completely bogus. The spec doesn't require untied tasks to change threads at any point, it is strictly a may case. So the test is testing something not required by the standard.
[Bug libgomp/65385] [libgomp] omp task untied test case fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65385 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- IMHO not, I view the untied clause purely as an optimization hint (and libgomp parses it, but ignores it).
[Bug libgomp/65386] New: [libgomp] omp task final test case fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65386 Bug ID: 65386 Summary: [libgomp] omp task final test case fails Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de CC: jakub at gcc dot gnu.org Created attachment 35007 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35007action=edit Test program. The task final test case of the OpenMP Validation SuiteV 3.0a fails on Linux. http://web.cs.uh.edu/~openuh/download/
[Bug libgomp/65386] [libgomp] omp task final test case fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65386 --- Comment #1 from Sebastian Huber sebastian.hu...@embedded-brains.de --- Created attachment 35009 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35009action=edit Test program.
[Bug tree-optimization/65310] vectorizer uses wrong alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65310 --- Comment #7 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 10 Mar 2015, pthaugen at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65310 --- Comment #6 from Pat Haugen pthaugen at gcc dot gnu.org --- Can you be more specific as with what options it fails? I just tried current trunk (r221324) and the testcase still fails. Only one basic block vectorized string is generated, where the testcase expects two occurrences. [pthaugen@igoo testsuite]$ ~/install/gcc/trunk/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/pthaugen/install/gcc/trunk/bin/gcc COLLECT_LTO_WRAPPER=/home/pthaugen/install/gcc/trunk/libexec/gcc/powerpc64-unknown-linux-gnu/5.0.0/lto-wrapper Target: powerpc64-unknown-linux-gnu Configured with: /home/pthaugen/src/gcc/trunk/gcc/configure --prefix=/home/pthaugen/install/gcc/trunk --enable-decimal-float --enable-lto --with-as=/home/pthaugen/install/binutils/binutils-2.25/bin/as --with-ld=/home/pthaugen/install/binutils/binutils-2.25/bin/ld --with-gmp=/home/pthaugen/install/gcc-host-libs --without-ppl --without-cloog --enable-languages=c,fortran,c++ --disable-bootstrap Thread model: posix gcc version 5.0.0 20150310 (experimental) [trunk revision 221324] (GCC) [pthaugen@igoo testsuite]$ ~/install/gcc/trunk/bin/g++ -std=c++98 -O2 -ftree-vectorize -fno-vect-cost-model -maltivec -mvsx -mno-allow-movmisalign -fdump-tree-slp-details -S -m64 slp-pr50819.cc [pthaugen@igoo testsuite]$ grep basic block vectorized slp-pr50819.cc.136t.slp2 slp-pr50819.cc:28:17: note: basic block vectorized [pthaugen@igoo testsuite]$ Still can't reproduce it. Cross configured with $ /space/rguenther/tramp3d/trunk/configure --target=powerpc64-suse-linux --with-cpu-64=power4 --enable-secureplt --with-long-double-128 target_alias=powerpc64-suse-linux CFLAGS=-g CXXFLAGS=-g --enable-languages=c,c++,lto --no-create --no-recursion gcc ./cc1plus -quiet -std=c++98 -O2 -ftree-vectorize -fno-vect-cost-model -maltivec -mvsx -mno-allow-movmisalign -fdump-tree-slp-details -m64 slp-pr50819.cc -I include gcc grep 'basic block vectorized' slp-pr50819.cc.135t.slp2 slp-pr50819.cc:28:70: note: basic block vectorized slp-pr50819.cc:28:70: note: basic block vectorized
[Bug tree-optimization/65388] Wrong comparison in same_succ_def::equal() tree-ssa-tail-merge.c:590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65388 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Marek Polacek from comment #1) That looks indeed. I meant weird.
[Bug tree-optimization/65388] Wrong comparison in same_succ_def::equal() tree-ssa-tail-merge.c:590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65388 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Do we warn in this case (something like condition is always false)? clang has -Wtautological-compare warning that warns say for int b; if (b != b) but doesn't already for int a[10], i; if (a[i] != a[i]). gcc has -Wtype-limits, which partially overlaps the -Wtautological-compare, so if we introduce it, we should probably just add there the cases not already covered by -Wtype-limits.
[Bug tree-optimization/65355] [4.8/4.9 Regression] vectorizer increase alignment of symbols already placed in anchors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65355 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[4.8/4.9/5 Regression] |[4.8/4.9 Regression] |vectorizer increase |vectorizer increase |alignment of symbols|alignment of symbols |already placed in anchors |already placed in anchors --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed on the trunk then. Not sure about the running all late gimple passes before all RTL generation, I'd be afraid that would increase compiler memory consumption too much.
[Bug preprocessor/65387] [4.8/4.9/5 Regression] cpp -C emits extraneous comment header on every file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65387 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Oh, in my case stdc-predef.h comes from glibc thus the license comment should be directed there. The GCC shipped stuff seems to have the runtime exception.
[Bug testsuite/63175] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2 basic block vectorized using SLP 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #37 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug sanitizer/65365] false positive signed negation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65365 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed in 4.9.
[Bug middle-end/56917] -ftrapv detects a overflow wrongly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56917 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Mar 11 10:37:38 2015 New Revision: 221346 URL: https://gcc.gnu.org/viewcvs?rev=221346root=gccview=rev Log: Backported from mainline 2014-12-04 Marek Polacek pola...@redhat.com PR middle-end/56917 * fold-const.c (fold_unary_loc): Perform the negation in A's type when transforming ~ (A - 1) or ~ (A + -1) to -A. * c-c++-common/ubsan/pr56917.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/ubsan/pr56917.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/fold-const.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/65388] Wrong comparison in same_succ_def::equal() tree-ssa-tail-merge.c:590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65388 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Ah, we have PR54979 for that already... Marek, would you be interested to look at this in stage1?
[Bug tree-optimization/65388] New: Wrong comparison in same_succ_def::equal() tree-ssa-tail-merge.c:590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65388
Bug ID: 65388
Summary: Wrong comparison in same_succ_def::equal()
tree-ssa-tail-merge.c:590
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: maksqwe1 at ukr dot net
tree-ssa-tail-merge.c:590
same_succ_def::equal()
if (!inverse_flags (e1, e2))
{
for (i = 0; i e1-succ_flags.length (); ++i)
===if (e1-succ_flags[i] != e1-succ_flags[i])
return 0;
}
[Bug tree-optimization/65388] Wrong comparison in same_succ_def::equal() tree-ssa-tail-merge.c:590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65388
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org ---
That looks indeed. The code is in mainline as well and I bet 4.8 has it too.
Patch:
--- a/gcc/tree-ssa-tail-merge.c
+++ b/gcc/tree-ssa-tail-merge.c
@@ -587,7 +587,7 @@ same_succ_def::equal (const value_type *e1, const
compare_type *e2)
if (!inverse_flags (e1, e2))
{
for (i = 0; i e1-succ_flags.length (); ++i)
- if (e1-succ_flags[i] != e1-succ_flags[i])
+ if (e1-succ_flags[i] != e2-succ_flags[i])
return 0;
}
[Bug tree-optimization/65388] Wrong comparison in same_succ_def::equal() tree-ssa-tail-merge.c:590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65388 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-03-11 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #4) Ah, we have PR54979 for that already... Marek, would you be interested to look at this in stage1? Yes, I am; we should be able to warn in such egregious cases. Similar issues: PR64249, PR63357. Taking this one...
[Bug rtl-optimization/65379] ifcvt does not clean up dead instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65379 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-11 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/65310] vectorizer uses wrong alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65310 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Whoops - tested in the wrong tree. Can reproduce now - investigating.
[Bug libgomp/65386] [libgomp] omp task final test case fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65386 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- The test looks bogus to me. Citing the standard: final task A task that forces all of its child tasks to become final and included tasks. None of the explicit tasks (final or not) create any child tasks, so nothing requires any explicit task to be included, so I see no reason why there should be any restriction on where the tasks are scheduled. IMHO the spec just says that all the children of the final task will be included (i.e. tied to the final parent task).
[Bug preprocessor/65387] [4.8/4.9/5 Regression] cpp -C emits extraneous comment header on every file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65387 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-11 CC||jsm28 at gcc dot gnu.org Target Milestone|--- |4.8.5 Summary|cpp -C emits extraneous |[4.8/4.9/5 Regression] cpp |comment header on every |-C emits extraneous comment |file|header on every file Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Heh. Does this since 4.8. This is from stdc-predef.h we forcefully include in each translation unit. You can use -nostdinc to restore original behavior. Note that this bug will likely be closed as invalid/wontfix. OTOH the included comment says the file is LGPL which may have issues if it gets included in sth statically linked? I think we should change its license to BSD/MIT.
[Bug go/64683] FAIL: runtime/pprof -- testing.go:278: The entry did not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683 --- Comment #9 from vries at gcc dot gnu.org --- Created attachment 35010 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35010action=edit libgo.log (nobootstrap build)
[Bug lto/65380] [5 Regression] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |5.0
[Bug tree-optimization/65310] vectorizer uses wrong alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65310 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- It's early SRA dropping alignment info. - # .MEM_48 = VDEF .MEM_47 - # lhs access alignment 128+0 - D.2264.theX = _31; - # .MEM_49 = VDEF .MEM_48 - # lhs access alignment 128+32 - D.2264.theY = _34; - # .MEM_50 = VDEF .MEM_49 - # lhs access alignment 128+64 - D.2264.theZ = _37; - # .MEM_51 = VDEF .MEM_50 - # lhs access alignment 128+96 - D.2264.theT = _40; - # .MEM_52 = VDEF .MEM_51 - # lhs access alignment 128+0 - # rhs access alignment 128+0 - *res_7(D) = D.2264; - # .MEM_9 = VDEF .MEM_52 + SR.22_44 = _31; + SR.23_43 = _34; + SR.24_42 = _37; + SR.25_41 = _40; + # .MEM_8 = VDEF .MEM_1(D) + # lhs access alignment 32+0 + MEM[(struct LorentzVector *)res_7(D)] = SR.22_44; + # .MEM_53 = VDEF .MEM_8 + # lhs access alignment 32+0 + MEM[(struct LorentzVector *)res_7(D) + 4B] = SR.23_43; + # .MEM_54 = VDEF .MEM_53 + # lhs access alignment 32+0 + MEM[(struct LorentzVector *)res_7(D) + 8B] = SR.24_42; + # .MEM_55 = VDEF .MEM_54 + # lhs access alignment 32+0 + MEM[(struct LorentzVector *)res_7(D) + 12B] = SR.25_41; + # .MEM_9 = VDEF .MEM_55 of course as it splits up the aggregate store and we can't represent align + known misalignment with the type used on the MEM_REF we are somewhat lost here. We can do better for the first and the third store though: # .MEM_8 = VDEF .MEM_1(D) # lhs access alignment 128+0 MEM[(struct LorentzVector *)res_7(D)] = SR.22_44; # .MEM_53 = VDEF .MEM_8 # lhs access alignment 32+0 MEM[(struct LorentzVector *)res_7(D) + 4B] = SR.23_43; # .MEM_54 = VDEF .MEM_53 # lhs access alignment 64+0 MEM[(struct LorentzVector *)res_7(D) + 8B] = SR.24_42; # .MEM_55 = VDEF .MEM_54 # lhs access alignment 32+0 MEM[(struct LorentzVector *)res_7(D) + 12B] = SR.25_41; that seems to be enough here as the vectorizer is clever enough to only care about the first ref alignment of a group access. Phew ;) Testing Index: gcc/tree-sra.c === --- gcc/tree-sra.c (revision 221324) +++ gcc/tree-sra.c (working copy) @@ -1597,7 +1597,7 @@ build_ref_for_offset (location_t loc, tr misalign = (misalign + offset) (align - 1); if (misalign != 0) align = (misalign -misalign); - if (align TYPE_ALIGN (exp_type)) + if (align != TYPE_ALIGN (exp_type)) exp_type = build_aligned_type (exp_type, align); mem_ref = fold_build2_loc (loc, MEM_REF, exp_type, base, off);
[Bug lto/65380] [5 Regression] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #2) Will take a look. Is it an open source program? Thanks. Unfortunately, it isn't open source; it's mostly used in house and there were talks about open-sourcing it, but it has not (yet) happened.
[Bug libgomp/65385] [libgomp] omp task untied test case fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65385 Sebastian Huber sebastian.hu...@embedded-brains.de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Sebastian Huber sebastian.hu...@embedded-brains.de --- I will forward this to the test suite authors. Is it then possible to test the task untied at all?
[Bug c++/65389] New: long compile time on incorrect code with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65389
Bug ID: 65389
Summary: long compile time on incorrect code with lambdas
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
The following program takes ages to compile:
template typename F, typename FF
void demangle_type_rec(F out, FF prepend_suffix)
{
//int class_type = // uncomment to get infinite stream of error messages
demangle_type([] {});
}
template typename Out
void demangle_type(Out out)
{
demangle_type_rec(out, [] {});
}
void print_seqid()
{
demangle_type([] {});
}
Probably it is possible to limit the compilation time on this incorrect case?
[Bug rtl-optimization/63491] Ice in LRA with simple vector test case on power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63491 --- Comment #9 from Peter Bergner bergner at gcc dot gnu.org --- (In reply to Peter Bergner from comment #8) (In reply to Vladimir Makarov from comment #7) I tried again the test on gcc rev. 221324 (Mar 10) with the mentioned options and I've failed to reproduce the crash. Maybe a configure option thing? Maybe --disable-bootstrap which I have been using? I just tried using the same revision you did (221324) and I still see the same error: Well I did a normal bootstrap build and also a --enable-checking=release build and they both ICE with the test case, so I'm not sure how you can't be seeing this.
[Bug c/65395] [4.9 Regression] compiler crash, -ftree-pre leads to SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65395 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.3 Summary|compiler crash, -ftree-pre |[4.9 Regression] compiler |leads to SSA corruption |crash, -ftree-pre leads to ||SSA corruption --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r198681, got fixed again with r211625.
[Bug tree-optimization/64705] Bad code generation of sieve on x86-64 because of too aggressive IV optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64705 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from amker at gcc dot gnu.org --- Fixed according to Vlad's input.
[Bug target/65369] [5 Regression] nettle test failure on powerpc64le-linux-gnu when built with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65369 --- Comment #8 from Martin Sebor msebor at gcc dot gnu.org --- Created attachment 35016 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35016action=edit Test case for nettle md4 test failure. The attached test case reduced from Nettle 3.0 test 7 in testsuite/md4-test.c reproduces the suspected gcc 5.0 incorrect code generation on ppc64le. Compile with -O3 and run and observe a SIGABRT.
[Bug c++/65396] New: Function template default template arguments not merged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65396
Bug ID: 65396
Summary: Function template default template arguments not
merged
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at stellarscience dot com
template typename T, T * void f();
template typename T, T * = nullptr void f() {}
int main() { fint(); }
gcc inaccurately rejects this program, which is violating the following
sentence from [C++11 14.1 p10]
The set of default template-arguments available for use with a template
declaration or definition is obtained by merging the default arguments from the
definition (if in scope) and all declarations in scope in the same way default
function arguments are (8.3.6).
