https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108989
--- Comment #2 from Dave Allerton ---
Apologies - should have spotted it but thanks for sorting it out.
Best regards
Dave Allerton
On 02/03/2023 13:32, sch...@linux-m68k.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #14 from niXman ---
(In reply to Jakub Jelinek from comment #13)
> Fixed now on the trunk. I'd wait a little bit with backports, though I
> think the gmp-param.h change doesn't need backporting.
Thank you Jakub!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108990
--- Comment #2 from Richard Biener ---
Consolidating these kind of duplicates would be nice. Note in this particular
case we should order the more specific pattern earlier (diagnosing that with
-v would be nice).
Implementing order preserving
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682
--- Comment #3 from Andreas Schwab ---
libgo/goarch.sh is missing LoongArch support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-03-03
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682
--- Comment #4 from Xi Ruoyao ---
(In reply to Andreas Schwab from comment #3)
> libgo/goarch.sh is missing LoongArch support.
We ship a go 1.18 runtime but LoongArch support was added in 1.19. Updating go
runtime in stage 3 is definitely not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109002
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-03-03
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #2 from Jakub Jelinek ---
I think there are several open PRs about var-tracking at -O0, which would be
nice e.g. for VLAs. The main problem is that var-tracking is very expensive,
so if we do it, it should track a very small subset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #3 from Jakub Jelinek ---
What is done on other arches? I mean the situation is basically the same on
x86_64,
where the artificial return value pointer argument is spilled early, then
clobbered
on calls and again b debug info is cor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> LTO will almost certainly break src/c++98/globals_io.cc so I don'tthink we
> can support building libstdc++ with LTO for now.
And would probably break the f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219
--- Comment #5 from Ivan Sorokin ---
(In reply to Patrick Palka from comment #4)
> Fixed for GCC 13 so far
Thank you very much!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109002
--- Comment #4 from Richard Biener ---
When doing partial PRE we somehow lose the effect of
g = 1;
we also generate weird PHIs:
pretmp_20 = h;
pretmp_22 = g;
# prephitmp_21 = PHI
# prephitmp_23 = PHI
# prephitmp_24 = PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109002
Richard Biener changed:
What|Removed |Added
Summary|-O1 -ftree-pre |[13 Regression] -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109004
Bug ID: 109004
Summary: wrong code for -O2 (any above -O0) with g++ 11.3 for
POWER9 (cross-compiler on x86_64 host)
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108727
Kewen Lin changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:dbeccab7a1f5dcc1876c854f17816047ba1ef137
commit r13-6441-gdbeccab7a1f5dcc1876c854f17816047ba1ef137
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109002
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:0132acc03cada2c3b47c48a205e821563153fc80
commit r13-6443-g0132acc03cada2c3b47c48a205e821563153fc80
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109002
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71850
--- Comment #7 from Costas Argyris ---
Created attachment 54575
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54575&action=edit
Treat include path args the same way between cpp_unique_options and asm_options
The proposed patch extends the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
Bug ID: 109005
Summary: [13 Regression] ICE during GIMPLE pass: ifcvt
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109006
Bug ID: 109006
Summary: [13 Regression] Python Exception :
There is no member or method named m_vecdata. since
r13-6332
Product: gcc
Version: 13.0
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109006
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #1 from simon at pushface dot org ---
Created attachment 54576
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54576&action=edit
Reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007
Bug ID: 109007
Summary: building for POWER8 leaks into POWER9 ISA with g++
11.3 (cross-compiler on x86_64 host)
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
simon at pushface dot org changed:
What|Removed |Added
Target||x86_64-apple-darwin
Kno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109006
--- Comment #1 from Jakub Jelinek ---
As for the non-*.py comments, perhaps:
2023-03-03 Jakub Jelinek
PR middle-end/109006
* vec.cc (test_auto_alias): Adjust comment for removal of
m_vecdata.
* read-rtl-functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
Bug ID: 109008
Summary: [13 Regression ]Maybe wrong code in scipy package
since r13-3926-gd4c2f1d376da6f
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
Richard Biener changed:
What|Removed |Added
Target||x86_64-linux-gnu
Target Milestone|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #2 from Richard Biener ---
So it boils down to us optimizing
d = 1. + eps;
if (d == 1.)
return eps;
to return 0. which is of course wrong.
double eps_or_zero (double eps)
{
double d = 1. + eps;
if (d == 1.)
return eps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #3 from Richard Biener ---
So with [1., 1.] = [1., 1.] + op2 we are calculating op2 = [1., 1.] - [1., 1.]
but with FP math we cannot apply such simplification without considering
rounding or exponent ranges. Maybe it's enough to "fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #4 from Richard Biener ---
The "easiest" way would be if the range endpoints would have one bit more of
mantissa and so we can represent all endpoints with one ulp off (aka
nextafter/nextbefore). So constants would always become non
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #5 from Jakub Jelinek ---
Well, we already do that half ulp fuzzing in frange_arithmetic. The thing is
that for
forward [1., 1.] - [1., -1.] it is really correctly [0., 0.], the subtraction
is exact in that case. It is just the rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109004
Richard Biener changed:
What|Removed |Added
Known to work||9.5.0
Summary|wrong code fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
--- Comment #4 from simon at pushface dot org ---
(In reply to Richard Biener from comment #3)
> Eh, I'm hoping for a C testcase ... what's the actual ICE?
This is an LLDB session -- hope that helps
$ lldb /opt/gcc-13-20230226/libexec/gcc/x86_6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #6 from Jakub Jelinek ---
Note, the ulps frange_arithmetic are ulps of the result, result is in this case
0.0,
so 1ulp is the smallest subnormal number.
That is something completely different from what we need here though for the
rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108727
--- Comment #3 from Alan Modra ---
Yes, looks good to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109005
Richard Biener changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #7 from Richard Biener ---
(In reply to Jakub Jelinek from comment #6)
> Note, the ulps frange_arithmetic are ulps of the result, result is in this
> case 0.0,
> so 1ulp is the smallest subnormal number.
> That is something completel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #8 from Richard Biener ---
We basically have to consider an input range [a, b] as [a - x, b + y]
with the largest positive x and y so that correctly rounding the value
yields a and b again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #9 from Richard Biener ---
(In reply to Richard Biener from comment #8)
> We basically have to consider an input range [a, b] as [a - x, b + y]
> with the largest positive x and y so that correctly rounding the value
> yields a and b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #4 from Ulrich Weigand ---
(In reply to Jakub Jelinek from comment #3)
> What is done on other arches?
That depends on the platform ABI. On some arches, including x86/x86_64 and
arm/aarch64, the ABI requires the generated code relo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #10 from Jakub Jelinek ---
So, can't we say compute what we compute right now for the reverse operation
and then call some helper function which will try to extended that range a
little bit in both directions by performing frange_ari
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #11 from Richard Biener ---
I think for the reverse op I'd naiively try to compute the result as we do now
and then extend the range by one ulp of the input range with the largest
magnitude.
Does real_nextafter (0.0) result in a den
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
Jakub Jelinek changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108924
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109009
Bug ID: 109009
Summary: Shrink Wrap missed opportunity
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109010
Bug ID: 109010
Summary: Fortran frontend memory leaks building SPEC CPU 2017
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461
Patrick Palka changed:
What|Removed |Added
CC||headch at gmail dot com
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109001
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109010
--- Comment #1 from Richard Biener ---
I've tried to attach the full build log but it's too large even compressed.
Instead I placed it at https://gcc.opensuse.org/CPU2017.449.log.xz but it
might take a day or so for it to appear.
Not all leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #12 from Jakub Jelinek ---
(In reply to Richard Biener from comment #11)
I think before we code something on the compiler side, it might be better
to play just with C testcases.
Quite naive
#include
__attribute__((noipa)) void
e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
Bug ID: 109011
Summary: missed optimization in presence of __builtin_ctz
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108999
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108141
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #6)
> The change has been reverted, so this is no longer a regression.
Just for the info. The patch I reverted resulted in wrong calculation of
pressure classes (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:1b0e3f8ca369f63d3e1a8e1c268d93530035503a
commit r13-6450-g1b0e3f8ca369f63d3e1a8e1c268d93530035503a
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
Patrick Palka changed:
What|Removed |Added
Summary|[13 Regression] ICE in |[12/13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13 Regression] |[11/12 Regression]
|I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108887
--- Comment #3 from Jan Hubicka ---
We don't really have way to mark nodes for removal. I am not 100% sure I
understand what the code does, but removing random nodes from cgraph in hook
invoked from mangling seems dangerous, since we invoke DEC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #6 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #5)
> So, I wonder if we just shouldn't ask for a DWARF 6 extension here, have
> some way for the compiler to specify DW_AT_location for the return value.
There is ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #5 from John Drouhard ---
Has there been any progress toward resolution for this? We've been trying to
use coroutines in our project but we require LTO for performance reasons, so
this is holding us back.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106896
--- Comment #10 from Jan Hubicka ---
The problem the assert is trying to solve is that local counters are all
frequencies relative to the entry block count, while IPA counters are absolute
values within the whole program. So comparing them mixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #6 from Jan Hubicka ---
I am not really expert on coroutines. But this seems to be a type (not a
declaration we globalize during LTO) generated internally by the front-end.
The name __D.9984.3.4 looks like it has a global counter in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108887
--- Comment #4 from Jakub Jelinek ---
Perhaps, but shouldn't we also unlink_from_assembler_name_hash (node, false);?
I think the point of the current removal is that we've discovered the mangling
alias clashes with some other symbol.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #7 from Iain Sandoe ---
(In reply to Jan Hubicka from comment #6)
from me there has been no progress on anything co-routines related, for a while
- I of not have any resources to work on it.
> I am not really expert on coroutines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109012
Bug ID: 109012
Summary: Repeated error messages when using -std=c++23
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
--- Comment #5 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:341e6cd8d603a334fd34657a6b454176be1c6437
commit r13-6452-g341e6cd8d603a334fd34657a6b454176be1c6437
Author: Patrick Palka
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
Patrick Palka changed:
What|Removed |Added
Summary|[12/13 Regression] ICE in |[12 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109009
--- Comment #1 from Segher Boessenkool ---
This is very target-specific. Could you please attach a test case (with any
significant compiler flags as well, and specific target mentioned, etc.) that
shows the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109006
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:ce1c99f1ccd7b1229a4f8531d6b6de6cf571a9ef
commit r13-6453-gce1c99f1ccd7b1229a4f8531d6b6de6cf571a9ef
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109013
Bug ID: 109013
Summary: [OpenMP] Diagnose if multiple 'omp ordered' appear in
a loop body
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #8 from Jan Hubicka ---
>
> the synthesised functions (actor, destroy) are intended to be TU-local.
> the ramp function is what remains of the user's original function after the
> coroutine body is outlined - so that has the origina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108887
--- Comment #5 from Jan Hubicka ---
> Perhaps, but shouldn't we also unlink_from_assembler_name_hash (node, false);?
> I think the point of the current removal is that we've discovered the mangling
> alias clashes with some other symbol.
cgraph_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #9 from Iain Sandoe ---
(In reply to Jan Hubicka from comment #8)
> >
> > the synthesised functions (actor, destroy) are intended to be TU-local.
> > the ramp function is what remains of the user's original function after the
> > co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109013
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #13 from Segher Boessenkool ---
(In reply to Alexander Monakov from comment #10)
> (In reply to Rui Ueyama from comment #9)
> > I'm the maintainer of the mold linker. I didn't implement that POWER10 ABI
> > because I didn't have an a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109013
--- Comment #2 from Jakub Jelinek ---
Even the dominating case could be valid.
E.g. if the body does
#pragma omp ordered
foo ();
bar ();
#pragma omp ordered
baz ();
where bar () calls exit (0);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109006
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:59a576f274b9093fd4b25eb6be556b40c2424478
commit r13-6454-g59a576f274b9093fd4b25eb6be556b40c2424478
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #14 from Alexander Monakov ---
Are you guys really sure you want to blame the user here, considering that all
linkers, including the BFD linker, initially misinterpreted the ABI the same
way?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109014
Bug ID: 109014
Summary: -Wanalyzer-use-of-uninitialized-value seen in
pcre2-10.42's pcre2test.c
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #7 from Andrew Pinski ---
(In reply to Ulrich Weigand from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > What is done on other arches?
>
> That depends on the platform ABI. On some arches, including x86/x86_64 and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109014
--- Comment #1 from David Malcolm ---
I believe the issue here is that:
* display_properties partially initializes the "found" buffer, writing a -1
terminator at the end of the initialized part at:
fv[m] = -1;
* display_properties then ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
--- Comment #11 from Tom Stellard ---
(In reply to Jakub Jelinek from comment #10)
> I'd start with verification if it is really libgcc, so don't recompile the
> app, just try it against GCC 12.2.1 libgcc vs. 13.0.1.
I confirmed it's libgcc. O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109015
Bug ID: 109015
Summary: Analyzer doesn't know about atomic builtins
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: anal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104882
--- Comment #6 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:220008eafaaed7433b1c18e394279391e885a138
commit r13-6455-g220008eafaaed7433b1c18e394279391e885a138
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51534
--- Comment #6 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:cc9cc5a9a5fb0c16532a16b87fbd155037a7ed89
commit r13-6457-gcc9cc5a9a5fb0c16532a16b87fbd155037a7ed89
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989
--- Comment #23 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:21edd841611a97442a6b95e8ec7e91ff8fd3a451
commit r13-6461-g21edd841611a97442a6b95e8ec7e91ff8fd3a451
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104852
--- Comment #8 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:21edd841611a97442a6b95e8ec7e91ff8fd3a451
commit r13-6461-g21edd841611a97442a6b95e8ec7e91ff8fd3a451
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52590
--- Comment #7 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:21edd841611a97442a6b95e8ec7e91ff8fd3a451
commit r13-6461-g21edd841611a97442a6b95e8ec7e91ff8fd3a451
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109016
Bug ID: 109016
Summary: Analyzer doesn't know about OMP builtins
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #10 from Iain Sandoe ---
Hmm... maybe I am being too hasty here.
If the coroutine has a definition in a header, then the coroutine frame type
_should_ be the same for each instance of it. So maybe this is actually
reporting a genui
1 - 100 of 142 matches
Mail list logo
