https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119222
--- Comment #5 from Gwen Fu ---
Maybe the bug is related to the code below：
(in gcc/fold-const.cc :fold_binary_loc)
case RDIV_EXPR:
/* Don't touch a floating-point divide by zero unless the mode
of the constant can represent i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #16 from Sam James ---
(In reply to Levi Zim from comment #15)
As long as the flag is passed correctly and applied to both the stage2 + stage3
builds, then the flag can't be to blame (just a trigger for it, rather than
some problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119286
--- Comment #1 from Thomas Schwinge ---
(In reply to Thomas Schwinge from comment #0)
> I found commit r15-7886-g2427793af1e545506e0315f8ec06adf73d76b3cc
> "middle-end: delay checking for alignment to load [PR118464]" responsible
> for a number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #14 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #8)
> Because as this PR shows, those 2->2 insn merges with no change on i2 can
> make a lot of sense and allow combination on the second and following user
> of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119168
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119285
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119159
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
s --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.1 20250314 (experimental) (GCC)
[511] %
[511] % gcctk -O3 small.c; ./a.out
[512] % gcct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38
--- Comment #3 from GCC Commits ---
The master branch has been updated by Tomasz Kaminski :
https://gcc.gnu.org/g:5abe571e0276fafcc6eed27c27abb28943e67c6f
commit r15-8057-g5abe571e0276fafcc6eed27c27abb28943e67c6f
Author: Tomasz KamiÅski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #17 from Levi Zim ---
(In reply to Sam James from comment #16)
> (In reply to Levi Zim from comment #15)
>
> As long as the flag is passed correctly and applied to both the stage2 +
> stage3 builds, then the flag can't be to blame (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119290
Bug ID: 119290
Summary: cobol testsuite should disable non-64-bit multilibs
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119290
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119290
--- Comment #3 from Jakub Jelinek ---
Yes, compile a minimal cobol program (some one liner or what).
And perhaps look particularly for the sorry message as failure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012
--- Comment #15 from Levi Zim ---
(In reply to Sam James from comment #14)
> Thanks. Please try to reproduce it manually next.
If I didn't revert that commit, then bisection of the CFLAGS shows that
-Wp,-D_FORTIFY_SOURCE=3 is what causes the bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119270
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119291
Sam James changed:
What|Removed |Added
Target Milestone|--- |13.4
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119227
Mark Wielaard changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119289
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> Libc++ behaves the same way.
Actually that's not true, libc++ resolves the symlink and copies the file to
that location. So it creates asdf, as you expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119292
Bug ID: 119292
Summary: code deduplication in case of throw (improvement)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94061
Jason Merrill changed:
What|Removed |Added
Status|NEW |SUSPENDED
--- Comment #11 from Jason Mer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119293
Bug ID: 119293
Summary: [15 Regression] gcc.dg/vect/vect-121.c fails since
r15-6811-g086031c0585985
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119227
--- Comment #6 from David Malcolm ---
Thanks for the info Mark.
Sorry if this comes across as blunt, but pushing changes and waiting for a
cronjob to run (in production) seems very 1990s.
Is there some automated way to bring up a test instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92713
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:1268924a2eed4e4f4cf1f43cc996b2f0eedeb07e
commit r15-8052-g1268924a2eed4e4f4cf1f43cc996b2f0eedeb07e
Author: Thomas Schwinge
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119284
--- Comment #3 from Jonathan Wakely ---
N.B. the error didn't happen because the wrong overload was selection, it
happened while doing overload resolution to see if it _should_ be selected.
This problem is precisely why the monadic operations o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #16 from GCC Commits ---
The master branch has been updated by Robert Dubner :
https://gcc.gnu.org/g:b673d7b593f63a526a85d56204f1217bc4fbf6a1
commit r15-8056-gb673d7b593f63a526a85d56204f1217bc4fbf6a1
Author: Robert Dubner
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #18 from Robert Dubner ---
(In reply to Jakub Jelinek from comment #17)
> Note,
> * gengen.cc: applies if( !optimize ) test
> is not properly formatted ChangeLog entry, unfortunately it got through
> pre-commit hooks.
> For n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119282
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115076
--- Comment #3 from Tobias Burnus ---
The testcase mentioned in PR 115271 comment 1, i.e., the existing (xfailed):
libgomp/testsuite/libgomp.fortran/declare-variant-2.f90
libgomp/testsuite/libgomp.fortran/declare-variant-2-aux.f90
is interes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105616
Donn Seeley changed:
What|Removed |Added
CC||donn.seeley at everfox dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116572
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119120
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d0d7c6632c2913c0243f048a15ff64aec6b6232e
commit r15-8059-gd0d7c6632c2913c0243f048a15ff64aec6b6232e
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119291
Sam James changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116572
--- Comment #7 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:075ec330307c5b1fe5ed166a633c718c06b01437
commit r15-8061-g075ec330307c5b1fe5ed166a633c718c06b01437
Author: Martin Jambor
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119294
Bug ID: 119294
Summary: Strange (buggy?) codegen when passing cleared vector
as argument
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119296
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119296
Bug ID: 119296
Summary: cobol, libgcobol the library uses strfromf* which are
C23 and not generally available outside GLIBC
Product: gcc
Version: 15.0
Status: UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #20 from Richard Sandiford ---
(In reply to Richard Sandiford from comment #18)
> Still more than 0% of course, but nevertheless much less than before.
than before the fix for PR101523 went in, I mean.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #22 from Segher Boessenkool ---
(In reply to Richard Sandiford from comment #18)
> I'd been reluctant to get involved in this for fear of creating friction or
> being a cook too many,
No, your input is much appreciated!
> but: the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #19 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #16)
> Tamar's explanation why #c0 gcc 14 code is better than gcc 15:
> "the mov is a zero latency instruction. sxtw, asr and sbfx themselves are
> aliases to th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #24 from Jakub Jelinek ---
So, I've retried the #c10 testing with the #c18 patch modified to do
-int limit = i2_unchanged ? 1200 : INT_MAX;
+int limit = i2_unchanged ? (getenv ("COMBLIM") ? atoi (getenv ("COMBLIM"))
: 1200) :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #23 from Richard Sandiford ---
(In reply to Segher Boessenkool from comment #22)
> (In reply to Richard Sandiford from comment #18)
> > but: the problem in PR101523 was that, after each
> > successful 2->2 attempt, distribute_links w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #25 from Jakub Jelinek ---
And some further attempts in the 1500..5000 range:
$ for i in 1500 2000 2500 3000 3500 4000 5000; do echo COMBLIM=$i time
./cc1plus -quiet -nostdinc -O2 pr101523.ii -mlong-double-128 -march=z196
-fpreproce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119293
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119285
Sam James changed:
What|Removed |Added
Priority|P2 |P1
--- Comment #2 from Sam James ---
P1 un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119299
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119291
--- Comment #5 from Sam James ---
(In reply to Andrew Pinski from comment #4)
> Created attachment 60756 [details]
> This should do exactly what that patch did
>
> It looks like a different change caused this version too.
r13-673-gd863ba23fb16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47253
Andrew Pinski changed:
What|Removed |Added
CC||hiraditya at msn dot com
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114518
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117069
--- Comment #7 from Sam James ---
This stopped failing for me around:
commit 2bc3ea210565dc7cdbba9adb31acceefed406254
Author: Sam James
Date: Fri Nov 22 15:20:45 2024 +
saving uncommitted changes in /etc prior to emerge run
diff --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116028
--- Comment #18 from Sam James ---
Is this failing still after r15-7400?
.size set2, .-set2
.ident "GCC: (GNU) 15.0.1 20250314 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-tgl-3 gcc]$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87576
Andrew Pinski changed:
What|Removed |Added
Known to fail|15.0|
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116028
--- Comment #19 from Andrew Pinski ---
(In reply to Sam James from comment #18)
> Is this failing still after r15-7400?
Yes this one is still failing for aarch64:
FAIL: gcc.dg/pr10474.c scan-rtl-dump pro_and_epilogue "Performing
shrink-wrapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
Jakub Jelinek changed:
What|Removed |Added
Summary|[14/15 regression] |[13/14/15 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119104
--- Comment #7 from Alejandro Colomar ---
alx@devuan:~/tmp$ cat nninz.c | grep -Tn ^
1:#include
2:
3:extern int any;
4:
5:[[gnu::nonnull]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
--- Comment #11 from Sam James ---
(In reply to Rainer Orth from comment #0)
> That already happened between 20240405
> (592536eb3c0a97a55b1019ff0216ef77e6ca847e) and 20240412
> (a76f236e084cbd02e4e3711cdfc3191dc7eeb460).
>
The former commit i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
Sam James changed:
What|Removed |Added
Priority|P1 |P2
Summary|[15 regression] abi_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214
--- Comment #20 from Robert Dubner ---
(In reply to Richard Biener from comment #15)
> (In reply to Robert Dubner from comment #14)
> > (In reply to Richard Biener from comment #13)
> > > (In reply to Robert Dubner from comment #7)
> > >
[...]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119290
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119293
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-03-14
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119300
Bug ID: 119300
Summary: ICE: in extract_insn, at recog.cc:2882 with
-msoft-float -mfpmath=387 and __builtin_ia32_rsqrtf()
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119299
--- Comment #3 from H.J. Lu ---
(In reply to AK from comment #0)
...
> https://godbolt.org/z/3xh6Mxq4j
FYI,
https://gitlab.com/x86-gcc/gcc/-/tree/users/hjl/condjmp/gcc-16?ref_type=heads
generates:
.globl g1
.type g1, @func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119300
--- Comment #1 from Andrew Pinski ---
__builtin_ia32_rsqrtf most likely not be turned on for soft-float.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|15.0|13.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #3 from Martin Jambor ---
Created attachment 60759
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60759&action=edit
Output of -fopt-info-vec in the slow case
Output of -fopt-info-vec in the slow case
des
--with-gxx-libcxx-include-dir=/usr/include/c++/v1
--with-build-config=bootstrap-cet
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250314 (experimental)
81203220af87714fd0f3170a2043ab5d95353eef (Gentoo Hardened 15.0. p, commit
c80eba1e1f25987e05fb9724b199fdb464becb37)
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978
--- Comment #28 from Chen Chen ---
I have seen that this regression was fixed on gcc15. Is there any plan to fix
it on gcc14 as well? Thanks.
(In reply to chenglulu from comment #26)
> (In reply to Tianyang Chou from comment #24)
> > (In reply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119283
--- Comment #2 from Iain Sandoe ---
(In reply to Richard Biener from comment #1)
> I wonder if it could just use strrchr as fallback?
IDK if cobol strings are always null-terminated?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119287
Sam James changed:
What|Removed |Added
Keywords||ice-checking,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
--- Comment #12 from Jakub Jelinek ---
I think it started with r14-321-g9a41d2cdbcd2af77a3a91a840a3a13f0eb39971b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119299
--- Comment #1 from Sam James ---
H.J. may be working on this for 16 (if so, dupe).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #26 from Segher Boessenkool ---
(In reply to Richard Sandiford from comment #23)
> Yeah, I'd wondered about limiting it an all cases too. Definitely seems
> worth trying. But given that we're in stage 4, maybe it would make sense t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119295
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119294
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119295
Bug ID: 119295
Summary: cobol, libcobol uses random_r which is GLIBC specific
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119294
Andrew Pinski changed:
What|Removed |Added
Summary|Strange codegen when|Could improve vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119297
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119291
--- Comment #4 from Andrew Pinski ---
Created attachment 60756
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60756&action=edit
This should do exactly what that patch did
It looks like a different change caused this version too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119297
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119294
Andrew Pinski changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119294
--- Comment #3 from Andrew Pinski ---
>It's furthermore strange that `set_indirect()` compiles to different code than
>`set()`, even though the former (should) just directly inline the latter.
That is because in the set case the argument stil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119282
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=119298
--- Comment #1 from Martin Jambor ---
Created attachment 60757
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60757&action=edit
Perf annotate of the slow case
Perf annotate of the slow case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #2 from Martin Jambor ---
Created attachment 60758
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60758&action=edit
Perf annotate of the fast case
Perf annotate of the fast case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #4 from Martin Jambor ---
Created attachment 60760
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60760&action=edit
Output of -fopt-info-vec in the fast case
Output of -fopt-info-vec in the fast case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
Bug ID: 119298
Summary: 538.imagick_r is faster when compiled with GCC 14.2
and -Ofast -flto -march=native than with master on
Zen5
Product: gcc
Version: 15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119294
--- Comment #5 from H.J. Lu ---
CSE turns
(insn 18 16 19 2 (set (mem/c:V16QI (plus:DI (reg/f:DI 19 frame)
(const_int -16 [0xfff0])) [0 MEM
[(void *)&x]+0 S16 A128])
(subreg:V16QI (reg:V4SI 111) 0)) "x.c":11:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119291
--- Comment #3 from Andrew Pinski ---
Works on aarch64 and the gimple level loops the same between x86_64 and
aarch64.
I suspect this is either a target issue or a rtl optimization issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119290
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b2de4b0926bddbb97b991dd95592c714ee519e1e
commit r15-8062-gb2de4b0926bddbb97b991dd95592c714ee519e1e
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
--- Comment #10 from Jakub Jelinek ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #4 from Jakub Jelinek ---
> > Does it have in that case the desired effect? I mean, does Solaris dynamic
> > linker complain wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119282
--- Comment #4 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:2f03a8d7be9775312c50abdc99109aaf8641bda3
commit r15-8063-g2f03a8d7be9775312c50abdc99109aaf8641bda3
Author: Patrick Palka
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79637
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79637
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87576
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #8 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119282
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87576
--- Comment #9 from Sam James ---
Created attachment 60762
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60762&action=edit
a.ii.xz (gcc 12)
g++ a.ii -o a -O3 -g -DDEBUG -D_DEBUG -Wno-array-bounds -Wall -Wextra
-pedantic -Wno-unused-param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119299
Bug ID: 119299
Summary: Jump followed by jump not optimized.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119279
--- Comment #3 from Richard Biener ---
I think
asm ("" : : "g" (__builtin_frame_address_(0)))
and using that input as frame pointer looks spot-on semantically, is that
what you are actually using or are you then using %rbp anyway in the
assemb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119282
Bug ID: 119282
Summary: Views
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned a
1 - 100 of 191 matches
Mail list logo
