https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119720
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-04-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718
--- Comment #9 from Jakub Jelinek ---
You can get some of it already from vanilla trunk,
-fdump-tree-tailc=/dev/stderr 2>&1 | grep '^Cannot convert:'
That is for spots where for musttail calls the pass would error as well.
This doesn't cover the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718
--- Comment #11 from Jakub Jelinek ---
Though, wonder if it wouldn't be more user-friendly to emit the GIMPLE or
GENERIC calls on the same line, incremental
--- gcc/tree-tailcall.cc.jj 2025-04-11 09:38:22.483257379 +0200
+++ gcc/tree-tailcal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718
--- Comment #10 from Jakub Jelinek ---
Created attachment 61071
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61071&action=edit
gcc15-pr119718.patch
Untested patch which changes the -fdump-tree-tailc message wording and moves
it to just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #13 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #7)
> Though, I think we should predefine __FLT_EVAL_METHOD__ to 16 rather than 0
> for -fexcess-precision=16.
-fexcess-precision is not meant to have an effect on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #18 from Richard Biener ---
(In reply to Richard Biener from comment #17)
> (In reply to Jan Hubicka from comment #14)
> >
> > Counting latencies, I think vinserti64x2 is 1 cycle and vpinst is
> > integer->sse move that is slower and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #14 from Jakub Jelinek ---
(In reply to Vincent Lefèvre from comment #13)
> -fexcess-precision is not meant to have an effect on __FLT_EVAL_METHOD__,
No, -fexcess-precision= is meant to have an effect on __FLT_EVAL_METHOD__, it
is w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I've now posted proper patches for the various issues breaking the
compilation of the COBOL frontend on Solaris:
cobol: Don't require GLOB_BRACE etc. [PR119217]
https://gcc.gnu.org/pip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #15 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Vincent Lefèvre from comment #13)
> > -fexcess-precision is not meant to have an effect on __FLT_EVAL_METHOD__,
>
> No, -fexcess-precision= is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101625
--- Comment #9 from Richard Biener ---
Still broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #16 from Jakub Jelinek ---
2 is of course the right value for -fexcess-precision=standard -m32 on x86 (for
-fexcess-precision=fast arguably it should be IMHO -1).
Anyway, if you don't believe -fexcess-precision= affects the FLT_EVAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #18 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:882d3b319dbf50ae64080731a1398031c100b7c7
commit r15-9378-g882d3b319dbf50ae64080731a1398031c100b7c7
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #18 from Jakub Jelinek ---
(In reply to Vincent Lefèvre from comment #17)
> > (for -fexcess-precision=fast arguably it should be IMHO -1).
>
> 2 is more accurate. Note that -1 would not make GCC conforming with
> -fexcess-precision=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110243
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rguenth at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #17 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #16)
> 2 is of course the right value for -fexcess-precision=standard -m32 on x86
So, it is not meant to affect __FLT_EVAL_METHOD__. FYI, -fexcess-precision has
be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112487
Richard Biener changed:
What|Removed |Added
Target Milestone|12.5|14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113255
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119722
--- Comment #1 from Jakub Jelinek ---
I think the problem is in the coalesce handling of
[local count: 1073741824]:
# b_17 = PHI
g.4_13 = g;
_14 = g.4_13 >> 50;
_15 = (unsigned int) _14;
_21 = b_17;
_16 = (unsigned int) _21;
s_22 = _15 + _16;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #19 from 康桓瑋 ---
(In reply to GCC Commits from comment #18)
> The master branch has been updated by Jonathan Wakely :
>
> https://gcc.gnu.org/g:882d3b319dbf50ae64080731a1398031c100b7c7
>
> commit r15-9378-g882d3b319dbf50ae64080731a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118541
--- Comment #8 from Segher Boessenkool ---
(The traditional FP comparisons we do use, i.e. fcmpu. We never used fcmpo,
because it is problematic, it needs access to information that in not in the
RTL at the point of the comparison, that informa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #22 from Jonathan Wakely ---
There might be pathological cases where they differ, e.g. a range type that has
member begin and ADL end, but they deserve to break.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #21 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #20)
> Does it matter? By design, ranges::begin does the same things as range-based
> for (handles arrays first, then looks for member begin(), then looks for ADL
> begin).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #23 from Jonathan Wakely ---
(In reply to 康桓瑋 from comment #21)
> FYI:
> https://stackoverflow.com/questions/79261063/in-what-situations-does-
> rangesfor-each-work-but-for-auto-elt-rg-fail/79262269#79262269
Yes, like that. It deser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #24 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #22)
> but they deserve to break.
I agree with that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #20 from Jonathan Wakely ---
Does it matter? By design, ranges::begin does the same things as range-based
for (handles arrays first, then looks for member begin(), then looks for ADL
begin).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #25 from Jonathan Wakely ---
If we can't use range-based 'for' with ranges then we've taken a wrong turn
somewhere.
I did test them in e.g. std/ranges/access/begin.cc so we know that
ranges::begin and ranges::end will work with them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119723
--- Comment #1 from Filip Kastl ---
> There was also this 10% regression for -O2 -march=native
s/regression/slowdown/ to be more clear. This slowdown also isn't a regression
against GCC 14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119723
Bug ID: 119723
Summary: 30% slowdown of 436.cactusADM on AMD Zen2 since
r15-9204-g0520ef274762f1
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: misse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #26 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #25)
> If we can't use range-based 'for' with ranges then we've taken a wrong turn
> somewhere.
>
> I did test them in e.g. std/ranges/access/begin.cc so we know that
> rang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #19 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #18)
> (In reply to Vincent Lefèvre from comment #17)
> > 2 is more accurate. Note that -1 would not make GCC conforming with
> > -fexcess-precision=fast.
>
> -fex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119723
--- Comment #2 from Jakub Jelinek ---
That commit to some extent restores the GCC 14 behavior. Arguably the
[0x8000ULL,0xULL] CONST_INTs better should have cost of
COST_N_INSNS (1)
but then we need to do something better for the uns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #5 from Robert Dubner ---
As the parser parses each COBOL statement, it tends to call a function,
generally named parser_whatever. For example, the COBOL statement "OPEN INPUT
" results in the function parser_file_open() being call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119722
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115110
--- Comment #15 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:97fa1ba84849a940c55eaecc2d7798d2582d39e4
commit r13-9505-g97fa1ba84849a940c55eaecc2d7798d2582d39e4
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107467
--- Comment #21 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:35aede5a6bc9b2cf7e7d019148debb6f227c6eb1
commit r13-9506-g35aede5a6bc9b2cf7e7d019148debb6f227c6eb1
Author: Sam James
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112859
--- Comment #11 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:0f86e86a869a7defefa63469a1c411ab4bb36c25
commit r13-9509-g0f86e86a869a7defefa63469a1c411ab4bb36c25
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112859
--- Comment #10 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:330a02b893eed85f10c85ab3974ec913616672e8
commit r13-9508-g330a02b893eed85f10c85ab3974ec913616672e8
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114501
--- Comment #15 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:4e49ae8d905d760e97d0c0310f40c7e3a0e4e9df
commit r13-9512-g4e49ae8d905d760e97d0c0310f40c7e3a0e4e9df
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115110
--- Comment #16 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:35aede5a6bc9b2cf7e7d019148debb6f227c6eb1
commit r13-9506-g35aede5a6bc9b2cf7e7d019148debb6f227c6eb1
Author: Sam James
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115347
--- Comment #10 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:330a02b893eed85f10c85ab3974ec913616672e8
commit r13-9508-g330a02b893eed85f10c85ab3974ec913616672e8
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
--- Comment #20 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:2f37a08b51ef8022a2ef0b596006df65ceb44314
commit r13-9511-g2f37a08b51ef8022a2ef0b596006df65ceb44314
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117113
--- Comment #7 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:8ee6631540ca9d5c437ce4bf3236d6d6ae22c475
commit r13-9514-g8ee6631540ca9d5c437ce4bf3236d6d6ae22c475
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119145
--- Comment #7 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:68b740f9e3112f7c0778bcb9dfd10b23cd1df1c0
commit r13-9516-g68b740f9e3112f7c0778bcb9dfd10b23cd1df1c0
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117424
--- Comment #16 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:7b0936da8dbe30b1876bf89b9ae59f1b7fa87dc9
commit r13-9515-g7b0936da8dbe30b1876bf89b9ae59f1b7fa87dc9
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113207
--- Comment #15 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:949f38047860b19a4276b8191d012a3b05aab1e2
commit r13-9510-g949f38047860b19a4276b8191d012a3b05aab1e2
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116906
--- Comment #9 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:9ade99bfbc7f47975d7f8765366904f4d2496afc
commit r13-9513-g9ade99bfbc7f47975d7f8765366904f4d2496afc
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111245
--- Comment #11 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:fb17a8b24cbba558ae2108de2aada1ed5031162c
commit r13-9507-gfb17a8b24cbba558ae2108de2aada1ed5031162c
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #6 from Jakub Jelinek ---
I'm not sure there is enough time before the branching for new options etc.
So, I just wondered about something that can be done quickly, whether it is
renaming
most of the getenv uses (except for those whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #53 from Jonathan Wakely ---
(In reply to tlknv from comment #44)
> Thanks Marc.
> I have posted my patch at
> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg02086.html
This is just a bandaid and not sufficient to avoid the problem. If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #20 from Jakub Jelinek ---
C23 documents it in detail, and so does float.h:
/* The floating-point expression evaluation method. The precise
definitions of these values are generalised to include support for
the interchange and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119145
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116958
Bug 116958 depends on bug 111055, which changed state.
Bug 111055 Summary: [C++23] Implement P1206R7, Conversions from ranges to
containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
What|Removed |Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
Tomasz Kamiński changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111053
Bug 111053 depends on bug 111055, which changed state.
Bug 111055 Summary: [C++23] Implement P1206R7, Conversions from ranges to
containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
What|Removed |Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119415
Bug 119415 depends on bug 111055, which changed state.
Bug 111055 Summary: [C++23] Implement P1206R7, Conversions from ranges to
containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
What|Removed |Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #27 from GCC Commits ---
The master branch has been updated by Tomasz Kaminski :
https://gcc.gnu.org/g:ae54d8cb51eb5cc1f5a3d319cc1840d2e9bfcbfc
commit r15-9380-gae54d8cb51eb5cc1f5a3d319cc1840d2e9bfcbfc
Author: Tomasz KamiÅski
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749
Bug 106749 depends on bug 111055, which changed state.
Bug 111055 Summary: [C++23] Implement P1206R7, Conversions from ranges to
containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
What|Removed |Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107176
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109747
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110269
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111397
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111489
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rguenth at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Keywords|needs-bisection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114070
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115701
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #7 from Robert Dubner ---
There are only a few getenv() calls that I regard as necessary. Those can be
renamed. As I said, GCOBOL_SHOW and GCOBOL_TRACE. There is a COBPATH that
operates like LD_LIBRARY_PATH; that can, and should,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
Tomasz Kamiński changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #8 from Jakub Jelinek ---
I meant it the other way around, keep the getenv calls that should work for all
users, maintainers or not in the 15 release as is.
Rename all other getenv calls (those which are meant for maintainer debuggin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #10 from Sam James ---
Dunno if it'd be an issue if for some reason we had a suid COBOL program? (In
general though, I agree, it's more of a documentation issue and the other
issues jakub mentions, not a security one.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119723
--- Comment #3 from Richard Biener ---
Btw, do we know which rev. happened to improve the score? As a general remark,
436.cactusADM spills a lot in the hottest loop, it's quite sensitive to this
and otherwise memory bound.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119716
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #4)
> If the compiler compiles it and it misbehaves at runtime, that is valid
> behavior for undefined behavior. ICE (as in the other PR) is something we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119716
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
Simon Sobisch changed:
What|Removed |Added
CC||simonsobisch at gnu dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119622
--- Comment #2 from Richard Biener ---
(In reply to Bruno Haible from comment #0)
> I built gcc version 15-20250323 from source, as usual through ".../configure
> ...", "make", "make install".
>
> Now I can compile a Modula-2 hello-world progra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119724
Bug ID: 119724
Summary: Missing upstreamed fast float changes leading to
broken aarch64-w64-mingw32 build
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #21 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #20)
> C23 documents it in detail, and so does float.h:
[...]
> So, only __FLT_EVAL_METHOD_TS_18661_3__ should be possibly 16 for
> -fexcess-precision=16.
What C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #22 from Vincent Lefèvre ---
(In reply to Vincent Lefèvre from comment #21)
> What C23 documents applies *only* when -fexcess-precision=standard, as this
> is the only -fexcess-precision value for which GCC is documented to be
> conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119724
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-04-11
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #23 from Jakub Jelinek ---
IMHO -fexcess-precision=16 (at least on x86_64 64-bit and with -mfpmath=sse
-msse2 32-bit too) are completely conformant modes, it is like 0 (where all of
float, _Float32, double, _Float64, long double, _Fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114970
--- Comment #9 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:4acdfb71d4fdaa43c2707ad7b2fb7b2b7bddfc42
commit r15-9384-g4acdfb71d4fdaa43c2707ad7b2fb7b2b7bddfc42
Author: Jason Merrill
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114970
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119524
Rainer Orth changed:
What|Removed |Added
Target|*-darwin* |*-darwin*, *-*-solaris*
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119723
--- Comment #4 from Filip Kastl ---
Bisection points to r15-7637-g94d01a88470293 being the first fast commit.
Author: Richard Biener
Date: Wed Feb 12 11:20:10 2025 +0100
tree-optimization/86270 - improve SSA coalescing for loop exit tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119524
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2025-04-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119725
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119718
--- Comment #12 from lucier at math dot purdue.edu ---
(In reply to Jakub Jelinek from comment #7)
> We can't just warn on all calls, most of them obviously aren't in tail call
> positions and such warning would have extreme amounts of false posi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014
--- Comment #24 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #23)
> IMHO -fexcess-precision=16 (at least on x86_64 64-bit and with -mfpmath=sse
> -msse2 32-bit too) are completely conformant modes,
If this is the intent, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115639
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114970
--- Comment #10 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:45c949fb697d4602fa8ce8e87213cf17e1acf60b
commit r14-11596-g45c949fb697d4602fa8ce8e87213cf17e1acf60b
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114970
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113831
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
--- Comment #22 from vvinayag at arm dot com ---
(In reply to rguent...@suse.de from comment #19)
> On Thu, 6 Mar 2025, vvinayag at arm dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
> >
> > vvinayag at arm dot com cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119726
Bug ID: 119726
Summary: Template Specialization of Inner class from Inherited
template class fails with: " too few
template-parameter-lists"
Product: gcc
Version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115639
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115639
--- Comment #5 from Patrick Palka ---
(In reply to Patrick Palka from comment #4)
> (In reply to Jason Merrill from comment #3)
> > (In reply to Marek Polacek from comment #2)
> > > The second time around, we're not finding the call in
> > > co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119727
Bug ID: 119727
Summary: -freport-bug vs. ASLR
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee:
epo/gcc-trunk//binary-trunk-20250411084350-r15-9377-g3b33d792cf1e4d-checking-release-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250411 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119727
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
1 - 100 of 236 matches
Mail list logo
