[Bug tree-optimization/101555] Compile slowdown in tree PRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101555 --- Comment #5 from Richard Biener --- OK, so most of the time is spent in ANTIC compute, specifically PHI translation and there translate_vuse_through_block doing the (rate limited) stmt_may_clobber_ref_p_1 query. It's a bit fishy that we're doing these things "twice", in particular we are supposed to translate ANTIC_IN to the predecessor ANTIC_OUT, thus all VUSEs should be already top-of-block. But then in compute_antic_aux we're doing /* Prune expressions that are clobbered in block and thus become invalid if translated from ANTIC_OUT to ANTIC_IN. */ prune_clobbered_mems (ANTIC_OUT, block); which is supposed to do the "translation" through the block but that does not adjust VUSEs of expressions. That uses value_dies_in_block_x, something with a cache but also following a somewhat different logic with respect to the VUSEs in the expression. The main complication here is that the expression set we start from is taken from the VN tables which may put "pre-translated" VUSEs in rather than starting with the VUSEs as they were.
[Bug target/102226] ICE with -O3 -msve-vector-bits=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102226 Richard Biener changed: What|Removed |Added Target||aarch64 Keywords||needs-reduction --- Comment #1 from Richard Biener --- preprocessed source would be nice to have, using preprocessed source from x86_64-linux doesn't work.
[Bug tree-optimization/102216] [12 Regression] missed optimization causing Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102216 --- Comment #6 from Andrew Pinski --- Created attachment 51420 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51420&action=edit Patch which I am testing.
[Bug target/102226] ICE with -O3 -msve-vector-bits=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102226 --- Comment #2 from Gilles Gouaillardet --- Created attachment 51421 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51421&action=edit preprocessed reproducer Here is the preprocessed reproducer
[Bug target/102211] [12 regression] ICE introduced by r12-3277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211 Andreas Schwab changed: What|Removed |Added Summary|ICE introduced by r12-3277 |[12 regression] ICE ||introduced by r12-3277 Keywords||build --- Comment #3 from Andreas Schwab --- This also breaks bootstrap.
[Bug target/102226] ICE with -O3 -msve-vector-bits=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102226
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
Last reconfirmed||2021-09-07
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #3 from ktkachov at gcc dot gnu.org ---
Reduced testcase
template struct b { using c = a; };
template class> using f = b;
template class g>
using h = typename f::c;
struct i {
template using k = typename j::l;
};
struct m : i {
using l = h;
};
class n {
public:
char operator[](long o) {
m::l s;
return s[o];
}
} p;
n r;
int q() {
long d;
for (long e; e; e++)
if (p[e] == r[e])
d++;
return d;
}
[Bug target/102211] [12 regression] ICE introduced by r12-3277
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102211 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug analyzer/102225] [12 Regression] ICE in get_or_create_int_cst, at analyzer/region-model-manager.cc:227 since r12-3237-geafa9d969237fd8f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102225 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-07 Ever confirmed|0 |1 Summary|[12 Regression] ICE in |[12 Regression] ICE in |get_or_create_int_cst, at |get_or_create_int_cst, at |analyzer/region-model-manag |analyzer/region-model-manag |er.cc:227 |er.cc:227 since ||r12-3237-geafa9d969237fd8f --- Comment #1 from Martin Liška --- Started with r12-3237-geafa9d969237fd8f.
[Bug target/102226] [12 Regression] ICE with -O3 -msve-vector-bits=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102226 ktkachov at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Summary|ICE with -O3|[12 Regression] ICE with |-msve-vector-bits=128 |-O3 -msve-vector-bits=128 Target Milestone|--- |12.0 Known to fail||12.0 Known to work||11.0 --- Comment #4 from ktkachov at gcc dot gnu.org --- Works in GCC 11
[Bug target/102227] New: [12 Regression] Likely wrong code since r12-3376-g13beaf9e8d2d8264c0ad8f6504793fdcf26f3f73
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102227 Bug ID: 102227 Summary: [12 Regression] Likely wrong code since r12-3376-g13beaf9e8d2d8264c0ad8f6504793fdcf26f3f73 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: hjl.tools at gmail dot com Blocks: 26163 Target Milestone: --- Since the revision, 434.zeusmp and other SPEC benchmarks do fail with -march=native -Ofast on AMD znver1 and Intel skylake. I isolated that the affected source file is tranx3.f, where I can see a couple of assembly changes like: Before: vmulsd gridcomr_+44688(,%rax,8), %xmm2, %xmm2 vaddsd %xmm2, %xmm0, %xmm1 vmulsd %xmm2, %xmm0, %xmm0 vxorpd %xmm2, %xmm2, %xmm2 vmaxsd %xmm2, %xmm0, %xmm0 vmovsd %xmm1, %xmm1, %xmm2 vandpd .LC1(%rip), %xmm2, %xmm2 vxorpd %xmm0, %xmm2, %xmm2 vandpd .LC2(%rip), %xmm1, %xmm0 vmovsd .LC3(%rip), %xmm1 vmaxsd %xmm1, %xmm0, %xmm0 vdivsd %xmm0, %xmm2, %xmm0 vmovsd %xmm0, 856(%rsp,%rbx,8) .L102: After: vmulsd gridcomr_+44688(,%rbx,8), %xmm0, %xmm0 vsubsd %xmm2, %xmm1, %xmm2 vmulsd gridcomr_+44688(,%rax,8), %xmm2, %xmm2 vaddsd %xmm2, %xmm0, %xmm1 vandpd .LC1(%rip), %xmm1, %xmm1 vmulsd %xmm2, %xmm0, %xmm0 vxorpd %xmm2, %xmm2, %xmm2 vmaxsd %xmm2, %xmm0, %xmm0 vmovsd .LC3(%rip), %xmm2 vxorpd %xmm0, %xmm1, %xmm0 vandpd .LC2(%rip), %xmm1, %xmm1 vmaxsd %xmm2, %xmm1, %xmm1 vdivsd %xmm1, %xmm0, %xmm0 vmovsd %xmm0, 856(%rsp,%rbx,8) .L102: @H.J. Can you please take a look? It's not easy to reproduce a smaller test-case .. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug target/102227] [12 Regression] Likely wrong code since r12-3376-g13beaf9e8d2d8264c0ad8f6504793fdcf26f3f73
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102227 Martin Liška changed: What|Removed |Added Target Milestone|--- |12.0 Priority|P3 |P1
[Bug target/102227] [12 Regression] Likely wrong code since r12-3376-g13beaf9e8d2d8264c0ad8f6504793fdcf26f3f73
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102227 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102224 --- Comment #1 from Andrew Pinski --- PR 102224 is most likely related.
[Bug tree-optimization/101555] Compile slowdown in tree PRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101555 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f387ff788f63c1974479644edae728047f843ec4 commit r12-3378-gf387ff788f63c1974479644edae728047f843ec4 Author: Richard Biener Date: Tue Sep 7 10:35:42 2021 +0200 tree-optimization/101555 - avoid redundant alias queries in PRE This avoids doing redundant work during PHI translation to invalidate mems when translating their corresponding VUSE through the blocks virtual PHI node. All the invalidation work is already done by prune_clobbered_mems. This speeds up the compile of the testcase from 275s with PRE taking 91% of the compile-time down to 43s with PRE taking 16% of the compile-time. 2021-09-07 Richard Biener PR tree-optimization/101555 * tree-ssa-pre.c (translate_vuse_through_block): Do not perform an alias walk to determine the validity of the mem at the start of the block which is already guaranteed by means of prune_clobbered_mems. (phi_translate_1): Pass edge to translate_vuse_through_block.
[Bug tree-optimization/101555] Compile slowdown in tree PRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101555 --- Comment #7 from Richard Biener --- The committed change improves compile-time to less than 50s, in principle it also applies to the GCC 11 and 10 branches where the related issue was fixed.
[Bug target/102222] ICE on s390 (internal compiler error: in extract_insn, at recog.c:2770)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-09-07
CC||krebbel at gcc dot gnu.org,
||marxin at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Martin Liška ---
Thank you for the report.
I can confirm it happens for the current master:
$ ./xgcc -B. ~/Programming/testcases/pr10.c -O2 -pipe -march=z10 -c
./as: line 114: exec: -m: invalid option
exec: usage: exec [-cl] [-a name] [command [argument ...]] [redirection ...]
/home/marxin/Programming/testcases/pr10.c:2:1: warning: data definition has
no type or storage class
2 | read_inode_val;
| ^~
/home/marxin/Programming/testcases/pr10.c:2:1: warning: type defaults to
‘int’ in declaration of ‘read_inode_val’ [-Wimplicit-int]
/home/marxin/Programming/testcases/pr10.c:5:1: warning: no semicolon at end
of struct or union
5 | } __attribute__((packed)) read_inode() {
| ^
/home/marxin/Programming/testcases/pr10.c: In function ‘read_inode’:
/home/marxin/Programming/testcases/pr10.c:7:1: error: unrecognizable insn:
7 | }
| ^
(insn 9 8 10 2 (set (strict_low_part (reg:SI 66))
(mem/c:SI (plus:SI (reg/f:SI 64)
(const_int 4 [0x4])) [1 read_inode_val+0 S4 A32]))
"/home/marxin/Programming/testcases/pr10.c":6:30 -1
(nil))
during RTL pass: vregs
/home/marxin/Programming/testcases/pr10.c:7:1: internal compiler error: in
extract_insn, at recog.c:2769
0x6998f5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/Programming/gcc2/gcc/rtl-error.c:108
0x699911 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/Programming/gcc2/gcc/rtl-error.c:116
0x698327 extract_insn(rtx_insn*)
/home/marxin/Programming/gcc2/gcc/recog.c:2769
0xaa8bb5 instantiate_virtual_regs_in_insn
/home/marxin/Programming/gcc2/gcc/function.c:1611
0xaa8bb5 instantiate_virtual_regs
/home/marxin/Programming/gcc2/gcc/function.c:1985
0xaa8bb5 execute
/home/marxin/Programming/gcc2/gcc/function.c:2034
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: s390-linux-gnu
Configured with: /home/marxin/Programming/gcc2/configure
--enable-languages=c,c++,fortran,lto --prefix=/home/marxin/bin/gcc2
--disable-bootstrap --disable-multilib --disable-libsanitizer
--target=s390-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20210907 (experimental) (GCC)
[Bug target/102224] [9/10/11/12 regession] wrong code for `x * copysign(1.0, x)` since r9-5298-g33142cf9cf82aa1f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224
Martin Liška changed:
What|Removed |Added
Summary|[9/10/11/12 regession] |[9/10/11/12 regession]
|wrong code for `x * |wrong code for `x *
|copysign(1.0, x)` |copysign(1.0, x)` since
||r9-5298-g33142cf9cf82aa1f
CC||hjl at gcc dot gnu.org,
||marxin at gcc dot gnu.org
--- Comment #9 from Martin Liška ---
(In reply to Gabriel Ravier from comment #5)
> Actually it seems to me like this is a GCC 9 regression, ever since this
> pattern exists: GCC 9, 10 and 11 emit the exact same faulty code.
I can confirm that:
$ cat pr102224.c
float
__attribute__((noipa))
f(float x, float y)
{
return x * __builtin_copysignf(1.0f, x);
}
int main()
{
float a = 1.23f;
volatile float b = f(a, a);
__builtin_printf ("a: %.2f, b: %.2f\n", a, b);
if (b != a)
__builtin_abort ();
return 0;
}
$ gcc pr102224.c -g -O3 && ./a.out
a: 1.23, b: 0.00
Aborted (core dumped)
Started with r9-5298-g33142cf9cf82aa1f.
[Bug target/102226] [12 Regression] ICE with -O3 -msve-vector-bits=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102226 --- Comment #5 from Richard Biener --- Confirmed - the incompatibility is hidden in the mode which isn't printed by the checking message. The PHI result has VNx2DImode while the PHI argument has V2DImode. It looks like this is from reduction-PHI retaining over epilogue vectorization where we seem to mix SVE and NEON style vectorization. The epilogue loop itself uses a converted value but its epilogue on the skip edge fails to do so.
[Bug target/102226] [12 Regression] ICE with -O3 -msve-vector-bits=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102226
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #6 from Richard Biener ---
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 0c8d992624b..c9dcc647d2c 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -7755,11 +7755,11 @@ vect_transform_cycle_phi (loop_vec_info loop_vinfo,
(reduc_info),
&stmts);
}
+ if (!useless_type_conversion_p (vectype_out, TREE_TYPE (def)))
+ def = gimple_convert (&stmts, vectype_out, def);
/* Adjust the input so we pick up the partially reduced value
for the skip edge in vect_create_epilog_for_reduction. */
accumulator->reduc_input = def;
- if (!useless_type_conversion_p (vectype_out, TREE_TYPE (def)))
- def = gimple_convert (&stmts, vectype_out, def);
if (loop_vinfo->main_loop_edge)
{
/* While we'd like to insert on the edge this will split
fixes it.
[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223 --- Comment #24 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:aad72d2ea8378e1a56c00d15daa4bdcac8a5ae39 commit r12-3379-gaad72d2ea8378e1a56c00d15daa4bdcac8a5ae39 Author: Martin Liska Date: Tue Jun 22 10:09:01 2021 +0200 inline: do not einline when no_profile_instrument_function is different PR gcov-profile/80223 gcc/ChangeLog: * ipa-inline.c (can_inline_edge_p): Similarly to sanitizer options, do not inline when no_profile_instrument_function attributes are different in early inliner. It's fine to inline it after PGO instrumentation. gcc/testsuite/ChangeLog: * gcc.dg/no_profile_instrument_function-attr-2.c: New test.
[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #25 from Martin Liška --- Should be implemented now.
[Bug target/102224] [9/10/11/12 regession] wrong code for `x * copysign(1.0, x)` since r9-5298-g33142cf9cf82aa1f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek ---
The problem is actually about not catering to op0 == op1.
In that case what we really want is x & 0x8000 rather than x ^ (x &
0x8000).
Unfortunately after RA the mask needs to be already emitted, I think e.g.
because of PIC etc. we can't easily use a different constant at that point, and
for non-AVX pandn insn the negation is on the "0" constrained operand.
So
--- gcc/config/i386/i386-expand.c.jj2021-09-06 14:47:43.184050185 +0200
+++ gcc/config/i386/i386-expand.c 2021-09-07 11:35:30.798849245 +0200
@@ -2289,12 +2289,20 @@ ix86_split_xorsign (rtx operands[])
mode = GET_MODE (dest);
vmode = GET_MODE (mask);
- op1 = lowpart_subreg (vmode, op1, mode);
- x = gen_rtx_AND (vmode, op1, mask);
- emit_insn (gen_rtx_SET (op1, x));
+ if (rtx_equal_p (op0, op1))
+{
+ op0 = lowpart_subreg (vmode, op0, mode);
+ x = gen_rtx_AND (vmode, op0, gen_rtx_NOT (vmode, mask));
+}
+ else
+{
+ op1 = lowpart_subreg (vmode, op1, mode);
+ x = gen_rtx_AND (vmode, op1, mask);
+ emit_insn (gen_rtx_SET (op1, x));
- op0 = lowpart_subreg (vmode, op0, mode);
- x = gen_rtx_XOR (vmode, op1, op0);
+ op0 = lowpart_subreg (vmode, op0, mode);
+ x = gen_rtx_XOR (vmode, op1, op0);
+}
dest = lowpart_subreg (vmode, dest, mode);
emit_insn (gen_rtx_SET (dest, x));
doesn't work without -mavx.
[Bug c++/102228] New: lookup_anon_field is quadratic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102228 Bug ID: 102228 Summary: lookup_anon_field is quadratic Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- When lookup_anon_field is called from build_class_member_access_expr with the intent to build OBJECT.MEMBER in a way including the anon aggregates COMPONENT_REFs then when there is a chain of anon aggregates to cover the path is built bottom-up, repeating the expensive recursive walk of lookup_anon_filed depth-of-anon-aggr times. So instead of building OBJECT...MEMBER by recursing to build_class_member_access_expr first with OBJECT and as MEMBER lookup_anon_field should return the full path it found. The PR101555 testcase with -fsyntax-only spends 66% in lookup_anon_field: Samples: 8K of event 'cycles', Event count (approx.): 9385924074 Overhead Samples Command Shared Object Symbol 66.28% 5415 cc1plus cc1plus [.] lookup_anon_field 10.04% 824 cc1plus cc1plus [.] get_class_binding_direct 5.01% 411 cc1plus cc1plus [.] fields_linear_search with -Os it's still the biggest hitter at nearly 15% compile time.
[Bug c++/102228] lookup_anon_field is quadratic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102228 Richard Biener changed: What|Removed |Added CC||jason at gcc dot gnu.org Keywords||compile-time-hog --- Comment #1 from Richard Biener --- The only other caller of lookup_anon_field is cplus_expand_constant for the PTRMEM_CST case which looks like it wouldn't handle nested anon aggregates at all (maybe anon aggregates can only be at zero offset?). If it weren't for this use some brute-force refactoring should be possible without knowing as to what extent all the bells and whistles from build_class_member_access_expr are necessary for the anon aggregate COMPONENT_REFs.
[Bug c++/102228] lookup_anon_field is quadratic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102228
--- Comment #2 from Richard Biener ---
For the PR101555 testcase if you can trust callgrind we get 4000 times
into build_class_member_access_expr and recurse 3000 times which means
on average we have two nested anon aggregates. But then the
lookup_anon_field calls end up recursing 49000 times on the toplevel
and nearly 3 million times from recursive invocations.
So something is clearly at odds here and maybe the issue in the description
is not the one at hand for the testcase but it should be possible to
write a testcase with a deep nesting of anon aggregates running into the
issue in the description.
The following illustrates it:
struct X {
struct {
struct {
struct {
struct {
struct {
struct {
struct {
int i;
};
};
};
};
};
};
};
};
int foo (struct X *p)
{
return p->i;
}
The testcase in PR101555 has
class Vara___024root {
...
struct {
struct {
... 60 members ...
};
struct {
... 60 members ...
};
... repeat 100 times ...
};
... repeat 100 times ...
};
so two levels deep but at each depth 100 anon aggregates :/ (most of
the actual members are never used)
[Bug c++/102228] lookup_anon_field is quadratic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102228 --- Comment #3 from Richard Biener --- The odd thing is of course that name lookup must already have found MEMBER and thus visited the path to it. It would just need to record that :/
[Bug target/102226] [12 Regression] ICE with -O3 -msve-vector-bits=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102226 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:843068149ec8fcaaaec12751f5b70221a1153857 commit r12-3381-g843068149ec8fcaaaec12751f5b70221a1153857 Author: Richard Biener Date: Tue Sep 7 11:46:00 2021 +0200 tree-optimization/102226 - fix epilogue vector re-use This fixes re-use of the reduction value in epilogue vectorization when a conversion from/to variable lenght vectors is required. 2021-09-07 Richard Biener PR tree-optimization/102226 * tree-vect-loop.c (vect_transform_cycle_phi): Record the converted value for the epilogue PHI use. * g++.dg/vect/pr102226.cc: New testcase.
[Bug target/102226] [12 Regression] ICE with -O3 -msve-vector-bits=128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102226 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed.
[Bug c++/102228] lookup_anon_field is quadratic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102228
--- Comment #4 from Richard Biener ---
I think there must be also a 1:1 correspondence to anon type and its single use
FIELD_DECL thus building a back-chain via DECL_CONTEXT and a new
ANON_AGGR_TYPE_FIELD should be possible.
At least I failed to do sth like
typedef struct { int i; } T;
struct X {
T;
};
struct Y {
T;
};
aka use the same aggregate type anonymously from two contexts.
[Bug target/102224] [9/10/11/12 regession] wrong code for `x * copysign(1.0, x)` since r9-5298-g33142cf9cf82aa1f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #11 from Jakub Jelinek --- Created attachment 51422 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51422&action=edit gcc12-pr102224.patch Untested fix. It is actually a mess. While we can during expansion emit efficient fabs code if the two input operands are equal, we still need to ensure correctness for the case where the operand equality is discovered only after expansion. This patch does that by ensuring through early-clobber and constraints that for pre-AVX dest==op1 is different from op0, because we want to overwrite op1 first with op1 & mask before using op0. For AVX, the constraints ensure that either all of dest, op0 and op1 are different, or any two of them are the same but the third one is different. If op0 and op1 are different, then it is ok without further changes, the i386-expand.c changes are for the op0 == op1 case where we've ensured that dest is different from the inputs - we can emit vpandn but if the mask is in memory, we need to force it into a register and can use dest for that.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- cross toolchain fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #25 from Alexey Brodkin --- > (In reply to Jonathan Wakely from comment #22) > > *** Bug 101060 has been marked as a duplicate of this bug. *** > > We can fix it today XDXD > > PROFIT PROFIT PROFIT!!! Given there's a solution/patch suggested by Yujie Yang is there a chance to get it fixed in upstream sources? For the record I'm also seeing initially reported problem when trying to build canadian cross GCC with Crosstool-NG (well, it's clear build system doesn't matter but just in case).
[Bug target/85819] conversion from __v[48]su to __v[48]sf should use FMA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85819 --- Comment #3 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:ad9fcb961c0705f56907a728c3748c011a0a8048 commit r12-3382-gad9fcb961c0705f56907a728c3748c011a0a8048 Author: H.J. Lu Date: Sat Sep 4 07:48:43 2021 -0700 x86: Enable FMA in unsigned SI to SF expanders Enable FMA in scalar/vector unsigned SI to SF expanders. Don't check TARGET_AVX512F which has vcvtusi2ss and vcvtudq2ps instructions. gcc/ PR target/85819 * config/i386/i386-expand.c (ix86_expand_convert_uns_sisf_sse): Enable FMA. (ix86_expand_vector_convert_uns_vsivsf): Likewise. gcc/testsuite/ PR target/85819 * gcc.target/i386/pr85819-1a.c: New test. * gcc.target/i386/pr85819-1b.c: Likewise. * gcc.target/i386/pr85819-2a.c: Likewise. * gcc.target/i386/pr85819-2b.c: Likewise. * gcc.target/i386/pr85819-2c.c: Likewise. * gcc.target/i386/pr85819-3.c: Likewise.
[Bug c++/102229] New: 'decltype(auto)' cannot be cv-qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102229 Bug ID: 102229 Summary: 'decltype(auto)' cannot be cv-qualified Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: netcan1996 at gmail dot com Target Milestone: --- code: https://godbolt.org/z/h833W9v95 it begins at version 11.x.
[Bug target/85819] conversion from __v[48]su to __v[48]sf should use FMA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85819 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #4 from H.J. Lu --- Fixed for GCC 12.
[Bug debug/101947] [12 Regression] broken LTO bootstrap in get_base_type_offset at dwarf2out.c:4330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101947 --- Comment #10 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:81e9178fe7f8bae4609619b1195765b14eef35b7 commit r12-3383-g81e9178fe7f8bae4609619b1195765b14eef35b7 Author: Eric Botcazou Date: Tue Sep 7 15:41:49 2021 +0200 Fix PR debug/101947 This is the recent LTO bootstrap failure with Ada enabled. The compiler now generates DW_OP_deref_type for a unit of the Ada front-end, which means that the offset of base types in the CU must be computed during early DWARF too. gcc/ PR debug/101947 * dwarf2out.c (mark_base_types): New overloaded function. (dwarf2out_early_finish): Invoke it on the COMDAT type list as well as the compilation unit, and call move_marked_base_types afterward.
[Bug debug/101947] [12 Regression] broken LTO bootstrap in get_base_type_offset at dwarf2out.c:4330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101947 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Eric Botcazou --- This should work again.
[Bug c++/102229] 'decltype(auto)' cannot be cv-qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102229
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #1 from Martin Liška ---
struct Test {
static constexpr decltype(auto) v = "test";
};
int main(int argc, char** argv) {
return 0;
}
[Bug c++/102229] [11/12 Regression] 'decltype(auto)' cannot be cv-qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102229 Richard Biener changed: What|Removed |Added Known to work||10.3.0 Last reconfirmed||2021-09-07 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |11.3 Priority|P3 |P2 Known to fail||11.1.0 Keywords||rejects-valid Summary|'decltype(auto)' cannot be |[11/12 Regression] |cv-qualified|'decltype(auto)' cannot be ||cv-qualified --- Comment #2 from Richard Biener --- Confirmed. clang accepts it as well.
[Bug c++/102229] [11/12 Regression] 'decltype(auto)' cannot be cv-qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102229 Marek Polacek changed: What|Removed |Added Resolution|--- |INVALID CC||mpolacek at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #3 from Marek Polacek --- This is desirable, added in my r11-2202 to fix bug 79815: "If the placeholder is the decltype(auto) type-specifier, T shall be the placeholder alone." but we weren't detecting "const decltype(auto)".
[Bug target/102230] New: ICE in classify_argument, at config/i386/i386.c:2474
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102230
Bug ID: 102230
Summary: ICE in classify_argument, at config/i386/i386.c:2474
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc-12.0.0-alpha20210905 snapshot (g:a827909537cf085e5673ca7816b7bd7151d89fc5)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/arm/armv8_2-fp16-arith-2.c:
typedef _Float16 float16x4_t __attribute__ ((vector_size (8)));
float16x4_t
test_float16x4_t (float16x4_t a)
{
return a;
}
% x86_64-unknown-linux-gnu-gcc-12.0.0 -c nyecizge.c
nyecizge.c: In function 'test_float16x4_t':
nyecizge.c:5:1: internal compiler error: in classify_argument, at
config/i386/i386.c:2474
5 | {
| ^
0x78253f classify_argument
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/config/i386/i386.c:2474
0x120239a examine_argument
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/config/i386/i386.c:2493
0x12058ff ix86_return_in_memory
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/config/i386/i386.c:4186
0xb2d715 aggregate_value_p(tree_node const*, tree_node const*)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/function.c:2119
0xb321ca allocate_struct_function(tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/function.c:4845
0x84f23c store_parm_decls()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/c/c-decl.c:10128
0x8af40f c_parser_declaration_or_fndef
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/c/c-parser.c:2506
0x8b7a53 c_parser_external_declaration
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/c/c-parser.c:1780
0x8b84bb c_parser_translation_unit
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/c/c-parser.c:1653
0x8b84bb c_parse_file()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/c/c-parser.c:22581
0x919b3d c_common_parse_file()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210905/work/gcc-12-20210905/gcc/c-family/c-opts.c:1236
[Bug c++/102229] [11/12 Regression] 'decltype(auto)' cannot be cv-qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102229 Marek Polacek changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|NEW --- Comment #4 from Marek Polacek --- Maybe it's not desirable after all, it may be that type-specifiers are not permitted but decl-specifiers are.
[Bug target/102231] New: includes unconditionally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102231 Bug ID: 102231 Summary: includes unconditionally Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- Instead, it should do something like #if __STDC_HOSTED__ #include #endif as Clang does, because only exists on hosted environments (which is good, because it itself uses , etc.) A few intrinsics that use stuff from need the same treatment.
[Bug tree-optimization/102232] New: Missed arithmetic fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102232
Bug ID: 102232
Summary: Missed arithmetic fold
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: llvm at rifkin dot dev
Target Milestone: ---
LLVM optimizes bar into tgt here but not foo.
https://godbolt.org/z/nhEjaoanx
int foo(int a, int b) {
return b * (1 + a / b) - a;
}
int bar(int a, int b) {
return b * (a / b) + b - a;
}
int tgt(int a, int b) {
return b - a % b;
}
LLVM appears to miss this too.
[Bug tree-optimization/102232] Missed arithmetic fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102232 --- Comment #1 from Jeremy R. --- Correction on first line: *GCC optimizes bar into tgt here but not foo. Pardon my sloppy copy-paste from my bug report over on LLVM's bugzilla!
[Bug target/102231] includes unconditionally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102231 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 65584 *** This bug has been marked as a duplicate of bug 65584 ***
[Bug target/65584] [i386] Intrinsics inclusion with `-nostdinc' failing due to `stdlib.h' dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65584 Andrew Pinski changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- *** Bug 102231 has been marked as a duplicate of this bug. ***
[Bug target/65584] [i386] Intrinsics inclusion with `-nostdinc' failing due to `stdlib.h' dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65584 Segher Boessenkool changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-09-07 Status|UNCONFIRMED |NEW
[Bug c++/102228] lookup_anon_field is quadratic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102228
--- Comment #5 from Richard Biener ---
(In reply to Richard Biener from comment #4)
> I think there must be also a 1:1 correspondence to anon type and its single
> use FIELD_DECL thus building a back-chain via DECL_CONTEXT and a new
> ANON_AGGR_TYPE_FIELD should be possible.
>
> At least I failed to do sth like
>
> typedef struct { int i; } T;
> struct X {
> T;
> };
> struct Y {
> T;
> };
>
> aka use the same aggregate type anonymously from two contexts.
I (fool) proofed this with
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 8b78e89ce3a..16156e428be 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -136,6 +136,7 @@ struct GTY(()) deferred_access {
/* Data for deferred access checking. */
static GTY(()) vec *deferred_access_stack;
static GTY(()) unsigned deferred_access_no_check;
+static GTY(()) hash_map *anon_aggr_field;
/* Save the current deferred access states and start deferred
access checking iff DEFER_P is true. */
@@ -3489,6 +3490,15 @@ finish_member_declaration (tree decl)
if (TREE_CODE (decl) != CONST_DECL)
DECL_CONTEXT (decl) = current_class_type;
+ if (TREE_CODE (decl) == FIELD_DECL
+ && ANON_AGGR_TYPE_P (TREE_TYPE (decl)))
+{
+ if (!anon_aggr_field)
+ anon_aggr_field = hash_map::create_ggc ();
+ if (anon_aggr_field->put (TREE_TYPE (decl), decl))
+ gcc_unreachable ();
+}
+
if (TREE_CODE (decl) == USING_DECL)
/* For now, ignore class-scope USING_DECLS, so that debugging
backends do not see them. */
if you think the 1:1 relationship is sound then I can try finding an
unused field in lang_type to record the FIELD_DECL used for an
ANON_AGGR_TYPE_P. I guess any of the method/inheritance related
members could be re-purposed (typeinfo_var for example, accesses are
in suitably special places that shouldn't show up for ANON_AGGR_TYPE_P)
I did wonder if we'll have different FIELD_DECLs for as-base or other
weird record variants that somehow get automatically generated as
copies from the same type (and where the FIELD_DECL would be at different
offset). But at least test coverage showed up
nothing... and I don't know enough C++ to think of how to provoke it
to break.
So, mine if proceeding with adding a ANON_AGGR_TYPE_FIELD mapping to
lang_type->typeinfo_var and setting it in finish_member_declaration
plus ditching lookup_anon_field is OK.
Jason?
[Bug target/65584] [i386] Intrinsics inclusion with `-nostdinc' failing due to `stdlib.h' dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65584 --- Comment #4 from Segher Boessenkool --- Since you closed PR102231 (which has a lot more detail), let me paste that here: includes unconditionally Instead, it should do something like #if __STDC_HOSTED__ #include #endif as Clang does, because only exists on hosted environments (which is good, because it itself uses , etc.) A few intrinsics that use stuff from need the same treatment. (apparently *is* created by GCC, but in the source tree it is pmm_malloc.h and gmm_malloc.h).
[Bug target/65584] [i386] Intrinsics inclusion with `-nostdinc' failing due to `stdlib.h' dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65584 --- Comment #5 from Jakub Jelinek --- We could avoid the stdlib.h include for pmm_alloc.h through __builtin_malloc/__builtin_free and __SIZE_TYPE__. But yes, maybe not defining _mm_malloc/_mm_free at all for non-__STDC_HOSTED__ is better.
[Bug target/65584] [i386] Intrinsics inclusion with `-nostdinc' failing due to `stdlib.h' dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65584 --- Comment #6 from Jakub Jelinek --- And the "somehow" is now possible too, we can use __has_include().
[Bug fortran/101308] Bind(C): gfortran does not create C descriptors for scalar pointer/allocatable arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101308 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus --- The mentioned testsuite has been committed in r12-3320 (Sep 2, 2021) The bug itself is fixed by https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578904.html (pending review)
[Bug target/65584] [i386] Intrinsics inclusion with `-nostdinc' failing due to `stdlib.h' dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65584 --- Comment #7 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #6) > And the "somehow" is now possible too, we can use __has_include(). Including it with -ffreestanding in effect is always wrong. Even if the header exists it may not be what you expected.
[Bug c++/96103] Unclear diagnostic for a function return with "decltype(auto)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96103 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/95658] Bogus duplicate error message in "decltype(auto)" type specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95658 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Target Milestone|--- |11.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Fixed in GCC 11: :1:1: error: 'decltype(auto)' type specifier only available with '-std=c++14' or '-std=gnu++14' 1 | decltype (auto) var = 0; | ^~~~ Which was implemented by PR 96103 so a dup. *** This bug has been marked as a duplicate of bug 96103 ***
[Bug c++/96103] Unclear diagnostic for a function return with "decltype(auto)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96103 --- Comment #4 from Andrew Pinski --- *** Bug 95658 has been marked as a duplicate of this bug. ***
[Bug c++/95657] Duplicate error messages for decltype(auto) with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95657
--- Comment #2 from Andrew Pinski ---
Looks fixed in GCC 11:
:1:1: error: 'decltype(auto)' type specifier only available with
'-std=c++14' or '-std=gnu++14'
1 | decltype (auto) foo( decltype (auto) a ){ }
| ^~~~
:1:22: error: 'decltype(auto)' type specifier only available with
'-std=c++14' or '-std=gnu++14'
1 | decltype (auto) foo( decltype (auto) a ){ }
| ^~~~
:1:38: error: expected initializer before 'a'
1 | decltype (auto) foo( decltype (auto) a ){ }
| ^
[Bug c++/100495] constexpr virtual destructor incorrectly reports memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100495 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:81f9718139cb1cc164ada411ada8cca9f32b8be8 commit r12-3387-g81f9718139cb1cc164ada411ada8cca9f32b8be8 Author: Jakub Jelinek Date: Tue Sep 7 19:33:28 2021 +0200 c++: Fix up constexpr evaluation of deleting dtors [PR100495] We do not save bodies of constexpr clones and instead evaluate the bodies of the constexpr functions they were cloned from. I believe that is just fine for constructors because complete vs. base ctors differ only in classes that have virtual bases and such constructors aren't constexpr, similarly complete/base destructors. But as the testcase below shows, for deleting destructors it is not fine, deleting dtors while marked as clones in fact are just artificial functions with synthetized body which calls the user destructor and deallocation. So, either we'd need to evaluate the destructor and afterwards synthetize and evaluate the deallocation, or we can just save and use the deleting dtors bodies. The latter seems much easier to me. 2021-09-07 Jakub Jelinek PR c++/100495 * constexpr.c (maybe_save_constexpr_fundef): Save body even for constexpr deleting dtors. (cxx_eval_call_expression): Don't use DECL_CLONED_FUNCTION for deleting dtors. * g++.dg/cpp2a/constexpr-new21.C: New test.
[Bug plugins/86441] instantiate_class_template() unable to re-execute constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86441 --- Comment #3 from Andrew Pinski --- is your plugin called before *free_lang_data pass is happening? Because if it is not, then most if not all of the front-end specific data has been removed from the types which is why you might be getting a crash.
[Bug plugins/86441] instantiate_class_template() unable to re-execute constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86441 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2021-09-07
[Bug c++/100495] constexpr virtual destructor incorrectly reports memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100495 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9f300873f6bf8456ebdbd40d0211aefe57f95cb5 commit r11-8968-g9f300873f6bf8456ebdbd40d0211aefe57f95cb5 Author: Jakub Jelinek Date: Tue Sep 7 19:33:28 2021 +0200 c++: Fix up constexpr evaluation of deleting dtors [PR100495] We do not save bodies of constexpr clones and instead evaluate the bodies of the constexpr functions they were cloned from. I believe that is just fine for constructors because complete vs. base ctors differ only in classes that have virtual bases and such constructors aren't constexpr, similarly complete/base destructors. But as the testcase below shows, for deleting destructors it is not fine, deleting dtors while marked as clones in fact are just artificial functions with synthetized body which calls the user destructor and deallocation. So, either we'd need to evaluate the destructor and afterwards synthetize and evaluate the deallocation, or we can just save and use the deleting dtors bodies. The latter seems much easier to me. 2021-09-07 Jakub Jelinek PR c++/100495 * constexpr.c (maybe_save_constexpr_fundef): Save body even for constexpr deleting dtors. (cxx_eval_call_expression): Don't use DECL_CLONED_FUNCTION for deleting dtors. * g++.dg/cpp2a/constexpr-new21.C: New test. (cherry picked from commit 81f9718139cb1cc164ada411ada8cca9f32b8be8)
[Bug c++/100495] constexpr virtual destructor incorrectly reports memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100495 --- Comment #9 from Jakub Jelinek --- Fixed for 11.3+/12+ so far, probably should be backported for 10.4 too.
[Bug target/97142] __builtin_fmod not optimized on POWER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142 --- Comment #17 from Peter Bergner --- (In reply to CVS Commits from comment #16) > The master branch has been updated by Xiong Hu Luo : So fixed on trunk. The Version about is to 10.2, does that mean we're going to back port this to the release branches, or are we calling it good with trunk?
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #26 from cqwrteur --- (In reply to Alexey Brodkin from comment #25) > > (In reply to Jonathan Wakely from comment #22) > > > *** Bug 101060 has been marked as a duplicate of this bug. *** > > > > We can fix it today XDXD > > > > PROFIT PROFIT PROFIT!!! > > Given there's a solution/patch suggested by Yujie Yang is there a chance to > get it fixed in upstream sources? > > For the record I'm also seeing initially reported problem when trying to > build canadian cross GCC with Crosstool-NG (well, it's clear build system > doesn't matter but just in case). why do you use Crosstool-NG?? It sucks. Just manually compile by yourself. Simple and no bullshit.
[Bug c++/42356] improve list of candidates and error recovery for ambiguous call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42356
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2011-10-22 00:00:00 |2021-9-7
--- Comment #19 from Andrew Pinski ---
This is what clang now prints:
:18:19: error: member 'newNode' found in multiple base classes of
different types
bar*b = f.newNode();
^
:5:13: note: member found by ambiguous name lookup
T* newNode() { return 0; }
^
:5:13: note: member found by ambiguous name lookup
Which is better than GCC's but does not print out what the multiple base
classes are.
[Bug tree-optimization/102232] Missed arithmetic fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102232 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug tree-optimization/102232] Missed arithmetic fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102232 Andrew Pinski changed: What|Removed |Added Keywords||TREE Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-07 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- So on aarch64, the code for all three functions are almost the same: foo(int, int): sdivw2, w0, w1 maddw1, w2, w1, w1 sub w0, w1, w0 ret bar(int, int): sdivw2, w0, w1 maddw1, w2, w1, w1 sub w0, w1, w0 ret tgt(int, int): sdivw2, w0, w1 msubw0, w2, w1, w0 sub w0, w1, w0 ret MSVC can do the transformation.
[Bug tree-optimization/102216] [12 Regression] missed optimization causing Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102216 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Pinski from comment #6) > Created attachment 51420 [details] > Patch which I am testing. Note I am throwing this patch away and started to rewrite parts of tree-ssa-forwprop.c instead.
[Bug fortran/101327] ICE in find_array_element, at fortran/expr.c:1355
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101327 --- Comment #6 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2a1537a19cb2fa85823cfa18ed40baa4b259b4e3 commit r12-3392-g2a1537a19cb2fa85823cfa18ed40baa4b259b4e3 Author: Harald Anlauf Date: Tue Sep 7 20:51:49 2021 +0200 Fortran - improve error recovery determining array element from constructor gcc/fortran/ChangeLog: PR fortran/101327 * expr.c (find_array_element): When bounds cannot be determined as constant, return error instead of aborting. gcc/testsuite/ChangeLog: PR fortran/101327 * gfortran.dg/pr101327.f90: New test.
[Bug target/102227] [12 Regression] Likely wrong code since r12-3369-g652bef70d392f9541b12ef65b461009c8c8fd54a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102227 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Keywords||wrong-code --- Comment #2 from Andrew Pinski --- Looks like it was always broken and is the same issue as reported in PR 102224 just getting exposed even more. *** This bug has been marked as a duplicate of bug 102224 ***
[Bug target/102224] [9/10/11/12 regession] wrong code for `x * copysign(1.0, x)` since r9-5298-g33142cf9cf82aa1f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102224 --- Comment #12 from Andrew Pinski --- *** Bug 102227 has been marked as a duplicate of this bug. ***
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 102227, which changed state. Bug 102227 Summary: [12 Regression] Likely wrong code since r12-3369-g652bef70d392f9541b12ef65b461009c8c8fd54a https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102227 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug analyzer/102233] New: Compiling a smallish binary with -fanalyzer seems to cause very very long compile times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102233 Bug ID: 102233 Summary: Compiling a smallish binary with -fanalyzer seems to cause very very long compile times Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: rjones at redhat dot com Target Milestone: --- This is not so simple to reproduce. It starts with checking out: https://github.com/libguestfs/libguestfs and compiling it. On Fedora, following the instructions here: https://libguestfs.org/guestfs-building.1.html#short-cut-for-fedora-or-red-hat-enterprise-linux-rhel-users # dnf builddep libguestfs # dnf install autoconf automake libtool gettext-devel $ git clone https://github.com/libguestfs/libguestfs $ git submodule update --init $ autoreconf -i $ ./configure CFLAGS=-fPIC $ make The thing which fails to compile is a unit test in lib/: $ make -C lib clean $ make -C lib $ make -C lib unit-tests CFLAGS="-O2 -g -fanalyzer" V=1 For me this takes a very long time linking the unit-tests binary: gcc -DHAVE_CONFIG_H -I. -I.. -I../gnulib/lib -I../gnulib/lib -I../common/utils -I../common/utils -I../common/structs -I../common/structs -I../lib -I../include -I. -Wall -Werror -I/usr/include/tirpc -O2 -g -fanalyzer -MT unit_tests-unit-tests.o -MD -MP -MF .deps/unit_tests-unit-tests.Tpo -c -o unit_tests-unit-tests.o `test -f 'unit-tests.c' || echo './'`unit-tests.c mv -f .deps/unit_tests-unit-tests.Tpo .deps/unit_tests-unit-tests.Po bash ../libtool-kill-dependency_libs.sh ../libtool --tag=CC --mode=link gcc -Wall -Werror -I/usr/include/tirpc -O2 -g -fanalyzer -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o unit-tests unit_tests-unit-tests.o ../common/structs/libstructs.la ../common/utils/libutils.la libguestfs_la-actions-0.lo libguestfs_la-actions-1.lo libguestfs_la-actions-2.lo libguestfs_la-actions-3.lo libguestfs_la-actions-4.lo libguestfs_la-actions-5.lo libguestfs_la-actions-6.lo libguestfs_la-actions-support.lo libguestfs_la-actions-variants.lo libguestfs_la-alloc.lo libguestfs_la-appliance.lo libguestfs_la-appliance-cpu.lo libguestfs_la-appliance-kcmdline.lo libguestfs_la-appliance-uefi.lo libguestfs_la-available.lo libguestfs_la-bindtests.lo libguestfs_la-canonical-name.lo libguestfs_la-command.lo libguestfs_la-conn-socket.lo libguestfs_la-copy-in-out.lo libguestfs_la-create.lo libguestfs_la-drives.lo libguestfs_la-errors.lo libguestfs_la-event-string.lo libguestfs_la-events.lo libguestfs_la-file.lo libguestfs_la-fuse.lo libguestfs_la-guid.lo libguestfs_la-handle.lo libguestfs_la-info.lo libguestfs_la-inspect-apps.lo libguestfs_la-inspect-icon.lo libguestfs_la-inspect-osinfo.lo libguestfs_la-journal.lo libguestfs_la-launch.lo libguestfs_la-launch-direct.lo libguestfs_la-launch-libvirt.lo libguestfs_la-launch-uml.lo libguestfs_la-launch-unix.lo libguestfs_la-libvirt-auth.lo libguestfs_la-libvirt-domain.lo libguestfs_la-lpj.lo libguestfs_la-match.lo libguestfs_la-mountable.lo libguestfs_la-private-data.lo libguestfs_la-proto.lo libguestfs_la-qemu.lo libguestfs_la-rescue.lo libguestfs_la-stringsbuf.lo libguestfs_la-structs-compare.lo libguestfs_la-structs-copy.lo libguestfs_la-structs-free.lo libguestfs_la-tmpdirs.lo libguestfs_la-tsk.lo libguestfs_la-uefi.lo libguestfs_la-umask.lo libguestfs_la-version.lo libguestfs_la-wait.lo libguestfs_la-whole-file.lo libguestfs_la-yara.lo ../common/errnostring/liberrnostring.la ../common/protocol/libprotocol.la ../common/qemuopts/libqemuopts.la ../common/structs/libstructs.la ../common/utils/libutils.la -lpcre2-8 -lvirt -lxml2 -lselinux -ljansson ../gnulib/lib/libgnu.la -ltirpc -lfuse -pthread libtool: link: gcc -Wall -Werror -I/usr/include/tirpc -O2 -g -fanalyzer -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o unit-tests unit_tests-unit-tests.o .libs/libguestfs_la-actions-0.o .libs/libguestfs_la-actions-1.o .libs/libguestfs_la-actions-2.o .libs/libguestfs_la-actions-3.o .libs/libguestfs_la-actions-4.o .libs/libguestfs_la-actions-5.o .libs/libguestfs_la-actions-6.o .libs/libguestfs_la-actions-support.o .libs/libguestfs_la-actions-variants.o .libs/libguestfs_la-alloc.o .libs/libguestfs_la-appliance.o .libs/libguestfs_la-appliance-cpu.o .libs/libguestfs_la-appliance-kcmdline.o .libs/libguestfs_la-appliance-uefi.o .libs/libguestfs_la-available.o .libs/libguestfs_la-bindtests.o .libs/libguestfs_la-canonical-name.o .libs/libguestfs_la-command.o .libs/libguestfs_la-conn-socket.o .libs/libguestfs_la-copy-in-out.o .libs/libguestfs_la-create.o .libs/libguestfs_la-drives.o .libs/libguestfs_la-errors.o .libs/libguestfs_la-event-string.o .libs/libguestfs_la-events.o .libs/libguestfs_la-file.o .libs/libguestfs_la-fuse.o .libs/libguestfs_la-guid.o .libs/libguestfs_la-handle.o .libs/libguest
[Bug analyzer/102233] Compiling a smallish binary with -fanalyzer seems to cause very very long compile times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102233 --- Comment #1 from Richard W.M. Jones --- perf top shows: 36.63% lto1 [.] shortest_paths::shortest_paths which it pretty much stuck permanently at 30-50% CPU. The machine has plenty of free memory and is not swapping. The stack trace is: #0 0x00d0b377 in shortest_paths::shortest_paths (this=, graph=..., given_node=, sense=, this=, graph=..., given_node=, sense=) at ../../gcc/shortest-paths.h:120 #1 0x00d0b8db in ana::epath_finder::explore_feasible_paths (this=this@entry=0x7fffbfd72130, target_enode=target_enode@entry=0x49007ac0, desc=desc@entry=0x18e81d6 "malloc_leak", diag_idx=diag_idx@entry=602) at ../../gcc/analyzer/diagnostic-manager.cc:349 #2 0x00d0bc1c in ana::epath_finder::get_best_epath (this=this@entry=0x7fffbfd72130, enode=0x49007ac0, desc=0x18e81d6 "malloc_leak", diag_idx=diag_idx@entry=602, out_problem=out_problem@entry=0x48f9dea0) at ../../gcc/analyzer/diagnostic-manager.cc:160 #3 0x00d0be22 in ana::saved_diagnostic::calc_best_epath (this=this@entry=0x48f9de40, pf=pf@entry=0x7fffbfd72130) at ../../gcc/analyzer/diagnostic-manager.cc:685 #4 0x00d0c046 in ana::dedupe_winners::add (sd=0x48f9de40, pf=0x7fffbfd72130, logger=, this=0x7fffbfd72170) at ../../gcc/analyzer/diagnostic-manager.cc:979 #5 ana::diagnostic_manager::emit_saved_diagnostics (this=0x7fffbfd724a0, eg=...) at ../../gcc/analyzer/diagnostic-manager.cc:1096 #6 0x00a9ea51 in ana::impl_run_checkers (logger=) at ../../gcc/analyzer/exploded-graph.h:813 #7 0x00a9f143 in ana::run_checkers () at ../../gcc/analyzer/analyzer-logging.h:150 #8 0x00a6f7a6 in (anonymous namespace)::pass_analyzer::execute (this=) at ../../gcc/analyzer/analyzer-pass.cc:87 #9 0x00e13ba9 in execute_one_pass (pass=0x2e3f540) at ../../gcc/passes.c:2567 #10 0x0127aa6b in execute_ipa_pass_list (pass=0x2e3f540) at ../../gcc/passes.c:2996 #11 0x01268538 in do_whole_program_analysis () at ../../gcc/lto/lto.c:469 #12 lto_main () at ../../gcc/lto/lto.c:637 #13 0x01264952 in compile_file () at ../../gcc/toplev.c:460 #14 0x0122aa1c in do_compile () at ../../gcc/toplev.c:2204 #15 toplev::main (this=this@entry=0x7fffbfd731ee, argc=, argv=) at ../../gcc/toplev.c:2345 #16 0x01229d90 in main (argc=, argv=) at ../../gcc/main.c:39
[Bug analyzer/102233] Compiling a smallish binary with -fanalyzer seems to cause very very long compile times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102233
--- Comment #2 from Richard W.M. Jones ---
I think since this seems to be LTO-related, you probably do need
to use LTO CFLAGS in the initial ./configure step. My actual CFLAGS
were:
export CFLAGS="$(rpm --eval '%{optflags}')"
export CXXFLAGS="$(rpm --eval '%{optflags}')"
export LDFLAGS="$(rpm --eval '%{__global_ldflags}')"
which on current Fedora will use LTO.
[Bug analyzer/102233] LTO with -fanalyzer on a smallish binary causes very very long compile times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102233 --- Comment #3 from David Malcolm --- Thanks for filing this. As we discussed on IRC, I recommend avoiding the combination of -fanalyzer and LTO for now. It works for simple examples, but has scaling issues on anything bigger, which I hope to eventually fix, but am focusing on other issues for GCC 12.
[Bug target/97142] __builtin_fmod not optimized on POWER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #18 from Segher Boessenkool ---
+/* { dg-final { scan-assembler-not {(?n)\mb.*fmod} } } */
+/* { dg-final { scan-assembler-not {(?n)\mb.*fmodf} } } */
+/* { dg-final { scan-assembler-not {(?n)\mb.*remainder} } } */
+/* { dg-final { scan-assembler-not {(?n)\mb.*remainderf} } } */
The "f" variants are unnecessary, those are matched by the other REs
already. This is harmless of course.
[Bug c++/102229] [11/12 Regression] 'decltype(auto)' cannot be cv-qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102229 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Jason Merrill --- The standard isn't very clear on this point; it seems like a core issue. 9.2.6/10: A constexpr specifier used in an object declaration declares the object as const. 9.2.9.6.2/2.2: for a variable declared with a type that contains a placeholder type, T is the declared type of the variable and E is the initializer. /5: If the placeholder-type-specifier is of the form type-constraint opt decltype(auto), T shall be the placeholder alone. The question is whether constexpr adds const before deduction (so it's part of "the declared type of the variable") or after. The latter interpretation seems more useful, so let's go with that.
[Bug c++/102229] [11/12 Regression] 'decltype(auto)' cannot be cv-qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102229 --- Comment #6 from Marek Polacek --- Thanks. With the latter interpretation in mind, it seems my earlier fix should be mitigated so that we allow constexpr decltype(auto) but not constexpr const decltype(auto) Yes? Do you want me to raise this with the CWG?
[Bug analyzer/102233] LTO with -fanalyzer on a smallish binary causes very very long compile times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102233
--- Comment #4 from David Malcolm ---
(In reply to Richard W.M. Jones from comment #2)
> I think since this seems to be LTO-related, you probably do need
> to use LTO CFLAGS in the initial ./configure step. My actual CFLAGS
> were:
>
> export CFLAGS="$(rpm --eval '%{optflags}')"
> export CXXFLAGS="$(rpm --eval '%{optflags}')"
> export LDFLAGS="$(rpm --eval '%{__global_ldflags}')"
For reference, what were the flags, specifically? Thanks.
[Bug c++/102234] New: internal compiler error: in type_memfn_rqual, at cp/typeck.c:10389
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102234
Bug ID: 102234
Summary: internal compiler error: in type_memfn_rqual, at
cp/typeck.c:10389
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sin-ack at protonmail dot com
Target Milestone: ---
Created attachment 51423
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51423&action=edit
Test case for bug
Seems to be similar to a few other bugs that relate to two destructor options
constrained by concepts. The test case as reduced by cvise is:
template constexpr bool IsDestructible{};
template
constexpr bool IsTriviallyDestructible = IsDestructible;
template class Optional {
~Optional() requires(!IsDestructible);
~Optional() requires(!IsTriviallyDestructible);
};
template class Result {
using ErrorType = ErrorT;
Optional m_error;
};
class SocketError class UDPSocket {
Result u16ResultUDPSocketSocketError
Output of g++ -v -save-temps -std=c++20 testcase.i is:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/10.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-10.3.0-r2/work/gcc-10.3.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/10.3.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/10.3.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/10.3.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/10.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.0/include/g++-v10
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/10.3.0/python
--enable-languages=c,c++,jit,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 10.3.0-r2 p3'
--disable-esp --enable-libstdcxx-time --enable-host-shared --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--disable-systemtap --disable-vtable-verify --disable-libvtv --without-zstd
--enable-lto --without-isl --enable-default-pie --enable-default-ssp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (Gentoo 10.3.0-r2 p3)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++2a' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-pc-linux-gnu/10.3.0/cc1plus -fpreprocessed testcase.i
-quiet -dumpbase testcase.i -mtune=generic -march=x86-64 -auxbase testcase
-std=c++2a -version -o testcase.s
GNU C++17 (Gentoo 10.3.0-r2 p3) version 10.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.3.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (Gentoo 10.3.0-r2 p3) version 10.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.3.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 7e5a4e9d9d860088f9be6ac2d50a5e79
testcase.i: In instantiation of ‘class Optional’:
testcase.i:10:23: required from ‘class Result’
testcase.i:13:34: required from here
testcase.i:4:29: internal compiler error: in type_memfn_rqual, at
cp/typeck.c:10389
4 | template class Optional {
| ^~~~
0x7f2345cf780c __libc_start_main
../csu/libc-start.c:332
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314
--- Comment #8 from anlauf at gcc dot gnu.org ---
I am testing the following patch which fixes comment#0:
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 2e49a673e15..f2e8896b562 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -2169,6 +2169,24 @@ add_init_expr_to_sym (const char *name, gfc_expr
**initp, locus *var_locus)
sym->as->type = AS_EXPLICIT;
}
+ /* Ensure that explicit bounds are simplified. */
+ if (sym->attr.flavor == FL_PARAMETER && sym->attr.dimension
+ && sym->as->type == AS_EXPLICIT)
+ {
+ for (int dim = 0; dim < sym->as->rank; ++dim)
+ {
+ gfc_expr *e;
+
+ e = sym->as->lower[dim];
+ if (e->expr_type != EXPR_CONSTANT)
+ gfc_reduce_init_expr (e);
+
+ e = sym->as->upper[dim];
+ if (e->expr_type != EXPR_CONSTANT)
+ gfc_reduce_init_expr (e);
+ }
+ }
+
/* Need to check if the expression we initialized this
to was one of the iso_c_binding named constants. If so,
and we're a parameter (constant), let it be iso_c.
[Bug c++/102234] internal compiler error: in type_memfn_rqual, at cp/typeck.c:10389
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102234
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #1 from Andrew Pinski ---
here is the valid code where the ICE happens:
template constexpr bool IsDestructible{};
template
constexpr bool IsTriviallyDestructible = IsDestructible;
template class Optional {
~Optional() requires(!IsDestructible);
~Optional() requires(!IsTriviallyDestructible);
};
template class Result {
using ErrorType = ErrorT;
Optional m_error;
};
class SocketError;
class UDPSocket {
Result u16ResultUDPSocketSocketError;
};
[Bug analyzer/102233] LTO with -fanalyzer on a smallish binary causes very very long compile times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102233
--- Comment #5 from Richard W.M. Jones ---
(In reply to David Malcolm from comment #4)
> (In reply to Richard W.M. Jones from comment #2)
> > I think since this seems to be LTO-related, you probably do need
> > to use LTO CFLAGS in the initial ./configure step. My actual CFLAGS
> > were:
> >
> > export CFLAGS="$(rpm --eval '%{optflags}')"
> > export CXXFLAGS="$(rpm --eval '%{optflags}')"
> > export LDFLAGS="$(rpm --eval '%{__global_ldflags}')"
>
> For reference, what were the flags, specifically? Thanks.
$ echo $CFLAGS
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
$ echo $CXXFLAGS
-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
$ echo $LDFLAGS
-Wl,-z,relro -Wl,--as-needed -Wl,-z,now
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld
[Bug c++/102234] internal compiler error: in type_memfn_rqual, at cp/typeck.c:10389
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102234 --- Comment #2 from sin-ack --- An important thing to note is that when the destructor is private, the ICE occurs. In the original code, when I made the desructor public (after adding the forgotten public: before the destructor), the code will successfully compile.
[Bug c++/102234] internal compiler error: in type_memfn_rqual, at cp/typeck.c:10389
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102234 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 96745. It has a nice reduced testcase. *** This bug has been marked as a duplicate of bug 96745 ***
[Bug c++/96745] [concepts] internal compiler error: in type_memfn_rqual, at cp/typeck.c:10389
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96745 Andrew Pinski changed: What|Removed |Added CC||sin-ack at protonmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 102234 has been marked as a duplicate of this bug. ***
[Bug target/97142] __builtin_fmod not optimized on POWER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142 --- Comment #19 from Segher Boessenkool --- (In reply to Peter Bergner from comment #17) > The Version about is to 10.2, does that mean we're going to back port this > to the release branches, or are we calling it good with trunk? This is a pretty low risk patch, so if it has an important positive effect we could decide to backport it. To both 11 and 10 then? Does it have such an important effect? But first let it stew for a while, see if surprises show up on trunk :-)
[Bug c++/102223] no warning when calling member function on dangling reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102223 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- are you expecting this to go under an existing warning flag, or a new one?
[Bug tree-optimization/102216] [12 Regression] missed optimization causing Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102216 Andrew Pinski changed: What|Removed |Added Attachment #51420|0 |1 is obsolete|| --- Comment #8 from Andrew Pinski --- Created attachment 51424 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51424&action=edit New patch THis is the new patch which I am testing. It fixes the original issue in forwprop but does not fix the FIXME of creating extra trees.
[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #9 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-September/056492.html
[Bug go/102102] [12 Regression] trunk 20210827 ftbfs libgo on x86_64-linux-gnux32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102102 --- Comment #1 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:21b046bade1c2666b82139d18c8b318bb051415e commit r12-3401-g21b046bade1c2666b82139d18c8b318bb051415e Author: Ian Lance Taylor Date: Tue Sep 7 14:37:55 2021 -0700 runtime: use hash32, not hash64, for amd64p32, mips64p32, mips64p32le Fixes PR go/102102 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/348015
[Bug go/102102] [12 Regression] trunk 20210827 ftbfs libgo on x86_64-linux-gnux32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102102 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Ian Lance Taylor --- Should be fixed now, I hope. I don't know how to test this, as my desktop does not support x32 mode.
[Bug target/102115] symbol address eliminated by the xtensa size optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102115 --- Comment #2 from CVS Commits --- The master branch has been updated by Max Filippov : https://gcc.gnu.org/g:b552c4e601c7fdc4d341e29cc1ed6081d42b00d0 commit r12-3402-gb552c4e601c7fdc4d341e29cc1ed6081d42b00d0 Author: Max Filippov Date: Tue Sep 7 15:40:00 2021 -0700 gcc: xtensa: fix PR target/102115 2021-09-07 Takayuki 'January June' Suwa gcc/ PR target/102115 * config/xtensa/xtensa.c (xtensa_emit_move_sequence): Add 'CONST_INT_P (src)' to the condition of the block that tries to eliminate literal when loading integer contant.
[Bug c++/102235] New: array not decay to pointer for template function parameter during specialization with parameter pack as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102235
Bug ID: 102235
Summary: array not decay to pointer for template function
parameter during specialization with parameter pack as
template argument
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
Consider this snippet with error of no matches of specialization, it is similar
to case PR94501 which happens during implicit conversion. However, the internal
implementation of them might be very different. So, I would rather file this as
a new bug instead of duplicate. The direct reason is that fixing this bug might
not fix this PR94501.
template
void foo(Ts...);
template<>
void foo(int*){}
parameter.cpp:4:6: error: template-id ‘foo’ for ‘void foo(int*)’ does
not match any template declaration
void foo(int*){}
^~
parameter.cpp:2:6: note: candidate is: template void foo(Ts ...)
void foo(Ts...);
^~~
[Bug tree-optimization/89317] Ineffective code from std::copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- Comment #4 from Andrew Pinski ---
Mine.
After my patch for PR 102216, we get:
_1 = &this_6(D)->data1;
_2 = this_6(D) + 16;
_19 = _2 - _1;
I suspect if we add:
(simplify
(pointer_diff (pointer_plus @0 @1) ADDR_EXPR@2)
(with { poly_int64 diff; }
(if (ptr_difference_const (@0, @2, &diff))
(plus { build_int_cst_type (type, diff); } (convert @1)
(simplify
(pointer_diff ADDR_EXPR@0 (pointer_plus @1 @2))
(with { poly_int64 diff; }
(if (ptr_difference_const (@0, @1, &diff))
(minus { build_int_cst_type (type, diff); } (convert @2)
This will work.
[Bug target/102115] symbol address eliminated by the xtensa size optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102115 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Max Filippov : https://gcc.gnu.org/g:dcb2873cd32b263643bfd9d1298b35d6cd028f0a commit r11-8969-gdcb2873cd32b263643bfd9d1298b35d6cd028f0a Author: Max Filippov Date: Tue Sep 7 15:40:00 2021 -0700 gcc: xtensa: fix PR target/102115 2021-09-07 Takayuki 'January June' Suwa gcc/ PR target/102115 * config/xtensa/xtensa.c (xtensa_emit_move_sequence): Add 'CONST_INT_P (src)' to the condition of the block that tries to eliminate literal when loading integer contant. (cherry picked from commit b552c4e601c7fdc4d341e29cc1ed6081d42b00d0)
[Bug target/102115] symbol address eliminated by the xtensa size optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102115 jcmvbkbc at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from jcmvbkbc at gcc dot gnu.org --- The fix is committed to master and releases/gcc-11 branch.
[Bug c++/102236] New: emplace_deref is not constexpr for join_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102236
Bug ID: 102236
Summary: emplace_deref is not constexpr for join_view
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
For instance:
#include
constexpr std::string_view first_n_words(std::string_view str, size_t n) {
namespace rv = std::views;
auto first_n = str
| rv::split(' ')
| rv::take(n)
| rv::join;
return std::string_view(&*first_n.begin(), std::ranges::distance(first_n));
}
constexpr std::string_view first4 = first_n_words("Hello to all you beautiful
libstdc++ developers", 4);
This doesn't compile because _M_emplace_deref isn't marked constexpr (probably
becase P2231 isn't implemented yet, but thought I'd file a bug report anyway).
[Bug tree-optimization/80155] [9/10/11/12 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 --- Comment #50 from Andrew Pinski --- the original testcase for cortex-m7 seems to be fixed in GCC 11+.
[Bug target/102230] ICE in classify_argument, at config/i386/i386.c:2474
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102230 --- Comment #1 from Hongtao.liu --- It relies on https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576496.html which is not committed yet.
