https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
--- Comment #3 from Vineet Gupta ---
Bisected this to ...
dc0dea98c96e02c6b24060170bc88da8d4931bc2 is the first bad commit
commit dc0dea98c96e02c6b24060170bc88da8d4931bc2
Author: Richard Biener
Date: Wed Nov 27 13:36:19 2024 +0100
middl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118521
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
--- Comment #4 from Vineet Gupta ---
Also slightly better test so avoid cpp/installed headers and use bare cc1
void func(const float *a, const float *b, float *c)
{
for (long i = 0; i < 1024; ++i) {
float a_l = __builtin_lround(a[i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118521
--- Comment #11 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:a2755339c6c9832467c573d956e91565943ecdc1
commit r15-7652-ga2755339c6c9832467c573d956e91565943ecdc1
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
Sam James changed:
What|Removed |Added
Target Milestone|--- |15.0
Summary|RISC-V: Extra FRM w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 118521, which changed state.
Bug 118521 Summary: [15 regression] std::vector Wstringop-overflow false
positive since r15-4473
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118521
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118952
--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Richard Sandiford from comment #1)
> I think this is essentially the same problem as PR34678.
Thanks, yeah I don't see PR34678 getting generally resolved any time soon. Is
there so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118951
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118952
--- Comment #3 from Richard Sandiford ---
(In reply to ktkachov from comment #2)
> Thanks, yeah I don't see PR34678 getting generally resolved any time soon.
> Is there something we could do with these particular builtins to make them a
> strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
--- Comment #19 from Evgeny Karpov ---
Thank you for your interest in aarch64-w64-mingw32.
Cross-compilation from the x86_64-pc-msys host to the aarch64-w64-mingw32
target
is already available. Work on a native toolchain is in progress.
More in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118685
--- Comment #11 from GCC Commits ---
The releases/gcc-12 branch has been updated by Gerald Pfeifer
:
https://gcc.gnu.org/g:23541b23deb5504c6d3c0a3e96a0858e10c3c627
commit r12-10960-g23541b23deb5504c6d3c0a3e96a0858e10c3c627
Author: Dimitry Andr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
Sam James changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118685
Gerald Pfeifer changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209
--- Comment #5 from Patrick Palka ---
(In reply to 康桓瑋 from comment #4)
> > Our concat_view implementation is accidentally based off of an older
> > revision of the paper, P2542R7 instead of R8. As far as I can tell the
> > only sem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209
--- Comment #6 from 康桓瑋 ---
(In reply to Patrick Palka from comment #5)
> (In reply to 康桓瑋 from comment #4)
> > > Our concat_view implementation is accidentally based off of an older
> > > revision of the paper, P2542R7 instead of R8. A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
Sam James changed:
What|Removed |Added
Keywords|needs-bisection |
Summary|[15 regression] Bootstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115209
--- Comment #7 from 康桓瑋 ---
(In reply to 康桓瑋 from comment #6)
> (In reply to Patrick Palka from comment #5)
> > (In reply to 康桓瑋 from comment #4)
> > > > Our concat_view implementation is accidentally based off of an older
> > > > revisi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
Bug ID: 118955
Summary: Fortran uses vector math functions without -ffast-math
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
Wilco changed:
What|Removed |Added
Target Milestone|--- |16.0
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #1 from Thomas Koenig ---
> Since vector
> functions can have much larger ULP errors, using them by default with -O2
> seems excessive.
"can have"? Is this indeed the case? I would consider this to be
a bug in the implementation of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
Thomas Koenig changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
Ever conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118956
--- Comment #1 from Richard Sandiford ---
Created attachment 60541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60541&action=edit
candidate patch
This patch changes the patterns so that they don't require a scratch register
post-reload.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118957
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118957
Bug ID: 118957
Summary: 5-9% slowdown of 511.povray_r and 453.povray on x86_64
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #2 from Wilco ---
(In reply to Thomas Koenig from comment #1)
> > Since vector
> > functions can have much larger ULP errors, using them by default with -O2
> > seems excessive.
>
> "can have"? Is this indeed the case? I would consi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118956
Bug ID: 118956
Summary: [15 regression]
gcc.target/aarch64/sve/pred-not-gen-[14].c fail after
r15-268-g9dbff9c05520a74e
Product: gcc
Version: 15.0
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118957
Filip Kastl changed:
What|Removed |Added
Summary|5-9% slowdown of|5-9% slowdown of
|511.p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118945
--- Comment #5 from Jeffrey A. Law ---
This doesn't seem like an ABI issue (WRT c#2), it's just question of what
uarchs prefer from a performance standpoint.
With that in mind I'd tend to think that a tune option is the way to go. In
general I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #45 from Xi Ruoyao ---
(In reply to Luke Dalessandro from comment #44)
> Now that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 was resolved is
> it possible to actually get the atomic/atomic_ref to generate cmpxchg16b? Or
> is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118958
Bug ID: 118958
Summary: Order of arguments to std::min change output when it
shouldn't
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118958
Jonathan Wakely changed:
What|Removed |Added
Keywords||missed-optimization
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116604
--- Comment #5 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:2f03b10da878fe8365975f54b72ff5e717a295a9
commit r15-7654-g2f03b10da878fe8365975f54b72ff5e717a295a9
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53929
LIU Hao changed:
What|Removed |Added
Attachment #57199|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118959
Bug ID: 118959
Summary: [15 Regression] 5-14% slowdown of 400.perlbench
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
Luke Dalessandro changed:
What|Removed |Added
CC||ldalessandro at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118958
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #46 from Luke Dalessandro ---
(In reply to Xi Ruoyao from comment #45)
> (In reply to Luke Dalessandro from comment #44)
> > Now that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 was resolved is
> > it possible to actually get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118959
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118950
--- Comment #4 from Robin Dapp ---
It indeed appears is if we need zeroing of the loaded gather values but
bool type_mode_padding_p
= TYPE_PRECISION (scalar_type) < GET_MODE_PRECISION (GET_MODE_INNER
(mode));
is false.
The last of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118958
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104296
Andrew Pinski changed:
What|Removed |Added
CC||asianzhang812 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118960
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118960
Bug ID: 118960
Summary: Define std::mutex unconditionally
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
--- Comment #12 from Jerry DeLisle ---
(In reply to Thomas Koenig from comment #10)
> What does the OpenMP standard say about I/O in partallel exexution?
I don't know,but the situation is libgfortran threads are being launched by the
async I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374
--- Comment #29 from GCC Commits ---
The trunk branch has been updated by Gerald Pfeifer :
https://gcc.gnu.org/g:25fa8d6dc30ace6493fd9e861c13ee3282aa02c0
commit r15-7656-g25fa8d6dc30ace6493fd9e861c13ee3282aa02c0
Author: Gerald Pfeifer
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116604
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
Tobias Burnus changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005
--- Comment #19 from Tobias Burnus ---
(In reply to Xi Ruoyao from comment #18)
> I get warnings like below after building both libgomp and the test program
> with tsan (following PR55561 comment 15):
>
> WARNING: ThreadSanitizer: lock-order-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118958
--- Comment #4 from Andrew Pinski ---
So the difference between func3 and func4 is the following:
func3 does:
```
D.2811 = 1;
_4 = num;
_7 = D.2811;
if (_4 < _7)
```
While func4 does:
```
D.2821 = 1;
_4 = D.2821;
_7 = num;
if (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
--- Comment #17 from Sam James ---
Created attachment 60544
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60544&action=edit
gcc-bug.sh
I can reproduce with this script at least. I'll try cut it down next.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118860
Zdenek Sojka changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047
--- Comment #12 from David Malcolm ---
Sam: what architectures/configurations do you see this on? Comment #0 was
presumably aarch64, but I don't think comment #3 specified anything beyond it
being 64-bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
--- Comment #6 from Andrew Pinski ---
DSE4 shows:
```
Deleted dead store: g[1] = 8;
Deleted dead store: g[0] = 5;
```
But as I mentioned the problem is in pcom which is forming an invalid pointer
in the first place.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118961
--- Comment #1 from Andrew Pinski ---
Maybe related to:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586290.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
--- Comment #7 from Andrew Pinski ---
Valgrind might dectect the removal of the stores. I am not 100% sure though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047
--- Comment #13 from Sam James ---
I've only seen this on amd64 so far (2 machines) but I didn't try to reproduce
it on arm64 or elsewhere.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118956
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-02-20
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118962
Bug ID: 118962
Summary: Segmentation fault on Windows
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118959
Andrew Pinski changed:
What|Removed |Added
Keywords||ra
Component|tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118962
--- Comment #1 from Andrew Pinski ---
IIRC there are some issues with realigning the stack and main ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118962
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #3 from Andrew Pinski ---
I am trying to remember if math-vector-fortran.h is included via the
preprocessor or include Fortran directive.
If the former, then you could use preprocessor directives here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118961
Bug ID: 118961
Summary: ICE g++ modules with LTO
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #4 from Andrew Pinski ---
But it is the later fpre-include.
#define TARGET_F951_OPTIONS "%{!nostdinc:\
%:fortran-preinclude-file(-fpre-include= math-vector-fortran.h finclude%s/)}"
I wonder if find_fortran_preinclude_file could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
Andrew Pinski changed:
What|Removed |Added
CC||rainer.bitschi at aon dot at
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118932
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #2)
> I think the relevant sentence from 19.2, paragraph 2, is
>
> "Furthermore, a binding label shall not be the same as the global identifier
> of any ot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118959
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
Andrew Pinski changed:
What|Removed |Added
Component|fortran |target
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118952
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118951
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118951
--- Comment #3 from Andrew Pinski ---
__FILE__ is actually an string_cst rather than a pointer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
Sam James changed:
What|Removed |Added
Attachment #60544|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118951
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118802
Sam James changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118923
--- Comment #4 from Jakub Jelinek ---
Created attachment 60547
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60547&action=edit
gcc15-pr118923.patch
Completely untested patch (can't test it right now).
Not using get_internal_target_expr b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #6 from Wilco ---
(In reply to Andrew Pinski from comment #5)
> Or you could just do:
> #define TARGET_F951_OPTIONS "%{Ofast|ffast-math|funsafe-math-optimizations: \
> %{!nostdinc: \
>%:fortran-preinclude-file(-fpre-include= mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #7 from Andrew Pinski ---
(In reply to Wilco from comment #6)
> (In reply to Andrew Pinski from comment #5)
>
> > Or you could just do:
> > #define TARGET_F951_OPTIONS "%{Ofast|ffast-math|funsafe-math-optimizations:
> > \
> > %{!no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118955
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Wilco from comment #6)
> > (In reply to Andrew Pinski from comment #5)
> >
> > > Or you could just do:
> > > #define TARGET_F951_OPTIONS
> > > "%{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118891
--- Comment #16 from marcus at mc dot pp.se ---
Created attachment 60548
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60548&action=edit
Result from check-gcc on stage1 of gcc 14.3 on aarch64_be
The tests finally completed.
So there were
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115028
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118957
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #8 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114518
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Component|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
--- Comment #9 from Andrew Pinski ---
(In reply to Sam James from comment #8)
> Sorry about that. It doesn't always hang because of uninit memory.
>
> With Valgrind, I got r15-1757-g4d24159a1fcb15. Does that sound more
> reasonable?
Maybe.
F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59252
--- Comment #10 from GCC Commits ---
The releases/gcc-13 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:0c3061fe7367b378eb8adf4845fde914faca1f40
commit r13-9384-g0c3061fe7367b378eb8adf4845fde914faca1f40
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458
--- Comment #18 from Vladimir Makarov ---
Created attachment 60549
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60549&action=edit
Reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118923
--- Comment #5 from Marek Polacek ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 60547 [details]
> gcc15-pr118923.patch
>
> Completely untested patch (can't test it right now).
> Not using get_internal_target_expr because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59252
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |13.4
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118915
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
Bug ID: 118954
Summary: Miscompile at -O3
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117829
Richard Biener changed:
What|Removed |Added
Summary|[12/13/14/15 regression]|[12/13/14 regression] False
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118954
Sam James changed:
What|Removed |Added
Summary|Miscompile at -O3 |[15 regression] Miscompile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939
Sam James changed:
What|Removed |Added
Known to work||13.3.1, 15.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #12 from Jonathan Wakely ---
Yeah I'm unable to reproduce this even on Debian with g++-13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #23 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:99f57446e63b8ebeaeeae8dc48981cd5f1dfb831
commit r15-7645-g99f57446e63b8ebeaeeae8dc48981cd5f1dfb831
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115955
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|15.0|16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117315
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
101 - 200 of 209 matches
Mail list logo
