[Bug tree-optimization/96929] Failure to optimize right shift of -1 to -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96929 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4866b2f5db117f9e89f82c44ffed57178c09cc49 commit r11-5271-g4866b2f5db117f9e89f82c44ffed57178c09cc49 Author: Jakub Jelinek Date: Tue Nov 24 09:03:17 2020 +0100 middle-end, c++: Treat shifts by negative as undefined [PR96929] The PR38359 change made the -1 >> x to -1 optimization less useful by requiring that the x must be non-negative. Shifts by negative amount are UB, but we for historic reasons had in some (but not all) places some hack to treat shifts by negative value as the other direction shifts by the negated amount. The following patch just removes that special handling, instead we punt on optimizing those (and ideally path isolation should catch that up and turn those into __builtin_unreachable, perhaps with __builtin_warning next to it). Folding the shifts in some places as if they were rotates and in other as if they were saturating just leads to inconsistencies. For C++ constexpr diagnostics and -fpermissive, I've added code to pretend fold-const.c has not changed, without -fpermissive it will be an error anyway and I think it is better not to change all the diagnostics. During x86_64-linux and i686-linux bootstrap/regtest, my statistics gathering patch noted 185 unique -m32/-m64 x TU x function_name x shift_kind x fold-const/tree-ssa-ccp cases. I have investigated the 64 ../../gcc/config/i386/i386.c x86_output_aligned_bss LSHIFT_EXPR wide_int_bitop 64 ../../gcc/config/i386/i386-expand.c emit_memmov LSHIFT_EXPR wide_int_bitop 64 ../../gcc/config/i386/i386-expand.c ix86_expand_carry_flag_compare LSHIFT_EXPR wide_int_bitop 64 ../../gcc/expmed.c expand_divmod LSHIFT_EXPR wide_int_bitop 64 ../../gcc/lra-lives.c process_bb_lives LSHIFT_EXPR wide_int_bitop 64 ../../gcc/rtlanal.c nonzero_bits1 LSHIFT_EXPR wide_int_bitop 64 ../../gcc/varasm.c optimize_constant_pool.isra LSHIFT_EXPR wide_int_bitop cases and all of them are either during jump threading (dom) or during PRE. For jump threading, the most common case is 1 << floor_log2 (whatever) where floor_log2 is return HOST_BITS_PER_WIDE_INT - 1 - clz_hwi (x); and clz_hwi is if (x == 0) return HOST_BITS_PER_WIDE_INT; return __builtin_clz* (x); and so has range [-1, 63] and a comparison against == 0 which makes the threader think it might be nice to jump thread the case leading to 1 << -1. I think it is better to keep the 1 << -1 s in the IL for this and let path isolation turn that into __builtin_unreachable () if the user wishes so. 2020-11-24 Jakub Jelinek PR tree-optimization/96929 * fold-const.c (wide_int_binop) : Return false on negative second argument rather than trying to handle it as shift in the other direction. * tree-ssa-ccp.c (bit_value_binop) : Punt on negative shift count rather than trying to handle it as shift in the other direction. * match.pd (-1 >> x to -1): Remove tree_expr_nonnegative_p check. * constexpr.c (cxx_eval_binary_expression): For shifts by constant with MSB set, emulate older wide_int_binop behavior to preserve diagnostics and -fpermissive behavior. * gcc.dg/tree-ssa/pr96929.c: New test.
[Bug tree-optimization/97964] Missed optimization opportunity for VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97964 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Andrew Pinski --- Here are the ranges that should be figured out: c:[0,1] d:[-2,0] e:[0,2] The problem comes from the fact -1/e could be undefined.
[Bug c/97958] ICE in build2, at tree.c:4868
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97958 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2aaf44a90283156ec0e70ad4d9030f3ba5054c6f commit r11-5272-g2aaf44a90283156ec0e70ad4d9030f3ba5054c6f Author: Jakub Jelinek Date: Tue Nov 24 09:04:28 2020 +0100 openmp: Fix C ICE on OpenMP atomics c_parser_binary_expression was using build2 to create a temporary holder for binary expression that c_parser_atomic and c_finish_omp_atomic can then handle. The latter performs then all the needed checking. Unfortunately, build2 performs some checking too, e.g. PLUS_EXPR vs. POINTER_PLUS_EXPR or matching types of the arguments, nothing we can guarantee at the parsing time. So we need something like C++ build_min_nt*. This patch implements that inline. 2020-11-24 Jakub Jelinek PR c/97958 * c-parser.c (c_parser_binary_expression): For omp atomic binary expressions, use make_node instead of build2 to avoid checking build2 performs. * c-c++-common/gomp/pr97958.c: New test.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 Richard Biener changed: What|Removed |Added Component|c |tree-optimization Target||x86_64-*-* --- Comment #6 from Richard Biener --- Hmm, I can't reproduce - there's nothing unusual in your full build log. Martin, I think he's testing one of the snapshot tarballs which have names after the date published.
[Bug rtl-optimization/97954] [11 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97954 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Component|c |rtl-optimization
[Bug c/97955] [11 Regression] ICE in build_array_type_1, at tree.c:8264 since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97955 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c/97958] ICE in build2, at tree.c:4868
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97958 Richard Biener changed: What|Removed |Added Known to work||11.0 --- Comment #3 from Richard Biener --- Fixed on trunk, not sure if you want to backport.
[Bug testsuite/97959] Random FAIL: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o link, -O -flto -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97959 Richard Biener changed: What|Removed |Added Component|lto |testsuite --- Comment #1 from Richard Biener --- Shouldn't they go into the respective parallel gccN/ directory?
[Bug tree-optimization/97960] [8/9/10/11 Regression] Wrong code at -O3 since r8-6511-g3ae129323d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97960 Richard Biener changed: What|Removed |Added Priority|P1 |P2 CC||rguenth at gcc dot gnu.org
[Bug c/97958] ICE in build2, at tree.c:4868
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97958 --- Comment #4 from Jakub Jelinek --- I do (while the #c0 testcase is invalid and I wouldn't care about it much, the first function in the testcase is completely valid and we shouldn't be crashing on that. But will aggregate it with other fixes.
[Bug tree-optimization/96929] Failure to optimize right shift of -1 to -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96929 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed on the trunk.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 96929, which changed state. Bug 96929 Summary: Failure to optimize right shift of -1 to -1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96929 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/97962] [10/11] ICE in build_over_call, at cp/call.c:8976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97962 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to fail||9.3.1 Ever confirmed|0 |1 Last reconfirmed||2020-11-24 Keywords||ice-checking --- Comment #1 from Richard Biener --- ICEs with GCC 9 as well when checking is enabled
[Bug tree-optimization/97964] Missed optimization opportunity for VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97964 Richard Biener changed: What|Removed |Added Keywords||needs-bisection Blocks||85316 --- Comment #2 from Richard Biener --- possibly caused by a bugfix Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #7 from Chris Clayton --- Yes, Richard's correct. I'm building from snapshot releases. That's why I used the term "snapshot releases" in comment 4. I've cloned git://gcc.gnu.org/git/gcc.git and am bisecting between b642fca1c31b2e2175e0860daf32b4ee0d918085 (11-20201108) and c746fc40f4ec8cfc1092efd49d567751858d2099 (11-20201115). I'm not 100% sure this is correct because I'm anything but a git expert and I've never come across a tree that didn't have branches for different strands of development (e.g gcc-10 gcc-11). git bisect start... reported that there were only 7 commits and that feels right, so I'll blunder on until someone tells me I'm doing this wrong (an, hopefully, how I should be doing it)
[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205 --- Comment #17 from rguenther at suse dot de --- On Mon, 23 Nov 2020, bernd.edlinger at hotmail dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205 > > --- Comment #16 from Bernd Edlinger --- > (In reply to SRINATH PARVATHANENI from comment #15) > > (In reply to Bernd Edlinger from comment #14) > > > fixed on trunk. > > > > Thanks Bernd for fixing this on trunk, would you mind backporting this to > > GCC-10 as well? > > > > Thanks you. > > > > Regards, > > Srinath. > > Since it is a gcc_checking_assert that triggers the ICE, > I assumed that does not affect a release build, > is that correct? That is correct.
[Bug tree-optimization/97964] Missed optimization opportunity for VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97964 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Keywords|needs-bisection | --- Comment #3 from Jakub Jelinek --- Changed with r8-2090-g2071f8f980cc0de02af3d7d7de201f4f189058ff
[Bug tree-optimization/97964] Missed optimization opportunity for VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97964 --- Comment #4 from Jakub Jelinek --- Note, trunk handles it fine again starting with r11-4755-g22984f3f090921b5ac80ec0057f6754ec458e97e So I guess we should just add the testcase (perhaps use a parameter instead of volatile etc.) and close, ranger is not backportable and even smaller VRP improvements might be too risky.
[Bug tree-optimization/97964] Missed optimization opportunity for VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97964 --- Comment #5 from Richard Biener --- (In reply to Jakub Jelinek from comment #4) > Note, trunk handles it fine again starting with > r11-4755-g22984f3f090921b5ac80ec0057f6754ec458e97e > So I guess we should just add the testcase (perhaps use a parameter instead > of volatile etc.) and close, ranger is not backportable and even smaller VRP > improvements might be too risky. Agreed.
[Bug tree-optimization/97964] Missed optimization opportunity for VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97964 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a40d5772ff12a3a4f4830b7db27bedf54b617e8e commit r11-5277-ga40d5772ff12a3a4f4830b7db27bedf54b617e8e Author: Jakub Jelinek Date: Tue Nov 24 10:42:56 2020 +0100 testsuite: Add testcase for already fixed bug [PR97964] This testcase started failing with r8-2090 and works again starting with r11-4755. 2020-11-24 Jakub Jelinek PR tree-optimization/97964 * gcc.dg/tree-ssa/pr97964.c: New test.
[Bug target/97950] Unoptimal code generation with __builtin_*_overflow{,_p} for short and __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a1dd66b108cba086f58448ccbe9bf57b0a342f9a
commit r11-5279-ga1dd66b108cba086f58448ccbe9bf57b0a342f9a
Author: Jakub Jelinek
Date: Tue Nov 24 10:45:40 2020 +0100
i386: Add *setcc_hi_1* define_insn_and_split [PR97950]
As the following testcase shows, unlike char, int or long long sized
__builtin_*_overflow{,_p}, for short sized one in most cases the ce1 pass
doesn't optimize the jo/jno or jc/jnc jumps with setting of a pseudo to 0/1
into seto/setc. The reason is missing *setcc_hi_1* pattern. The following
patch implements it using mode iterators so that on i486 and pentium?
one can get the zero extension through and instead of movzbw.
2020-11-24 Jakub Jelinek
PR target/97950
* config/i386/i386.md (*setcc_si_1_and): Macroize into...
(*setcc__1_and): New define_insn_and_split with SWI24
iterator.
(*setcc_si_1_movzbl): Macroize into...
(*setcc__1_movzbl): New define_insn_and_split with SWI24
iterator.
* gcc.target/i386/pr97950.c: New test.
[Bug target/97950] Unoptimal code generation with __builtin_*_overflow{,_p} for short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97950
Jakub Jelinek changed:
What|Removed |Added
Summary|Unoptimal code generation |Unoptimal code generation
|with|with
|__builtin_*_overflow{,_p} |__builtin_*_overflow{,_p}
|for short and __int128 |for short
Resolution|--- |FIXED
Status|ASSIGNED|RESOLVED
--- Comment #6 from Jakub Jelinek ---
Fixed for 11.1, too risky for backports.
[Bug tree-optimization/97964] Missed optimization opportunity for VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97964 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from Jakub Jelinek --- Thus fixed for 11.1+.
[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 Bug 85316 depends on bug 97964, which changed state. Bug 97964 Summary: Missed optimization opportunity for VRP https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97964 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326 --- Comment #12 from rsandifo at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #11) > The larger expressions should be subject to a propagation pass and not > arbitrarily complex static pattern matching. Maybe backprop is a suitable > one to wire this in. Sounds good. backprop was originally added to deal with a similar “move things out of fold-const.c” problem (which is why it's currently so special-purpose).
[Bug c++/97965] New: constexpr evaluation vs. NaNs inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97965
Bug ID: 97965
Summary: constexpr evaluation vs. NaNs inconsistency
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
constexpr bool a = __builtin_nan ("") > 0.0;
constexpr bool b = __builtin_nans ("") > 0.0;
constexpr bool c = __builtin_nan ("") < 0.0;
constexpr bool d = __builtin_nans ("") < 0.0;
strangely accepts the < 0.0 comparisons and rejects the > 0.0 comparisons.
clang++ accepts all of them. IMHO either we should accept all of them, or just
the ones not involving SNaNs, or reject all of them, it is unclear what
exceptions appart from division by zero (and does that apply to floating
point?) should cause constexpr evaluation to fail (I'd hope inexact exception
doesn't count, another question is underflow/overflow, another one is invalid
operations that from non-NaN operands create NaN, another one are operations
with NaNs, another one are operations with SNaNs).
Seems the reason why < 0.0 is accepted is fold_binary_loc uses
tree_expr_nonnegative_warnv_p on the NaN REAL_CST which in the end uses
tree_single_nonnegative_warnv_p which uses !REAL_VALUE_NEGATIVE.
While NaNs have a sign in the representation, it shouldn't affect behavior of
the comparisons, so I think we should never treat NaNs with the sign bit clear
as non-negative.
[Bug middle-end/97943] [11 Regression] ICE with __builtin_clear_padding on flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97943 --- Comment #7 from Jonathan Wakely --- (In reply to Jason Merrill from comment #6) > I think we should reject trying to clear the padding of a > flexible/zero-length array, with error rather than sorry. And handle an > array at the end of a struct like any other array. Nobody should be using > this builtin with the struct hack, it's impossible for it to do anything > sensible. I agree. In the unlikely scenario somebody comes up with a good use, we can relax it later. If we allow it now somebody will find a way to depend on it "working" and then it's harder to remove later.
[Bug tree-optimization/95853] Failure to optimize add overflow pattern to __builtin_add_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95853 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 95853, which changed state. Bug 95853 Summary: Failure to optimize add overflow pattern to __builtin_add_overflow https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95853 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #8 from Chris Clayton --- Sorry, my last comment contains an error. git bisect start... reported 7 bisections would be needed not that there were only 7 commits.
[Bug c++/97966] New: maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97966 Bug ID: 97966 Summary: maybe_instantiate_noexcept Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jonathan.k at qspark dot co Target Milestone: --- Getting the following backtrace while compiling using gcc 10.2 with c++17 on fedora 23 os: 11:09:02 0x5fe0c0 maybe_instantiate_noexcept(tree_node*, int) 11:09:02../.././gcc/cp/pt.c:25346 11:09:02 0x6c5f9a mark_used(tree_node*, int) 11:09:02../.././gcc/cp/decl2.c:5516 11:09:02 0x77cd97 instantiate_class_template_1 11:09:02../.././gcc/cp/pt.c:11819 11:09:02 0x77d7a2 instantiate_class_template(tree_node*) 11:09:02../.././gcc/cp/pt.c:12120 11:09:02 0x7ad0ed complete_type(tree_node*) 11:09:02../.././gcc/cp/typeck.c:137 11:09:02 0x7ad0ed complete_type(tree_node*) 11:09:02../.././gcc/cp/typeck.c:111 11:09:02 0x77cdec instantiate_class_template_1 11:09:02../.././gcc/cp/pt.c:11906 11:09:02 0x77d7a2 instantiate_class_template(tree_node*) 11:09:02../.././gcc/cp/pt.c:12120 11:09:02 0x7ad0ed complete_type(tree_node*) 11:09:02../.././gcc/cp/typeck.c:137 11:09:02 0x7ad0ed complete_type(tree_node*) 11:09:02../.././gcc/cp/typeck.c:111 11:09:02 0x730ef3 cp_parser_nested_name_specifier_opt 11:09:02../.././gcc/cp/parser.c:6642 11:09:02 0x7201ca cp_parser_constructor_declarator_p 11:09:02../.././gcc/cp/parser.c:28667 11:09:02 0x7201ca cp_parser_decl_specifier_seq 11:09:02../.././gcc/cp/parser.c:14349 11:09:02 0x743485 cp_parser_single_declaration 11:09:02../.././gcc/cp/parser.c:29421 11:09:02 0x7437fd cp_parser_template_declaration_after_parameters 11:09:02../.././gcc/cp/parser.c:29084 11:09:02 0x743daa cp_parser_explicit_template_declaration 11:09:02../.././gcc/cp/parser.c:29350 11:09:02 0x746c89 cp_parser_declaration 11:09:02../.././gcc/cp/parser.c:13387 11:09:02 0x746872 cp_parser_toplevel_declaration 11:09:02../.././gcc/cp/parser.c:13466 11:09:02 0x746872 cp_parser_declaration_seq_opt 11:09:02../.././gcc/cp/parser.c:13314 11:09:02 0x746872 cp_parser_namespace_body 11:09:02../.././gcc/cp/parser.c:19727 Attached a generated ii file. Compilation flag: /usr/local/bin/g++ -save-temps=obj -std=c++17 -Wall -Wextra -Wno-unused-parameter -Werror -O3 -g -Wfatal-errors -ftemplate-depth=1800 -ftrack-macro-expansion=1 -static-libstdc++ -fpic -o /Exceptions.cpp.o -c /Exceptions.cpp If you can also provide a code workaround I can use if this is a known issue then it would be great. Thanks in advance, Jonathan
[Bug c++/97966] maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97966 --- Comment #1 from jonathan.k at qspark dot co --- Created attachment 49617 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49617&action=edit ii file which can be used to reproduce the bug
[Bug fortran/97927] gfortran: ICE in lookup_field_for_decl, at tree-nested.c:288
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97927 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #9 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #8) > Can't reproduce with 20201005 10 branch or current trunk. Neither I with yesterday's trunk and today's GCC 10 (8c8c5aae6b462d2df38f21f76c01d89d2f79f099) It also does not crash on GCC 10 with ede01bd9adf55f43598036d21d5db3d95dfd24a3 (= Wed Aug 26) nor with c0746a1beb1ba073c7981eb09f55b3d993b32e5c (= Aug 25).
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #9 from Martin Liška --- Ok, so the question is: does it reproduce with the current master or now?
[Bug ipa/96734] gcc 10.2.0 fails to compile on mips64 due to crash in IPA SRA pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96734 Martin Liška changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #11 from Martin Liška --- Apparently, it's gone.
[Bug tree-optimization/97967] New: Missed optimization opportunity for VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97967
Bug ID: 97967
Summary: Missed optimization opportunity for VRP
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ishiura-compiler at ml dot kwansei.ac.jp
Target Milestone: ---
We have another VRP related test case for GCC-10.2.0.
We expect A1.c and A2.c should compile to the same codes, but they did
not.
+-+-+
|A1.c | A2.c |
+-+-+
|int main (void) |int main (void) |
|{|{|
| volatile int a = 1;| volatile int a = 1;|
| | |
| int b = a%2; | a; |
| int t = 200<(short)(-50*b);| int t = 0; |
| | |
| if (t != 0) __builtin_abort(); | if (t != 0) __builtin_abort(); |
| | |
| return 0; | return 0; |
|}|}|
+-+-+
+---+--+
| A1.s (gcc-10.2.0 A1.c -O3 -S) | A2.s (gcc-10.2.0 A2.c -O3 -S)|
+---+--+
|main: |main: |
|.LFB0: |.LFB0:|
| .cfi_startproc | .cfi_startproc |
| subq$24, %rsp | movl$1, -4(%rsp) |
| .cfi_def_cfa_offset 32 | movl-4(%rsp), %eax |
| movl$1, 12(%rsp)| |
| movl12(%rsp), %eax | |
| movl%eax, %edx | |
| shrl$31, %edx | |
| addl%edx, %eax | |
| andl$1, %eax| |
| subl%edx, %eax | |
| imull $-50, %eax, %eax| |
| cmpw$200, %ax | |
| jg .L3 | |
| xorl%eax, %eax | xorl%eax, %eax |
| addq$24, %rsp | |
| .cfi_def_cfa_offset 8 | |
| ret | ret|
| .cfi_endproc| .cfi_endproc |
| .section .text.unlikely | |
| .cfi_startproc | |
| .type main.cold, @function| |
|main.cold: | |
|.LFSB0:| |
|.L3: | |
|.cfi_def_cfa_offset 32 | |
|callabort | |
|.cfi_endproc | |
|.LFE0: |.LFE0:|
|.section text.startup | |
|.size main, .-main | .size main, .-main |
|.section .text.unlikely | |
|.size main.cold, .-mai...| |
|.LCOLDE0: | |
|.section .text.startup| |
|.LHOTE0: | |
|.ident "GCC: (GNU) 10.2.0"| .ident "GCC: (GNU) 10.2.0"|
|.section .note.GNU-stac...| .section .note.GNU-stac...|
+--+
$ gcc -v
using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
target: x86_64-pc-linux-gnu
configure woth: ../configure --enable-languages=c,c++ --prefix=/usr/local
--disable-bootstrap --disable-multilib
thred model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #10 from Richard Biener --- There's only two relevant changes, both before the snapshot tested: ec383f0bdb4077b744d493d02afff5f13f33029e and d87ee7f1c9cd2ffa6302cdfd0686d72e5bb7463b
[Bug rtl-optimization/95862] Failure to optimize usage of __builtin_mul_overflow to small __int128-based check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95862 Jakub Jelinek changed: What|Removed |Added Component|tree-optimization |rtl-optimization Last reconfirmed||2020-11-24 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Jakub Jelinek --- I don't really see why it woiuld need to do the 128-bit multiplication at all, it can just do ((int64_t) a * b) < 0 (aka ((uint64_t) a * b) >> 63).
[Bug libstdc++/67791] [8/9/10/11 Regression] Crash using std::thread and iostream with dynamic loading of a shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67791 --- Comment #9 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:4bbd5d0c5fb2b7527938ad44a6d8a2f2ef8bbe12 commit r11-5315-g4bbd5d0c5fb2b7527938ad44a6d8a2f2ef8bbe12 Author: Jonathan Wakely Date: Tue Nov 24 12:48:31 2020 + libstdc++: Throw instead of segfaulting in std::thread constructor [PR 67791] This turns a mysterious segfault into an exception with a more useful message. If the exception isn't caught, the user sees this instead of just a segfault: terminate called after throwing an instance of 'std::system_error' what(): Enable multithreading to use std::thread: Operation not permitted Aborted (core dumped) libstdc++-v3/ChangeLog: PR libstdc++/67791 * src/c++11/thread.cc (thread::_M_start_thread(_State_ptr, void (*)())): Check that gthreads is available before calling __gthread_create.
[Bug tree-optimization/97960] [8/9/10/11 Regression] Wrong code at -O3 since r8-6511-g3ae129323d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97960
--- Comment #3 from Richard Biener ---
Creating dr for b[_7]
base_address: &b
offset from base address: (ssizetype) ((sizetype) (signed char) _5 * 4)
constant offset from base address: -1012
step: 4
base alignment: 32
base misalignment: 0
offset alignment: 4
step alignment: 4
base_object: b
Access function 0: {(int) h_20, +, 1}_2
looks like the wrong sign for the constant offset.
#0 split_constant_offset_1 (type=,
op0=, code=NOP_EXPR, op1=,
var=0x7fffba10, off=0x7fffba08, cache=..., limit=0x7fffc19c)
now, var_min/max is UNSIGNED -3 / -1 (precision 8), woff is 3
we compute -3 + 3 == 0 and overflow to true (UNSIGNED arithmetic)
_5 = (unsigned char) _35;
_6 = _5 + 3;
h_20 = (signed char) _6;
but then we continue with
/* Calculate (ssizetype) OP0 - (ssizetype) TMP_VAR. */
widest_int diff = (widest_int::from (op0_min, sgn)
- widest_int::from (var_min, sgn));
getting -253. I remember this place has changed quite some times and
wide (sign-extended) vs. widest (signed) ints do not make it easier
to see what's correct ...
I'm defering to Richard here. The C testcase trips at this point just
twice (ldist and vectorizer) so it's easy enough to 'catch' in a debugger.
[Bug rtl-optimization/97968] New: Unnecessary mov instruction with comparison and cmov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97968
Bug ID: 97968
Summary: Unnecessary mov instruction with comparison and cmov
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
The same problem applies with all comparison operators but '==' for 'int' and
'long' on x86-64.
(Returning a negative value instead of 0 makes the compiler generate a jump
instead of a cmov. I don't know if it's worth a bug)
---
int f(int n, int j)
{
return n > j ? n : 0;
}
---
with O2 produces
---
f(int, int):
mov eax, edi
cmp edi, esi
mov edx, 0
cmovle eax, edx
ret
---
Ideally it should produce something like that. (the first mov can be deleted
with some little changes later)
---
f(int, int):
mov eax, 0
cmp edi, esi
cmovg eax, edi
ret
---
[Bug rtl-optimization/95862] Failure to optimize usage of __builtin_mul_overflow to small __int128-based check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95862 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 49618 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49618&action=edit gcc11-pr95862.patch Untested fix.
[Bug c/97969] New: [ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 Bug ID: 97969 Summary: [ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pmiscml at gmail dot com Target Milestone: --- Created attachment 49619 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49619&action=edit Testcase minimized with CReduce Attached in the creduce-minimized source code (and original preprocessed source) which, when compiled with ARM (32-bit) targeting compiler with certain options, and a code with setjmp(), leads to an apparent infinite loop with ever-growing memory usage. Specific command line to reproduce the issue is: arm-zephyr-eabi-gcc -std=c99 \ -fno-omit-frame-pointer \ -mthumb \ -Os \ -x cpp-output -c js-parser_cpp.c The combo of 3 of "-fno-omit-frame-pointer -mthumb -Os" is what causes the issue. Removing any of them gets rid of it. The issue is not speculative - it happens with JerryScript project (https://github.com/jerryscript-project/jerryscript/) build against Zephyr RTOS (https://github.com/zephyrproject-rtos/zephyr/) for a Cortex-M0 target (original gcc options included -mcpu=cortex-m0plus, but as the issue is reproducible with just -mthumb, I didn't include it above). The nature of the issue is pretty DoS'ish/CVE'ish, indeed, it caused our AWS-based CI to run builds for 12+ hrs (which normally take 10 mins). The issue happens with GCC 10.2, which is the latest at the time of reporting, but also with 9.2.0. Specific GCC build comes from the SDK of the mentioned Zephyr RTOS, which is built using Crosstool-NG, definitely with some patches, but shouldn't be anything serious which might cause such behavior. It's however my intention to try other toolchains, I just decided first to record currently available information in this ticket. $ /home/pfalcon/opt/zephyr-sdk-0.12.0b1/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -v Using built-in specs. COLLECT_GCC=/home/pfalcon/opt/zephyr-sdk-0.12.0b1/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc COLLECT_LTO_WRAPPER=/mnt/hdd/opt/zephyr-sdk-0.12.0b1/arm-zephyr-eabi/bin/../libexec/gcc/arm-zephyr-eabi/10.2.0/lto-wrapper Target: arm-zephyr-eabi Configured with: /workdir/build/build_arm/.build/arm-zephyr-eabi/src/gcc/configure --build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu --target=arm-zephyr-eabi --prefix=/workdir/build/output/arm-zephyr-eabi --with-local-prefix=/workdir/build/output/arm-zephyr-eabi/arm-zephyr-eabi --with-headers=/workdir/build/output/arm-zephyr-eabi/arm-zephyr-eabi/include --with-newlib --enable-threads=no --disable-shared --with-pkgversion='crosstool-NG 1.24.0.192_9551914' --enable-__cxa_atexit --disable-libgomp --disable-libmudflap --disable-libmpx --disable-libssp --disable-libquadmath --disable-libquadmath-support --with-gmp=/workdir/build/build_arm/.build/arm-zephyr-eabi/buildtools --with-mpfr=/workdir/build/build_arm/.build/arm-zephyr-eabi/buildtools --with-mpc=/workdir/build/build_arm/.build/arm-zephyr-eabi/buildtools --with-isl=/workdir/build/build_arm/.build/arm-zephyr-eabi/buildtools --enable-lto --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --disable-nls --enable-multiarch --with-multilib-list=rmprofile --enable-languages=c,c++ --with-gnu-ld --with-gnu-as --enable-initfini-array Thread model: single Supported LTO compression algorithms: zlib gcc version 10.2.0 (crosstool-NG 1.24.0.192_9551914) $ /home/pfalcon/opt/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -v Using built-in specs. COLLECT_GCC=/home/pfalcon/opt/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc COLLECT_LTO_WRAPPER=/mnt/hdd/opt/zephyr-sdk-0.11.4/arm-zephyr-eabi/bin/../libexec/gcc/arm-zephyr-eabi/9.2.0/lto-wrapper Target: arm-zephyr-eabi Configured with: /home/buildslave/src/github.com/zephyrproject-rtos/sdk-ng/build/build_arm/.build/arm-zephyr-eabi/src/gcc/configure --build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu --target=arm-zephyr-eabi --prefix=/home/buildslave/src/github.com/zephyrproject-rtos/sdk-ng/build/output/arm-zephyr-eabi --with-local-prefix=/home/buildslave/src/github.com/zephyrproject-rtos/sdk-ng/build/output/arm-zephyr-eabi/arm-zephyr-eabi --with-headers=/home/buildslave/src/github.com/zephyrproject-rtos/sdk-ng/build/output/arm-zephyr-eabi/arm-zephyr-eabi/include --with-newlib --enable-threads=no --disable-shared --with-pkgversion='crosstool-NG 1.24.0.37-3f461da-dirty' --enable-__cxa_atexit --disable-libgomp --disable-libmudflap --disable-libmpx --disable-libssp --disable-libquadmath --disable-libquadmath-support --with-gmp=/home/buildslave/src/github.com/zephyrproject-rtos/sdk-ng/build/build_arm/.build/arm-zephyr-eabi/buildtools --with-mpfr=/home/buildslave/src/githu
[Bug c/97969] [ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 --- Comment #1 from Paul Sokolovsky --- Created attachment 49620 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49620&action=edit Preprocessed original source which caused the issue (js-parser.c from JerryScript project)
[Bug tree-optimization/97960] [8/9/10/11 Regression] Wrong code at -O3 since r8-6511-g3ae129323d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97960 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #4 from rsandifo at gcc dot gnu.org --- Mine. Might not be able to get to it for a few days though.
[Bug c/97969] [ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 --- Comment #2 from Paul Sokolovsky --- To confirm, GCC 9.3.1 from "gcc-arm-none-eabi-9-2020-q2-update" (as distributed by Arm from https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm) also has this issue.
[Bug c/97969] [9/10/11 Regression][ARM/Thumb] Certain combo of codegen options leads to compilation infinite loop with growing memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target||arm Status|UNCONFIRMED |NEW Known to fail||10.2.1, 11.0, 9.3.1 CC||ktkachov at gcc dot gnu.org Known to work||8.4.1 Last reconfirmed||2020-11-24 Summary|[ARM/Thumb] Certain combo |[9/10/11 |of codegen options leads to |Regression][ARM/Thumb] |compilation infinite loop |Certain combo of codegen |with growing memory use |options leads to ||compilation infinite loop ||with growing memory use Keywords||memory-hog Ever confirmed|0 |1 --- Comment #3 from ktkachov at gcc dot gnu.org --- Confirmed on the 9, 10, 11 branches. On GCC 8 it completes successfully. Doesn't reproduce on aarch64, looks like it needs all of -mthumb -fno-omit-frame-pointer -Os.
[Bug tree-optimization/97970] New: [11 regression] 'gcc.dg/gomp/pr82374.c scan-tree-dump-times vect "vectorized 1 loops" 2' for 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97970
Bug ID: 97970
Summary: [11 regression] 'gcc.dg/gomp/pr82374.c
scan-tree-dump-times vect "vectorized 1 loops" 2' for
32-bit x86
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, uweigand at gcc dot gnu.org
Target Milestone: ---
Target: 32-bit x86
Seen for 32-bit x86 (x86_64-pc-linux-gnu with 'm32'):
PASS: gcc.dg/gomp/pr82374.c (test for excess errors)
[-PASS:-]{+FAIL:+} gcc.dg/gomp/pr82374.c scan-tree-dump-times vect
"vectorized 1 loops" 2
[...]/gcc.dg/gomp/pr82374.c:18:9: note: vectorized [-1-] {+0+} loops in
function.
[...]/gcc.dg/gomp/pr82374.c:24:1: note: vectorized [-1-] {+0+} loops in
function.
Per my testing, this appears with recent commit
r11-5310-gc4fa3728ab4f78984a549894e0e8c4d6a253e540 "Fix -ffast-math flags
handling inconsistencies".
(I don't know whether that's a latent issue, or whether the testcase has any
issues.)
[Bug target/97534] [10/11 Regression] ICE in decompose, at rtl.h:2280 (arm-linux-gnueabihf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97534 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:f30a9a8d9e06ae2bf38e0d25e3ca6095212c78e9 commit r11-5319-gf30a9a8d9e06ae2bf38e0d25e3ca6095212c78e9 Author: Richard Earnshaw Date: Tue Nov 24 16:21:17 2020 + arm: correctly handle negating INT_MIN in arm_split_atomic_op [PR97534] arm_split_atomic_op handles subtracting a constant by converting it into addition of the negated constant. But if the type of the operand is int and the constant is -1 we currently end up generating invalid RTL which can lead to an abort later on. The problem is that in a HOST_WIDE_INT, INT_MIN is represented as 0x8000 and the negation of this is 0x8000, but that's not a valid constant for use in SImode operations. The fix is straight-forward which is to use gen_int_mode rather than simply GEN_INT. This knows how to correctly sign-extend the negated constant when this is needed. gcc/ PR target/97534 * config/arm/arm.c (arm_split_atomic_op): Use gen_int_mode when negating a const_int. gcc/testsuite * gcc.dg/pr97534.c: New test.
[Bug bootstrap/97933] [11 Regression] Bootstrap failure on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97933 --- Comment #4 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:bc8f0f1f88d95a284aa329fbc7e70e0b529eaa2a commit r11-5320-gbc8f0f1f88d95a284aa329fbc7e70e0b529eaa2a Author: Vladimir N. Makarov Date: Tue Nov 24 11:25:16 2020 -0500 [PR97933] LRA: find correctly last empty dest block. gcc/ 2020-11-24 Vladimir Makarov PR bootstrap/97933 * lra.c (lra_process_new_insns): Stop on the first real insn after head of e->dest.
[Bug target/97534] [10/11 Regression] ICE in decompose, at rtl.h:2280 (arm-linux-gnueabihf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97534 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:dd2c4e4e97331b1b3d9081191d14f8967d73e31c commit r10-9068-gdd2c4e4e97331b1b3d9081191d14f8967d73e31c Author: Richard Earnshaw Date: Tue Nov 24 16:21:17 2020 + arm: correctly handle negating INT_MIN in arm_split_atomic_op [PR97534] arm_split_atomic_op handles subtracting a constant by converting it into addition of the negated constant. But if the type of the operand is int and the constant is -1 we currently end up generating invalid RTL which can lead to an abort later on. The problem is that in a HOST_WIDE_INT, INT_MIN is represented as 0x8000 and the negation of this is 0x8000, but that's not a valid constant for use in SImode operations. The fix is straight-forward which is to use gen_int_mode rather than simply GEN_INT. This knows how to correctly sign-extend the negated constant when this is needed. gcc/ PR target/97534 * config/arm/arm.c (arm_split_atomic_op): Use gen_int_mode when negating a const_int. gcc/testsuite * gcc.dg/pr97534.c: New test.
[Bug target/97534] [10/11 Regression] ICE in decompose, at rtl.h:2280 (arm-linux-gnueabihf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97534 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Richard Earnshaw --- Fixed on gcc-10 and master.
[Bug target/96906] Failure to optimize __builtin_ia32_psubusw128 compared to 0 to __builtin_ia32_pminuw128 compared to operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96906 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 49621 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49621&action=edit gcc11-pr96906.patch Looking over Agner Fog's table, pminus[bw] and psubus[bw] seems to have the same timing. This untested patch does the optimization in the combiner for SSE2/SSE4.1/AVX2, but handling AVX512BW and AVX512BW+AVX512VL will need further define_insn_and_split patterns I don't have cycles for right now (match the unspec comparisons in there).
[Bug c++/96199] [10/11 Regression] internal compiler error: in tsubst_copy with CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96199 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:e89ebd3e896f27d4afc400044d5a2b69cb524bcb commit r10-9069-ge89ebd3e896f27d4afc400044d5a2b69cb524bcb Author: Jason Merrill Date: Thu Oct 8 15:43:26 2020 -0400 c++: Fix member alias template in C++17 and up. [PR96805] Here we're trying to push into a::c in order to instantiate t, but were building a TYPENAME_TYPE for it because a isn't open yet. Don't do that when we know we're trying to enter the scope. gcc/cp/ChangeLog: PR c++/96805 PR c++/96199 * pt.c (tsubst_aggr_type): Don't build a TYPENAME_TYPE when entering_scope. (tsubst_template_decl): Use tsubst_aggr_type. gcc/testsuite/ChangeLog: PR c++/96805 * g++.dg/cpp0x/alias-decl-pr96805.C: New test.
[Bug c++/96805] [10 Regression] ICE: Segmentation fault in instantiate_template / pop_nested_class()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96805 --- Comment #13 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:e89ebd3e896f27d4afc400044d5a2b69cb524bcb commit r10-9069-ge89ebd3e896f27d4afc400044d5a2b69cb524bcb Author: Jason Merrill Date: Thu Oct 8 15:43:26 2020 -0400 c++: Fix member alias template in C++17 and up. [PR96805] Here we're trying to push into a::c in order to instantiate t, but were building a TYPENAME_TYPE for it because a isn't open yet. Don't do that when we know we're trying to enter the scope. gcc/cp/ChangeLog: PR c++/96805 PR c++/96199 * pt.c (tsubst_aggr_type): Don't build a TYPENAME_TYPE when entering_scope. (tsubst_template_decl): Use tsubst_aggr_type. gcc/testsuite/ChangeLog: PR c++/96805 * g++.dg/cpp0x/alias-decl-pr96805.C: New test.
[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060 --- Comment #17 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:3c45da4414884a5424484f5db1ab951d9de6 commit r10-9070-g3c45da4414884a5424484f5db1ab951d9de6 Author: Jason Merrill Date: Tue Nov 10 18:02:04 2020 -0500 dwarf2: Set DW_AT_declaration for undefined fns [PR97060] If DECL_INITIAL isn't set, we can't emit anything about the body of the function, so add the declaration attribute. gcc/ChangeLog: PR debug/97060 * dwarf2out.c (gen_subprogram_die): It's a declaration if DECL_INITIAL isn't set. gcc/testsuite/ChangeLog: PR debug/97060 * gcc.dg/debug/dwarf2/pr97060.c: New test.
[Bug c++/97918] [8/9/10/11 Regression] ICE near htab_hash_string when LTO, -O & -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97918 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8157b74114f2ba8a6495244f3e171a818a86436a commit r10-9071-g8157b74114f2ba8a6495244f3e171a818a86436a Author: Jason Merrill Date: Fri Nov 20 15:20:45 2020 -0500 dwarf2: ICE with local class in unused function [PR97918] Here, since we only mention bar, we never emit debug information for it. But we do emit debug information for H::h, so we need to refer to the debug info for bar::J even though there is no bar. We deal with this sort of thing in dwarf2out with the limbo_die_list; parentless dies like J get attached to the CU at EOF. But here, we were flushing the limbo list, then generating the template argument DIE for H that refers to J, which adds J to the limbo list, too late to be flushed. So let's flush a little later. gcc/ChangeLog: PR c++/97918 * dwarf2out.c (dwarf2out_early_finish): flush_limbo_die_list after gen_scheduled_generic_parms_dies. gcc/testsuite/ChangeLog: PR c++/97918 * g++.dg/debug/localclass2.C: New test.
[Bug c++/95158] [8/9 Regression] Templates + Diamond Inheritance + Final = Pure Virtual Function Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95158 --- Comment #6 from CVS Commits --- The releases/gcc-8 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a2bdff4f24d9065791e6d8820004772b9fe0c4c1 commit r8-10637-ga2bdff4f24d9065791e6d8820004772b9fe0c4c1 Author: Jason Merrill Date: Wed Jun 3 23:50:06 2020 -0400 c++: Fix FE devirt with diamond inheritance [PR95158] This started breaking in GCC 8 because of the fix for PR15272; after that change, we (correctly) remember the lookup from template parsing time that found Base::foo through the non-dependent MiddleB base, and so we overlook the overrider in MiddleA. But given that, the devirtualization condition from the fix for PR59031 is insufficient; we know that d has to be a Derived, and we found Base::foo in Base, but forcing a non-virtual call gets the wrong function. Fixed by removing the PR59031 code, and instead looking up the overrider in BINFO_VIRTUALS. gcc/cp/ChangeLog: PR c++/95158 * class.c (lookup_vfn_in_binfo): New. * call.c (build_over_call): Use it. (build_new_method_call_1): Don't set LOOKUP_NONVIRTUAL. * cp-tree.h (resolves_to_fixed_type_p): Add default argument. (lookup_vfn_in_binfo): Declare. gcc/testsuite/ChangeLog: PR c++/95158 * g++.dg/template/virtual5.C: New test.
[Bug c++/97918] [8/9/10/11 Regression] ICE near htab_hash_string when LTO, -O & -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97918 --- Comment #13 from CVS Commits --- The releases/gcc-8 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ca8325441a6bb06292db9f165607d4e395f46c4b commit r8-10638-gca8325441a6bb06292db9f165607d4e395f46c4b Author: Jason Merrill Date: Fri Nov 20 15:20:45 2020 -0500 dwarf2: ICE with local class in unused function [PR97918] Here, since we only mention bar, we never emit debug information for it. But we do emit debug information for H::h, so we need to refer to the debug info for bar::J even though there is no bar. We deal with this sort of thing in dwarf2out with the limbo_die_list; parentless dies like J get attached to the CU at EOF. But here, we were flushing the limbo list, then generating the template argument DIE for H that refers to J, which adds J to the limbo list, too late to be flushed. So let's flush a little later. gcc/ChangeLog: PR c++/97918 * dwarf2out.c (dwarf2out_early_finish): flush_limbo_die_list after gen_scheduled_generic_parms_dies. gcc/testsuite/ChangeLog: PR c++/97918 * g++.dg/debug/localclass2.C: New test.
[Bug c++/95158] [8/9 Regression] Templates + Diamond Inheritance + Final = Pure Virtual Function Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95158 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:19323ea3e9344eb773f8fe872eadbe4f1ac6461f commit r9-9066-g19323ea3e9344eb773f8fe872eadbe4f1ac6461f Author: Jason Merrill Date: Wed Jun 3 23:50:06 2020 -0400 c++: Fix FE devirt with diamond inheritance [PR95158] This started breaking in GCC 8 because of the fix for PR15272; after that change, we (correctly) remember the lookup from template parsing time that found Base::foo through the non-dependent MiddleB base, and so we overlook the overrider in MiddleA. But given that, the devirtualization condition from the fix for PR59031 is insufficient; we know that d has to be a Derived, and we found Base::foo in Base, but forcing a non-virtual call gets the wrong function. Fixed by removing the PR59031 code, and instead looking up the overrider in BINFO_VIRTUALS. gcc/cp/ChangeLog: PR c++/95158 * class.c (lookup_vfn_in_binfo): New. * call.c (build_over_call): Use it. (build_new_method_call_1): Don't set LOOKUP_NONVIRTUAL. * cp-tree.h (resolves_to_fixed_type_p): Add default argument. (lookup_vfn_in_binfo): Declare. gcc/testsuite/ChangeLog: PR c++/95158 * g++.dg/template/virtual5.C: New test.
[Bug c++/97918] [8/9/10/11 Regression] ICE near htab_hash_string when LTO, -O & -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97918 --- Comment #14 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:196716c10bcd4074c404cc8f13bf8d9b31c76238 commit r9-9067-g196716c10bcd4074c404cc8f13bf8d9b31c76238 Author: Jason Merrill Date: Fri Nov 20 15:20:45 2020 -0500 dwarf2: ICE with local class in unused function [PR97918] Here, since we only mention bar, we never emit debug information for it. But we do emit debug information for H::h, so we need to refer to the debug info for bar::J even though there is no bar. We deal with this sort of thing in dwarf2out with the limbo_die_list; parentless dies like J get attached to the CU at EOF. But here, we were flushing the limbo list, then generating the template argument DIE for H that refers to J, which adds J to the limbo list, too late to be flushed. So let's flush a little later. gcc/ChangeLog: PR c++/97918 * dwarf2out.c (dwarf2out_early_finish): flush_limbo_die_list after gen_scheduled_generic_parms_dies. gcc/testsuite/ChangeLog: PR c++/97918 * g++.dg/debug/localclass2.C: New test.
[Bug c++/95158] [8/9 Regression] Templates + Diamond Inheritance + Final = Pure Virtual Function Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95158 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jason Merrill --- Also fixed for 8.5/9.4.
[Bug tree-optimization/96912] Failure to optimize pblendvb pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96912
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Note, in:
typedef char V __attribute__((vector_size(16)));
typedef long long W __attribute__((vector_size(16)));
W
foo (W x, W y, V m)
{
W t = (m < 0);
return (~t & x) | (t & y);
}
V
bar (V x, V y, V m)
{
V t = (m < 0);
return (~t & x) | (t & y);
}
we actually optimize bar the way we should, seems it is forwprop1 that turns
_1 = m_5(D) < { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
t_6 = VEC_COND_EXPR <_1, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1 }, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }>;
_2 = ~t_6;
_3 = x_7(D) & _2;
_4 = t_6 & y_8(D);
_9 = _3 | _4;
return _9;
into:
_1 = m_5(D) < { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
t_6 = VEC_COND_EXPR <_1, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1 }, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }>;
_2 = VEC_COND_EXPR <_1, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, {
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 }>;
_3 = VEC_COND_EXPR <_1, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
x_7(D)>;
_4 = VEC_COND_EXPR <_1, y_8(D), { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0 }>;
_9 = VEC_COND_EXPR <_1, y_8(D), x_7(D)>;
return _9;
but the similar:
_1 = m_6(D) < { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
_2 = VEC_COND_EXPR <_1, { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1 }, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }>;
t_7 = VIEW_CONVERT_EXPR(_2);
_3 = ~t_7;
_4 = x_8(D) & _3;
_5 = t_7 & y_9(D);
_10 = _4 | _5;
return _10;
in foo isn't optimized similarly. I'll look tomorrow at that, we should handle
it likee bar with the VEC_COND_EXPR being done in the vector type corresponding
to the comparison with VCEs to that and back.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #11 from Chris Clayton --- I've finished the bisect and landed at: [chris:~/scratch/gcc-ICE/gcc]$ git bisect good bd87cc14ebdb6789e067fb1828d5808407c308b3 is the first bad commit commit bd87cc14ebdb6789e067fb1828d5808407c308b3 Author: Richard Biener Date: Wed Nov 11 11:51:59 2020 +0100 tree-optimization/97623 - Avoid PRE hoist insertion iteration The recent previous change in this area limited hoist insertion iteration via a param but the following is IMHO better since we are not really interested in PRE opportunities exposed by hoisting but only the other way around. So this moves hoist insertion after PRE iteration finished and removes hoist insertion iteration alltogether. 2020-11-11 Richard Biener PR tree-optimization/97623 * params.opt (-param=max-pre-hoist-insert-iterations): Remove again. * doc/invoke.texi (max-pre-hoist-insert-iterations): Likewise. * tree-ssa-pre.c (insert): Move hoist insertion after PRE insertion iteration and do not iterate it. * gcc.dg/tree-ssa/ssa-hoist-3.c: Adjust. * gcc.dg/tree-ssa/ssa-hoist-7.c: Likewise. * gcc.dg/tree-ssa/ssa-pre-30.c: Likewise. gcc/doc/invoke.texi | 5 - gcc/params.opt | 4 gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-3.c | 2 +- gcc/testsuite/gcc.dg/tree-ssa/ssa-hoist-7.c | 4 ++-- gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-30.c | 2 +- gcc/tree-ssa-pre.c | 34 +++-- 6 files changed, 26 insertions(+), 25 deletions(-) I've also confirmed the outcome. A build with this commit at HEAD fails with the ICE. A build with the commits parent at HEAD succeeds. I'll attach the bisect log in a few minutes.
[Bug tree-optimization/97953] ICE (segfault) during GIMPLE pass: loopdone compiling libgcc/config/libbid/bid128_fma.c:190:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97953 --- Comment #12 from Chris Clayton --- Created attachment 49622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49622&action=edit git bisect log
[Bug c/97971] New: [9/10/11 Regression] ICE in process_alt_operands, at lra-constraints.c:3110
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97971
Bug ID: 97971
Summary: [9/10/11 Regression] ICE in process_alt_operands, at
lra-constraints.c:3110
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r9 between 20181104 and 2018 :
$ cat z1.c
int f ()
{
register _Complex a asm ("rax");
register int b asm ("rdx");
asm ("abc %0 %1" : "=&r" (a), "=r" (b));
return a;
}
$ gcc-11-20201122 -c z1.c
z1.c: In function 'f':
z1.c:7:1: error: unable to generate reloads for impossible constraints:
7 | }
| ^
(insn 5 2 6 2 (parallel [
(set (reg/v:DC 0 ax [ a ])
(asm_operands:DC ("abc %0 %1") ("=&r") 0 []
[]
[] z1.c:5))
(set (reg/v:SI 1 dx [ b ])
(asm_operands:SI ("abc %0 %1") ("=r") 1 []
[]
[] z1.c:5))
(clobber (reg:CC 17 flags))
]) "z1.c":5:3 -1
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg/v:SI 1 dx [ b ])
(expr_list:REG_UNUSED (reg:DI 1 dx)
(nil)
during RTL pass: reload
z1.c:7:1: internal compiler error: in process_alt_operands, at
lra-constraints.c:3110
0x5f12f5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0x9de587 process_alt_operands
../../gcc/lra-constraints.c:3109
0x9e190b curr_insn_transform
../../gcc/lra-constraints.c:4073
0x9e4646 lra_constraints(bool)
../../gcc/lra-constraints.c:5138
0x9d28e2 lra(_IO_FILE*)
../../gcc/lra.c:2331
0x98dde9 do_reload
../../gcc/ira.c:5802
0x98dde9 execute
../../gcc/ira.c:5988
[Bug c/97972] New: [10/11 Regression] ICE in moving_insn_creates_bookkeeping_block_p, at sel-sched.c:2031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97972 Bug ID: 97972 Summary: [10/11 Regression] ICE in moving_insn_creates_bookkeeping_block_p, at sel-sched.c:2031 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r10 between 20191117 and 20191124. Needs option -O2 and testfile gcc.c-torture/compile/20161124-1.c : $ gcc-11-20201122 -c 20161124-1.c -O2 -fsanitize=undefined -fselective-scheduling2 -fvar-tracking-assignments cc1: warning: var-tracking-assignments changes selective scheduling during RTL pass: sched2 20161124-1.c: In function 'foo': 20161124-1.c:22:1: internal compiler error: Segmentation fault 22 | } | ^ 0xb42eff crash_signal ../../gcc/toplev.c:330 0xb0d5c7 moving_insn_creates_bookkeeping_block_p ../../gcc/sel-sched.c:2031 0xb0d5c7 moveup_expr ../../gcc/sel-sched.c:2199 0xb0d5c7 moveup_expr_cached ../../gcc/sel-sched.c:2544 0xb0fe1e move_op_ascend ../../gcc/sel-sched.c:6149 0xb11a57 code_motion_path_driver ../../gcc/sel-sched.c:6648 0xb11d3e code_motion_process_successors ../../gcc/sel-sched.c:6342 0xb11d3e code_motion_path_driver ../../gcc/sel-sched.c:6608 0xb12193 move_op ../../gcc/sel-sched.c:6702 0xb12193 move_exprs_to_boundary ../../gcc/sel-sched.c:5223 0xb12193 schedule_expr_on_boundary ../../gcc/sel-sched.c:5436 0xb15864 fill_insns ../../gcc/sel-sched.c:5578 0xb17613 schedule_on_fences ../../gcc/sel-sched.c:7353 0xb17613 sel_sched_region_2 ../../gcc/sel-sched.c:7491 0xb181ad sel_sched_region_1 ../../gcc/sel-sched.c:7533 0xb18c7b sel_sched_region(int) ../../gcc/sel-sched.c:7634 0xb196b9 run_selective_scheduling() ../../gcc/sel-sched.c:7720 0xafaf75 rest_of_handle_sched2 ../../gcc/sched-rgn.c:3738 0xafaf75 execute ../../gcc/sched-rgn.c:3882
[Bug jit/97867] [11 Regression] thunk_info::release breaks function calls in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97867 David Malcolm changed: What|Removed |Added Summary|FAIL: |[11 Regression] |test-combination.c.exe |thunk_info::release breaks |test-functions.c.exe|function calls in libgccjit |test-pr66779.c.exe | |test-threads.c.exe killed | Assignee|dmalcolm at gcc dot gnu.org|hubicka at gcc dot gnu.org Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-24 Ever confirmed|0 |1 --- Comment #3 from David Malcolm --- Thanks Martin. Looks like this is Honza's thunk_info cleanup stuff that I reported on the list. Reassigning, and setting to P1 as this will likely break all non-trivial usage of libgccjit.
[Bug target/93082] macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 Fabian Groffen changed: What|Removed |Added CC||grobian at gentoo dot org --- Comment #3 from Fabian Groffen --- The problem with this snippet is that it doesn't work on Frameworks, does it? At least for me, it seems it searches from usr/include only?
[Bug c++/97973] New: [10/11 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:19577
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97973
Bug ID: 97973
Summary: [10/11 Regression] ICE in tsubst_copy_and_build, at
cp/pt.c:19577
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r10 between 20200119 and 20200126 :
$ cat z1.cc
void a (const int& b);
template int d { a[1](1.); }
$ g++-11-20201122 -c z1.cc
z1.cc:2:35: internal compiler error: in tsubst_copy_and_build, at cp/pt.c:19577
2 | template int d { a[1](1.); }
| ^
0x768e61 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19577
0x7688d2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19477
0x6817cc fold_non_dependent_expr_template
../../gcc/cp/constexpr.c:7177
0x6df205 fold_for_warn(tree_node*)
../../gcc/cp/expr.c:409
0x800ebc check_function_restrict
../../gcc/c-family/c-common.c:5468
0x800ebc check_function_arguments(unsigned int, tree_node const*, tree_node
const*, int, tree_node**, vec*)
../../gcc/c-family/c-common.c:5840
0x7c9607 cp_build_function_call_vec(tree_node*, vec**, int, tree_node*)
../../gcc/cp/typeck.c:4024
0x79689f finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.c:2728
0x73f005 cp_parser_postfix_expression
../../gcc/cp/parser.c:7556
0x7471b5 cp_parser_unary_expression
../../gcc/cp/parser.c:8659
0x7211ff cp_parser_cast_expression
../../gcc/cp/parser.c:9562
0x721a32 cp_parser_binary_expression
../../gcc/cp/parser.c:9664
0x7231c0 cp_parser_assignment_expression
../../gcc/cp/parser.c:9968
0x7221ad cp_parser_constant_expression
../../gcc/cp/parser.c:10264
0x722711 cp_parser_initializer_clause
../../gcc/cp/parser.c:23723
0x7228b4 cp_parser_initializer_list
../../gcc/cp/parser.c:24002
0x7228b4 cp_parser_braced_list
../../gcc/cp/parser.c:23764
0x726082 cp_parser_initializer
../../gcc/cp/parser.c:23681
0x74e50e cp_parser_init_declarator
../../gcc/cp/parser.c:21323
0x751014 cp_parser_single_declaration
../../gcc/cp/parser.c:29997
[Bug c++/97974] New: [9/10/11 Regression] ICE tree check: expected overload, have function_decl in get_class_binding_direct, at cp/name-lookup.c:1332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97974
Bug ID: 97974
Summary: [9/10/11 Regression] ICE tree check: expected
overload, have function_decl in
get_class_binding_direct, at cp/name-lookup.c:1332
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with r8 before 20180525 :
$ cat z1.cc
struct {
struct {
operator int ();
int a;
};
operator int;
};
$ g++-11-20201122 -c z1.cc
z1.cc:6:12: internal compiler error: tree check: expected overload, have
function_decl in get_class_binding_direct, at cp/name-lookup.c:1332
6 | operator int
|^~~
0x6520ba tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9810
0x7fad5a tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3317
0x7fad5a get_class_binding_direct(tree_node*, tree_node*, bool)
../../gcc/cp/name-lookup.c:1332
0x8ea66b lookup_field_r
../../gcc/cp/search.c:978
0x8e904e dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
../../gcc/cp/search.c:1408
0x8e91fc lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
../../gcc/cp/search.c:1121
0x8e95a0 lookup_fnfields(tree_node*, tree_node*, int, int)
../../gcc/cp/search.c:1327
0x80aada lookup_name_1
../../gcc/cp/name-lookup.c:6587
0x80aada lookup_name(tree_node*, LOOK_where, LOOK_want)
../../gcc/cp/name-lookup.c:6665
0x811255 lookup_name(tree_node*, LOOK_want)
../../gcc/cp/name-lookup.h:294
0x811255 cp_parser_lookup_name
../../gcc/cp/parser.c:28864
0x818615 cp_parser_diagnose_invalid_type_name
../../gcc/cp/parser.c:3365
0x84a063 cp_parser_parse_and_diagnose_invalid_type_name
../../gcc/cp/parser.c:3619
0x860367 cp_parser_member_declaration
../../gcc/cp/parser.c:25456
0x82f722 cp_parser_member_specification_opt
../../gcc/cp/parser.c:25306
0x82f722 cp_parser_class_specifier_1
../../gcc/cp/parser.c:24395
0x832159 cp_parser_class_specifier
../../gcc/cp/parser.c:24706
0x832159 cp_parser_type_specifier
../../gcc/cp/parser.c:17962
0x832d86 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14584
0x8339f1 cp_parser_simple_declaration
../../gcc/cp/parser.c:13841
[Bug tree-optimization/97970] [11 regression] 'gcc.dg/gomp/pr82374.c scan-tree-dump-times vect "vectorized 1 loops" 2' for 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97970 --- Comment #1 from CVS Commits --- The master branch has been updated by Ulrich Weigand : https://gcc.gnu.org/g:ce2d9549f2b2bcb70a1a6f8f4e776e1ed427546b commit r11-5322-gce2d9549f2b2bcb70a1a6f8f4e776e1ed427546b Author: Ulrich Weigand Date: Tue Nov 24 19:30:01 2020 +0100 Revert: "Fix -ffast-math flags handling inconsistencies" This reverts commit c4fa3728ab4f78984a549894e0e8c4d6a253e540, which caused a regression in the default for flag_excess_precision. 2020-11-24 Ulrich Weigand gcc/ PR tree-optimization/97970 * doc/invoke.texi (-ffast-math): Revert last change. * opts.c: Revert last change.
[Bug c++/97975] New: ICE unexpected expression '(int)A< >::b' of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97975
Bug ID: 97975
Summary: ICE unexpected expression '(int)A<
>::b' of kind
implicit_conv_expr
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Seems to be an old issue :
$ cat z1.cc
template class A
{
static const float b;
static inline const int c = b;
};
$ g++-11-20201122 -c z1.cc
z1.cc:4:31: internal compiler error: unexpected expression '(int)A<
>::b' of kind implicit_conv_expr
4 | static inline const int c = b;
| ^
0x6f5185 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6647
0x6f6b37 cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:6856
0x6fbf8f maybe_constant_init_1
../../gcc/cp/constexpr.c:7307
0x96811c store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/cp/typeck2.c:760
0x74fc6e check_initializer
../../gcc/cp/decl.c:6923
0x77f0ab cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7713
0x793bd3 finish_static_data_member_decl(tree_node*, tree_node*, bool,
tree_node*, int)
../../gcc/cp/decl2.c:814
0x79477e grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../../gcc/cp/decl2.c:1000
0x85f9f4 cp_parser_member_declaration
../../gcc/cp/parser.c:25861
0x82f722 cp_parser_member_specification_opt
../../gcc/cp/parser.c:25306
0x82f722 cp_parser_class_specifier_1
../../gcc/cp/parser.c:24395
0x832159 cp_parser_class_specifier
../../gcc/cp/parser.c:24706
0x832159 cp_parser_type_specifier
../../gcc/cp/parser.c:17962
0x832d86 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14584
0x85e0f5 cp_parser_single_declaration
../../gcc/cp/parser.c:29906
0x85e4b5 cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.c:29570
0x85f07f cp_parser_explicit_template_declaration
../../gcc/cp/parser.c:29835
0x85f07f cp_parser_template_declaration_after_export
../../gcc/cp/parser.c:29854
0x8613a9 cp_parser_declaration
../../gcc/cp/parser.c:13608
0x861cf8 cp_parser_translation_unit
../../gcc/cp/parser.c:4806
[Bug tree-optimization/97970] [11 regression] 'gcc.dg/gomp/pr82374.c scan-tree-dump-times vect "vectorized 1 loops" 2' for 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97970 --- Comment #2 from Ulrich Weigand --- The patch did not handle flag_excess_precision correctly. I've reverted for now and will look into a proper fix. Sorry for the breakage.
[Bug jit/97867] [11 Regression] thunk_info::release breaks function calls in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97867
--- Comment #4 from Jan Hubicka ---
Sorry, I lost track of this, because i still hit the strange linker error with
building libjit
The following ghsould fix it.
diff --git a/gcc/symtab-thunks.h b/gcc/symtab-thunks.h
index 41a684995b3..0dba2217793 100644
--- a/gcc/symtab-thunks.h
+++ b/gcc/symtab-thunks.h
@@ -167,7 +167,7 @@ inline void
thunk_info::release ()
{
if (symtab->m_thunks)
-delete (symtab->m_thunks);
+ggc_delete (symtab->m_thunks);
symtab->m_thunks = NULL;
}
#endif /* GCC_SYMTAB_THUNKS_H */
[Bug c/97955] [11 Regression] ICE in build_array_type_1, at tree.c:8264 since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97955 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug c/97971] [9/10/11 Regression] ICE in process_alt_operands, at lra-constraints.c:3110
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97971
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
_Complex with ("rax") occupies the rax/rdx registers, so the testcase is
invalid.
As it is during processing inline asm, I think it should use the standard
reload diagnostics about impossible to reload asm.
[Bug c++/97899] [11 Regression] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:92a30040c8d3ea4899979ec41a7e8e6a625c438d
commit r11-5323-g92a30040c8d3ea4899979ec41a7e8e6a625c438d
Author: Jason Merrill
Date: Fri Nov 20 16:50:20 2020 -0500
c++: ICE with int{} in template. [PR97899]
split_nonconstant_init_1 was confused by a CONSTRUCTOR with non-aggregate
type, which (with COMPOUND_LITERAL_P set) we use in a template to represent
a braced functional cast. It seems to me that there's no good reason to do
split_nonconstant_init at all in a template.
gcc/cp/ChangeLog:
PR c++/97899
* typeck2.c (store_init_value): Don't split_nonconstant_init in a
template.
gcc/testsuite/ChangeLog:
PR c++/97899
* g++.dg/cpp0x/initlist-template3.C: New test.
[Bug c++/97899] [11 Regression] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Jason Merrill --- Fixed.
[Bug target/97827] bootstrap error building the amdgcn-amdhsa offload compiler with LLVM 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827 --- Comment #7 from Tobias Burnus --- Submitted LLVM patch at https://reviews.llvm.org/D92052 If it gets accepted for LLVM + backported to 11, we are done. Otherwise, we have to proceed as suggested in the email thread.
[Bug tree-optimization/97956] [11 Regression] ICE in build2, at tree.c:4872 since r11-2709-g866626efd749ed3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97956 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug c++/96805] [10 Regression] ICE: Segmentation fault in instantiate_template / pop_nested_class()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96805 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Jason Merrill --- Fixed.
[Bug c++/97965] constexpr evaluation vs. NaNs inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97965 --- Comment #1 from joseph at codesourcery dot com --- I don't think there should be any difference between quiet and signaling NaNs here, since < <= > >= comparisons with either kind of NaN raise "invalid"; it's == != (and the __builtin_is* comparisons) that only raise exceptions for signaling NaN but not quiet.
[Bug c++/97976] New: Optimization regression in 10.1 for lambda passed as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97976
Bug ID: 97976
Summary: Optimization regression in 10.1 for lambda passed as
template argument
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at int19h dot net
Target Milestone: ---
The following C++11 and above code:
extern const int* data;
template bool func(T callback)
{
for (const int* pi = data; pi; ++pi)
{
if (callback(*pi))
{
return false;
}
}
return true;
}
bool f0(int i)
{
return func([i](const int j){ return i == j; });
}
With GCC 10.1 with "-std=c++11 -O2" flags generates the following:
f0(int):
cmp QWORD PTR data[rip], 0
seteal
ret
While GCC 9.3 with the same command line flags generates the following:
f0(int):
mov rax, QWORD PTR data[rip]
testrax, rax
jne .L3
jmp .L4
.L7:
add rax, 4
.L3:
cmp edi, DWORD PTR [rax]
jne .L7
xor eax, eax
ret
.L4:
mov eax, 1
ret
It looks like this regression started with GCC 10 and starts at -02
optimization level for C++11 and above. I have tested this with clang and msvc,
and they generate code similar to what is generated by gcc 9.3.
This behavior can also be seen in the Compiler Explorer here:
https://godbolt.org/z/r4zMnc
Thank you!
--peter
[Bug c++/97976] Optimization regression in 10.1 for lambda passed as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97976 --- Comment #1 from Andrew Pinski --- I don't think there is a bug here. This loop here: for (const int* pi = data; pi; ++pi) invokes undefined behavior as pi can never become null after doing the increment.
[Bug c++/97976] Optimization regression in 10.1 for lambda passed as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97976 Peter Bisroev changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Peter Bisroev --- Hi Andrew, You are 100% correct. I realized that as soon as I hit submit button. I was trying to create a simple test case of the problem that I saw and a bit oversimplified it. GCC actually optimized this really well. I apologize for a false report. Regards, --peter
[Bug c/97955] [11 Regression] ICE in build_array_type_1, at tree.c:8264 since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97955 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:211d68dda14d6b773ad648909ef9dd0d65ec2053 commit r11-5325-g211d68dda14d6b773ad648909ef9dd0d65ec2053 Author: Martin Sebor Date: Tue Nov 24 15:23:57 2020 -0700 PR c/97955 - ICE in build_array_type_1 on invalid redeclaration of function with VLA parameter gcc/c-family/ChangeLog: * c-warn.c (warn_parm_array_mismatch): Avoid invalid redeclarations. gcc/testsuite/ChangeLog: * gcc.dg/pr97955.c: New test.
[Bug libstdc++/97944] 30_threads/jthread/95989.cc fails randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944 --- Comment #2 from Jonathan Wakely --- I can't reproduce this on aarch64-unknown-linux-gnu (Fedora 32) or powerpc64le-unknown-linux-gnu (Centos 7.8.2003). I've never seen it fail :-( Please provide the glibc and distro details for the systems where this fails for you.
[Bug libstdc++/97944] 30_threads/jthread/95989.cc fails randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944 --- Comment #3 from Christophe Lyon --- My testing is with cross-compilers, binutils-2.34, glibc-2.29, host is RHEL7 x86_64. Note that Toon reported a failure on x86_64: https://gcc.gnu.org/pipermail/gcc-testresults/2020-November/630321.html
[Bug libstdc++/97944] 30_threads/jthread/95989.cc fails randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #4 from seurer at gcc dot gnu.org --- I see this natively on powerpcle for both power 8 and 9. It started I think with or near r11-5215. There are some other ones that fail intermittently, too. FAIL: 30_threads/latch/3.cc execution test FAIL: 30_threads/semaphore/try_acquire_until.cc execution test FAIL: 29_atomics/atomic_integral/wait_notify.cc execution test Possibly more.
[Bug middle-end/97931] missing -Wuninitialized initializing an aggregate member with itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97931 --- Comment #3 from Martin Sebor --- -Winit-self isn't enabled by -Wall in C (to accommodate the 'int i = i;' hack) so unless that changes I'd rather see it in -Wuninitialized (which is in -Wall in all C languages).
[Bug libstdc++/97944] 30_threads/jthread/95989.cc fails randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944 --- Comment #5 from Jonathan Wakely --- (In reply to seurer from comment #4) > I see this natively on powerpcle for both power 8 and 9. It started I think > with or near r11-5215. > > There are some other ones that fail intermittently, too. > FAIL: 30_threads/latch/3.cc execution test > FAIL: 30_threads/semaphore/try_acquire_until.cc execution test > FAIL: 29_atomics/atomic_integral/wait_notify.cc execution test > > Possibly more. That's PR 97936 which I assumed was unrelated. But maybe this bug is actually caused by that change too. The addition of and std::binary_semaphore does affect the code tested by 30_threads/jthread/95989.cc It would help if I could reproduce this on *any* of my test machines though.
[Bug libstdc++/97944] 30_threads/jthread/95989.cc fails randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944 --- Comment #6 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a3313a2214a6253672ab4fa37a2dcf57fd0f8dce commit r11-5326-ga3313a2214a6253672ab4fa37a2dcf57fd0f8dce Author: Jonathan Wakely Date: Tue Nov 24 23:22:01 2020 + libstdc++: Disable failing tests [PR 97936] These tests are unstable and causing failures due to timeouts. Disable them until the cause can be found, so that testing doesn't have to wait for them to timeout. libstdc++-v3/ChangeLog: PR libstdc++/97936 PR libstdc++/97944 * testsuite/29_atomics/atomic_integral/wait_notify.cc: Disable. Do not require pthreads, but add -pthread when appropriate. * testsuite/30_threads/jthread/95989.cc: Likewise. * testsuite/30_threads/latch/3.cc: Likewise. * testsuite/30_threads/semaphore/try_acquire_until.cc: Likewise.
[Bug libstdc++/97936] [11 Regression] 30_threads/latch/3.cc hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a3313a2214a6253672ab4fa37a2dcf57fd0f8dce commit r11-5326-ga3313a2214a6253672ab4fa37a2dcf57fd0f8dce Author: Jonathan Wakely Date: Tue Nov 24 23:22:01 2020 + libstdc++: Disable failing tests [PR 97936] These tests are unstable and causing failures due to timeouts. Disable them until the cause can be found, so that testing doesn't have to wait for them to timeout. libstdc++-v3/ChangeLog: PR libstdc++/97936 PR libstdc++/97944 * testsuite/29_atomics/atomic_integral/wait_notify.cc: Disable. Do not require pthreads, but add -pthread when appropriate. * testsuite/30_threads/jthread/95989.cc: Likewise. * testsuite/30_threads/latch/3.cc: Likewise. * testsuite/30_threads/semaphore/try_acquire_until.cc: Likewise.
[Bug tree-optimization/66512] PRE fails to optimize calls to pure functions in C++, ok in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66512
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #4 from Fangrui Song ---
Should this be reopened?
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html 'const' is
not clarified on its interaction with threads
(https://gcc.gnu.org/legacy-ml/gcc/2015-09/msg00365.html)
and
void f()
{
for (;;)
g(p());
}
is still pessimized for C++ (I tend to agree that 'const' should imply
'nothrow'; even if no, the #c2 case should be resolved properly)
[Bug libstdc++/97944] 30_threads/jthread/95989.cc fails randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97944 --- Comment #7 from Jonathan Wakely --- (In reply to Christophe Lyon from comment #1) > This is also affects gcc-10 Ah, but r11-5215 isn't on the gcc-10 branch, so I think this one must be a separate issues from PR 97936.
[Bug tree-optimization/97956] [11 Regression] ICE in build2, at tree.c:4872 since r11-2709-g866626efd749ed3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97956 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/560127.html
[Bug c/97955] [11 Regression] ICE in build_array_type_1, at tree.c:8264 since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97955 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Martin Sebor --- Fixed in r11-5325.
[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791 Peter Bergner changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|acsawdey at gcc dot gnu.org|bergner at gcc dot gnu.org --- Comment #14 from Peter Bergner --- This looks to be an attribute target issue. When we ICE, we have: (gdb) p TARGET_POWER10 $6 = true (gdb) p TARGET_MMA $7 = true (gdb) p TARGET_VSX $8 = false (gdb) p TARGET_POWERPC64 $9 = false (gdb) p TARGET_64BIT $10 = false TARGET_VSX being false here when POWER10/MMA is enabled is a problem. I'll have a look.
[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791 --- Comment #15 from Segher Boessenkool --- Why does that compiler default to -mcpu=power10?
