[Bug fortran/68800] Fortran FE produces many memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68800 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-18 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- There are six PR already opened for memory leak.
[Bug c/68971] -Woverflow false alarm in code unreachable after __builtin_mul_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971 --- Comment #6 from Paul Eggert --- (In reply to Martin Sebor from comment #5) > This is a valid constant expression I'm aware of the distinction between constant and other expressions. I'm trying to give the ordinary user's viewpoint, not the viewpoint of a language standards nerd. From the ordinary user's viewpoint GCC is busted here because it is crying wolf. There are tons of other places where GCC could cry wolf while following the letter of the standard, but GCC doesn't do that because in practice crying wolf is counterproductive. > since __builtin_mul_overflow has already computed the product it > seems that the result should be used rather than computed again using plain > multiplication. It's a test program, and it's doing things twice in order to test them for consistency. You're right, most likely this particular combination wouldn't occur except in test programs. So it could be that the use of -Wno-overflow can be limited to test programs, if we're lucky. Still, it'd be better if GCC were fixed to not cry wolf in situations like these.
[Bug fortran/68968] Internal Compiler error with cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68968 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-18 Summary|Internal Compiler error |Internal Compiler error ||with cpp Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- > If gfortran is replaced by cpp in the above, it seems to generate what one > would expect. Confirmed from 4.4 up to trunk (6.0). I get the same ICE if I compile the test with -cpp. > A workaround is to remove the apostrophes around 's', 'd', and 'q'. This "fixes" the ICE, but the executable prints C_FLOAT for s, d, or q and ICE for -Dplet_=\'q\'.
[Bug c++/68954] [5/6 Regression] -Wdeprecated-declarations -Werror errors for system header templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68954 --- Comment #6 from rguenther at suse dot de --- On Thu, 17 Dec 2015, manu at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68954 > > --- Comment #4 from Manuel López-Ibáñez --- > (In reply to Richard Biener from comment #0) > > std::auto_ptr is marked as deprecated in > > libstdc++-v3/include/backward/auto_ptr.h > > and > > > > #include > > > > int main() > > { > > int i; > > std::auto_ptr x; > > } > > > > warns about this even without -Wsystem-headers. What is worse, since GCC > > 5.3 > > Perhaps something changed in the location passed to the warning? Or there > should be an explicit check of whether the location of the declaration is at a > system header. > > > adding -Werror makes this an error while with 5.2 it was a warning despite > > -Werror: > > Sorry, how is this a bug and not simply working as intended? I just wanted clarification for that. Yes, it looks like it now works as intended but it makes packages that previously build fine with -Werror fail now when updating from GCC 5.2 to 5.3. I agree the new behavior makes sense but I wondered if it was intentionally that for warnings enabled by default (no -W*) we continue issueing a warning rather than an error with -Werror.
[Bug c++/68795] [6 Regression] Use of uninitialised value of size 8 in cp_parser_postfix_expression (parser.c:6831)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68795 --- Comment #4 from Nick Clifton --- Hi David, > Bother; I have another patch for this I was about to post, which is > bootstrapping right now Oops - sorry for treading on your toes! Cheers Nick
[Bug tree-optimization/68962] [6 Regression] internal compiler error: in vect_analyze_stmt, at tree-vect-stmts.c:8013 when building 416.gamess on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68962 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from ktkachov at gcc dot gnu.org --- dup. *** This bug has been marked as a duplicate of bug 68946 ***
[Bug tree-optimization/68946] [6 Regression] ICE at -O3 on x86_64-linux-gnu in both 32- and 64-bit modes (in vect_analyze_stmt, at tree-vect-stmts.c:8013)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68946 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #7 from ktkachov at gcc dot gnu.org --- *** Bug 68962 has been marked as a duplicate of this bug. ***
[Bug fortran/68196] [4.9/5 Regression] ICE on function result with procedure pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68196 --- Comment #10 from Paul Thomas --- Author: pault Date: Fri Dec 18 09:34:13 2015 New Revision: 231807 URL: https://gcc.gnu.org/viewcvs?rev=231807&root=gcc&view=rev Log: 2015-12-18 Paul Thomas PR fortran/68196 *expr.c (gfc_has_default_initializer): Prevent infinite recursion through this function for procedure pointer components. * trans-array.c (structure_alloc_comps): Ditto twice. 2015-12-18 Paul Thomas PR fortran/68196 * gfortran.dg/proc_ptr_48.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_48.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/68534] No error on mismatch in number of arguments between submodule and module interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68534 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Paul Thomas --- I corrected this error on 2015-12-05 but, for some reason, the commit has not appeared below. Anyway, it's done (I just checked :-) ) and I am closing the PR. Thanks for the report Paul
[Bug rtl-optimization/68796] Make use of and-immediate+compare instructions more robust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68796 --- Comment #2 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Dec 18 09:58:07 2015 New Revision: 231810 URL: https://gcc.gnu.org/viewcvs?rev=231810&root=gcc&view=rev Log: [AArch64] PR rtl-optimization/68796 Add compare-of-zero_extract pattern PR rtl-optimization/68796 * config/aarch64/aarch64.md (*and3nr_compare0_zextract): New pattern. * config/aarch64/aarch64.c (aarch64_select_cc_mode): Handle ZERO_EXTRACT comparison with zero. (aarch64_mask_from_zextract_ops): New function. * config/aarch64/aarch64-protos.h (aarch64_mask_from_zextract_ops): New prototype. * gcc.target/aarch64/tst_3.c: New test. * gcc.target/aarch64/tst_4.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/aarch64/tst_3.c trunk/gcc/testsuite/gcc.target/aarch64/tst_4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-protos.h trunk/gcc/config/aarch64/aarch64.c trunk/gcc/config/aarch64/aarch64.md trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707 --- Comment #22 from rguenther at suse dot de --- On Thu, 17 Dec 2015, alalaw01 at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707 > > --- Comment #21 from alalaw01 at gcc dot gnu.org --- > Here's the smallest testcase I could come up with (where SLP gets cancelled, > but we end up with fewer st2's than before)...the key seems to be things being > used in multiple places. > > #define N 1024 > > int in1[N], in2[N]; > int out1[N], out2[N]; > int w[N]; > > void foo() { > for (int i = 0; i < N; i+=2) > { > int a = in1[i] & in2[i]; > int b = in1[i+1] & in2[i+1]; > out1[i] = a; > out1[i+1] = b; > out2[i] = (a + w[i]) ^ (b+w[i+1]); > out2[i+1] = (b + w[i]) ^ (a+w[i+1]); > } > } With discarding the instance for out2 we end up using both SLP and load-lanes for in1[], in2[] and w[] which ends up making those loads redundantly. The code .L2: ld2 {v16.4s - v17.4s}, [x2] add x0, x0, 32 ld2 {v18.4s - v19.4s}, [x1] ld2 {v2.4s - v3.4s}, [x3], 32 ldr q5, [x2, 16] and v1.16b, v18.16b, v16.16b and v0.16b, v19.16b, v17.16b cmp x5, x3 ldr q21, [x1, 16] ldr q4, [x2], 32 ldr q20, [x1], 32 add v17.4s, v0.4s, v3.4s add v16.4s, v1.4s, v2.4s add v0.4s, v0.4s, v2.4s add v1.4s, v1.4s, v3.4s and v5.16b, v5.16b, v21.16b and v4.16b, v4.16b, v20.16b eor v6.16b, v17.16b, v16.16b eor v7.16b, v1.16b, v0.16b str q5, [x0, -16] str q4, [x0, -32] st2 {v6.4s - v7.4s}, [x4], 32 bne .L2 ret looks as expected - load/store-lanes for out2 and regular vector loads for out1. We need to unroll 4 times for load-lanes vs. doing only SLP which requires only 2 times unrolling (I wondered if load-lanes would require more unrolling we should prefer SLP anyway?). With SLP .L2: ldr q3, [x0, x5] ldr q2, [x0, x4] ldr q0, [x0, x2] rev64 v4.4s, v3.4s rev64 v1.4s, v2.4s and v2.16b, v2.16b, v3.16b trn2v3.4s, v0.4s, v0.4s trn1v0.4s, v0.4s, v0.4s and v1.16b, v1.16b, v4.16b str q2, [x0, x3] add v0.4s, v0.4s, v2.4s add v1.4s, v1.4s, v3.4s eor v0.16b, v1.16b, v0.16b str q0, [x0, x1] add x0, x0, 16 cmp x0, 4096 bne .L2 indeed looks much nicer because it can share the actual loads and ANDs (the vectorizer doesn't and doesn't know that, only later CSE does, so we can't use that "knowledge" for our decision). But note there are no st2 remaining (as expected for a full SLP vectorization). Such cases were why I was thinking to apply this logic to all SLP instances at once (but then without knowing about actual sharing we have to wheight N non-permuted SLP instances against M (partially) permuted SLP instances). We can build up load sharing information after we built all SLP instances and then do some decision based on that (this would also make it possible to improve SLP costing in general which simply assumes no later CSE will happen). Hybrid SLP stmts simply mean that we not only need to have different permutations of loads but we also have to duplicate shared compute stmts (as elements are permuted differently). In this case the ANDs for computing a and b. Another improvement possibility for the current heuristic would be to query whether _all_ loads need to be permuted with SLP, like with if (STMT_VINFO_STRIDED_P (stmt_vinfo) || ! SLP_TREE_LOAD_PERMUTATION (load_node).exists () || ! vect_load_lanes_supported (STMT_VINFO_VECTYPE (stmt_vinfo), GROUP_SIZE (stmt_vinfo))) break; thus if there is a load node which is not permuted then retain the SLP. This would preserve the SLP for out2 because there are unpermuted uses of a and b. It would also preserve the SLP if you comment the out1 stores thus generate .L2: ldr q3, [x0, x4] ldr q2, [x0, x3] ldr q0, [x0, x2] rev64 v5.4s, v3.4s rev64 v1.4s, v2.4s and v2.16b, v2.16b, v3.16b trn2v4.4s, v0.4s, v0.4s trn1v0.4s, v0.4s, v0.4s and v1.16b, v1.16b, v5.16b add v0.4s, v0.4s, v2.4s add v1.4s, v1.4s, v4.4s eor v0.16b, v1.16b, v0.16b str q0, [x0, x1] add x0, x0, 16 cmp x0, 4096 bne .L2 instead of .L2: ld2 {v6.4s - v7.4s}, [x2], 32 ld2 {v16.4s - v17.4s}, [x1], 32 ld2 {v2.4s - v3.4s}, [x3], 32 and v1.16b, v16.16b, v6.16b and v0.16b, v17.16b, v7.16b add
[Bug tree-optimization/68956] [6 regression] Vectorizer miscompilation of 416.gamess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68956 --- Comment #5 from Ilya Enkovich --- Author: ienkovich Date: Fri Dec 18 10:01:02 2015 New Revision: 231811 URL: https://gcc.gnu.org/viewcvs?rev=231811&root=gcc&view=rev Log: gcc/ PR tree-optimization/68956 * tree-vect-stmts.c (vect_init_vector): Fix constants used for boolean vectors. gcc/testsuite PR tree-optimization/68956 * gcc.target/i386/pr68956.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr68956.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/68956] [6 regression] Vectorizer miscompilation of 416.gamess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68956 Ilya Enkovich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Ilya Enkovich --- Fixed
[Bug target/68973] [6 regression] Internal compiler error on power for gcc/testsuite/g++.dg/pr67211.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68973 Richard Biener changed: What|Removed |Added Target||powerpc64* Target Milestone|--- |6.0
[Bug c++/68954] [5/6 Regression] -Wdeprecated-declarations -Werror errors for system header templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68954 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- To me the new behavior looks right.
[Bug tree-optimization/68906] [6 Regression] ICE at -O3 on x86_64-linux-gnu: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68906 --- Comment #4 from Ilya Enkovich --- Author: ienkovich Date: Fri Dec 18 10:16:56 2015 New Revision: 231812 URL: https://gcc.gnu.org/viewcvs?rev=231812&root=gcc&view=rev Log: gcc/ 2015-12-18 Yuri Rumyantsev PR tree-optimization/68906 * tree-ssa-loop-unswitch.c (tree_unswitch_outer_loop): Add check that an exit block belongs to LOOP. gcc/testsuite/ 2015-12-18 Yuri Rumyantsev PR tree-optimization/68906 * gcc.dg/torture/pr68906.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr68906.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-unswitch.c
[Bug tree-optimization/68964] [6 regression] Internal compiler error for test case gcc.dg/tm/20100610.c since r231674
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68964 Richard Biener changed: What|Removed |Added CC||rth at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #2 from Richard Biener --- So TM does expand_assign_tm on # .MEM_47 = VDEF <.MEM_4> MEM[(double *)elementPtr_1 + 56B] = vect_cst__54; doing else if (store_p && !load_p) { transaction_subcode_ior (region, GTMA_HAVE_STORE); gcall = build_tm_store (loc, lhs, rhs, gsi); } but gcall is NULL and thus if (!gcall) { tree lhs_addr, rhs_addr, tmp; ... else { tmp = NULL_TREE; lhs_addr = gimplify_addr (gsi, lhs); } rhs_addr = gimplify_addr (gsi, rhs); which builds the address of vect_cst__54 which is obviously not going to work. Not sure what TM people were thinking of here. If you really need sth in memory then you need to create a stack var, store to it and use its address. Simply doing the above isn't going to work. Leaving to rth.
[Bug tree-optimization/68951] [6 Regression] ICE in vect_update_misalignment_for_peel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68951 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/68963] [4.9/5/6 Regression] O3 vs. O2 discards part of loop and terminates early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68963 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.7.4 Keywords||wrong-code Last reconfirmed||2015-12-18 Component|c |tree-optimization CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|O3 vs. O2 discards part of |[4.9/5/6 Regression] O3 vs. |loop and terminates early |O2 discards part of loop ||and terminates early Target Milestone|--- |4.9.4 Known to fail||4.8.5, 4.9.3, 5.3.0, 6.0 --- Comment #1 from Richard Biener --- Confirmed. This is complete peeling doing sth wrong: test123.c:10:2: note: loop with 4 iterations completely unrolled Last iteration exit edge was proved true. We have bogus range info in .pcom: : # RANGE [0, 3] NONZERO 3 # i_23 = PHI <0(4), i_20(9)> if (K_5(D) > i_23) goto ; else goto ; ... : # RANGE [1, 4] NONZERO 7 i_20 = i_23 + 1; if (i_20 < _21) goto ; else goto ; : goto ; but disabling VRP1 doesn't help here (it uses niter analysis to derive the above so niter analysis is wrong in some way).
[Bug tree-optimization/68961] [6 regression] Test case gcc.target/powerpc/pr60203.c fails since r231674
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68961 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0 --- Comment #3 from Richard Biener --- As said I can't reproduce this with a cross. The function is optimized way before we get to vectorization. spawn /home/abuild/rguenther/obj-ppc64le-g/gcc/xgcc -B/home/abuild/rguenther/obj-ppc64le-g/gcc/ /space/rguenther/src/svn/trunk3/gcc/testsuite/gcc.target/powerpc/pr60203.c -fno-diagnostics-show-caret -fdiagnostics-color=never -mcpu=power8 -O3 -S -o pr60203.s^M PASS: gcc.target/powerpc/pr60203.c (test for excess errors) PASS: gcc.target/powerpc/pr60203.c scan-assembler-not stfd PASS: gcc.target/powerpc/pr60203.c scan-assembler-not lfd PASS: gcc.target/powerpc/pr60203.c scan-assembler-not lxsdx PASS: gcc.target/powerpc/pr60203.c scan-assembler-not stxsdx PASS: gcc.target/powerpc/pr60203.c scan-assembler-not mfvsrd PASS: gcc.target/powerpc/pr60203.c scan-assembler-not mtvsrd pack: blr this is for ppc64le. Already .fre1 has pack (double a, double aa) { double u$d$0; union u_ld u; : u.d[1] = aa_4(D); u ={v} {CLOBBER}; return a_2(D); } where u is later trivially deleted as dead. Cross from x86_64 configured as > ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: powerpc64le-suse-linux Configured with: /space/rguenther/src/svn/trunk3/configure --disable-bootstrap --target=powerpc64le-suse-linux --enable-languages=c,c++,fortran : (reconfigured) /space/rguenther/src/svn/trunk3/configure --disable-bootstrap --target=powerpc64le-suse-linux --enable-languages=c,c++,fortran : (reconfigured) /space/rguenther/src/svn/trunk3/configure --disable-bootstrap --target=powerpc64le-suse-linux --enable-languages=c,c++,fortran : (reconfigured) /space/rguenther/src/svn/trunk3/configure --disable-bootstrap --target=powerpc64le-suse-linux --enable-languages=c,c++,fortran : (reconfigured) /space/rguenther/src/svn/trunk3/configure --disable-bootstrap --target=powerpc64le-suse-linux target_alias=powerpc64le-suse-linux CFLAGS=-g CXXFLAGS=-g --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: posix gcc version 6.0.0 20151217 (experimental) [trunk revision 221942] (GCC)
[Bug c++/67592] A virtual member function declared constexpr fails to trigger a diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67592 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-12-18 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- Mine.
[Bug target/68937] i686: -fno-plt produces wrong code (maybe only with tailcall)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68937 --- Comment #11 from Zdenek Sojka --- (In reply to H.J. Lu from comment #10) > (In reply to Zdenek Sojka from comment #9) ... > > > > Please try > > https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01759.html Testsuite run with "-fPIC -fno-plt" patched by https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01838.html doesn't introduce any new ICEs, and fixes all exec failures, compared to trunk.
[Bug testsuite/68776] [6 regression] gcc.dg/vect/vect-widen-mult-const-[su]16.c failures since r226675
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68776 --- Comment #7 from Richard Biener --- (In reply to rguent...@suse.de from comment #6) > On December 17, 2015 4:19:00 PM GMT+01:00, "wschmidt at gcc dot gnu.org" > wrote: > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68776 > > > >--- Comment #5 from Bill Schmidt --- > >(In reply to Bill Schmidt from comment #4) > >> Yep. I'll verify the fix and commit today if all goes well. Thanks > >for the > >> investigation! > > > >Actually, looking at check_effective_target_vect_int_mult, this won't > >work (and > >I've confirmed it doesn't): > > > > if { ([istarget powerpc*-*-*] && ![istarget powerpc-*-linux*paired*]) > > || [istarget spu-*-*] > > || [istarget i?86-*-*] || [istarget x86_64-*-*] > > || [istarget ia64-*-*] > > || [istarget aarch64*-*-*] > > || [check_effective_target_arm32] } { > > set et_vect_int_mult_saved 1 > > > >So the proposal will still expect powerpc64le to find 2 instances > >instead of 4. > > > >I've verified that we are generating the expected widening > >multiplication > >sequences for foo and bar, and generating 32-bit multiplies for baz. > > But if ppc can do int mult the mult pattern should not apply... Specifically: static gimple * vect_recog_mult_pattern (vec *stmts, tree *type_in, tree *type_out) { ... vectype = get_vectype_for_scalar_type (itype); if (vectype == NULL_TREE) return NULL; /* If the target can handle vectorized multiplication natively, don't attempt to optimize this. */ optab = optab_for_tree_code (MULT_EXPR, vectype, optab_default); if (optab != unknown_optab) { machine_mode vec_mode = TYPE_MODE (vectype); int icode = (int) optab_handler (optab, vec_mode); if (icode != CODE_FOR_nothing) return NULL; so powerpc can _not_ do integer multiplication (V2DI in this case). Ok, so if you take "int" literally it can do vect_int_mult and we don't have a vect_long_mult target. I would say it would help to make the "pattern recognized" printing more specific but that requires some extra work. Let me try sth simple...
[Bug c++/68978] New: [6 Regression] bogus error: lvalue required as left operand of assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68978 Bug ID: 68978 Summary: [6 Regression] bogus error: lvalue required as left operand of assignment Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Target Milestone: --- Boost-1.60 fails to compile: markus@x4 tmp % cat test.ii template int toi() { int i = 0, c = 0, radix = 10, max = 0x7fff; if (max < ((i *= radix) += c)) return 0; return i; } markus@x4 tmp % g++ -c test.ii test.ii: In function ‘int toi()’: test.ii:3:30: error: lvalue required as left operand of assignment if (max < ((i *= radix) += c)) ^
[Bug rtl-optimization/68910] [5/6 regression] huge stack frame and poor code with instruction scheduling at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910 --- Comment #10 from Eric Botcazou --- > In case I revert (e.g. double revert) to enable the LRA for SPARC > > commit a28f6dc56909fc35dd83d4364bc68c69e2450a51 > Author: davem > Date: Tue Sep 22 03:52:45 2015 + > > Revert LRA SPARC changes for now. > > gcc/ > > PR/67622 > Revert: > 2015-09-11 David S. Miller > > then the clr instructions are gone. Interesting, but we cannot do it on the 5 branch and there are apparently still issues even on the mainline. In any case, I have a trivial fix for the code generation issue and a safe change for the stack frame so I'll go for them.
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- This is of course Fortran FE bug. What is the Fortran FE emitting right now is kind like invalid C (and invalid middle-end) below. It wouldn't be invalid C++, but for C++ that would be different baz functions and name mangling would differentiate those; that is not what is going on in C or in what libgfortran expects: typedef __SIZE_TYPE__ size_t; struct D { long stride, lower_bound, ubound; }; struct A { float *base_addr; size_t offset; long dtype; struct D dim[7]; }; struct A1 { float *base_addr; size_t offset; long dtype; struct D dim[1]; }; struct A2 { float *base_addr; size_t offset; long dtype; struct D dim[2]; }; void foo (void) { extern void baz (struct A1 *); struct A1 a1 = { 0, 0, 0, { { 0, 0, 0 } } }; baz (&a1); } void bar (void) { extern void baz (struct A2 *); struct A2 a2 = { 0, 0, 0, { { 0, 0, 0 }, { 0, 0, 0 } } }; baz (&a2); } Above, A stands for generic real(8) array descriptor type that supports up to maximum number of dimensions, A1 for rank 1 and A2 for rank 2 real(8) array descriptor. IMHO you want instead: typedef __SIZE_TYPE__ size_t; struct D { long stride, lower_bound, ubound; }; struct A { float *base_addr; size_t offset; long dtype; struct D dim[7]; }; struct A1 { float *base_addr; size_t offset; long dtype; struct D dim[1]; }; struct A2 { float *base_addr; size_t offset; long dtype; struct D dim[2]; }; void foo (void) { extern void baz (struct A *); struct A1 a1 = { 0, 0, 0, { { 0, 0, 0 } } }; baz ((struct A *) &a1); } void bar (void) { extern void baz (struct A *); struct A2 a2 = { 0, 0, 0, { { 0, 0, 0 }, { 0, 0, 0 } } }; baz ((struct A *) &a2); } and ensure that A/A1/A2 etc. (the various types created by gfc_get_array_type_bounds) have the same TYPE_ALIAS to make the alias oracle happy. I hope only the libgfortran intrinsics that handle various ranks by the same function are a problem, therefore I'd say you should be marking the symbols for those intrinsics with some flag that you want to treat their arguments like assumed rank arrays, and then just cast the addresses of the descriptors you want to pass to them to some reference type to assumed rank descriptor type (dunno if just array7_real(kind=8) (i.e. maximum rank), or something else). Now, the question is if this affects just the intrinsic routines from libgfortran, or user written functions/subroutines too. I hope the latter only should be called with the right rank except for assumed
[Bug c++/68385] [6 Regression] ICE building libstdc++ on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68385 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- So, is this fixed now?
[Bug c++/68978] [6 Regression] bogus error: lvalue required as left operand of assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68978 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-18 CC||ppalka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- Started with r231640: commit d175f0193ed47b61eafd213ca2d3dde73f8f5996 Author: ppalka Date: Tue Dec 15 03:33:53 2015 + Fix PR c++/21802 (two-stage name lookup fails for operators)
[Bug ada/62042] Missing optimization of copying non-limited objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62042 --- Comment #9 from Victor Porton --- Not fixed in 5.3.1.
[Bug ada/62235] segmentation fault on Ada 2012 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62235 --- Comment #7 from Victor Porton --- Not fixed in 5.3.1.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 Jakub Jelinek changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Isn't this related or dup of PR66745 ? As for the lvalue error, reduced testcase is: template int foo (int max, int i, int radix, int c) { if (max < ((i *= radix) += c)) return i / radix; return 0; } int bar (int max, int i, int radix, int c) { return foo <0> (max, i, radix, c); } and that one started with r231640 (doesn't error out if foo is not a template). Do we have a PR for that already, or shall I file a new one?
[Bug other/66827] [6 Regression] left shifts of negative value warnings due to C++14 switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66827 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #8 from Nick Clifton --- Created attachment 37079 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37079&action=edit Convert to unsigned before shifting (In reply to Jakub Jelinek from comment #7) > The question is about the others, but it has been so long that the > locations are all useless. I have just checked. The only problems that still remain are in libiberty/regex.c. The uploaded patch fixes this problem. I plan to submit it for review after running a few more regression tests.
[Bug ada/62236] : error: aggregate value used where an integer was expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62236 --- Comment #5 from Victor Porton --- Not fixed in 5.3.1.
[Bug rtl-optimization/65980] [6 Regression] -fcompare-debug failure building Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65980 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug target/65931] [5/6 regression] dsymutil assertion failure building libgnat-5.dylib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65931 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Any news on this? If we want to workaround it, it should be bisected and analyzed what is the difference in the debug info. Or just use a sane OS ;).
[Bug ipa/66764] [6 Regression] ICE in analyze_function() on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66764 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Hi David, > Analyzing compilation unit I am unable to reproduce this ICE. What command line options were being used when it happened ? Cheers Nick
[Bug bootstrap/67598] [6 Regression] Target powerpc-e500v2-linux-gnuspe failed to bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67598 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #3 from Nick Clifton --- (In reply to Arseny Solokha from comment #2) > Fixed during the last week, as of 6.0.0-alpha20151122 snapshot (in r230440, > apparently). If it is fixed, please could you close this PR ? Cheers Nick
[Bug c++/68979] New: [6 Regression] error: left operand of shift expression ‘(-1 << 4)’ is negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68979 Bug ID: 68979 Summary: [6 Regression] error: left operand of shift expression ‘(-1 << 4)’ is negative Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Target Milestone: --- markus@x4 tmp % cat enum.ii enum A { bit_mask = ~(-1 << 4) }; markus@x4 tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3/g++ -std=c++14 -Wall -Wextra -c enum.ii markus@x4 tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/5.3.1/g++ -std=c++14 -Wall -Wextra -c enum.ii markus@x4 tmp % clang++ -std=c++14 -Wall -Wextra -c enum.ii markus@x4 tmp % icpc -std=c++14 -Wall -Wextra -c enum.ii markus@x4 tmp % g++ -Wall -Wextra -c enum.ii enum.ii:1:29: warning: left shift of negative value [-Wshift-negative-value] enum A { bit_mask = ~(-1 << 4) }; ^ enum.ii:1:26: error: left operand of shift expression ‘(-1 << 4)’ is negative enum A { bit_mask = ~(-1 << 4) }; ^ enum.ii:1:30: error: enumerator value for ‘bit_mask’ is not an integer constant enum A { bit_mask = ~(-1 << 4) }; ^
[Bug c++/68979] [6 Regression] error: left operand of shift expression ‘(-1 << 4)’ is negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68979 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Why do you think this is a bug? Note that -1 << 4 is rejected in a context where an integer constant expression is required only in C++11/14.
[Bug tree-optimization/68977] [gomp4] FAIL: c-c++-common/goacc/loop-2.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68977 vries at gcc dot gnu.org changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #2 from vries at gcc dot gnu.org --- minimal version: ... int main () { int i, j; #pragma acc parallel { #pragma acc loop gang for (i = 0; i < 10; i++) { #pragma acc loop gang for (j = 1; j < 10; j++) { } } #pragma acc loop gang worker for (i = 0; i < 10; i++) { } } return 0; } ... The problem is that we have stmt: ... .step.4_68 = _85; ... And the defining stmt of _85 is NULL. Before oaccdevlow, the assignment loops like: ... .step.4_68 = GOACC_LOOP (1, 1, 10, 1, -1, 0); ... During oaccdevlow we translate the GOACC_LOOP, and we try to gimplify an assign: ... 19254 gimplify_assign (lhs, r, &seq); (gdb) call debug_generic_expr (lhs) .step.4_68 (gdb) call debug_generic_expr (r) (D.1697 * D.1698) * 1 (gdb) call debug_gimple_seq (seq) D.1697 = GOACC_DIM_SIZE (0); D.1698 = GOACC_DIM_SIZE (1); ... But during gimplification, we run into: ... case INIT_EXPR: ... if (seen_error ()) return GS_ERROR; ... And we're left with the uninitialized ssa name. An easy fix seems to be: ... diff --git a/gcc/omp-low.c b/gcc/omp-low.c index 185426f..c1aeddd 100644 --- a/gcc/omp-low.c +++ b/gcc/omp-low.c @@ -19128,7 +19128,7 @@ oacc_xform_loop (gcall *call) -> chunks=ceil (range/(chunksize*threads*step)) striding=false,chunking=false -> chunk_size=ceil(range/(threads*step)),chunks=1 */ - push_gimplify_context (true); + push_gimplify_context (false); switch (code) { ... It means we're left with an uninitialized var, but ssa updating rewrites that into a default def, so we have valid ssa. We could also adopt the omp_lower strategy: ... /* If we have issued syntax errors, avoid doing any heavy lifting. Just replace the OMP directives with a NOP to avoid confusing RTL expansion. */ if (seen_error () && is_gimple_omp (stmt)) { gsi_replace (gsi_p, gimple_build_nop (), true); return; } ...
[Bug c++/68979] [6 Regression] error: left operand of shift expression ‘(-1 << 4)’ is negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68979 --- Comment #2 from Markus Trippelsdorf --- (In reply to Marek Polacek from comment #1) > Why do you think this is a bug? Note that -1 << 4 is rejected in a context > where an integer constant expression is required only in C++11/14. I think that erroring out in this case is too harsh from a QOI standpoint. A warning should be sufficient.
[Bug go/68980] New: [6 regression] ps -o cmd in gotest isn't portable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68980 Bug ID: 68980 Summary: [6 regression] ps -o cmd in gotest isn't portable Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- Host: *-*-solaris2.* Target: *-*-solaris2.* Build: *-*-solaris2.* The use of ps -o cmd in gotest isn't portable: on Solaris, this leads to lots of usage messages in libgo.log PASS ps: unknown output format: -o cmd usage: ps [ -aAdeflcjLPyZ ] [ -o format ] [ -t termlist ] [ -u userlist ] [ -U userlist ] [ -G grouplist ] [ -p proclist ] [ -g pgrplist ] [ -s sidlist ] [ -z zonelist ] 'format' is one or more of: user ruser group rgroup uid ruid gid rgid pid ppid pgid sid taskid ctid pri opri pcpu pmem vsz rss osz nice class time etime stime zone zoneid f s c lwp nlwp psr tty addr wchan fname comm args projid project pset /vol/gcc/src/hg/trunk/local/libgo/testsuite/gotest[623]: 19046 Terminated PASS: bufio and sometimes, in cases where there really some process needs to be killed, to a hang of the whole make check. Solaris ps offers ps -o comm instead, and I suspect there might be more differences on other targets. Rainer
[Bug go/68980] [6 regression] ps -o cmd in gotest isn't portable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68980 Rainer Orth changed: What|Removed |Added Target Milestone|--- |6.0
[Bug ipa/68981] New: [4.9/5/6 Regression] g++.dg/ipa/pr60640-4.C FAILs with -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68981 Bug ID: 68981 Summary: [4.9/5/6 Regression] g++.dg/ipa/pr60640-4.C FAILs with -ftree-vectorize Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Created attachment 37080 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37080&action=edit reduced testcase Output: $ i686-pc-linux-gnu-g++ -O3 -ftree-vectorize gcc/testsuite/g++.dg/ipa/pr60640-4.C $ ./a.out Segmentation fault For the reduced testcase, -O3 is enough: $ i686-pc-linux-gnu-g++ -O3 testcase.C $ ./a.out Aborted The original testcase segfaults on i686, but the reduced testcase Aborts on all other architectures - but only in 4.9 and 5 branches: $ x86_64-pc-linux-gnu-g++-4.9.3 -O3 testcase.C $ ./a.out Aborted Tested revisions for the reduced testcase @ -O3: r231814 - FAIL (segfault) (for i686 only) 5-branch r231650 - FAIL (segfault) (for i686 only) 5_2_0-release, 5_3_0-release - FAIL (abort) (all architectures) 4_9-branch r231643 - FAIL (abort) (all architectures) 4_8-branch r224828 - OK
[Bug libstdc++/68982] New: Missing explicit qualification for std::forward in functional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68982 Bug ID: 68982 Summary: Missing explicit qualification for std::forward in functional Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rogero at howzatt dot demon.co.uk Target Milestone: --- I notice that is no longer consistently prefixing forward with std:: and this means ADL gets invoked, which causes trouble when the argument is from boost namespace and boost::forward is available. As an example, consider libstdc++-v3/include/std/functional at r229290, line 616: operator()(_Tp&& __obj) const noexcept(noexcept(std::__invoke(_M_pm, forward<_Tp>(__obj -> decltype(std::__invoke(_M_pm, std::forward<_Tp>(__obj))) { return std::__invoke(_M_pm, std::forward<_Tp>(__obj)); } This can produce compiler errors when, for instance, the instantiating type _Tp is boost::shared_ptr. I get failures building proprietary code, have not yet produced a simple standa-alone example.
[Bug testsuite/68776] [6 regression] gcc.dg/vect/vect-widen-mult-const-[su]16.c failures since r226675
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68776 --- Comment #8 from Richard Biener --- Author: rguenth Date: Fri Dec 18 13:52:11 2015 New Revision: 231815 URL: https://gcc.gnu.org/viewcvs?rev=231815&root=gcc&view=rev Log: 2015-12-18 Richard Biener PR testsuite/68776 * tree-vect-patterns.c (struct vect_recog_func): New. (vect_vect_recog_func_ptrs): Make an array of function name pairs. (vect_pattern_recog_1): Print the recognized pattern name. Return true if a pattern was recognized. (vect_pattern_recog): Adjust. Stop iterating over pattern recognition functions on a stmt if a pattern was recognized. * gcc.dg/vect/vect-widen-mult-const-s16.c: Adjust. * gcc.dg/vect/vect-widen-mult-const-u16.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c trunk/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-u16.c trunk/gcc/tree-vect-patterns.c
[Bug testsuite/68776] [6 regression] gcc.dg/vect/vect-widen-mult-const-[su]16.c failures since r226675
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68776 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener --- Fixed.
[Bug c++/68970] Missing "expected ; after class" message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68970 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-18 Ever confirmed|0 |1
[Bug middle-end/67639] ICE at -O1 and above on x86_64-linux-gnu in expand_gimple_basic_block, at cfgexpand.c:5697
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67639 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |bernds at gcc dot gnu.org --- Comment #3 from Bernd Schmidt --- Looking into it.
[Bug libstdc++/68982] Missing explicit qualification for std::forward in functional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68982 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-12-18 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 --- My fault.
[Bug c++/68983] New: [6 Regression] ICE: in store_field, at expr.c:6659
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68983 Bug ID: 68983 Summary: [6 Regression] ICE: in store_field, at expr.c:6659 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: jason at gcc dot gnu.org Target Milestone: --- Trying to build LibreOffice shows: markus@x4 tmp % g++ -c -w scmod.ii scmod.ii: In constructor ‘ScGridOptions::ScGridOptions(const SvxOptionsGrid&)’: scmod.ii:5039:163: internal compiler error: in store_field, at expr.c:6659 class ScGridOptions : public SvxOptionsGrid { public: ScGridOptions() : SvxOptionsGrid() {} ScGridOptions( const SvxOptionsGrid& rOpt ) : SvxOptionsGrid( rOpt ) {} void SetDefaults(); const ScGridOptions& operator= ( const ScGridOptions& rCpy ); bool operator== ( const ScGridOptions& rOpt ) const; bool operator!= ( const ScGridOptions& rOpt ) const { return !(operator==(rOpt)); } }; ^ 0x9f28a6 store_field ../../gcc/gcc/expr.c:6659 0x9ed991 expand_assignment(tree_node*, tree_node*, bool) ../../gcc/gcc/expr.c:5020 0x8e07fe expand_gimple_stmt_1 ../../gcc/gcc/cfgexpand.c:3606 0x8e07fe expand_gimple_stmt ../../gcc/gcc/cfgexpand.c:3702 0x8e3ee4 expand_gimple_basic_block ../../gcc/gcc/cfgexpand.c:5708 0x8e8ed6 execute ../../gcc/gcc/cfgexpand.c:6323 Started with r228704: commit ab48ece0923ded0cbd089ce31d1b3d26c239bc4e Author: jason Date: Mon Oct 12 07:58:43 2015 + PR c++/67557 * expr.c (store_field): Call store_constructor directly when storing a CONSTRUCTOR into a target smaller than its type. Guard against unsafe bitwise copy. Reducing will take a while (8 Mb boost testcase)...
[Bug c++/68975] Request: Provide alternate keyword for decltype in C++03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68975 --- Comment #1 from Jonathan Wakely --- I see that clang supports __decltype (but not __decltype__, strangely)
[Bug tree-optimization/68977] [gomp4] FAIL: c-c++-common/goacc/loop-2.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68977 --- Comment #3 from Nathan Sidwell --- As the code is ill-formed, and IIUC the error only happens if we;ve seen an error, I suggest push_gimplify_context (!seen_error ()); No point making the compiler work harder than necesary in the usual case?
[Bug c++/68983] [6 Regression] ICE: in store_field, at expr.c:6659
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68983 --- Comment #1 from Markus Trippelsdorf --- Created attachment 37081 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37081&action=edit unreduced testcase
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- Regarding the verify_unstripped_args ICE, what I see is that the ICE is while some parts of strip_typedefs check if recursion has changed anything and only build new trees if it changed, other parts rely on various other mechanisms. Say for POINTER_TYPE we use build_pointer_type and hope (the caching should hopefully ensure that it is fine) that we get the same pointer as we called it with if nothing changed, but say for METHOD_TYPE which is the problem here even if nothing really changed we still construct full new argument list etc. and then call build_method_type_directly (or build_function_type for FUNCTION_TYPE) and hope we get the same method type back. I'd say that is rather costly, depends on how often nothing really needs to be stripped, if that is often the case, we'd better just check first if anything changed and only in that case build the list. On the testcase for some reason build_method_type_directly returns a different type though.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #11 from Markus Trippelsdorf --- (In reply to Jakub Jelinek from comment #9) > Isn't this related or dup of PR66745 ? > > As for the lvalue error, reduced testcase is: > template > int > foo (int max, int i, int radix, int c) > { > if (max < ((i *= radix) += c)) > return i / radix; > return 0; > } > > int > bar (int max, int i, int radix, int c) > { > return foo <0> (max, i, radix, c); > } > and that one started with r231640 (doesn't error out if foo is not a > template). > Do we have a PR for that already, or shall I file a new one? I've opened PR68978 for this issue.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #12 from Markus Trippelsdorf --- *** Bug 66745 has been marked as a duplicate of this bug. ***
[Bug c++/66745] [6 Regression] ice in check_unstripped_args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66745 Markus Trippelsdorf changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Markus Trippelsdorf --- Lets close this one. There is more analysis in the duplicate bug. *** This bug has been marked as a duplicate of bug 68763 ***
[Bug tree-optimization/68835] [5 Regression] ICE in set_value_range, at tree-vrp.c:387, with __int128 bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68835 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Fri Dec 18 14:38:17 2015 New Revision: 231817 URL: https://gcc.gnu.org/viewcvs?rev=231817&root=gcc&view=rev Log: Backported from mainline 2015-12-17 Jakub Jelinek PR tree-optimization/68835 * tree.c (get_int_cst_ext_nunits): Return cst.get_precision () / HOST_BITS_PER_WIDE_INT + 1 for all unsigned wi::neg_p (cst) constants. (build_new_int_cst): If cst.get_precision is not a multiple of HOST_BITS_PER_WIDE_INT, zero extend -1 to the precision % HOST_BITS_PER_WIDE_INT. * gcc.dg/pr68835-1.c: New test. * gcc.dg/pr68835-2.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr68835-1.c branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr68835-2.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree.c
[Bug tree-optimization/68835] [5 Regression] ICE in set_value_range, at tree-vrp.c:387, with __int128 bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68835 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jakub Jelinek --- Fixed.
[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Markus, How do I reproduce this ? IE please could you upload a testcase to demonstrate this problem. Cheers Nick
[Bug libstdc++/68984] New: error: ‘constexpr bool std::isinf(double)’ conflicts with a previous declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68984 Bug ID: 68984 Summary: error: ‘constexpr bool std::isinf(double)’ conflicts with a previous declaration Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Target Milestone: --- markus@x4 tmp % cat isinf.cpp #include using std::isinf; markus@x4 tmp % g++ -std=c++11 -c isinf.cpp isinf.cpp:2:12: error: ‘constexpr bool std::isinf(double)’ conflicts with a previous declaration using std::isinf; ^ In file included from /usr/include/features.h:368:0, from /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/x86_64-pc-linux-gnu/bits/os_defines.h:39, from /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/x86_64-pc-linux-gnu/bits/c++config.h:493, from /usr/lib/gcc/x86_64-pc-linux-gnu/6.0.0/include/g++-v6/cmath:41, from isinf.cpp:1: /usr/include/bits/mathcalls.h:201:1: note: previous declaration ‘int isinf(double)’ __MATHDECL_1 (int,isinf,, (_Mdouble_ __value)) __attribute__ ((__const__)); ^ markus@x4 tmp % clang++ -stdlib=libc++ -std=c++11 -c isinf.cpp markus@x4 tmp %
[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770 --- Comment #2 from Markus Trippelsdorf --- trippels@gcc2-power8 ~ % ../gcc/configure --enable-checking=valgrind --with-cpu=power8 --disable-libsanitizer --disable-bootstrap --disable-libstdcxx-pch --disable-libvtv --disable-libitm --disable-libcilkrts --disable-libssp --disable-libgomp --disable-werror --disable-multilib --enable-languages=c,c++ trippels@gcc2-power8 ~ % make -j60 Because of the high parallelism, it is hard to tell exactly which file triggers the issue.
[Bug libstdc++/68276] ios_base::_M_grow_words should use new (std::nothrow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68276 --- Comment #2 from ville at gcc dot gnu.org --- Author: ville Date: Fri Dec 18 15:17:09 2015 New Revision: 231819 URL: https://gcc.gnu.org/viewcvs?rev=231819&root=gcc&view=rev Log: 2015-12-18 Ville Voutilainen PR libstdc++/68276 * src/c++11/ios.cc (_M_grow_words): Use nothrow new. * testsuite/27_io/ios_base/storage/11584.cc: Adjust. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++11/ios.cc trunk/libstdc++-v3/testsuite/27_io/ios_base/storage/11584.cc
[Bug libstdc++/68276] ios_base::_M_grow_words should use new (std::nothrow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68276 Ville Voutilainen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Ville Voutilainen --- Done.
[Bug target/67710] FAIL: gcc.dg/darwin-*version-*.c (test for excess errors) with Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67710 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- Unfortunately, it doesn't work on Mac OS X 10.11.2: every link test FAILs with FAIL: 17_intro/freestanding.cc (test for excess errors) Excess errors: ld: warning: object file (/var/folders/1d/k16rgv6d5039jhvlj8_dzk4h00021y/T//cc0iIoOX.o) was built for newer OSX version (10.11.2) than being linked (10.11) I've found that while ld strips the micro version passed to -mmacosx_version_min, clang does not, resulting in this mess. Given that ld(1) documents the version number format as ., for now it seems that gcc should only pass this to as and ld. Looking... Rainer
[Bug libstdc++/68982] Missing explicit qualification for std::forward in functional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68982 --- Comment #2 from Roger Orr --- Created attachment 37082 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37082&action=edit Example of failure, against code using boost 1.57.0
[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674 --- Comment #12 from chrbr at gcc dot gnu.org --- (In reply to ktkachov from comment #8) > (In reply to chrbr from comment #7) > > I was suggesting in #68934 to make this code invalid and report an error. > > Since SIMD types should not be used for declarations in NOSIMD context. But > > I don't have a strong position about this. We might make this code work by > > repairing the DECL_MODE depending on the usage context, but certainly less > > practical than handle the error. > > > > Other opinions ? > > > > thanks > > I agree about considering this code invalid. > In the context where the variables are being declared there is no SIMD, so > they don't really have a meaning. In the testcase if we wrap the > declarations in a pargma like so: > #pragma GCC push_options > #pragma GCC target ("+simd") > int8x8_t a, b; > int16x8_t e; > #pragma GCC pop_options > > then we don't ICE. > I suspect repairing DECL_MODE will be a messy affair. So unless you see a > clean/safe way of doing this I'd propose just somehow detecting this error > and throwing an error instead of an ICE. I changed my mind :-) : - The surrounding of global declaration by the #pragma is too heavy to be used. The compiler is able to derive the type from the attribute target when using it. - The compiler already handle this partially: see the comment in stor-layout: /* Vector types need to re-check the target flags each time we report the machine mode. We need to do this because attribute target can change the result of vector_mode_supported_p and have_regs_of_mode on a per-function basis. Thus the TYPE_MODE of a VECTOR_TYPE can change on a per-function basis. */ I'm testing a central fix in expand_expr. Will need to check on the other targets but it fixes the case it for arm and aarch64. patch attached for first feedback and early review.
[Bug target/68895] [ARM] ICE with target attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68895 --- Comment #3 from chrbr at gcc dot gnu.org --- Created attachment 37083 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37083&action=edit fix under validation Initial patch to recompute DECL_MODE
[Bug target/65931] [5/6 regression] dsymutil assertion failure building libgnat-5.dylib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65931 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from Jakub Jelinek --- > Any news on this? If we want to workaround it, it should be bisected and > analyzed what is the difference in the debug info. > Or just use a sane OS ;). Using sane tools seems enough ;-) I'd been using a copy of dsymutils from dwarfutils-119, so I didn't notice. Checking back now, the dsymutil from Xcode 7.2 (Apple LLVM 7.0.2 (clang-700.1.81)) works just fine, too. No idea when this started working again. Rainer
[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674 --- Comment #13 from chrbr at gcc dot gnu.org --- Created attachment 37084 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37084&action=edit preliminary fix
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 --- Comment #13 from Jakub Jelinek --- The reason for the weird behavior of build_method_type_directly are default args. We call this function with one argument list and return type etc., where one argument type in TYPE_ARG_TYPES has TREE_PURPOSE some DEFAULT_ARG. Then it is called again on another argument list and return type, but all the types are the same in there, the only difference is that the argument with default arg has different DEFAULT_ARG (and obviously the TREE_LIST nodes aren't the same either, but that is not the problem). TREE_PURPOSE of TYPE_ARG_TYPES nodes is ignored for hash value computation, the two nodes get the same hash value. But, type_list_equal compares even the TREE_PURPOSE and determines the two METHOD_TYPEs are not equal, so we create another METHOD_TYPE. Next, we in-place modify the TREE_PURPOSE in those two METHOD_TYPEs and they actually end up being the same (well, not pointer equality, but simple_cst_equal kind of equality). So, because of the in-place modifications of the default argument, we now have two different METHOD_TYPEs that compare equal and have the same hash value in the hash table, and we get pretty randomly chosen one of those. Now, the question is, do we use hash tables for the FUNCTION_TYPE/METHOD_TYPE just as a way to decrease compiler memory usage (in that case what we do is probably fine), or do we rely on it for other reasons, so that say pointer equality can be used for the "same" function types (strip_typedefs and its caller clearly relies on that, but perhaps that is a bug). If we rely on it for other reasons, then I'd be afraid we couldn't modify the default arguments in place, so we'd need to include the TREE_PURPOSE in the hash value (optionally) and build_method_type_directly again after we change the TREE_PURPOSE, so in the end such change could result in more compiler memory being used for the function/method types.
[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674 chrbr at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |chrbr at gcc dot gnu.org --- Comment #14 from chrbr at gcc dot gnu.org --- Created attachment 37085 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37085&action=edit new preliminary fix
[Bug testsuite/68913] [6 Regression] gcc.dg/lto/pr61886 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68913 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Created attachment 37086 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37086&action=edit Provide weak version of __fread_chk It seems to me that we could solve this problem by providing our own definition of __fread_chk. It does not have to work, since this is a link test, and the real purpose of the test is to check that __fread_chk_warn is not referenced at link time. So I plan on submitting the uploaded patch after a few more local checks.
[Bug c++/68985] New: braced initializer bug when defining a static constexpr int within a class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68985 Bug ID: 68985 Summary: braced initializer bug when defining a static constexpr int within a class Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ryan.burn at gmail dot com Target Milestone: --- The follow code compiles fine with clang (http://melpon.org/wandbox/permlink/VNNQJW7whi3CmEKH) but gives this error with gcc: prog.cc:12:39: error: cannot convert 'my_t' to 'const int' in initialization static constexpr int x = my_t{}; ^ template struct A{ constexpr operator int() { return I; } }; template using my_t = A; template class B { public: static constexpr int x = my_t{}; }; int main() { return 0; }
[Bug sanitizer/65479] sanitizer stack trace missing frames past #0 on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 Bill Schmidt changed: What|Removed |Added Target||powerpc64*-*-linux* CC||wschmidt at gcc dot gnu.org --- Comment #11 from Bill Schmidt --- Martin, can this be closed?
[Bug c/68986] New: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68986 Bug ID: 68986 Summary: internal compiler error: Segmentation fault Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jas...@3db-labs.com Target Milestone: --- Created attachment 37087 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37087&action=edit C source file that demonstrates the error I'm running on Ubuntu 14.04 (x86_64) using gcc 5.3.0. I've also observed this problem with 5.2.0 and 5.2.1 at least, however. I haven't seen any problems with any gcc versions in the 4.x series; it appears to be isolated to 5.x at least. Here is the output of gcc run with the `-v` argument: $ gcc-5 -v Using built-in specs. COLLECT_GCC=gcc-5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.3.0-3ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.3.0 20151204 (Ubuntu 5.3.0-3ubuntu1~14.04) I compile the attached C file (which is reduced down from the original file, down to the minimum code required to show the compiler error) using the following command line: gcc-5 tracesig.c -c -fPIC -mpreferred-stack-boundary=5 -mincoming-stack-boundary=4 The stack-related options come from source code elsewhere in this project that has particular SIMD requirements. When I execute the above command line, I get the following output: tracesig.c: In function ‘char* __check_point_msg_buffer()’: tracesig.c:20:1: internal compiler error: Segmentation fault } ^ 0xa8842f crash_signal ../../src/gcc/toplev.c:383 0xcca22c ix86_expand_prologue() ../../src/gcc/config/i386/i386.c:11503 0xda9dca gen_prologue() ../../src/gcc/config/i386/i386.md:12254 0x877cbf thread_prologue_and_epilogue_insns() ../../src/gcc/function.c:5930 0x8784a2 rest_of_handle_thread_prologue_and_epilogue ../../src/gcc/function.c:6500 0x8784a2 execute ../../src/gcc/function.c:6538 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. I will attach the preprocessed file in a subsequent reply to the report.
[Bug c/68986] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68986 --- Comment #1 from jas...@3db-labs.com --- Created attachment 37088 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37088&action=edit preprocessed output file from gcc
[Bug rtl-optimization/58967] Powerpc -mlra cannot compile quadrature_lib.cc in Spec2006 with -O3 -ffast-math -funroll-loops -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58967 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||wschmidt at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Bill Schmidt --- Fixed some time ago.
[Bug rtl-optimization/55598] LRA on powerpc does not like assembler in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55598 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #3 from Bill Schmidt --- What's the status here?
[Bug sanitizer/65479] sanitizer stack trace missing frames past #0 on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 --- Comment #12 from Martin Sebor --- The sanitizer tests are still failing and this bug still hasn't been fixed. The patch in r224402 was only partial, committed on the assumption that the LLVM AddressSantitizer maintainers would approve my patch for it. Unfortunately, I never managed to convince them to approve the trivial patch there and after much back and forth I gave up (the review is here: http://reviews.llvm.org/D10065).
[Bug c/68971] -Woverflow false alarm in code unreachable after __builtin_mul_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971 --- Comment #7 from Martin Sebor --- I didn't mean to sound like I was lecturing you, just trying to draw a clear distinction between the cases. Perhaps what's needed is for GCC to treat the builtins as constant expressions when they're invoked with them as operands. If you agree with that approach, I suggest closing this bug and opening a new one with that request. FWIW, in my experience, because sophisticated warnings that try to avoid issuing false positives for unreachable code (e.g., -Wmaybe-uninutialized) depend on optimizations they tend to be inconsistent not only between optimization settings but also between different targets. That in turn causes hard to prevent build failures for the same code, which prompts some people/teams to disable them altogether.
[Bug c++/68978] [6 Regression] bogus error: lvalue required as left operand of assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68978 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- It looks like lvalue_kind() does not handle MODOP_EXPRs correctly. It does not consider (i *= radix) (encoded at that point as an unlowered MODOP_EXPR) to be an lvalue. I am testing this fix: diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c index ae176d0..ac22e45 100644 --- a/gcc/cp/tree.c +++ b/gcc/cp/tree.c @@ -186,6 +186,7 @@ lvalue_kind (const_tree ref) break; case MODIFY_EXPR: +case MODOP_EXPR: case TYPEID_EXPR: return clk_ordinary;
[Bug rtl-optimization/49847] [4.8 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 --- Comment #40 from Jeffrey A. Law --- Author: law Date: Fri Dec 18 17:17:14 2015 New Revision: 231821 URL: https://gcc.gnu.org/viewcvs?rev=231821&root=gcc&view=rev Log: [PATCH] [PR rtl-optimization/49847] Fix ICE in CSE due to cc0-setter and cc0-user in different blocks PR rtl-optimization/49847 * cse.c (record_jump_equiv): Handle fold_rtx returning NULL_RTX. PR rtl-optimization/49847 * g++.dg/pr49847-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr49847-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c trunk/gcc/testsuite/ChangeLog
[Bug c/68473] [6 Regression] ICE: in contains_point, at diagnostic-show-locus.c:340 after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68473 --- Comment #10 from Jeffrey A. Law --- Created attachment 37089 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37089&action=edit Another testcase, Attaching another testcase. Hopefully it's fixed by the pending patch from David.
[Bug c/68971] -Woverflow false alarm in code unreachable after __builtin_mul_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971 --- Comment #8 from Paul Eggert --- (In reply to Martin Sebor from comment #7) > Perhaps what's needed is for GCC to treat the builtins as constant > expressions when they're invoked with them as operands. If you agree with > that approach, I suggest closing this bug and opening a new one with that > request. Yes, I already filed a bug report along these lines, as Bug#68120. > because sophisticated warnings that try to avoid > issuing false positives for unreachable code (e.g., -Wmaybe-uninutialized) > depend on optimizations they tend to be inconsistent not only between > optimization settings but also between different targets. Yes, that issue is well known. We generally work around the problem by enabling fancy warnings only on one platform (x86-64) with known settings, and not bothering with other platforms. A corollary of this practice is that warning-related GCC bugs tend not to be reported or fixed on platforms other than x86-64. However, this workaround does not suffice for -Woverflow because -Woverflow is enabled by default. This raises the priority of getting -Woverflow right.
[Bug tree-optimization/68967] Build and test parloops on by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68967 vries at gcc dot gnu.org changed: What|Removed |Added Attachment #37069|0 |1 is obsolete|| --- Comment #7 from vries at gcc dot gnu.org --- Created attachment 37090 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37090&action=edit 0003-compile-target-libgomp-before-configuring-other-libs.patch Updated version. With this version, I was able to do a c bootstrap with --disable-multilib.
[Bug c/68120] can't easily deal with integer overflow at compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68120 --- Comment #2 from Paul Eggert --- (In reply to Paul Eggert from comment #0) > I am working around the problem with macro definitions like this: > > # define INT_ADD_OVERFLOW(a, b) \ >(__builtin_constant_p ((a) == (b)) \ > ? _GL_INT_ADD_OVERFLOW (a, b) \ > : __builtin_add_overflow (a, b, &(__typeof__ ((a) + (b))) {0})) Just to follow up on my own bug report, the above approach turned out not to work, because the resulting macro expands to an expression that is not an integer constant expression according to GCC's current rules. I eventually gave up on this approach entirely, and INT_ADD_OVERFLOW (a, b) now expands to this: (0 * (0 * (b) + (a)) - (1)) < 0) ? - (~ (0 * (0 * (b) + (a)) + (0)) == -1) - 0 * (0 * (b) + (a)) + (1)) << (sizeof ((0 * (b) + (a)) + 0) * 8 - 2)) - 1) * 2 + 1) : (0 * (0 * (b) + (a)) + (0 < 0 ? ((b) < 0 ? (a) < 0 * (0 * (b) + (a)) - (1)) < 0) ? - (~ (0 * (0 * (b) + (a)) + (0)) == -1) - 0 * (0 * (b) + (a)) + (1)) << (sizeof ((0 * (b) + (a)) + 0) * 8 - 2)) - 1) * 2 + 1) : (0 * (0 * (b) + (a)) + (0 - (b) : 0 * (0 * (b) + (a)) - (1)) < 0) ? 0 * (0 * (b) + (a)) + (1)) << (sizeof ((0 * (b) + (a)) + 0) * 8 - 2)) - 1) * 2 + 1) : (0 * (0 * (b) + (a)) - (1 - (b) < (a)) : (a) < 0 ? (b) <= (a) + (b) : (b) < 0 ? (a) <= (a) + (b) : (a) + (b) < (b)) Although this *is* an integer constant expression, it is less nice than a simple call to __builtin_add_overflow would be, and it generates less-efficient code in some cases when A and B are not constants.
[Bug target/65421] inefficient code returning float aggregates on powepc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65421 Martin Sebor changed: What|Removed |Added Last reconfirmed|2015-03-18 00:00:00 |2015-12-18 Known to fail||5.1.0, 6.0 --- Comment #2 from Martin Sebor --- Today's trunk emits the same code as 5.1.0.
[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770 --- Comment #3 from Markus Trippelsdorf --- Created attachment 37091 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37091&action=edit unreduced testcase
[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-18 Ever confirmed|0 |1 --- Comment #4 from Markus Trippelsdorf --- trippels@gcc2-power8 c++98 % valgrind --trace-children=yes --track-origins=yes ~/gcc_test/usr/local/bin/g++ -std=gnu++98 -O2 -c parallel_settings.ii ==124421== Memcheck, a memory error detector ==124421== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==124421== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==124421== Command: /home/trippels/gcc_test/usr/local/bin/g++ -std=gnu++98 -O2 -c parallel_settings.ii ==124421== ==124423== Memcheck, a memory error detector ==124423== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==124423== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==124423== Command: /home/trippels/gcc_test/usr/local/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/6.0.0/cc1plus -fpreprocessed parallel_settings.ii -quiet -dumpbase parallel_settings.ii -mcpu=power8 -auxbase parallel_settings -O2 -std=gnu++98 -o /home/trippels/tmp/ccj9CuMk.s ==124423== ==124423== Conditional jump or move depends on uninitialised value(s) ==124423==at 0x10A76104: default_secondary_reload(bool, rtx_def*, int, machine_mode, secondary_reload_info*) (targhooks.c:940) ==124423==by 0x10E4DDB3: rs6000_secondary_reload(bool, rtx_def*, int, machine_mode, secondary_reload_info*) (rs6000.c:18415) ==124423==by 0x1085CE37: copy_cost(rtx_def*, machine_mode, int, bool, secondary_reload_info*) [clone .part.7] (ira-costs.c:445) ==124423==by 0x1085CEA7: copy_cost (ira-costs.c:434) ==124423==by 0x1085CEA7: copy_cost(rtx_def*, machine_mode, int, bool, secondary_reload_info*) [clone .part.7] (ira-costs.c:452) ==124423==by 0x1085D3E3: copy_cost (ira-costs.c:434) ==124423==by 0x1085D3E3: record_reg_classes(int, int, rtx_def**, machine_mode*, char const**, rtx_insn*, reg_class*) [clone .constprop.43] (ira-costs.c:984) ==124423==by 0x1085F77F: record_operand_costs(rtx_insn*, reg_class*) (ira-costs.c:1325) ==124423==by 0x1085FCCB: scan_one_insn (ira-costs.c:1462) ==124423==by 0x1085FCCB: process_bb_for_costs(basic_block_def*) (ira-costs.c:1583) ==124423==by 0x10855A2F: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1798) ==124423==by 0x108626FF: find_costs_and_classes(_IO_FILE*) (ira-costs.c:1680) ==124423==by 0x10862EB3: ira_costs() (ira-costs.c:2213) ==124423==by 0x10859D9B: ira_build() (ira-build.c:3419) ==124423==by 0x1084FA4B: ira (ira.c:5219) ==124423==by 0x1084FA4B: (anonymous namespace)::pass_ira::execute(function*) (ira.c:5511) ==124423== Uninitialised value was created by a stack allocation ==124423==at 0x1085CDA8: copy_cost(rtx_def*, machine_mode, int, bool, secondary_reload_info*) [clone .part.7] (ira-costs.c:426)
[Bug libfortran/68987] New: double free or corruption in _gfortran_st_write_done when a write statement to an internal file uses an invalid format and the ERR= specifier appears.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68987 Bug ID: 68987 Summary: double free or corruption in _gfortran_st_write_done when a write statement to an internal file uses an invalid format and the ERR= specifier appears. Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: mathewc at nag dot co.uk Target Milestone: --- I'm using > gfortran --version GNU Fortran (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) on > uname -a Linux cuivienen.nag.co.uk 4.2.7-300.fc23.x86_64 #1 SMP Wed Dec 9 22:28:30 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > /lib/libc.so.6 GNU C Library (GNU libc) stable release version 2.22, by Roland McGrath et al. ... Compiled by GNU CC version 5.1.1 20150618 (Red Hat 5.1.1-4). and then with > cat foo.f90 && gfortran foo.f90 && ./a.out Program foo Call s('(foo)') End Program Subroutine s(fmt) Character (*) :: fmt Character (1) :: c Integer :: i Write (c, fmt, Iostat=i) 42 If (i==0) Stop 'FAIL1' Write (c, fmt, Err=100) 42 Stop 'FAIL2' 100 Continue Print *, 'ok' End Subroutine *** Error in `./a.out': double free or corruption (out): 0x01050360 *** === Backtrace: = /lib64/libc.so.6(+0x77e35)[0x2b46ad0cae35] /lib64/libc.so.6(+0x8051a)[0x2b46ad0d351a] /lib64/libc.so.6(cfree+0x4c)[0x2b46ad0d6ccc] /lib64/libgfortran.so.3(_gfortran_st_write_done+0x7b)[0x2b46ac6bcdab] ./a.out[0x400a0a] ./a.out[0x400a9e] ./a.out[0x400ad5] /lib64/libc.so.6(__libc_start_main+0xf0)[0x2b46ad073580] ./a.out[0x4007b9] === Memory map: 0040-00401000 r-xp 00:2b 43527338 /fserver/mathewc/test_f/a.out 0060-00601000 r--p 00:2b 43527338 /fserver/mathewc/test_f/a.out 00601000-00602000 rw-p 1000 00:2b 43527338 /fserver/mathewc/test_f/a.out 0104d000-0106e000 rw-p 00:00 0 [heap] 2b46ac3ac000-2b46ac3cd000 r-xp fd:01 1315819 /usr/lib64/ld-2.22.so 2b46ac3cd000-2b46ac3cf000 rw-p 00:00 0 2b46ac3ec000-2b46ac3ef000 rw-p 00:00 0 2b46ac5cc000-2b46ac5cd000 r--p 0002 fd:01 1315819 /usr/lib64/ld-2.22.so 2b46ac5cd000-2b46ac5ce000 rw-p 00021000 fd:01 1315819 /usr/lib64/ld-2.22.so 2b46ac5ce000-2b46ac5cf000 rw-p 00:00 0 2b46ac5cf000-2b46ac6f7000 r-xp fd:01 1321356 /usr/lib64/libgfortran.so.3.0.0 2b46ac6f7000-2b46ac8f7000 ---p 00128000 fd:01 1321356 /usr/lib64/libgfortran.so.3.0.0 2b46ac8f7000-2b46ac8f9000 r--p 00128000 fd:01 1321356 /usr/lib64/libgfortran.so.3.0.0 2b46ac8f9000-2b46ac8fb000 rw-p 0012a000 fd:01 1321356 /usr/lib64/libgfortran.so.3.0.0 2b46ac8fb000-2b46ac9fc000 r-xp fd:01 1321296 /usr/lib64/libm-2.22.so 2b46ac9fc000-2b46acbfb000 ---p 00101000 fd:01 1321296 /usr/lib64/libm-2.22.so 2b46acbfb000-2b46acbfc000 r--p 0010 fd:01 1321296 /usr/lib64/libm-2.22.so 2b46acbfc000-2b46acbfd000 rw-p 00101000 fd:01 1321296 /usr/lib64/libm-2.22.so 2b46acbfd000-2b46acc13000 r-xp fd:01 1312410 /usr/lib64/libgcc_s-5.3.1-20151207.so.1 2b46acc13000-2b46ace12000 ---p 00016000 fd:01 1312410 /usr/lib64/libgcc_s-5.3.1-20151207.so.1 2b46ace12000-2b46ace13000 r--p 00015000 fd:01 1312410 /usr/lib64/libgcc_s-5.3.1-20151207.so.1 2b46ace13000-2b46ace14000 rw-p 00016000 fd:01 1312410 /usr/lib64/libgcc_s-5.3.1-20151207.so.1 2b46ace14000-2b46ace52000 r-xp fd:01 1312475 /usr/lib64/libquadmath.so.0.0.0 2b46ace52000-2b46ad051000 ---p 0003e000 fd:01 1312475 /usr/lib64/libquadmath.so.0.0.0 2b46ad051000-2b46ad052000 r--p 0003d000 fd:01 1312475 /usr/lib64/libquadmath.so.0.0.0 2b46ad052000-2b46ad053000 rw-p 0003e000 fd:01 1312475 /usr/lib64/libquadmath.so.0.0.0 2b46ad053000-2b46ad20a000 r-xp fd:01 1321289 /usr/lib64/libc-2.22.so 2b46ad20a000-2b46ad40a000 ---p 001b7000 fd:01 1321289 /usr/lib64/libc-2.22.so 2b46ad40a000-2b46ad40e000 r--p 001b7000 fd:01 1321289 /usr/lib64/libc-2.22.so 2b46ad40e000-2b46ad41 rw-p 001bb000 fd:01 1321289 /usr/lib64/libc-2.22.so 2b46ad41-2b46ad414000 rw-p 00:00 0 2b46b000-2b46b0021000 rw-p 00:00 0 2b46b0021000-2b46b400 ---p 00:00 0 7ffdd7827000-7ffdd7848000 rw-p 00:00 0 [stack] 7ffdd785d000-7ffdd785f000 r--p 00:00 0 [vvar] 7ffdd785f000-7ffdd7861000 r-xp 00:00 0
[Bug c++/60044] Template argument of alias template not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60044 Roman Perepelitsa changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Roman Perepelitsa --- Fixed by r217250.
[Bug c++/67592] A virtual member function declared constexpr fails to trigger a diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67592 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Dec 18 18:18:47 2015 New Revision: 231824 URL: https://gcc.gnu.org/viewcvs?rev=231824&root=gcc&view=rev Log: /cp 2015-12-18 Paolo Carlini PR c++/67592 * decl.c (grokdeclarator): Reject constexpr virtual member functions; in error messages, prefer % and % to virtual and constexpr, respectively. /testsuite 2015-12-18 Paolo Carlini PR c++/67592 * g++.dg/cpp0x/constexpr-virtual5.C: New. * g++.dg/cpp0x/pr51463.C: Adjust dg-error string. * g++.dg/inherit/pure1.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-virtual5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/pr51463.C trunk/gcc/testsuite/g++.dg/inherit/pure1.C
[Bug c++/67592] A virtual member function declared constexpr fails to trigger a diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67592 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #3 from Paolo Carlini --- Fixed.
[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312 John Paul Adrian Glaubitz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #25 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #24) > Will report back by then. This issue no longer occurs with gcc-5_5.3.1-3 from Debian (SVN/gcc-5 branch r231361) and this bug can therefore be marked as RESOLVED/FIXED. Full build log: https://people.debian.org/~glaubitz/gcc-5_5.3.1-3+sh4_sh4-20151216-2227.build
[Bug libfortran/68987] [5/6 Regression] double free or corruption in _gfortran_st_write_done when a write statement to an internal file uses an invalid format and the ERR= specifier appears.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68987 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-18 CC||jvdelisle at gcc dot gnu.org Summary|double free or corruption |[5/6 Regression] double |in _gfortran_st_write_done |free or corruption in |when a write statement to |_gfortran_st_write_done |an internal file uses an|when a write statement to |invalid format and the ERR= |an internal file uses an |specifier appears. |invalid format and the ERR= ||specifier appears. Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed around revision r222140, may be r222111 (pr65089) for trunk (6.0) and r229935 for the 5 branch.
[Bug rtl-optimization/68988] reload_pseudo_compare_func violates qsort requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68988 --- Comment #1 from Yury Gribov --- The bug was detected with SortChecker tool (https://github.com/yugr/sortcheck).
[Bug rtl-optimization/68988] New: reload_pseudo_compare_func violates qsort requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68988 Bug ID: 68988 Summary: reload_pseudo_compare_func violates qsort requirements Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: y.gribov at samsung dot com CC: vmakarov at redhat dot com Target Milestone: --- One of the comparisons in reload_pseudo_compare_func violates the transitivity axiom (i.e. x < y && y < z => x < z) which is a requirement for proper comparison function. The offending piece is if ((diff = (ira_reg_class_max_nregs[cl2][lra_reg_info[r2].biggest_mode] - ira_reg_class_max_nregs[cl1][lra_reg_info[r1].biggest_mode])) != 0 /* The code below executes rarely as nregs == 1 in most cases. So we should not worry about using faster data structures to check reload pseudos. */ && ! bitmap_bit_p (&non_reload_pseudos, r1) && ! bitmap_bit_p (&non_reload_pseudos, r2)) This one is activated only when non_reload_pseudos is off for both r1 and r2. Now imagine that we compare non-reload pseudos A, B but for reload pseudo C. Then A/B pair will be compared absolutely differently from A/C and B/C pairs. In practice this may lead to violation of transitivity axiom which may puzzle qsort and lead to all sorts of bugs (e.g. unsorted array of pseudos). For additional details check https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01817.html
[Bug c++/68983] [6 Regression] ICE: in store_field, at expr.c:6659
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68983 Markus Trippelsdorf changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-18 Ever confirmed|0 |1 --- Comment #2 from Markus Trippelsdorf --- class SvxOptionsGrid { int nFldDrawX; bool bEqualGrid; public: ~SvxOptionsGrid(); }; class A : SvxOptionsGrid { public: A(SvxOptionsGrid p1) : SvxOptionsGrid(p1) {} }; SvxOptionsGrid a; void fn1() { A b(a); }