https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119400
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119401
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #29 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #21)
> GOT indirection for mcount has been there from the very beginning:
> https://gcc.gnu.org/cgit/gcc/tree/gcc/config/i386/i386.
> h?id=c98f874233428d7e6ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119402
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.3
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119402
Bug ID: 119402
Summary: [14/15 Regression] `((-bool) & _6) & (~_6)` is not
optimized to 0 on some targets
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Keyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107596
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119401
Andrew Pinski changed:
What|Removed |Added
Known to work||14.2.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119400
--- Comment #5 from Ilya Zylev ---
Thank you very much, that clarifies original post.
-fms-extensions
-fno-ms-extensions
options work as intended.
Is it possible to configure these options from inside the source code being
compiled by GCC? P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
--- Comment #17 from Hime Haieto ---
I'm not entirely sure what I should be doing/commenting on at the moment
considering that the current patches are clearly marked as being
temporary/partial fixes. However, I did still mess around with it a b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119400
--- Comment #3 from Andrew Pinski ---
mingw defaults to -fms-extensions. If you don't want these extensions then use
-fno-ms-extensions.
Note the definition of the extensions has changed over time and GCC has not
kept up to date with them; look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119400
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-03-21
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119400
--- Comment #1 from Andrew Pinski ---
-fms-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119375
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119400
--- Comment #2 from Andrew Pinski ---
https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-c4430?view=msvc-170
This error might be generated due to compiler conformance work done for Visual
Studio 2005: all d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119400
Bug ID: 119400
Summary: Windows-targeted builds of GCC allow -fpermissive
-Wimplicit-int behaviour in C++
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119375
--- Comment #2 from Andi Kleen ---
I already had that commit in my tree, since it was already on trunk.
Or did you think of something different?
commit cfdb961588ba318a78e995d2e2cde43130acd993
Author: Alex Coplan
Date: Tue Nov 26 17:48:14 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #12 from Giuseppe D'Angelo ---
The testcase was just meant to show that a warning originating in a system
header was still be emitted, not that the specific warning didn't make sense :)
Of course it was silly/extreme.
But I understa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119384
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97286
--- Comment #6 from Andrew Pinski ---
*** Bug 111829 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97286
Andrew Pinski changed:
What|Removed |Added
CC||ebiggers3 at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107892
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118914
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111829
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94663
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97286
Andrew Pinski changed:
What|Removed |Added
CC||gcc at kheafield dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97286
Andrew Pinski changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97286
--- Comment #3 from Andrew Pinski ---
simplified to remove intrsinics:
```
typedef int v4si __attribute__((vector_size(4*sizeof(int;
typedef float v4sf __attribute__((vector_size(4*sizeof(int;
void f(v4sf *a, v4sf *b, int l)
{
v4si c =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119384
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118545
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107352
Andrew Pinski changed:
What|Removed |Added
CC||rush102333 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119392
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119396
--- Comment #1 from Andrew Pinski ---
>From libgcc/Makefile.in:
```
enable_shared = @enable_shared@
...
# Only handle shared libraries if both:
# - the user requested them
# - we know how to build them
ifeq ($(SHLIB_LINK),)
enable_shared :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119380
--- Comment #3 from Jerry DeLisle ---
Works for me on gcc version 12.3.1 20230805 (GCC)
The last commit there is commit a3931bf6093dbeda637601da07cdbbd07e57ccbd (HEAD
-> releases/gcc-12)
This was a cherry pick from commit 03fb35f8753d87148b. M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119398
Bug ID: 119398
Summary: partial ordering of nested class template
specializations fails with NTTP of nested class type
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118914
--- Comment #5 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:e8a5f747cfa9c79ab7d95ff95d17d3e31afede50
commit r15-8478-ge8a5f747cfa9c79ab7d95ff95d17d3e31afede50
Author: Andrew Pinski
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #11 from Jonathan Wakely ---
(In reply to Giuseppe D'Angelo from comment #8)
> Well, that's a laudable goal, but I'm very afraid it'll just cause the
> corresponding warnings to be entirely disabled instead -- since in many
> cases t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119380
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399
Bug ID: 119399
Summary: Overlap check in vectorized code may invoke UB
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #21 from Alexander Monakov ---
GOT indirection for mcount has been there from the very beginning:
https://gcc.gnu.org/cgit/gcc/tree/gcc/config/i386/i386.h?id=c98f874233428d7e6ba83def7842fd703ac0ddf1#n623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #9 from Andrew Pinski ---
It would be better if you have an example of a false positive from the system
headers rather than the current one you showed of a true positive.
Yes there are a few in gcc bug system already dealing with -W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119391
--- Comment #8 from Jakub Jelinek ---
Most of arithmetics is still UB on signed overflow even in C++20, there are
just small exceptions like the left shift.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119391
Jonathan Wakely changed:
What|Removed |Added
Summary|Preprocessor tokens should |[C++20] Preprocessor tokens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811
Andrew Pinski changed:
What|Removed |Added
Attachment #60826|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119361
--- Comment #3 from Edwin Lu ---
(In reply to Robin Dapp from comment #2)
> I looked into this some more and it points to a general deficiency in how we
> handle the split between VLA and VLS modes.
> With ...bits=zvl the RVVM1SI etc modes. beco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #8 from Giuseppe D'Angelo ---
Well, that's a laudable goal, but I'm very afraid it'll just cause the
corresponding warnings to be entirely disabled instead -- since in many cases
the end-user can't upgrade the system header, nor the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119392
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #6 from Andrew Pinski ---
(In reply to Giuseppe D'Angelo from comment #5)
> Are they all *supposed* to be emitted even from system headers?
Yes because they might not be false positives. Even in the bug report you filed
here is a tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #7 from Andrew Pinski ---
Note yes there are a bunch of false positives for some system headers but many
of the warnings have actually helped adding hints to compiler to both remove
the false positives and improve code quality.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #5 from Giuseppe D'Angelo ---
Hi,
Thanks for the link. However this isn't just about -Wuninitialized, but also
about a bunch of other (middle-end?) warnings, as I wrote in the first message.
(To add insult to injury, they're also fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119383
--- Comment #3 from Sam James ---
I couldn't reproduce with the script as Boost failed to build (`ERROR: rule
"version.boost-build" unknown in module "build-system".`). I've dealt with b2
(the Boost build system before) and I'm not a fan :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118615
--- Comment #28 from Jakub Jelinek ---
I've managed to reproduce the aarch64-linux bootstrap miscompilation with
r15-2810, and
verified it is the
- if (before_p)
+ if (before_p && PREV_INSN (curr_insn) != prev_insn)
part of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119390
--- Comment #2 from Sam James ---
I don't see it either with glibc-2.41 (tip of stable branch). I do see
PR119377.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119397
--- Comment #1 from Andrew Pinski ---
>There should be a COPYING.*
Huh? No there does not need to be.
The notice is inside the source and all still.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #26 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #25)
> (In reply to Ard Biesheuvel from comment #24)
> > - never emit 'call mcount'
> > - emit 'call *mcount@GOTPCREL(%rip)' if -fno-plt
> > - emit 'call mcount@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115983
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #4 from Andrew Pinski ---
Created attachment 60837
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60837&action=edit
This works if you don't want an uninitialized variable warning from the header
file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 119388, which changed state.
Bug 119388 Summary: [12/13/14/15 Regression] -isystem does not disable warnings
coming from system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114292
Simon Martin changed:
What|Removed |Added
Summary|[12/13/14 Regression] ICE |[12/13 Regression] ICE with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119397
Bug ID: 119397
Summary: missing license file for SunPro covered sources
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118600
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119396
Bug ID: 119396
Summary: libgcc: Shared objects are being built for target that
doesn't support shared libs
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118600
--- Comment #4 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:d286ece094ca52f41bf71096aa1de0a0cd954dfb
commit r15-8475-gd286ece094ca52f41bf71096aa1de0a0cd954dfb
Author: Gaius Mulley
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119391
--- Comment #6 from Neil Booth ---
Yes, the problem isn't that evaluation isn't in intmax_t (so the subject is now
incorrect). That clearly happens as there are hundreds of tests that would
fail.
The problem is that cpp thinks it's undefined b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119380
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114292
--- Comment #12 from GCC Commits ---
The releases/gcc-14 branch has been updated by Simon Martin
:
https://gcc.gnu.org/g:f86d274ab76fdd89d7afd9b2eab28f3a61749cfb
commit r14-11426-gf86d274ab76fdd89d7afd9b2eab28f3a61749cfb
Author: Simon Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118061
uecker at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90746
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119395
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-03-20
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116681
Richard Biener changed:
What|Removed |Added
Keywords|needs-bisection |
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 116681, which changed state.
Bug 116681 Summary: [12/13/14 Regression] ICE: in start, at timevar.cc:491 with
-ftime-report -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116681
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119395
Bug ID: 119395
Summary: target hook function_ok_for_sibcall should take a
gcall* instead of CALL_EXPR as the last argument
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
--- Comment #8 from Richard Biener ---
The -ftime-report ICE on the gcc-14 branch is PR116681.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #28 from Ard Biesheuvel ---
(In reply to Franz Sirl from comment #27)
> Maybe silly question, but since the changelog is only talking about
> __fentry__, why couldn't you make the decision based on flag_fentry?
Sadly, I don't think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119389
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119394
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119391
--- Comment #5 from Jonathan Wakely ---
Doh, yes, of course. So like Neil said in the first place, valid in C++20.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119389
--- Comment #4 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:607f92597c3047d7813a981450a7493bca014324
commit r15-8471-g607f92597c3047d7813a981450a7493bca014324
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119393
Alex Coplan changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118615
--- Comment #27 from Jakub Jelinek ---
So the -fcompare-debug issue is because curr_insn is a JUMP_INSN:
(call_insn 10013 3 4 3 (parallel [
(call (mem:DI (symbol_ref:DI ("g") [flags 0x41] ) [0 g S8 A8])
(const_int 0 [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #27 from Franz Sirl ---
Maybe silly question, but since the changelog is only talking about __fentry__,
why couldn't you make the decision based on flag_fentry?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119394
Bug ID: 119394
Summary: Add fixit hint suggesting adding () to [] noexcept {}
in C++ < 23
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119393
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119393
--- Comment #3 from Tamar Christina ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119393
--- Comment #2 from Andrew Pinski ---
>I've attached a reduced reproducer which (unfortunately) still requires LTO,
>but it is at least fairly well reduced (only two small TUs).
One thing you could do is combine the 2 TUs (since they are small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119393
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119391
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #25 from Alexander Monakov ---
(In reply to Ard Biesheuvel from comment #24)
> - never emit 'call mcount'
> - emit 'call *mcount@GOTPCREL(%rip)' if -fno-plt
> - emit 'call mcount@PLT' otherwise
As discussed, gcc was always using GOT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811
--- Comment #18 from Christophe Lyon ---
Thanks for your patch!
I can confirm your comment #16, bootstrap in progress on an arm-linux-gnueabihf
machines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119391
--- Comment #4 from Jakub Jelinek ---
And
#if 1U << 63
#endif
or
#if 1ULL << 63
#endif
is accepted with no diagnostics.
So, isn't this valid in C++20 and above since wg21.link/p1236 and invalid
otherwise (C++98 .. C++17 and any C)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #24 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #23)
> That's probably just copying existing behavior from 32-bit x86.
>
> Can we preserve previous behavior that under -fpic -mno-direct-extern-access
> mcount
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119391
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119391
--- Comment #2 from Jonathan Wakely ---
It changed from long to intmax_t with
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1988.pdf
But even with long, it should have been accepted for LP64 targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #23 from Alexander Monakov ---
That's probably just copying existing behavior from 32-bit x86.
Can we preserve previous behavior that under -fpic -mno-direct-extern-access
mcount is called via GOT (and else emit mcount@PLT if -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119349
Andre Vehreschild changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #7 from Andre V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119393
Bug ID: 119393
Summary: [15 Regression] Worse vectorization of imagick_r hot
loop on aarch64 since r15-5024-g2a2e6784074e1f
Product: gcc
Version: 15.0
Status: UNCONFIRME
1 - 100 of 188 matches
Mail list logo
