https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #16 from Segher Boessenkool ---
It is allowed by recog(). Most likely your pattern is incorrect, but it
is not completely impossible there is something wrong in genrecog.cc --
but that isn't combine either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #15 from Xi Ruoyao ---
(In reply to Segher Boessenkool from comment #14)
> (match_operand:DI 1 "register_operand" "r0")
>
> That means either a general register ("r"), or the same thing as operand 0
> (that's what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430
--- Comment #10 from Alexandre Oliva ---
Sorry, I'd missed the build scripts, that presumably would have enabled me to
trigger the problem more readily.
Anyhow, this explains why lto and PIE are both needed to trigger the problem.
As for a sol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430
--- Comment #9 from Alexandre Oliva ---
I'm not sure I've run into the same problem, but the one I'm looking at is in
the training stage, in ali.o, one of many that raise an assertion failure from
SInput.Get_Source_File_Index.Assertions. Intere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #10 from H.J. Lu ---
(In reply to Filip Kastl from comment #8)
> The same commit (r16-1644-gaba3b9d3a48a07) causes ~20% slowdown of 470lbm
> from 2006 SPEC on Zen5 with -Ofast -march=native -flto -fprofile-use.
>
> https://lnt.opens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120709
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=90569
mirh at protonmail dot ch changed:
What|Removed |Added
CC||mirh at protonmail dot ch
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #18 from Frank Heckenbach ---
(In reply to Frank Heckenbach from comment #17)
> Maybe I've found a work-around. I took the is_instance_of_v template from
> https://indii.org/blog/is-type-instantiation-of-template/ and turned it into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116928
--- Comment #2 from eczbek.void at gmail dot com ---
I made a patch: https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685831.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969
--- Comment #11 from Andrew Pinski ---
(In reply to Frank Heckenbach from comment #10)
>
> So "most" means "some of the features of the standard plus some non-standard
> features which will then suddenly be withdrawn"?
YES. Especially based on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969
--- Comment #10 from Frank Heckenbach ---
(In reply to Andrew Pinski from comment #7)
> From
> https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Standards.html#C_002b_002b-
> Language :
> Another revised ISO C++ standard was published in 2020 as ISO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118697
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969
--- Comment #9 from Frank Heckenbach ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Frank Heckenbach from comment #5)
> > I never used "-fconcepts-ts" until now that GCC forces me to.
>
> Not exactly. The code was accepted by ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969
--- Comment #8 from Andrew Pinski ---
Also from https://gcc.gnu.org/projects/cxx-status.html#cxx20 :
Important: Because the ISO C++20 standard is recent, GCC's support is
experimental.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969
--- Comment #7 from Andrew Pinski ---
From
https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Standards.html#C_002b_002b-Language
:
Another revised ISO C++ standard was published in 2020 as ISO/IEC 14882:2020,
and is referred to as C++20; before its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969
--- Comment #5 from Frank Heckenbach ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Frank Heckenbach from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > I am almost want to close this as won't fix since -fconce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969
--- Comment #4 from Frank Heckenbach ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Frank Heckenbach from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > I am almost want to close this as won't fix since -fconce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969
--- Comment #3 from Andrew Pinski ---
(In reply to Frank Heckenbach from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I am almost want to close this as won't fix since -fconcepts-ts has already
> > been removed in GCC 15 which w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969
--- Comment #2 from Frank Heckenbach ---
(In reply to Andrew Pinski from comment #1)
> I am almost want to close this as won't fix since -fconcepts-ts has already
> been removed in GCC 15 which was released 3 months ago.
So much for the "deprec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969
--- Comment #1 from Andrew Pinski ---
I am almost want to close this as won't fix since -fconcepts-ts has already
been removed in GCC 15 which was released 3 months ago.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120969
Bug ID: 120969
Summary: two consecutive '[' shall only introduce an attribute
before '[' token
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120918
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120968
Bug ID: 120968
Summary: Using global C name with import std recommends using
the same undeclared name
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120921
--- Comment #5 from Andrew Pinski ---
Created attachment 61808
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61808&action=edit
Patch which I am testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120921
--- Comment #4 from Andrew Pinski ---
Created attachment 61807
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61807&action=edit
testcases for the invalid cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #14 from Segher Boessenkool ---
(match_operand:DI 1 "register_operand" "r0")
That means either a general register ("r"), or the same thing as operand 0
(that's what "0" means)!
So the backend explicitly allows it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120921
--- Comment #3 from Andrew Pinski ---
So looking into this further, the problem is only with
verify_gimple_assign_single where the issue is.
Another testcase:
```
void __GIMPLE b(int t, int t1) {
&t1 = &t;
}
```
And another one:
```
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120967
Bug ID: 120967
Summary: std::format produces incorrect results when printing
large floating point numbers when using the alternate
flag and precision set to 0
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
--- Comment #16 from Eric Botcazou ---
> I'll try to recompile GCC 6.5 with GCC 5.5 again, but this time not with
> just '--with-gnu-as', buth with also '--with-as=/usr/local/bin/as'. Perhaps
> that will fix this.
Yes, that's the right thing to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed|2021-08-12 00:00:00 |2025-7-5
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120951
--- Comment #10 from Andrew Pinski ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688651.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120966
Andrew Pinski changed:
What|Removed |Added
Summary|-Waggressive-loop-optimizat |++/-- for short still uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120942
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120782
--- Comment #8 from Robin Dapp ---
The vlse comes from a vec_duplicate:V2DI that has a reg pointing to a
"real(kind=4)", so a float.
What's interesting, though, is that the MEM is supposedly 64-bit aligned (see
below, A64).
(insn 285 282 287 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118891
--- Comment #26 from Sam James ---
*** Bug 120965 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120965
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120964
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118891
Sam James changed:
What|Removed |Added
CC||hanwei62 at huawei dot com
--- Comment #25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
--- Comment #15 from TCH ---
I'll try to recompile GCC 6.5 with GCC 5.5 again, but this time not with just
'--with-gnu-as', buth with also '--with-as=/usr/local/bin/as'. Perhaps that
will fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56954
TCH changed:
What|Removed |Added
CC||tch at protonmail dot com
--- Comment #5 from TCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
--- Comment #14 from TCH ---
The resulting binary however has a problem: it tries to use the non-GNU
assembler under '/usr/ccs/bin/as', instead of using the GNU assembler under
'/usr/local/as', despite being configured to use the GNU assembler a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
--- Comment #13 from TCH ---
@Eric Botcazou:
You were right: using the GNU assembler, but not using the GNU linker did the
trick. (I tried to compile GCC6 without using neither of the GNU assembler nor
the linker before, but then the assembler e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120942
--- Comment #6 from Renze Lin ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Renze Lin from comment #4)
> > (In reply to Andrew Pinski from comment #2)
> > > Also can you provide the full output of "gcc -v" ?
> >
> > The output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120948
--- Comment #6 from Andrew Pinski ---
(In reply to Richard Biener from comment #5)
> But of course if we'd want to expose
> this to the user it might instead be
>
> x = __builtin_assume (x != 0);
I dont see why we want to expose this to the u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
--- Comment #12 from TCH ---
Created attachment 61805
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61805&action=edit
Fixes all of the errors of compiling GCC6 on Solaris 10 SPARC
The fix of the 'NAN' and 'INFINITY' problem is an ugly 'u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86615
TCH changed:
What|Removed |Added
CC||tch at protonmail dot com
--- Comment #3 from TCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120966
--- Comment #1 from Andreas Schwab ---
There is no short overflow due to integer promotion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120954
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|15.2|12.5
Summary|[15/16 Regressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870
Sam James changed:
What|Removed |Added
Target Milestone|--- |16.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120966
Bug ID: 120966
Summary: -Waggressive-loop-optimizations warns for int but not
for short overflow
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #4 from Georg-Johann Lay ---
(In reply to fiesh from comment #3)
> Is there some other output, like nm or objdump, that could help?
Not very helpful IMO.
You can try the following steps:
1) It's unlikely that LTO is essential. Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120959
--- Comment #3 from Richard Biener ---
(In reply to Richard Biener from comment #2)
> That change shouldn't have caused code generation changes IIRC.
That is, I would have expected RTL expansion to expand the
division/multiplications as shifts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120959
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |16.0
--- Comment #2 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120954
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120948
--- Comment #5 from Richard Biener ---
A better representation than if (...) __builtin_unrechable (); for asserts
would be nice. We have with __builtin_assume_aligned something very related.
So in GIMPLE we could have
_2 = .ASSUME (_1, !=, 0);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120782
--- Comment #7 from Robin Dapp ---
Ok, I was able to reproduce it with r15-9904-g2498cbbcdb23da.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120965
Bug ID: 120965
Summary: gcc 14.3 aarch64 be failed with pr78542.c
Product: gcc
Version: 14.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120964
Bug ID: 120964
Summary: aarch64 be failed with pr78542.c
Product: gcc
Version: 14.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120949
--- Comment #6 from Jonathan Wakely ---
I think https://github.com/llvm/llvm-project/pull/133107 fixed clang trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118891
--- Comment #24 from marcus at mc dot pp.se ---
I can confirm that with those two patches a 3-stage build of 14.2.1 completes
with stage 2 and 3 compared as equal.
The number of failed tests with "vect" somewhere in the name is down to 6:
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118681
--- Comment #10 from Jonathan Wakely ---
Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688627.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120949
--- Comment #5 from Jonathan Wakely ---
But not with Clang 20:
:5:34: error: an attribute list cannot appear here
5 | __attribute__((always_inline)) [[nodiscard]] friend inline int baz ()
{ return 42; }
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120955
--- Comment #3 from fiesh at zefix dot tv ---
Thank you for the feedback. I tried to generate a test case, but it proved
really hard for me. Is there some other output, like nm or objdump, that could
help?
65 matches
Mail list logo
