https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #44 from Kewen Lin ---
(In reply to Richard Biener from comment #43)
> (In reply to Richard Biener from comment #42)
> > I think this goes wrong in vectorizable_operation which does
> >
> > if (using_emulated_vectors_p
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #10 from Michael Hudson-Doyle
---
FWIW, I see a similar error on ppc64el with what looks like a similar cause. (I
also see other errors that do not go away with s/O3/O2/ so that might be
something slightly different).
O3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #9 from Michael Hudson-Doyle
---
I uploaded the object file with the bad code to
https://people.canonical.com/~mwh/e_j1f128.os.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106581
--- Comment #12 from Lance Fredrickson ---
I will send an email to their mailing list and inform them of this thread as
well. I've queried on buildroot mailing list and irc if anyone uses aarch64 +
uclibc-ng.
thanks for your attention and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #8 from Michael Hudson-Doyle
---
I just changed
z = xx * xx;
to
z = math_opt_barrier(xx * xx);
which perhaps isn't sufficient.
But my reading of the assembly is that the issue is that some of the math code
is being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106545
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at rivosinc dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106581
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106581
--- Comment #10 from Lance Fredrickson ---
(gdb) disassemble 0x7fb7eae3b8
Dump of assembler code for function (anonymous namespace)::get_global():
0x007fb7eae3b8 <+0>: stp x29, x30, [sp, #-16]!
0x007fb7eae3bc <+4>: mov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106581
--- Comment #9 from Andrew Pinski ---
disassemble 0x7fb7eae3b8
Which was:
0x007fb7eae3fc <+8>: bl 0x7fb7eae3b8 <(anonymous
namespace)::get_global()>
I am still trying to figure out how the TLS address was formed here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106581
--- Comment #8 from Lance Fredrickson ---
Here is 'info proc mappings'
(gdb) info proc mappings
process 16896
Mapped address spaces:
Start Addr End Addr Size Offset objfile
0x555000 0x556000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #7 from joseph at codesourcery dot com ---
I'd suggest looking at the generated assembly. I don't know exactly what
you mean by "putting a math_opt_barrier on this line"; it would need to be
used in a way that ensures a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106581
--- Comment #7 from Andrew Pinski ---
(In reply to Lance Fredrickson from comment #6)
> info mem gives
>
> (gdb) info mem
> Using memory regions provided by the target.
> There are no memory regions defined.
Sorry, I mean "info proc mappings"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106581
--- Comment #6 from Lance Fredrickson ---
info mem gives
(gdb) info mem
Using memory regions provided by the target.
There are no memory regions defined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106581
--- Comment #5 from Andrew Pinski ---
uclibc must have some ordering issue when it comes to atexit and shared
libraries and TLS.
Can you also do:
"info mem"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106581
--- Comment #4 from Lance Fredrickson ---
Here you go.
(gdb) info registers
x0 0xff6fea06f01097094268656
x1 0x7fb7ffa6c0548547831488
x2 0x0 0
x3 0x0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106581
--- Comment #3 from Andrew Pinski ---
(In reply to Lance Fredrickson from comment #2)
> Here is the disassemble
>
> (gdb) disassemble
> Dump of assembler code for function _ZSt18uncaught_exceptionv:
>0x007fb7eae2a8 <+0>: stp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106581
--- Comment #2 from Lance Fredrickson ---
Here is the disassemble
(gdb) disassemble
Dump of assembler code for function _ZSt18uncaught_exceptionv:
0x007fb7eae2a8 <+0>: stp x29, x30, [sp, #-16]!
0x007fb7eae2ac <+4>:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106581
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #6 from Michael Hudson-Doyle
---
Are there any tips as to how to diagnose this further? I tried putting a
math_opt_barrier on this line:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106581
Bug ID: 106581
Summary: [Aarch64] libstdc++ segfault at end of execution
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96786
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
--- Comment #15 from dave.anglin at bell dot net ---
On 2022-08-10 9:30 a.m., rguenth at gcc dot gnu.org wrote:
> hen I try with a cc1 cross I see
>
>> ./cc1 -quiet t.i -fpreprocessed -O2 -g -std=gnu11 -fgnu89-inline
>> -fmerge-all-constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96786
Erhard F. changed:
What|Removed |Added
CC||erhard_f at mailbox dot org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106061
Andrew Pinski changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106580
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106492
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Tobias Burnus
:
https://gcc.gnu.org/g:68b8c55c7e7de8438ea97f600cdccac826b8e67d
commit r12-8678-g68b8c55c7e7de8438ea97f600cdccac826b8e67d
Author: Tobias Burnus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106580
Bug ID: 106580
Summary: ICE with UBSan and -fsanitize-undefined-trap-on-error
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
--- Comment #14 from dave.anglin at bell dot net ---
On 2022-08-10 1:38 p.m., dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
>
> --- Comment #13 from dave.anglin at bell dot net ---
> On 2022-08-10 9:30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
Jakub Jelinek changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
--- Comment #13 from dave.anglin at bell dot net ---
On 2022-08-10 9:30 a.m., rguenth at gcc dot gnu.org wrote:
> You could try if -fno-tree-pre reproduces it also before the change.
It doesn't.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106576
--- Comment #1 from Thomas Koenig ---
There currently is a c.l.f. thread on this, with this test case.
Although what nagfor and xlf are doing makes sense, it does
not (to me) follow from the language of the standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106578
--- Comment #3 from Gökçe Aydos ---
> using 'tmp' instead makes it properly fire.
Dear Richard, maybe I misunderstood what you meant with *fire*. If `tmp` is
used then gcc does not *fire* any warning and works correctly, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
Bug ID: 106579
Summary: ieee_signaling_nan problem in fortran on powerpc64
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106571
--- Comment #5 from Boris ---
(In reply to Michael Matz from comment #4)
> Boris: what does DECLARE_PER_CPU() expand into? Are there other attributes
> that could be usefully checked for mismatch between decl and def?
Unfortunately,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #5 from joseph at codesourcery dot com ---
It's possible code is being moved across SET_RESTORE_ROUNDL, in which case
maybe math_opt_barrier needs to be used in glibc code to prevent that
movement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106506
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2022-08-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
--- Comment #12 from dave.anglin at bell dot net ---
On 2022-08-10 9:30 a.m., rguenth at gcc dot gnu.org wrote:
> When I try with a cc1 cross I see
>
>> ./cc1 -quiet t.i -fpreprocessed -O2 -g -std=gnu11 -fgnu89-inline
>> -fmerge-all-constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106578
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-08-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106513
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:ab2ca2dbd528f0564b80fa0e6eda96e0237742bc
commit r12-8677-gab2ca2dbd528f0564b80fa0e6eda96e0237742bc
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106513
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:f675afa4eeac9910a2c085a95aa04d6d9f2fd8d6
commit r13-2013-gf675afa4eeac9910a2c085a95aa04d6d9f2fd8d6
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106334
--- Comment #10 from CVS Commits ---
The releases/gcc-12 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:4769ac6c5dfde2810a0266fe388211edc644e623
commit r12-8676-g4769ac6c5dfde2810a0266fe388211edc644e623
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106540
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:4769ac6c5dfde2810a0266fe388211edc644e623
commit r12-8676-g4769ac6c5dfde2810a0266fe388211edc644e623
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106578
--- Comment #1 from Gökçe Aydos ---
FYI: [`realloc` behavior in the C11
standard](http://port70.net/~nsz/c/c11/n1570.html#7.22.3.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106578
Bug ID: 106578
Summary: spurious -Wuse-after-free=2 after conditional free()
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106570
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106524
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106514
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-08-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106513
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106147
--- Comment #3 from David Malcolm ---
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106203#c1 (w.r.t possible
revamp of how source locations are tracked in the analyzer, given that an
infinite loop might not contain any statements)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106203
--- Comment #1 from David Malcolm ---
I've been prototyping an implementation of PR 106147 (infinite loop detection),
and in some cases there aren't any statements at all for my warnings, just
location_t values (if that). So as part of that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101839
--- Comment #10 from Jan Hubicka ---
Created attachment 53430
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53430=edit
Patch I am testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106513
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
--- Comment #11 from Richard Biener ---
The dump difference is easily explained by taming PRE when -ftree-vectorize is
on, it's not a "real" difference.
When I try with a cc1 cross I see
> ./cc1 -quiet t.i -fpreprocessed -O2 -g -std=gnu11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101839
--- Comment #9 from Jan Hubicka ---
Thanks for looking into this.
What happens here is that we start working from a call where we know that
outer_type is BA. We correctly find the BA::type and notice that it is final
and thus we do not need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106395
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-08-10
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106369
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106577
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106328
--- Comment #10 from rguenther at suse dot de ---
On Wed, 10 Aug 2022, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106328
>
> --- Comment #9 from Martin Liška ---
> > Magically only with recent GNU make,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106328
--- Comment #9 from Martin Liška ---
> Magically only with recent GNU make, otherwise needs proper prefixed
> rules in the lto-wrapper generated makefile which I don't think we do.
Wait, the cooperation works with older GNU make if a Makefile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106328
--- Comment #8 from rguenther at suse dot de ---
On Wed, 10 Aug 2022, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106328
>
> Martin Liška changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #43 from Richard Biener ---
(In reply to Richard Biener from comment #42)
> I think this goes wrong in vectorizable_operation which does
>
> if (using_emulated_vectors_p
> && !vect_can_vectorize_without_simd_p (code))
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #42 from Richard Biener ---
I think this goes wrong in vectorizable_operation which does
if (using_emulated_vectors_p
&& !vect_can_vectorize_without_simd_p (code))
to guard this but I'm not sure how this slips through?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106571
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106328
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106328
--- Comment #6 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:fed766af32ed6cd371016cc24e931131e19b4eb1
commit r13-2012-gfed766af32ed6cd371016cc24e931131e19b4eb1
Author: Martin Liska
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101706
Ivan Sorokin changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98709
Ivan Sorokin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 98709, which changed state.
Bug 98709 Summary: gcc optimizes bitwise operations, but doesn't optimize
logical ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98709
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106577
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|[13 Regression]
nary-trunk-r13-2009-20220810070724-gc16d9f78dc8-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220810 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106443
--- Comment #3 from Gaius Mulley ---
Thanks for the report and reminder/patch - I've now pushed the patch to gcc.cc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88174
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 88174, which changed state.
Bug 88174 Summary: Make __real__ += __val usable in constexpr context.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88174
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106342
--- Comment #8 from Jakub Jelinek ---
commit r13-1955-g2f17f489de47d46626ed85804c3b810547ef550e
Author: Ilya Leoshkevich
Date: Fri Jul 29 16:14:10 2022 +0200
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
--- Comment #7 from Jakub Jelinek ---
Perhaps either a quick check that for base ptrs that live in memory gimple_vuse
is the same for both statements or if not, do walk_aliased_vdefs with low
constant limit?
We'd want to stop if we reach the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
--- Comment #6 from Jakub Jelinek ---
Or perhaps could we ask the alias oracle in can_remove_asan_check
for the *base_checks case if base_addr lives in memory whether base_addr could
change in between the stmt in the vector and current stmt,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
Yuri Gribov changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #41 from Kewen Lin ---
(In reply to Kewen Lin from comment #40)
> > >diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
> > >index d666f67..7d8b4ac2200 100644
> > >--- a/gcc/internal-fn.cc
> > >+++ b/gcc/internal-fn.cc
> > >@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
Jakub Jelinek changed:
What|Removed |Added
CC||ygribov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558
--- Comment #3 from Jakub Jelinek ---
Looks like a bug in the sanopt pass.
For -O2, we have before sanopt in main:
b.0_1 = b;
e.2_3 = e;
c.5_4 = c;
.ASAN_CHECK (7, c.5_4, 8, 8);
*c.5_4 = e.2_3;
b.7_5 = b;
.ASAN_CHECK (7, b.7_5, 4,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106576
Bug ID: 106576
Summary: Finalization of temporaries from functions not
occuring
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106504
--- Comment #1 from Jakub Jelinek ---
There have been discussions about this in several F2Fs.
For linear it is desirable to allow private outer var because linear
is the implicit behavior of simd iterators and people want to be able to use
them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106575
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106574
--- Comment #4 from Richard Biener ---
(In reply to Michael Hudson-Doyle from comment #3)
> Certainly this could be "handled" by bumping the tolerance I guess. Not sure
> how to tell if that is appropriate though...
You have to look what GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #52 from Andrew Pinski ---
(In reply to Mathieu Malaterre from comment #51)
> (In reply to Richard Earnshaw from comment #50)
> > Fixed on master so far.
>
> Not clear how this is possible. I reported an issue against gcc-11 which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106187
--- Comment #51 from Mathieu Malaterre ---
(In reply to Richard Earnshaw from comment #50)
> Fixed on master so far.
Not clear how this is possible. I reported an issue against gcc-11 which could
not be reproduced using gcc-12. Are you saying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106572
--- Comment #7 from Richard Biener ---
There's also -Wfoo={1,2,3} and the like, not sure what "everything" would be
here? The "strictest" level (if the levels order by strictness?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #40 from Kewen Lin ---
> >diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
> >index d666f67..7d8b4ac2200 100644
> >--- a/gcc/internal-fn.cc
> >+++ b/gcc/internal-fn.cc
> >@@ -3750,7 +3750,12 @@ static bool
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106575
--- Comment #1 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:c16d9f78dc81664e3341157c5a6efb85c0c141f4
commit r13-2009-gc16d9f78dc81664e3341157c5a6efb85c0c141f4
Author: Roger Sayle
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106322
--- Comment #39 from Andrew Pinski ---
Comment on attachment 53428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53428
untested patch
>diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
>index d666f67..7d8b4ac2200 100644
>---
93 matches
Mail list logo
