https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #13 from JuzheZhong ---
Ok. I found the optimized tree:
_5 = 3.33314829616256247390992939472198486328125e-1 - _4;
_8 = .FMA (_5, 1.229982236431605997495353221893310546875e-1, _4);
Let CST0 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
--- Comment #1 from Jonathan Wakely ---
Using #include definitely won't work, that would just create a cycle between
the libstdc++ versions of stdlib.h and cstdlib, at least for all targets that
don't have stdlib.h in include-fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113796
Andrew Pinski changed:
What|Removed |Added
Target|riscv aarch64 |
Summary|[14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113796
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> ifcvt needs to something similar to what phiopt did in
> r14-2650-g8c79b49cd4fa74 .
Or ifcvt needs to remove the range info earlier ...
I have not looked into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113796
--- Comment #3 from Andrew Pinski ---
Just an FYI :
[apinski@xeond2 upstream-full-cross]$ ./install/bin/aarch64-linux-gnu-gcc -O2
-static t65.c -march=armv9-a+sve2 -fno-vect-cost-model
[apinski@xeond2 upstream-full-cross]$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113796
Andrew Pinski changed:
What|Removed |Added
Target|riscv |riscv aarch64
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113796
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113795
keithp at keithp dot com changed:
What|Removed |Added
Version|13.2.1 |14.0
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113796
Bug ID: 113796
Summary: [14] RISC-V rv64gcv vector: Runtime mismatch at -O2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113795
--- Comment #1 from keithp at keithp dot com ---
compiler command:
arm-none-eabi-gcc \
-std=c18 \
-O2 \
-mthumb \
-march=armv8.1-m.main+pacbti+fp \
-mbranch-protection=standard \
-o \
bar.s \
-S \
bar.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113795
Bug ID: 113795
Summary: armv8.1m-m.main+pacbti -mbranch-protection=standard
-O2 compile error
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
--- Comment #6 from Arthur O'Dwyer ---
(In reply to Marek Polacek from comment #5)
> IOW, this should be accepted in C++23 but isn't (clang++ accepts in C++23):
> [...]
Correct, at least that's my intended interpretation. But the unexpected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #12 from JuzheZhong ---
Ok. I found it even without vectorization:
GCC is worse than Clang:
https://godbolt.org/z/addr54Gc6
GCC (14 instructions inside the loop):
fld fa3,0(a0)
fld fa5,8(a0)
fld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113731
Sam James changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113794
Sam James changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113794
Bug ID: 113794
Summary: [14 Regression] building the amdgcn-amdhsa offload
compiler fails building newlib
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103910
Alejandro Colomar changed:
What|Removed |Added
CC||alx at kernel dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113766
--- Comment #2 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:db5c3f6d952bc3950d23c0a6be4e8ec9147ef752
commit r14-8834-gdb5c3f6d952bc3950d23c0a6be4e8ec9147ef752
Author: Pan Li
Date: Tue Feb 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492
--- Comment #18 from Li Pan ---
Thanks for the confirmation.
Yes, it was before expand. I will prepare one PATCH for this, and it should
target for gcc-15 I bet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113791
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113791
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545
Hans-Peter Nilsson changed:
What|Removed |Added
Status|ASSIGNED|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545
--- Comment #1 from Hans-Peter Nilsson ---
There's a test-suite patch at
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643667.html which is
currently in review-ping limbo.
I'm unassigning myself from this PR. I won't work on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113793
Bug ID: 113793
Summary: malloc abort on character allocate with source
argument
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
--- Comment #5 from Marek Polacek ---
IOW, this should be accepted in C++23 but isn't (clang++ accepts in C++23):
struct AutoPtr {
AutoPtr() = default;
AutoPtr(AutoPtr&) {}
};
template auto f(T p, int) -> decltype(throw p, 1) =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
--- Comment #4 from Marek Polacek ---
Um, that's not it. Since
struct AutoPtr {
AutoPtr() = default;
AutoPtr(AutoPtr&) {}
};
template int
f (T p)
{
throw p;
}
void
g ()
{
f (AutoPtr ());
}
is rejected in C++23, we probably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
Bug ID: 113792
Summary: error: '__size_t' was not declared in this scope
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #25 from Andrew Pinski ---
PK_FinalTemplate constructor is doing:
this->AccessKey()
Where AccessKey is virtual function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744
--- Comment #11 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #10)
> As discussed on IRC, probably the
> if (!__builtin_mul_overflow(__l._M_lo, __x, &__lo))
> optimization isn't a good idea, because most likely the compiler will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492
--- Comment #17 from Tamar Christina ---
(In reply to Li Pan from comment #16)
> I have a try like below and finally have the Standard Name "SAT_ADD". Could
> you please help to double-check if my understanding is correct?
>
> Given below
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744
--- Comment #9 from Jonathan Wakely ---
Oops yes!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744
--- Comment #8 from Jakub Jelinek ---
if (!__l._M_hi)
{
__l._M_lo %= __m;
return __l;
}
auto __n = __l._M_hi ? __builtin_clzll(__l._M_hi)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744
Jonathan Wakely changed:
What|Removed |Added
Attachment #57346|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
Andrew Pinski changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744
--- Comment #6 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #4)
> Why not just
> __l._M_hi += __builtin_uaddll_overflow(__l._M_lo, __c,
> &__l._M_lo);
> and similarly for subtraction?
No good reason - I'll change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744
Jonathan Wakely changed:
What|Removed |Added
Attachment #57345|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113791
Marek Polacek changed:
What|Removed |Added
Keywords|needs-reduction |rejects-valid
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:40485378ade83102d7aa30c317f5d6c90c1d232b
commit r14-8832-g40485378ade83102d7aa30c317f5d6c90c1d232b
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744
--- Comment #4 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #1)
> Created attachment 57345 [details]
> Use 64-bit integers to do 128-bit arithmetic
>
> This patch defines a custom type that implements the necessary 128-bit
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744
--- Comment #3 from Jonathan Wakely ---
Based on that, I'm not sure what libc++ does is actually better than what
libstdc++ does today (i.e. refuse to compile if the results would be wrong).
I think the patch above would make sense though. I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744
--- Comment #2 from Jonathan Wakely ---
(In reply to Lewis Fox from comment #0)
> libc++'s
> implementation of linear_congruential_engine (though libc++ incorrectly uses
> Schrage's method).
I haven't checked what libc++ actually does, but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87744
--- Comment #1 from Jonathan Wakely ---
Created attachment 57345
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57345=edit
Use 64-bit integers to do 128-bit arithmetic
This patch defines a custom type that implements the necessary 128-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113791
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
--- Comment #3 from Marek Polacek ---
I have a patch for the ICE (build_throw doesn't have a complain param so we
wind up with "error reporting routines re-entered").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #23 from Andrew Pinski ---
This might be a divirtualization issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113791
Bug ID: 113791
Summary: Incorrect handling of lvalue to rvalue conversion in
ternary operator
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #22 from Jonathan Wakely ---
Created attachment 57344
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57344=edit
Gzipped preprocessed source
With -O2 -fsantiize=unreachable this prints an error:
pubkey.h:2209:32: runtime
rithms: zlib zstd
gcc version 14.0.1 20240206 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
--- Comment #14 from Jonathan Wakely ---
(In reply to Jeffrey Walton from comment #13)
> Add a mee too. When using sanitizers, like -fsanitize=undefined, the
> compiler driver is not adding the necessary libraries to link the program.
That's a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113689
--- Comment #12 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:f2a060820c24724bb48ee006d257c449e4d94b72
commit r14-8831-gf2a060820c24724bb48ee006d257c449e4d94b72
Author: H.J. Lu
Date: Tue Feb 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113689
--- Comment #11 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #10)
>
> Just the second hunk. I think with sorry call the compilation fails, so what
> you actually emit doesn't matter (one can see it with -pipe, sure).
Done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113689
--- Comment #10 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #9)
> Like this?
>
> diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> index f02c6c02ac6..ed0b0e19985 100644
> --- a/gcc/config/i386/i386.cc
> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113689
--- Comment #9 from H.J. Lu ---
Like this?
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index f02c6c02ac6..ed0b0e19985 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -22785,10 +22785,10 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113689
--- Comment #8 from Jakub Jelinek ---
(In reply to Rainer Orth from comment #7)
> This patch broke Solaris/x86 (i386-pc-solaris2.11) bootstrap:
>
> /vol/gcc/src/hg/master/local/gcc/config/i386/i386.cc: In function 'void
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113689
Rainer Orth changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
Marek Polacek changed:
What|Removed |Added
Summary|ICE on P2266/C++23 |[13/14 Regression] ICE on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2024-02-06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101165
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106882
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #6 from Tamar Christina ---
The reason for the miscompile popping up is this change from the previous patch
diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
index 109d4ce5192..df3eab2e8d5 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
Bug ID: 113789
Summary: ICE on P2266/C++23 `decltype(throw x)` where x is
move-eligible parameter
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113678
--- Comment #3 from Andrew Pinski ---
Note the SLP that happens in connection with the loop vectorizer actually does
a decent job ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788
--- Comment #2 from Marek Polacek ---
Yes, seems that currently we only check that it's the first specifier:
/* Special case for "this" specifier, indicating a parm is an xobj parm.
The "this" specifier must be the first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788
--- Comment #1 from Jakub Jelinek ---
Seems it is far more cases where we allow it:
struct S { int a, b; };
struct U {
void foo () { this int g = 1; }
};
this auto h = 1;
int
main ()
{
S s = { 1, 2 };
short t[3] = { 3, 4, 5 };
this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113678
--- Comment #2 from Andrew Pinski ---
Noticed the same with:
```
void f(unsigned char *a, unsigned char *b, unsigned char *c)
{
unsigned char t[8];
t[0] = a[0];
t[1] = a[1];
t[2] = a[2];
t[3] = a[3];
t[4] = b[0];
t[5] = b[1];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2024-02-06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113677
--- Comment #4 from Andrew Pinski ---
Note it is not just about constants either.
Take:
```
#define vect64 __attribute__((vector_size(8) ))
#define vect128 __attribute__((vector_size(16) ))
vect128 unsigned int f(vect64 unsigned int a, vect64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94231
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94231
--- Comment #3 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:1befe47f64bf0b964be90730e2cbef550cb6d2b7
commit r14-8830-g1befe47f64bf0b964be90730e2cbef550cb6d2b7
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788
Bug ID: 113788
Summary: Deducing this is broken with structured binding
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113786
Jonathan Wakely changed:
What|Removed |Added
Blocks||87403
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #9 from Andrew Pinski ---
_57 = [(int *)0B + _56 + _55 * 1];
*_57 = _14;
The fix for PR 110702 must not have been enough.
Or rather this part of the explanation was fully true:
```
The patch below
recognizes the fallback
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113756
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113756
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113612
--- Comment #4 from Marek Polacek ---
It was freed here in duplicate_decls:
#1 0x012f535d in ggc_free (p=0x7fffea210e10) at
/home/mpolacek/src/gcc/gcc/ggc-page.cc:1630
#2 0x00e971b2 in duplicate_decls (newdecl=,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #8 from Jan Hubicka ---
I will take a look. Mod-ref only reuses the code detecting errneous paths in
ssa-split-paths, so that code will get confused, too. It makes sense for ivopts
to compute difference of two memory allocations,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113612
--- Comment #3 from Marek Polacek ---
(gdb) up
#1 0x01120e27 in get_partial_spec_bindings (tmpl=,
spec_tmpl=, args=)
at /home/mpolacek/src/gcc/gcc/cp/pt.cc:25888
25888 = TI_ARGS (get_template_info (DECL_TEMPLATE_RESULT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113612
Marek Polacek changed:
What|Removed |Added
Priority|P4 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112875
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #17 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:df9f6b934886f51c0c07220d1ee38874b69646c7
commit r14-8828-gdf9f6b934886f51c0c07220d1ee38874b69646c7
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99387
--- Comment #4 from Marek Polacek ---
This PR seems to have been fixed by r12-6773:
commit 09845ad7569bac27c3a1dc7b410d9df764d2ca06
Author: Patrick Palka
Date: Thu Jan 20 09:25:49 2022 -0500
c++: CTAD inside alias template [PR91911,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96090
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94231
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #7 from Alex Coplan ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > My bisection points to r12-5915-ge93809f62363ba4b233858005aef652fb550e896
>
> Which means it is related to bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #6 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #5)
> My bisection points to r12-5915-ge93809f62363ba4b233858005aef652fb550e896
Which means it is related to bug 110702 .
Again try -fno-ivopts . I suspect ivopts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-02-06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #4 from Alex Coplan ---
Same with the head of the GCC 12 branch, but I agree it isn't a [14 Regression]
as I can reproduce the issue with basepoints/gcc-14, so maybe something was
backported to 12/13 that is making it latent on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #3 from Alex Coplan ---
(In reply to Jakub Jelinek from comment #1)
> Why do you think it is a 14 Regression?
> Seems r12-5166 works fine while r12-6600 already doesn't, so that would make
> it [12/13/14 Regression], no?
Well on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86918
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #2 from Andrew Pinski ---
Also try -fno-ivopts .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
Bug ID: 113787
Summary: [14 Regression] Wrong code at -O with ipa-modref on
aarch64
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
1 - 100 of 159 matches
Mail list logo
