[Bug libstdc++/110593] New: The std::ratio meta arithmetic can accept non-std::ratio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110593
Bug ID: 110593
Summary: The std::ratio meta arithmetic can accept
non-std::ratio
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
[ratio.general]: "If a template parameter is named R1 or R2, and the template
argument is not a specialization of the ratio template, the program is
ill-formed."
So for the following libstdc++ needs to be diagnosed, right?
#include
struct Ratio { constexpr static double num = 0, den = 1; };
static_assert(std::ratio_equal>());
https://godbolt.org/z/MhazY5ecn
Only MSVC-STL triggers the static assertion.
[Bug target/110592] New: [SPARC] GCC should default to TSO memory model when compiling for sparc32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592 Bug ID: 110592 Summary: [SPARC] GCC should default to TSO memory model when compiling for sparc32 Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: koachan+gccbugs at protonmail dot com Target Milestone: --- Created attachment 55501 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55501=edit Reproducer of unwanted memory reordering under TSO processors Currently, when targeting sparc32 processors, GCC assumes that the hardware has sequentially consistent memory ordering by default. This can cause problems when running generated binaries on v8 and later processors, which uses weaker TSO ordering. In the attached reproducer, when compiled with the default sparc32 target, the resulting code is missing the required barriers: 0fb0 : ... 104c: e0 26 00 00 st %l0, [ %i0 ] 1050: c2 06 40 00 ld [ %i1 ], %g1 1054: c2 26 80 00 st %g1, [ %i2 ] ... 108c : ... 1128: e0 26 00 00 st %l0, [ %i0 ] 112c: c2 06 40 00 ld [ %i1 ], %g1 1130: c2 26 80 00 st %g1, [ %i2 ] ... Compare with the result when explicitly specifying -mcpu=v8: 0fa4 : ... 1040: e0 26 00 00 st %l0, [ %i0 ] 1044: c0 6b bf ff ldstub [ %sp + -1 ], %g0 1048: c0 6b bf ff ldstub [ %sp + -1 ], %g0 104c: c2 06 40 00 ld [ %i1 ], %g1 1050: c2 26 80 00 st %g1, [ %i2 ] 1054: c0 6b bf ff ldstub [ %sp + -1 ], %g0 ... 108c : ... 1128: e0 26 00 00 st %l0, [ %i0 ] 112c: c0 6b bf ff ldstub [ %sp + -1 ], %g0 1130: c0 6b bf ff ldstub [ %sp + -1 ], %g0 1134: c2 06 40 00 ld [ %i1 ], %g1 1138: c2 26 80 00 st %g1, [ %i2 ] 113c: c0 6b bf ff ldstub [ %sp + -1 ], %g0 ... This causes the default-target code to hit the assert condition. Since all code that works on TSO processors will work on processors with a stronger memory model (i.e sequential consistency), it is probably better if GCC uses TSO by default unless otherwise specified (e.g by explicitly using -mcpu=v7).
[Bug c++/106389] [11/12/13/14 Regression] IPA modref breaks Safe Bitfields in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106389 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-07-08 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #8 from Andrew Pinski --- .
[Bug middle-end/98540] [11/12/13/14 Regression] ICE: error: type variant with 'TYPE_ALIAS_SET_KNOWN_P' since r7-6939-g853ef4e5632df328
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98540 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #9 from Andrew Pinski --- Dup of bug 97990. *** This bug has been marked as a duplicate of bug 97990 ***
[Bug c++/97990] [11/12/13/14 Regression] ICE: ‘verify_type’ failed with vector types and non-PODs since r6-5222-gba6a6a1d44c17f25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97990 --- Comment #10 from Andrew Pinski --- *** Bug 98540 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/110582] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110582
--- Comment #4 from Andrew Pinski ---
Another testcase:
```
int a, b;
int main() {
char a = 0;
int t = 0;
for (; t <253; t ++){
int d = 2;
d ^= 2 && a;
b = a == 0 ? d : d / a;
a = b;
}
for (; (1 + 95 << 24) + b + 1 + 686658714L + b - 2297271457;)
;
}
```
Just to show that you could count up from 0 to 253 and still have an issue
without any wrapping happening in the original code.
[Bug tree-optimization/110582] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110582
--- Comment #3 from Andrew Pinski ---
(In reply to Richard Biener from comment #2)
> It works with -fno-tree-loop-optimize but the difference from loop opts is
> just
So changing it to what -ftree-loop-optimize, it still passes with
-fno-tree-loop-optimize (which is even odder):
```
int a, b;
int main() {
char c = a = 0;
unsigned char t = 253;
for (; t != 0; t --){
int d = 2;
d ^= 2 && a;
b = a == 0 ? d : d / a;
a = b;
}
for (; (1 + 95 << 24) + b + 1 + 686658714L + b - 2297271457;)
;
}
```
The difference in this case is:
+ unsigned charD.20 ivtmp_32;
+ unsigned charD.20 ivtmp_33;
...
- # RANGE [irange] unsigned char [1, 253]
- # t_19 = PHI
# .MEM_20 = PHI <.MEM_20(5), .MEM_11(D)(2)>
# a_lsm.11_2 = PHI
+ # ivtmp_33 = PHI
...
- # RANGE [irange] unsigned char [0, 252]
- t_16 = t_19 + 255;
- if (t_16 != 0)
+ ivtmp_32 = ivtmp_33 - 1;
+ if (ivtmp_32 != 0)
```
The only thing I can of which might be causing the issue is +255 vs -1 here.
[Bug tree-optimization/110539] [14 Regression] Dead Code Elimination Regression at since r14-338-g1dd154f6407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-July/62 ||3881.html Keywords||patch --- Comment #6 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623881.html
[Bug rtl-optimization/110423] Redundant constants not getting eliminated on RISCV.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110423 --- Comment #3 from Vineet Gupta --- (In reply to Jeffrey A. Law from comment #2) > This is derived heavily from Click's work in the 90s. > This would happen in gimple most likely, though I guess one could do it in > RTL if they have a high pain threshold. If a gimple pass, it won't help catch the late reload induced rematerializations, which is seen on a lot of SPEC workloads, e.g. cactu for stack addressing. Although I guess Manolis' fold const offset pass patch would help things a bit. > Click's paper is much more general, but the same concepts apply. His paper > doesn't cover anything like bifurcating the graph (thus allowing multiple > constant loads in an effort to reduce undesired speculation or register > allocation conflicts). > > We might be able to get away with this precisely because these are constant > loads and thus subject to rematerialization later if register pressure is > high. > > https://courses.cs.washington.edu/courses/cse501/06wi/reading/click-pldi95. > pdf The prospect of implementing Cliff's Global Value Numbering is very exciting, however I would like to start small. Started digging into gcse.cc Hoist pass, granted this is still pre-reload. It seems Hoist has some global redundancy elimination capabilities for constants, added by Maxim Kuvyrkov back in 2010. I need to see what it can and can not do.
[Bug fortran/105526] [Coarray] Missing checks for arguments of type TEAM_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105526
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> *** Bug 103796 has been marked as a duplicate of this bug. ***
The diff attached to the duplicate did handle the optional form-team-spec-list.
+
+ /* Abort if the unsupported form-team-spec-list is detected. */
+ gfc_gobble_whitespace ();
+ if (gfc_peek_ascii_char () == ',')
+{
+ gfc_error ("Comma detected at %C. The optional [, "
+ "form-team-spec-list ] is unsupported. Be a hero and "
+ "join the gfortran development team.");
+ return MATCH_ERROR;
+}
gfortran currently gives
hotrats:kargl[203] gfcx -c -fcoarray=single a.f90
a.f90:7:22:
7 | FORM TEAM (ME(1), ROW, NEW_INDEX=ME(2))
| 1
Error: Syntax error in FORM TEAM statement at (1)
[Bug c++/103511] __builtin_bit_cast requires a constructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103511 --- Comment #5 from Louis Dionne --- Note that my claim about TriviallyCopyable is taken from the Standard here, for reference (even though Jason probably knows this by heart :-). https://eel.is/c++draft/class.prop#1: > A trivially copyable class is a class: > (1.1) that has at least one eligible copy constructor, move constructor, copy > assignment operator, or move assignment operator ([special], > [class.copy.ctor], [class.copy.assign]), > (1.2) where each eligible copy constructor, move constructor, copy assignment > operator, and move assignment operator is trivial, and > (1.3) that has a trivial, non-deleted destructor ([class.dtor]).
[Bug middle-end/110590] Failing CFG consistency testcases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110590 --- Comment #2 from Jan Hubicka --- ... and testsuite/gcc.dg/unroll-7.c
[Bug fortran/107397] [11/12 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397 --- Comment #14 from anlauf at gcc dot gnu.org --- This PR is half a zombie. Jerry, do you plan to backport the fixes in comment#8 and comment#11 so that we can finally close this one?
[Bug target/82580] Optimize comparisons for __int128 on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82580 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Comment #16 from Roger Sayle --- Advance warning that the testcase pr82580.c will start FAILing due to differences in register allocation following improvements to __int128 parameter passing as explained in https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623756.html. We might need additional reload alternatives/preferences to ensure that we don't generate a movzbl. Hopefully, Jakub and/or Uros have some suggestions for how best this can be fixed. Previously, the SUBREGs and CLOBBERs generated by middle-end RTL expansion (unintentionally) ensured that rdx and rax would never be used for __int128 arguments, which conveniently allowed the use of xor eax,eax; setc al in peephole2 as AX_REG wasn't live. Now reload has more freedom, it elects to use rax as at this point the backend hasn't expressed any preference that it would like eax reserved for producing the result.
[Bug d/108842] Cannot use enum array with -fno-druntime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108842 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED CC||ibuclaw at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #5 from ibuclaw at gcc dot gnu.org --- Fix committed and backported.
[Bug d/108842] Cannot use enum array with -fno-druntime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108842 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:eef069fe8b9509a783c9ecb2eb659df4f5ab commit r11-10898-geef069fe8b9509a783c9ecb2eb659df4f5ab Author: Iain Buclaw Date: Fri Jul 7 21:06:07 2023 +0200 d: Fix PR 108842: Cannot use enum array with -fno-druntime Restrict the generating of CONST_DECLs for D manifest constants to just scalars without pointers. It shouldn't happen that a reference to a manifest constant has not been expanded within a function body during codegen, but it has been found to occur in older versions of the D front-end (PR98277), so if the decl of a non-scalar constant is requested, just return its initializer as an expression. PR d/108842 gcc/d/ChangeLog: * decl.cc (DeclVisitor::visit (VarDeclaration *)): Only emit scalar manifest constants. (get_symbol_decl): Don't generate CONST_DECL for non-scalar manifest constants. * imports.cc (ImportVisitor::visit (VarDeclaration *)): New method. gcc/testsuite/ChangeLog: * gdc.dg/pr98277.d: Add more tests. * gdc.dg/pr108842.d: New test. (cherry picked from commit f934c5753849f7c48c6a3abfcd73b8f6008e8371)
[Bug target/91681] Missed optimization for 128 bit arithmetic operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91681 Roger Sayle changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com CC||roger at nextmovesoftware dot com --- Comment #4 from Roger Sayle --- Advance warning, the testcase pr91681-1.c will start FAILing (temporarily) due to changes/improvements in __int128 parameter passing, as explained in https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623756.html Easily fixed by additional define_insn_and_split patterns which I'll submit soon.
[Bug target/43644] __uint128_t missed optimizations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43644
--- Comment #3 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:bdf2737cda53a83332db1a1a021653447b05a7e7
commit r14-2386-gbdf2737cda53a83332db1a1a021653447b05a7e7
Author: Roger Sayle
Date: Fri Jul 7 20:39:58 2023 +0100
i386: Improve __int128 argument passing (in ix86_expand_move).
Passing 128-bit integer (TImode) parameters on x86_64 can sometimes
result in surprising code. Consider the example below (from PR 43644):
unsigned __int128 foo(unsigned __int128 x, unsigned long long y) {
return x+y;
}
which currently results in 6 consecutive movq instructions:
foo:movq%rsi, %rax
movq%rdi, %rsi
movq%rdx, %rcx
movq%rax, %rdi
movq%rsi, %rax
movq%rdi, %rdx
addq%rcx, %rax
adcq$0, %rdx
ret
The underlying issue is that during RTL expansion, we generate the
following initial RTL for the x argument:
(insn 4 3 5 2 (set (reg:TI 85)
(subreg:TI (reg:DI 86) 0)) "pr43644-2.c":5:1 -1
(nil))
(insn 5 4 6 2 (set (subreg:DI (reg:TI 85) 8)
(reg:DI 87)) "pr43644-2.c":5:1 -1
(nil))
(insn 6 5 7 2 (set (reg/v:TI 84 [ x ])
(reg:TI 85)) "pr43644-2.c":5:1 -1
(nil))
which by combine/reload becomes
(insn 25 3 22 2 (set (reg/v:TI 84 [ x ])
(const_int 0 [0])) "pr43644-2.c":5:1 -1
(nil))
(insn 22 25 23 2 (set (subreg:DI (reg/v:TI 84 [ x ]) 0)
(reg:DI 93)) "pr43644-2.c":5:1 90 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 93)
(nil)))
(insn 23 22 28 2 (set (subreg:DI (reg/v:TI 84 [ x ]) 8)
(reg:DI 94)) "pr43644-2.c":5:1 90 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 94)
(nil)))
where the heavy use of SUBREG SET_DESTs creates challenges for both
combine and register allocation.
The improvement proposed here is to avoid these problematic SUBREGs
by adding (two) special cases to ix86_expand_move. For insn 4, which
sets a TImode destination from a paradoxical SUBREG, to assign the
lowpart, we can use an explicit zero extension (zero_extendditi2 was
added in July 2022), and for insn 5, which sets the highpart of a
TImode register we can use the *insvti_highpart_1 instruction (that
was added in May 2023, after being approved for stage1 in January).
This allows combine to work its magic, merging these insns into a
*concatditi3 and from there into other optimized forms.
So for the test case above, we now generate only a single movq:
foo:movq%rdx, %rax
xorl%edx, %edx
addq%rdi, %rax
adcq%rsi, %rdx
ret
But there is a little bad news. This patch causes two (minor) missed
optimization regressions on x86_64; gcc.target/i386/pr82580.c and
gcc.target/i386/pr91681-1.c. As shown in the test case above, we're
no longer generating adcq $0, but instead using xorl. For the other
FAIL, register allocation now has more freedom and is (arbitrarily)
choosing a register assignment that doesn't match what the test is
expecting. These issues are easier to explain and fix once this patch
is in the tree.
The good news is that this approach fixes a number of long standing
issues, that need to checked in bugzilla, including PR target/110533
which was just opened/reported earlier this week.
2023-07-07 Roger Sayle
gcc/ChangeLog
PR target/43644
PR target/110533
* config/i386/i386-expand.cc (ix86_expand_move): Convert SETs of
TImode destinations from paradoxical SUBREGs (setting the lowpart)
into explicit zero extensions. Use *insvti_highpart_1 instruction
to set the highpart of a TImode destination.
gcc/testsuite/ChangeLog
PR target/43644
PR target/110533
* gcc.target/i386/pr110533.c: New test case.
* gcc.target/i386/pr43644-2.c: Likewise.
[Bug target/110533] [x86-64] naked with -O0 and register-passed struct/int128 clobbers parameters/callee-saved regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110533
--- Comment #4 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:bdf2737cda53a83332db1a1a021653447b05a7e7
commit r14-2386-gbdf2737cda53a83332db1a1a021653447b05a7e7
Author: Roger Sayle
Date: Fri Jul 7 20:39:58 2023 +0100
i386: Improve __int128 argument passing (in ix86_expand_move).
Passing 128-bit integer (TImode) parameters on x86_64 can sometimes
result in surprising code. Consider the example below (from PR 43644):
unsigned __int128 foo(unsigned __int128 x, unsigned long long y) {
return x+y;
}
which currently results in 6 consecutive movq instructions:
foo:movq%rsi, %rax
movq%rdi, %rsi
movq%rdx, %rcx
movq%rax, %rdi
movq%rsi, %rax
movq%rdi, %rdx
addq%rcx, %rax
adcq$0, %rdx
ret
The underlying issue is that during RTL expansion, we generate the
following initial RTL for the x argument:
(insn 4 3 5 2 (set (reg:TI 85)
(subreg:TI (reg:DI 86) 0)) "pr43644-2.c":5:1 -1
(nil))
(insn 5 4 6 2 (set (subreg:DI (reg:TI 85) 8)
(reg:DI 87)) "pr43644-2.c":5:1 -1
(nil))
(insn 6 5 7 2 (set (reg/v:TI 84 [ x ])
(reg:TI 85)) "pr43644-2.c":5:1 -1
(nil))
which by combine/reload becomes
(insn 25 3 22 2 (set (reg/v:TI 84 [ x ])
(const_int 0 [0])) "pr43644-2.c":5:1 -1
(nil))
(insn 22 25 23 2 (set (subreg:DI (reg/v:TI 84 [ x ]) 0)
(reg:DI 93)) "pr43644-2.c":5:1 90 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 93)
(nil)))
(insn 23 22 28 2 (set (subreg:DI (reg/v:TI 84 [ x ]) 8)
(reg:DI 94)) "pr43644-2.c":5:1 90 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 94)
(nil)))
where the heavy use of SUBREG SET_DESTs creates challenges for both
combine and register allocation.
The improvement proposed here is to avoid these problematic SUBREGs
by adding (two) special cases to ix86_expand_move. For insn 4, which
sets a TImode destination from a paradoxical SUBREG, to assign the
lowpart, we can use an explicit zero extension (zero_extendditi2 was
added in July 2022), and for insn 5, which sets the highpart of a
TImode register we can use the *insvti_highpart_1 instruction (that
was added in May 2023, after being approved for stage1 in January).
This allows combine to work its magic, merging these insns into a
*concatditi3 and from there into other optimized forms.
So for the test case above, we now generate only a single movq:
foo:movq%rdx, %rax
xorl%edx, %edx
addq%rdi, %rax
adcq%rsi, %rdx
ret
But there is a little bad news. This patch causes two (minor) missed
optimization regressions on x86_64; gcc.target/i386/pr82580.c and
gcc.target/i386/pr91681-1.c. As shown in the test case above, we're
no longer generating adcq $0, but instead using xorl. For the other
FAIL, register allocation now has more freedom and is (arbitrarily)
choosing a register assignment that doesn't match what the test is
expecting. These issues are easier to explain and fix once this patch
is in the tree.
The good news is that this approach fixes a number of long standing
issues, that need to checked in bugzilla, including PR target/110533
which was just opened/reported earlier this week.
2023-07-07 Roger Sayle
gcc/ChangeLog
PR target/43644
PR target/110533
* config/i386/i386-expand.cc (ix86_expand_move): Convert SETs of
TImode destinations from paradoxical SUBREGs (setting the lowpart)
into explicit zero extensions. Use *insvti_highpart_1 instruction
to set the highpart of a TImode destination.
gcc/testsuite/ChangeLog
PR target/43644
PR target/110533
* gcc.target/i386/pr110533.c: New test case.
* gcc.target/i386/pr43644-2.c: Likewise.
[Bug target/106895] powerpc64 unable to specify even/odd register pairs in extended inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
--- Comment #12 from Segher Boessenkool ---
> I guess that would be annoying if you couldn't have modifiers on constraints
There is no such thing as "operand modifiers". There are *output* modifiers:
they change how an operand is *printed*, they do not change the operand in any
way, shape, or form.
> or a bad algorithm for working them out. Fair enough.
No idea what you mean here?
> > > or why TI doesn't work but PTI apparently would,
> >
> > Because this is exactly what PTImode is *for*!
>
> Right I accept it is, I meant I just would not have been able to work it out
> (assuming if PTI was documented it would be "Partial Tetra Integer" and be
> no more useful than the other P?I type documentation.
For the rs6000 port, multi-register operands are not restricted to aligned
register numbers ("even/odd pairs"). (Some other ports do have this). We use
the existing PTI mode for that (it also can be allocated in GPRs only, never in
VSRs, unlike TImode).
"Partial" does not have much meaning here. A minority of ports use partial
integer words for what they were introduced for originally: modes that are
smaller than a full register, say, a 24-bit mode when registers are 32 bits.
We use it as another integer mode that is the same size. It is unfortunate
that we still have to resort to such tricks.
[Bug d/108842] Cannot use enum array with -fno-druntime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108842 --- Comment #3 from CVS Commits --- The releases/gcc-12 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:0444c2065aef569aa16e43cffc564c202a59af33 commit r12-9759-g0444c2065aef569aa16e43cffc564c202a59af33 Author: Iain Buclaw Date: Fri Jul 7 21:06:07 2023 +0200 d: Fix PR 108842: Cannot use enum array with -fno-druntime Restrict the generating of CONST_DECLs for D manifest constants to just scalars without pointers. It shouldn't happen that a reference to a manifest constant has not been expanded within a function body during codegen, but it has been found to occur in older versions of the D front-end (PR98277), so if the decl of a non-scalar constant is requested, just return its initializer as an expression. PR d/108842 gcc/d/ChangeLog: * decl.cc (DeclVisitor::visit (VarDeclaration *)): Only emit scalar manifest constants. (get_symbol_decl): Don't generate CONST_DECL for non-scalar manifest constants. * imports.cc (ImportVisitor::visit (VarDeclaration *)): New method. gcc/testsuite/ChangeLog: * gdc.dg/pr98277.d: Add more tests. * gdc.dg/pr108842.d: New test. (cherry picked from commit f934c5753849f7c48c6a3abfcd73b8f6008e8371)
[Bug d/108842] Cannot use enum array with -fno-druntime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108842 --- Comment #2 from CVS Commits --- The releases/gcc-13 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:acd679a7944a4fde8a7ed9ac739749deff9f71ba commit r13-7547-gacd679a7944a4fde8a7ed9ac739749deff9f71ba Author: Iain Buclaw Date: Fri Jul 7 21:06:07 2023 +0200 d: Fix PR 108842: Cannot use enum array with -fno-druntime Restrict the generating of CONST_DECLs for D manifest constants to just scalars without pointers. It shouldn't happen that a reference to a manifest constant has not been expanded within a function body during codegen, but it has been found to occur in older versions of the D front-end (PR98277), so if the decl of a non-scalar constant is requested, just return its initializer as an expression. PR d/108842 gcc/d/ChangeLog: * decl.cc (DeclVisitor::visit (VarDeclaration *)): Only emit scalar manifest constants. (get_symbol_decl): Don't generate CONST_DECL for non-scalar manifest constants. * imports.cc (ImportVisitor::visit (VarDeclaration *)): New method. gcc/testsuite/ChangeLog: * gdc.dg/pr98277.d: Add more tests. * gdc.dg/pr108842.d: New test. (cherry picked from commit f934c5753849f7c48c6a3abfcd73b8f6008e8371)
[Bug d/108842] Cannot use enum array with -fno-druntime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108842 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:f934c5753849f7c48c6a3abfcd73b8f6008e8371 commit r14-2385-gf934c5753849f7c48c6a3abfcd73b8f6008e8371 Author: Iain Buclaw Date: Fri Jul 7 21:06:07 2023 +0200 d: Fix PR 108842: Cannot use enum array with -fno-druntime Restrict the generating of CONST_DECLs for D manifest constants to just scalars without pointers. It shouldn't happen that a reference to a manifest constant has not been expanded within a function body during codegen, but it has been found to occur in older versions of the D front-end (PR98277), so if the decl of a non-scalar constant is requested, just return its initializer as an expression. PR d/108842 gcc/d/ChangeLog: * decl.cc (DeclVisitor::visit (VarDeclaration *)): Only emit scalar manifest constants. (get_symbol_decl): Don't generate CONST_DECL for non-scalar manifest constants. * imports.cc (ImportVisitor::visit (VarDeclaration *)): New method. gcc/testsuite/ChangeLog: * gdc.dg/pr98277.d: Add more tests. * gdc.dg/pr108842.d: New test.
[Bug fortran/110585] ICE in gfc_compare_expr for findloc with complex literal array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110585 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-July/059566.html
[Bug fortran/103796] ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9446 since r8-6395-gf8862a1b2afad9d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103796 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #8 from anlauf at gcc dot gnu.org --- Dup of pr105526. *** This bug has been marked as a duplicate of bug 105526 ***
[Bug fortran/105526] [Coarray] Missing checks for arguments of type TEAM_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105526 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||gs...@t-online.de --- Comment #4 from anlauf at gcc dot gnu.org --- *** Bug 103796 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 --- Comment #59 from Tamar Christina --- I've sent two patches upstream this morning to fix the remaining ifcvt issues: https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623848.html https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623849.html This brings us within 5% of GCC-12, but not all the way there, the reason is that since GCC-13 PRE behaves differently. In GCC-12 after PRE we'd have the following CFG: [local count: 623751662]: _16 = distbb_79 * iftmp.1_100; iftmp.8_80 = 1.0e+0 - _16; _160 = chrg_init_75 * iftmp.8_80; [local count: 1057206200]: # iftmp.8_39 = PHI # prephitmp_161 = PHI <_160(15), chrg_init_75(14)> if (distbb_79 < iftmp.0_96) goto ; [50.00%] else goto ; [50.00%] [local count: 528603100]: _164 = ABS_EXPR ; _166 = -_164; [local count: 1057206200]: # iftmp.9_40 = PHI <1.0e+0(17), 0.0(16)> # prephitmp_163 = PHI # prephitmp_167 = PHI <_166(17), 0.0(16)> if (iftmp.2_38 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 528603100]: [local count: 1057206200]: # iftmp.10_41 = PHI That is to say, in both branches we always do the multiply, gimple-isel then correctly turns this into a COND_MUL based on the mask. Since GCC-13 PRE now does some extra optimizations: [local count: 1057206200]: # l_107 = PHI _13 = lpos_x[l_107]; x_72 = _13 - p_atom$x_81; powmult_73 = x_72 * x_72; distbb_74 = powmult_73 - radij_58; if (distbb_74 >= 0.0) goto ; [59.00%] else goto ; [41.00%] [local count: 433454538]: _165 = ABS_EXPR ; _168 = -_165; goto ; [100.00%] [local count: 623751662]: _14 = distbb_74 * iftmp.1_101; iftmp.8_76 = 1.0e+0 - _14; if (distbb_74 < iftmp.0_97) goto ; [20.00%] else goto ; [80.00%] [local count: 124750334]: _162 = chrg_init_70 * iftmp.8_76; _164 = ABS_EXPR <_162>; _167 = -_164; [local count: 1057206200]: # iftmp.9_38 = PHI <1.0e+0(18), 0.0(17), 1.0e+0(16)> # iftmp.8_102 = PHI # prephitmp_163 = PHI <_162(18), 0.0(17), chrg_init_70(16)> # prephitmp_169 = PHI <_167(18), 0.0(17), _168(16)> if (iftmp.2_36 != 0) goto ; [50.00%] else goto ; [50.00%] That is to say, the multiplication is now compleletely skipped in one branch, this should be better for scalar code, but for vector we have to do the multiplication anyway. after ifcvt we end up with: _162 = chrg_init_70 * iftmp.8_76; _164 = ABS_EXPR <_162>; _167 = -_164; _ifc__166 = distbb_74 < iftmp.0_97 ? _167 : 0.0; prephitmp_169 = distbb_74 >= 0.0 ? _ifc__166 : _168; instead of _160 = chrg_init_75 * iftmp.8_80; prephitmp_161 = distbb_79 < 0.0 ? chrg_init_75 : _160; _164 = ABS_EXPR ; _166 = -_164; prephitmp_167 = distbb_79 < iftmp.0_96 ? _166 : 0.0; previously we'd make COND_MUL and COND_NEG and so don't need a VCOND in the end, now we select after the multiplication, so we only have a COND_NEG followed by a VCOND. This is obviously worse, but I have no idea how to recover it. Any ideas?
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 Jakub Jelinek changed: What|Removed |Added Attachment #55499|0 |1 is obsolete|| --- Comment #76 from Jakub Jelinek --- Created attachment 55500 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55500=edit gcc14-bitint-wip.patch Now with support for INTEGER_CST PHI arguments. Will start work on large/huge _BitInt multiplication/division next.
[Bug fortran/103796] ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9446 since r8-6395-gf8862a1b2afad9d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103796 --- Comment #7 from Steve Kargl --- On Tue, Jul 04, 2023 at 09:34:02PM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103796 > > Jerry DeLisle changed: > >What|Removed |Added > > CC||jvdelisle at gcc dot gnu.org > > --- Comment #6 from Jerry DeLisle --- > This appears to be fixed on trunk. Can we close it? > Yes. Likely fixed by 2022-05-10 Harald Anlauf PR fortran/105526 * resolve.cc (check_team): New. (gfc_resolve_code): Add checks for arguments to coarray intrinsics FORM TEAM, CHANGE TEAM, and SYNC TEAM.
[Bug tree-optimization/89479] __restrict on a pointer ignored when disambiguating against a call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479 Andrew Pinski changed: What|Removed |Added CC||javier.martinez.bugzilla@gm ||ail.com --- Comment #12 from Andrew Pinski --- *** Bug 110589 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/110589] Missed optimization with call-clobbered restrict qualified references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110589 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 89479. *** This bug has been marked as a duplicate of bug 89479 ***
[Bug c++/103511] __builtin_bit_cast requires a constructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103511 --- Comment #4 from Jakub Jelinek --- Jason, your call on this?
[Bug c++/103511] __builtin_bit_cast requires a constructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103511
Louis Dionne changed:
What|Removed |Added
CC||ldionne.2 at gmail dot com
--- Comment #3 from Louis Dionne ---
I concur with the reporter of this issue. `bit_cast` requires the types to be
TriviallyCopyable. In turn, TriviallyCopyable requires (for class types) that
there's at least one eligible copy constructor, move constructor, copy
assignment operator, or move assignment operator. It doesn't say which of those
has to be valid, but at least one of those has to be valid.
However, GCC's implementation of __builtin_bit_cast seems to always require at
least a copy or a move constructor, which seems like a bug to me.
For example, the following code should be valid IIUC, but it fails with GCC:
struct CopyAssignable {
CopyAssignable() = default;
int value = 0;
CopyAssignable(const CopyAssignable&)= delete;
CopyAssignable(CopyAssignable&&) = delete;
CopyAssignable& operator=(const CopyAssignable&) = default;
CopyAssignable& operator=(CopyAssignable&&) = delete;
};
struct MoveAssignable {
MoveAssignable() = default;
int value = 0;
MoveAssignable(const MoveAssignable&)= delete;
MoveAssignable(MoveAssignable&&) = delete;
MoveAssignable& operator=(const MoveAssignable&) = delete;
MoveAssignable& operator=(MoveAssignable&&) = default;
};
int main(int, char**) {
CopyAssignable foo1;
(void)__builtin_bit_cast(CopyAssignable, foo1); // doesn't work
MoveAssignable foo2;
(void)__builtin_bit_cast(MoveAssignable, foo2); // doesn't work
}
Full example on Godbolt showing that this is accepted by Clang and MSVC but
rejected by GCC: https://godbolt.org/z/548YKndrK
I am running into this issue while trying to fix something in libc++ here:
https://reviews.llvm.org/D154613
[Bug middle-end/110590] Failing CFG consistency testcases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110590 --- Comment #1 from Jan Hubicka --- Forgot about gcc.dg/tree-prof/update-unroll-2.c
[Bug target/110591] New: [i386] (Maybe) Missed optimisation: _cmpccxadd sets flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110591
Bug ID: 110591
Summary: [i386] (Maybe) Missed optimisation: _cmpccxadd sets
flags
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
In:
#include
bool increment_if(int *ptr, int v)
{
return _cmpccxadd_epi32(ptr, v, 1, _CMPCCX_Z) == v;
}
GCC generates (and current Clang does the same):
increment_if(int*, int):
movl$1, %edx
movl%esi, %eax
cmpzxadd%edx, %eax, (%rdi)
cmpl%eax, %esi
sete%al
ret
The CMPccXADD instructions set EFLAGS to the result of the comparison of their
memory operand to the middle one, which will get the current value of that
memory location whether the comparison succeeded or not. That means the CMP
instruction on the next line is superfluous, since it'll set the flags to
exactly what they are already set to. That means this particular example could
be written:
movl$1, %edx
cmpzxadd%edx, %esi, (%rdi)
sete%al
ret
Saving 2 retire slots and 1 uop. This can be done every time the result of the
intrinsic is compared to the same value that was passed as the intrinsic's
second parameter.
However, in a real workload, this function is likely to be inlined, where the
extra MOV may not be present at all and the CMP is likely to be followed by a
Jcc instead of a SETcc. For the latter case, the CMP+Jcc would be macro-fused,
so there would be no 1-uop gain. Moreover, this atomic operation is likely
going to be multiple cycles long and the conditional code after it probably
can't be speculated very well either.
I'll leave it up to you to decide whether it's worth pursuing this.
[Bug middle-end/110590] New: Failing CFG consistency testcases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110590 Bug ID: 110590 Summary: Failing CFG consistency testcases Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- there are 3 testcases that checks for Invalid sum but fogets to enable blocks-details which fails after this is fixed: gcc.dg/tree-ssa/loop-ch-profile-1.c here the problem is that loop header dulication introduces loop invariant conditoinal that is later updated by tree-ssa-dom but dom does not take care of updating profile. Since loop-ch knows when it duplicates loop invariant, we may be able to get this right. The test is still useful since it tests that right after ch profile is consistent. gcc.dg/tree-prof/update-cunroll-2.c This is about profile updating code in duplicate_loop_body_to_header_edge being wrong when optimized out exit is not last in the loop. In that case the probability of later exits needs to be accounted in. I will think about making this better - in general this does not seem to have easy solution, but for special case of chained tests we can definitely account for the later exits. gcc.dg/tree-ssa/update-unroll-1.c This fails after aprefetch invoked unrolling. I did not look into details yet.
[Bug target/86005] [RISCV] Invalid intermixing of __atomic_* libcalls and inline atomic instruction sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005
Patrick O'Neill changed:
What|Removed |Added
CC||patrick at rivosinc dot com
--- Comment #11 from Patrick O'Neill ---
The Char example from this issue is resolved on trunk since we added inline
subword atomics.
https://inbox.sourceware.org/gcc-patches/20230418214124.2446642-1-patr...@rivosinc.com/
Char example: https://godbolt.org/z/h94PT7hfo
char atomic(char *i) {
char j = __atomic_add_fetch(i, 1, __ATOMIC_SEQ_CST);
char k;
__atomic_load(i, , __ATOMIC_SEQ_CST);
return j+k;
}
options: -O3 -march=rv64iad
atomic(char*):
andia4,a0,3
slliw a4,a4,3
li a3,255
sllwa3,a3,a4
li a1,1
andia2,a0,-4
not a6,a3
sllwa1,a1,a4
1:
lr.w.aqrl a5, 0(a2)
add a7, a5, a1
and a7, a7, a3
and t1, a5, a6
or t1, t1, a7
sc.w.rl a7, t1, 0(a2)
bneza7, 1b
srawa5,a5,a4
addiw a5,a5,1
andia5,a5,0xff
fence rw,rw
lbu a0,0(a0)
fence rw,rw
add a0,a0,a5
andia0,a0,0xff
ret
The initial example's behavior is still present.
[Bug tree-optimization/110589] New: Missed optimization with call-clobbered restrict qualified references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110589
Bug ID: 110589
Summary: Missed optimization with call-clobbered restrict
qualified references
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: javier.martinez.bugzilla at gmail dot com
Target Milestone: ---
I see this on GCC trunk and do not think it is a regression, the optimization
is being taken by Clang.
https://godbolt.org/z/G8qrzaKn9
extern void foo(void);
int test_clobber_by_call (int * restrict val_ptr) {
*val_ptr = 1;
foo();
return *val_ptr;
}
GCC 14.0 -O3 produces:
test_clobber_by_call:
pushrbx
mov rbx, rdi
mov BYTE PTR [rdi], 1
callfoo
movzx eax, BYTE PTR [rbx] ; <--- Not expected
pop rbx
ret
I would expect restrict to be a guarantee that foo() will not alias val_ptr,
producing:
test_clobber_by_call:
mov DWORD PTR [rdi], 1
callfoo
mov eax, 1
ret
This is indeed the output when the compiler recognizes that foo does not alias,
as in:
__attribute((noinline)) void foo(int *a) {
*(a+10) = 0;
}
int test_clobber_by_call (int * val_ptr) {
*val_ptr = 1;
foo(val_ptr);
return *val_ptr;
}
-
It looks to me as if tree-ssa-alias.c#call_may_clobber_ref_p is not considering
a restrict qualified reference.
The following patch produces optimized code for the above example. I do not
claim that it is correct, but it does reflect what I expected to see:
diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
index c3f43dc..277a21e 100644
--- a/gcc/tree-ssa-alias.c
+++ b/gcc/tree-ssa-alias.c
@@ -3037,6 +3037,16 @@ call_may_clobber_ref_p_1 (gcall *call, ao_ref *ref, bool
tbaa_p)
&& SSA_NAME_POINTS_TO_READONLY_MEMORY (TREE_OPERAND (base, 0)))
return false;
+ /* perhaps should be moved further up */
+ if ((TREE_CODE (base) == MEM_REF
+ || TREE_CODE (base) == TARGET_MEM_REF)
+ && TREE_CODE(TREE_OPERAND (base, 0)) == SSA_NAME)
+{
+ struct ptr_info_def *pi = SSA_NAME_PTR_INFO (TREE_OPERAND (base, 0));
+ if (pi && pi->pt.vars_contains_restrict)
+return false;
+}
+
if (int res = check_fnspec (call, ref, true))
{
if (res == 1)
test_clobber_by_call:
sub rsp, 8
mov BYTE PTR [rdi], 1
callmay_alias
mov eax, 1 ; <- deref gone
add rsp, 8
ret
[Bug rtl-optimization/51041] register allocation of SSE register in loop with across eh edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51041 --- Comment #4 from Vladimir Makarov --- I believe it is the same problem as PR110215 which was solved recently by checking whether pseudo values are used in the exception handler and the handler does not return control flow back to the function code. So I guess this problem was solved too.
[Bug target/110559] Bad mask_load/mask_store codegen of RVV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110559 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-07-07 Ever confirmed|0 |1 --- Comment #2 from Jeffrey A. Law --- Yea, we definitely want pressure sensitive scheduling. While it's more valuable for scalar cases, it can help with some vector as well. Also note there's two variants of the pressure sensitive scheduler support. I think we use the newer one which is supposed to be better, but I don't think we've really evaluated one over the other. Setting issue rate to 1 for the first pass scheduler is a bit of a hack, though not terribly uncommon. It's something I've wanted to go back and review, so fully support you digging into that as well.
[Bug target/110559] Bad mask_load/mask_store codegen of RVV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110559 --- Comment #1 from Robin Dapp --- This can be improved in parts by enabling register-pressure aware scheduling. The rest is due to the default issue rate of 1. Setting proper instruction latency will then obviously cause a bit more reordering but my tests haven't shown a lot of additional spilling. I'm going to set the scheduler options in a patch next week.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 Jakub Jelinek changed: What|Removed |Added Attachment #55482|0 |1 is obsolete|| --- Comment #75 from Jakub Jelinek --- Created attachment 55499 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55499=edit gcc14-bitint-wip.patch Cast fixes, now it passes the whole testsuite.
[Bug rtl-optimization/110372] [14 Regression] ICE: insn does not satisfy its constraints: {*movdi_internal} with -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110372 --- Comment #3 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:1f7e5a7b91862b999aab88ee0319052aaf00f0f1 commit r14-2380-g1f7e5a7b91862b999aab88ee0319052aaf00f0f1 Author: Vladimir N. Makarov Date: Fri Jul 7 09:53:38 2023 -0400 LRA: Refine reload pseudo class For given testcase a reload pseudo happened to occur only in reload insns created on one constraint sub-pass. Therefore its initial class (ALL_REGS) was not refined and the reload insns were not processed on the next constraint sub-passes. This resulted into the wrong insn. PR rtl-optimization/110372 gcc/ChangeLog: * lra-assigns.cc (assign_by_spills): Add reload insns involving reload pseudos with non-refined class to be processed on the next sub-pass. * lra-constraints.cc (enough_allocatable_hard_regs_p): New func. (in_class_p): Use it. (print_curr_insn_alt): New func. (process_alt_operands): Use it. Improve debug info. (curr_insn_transform): Use print_curr_insn_alt. Refine reload pseudo class if it is not refined yet. gcc/testsuite/ChangeLog: * gcc.target/i386/pr110372.c: New.
[Bug bootstrap/54179] please split insn-emit.c !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #34 from mmokrejs at gmail dot com --- Thank you all. Just to clarify https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179#c31 , I did not show the Oom error itself nor the cmd killed dut to that but you can see details at https://bugs.gentoo.org/show_bug.cgi?id=909766 . I shouldn't have run just "make" but properly letting bootsrap procedure to continue, which I do not know how to. And that triggered the comparison error I assume. I used to have only 1GB RAM available in the virtual machine btw. and I always had to get around somehow the bootstrapping issue.
[Bug tree-optimization/110311] [14 Regression] regression in tree-optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311 --- Comment #49 from Jürgen Reuter --- (In reply to anlauf from comment #48) > (In reply to anlauf from comment #47) > > However, when I use -O2 together with an -march= flag, the code works. > > I've tested -march=sandybridge, -march=haswell, -march=skylake, > > -march=native. > > It FPEs without. > > And it FPEs with core2,nehalem,westmere! > > Next I tried: > > -march=sandybridge -mno-avx # FPE! > -march=sandybridge # OK. Yes, I can fully confirm your findings, also the ones from comment #47. I was looking at the commits in the period June 12-18 which could have caused this, some which seem potential candidates are: 2023-06-18 Honza PR tree-optimization/109849 2023-06-16 Jakub Jelinek PR tree-optimization/110271 * tree-ssa-math-opts.cc (math_opts_dom_walker::after_dom_children) : Ignore return value from match_arith_overflow, instead call match_uaddc_usubc only if gsi_stmt (gsi) is still stmt. (This one sounds pretty suspicious to me) 2023-06-16 Richard Biener PR tree-optimization/110269 * fold-const.cc (fold_binary_loc): Merge x != 0 folding 2023-06-13 Alexandre Oliva * range-op-float.cc (frange_nextafter): Drop inline. (frelop_early_resolve): Add static. (frange_float): Likewise 2023-06-12 Andrew MacLeod PR tree-optimization/110205 * range-op-float.cc (range_operator::fold_range): Add default FII fold routine. * range-op-mixed.h (class operator_gt): Add missing final overrides. * range-op.cc (range_op_handler::fold_range): Add RO_FII case. 2023-06-12 Andrew MacLeod * gimple-range-gori.cc (gori_compute::condexpr_adjust): Do not pass type. [...] (there is a long list of commits by Andrew on June 12) 2023-06-12 Andre Vieira PR middle-end/110142 * tree-vect-patterns.cc (vect_recog_widen_op_pattern): Don't pass subtype to vect_widened_op_tree and remove subtype parameter, also remove superfluous overloaded function definition. (vect_recog_widen_plus_pattern): Remove subtype parameter and dont pass to call to vect_recog_widen_op_pattern. (vect_recog_widen_minus_pattern): Likewise. (^^^ this one also looks suspicious to me) Any ideas which could have caused the changes?
[Bug tree-optimization/110392] [13 Regression] ICE at -O3 with "-O3 -Wall -fno-tree-vrp -fno-tree-dominator-opts -fno-tree-copy-prop -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop": in find_var_cmp_co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110392 --- Comment #5 from CVS Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:980666fbaf24f444a4cc7e78eb19aae00f296fdb commit r13-7544-g980666fbaf24f444a4cc7e78eb19aae00f296fdb Author: Richard Biener Date: Mon Jun 26 11:21:43 2023 +0200 tree-optimization/110392 - ICE with predicate analysis Feeding not optimized IL can result in predicate normalization to simplify things so a predicate can get true or false. The following re-orders the early exit in that case to come after simplification and normalization to take care of that. PR tree-optimization/110392 * gimple-predicate-analysis.cc (uninit_analysis::is_use_guarded): Do early exits on true/false predicate only after normalization. (cherry picked from commit ab6eac20f00761695c69b555f6b0a026bc25770d)
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #97 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #96)
>
> Not really. 'expand_ashiftrt' could emit
>
> mov #imm, r1
> shad r1, r0
>
> and 'mov' instruction would be loop invariant if there's a loop. It looks
> like 'ashrsi3_libcall_expanded' is a bad name. I think name
> 'ashrsi3_n_call_expanded' would be more appropriate.
Ah, yes, indeed. I'm cleaning up your patch and will rename it.
>
> > However, there is one case from your previous posts in PR 49263:
> >
> > int f_rshift(char v){
> > return v >> S;
> > }
> >
> > This will not work on SH2 and expand to a libcall.
>
> I think you mean SH2A, because the same is going on with SH4.
>
> > On SH4 the combine pass
> > converts it into:
> >
> > Successfully matched this instruction:
> > (set (reg:SI 166)
> > (ashiftrt:SI (reg/v:SI 164 [ v ])
> > (const_int 31 [0x1f])))
> >
> > But it doesn't even try to do so with the 'ashrsi3_n_call' pattern. Not
> > sure why ...
>
> Well, the same thing is going on when using vanilla GCC. It looks like it's
> happening due to char sign extension. Then instruction is catched by
> 'ashrsi2_31' pattern. In another words, it looks to me like an optimization.
It can be fixed by adding another pattern. I'll make another patch for that
later.
[Bug middle-end/110316] [11/12/13/14 Regression] g++.dg/ext/timevar1.C and timevar2.C fail erratically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110316 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #2 from Richard Biener --- GCC 10 branch is being closed.
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 Bug 84402 depends on bug 54179, which changed state. Bug 54179 Summary: please split insn-emit.c ! https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX |---
[Bug rtl-optimization/110079] [11/12/13/14 Regression] ICE with -freorder-blocks-and-partition and inline-asm goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110079 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #3 from Richard Biener --- GCC 10 branch is being closed.
[Bug c++/109918] [11/12/13/14 Regression] Unexpected -Woverloaded-virtual with virtual conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109918 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #2 from Richard Biener --- GCC 10 branch is being closed.
[Bug tree-optimization/110556] [12 Regression] division of INT_MIN and -1 happening incorrectly with -fno-delete-dead-exceptions -fnon-call-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110556 --- Comment #13 from CVS Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:45e950b542ca598eb8a4a69305fdd96dcb603353 commit r13-7546-g45e950b542ca598eb8a4a69305fdd96dcb603353 Author: Richard Biener Date: Thu Jul 6 13:51:55 2023 +0200 tree-optimization/110556 - tail merging still pre-tuples The stmt comparison function for GIMPLE_ASSIGNs for tail merging still looks like it deals with pre-tuples IL. The following attempts to fix this, not only comparing the first operand (sic!) of stmts but all of them plus also compare the operation code. PR tree-optimization/110556 * tree-ssa-tail-merge.cc (gimple_equal_p): Check assign code and all operands of non-stores. * gcc.dg/torture/pr110556.c: New testcase. (cherry picked from commit 7b16686ef882ab141276f0e36a9d4ce1d755f64a)
[Bug c++/109823] [11/12/13/14 Regression] ICE with trailing return of decltype of a fold expression in nested generic variadic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109823 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #3 from Richard Biener --- GCC 10 branch is being closed.
[Bug middle-end/110515] [12 Regression] llvm-15.0.7 possibly invalid code on -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110515 --- Comment #14 from CVS Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:0d20f9dbbd69a9bf43a6324128d8c08175e6eab6 commit r13-7545-g0d20f9dbbd69a9bf43a6324128d8c08175e6eab6 Author: Richard Biener Date: Wed Jul 5 15:57:49 2023 +0200 tree-optimization/110515 - wrong code with LIM + PRE In this PR we face the issue that LIM speculates a load when hoisting it out of the loop (since it knows it cannot trap). Unfortunately this exposes undefined behavior when the load accesses memory with the wrong dynamic type. This later makes PRE use that representation instead of the original which accesses the same memory location but using a different dynamic type leading to a wrong disambiguation of that original access against another and thus a wrong-code transform. Fortunately there already is code in PRE dealing with a similar situation for code hoisting but that left a small gap which when fixed also fixes the wrong-code transform in this bug even if it doesn't address the underlying issue of LIM speculating that load. The upside is this fix is trivially safe to backport and chances of code generation regressions are very low. PR tree-optimization/110515 * tree-ssa-pre.cc (compute_avail): Make code dealing with hoisting loads with different alias-sets more robust. * g++.dg/opt/pr110515.C: New testcase. (cherry picked from commit 9f4f833455bb35c11d03e93f802604ac7cd8b740)
[Bug tree-optimization/110381] [11/12 Regression] double counting for sum of structs of floating point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381 --- Comment #21 from CVS Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:32c7f05f8bc6d45dee374fe22be3f0e19836278a commit r13-7543-g32c7f05f8bc6d45dee374fe22be3f0e19836278a Author: Richard Biener Date: Mon Jun 26 12:51:37 2023 +0200 tree-optimization/110381 - preserve SLP permutation with in-order reductions The following fixes a bug that manifests itself during fold-left reduction transform in picking not the last scalar def to replace and thus double-counting some elements. But the underlying issue is that we merge a load permutation into the in-order reduction which is of course wrong. Now, reduction analysis has not yet been performend when optimizing permutations so we have to resort to check that ourselves. PR tree-optimization/110381 * tree-vect-slp.cc (vect_optimize_slp_pass::start_choosing_layouts): Materialize permutes before fold-left reductions. * gcc.dg/vect/pr110381.c: New testcase. (cherry picked from commit 53d6f57c1b20c6da52aefce737fb7d5263686ba3)
[Bug c++/108975] [11 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #18 from Richard Biener --- GCC 10 branch is being closed.
[Bug middle-end/108042] [11/12/13/14 Regression] weakref on an extern decl is incorrectly ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108042 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #3 from Richard Biener --- GCC 10 branch is being closed.
[Bug ada/107475] [11/12/13/14 Regression] libgnat fails to link libgnat.so on systems with older glibc on x86_64-linux-gnux32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107475 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #3 from Richard Biener --- GCC 10 branch is being closed.
[Bug middle-end/107443] [11/12/13/14 Regression] Removing switch with __builtin_unreachable causes missed optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107443 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #3 from Richard Biener --- GCC 10 branch is being closed.
[Bug fortran/107397] [11/12 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #13 from Richard Biener --- GCC 10 branch is being closed.
[Bug c++/107321] [11/12/13/14 Regression] ICE in strip_array_types, at tree.cc:7284 since r10-4397-gb7689b962dd6536b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107321 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #2 from Richard Biener --- GCC 10 branch is being closed.
[Bug tree-optimization/110582] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110582
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
CC||amacleod at redhat dot com
--- Comment #2 from Richard Biener ---
It works with -fno-tree-loop-optimize but the difference from loop opts is just
int main ()
{
int D.2782;
int b_lsm.13;
int a_lsm.12;
char c;
- unsigned char c.6_2;
- unsigned char _3;
int iftmp.1_11;
int _12(D);
int iftmp.1_15;
+ unsigned char ivtmp_36;
+ unsigned char ivtmp_37;
int _38;
long int _39;
long int _40;
@@ -23,8 +21,8 @@
[local count: 10737416]:
[local count: 1063004409]:
- # c_21 = PHI
# a_lsm.12_4 = PHI
+ # ivtmp_37 = PHI
if (a_lsm.12_4 != 0)
goto ; [50.00%]
else
@@ -35,10 +33,8 @@
[local count: 1063004409]:
# iftmp.1_11 = PHI
- c.6_2 = (unsigned char) c_21;
- _3 = c.6_2 + 1;
- c_18 = (char) _3;
- if (c_18 != -3)
+ ivtmp_36 = ivtmp_37 - 1;
+ if (ivtmp_36 != 0)
goto ; [98.99%]
else
with that indeed threadfull2 miscompiles this somehow. Andrew?
[Bug tree-optimization/107176] [11/12 Regression] Wrong code at -Os on x86_64-pc-linux-gnu since r7-2012-g43aabfcfd4139e4c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107176 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #11 from Richard Biener --- GCC 10 branch is being closed.
[Bug middle-end/106982] [11 Regression][OpenACC] ICE incorrect sharing of tree nodes with nested reduction / .GOACC_REDUCTION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106982 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #4 from Richard Biener --- GCC 10 branch is being closed.
[Bug debug/106399] [11/12/13/14 Regression] Wrong debug info for function with nested function under O0 since r9-1284-gd70ba0c10dec6968
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106399 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #7 from Richard Biener --- GCC 10 branch is being closed.
[Bug rtl-optimization/105988] [11/12/13/14 Regression] ICE in linemap_ordinary_map_lookup, at libcpp/line-map.cc:1064 since r6-4873-gebedc9a3414d8422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105988 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #8 from Richard Biener --- GCC 10 branch is being closed.
[Bug fortran/106692] [11/12/13/14 Regression] Cray pointer comparison wrongly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106692 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #6 from Richard Biener --- GCC 10 branch is being closed.
[Bug ipa/105917] [11/12/13/14 regression] Missed passthru jump function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105917 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #4 from Richard Biener --- GCC 10 branch is being closed.
[Bug c++/105838] [11/12 Regression] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #24 from Richard Biener --- GCC 10 branch is being closed.
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #96 from Alexander Klepikov
---
(In reply to Oleg Endo from comment #95)
> The infinite loop is in splitting of the 'ashrsi3_n_call' pattern with the
> constant 1. This is because 'ashrsi3_n_call' match overlaps with the 'shar'
> pattern.
Yes, I confirm that. 'operands[2] != const1_rtx' works well, thank you!
> Another point is that you had the
> 'cfun->machine->ashrsi3_libcall_expanded++;' in the wrong place. It was
> counting up even if it wouldn't have emitted the libcall.
Not really. 'expand_ashiftrt' could emit
mov #imm, r1
shad r1, r0
and 'mov' instruction would be loop invariant if there's a loop. It looks like
'ashrsi3_libcall_expanded' is a bad name. I think name
'ashrsi3_n_call_expanded' would be more appropriate.
> However, there is one case from your previous posts in PR 49263:
>
> int f_rshift(char v){
> return v >> S;
> }
>
> This will not work on SH2 and expand to a libcall.
I think you mean SH2A, because the same is going on with SH4.
> On SH4 the combine pass
> converts it into:
>
> Successfully matched this instruction:
> (set (reg:SI 166)
> (ashiftrt:SI (reg/v:SI 164 [ v ])
> (const_int 31 [0x1f])))
>
> But it doesn't even try to do so with the 'ashrsi3_n_call' pattern. Not
> sure why ...
Well, the same thing is going on when using vanilla GCC. It looks like it's
happening due to char sign extension. Then instruction is catched by
'ashrsi2_31' pattern. In another words, it looks to me like an optimization.
[Bug tree-optimization/110386] [11/12/13/14 Regression] ICE with ABSU in backprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110386 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #5 from Richard Biener --- GCC 10 branch is being closed.
[Bug c++/105742] [11/12/13/14 Regression] accepts-invalid non-dependent call to non-static member function from unrelated class in presence of dependent base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105742 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #4 from Richard Biener --- GCC 10 branch is being closed.
[Bug c++/110295] [11/12 Regression] ICE in dwarf2out_finish with local class with inherited operator delete in a templated function and -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110295 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #7 from Richard Biener --- GCC 10 branch is being closed.
[Bug rtl-optimization/105653] [11/12/13/14 Regression] '-fcompare-debug' failure w/ -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105653 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #4 from Richard Biener --- GCC 10 branch is being closed.
[Bug middle-end/110294] [11 Regression] Segmentation fault with '-O3 -fno-dce -fno-toplevel-reorder -fno-tree-dce -fno-tree-pta -fno-tree-sink -ftoplevel-reorder'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110294 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #5 from Richard Biener --- GCC 10 branch is being closed.
[Bug middle-end/105630] [11/12 Regression] '-fcompare-debug' failure w/ -O1 -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105630 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #5 from Richard Biener --- GCC 10 branch is being closed.
[Bug c/110238] [11/12/13/14 Regression] Incorrect "comparison between pointer and zero character constant" warning when comparing pointer to unsigned null pointer constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110238 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #2 from Richard Biener --- GCC 10 branch is being closed.
[Bug rtl-optimization/105453] [11 Regression] load introduced by ce1 for conditional loads at -O1, might cause issues with the C/C++ memory model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105453 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #8 from Richard Biener --- GCC 10 branch is being closed.
[Bug analyzer/109432] [meta-bug] tracker bug for issues with -Wanalyzer-out-of-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109432 Bug 109432 depends on bug 109439, which changed state. Bug 109439 Summary: RFE: Spurious -Wanalyzer-use-of-uninitialized-value tagging along -Wanalyzer-out-of-bounds https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109439 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/105452] [11/12/13/14 Regression] static_assert inside anonymous union inside a templated struct causes invalid "inaccessible within this context" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105452 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #7 from Richard Biener --- GCC 10 branch is being closed.
[Bug analyzer/109439] RFE: Spurious -Wanalyzer-use-of-uninitialized-value tagging along -Wanalyzer-out-of-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109439 Benjamin Priour changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Benjamin Priour --- Resolved as part of the above patch.
[Bug c++/105244] [11/12/13/14 Regression] ICE in implicitly_declare_fn, at cp/method.cc:3114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105244 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #5 from Richard Biener --- GCC 10 branch is being closed.
[Bug tree-optimization/109960] [11/12/13/14 Regression] missing combining of `(a&1) != 0 || (a&2)!=0` into `(a&3)!=0`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109960 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #6 from Richard Biener --- GCC 10 branch is being closed.
[Bug c/105180] [11/12/13/14 Regression] K style definition does not evaluate array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105180 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #8 from Richard Biener --- GCC 10 branch is being closed.
[Bug middle-end/109967] [11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #5 from Richard Biener --- GCC 10 branch is being closed.
[Bug fortran/105168] [11/12/13/14 Regression] ICE in gfc_maybe_dereference_var, at fortran/trans-expr.cc:2870 since r9-3522-gd0477233215e37de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105168 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #5 from Richard Biener --- GCC 10 branch is being closed.
[Bug tree-optimization/109925] [11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu since GCC-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109925 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #3 from Richard Biener --- GCC 10 branch is being closed.
[Bug c/105149] [11 Regression] ICE in verify_ssa, at tree-ssa.cc:1211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105149 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #13 from Richard Biener --- GCC 10 branch is being closed.
[Bug c++/109876] [11/12/13/14 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #12 from Richard Biener --- GCC 10 branch is being closed.
[Bug middle-end/105126] [11/12/13/14 Regression] Optimization regression gcc inserts not needed movsx when using switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105126 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #6 from Richard Biener --- GCC 10 branch is being closed.
[Bug rtl-optimization/104989] [11 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.cc:2797 (error: flow control insn inside a basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104989 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #9 from Richard Biener --- GCC 10 branch is being closed.
[Bug c++/109381] [11/12/13/14 Regression] Ambiguous member lookup with this-> accepted when it should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109381 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #3 from Richard Biener --- GCC 10 branch is being closed.
[Bug tree-optimization/110392] [13 Regression] ICE at -O3 with "-O3 -Wall -fno-tree-vrp -fno-tree-dominator-opts -fno-tree-copy-prop -fno-tree-fre -fno-tree-ccp -fno-tree-forwprop": in find_var_cmp_co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110392 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to work||13.1.1 Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug rtl-optimization/104961] [11 Regression] compilation never (?) finishes at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104961 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #7 from Richard Biener --- GCC 10 branch is being closed.
[Bug tree-optimization/109184] [11/12/13/14 Regression] csmith: 2017 bug with -floop-interchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109184 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #14 from Richard Biener --- GCC 10 branch is being closed.
[Bug target/108933] [11/12/13/14 Regression] Missing rev16 detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108933 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #4 from Richard Biener --- GCC 10 branch is being closed.
[Bug bootstrap/54179] please split insn-emit.c !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #33 from Tamar Christina --- (In reply to Sam James from comment #32) > I'll tentatively reopen as IIRC tamar mentioned they've had some ideas about > this, apologies if I'm misremembering. Hello, yes I have a patch locally that I need to finish (there's a lot of gen- machinery). I'll try to get it upstream soon :)
[Bug tree-optimization/110176] [11/12/13/14 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #5 from Richard Biener --- GCC 10 branch is being closed.
[Bug c++/109958] [11/12/13/14 Regression] ICE: in build_ptrmem_type, at cp/decl.cc:11066 taking the address of bound static member function brought into derived class by using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109958 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #4 from Richard Biener --- GCC 10 branch is being closed.
[Bug fortran/104717] [11 Regression] ICE: verify_ssa failed (Error: type mismatch between an SSA_NAME and its symbol)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104717 Richard Biener changed: What|Removed |Added Target Milestone|10.5|11.5 --- Comment #13 from Richard Biener --- GCC 10 branch is being closed.
