[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=35006&action=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/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=35007&action=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/65385] [libgomp] omp task untied test case fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65385 --- Comment #1 from Sebastian Huber --- Created attachment 35008 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35008&action=edit Test program.
[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 --- Created attachment 35009 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35009&action=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 --- 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 Sebastian Huber changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Sebastian Huber --- I will forward this to the test suite authors. Is it then possible to test the task untied at all?
[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 --- IMHO not, I view the untied clause purely as an optimization hint (and libgomp parses it, but ignores it).
[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 --- 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 --- > > 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 libgomp/65386] [libgomp] omp task final test case fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65386 --- Comment #2 from Jakub Jelinek --- 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 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 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 --- 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 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 changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |5.0
[Bug rtl-optimization/65379] ifcvt does not clean up dead instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65379 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-11 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug tree-optimization/65310] vectorizer uses wrong alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65310 --- Comment #8 from Richard Biener --- Whoops - tested in the wrong tree. Can reproduce now - investigating.
[Bug tree-optimization/65310] vectorizer uses wrong alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65310 Richard Biener changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #9 from Richard Biener --- 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 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 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 --- 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=35010&action=edit libgo.log (nobootstrap build)
[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 --- 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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #37 from Richard Biener --- Fixed.
[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 --- (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 sanitizer/65365] false positive signed negation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65365 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- 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 --- Author: mpolacek Date: Wed Mar 11 10:37:38 2015 New Revision: 221346 URL: https://gcc.gnu.org/viewcvs?rev=221346&root=gcc&view=rev Log: Backported from mainline 2014-12-04 Marek Polacek 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] 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 changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- 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 --- Comment #2 from Marek Polacek --- (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 changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- 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/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 --- Ah, we have PR54979 for that already... Marek, would you be interested to look at this in stage1?
[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 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 --- (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 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 void demangle_type_rec(F out, FF prepend_suffix) { //int class_type = // uncomment to get infinite stream of error messages demangle_type([&] {}); } template 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 tree-optimization/65310] vectorizer uses wrong alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65310 --- Comment #10 from Richard Biener --- Author: rguenth Date: Wed Mar 11 15:09:51 2015 New Revision: 221348 URL: https://gcc.gnu.org/viewcvs?rev=221348&root=gcc&view=rev Log: 2015-03-11 Richard Biener 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 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 --- Created attachment 35011 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35011&action=edit gcc14:/home/amylaar/pr39374/pr39374-diff
[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 --- Created attachment 35012 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35012&action=edit gcc14:/home/amylaar/pr39374/pr39374-r14476
[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=35013&action=edit preprocessed source g++ (GCC) 5.0.0 20150311 (experimental) === e.cc === #include auto f(int n){ return std::make_shared(); } === $ 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 'template 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*, vec**, bool, int) /gcc/gcc/cp/call.c:4080 0x7907d1 finish_call_expr(tree_node*, vec**, 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 other/65384] Intel MPX does not support x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65384 H.J. Lu 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 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 changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez --- 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 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 --- (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 middle-end/65391] unnecessary load of conditionally updated pointer in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65391 David Edelsohn 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 --- Confirmed.
[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 --- 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 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 --- Author: meissner Date: Wed Mar 11 16:57:41 2015 New Revision: 221350 URL: https://gcc.gnu.org/viewcvs?rev=221350&root=gcc&view=rev Log: [gcc] 2015-03-09 Michael Meissner 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 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 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 changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Jakub Jelinek --- 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 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 --- 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 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 changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #7 from Aldy Hernandez --- 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 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 --- Any progress on this? This is a P1 PR, but no comments have been added for more than a month...
[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 --- (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 changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek --- Fixed, thanks.
[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 int main() { std::deque 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++/65392] Bad mangled names in Debug Mode assertions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65392 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-11 Ever confirmed|0 |1
[Bug rtl-optimization/64366] Segmentation fault in remove_pseudos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64366 --- Comment #2 from Vladimir Makarov --- 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 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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Aldy Hernandez --- 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 Date: Mon Dec 9 11:30:39 2013 + 2013-12-09 Alan Modra Apply from mainline 2013-12-05 Alan Modra * configure.ac (BUILD_CXXFLAGS) Don't use ALL_CXXFLAGS 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 --- Author: gjl Date: Wed Mar 11 18:35:52 2015 New Revision: 221354 URL: https://gcc.gnu.org/viewcvs?rev=221354&root=gcc&view=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++/63711] can not compile llvm in debug mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63711 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|unknown |4.9.1 Resolution|--- |FIXED Target Milestone|--- |4.9.2 --- Comment #2 from Jonathan Wakely --- Fixed then.
[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 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 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 --- Author: gjl Date: Wed Mar 11 18:51:09 2015 New Revision: 221355 URL: https://gcc.gnu.org/viewcvs?rev=221355&root=gcc&view=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 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 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 --- Fixed.
[Bug libstdc++/65393] std::thread shared_ptr inefficiency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65393 Jonathan Wakely 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 --- (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 libstdc++/63711] can not compile llvm in debug mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63711 Jonathan Wakely changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Jonathan Wakely --- This is a dup of PR 63500 *** This bug has been marked as a duplicate of bug 63500 ***
[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 changed: What|Removed |Added CC||dushistov at mail dot ru --- Comment #11 from Jonathan Wakely --- *** Bug 63711 has been marked as a duplicate of this bug. ***
[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 changed: What|Removed |Added Status|NEW |WAITING CC||aldyh at gcc dot gnu.org --- Comment #20 from Aldy Hernandez --- 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/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 changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #3 from Pat Haugen --- (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=221297&root=gcc&view=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 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 --- Author: mpolacek Date: Wed Mar 11 20:36:56 2015 New Revision: 221359 URL: https://gcc.gnu.org/viewcvs?rev=221359&root=gcc&view=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 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 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=35015&action=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 libfortran/65200] Handle EPERM when opening files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65200 --- Comment #7 from Janne Blomqvist --- Author: jb Date: Wed Mar 11 21:34:22 2015 New Revision: 221361 URL: https://gcc.gnu.org/viewcvs?rev=221361&root=gcc&view=rev Log: PR 65200 Handle EPERM in addition to EACCES. gcc/fortran ChangeLog: 2015-03-11 Janne Blomqvist PR libfortran/65200 * gfortran.texi: Document behavior when opening files without explicit ACTION= specifier. libgfortran ChangeLog: 2015-03-11 Janne Blomqvist 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 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 --- 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 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 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/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 --- 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 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 --- (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 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 --- 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 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 void f(); template void f() {} int main() { f(); } 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).
[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 --- Created attachment 35016 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35016&action=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.