https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #18 from Martin Uecker ---
>
> + TYPE_CANONICAL (x) = TYPE_CANONICAL (t);
> As has been discussed, this is wrong, it should have been
> TYPE_CANONICAL (x) = build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS
> (x));
> or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114599
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88371
--- Comment #2 from Eyal Rozenberg ---
(In reply to Andrew Pinski from comment #1)
> Looks to be fixed in GCC 10+.
Indeed... mark this as RESOLVED FIXED perhaps?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100482
Nathaniel Shead changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #17 from Jakub Jelinek ---
Some comments:
+ else
+{
+ TYPE_CANONICAL (t) = t;
+}
The formatting here is wrong, TYPE_CANONICAL is indented too much, but we also
don't put a single statement between {}s, so just
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114587
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114599
--- Comment #3 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:9ab8fdfeef5b1a47b358e08a98177b2fad65fed9
commit r14-9803-g9ab8fdfeef5b1a47b358e08a98177b2fad65fed9
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115
--- Comment #16 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:9ab8fdfeef5b1a47b358e08a98177b2fad65fed9
commit r14-9803-g9ab8fdfeef5b1a47b358e08a98177b2fad65fed9
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114599
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596
--- Comment #4 from Tobias Burnus ---
> For selector construct = {teams, parallel, for}
> score1 = 29 score2 = 29
> ---
>
> The constructs[i]'s score look fine.
>
> But I wonder why score == 29 and not 28.
Answer:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590
jbeulich at suse dot com changed:
What|Removed |Added
CC||jbeulich at suse dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114572
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:592536eb3c0a97a55b1019ff0216ef77e6ca847e
commit r14-9801-g592536eb3c0a97a55b1019ff0216ef77e6ca847e
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114597
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114597
--- Comment #5 from wierton <141242068 at smail dot nju.edu.cn> ---
(In reply to Xi Ruoyao from comment #4)
> I believe the second form is still incorrect and it just works by luck. To
> ensure it work you have to do:
>
> asm("mov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596
--- Comment #3 from Tobias Burnus ---
The scoring is according to TR12:
> Each trait selector for which the corresponding trait appears
> in the construct trait set in the OpenMP context is given the
> value 2^(pā1) where p is the position of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #1 from m.cencora at gmail dot com ---
gcc version info:
g++-14 (Ubuntu 14-20240330-1ubuntu2) 14.0.1 20240330 (experimental) [master
r14-9728-g6fc84f680d0]
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596
--- Comment #2 from Tobias Burnus ---
Crossref to the OpenMP spec discussions [not publicly available]
related to the scoring:
* Jakub asked about this testcase in an omp-lang in the email 2019/016447.html
(w/o getting a reply.
* He then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114511
--- Comment #2 from Richard Biener ---
Confirmed.
_3 = _1 + _2;
y = _3;
_18 = b_9(D) + c_12(D);
_19 = _18 - a_8(D);
_20 = _3 + _19;
_6 = _20 - _1;
re-association doesn't associate the def of _3 because it has multiple uses
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #22 from Jakub Jelinek ---
BTW, wonder if it wouldn't be desirable to revert the PR114361 patch until this
is sorted out, or at least limit the effects of that patch to flag_isoc23 and
using multiple types with the same tag and same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Summary|missed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #21 from Jakub Jelinek ---
Why? That is already set by
TYPE_CANONICAL (t) = *e;
else
{
TYPE_CANONICAL (t) = t;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114599
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #23 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:8057f9aa1f7e70490064de796d7a8d42d446caf8
commit r14-9805-g8057f9aa1f7e70490064de796d7a8d42d446caf8
Author: Martin Uecker
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361
Martin Uecker changed:
What|Removed |Added
Resolution|FIXED |---
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #16 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Jakub Jelinek from comment #14)
> > Marking for 14 as well because I believe the trunk commit just made it
> > latent there rather than fixed.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #19 from Jakub Jelinek ---
(In reply to Martin Uecker from comment #18)
> I am just looking at a version that would have changed the condition to:
>
> if (TYPE_MODE (t) == mode && TYPE_REF_CAN_ALIAS_ALL (t) == can_alias_all
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #20 from Martin Uecker ---
(In reply to Martin Uecker from comment #18)
> >
> > + TYPE_CANONICAL (x) = TYPE_CANONICAL (t);
> > As has been discussed, this is wrong, it should have been
> > TYPE_CANONICAL (x) =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
Bug ID: 114600
Summary: [modules] redefinition errors when using certain std
headers in GMF
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
Patrick Palka changed:
What|Removed |Added
CC||nshead at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11196
Jonathan Wakely changed:
What|Removed |Added
CC||zwuis at outlook dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
--- Comment #8 from Richard Biener ---
So in principle we'd need to adjust the bound by one only instead of not using
range info at all as the increment is executed in each loop iteration but
the loop may "stop" before it is reached.
We fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:8c9063825ce726fcbbc067d8a6d062cc2d4acf5e
commit r14-9809-g8c9063825ce726fcbbc067d8a6d062cc2d4acf5e
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
Nathaniel Shead changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114604
Richard Biener changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102793
--- Comment #7 from Manolis Tsamis ---
Also submitted in the lists:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/648856.html
I should note that I needed to modify the test uninit-pred-6_c.c and remove
this check:
if (l)
if (n >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114604
--- Comment #2 from Richard Biener ---
Created attachment 57887
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57887=edit
BITMAP_ALLOC instrumentation
This is the instrumentation patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114605
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |14.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #5 from Patrick Palka ---
(In reply to Nathaniel Shead from comment #4)
> In general we don't yet implement merging of textual redefinitions; I guess
> this ultimately falls under that, but I'm not sure we have a dedicated bug
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114599
H.J. Lu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112723
--- Comment #7 from Jakub Jelinek ---
Ah, with -fwrapv. Without -fwrapv the testcase invokes UB always, either the
first c + c overflows or the second one, or the c += -2147483647 - 1;
overflows.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596
--- Comment #6 from Tobias Burnus ---
(In reply to sandra from comment #5)
> Tobias, it looks to me like you missed the connection ...
No, I didn't - I did link it (cf. top of comment 3) ā but I just cannot read
:-/
Hence, for
(1) *teams*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596
--- Comment #7 from sandra at gcc dot gnu.org ---
OK, I will do no more work on the old implementation, adjust the broken
testcases, and proceed with getting the my new implementation ready for stage 1
submission. I don't know if I'll be able
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114605
Bug ID: 114605
Summary: [14 Regression] wrong code with -march=z13 -O0 since
r14-5831
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114603
--- Comment #1 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:67cbb1c638d6ab3a9cb77e674541e2b291fb67df
commit r14-9811-g67cbb1c638d6ab3a9cb77e674541e2b291fb67df
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114603
Richard Sandiford changed:
What|Removed |Added
Last reconfirmed||2024-04-05
fix=/repo/gcc-trunk//binary-trunk-r14-9803-20240405111321-g9ab8fdfeef5-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240405 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114602
Bug ID: 114602
Summary: Compilcation failure when using a user-defined
function which name is same as a posix function
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #54 from Segher Boessenkool ---
Propose a patch, then? With justification. It should also work for 10x
bigger testcases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114604
Bug ID: 114604
Summary: Ranger allocates from uninitialized
bitmap_default_obstack
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32
Marek Polacek changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114599
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114605
--- Comment #2 from Jakub Jelinek ---
Created attachment 57889
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57889=edit
gcc14-pr114605.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596
--- Comment #5 from sandra at gcc dot gnu.org ---
Tobias, it looks to me like you missed the connection between the first half of
item (1) in 7.3 (I'm still looking at the 5.2 spec):
"Each trait selector for which the corresponding trait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112723
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #55 from Richard Biener ---
(In reply to Segher Boessenkool from comment #54)
> Propose a patch, then? With justification. It should also work for 10x
> bigger testcases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114603
Bug ID: 114603
Summary: aarch64: Invalid SVE cnot optimisation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102793
Manolis Tsamis changed:
What|Removed |Added
CC||manolis.tsamis at vrull dot eu
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #17 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a844095e17c1a5aada1364c6f6eaade87ead463c
commit r14-9808-ga844095e17c1a5aada1364c6f6eaade87ead463c
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114602
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114605
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-04-05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #21 from Alexander Monakov ---
It is possible to reduce gcc_qsort workload by improving the presorted-ness of
the array, but of course avoiding quadratic behavior would be much better.
With the following change, we go from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114606
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964
--- Comment #4 from Martin Jambor ---
Oops. I made a mistake, the commit above fixes PR 114247, sorry :-/
This one is the next in my queue. Sorry again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
Nicolas Boulenguez changed:
What|Removed |Added
Attachment #57866|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #16 from Nicolas Boulenguez ---
This 3rd attempt does the requested split.
It fixes all build errors on Debian/amd64.
The new Ada.Calendar.Clock returns sensible results.
In other words, it seems ready for review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114608
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Target|riscv*-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88371
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88371
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.0
--- Comment #4 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114579
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
the fix in trunk, prints the same error as in the
original post:
:5:32: in 'constexpr' expansion of 'std::bit_cast(std::bit_cast(A{1}))'
/opt/compiler-explorer/gcc-trunk-20240405/include/c++/14.0.1/bit:94:33: sorry,
unimplemented: '__builtin_bit_cast' cannot be constant evaluated because the
argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106500
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114609
--- Comment #2 from arnaud.lb at gmail dot com ---
I can not think of any location where this warning would make sense for this
code. The warning behaves as if we did this:
```
()->member == 1 ? (_Bool) : (_Bool)0) ? 2 : 3;
```
In this case it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114588
--- Comment #3 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:4b02dd48f531ea88587edd2b75b6e5243b4389e8
commit r14-9817-g4b02dd48f531ea88587edd2b75b6e5243b4389e8
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114606
Bug ID: 114606
Summary: -Whardened doesn't trigger with -fcf-protection=none
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114607
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925
--- Comment #16 from anlauf at gcc dot gnu.org ---
BTW: r12-5767 backports cleanly to 11-branch and regtests cleanly.
I could push it if there are no objections, so that we can finally close
this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114608
Bug ID: 114608
Summary: [14 Regression] Undefined reference in output asm with
-fipa-reference -fipa-reference-addressable
-fsection-anchors -gbtf
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114608
--- Comment #1 from Patrick O'Neill ---
Command:
> /scratch/tc-testing/tc-apr-4/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> -fipa-reference -fipa-reference-addressable -fsection-anchors -gbtf red.c -o
> rv64gcv.out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
Andrew Pinski changed:
What|Removed |Added
CC||lsof at mailbox dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87299
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114610
Bug ID: 114610
Summary: -Wanalyzer-memory-leak reports often far too verbose
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964
--- Comment #3 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:8cd0d29270d4ed86c69b80c08de66dcb6c1e22fe
commit r14-9813-g8cd0d29270d4ed86c69b80c08de66dcb6c1e22fe
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91079
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112490
Barry Revzin changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114609
Bug ID: 114609
Summary: -Waddress false positive
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
Andrew Pinski changed:
What|Removed |Added
CC||arnaud.lb at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114609
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114611
Bug ID: 114611
Summary: H edit descriptor should flag as error with -std-f95
(or higher)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114612
Bug ID: 114612
Summary: Deep copy missing for allocatable derived type
components
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114607
Bug ID: 114607
Summary: aarch64: Incorrect expansion of svsudot
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114608
--- Comment #2 from Patrick O'Neill ---
(.BTF+0x88): undefined reference to `a'
^ This is the interesting failure line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug 94404 depends on bug 91079, which changed state.
Bug 91079 Summary: [DR 1881] Standard-layout classes and unnamed bit-fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91079
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91079
--- Comment #3 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:2b2d3a135a43cbafadd8957e0b2543f38c390437
commit r14-9815-g2b2d3a135a43cbafadd8957e0b2543f38c390437
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:a040eea6b65456625443dcfbf6b21913f2003c8b
commit r13-8589-ga040eea6b65456625443dcfbf6b21913f2003c8b
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
--- Comment #9 from Martin Jambor ---
On master this has been fixed by r14-9813-g8cd0d29270d4ed where I
unfortunately copy-pasted a wrong bug number :-/
I assume this needs backporting to at least gcc-13 and gcc-12. I'll do
that in a week or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114588
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
1 - 100 of 134 matches
Mail list logo
