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=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=119384
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
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=97286
Andrew Pinski changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
--- Comment
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=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=111829
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=119380
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119384
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99434
--- Comment #7 from Andrew Pinski ---
Created attachment 60830
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60830&action=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119384
--- Comment #1 from ktkachov at gcc dot gnu.org ---
> We have a workload for aarch64 using the SIMDe translation error
Oops, this should say "SIMDe translation layer"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119370
--- Comment #6 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e0b3eeb67f6d3bfe95591d8fb0c7dfd3f1b3b4ef
commit r15-8462-ge0b3eeb67f6d3bfe95591d8fb0c7dfd3f1b3b4ef
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119381
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
--- Comment #6 from Tamar Christina ---
(In reply to ktkachov from comment #5)
> (In reply to Tamar Christina from comment #4)
> > While looking at the codegen it looks like GROMACS has a lot of loops that
> > get vectorized now and it's showing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
Bug ID: 119386
Summary: [14/15 Regression][x64] Shared libraries can no longer
be compiled with profiling
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119055
--- Comment #2 from Filip Kastl ---
It looks like this benchmark is roughly at the same time as it was before.
I'll close this if there are no objections.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119372
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119325
--- Comment #21 from Tobias Burnus ---
Andrew's patch to Newlib's newlib/libm/machine/amdgcn/amdgcn_veclib.h:
* [PATCH] Fix GCN SIMD libm bug
https://sourceware.org/pipermail/newlib/2025/021582.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119384
Bug ID: 119384
Summary: Extra move in tight loop with SIMD and subregs
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119385
Bug ID: 119385
Summary: internal compiler error when referencing parameters in
require clauses in lambda expressions
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119385
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119328
Andrew Pinski changed:
What|Removed |Added
CC||liuxf19 at 163 dot com
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119381
--- Comment #7 from Jakub Jelinek ---
Or in C23 constexpr int size = 4096;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99434
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Depends on|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114189
Bug 114189 depends on bug 115519, which changed state.
Bug 115519 Summary: s390 fallout from removing vcond{,u,eq} patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115519
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115519
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114412
--- Comment #9 from Filip Kastl ---
If we look at these comparisons
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.5=596.100.0&plot.6=755.100.0&plot.7=868.100.0&plot.8=1032.100.0&plot.9=586.100.0
we see that we are now even faster than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116763
--- Comment #2 from Filip Kastl ---
Indeed. If we look at these comparisons
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.5=596.100.0&plot.6=755.100.0&plot.7=868.100.0&plot.8=1032.100.0&plot.9=586.100.0&;
https://lnt.opensuse.org/db_d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116958
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
Tamar Christina changed:
What|Removed |Added
Last reconfirmed||2025-03-20
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
Bug ID: 119387
Summary: Regression in performance by a factor of 6 when
building with debugging symbols
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
--- Comment #1 from Jonathan Wakely ---
Bisecting ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64504
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #8 from Jonathan W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
Bug ID: 119388
Summary: [12/13/14/15 Regression] -isystem does not disable
warnings coming from system headers
Product: gcc
Version: 15.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119370
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #3 from Franz Sirl ---
The option -mdirect-extern-access is enabled by default since it was added in
r12-7126-ab0b5fbfe90168d2e470aefb19e0cf31526290bc . I didn't even know about
this option before I ran into this problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #4 from Franz Sirl ---
> Note that the GCC man page is pretty clear about this:
>
> -mdirect-extern-access
> -mno-direct-extern-access
>
> Do not use or use GOT to access external symbols. The default is
> -mno-direct-extern-acces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to Tamar Christina from comment #4)
> While looking at the codegen it looks like GROMACS has a lot of loops that
> get vectorized now and it's showing some inefficiencies in the codege
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241
--- Comment #19 from Jakub Jelinek ---
(In reply to Richard Biener from comment #18)
> It's the following hunk. real_to_decimal always uses e+exp notation
> and a lower-case 'E'.
Not 100%. I believe it prints -0.0 and 0.0 like that rather tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241
--- Comment #20 from Richard Biener ---
(In reply to Jakub Jelinek from comment #19)
> (In reply to Richard Biener from comment #18)
> > It's the following hunk. real_to_decimal always uses e+exp notation
> > and a lower-case 'E'.
>
> Not 100%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #1 from Ard Biesheuvel ---
I don't think -mdirect-extern-access should be used when creating shared
libraries, is there any reason in particular this is being used?
However, given that this is a function call, I'd expect the direct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119390
--- Comment #1 from Richard Biener ---
Seems to be fine when compiling cobol1 with -O -D_FORTIFY_SOURCE=[23] with
glibc 2.38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119389
Filip Kastl changed:
What|Removed |Added
Summary|[15 Regression] tree FRE|[15 Regression] tree FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #2 from Ard Biesheuvel ---
Note that the GCC man page is pretty clear about this:
-mdirect-extern-access
-mno-direct-extern-access
Do not use or use GOT to access external symbols. The default is
-mno-direct-extern-access: GOT is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #5 from Ard Biesheuvel ---
(In reply to Franz Sirl from comment #4)
> > Note that the GCC man page is pretty clear about this:
> >
> > -mdirect-extern-access
> > -mno-direct-extern-access
> >
> > Do not use or use GOT to access ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241
--- Comment #22 from rguenther at suse dot de ---
On Thu, 20 Mar 2025, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241
>
> --- Comment #21 from Jakub Jelinek ---
> I'm not sure if shifting the exponent is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241
--- Comment #23 from Jakub Jelinek ---
I've misparsed the condition guarding it, thought %f is done when it the
exponent is outside of the narrow range, not inside.
Anyway, if it is going to stick with the E notation, we should change e to E
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #2 from Jonathan Wakely ---
I think it was that change for Bug 99612, which means that (some?) locations
for (some?) warnings are no longer considered to be in system headers, so no
longer suppressed by -isystem and the system_header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
Uroš Bizjak changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119349
--- Comment #6 from Andre Vehreschild ---
I mean pr90068
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119389
Sam James changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119349
Andre Vehreschild changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241
--- Comment #21 from Jakub Jelinek ---
I'm not sure if shifting the exponent is right for positive exponents, for very
large ones that would mean appending zeros but the exact value might not have
zeros in there, so we might need something with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
Patrick Palka changed:
What|Removed |Added
Attachment #60831|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241
--- Comment #24 from Robert Dubner ---
Here comes perhaps too much information.
That "value thing" was added late. I believe it arrived at the point where Jim
realized he needed to be doing compile-time numerical calculations for the
Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
Franz Sirl changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #19 from Alexander Monakov ---
The question is why prior to your patch GCC emitted mcount@GOT (i.e. avoiding
the PLT trampoline for mcount on purpose), going all the way back to gcc-3.4
(and probably further).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #17 from Michael Matz ---
(In reply to Ard Biesheuvel from comment #16)
> OK, so in summary, the fallthrough for CM_SMALL_PIC/CM_MEDIUM_PIC should be
> removed, and instead, a 'call mcount@PLT' should be emitted.
That crucially depe
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=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=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=119386
--- Comment #22 from Ard Biesheuvel ---
(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=c98f874233428d7e6ba83d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #20 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #19)
> The question is why prior to your patch GCC emitted mcount@GOT (i.e.
> avoiding the PLT trampoline for mcount on purpose), going all the way back
> to gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119380
Andre Vehreschild changed:
What|Removed |Added
Last reconfirmed||2025-03-20
Ever confirmed|0
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
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
See Also|
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
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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=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=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=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=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=119386
Richard Biener changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #16 from Ard Biesheuvel ---
OK, so in summary, the fallthrough for CM_SMALL_PIC/CM_MEDIUM_PIC should be
removed, and instead, a 'call mcount@PLT' should be emitted.
I suppose this should check for -fno-plt as well, and revert to 'ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119391
Bug ID: 119391
Summary: Rejects valid
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #15 from Alexander Monakov ---
Any idea why prior to introduction of this bug, gcc always emitted a
GOT-indirect call for mcount? It looks like it is avoiding lazy PLT resolver,
but why is that necessary?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #18 from Ard Biesheuvel ---
(In reply to Michael Matz from comment #17)
> (In reply to Ard Biesheuvel from comment #16)
> > OK, so in summary, the fallthrough for CM_SMALL_PIC/CM_MEDIUM_PIC should be
> > removed, and instead, a 'call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118061
uecker at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASS
101 - 188 of 188 matches
Mail list logo
