https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113595
Bug ID: 113595
Summary: Confusing 'goto' is not a constant expression error
message in constructor at compile time
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113595
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-01-25
Summary|Confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113548
--- Comment #7 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:e7d7c9e889ae8553b9aac79e6944d70702f8ee53
commit r14-8417-ge7d7c9e889ae8553b9aac79e6944d70702f8ee53
Author: Andrew Pinski
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113548
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
Hongtao Liu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275
--- Comment #4 from Richard Biener ---
Since this was a costing change I wonder if we identified the code change
responsible and thus have a testcase? I realize that for maximum assurance
one would need to have a debug counter for switching the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113522
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #4 from Jian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90582
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #2 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113588
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #6 from rguenther at suse dot de ---
On Thu, 25 Jan 2024, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
>
> --- Comment #5 from JuzheZhong ---
> Both ICC and Clang X86 can vectorize SPEC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #12 from rguenther at suse dot de ---
On Thu, 25 Jan 2024, liuhongt at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
>
> --- Comment #7 from Hongtao Liu ---
> diff --git a/gcc/fold-const.cc b/gcc/fol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #7 from JuzheZhong ---
(In reply to rguent...@suse.de from comment #6)
> On Thu, 25 Jan 2024, juzhe.zhong at rivai dot ai wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
> >
> > --- Comment #5 from JuzheZhong ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #13 from Richard Sandiford ---
I don't think there's any principle that upper bits must be zero.
How do we end up with a pattern that depends on that being the case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
Bug ID: 113596
Summary: Stack memory leakage caused by inline alloca
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #8 from Richard Biener ---
(In reply to JuzheZhong from comment #7)
>
> But I wonder if we see it is beneficial on some boards, could you teach us
> how we can enable vectorization for such case according to uarchs ?
If you figure h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #1 from Andrew Pinski ---
Why do you think this is a bug?
You are forcing a function which calls alloca to be inlined, GCC DOES not
normally inline functions which call alloca due to not restoring the stack
pointer after the return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113522
--- Comment #5 from Jonathan Wakely ---
(In reply to Jiang An from comment #4)
> Hmm... currently it's specified in [algorithms.requirements] that
> > The well-formedness and behavior of a call to an algorithm with an
> > explicitly-specified t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #2 from Andrew Pinski ---
You could instead use VLA which is done correctly though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
Andrew Pinski changed:
What|Removed |Added
Keywords||documentation
--- Comment #3 from Andre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113522
--- Comment #6 from Jonathan Wakely ---
I'd also like to ban it for std::make_pair, but that would break loads of very
silly code that does std::make_pair(a,b) (c.f. Bug 92300 comment 3).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #4 from John Sanpe ---
(In reply to Andrew Pinski from comment #1)
> Why do you think this is a bug?
>
> You are forcing a function which calls alloca to be inlined, GCC DOES not
> normally inline functions which call alloca due to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113588
--- Comment #4 from Tamar Christina ---
The change Richi made this morning to only allow may_be_zero for the last exit
makes it not rotate this loop anymore.
However the bug is simply that if the final exit has a memory access it should
be che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #5 from John Sanpe ---
(In reply to Andrew Pinski from comment #3)
> The documentation should be more clear on this though.
But adding a hint would also be reasonable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267
--- Comment #15 from Maxim Kuvyrkov ---
(In reply to Maxim Kuvyrkov from comment #13)
> We are seeing scan-assembler failures in a single 32-bit arm test. This
> affects both linux and bare-metal targets: arm-linux-gnueabihf and
> arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113522
--- Comment #7 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #6)
> I'd also like to ban it for std::make_pair, but that would break loads of
> very silly code that does std::make_pair(a,b) (c.f. Bug 92300 comment
> 3).
Note G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113590
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
Maxim Kuvyrkov changed:
What|Removed |Added
CC||mkuvyrkov at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70730
--- Comment #3 from Manuel López-Ibáñez ---
(In reply to Eric Gallager from comment #2)
> (In reply to Manuel López-Ibáñez from comment #1)
> > If not, this then depends on PR43486
>
> (that's now fixed, btw... so maybe that's had an impact on t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
John Sanpe changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113592
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #4 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #7 from Richard Biener ---
In theory, if somebody really wanted it, we could replace alloca with
__builtin_stack_save/restore during inlining (not sure if it would
simply work, and be efficient, by just putting save at the start of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
Hongtao Liu changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #15 from Richard Biener ---
(In reply to Richard Sandiford from comment #13)
> I don't think there's any principle that upper bits must be zero.
> How do we end up with a pattern that depends on that being the case?
I think the prob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112470
--- Comment #10 from Andrew Pinski ---
The instruction increase is 2:
sub sp, sp, #128
...
stp x29, x30, [sp, 112]
vs:
stp x29, x30, [sp, -128]!
and
ldp x29, x30, [sp, 112]
...
add s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112470
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113577
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109227
Andrew Pinski changed:
What|Removed |Added
CC||usaxena95 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
Bug ID: 113597
Summary: [14 Regression] aarch64: Significant code quality
regression since r14-8346-ga98d5130a6dcff
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #1 from Richard Biener ---
I will have a look - but can you explain for me what I see? I suppose the
testcase was reduced from something?
Is the assembly diff complete? That is, do we really have more fmla or
are they just moved?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #2 from Alex Coplan ---
(In reply to Richard Biener from comment #1)
> I will have a look - but can you explain for me what I see? I suppose the
> testcase was reduced from something?
Yeah, the testcase is reduced.
>
> Is the ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #3 from Alex Coplan ---
Created attachment 57210
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57210&action=edit
before.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #4 from Alex Coplan ---
Created attachment 57211
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57211&action=edit
after.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #5 from Andrew Pinski ---
Note I think this testcase has been reduced too much, but maybe that can be
"fixed". The stores to the arguments go past the bounds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #6 from Alex Coplan ---
Looking at the dump files, the first difference seems to be in 292r.dse1:
8: NOTE_INSN_BASIC_BLOCK 2
2: r116:SI=zero_extend(x0:HI)
REG_DEAD x0:HI
@@ -178,7 +161,26 @@
5: NOTE_INSN_FUNCTI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #7 from Alex Coplan ---
I expect the store pairs come from memcpy lowering/expansion in the aarch64
backend, that is the only way we get store pairs so early in the RTL pipeline
IIRC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #8 from Andrew Pinski ---
(In reply to Alex Coplan from comment #7)
> I expect the store pairs come from memcpy lowering/expansion in the aarch64
> backend, that is the only way we get store pairs so early in the RTL
> pipeline IIRC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #9 from Alex Coplan ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Alex Coplan from comment #7)
> > I expect the store pairs come from memcpy lowering/expansion in the aarch64
> > backend, that is the only way we get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #10 from Richard Biener ---
Created attachment 57212
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57212&action=edit
patch for debugging
Btw, I've used the attached to investigate other issues with the change. It
will show t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113485
--- Comment #8 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:f251bbfec9174169510b2dec14b9bf763e7b77af
commit r14-8420-gf251bbfec9174169510b2dec14b9bf763e7b77af
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113550
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:8eead1148cd0ac086b39a7abccea404041c85cb5
commit r14-8421-g8eead1148cd0ac086b39a7abccea404041c85cb5
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113572
--- Comment #6 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:c3de14ba1ba0e77254118af64ed881f115ee42a0
commit r14-8422-gc3de14ba1ba0e77254118af64ed881f115ee42a0
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113572
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113485
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113550
Richard Sandiford changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113574
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:fb1b7e2fec951ba0bf4f68fac6a16929f4f63910
commit r14-8423-gfb1b7e2fec951ba0bf4f68fac6a16929f4f63910
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113574
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #16 from Richard Sandiford ---
(In reply to Richard Biener from comment #15)
> I think the problem is the cbranch pattern which looks at all of the
> QImode mask - but of course it doesn't know it's really V4BImode it's
> working on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113598
Bug ID: 113598
Summary: GCC internal compiler error
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
Bug ID: 113599
Summary: Wrong computation of member offset through
pointer-to-member
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-01-25
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113422
--- Comment #2 from Jan Hubicka ---
Cycling read-only var discovery would be quite expensive, since you need to
interleave it with early opts each round. I wonder how llvm handles this?
I think there is more hope with IPA-PTA getting scalable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #17 from Tamar Christina ---
Well the mid-end has generated the right precision. The type it generates is
vector(4) vexit_reduc_67;
so it does say it's a single bit boolean.
Isn't this just an expand problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
--- Comment #3 from Jakub Jelinek ---
The problem is in that typeck2.cc change:
- datum = fold_build_pointer_plus (fold_convert (ptype, datum),
component);
+ datum = cp_convert (ptype, datum, complain);
+ if (!processing_template_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
--- Comment #13 from Richard Biener ---
(In reply to Robin Dapp from comment #12)
> Created attachment 57209 [details]
> Tentative
>
> I tested the attached "fix". On my machine with 13.2 host compiler it
> reduced the build time for insn-opin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113538
--- Comment #1 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:acc22d56e140220e7dc6c138918cb6754b6d1c0b
commit r14-8424-gacc22d56e140220e7dc6c138918cb6754b6d1c0b
Author: Yanzhang Wang
Date: Thu Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
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=113538
Yanzhang, Wang changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #18 from Richard Sandiford ---
(In reply to Tamar Christina from comment #17)
> Well the mid-end has generated the right precision. The type it generates is
> vector(4) vexit_reduc_67;
> so it does say it's a single bit boolean.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #11 from Richard Biener ---
In DSE the only differences is
fbt (0x751a1a50: (plus:DI (reg/v/f:DI 117 [ u ])
-(reg:DI 146 [ _44 ]))) == (address 0)
+(reg:DI 146 [ _44 ]))) == (nil)
fbt (0x7700b3c0: (reg/f:DI 64 sfp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113597
--- Comment #12 from Richard Biener ---
Created attachment 57214
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57214&action=edit
prototype fix
The attached prototype fixes the testcase for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #19 from rguenther at suse dot de ---
On Thu, 25 Jan 2024, rsandifo at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
>
> --- Comment #18 from Richard Sandiford ---
> (In reply to Tamar Christina from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #9 from Jakub Jelinek ---
Created attachment 57215
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57215&action=edit
gcc14-pr113596.patch
Untested patch to do that.
The disadvantage of doing that is that it may penalize inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863
--- Comment #5 from Iain Sandoe ---
(In reply to Rainer Orth from comment #4)
> On macOS 11, everything is still fine. On macOS 14, there's progress:
> The remaining failures fall into two categories:
>
> FAIL: obj-c++.dg/encode-10.mm -fgnu-r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113600
Bug ID: 113600
Summary: 525.x264_r run-time regresses by 8% with PGO -Ofast
-march=znver4
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #10 from Richard Biener ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 57215 [details]
> gcc14-pr113596.patch
>
> Untested patch to do that.
> The disadvantage of doing that is that it may penalize inline calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113596
--- Comment #11 from Jakub Jelinek ---
In reply to Richard Biener from comment #10)
> We can make ->calls_alloca more precise though of course
> we usually also do not want to inline functions with VLAs.
Yes. Or remember while inlining whether
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
--- Comment #14 from Robin Dapp ---
Ok, running tests with the adjusted version and going to post a patch
afterwards.
However, during a recent run compiling insn-recog took 2G and insn-emit-7 as
well as insn-emit-10 required > 1.5G each. Looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599
--- Comment #5 from Patrick Palka ---
D'oh, sorry for the breakage.
(In reply to Jakub Jelinek from comment #3)
> If no checking is needed, then it could be just datum = build_nop (ptype,
> datum);
> if we don't want folding.
Makes sense to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112969
--- Comment #2 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:6426d466779fa889bca170e3ff80dbfc6ea8c2e8
commit r14-8428-g6426d466779fa889bca170e3ff80dbfc6ea8c2e8
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112969
--- Comment #3 from David Malcolm ---
Should be fixed on trunk for gcc 14 by the above patch.
Keeping open to track backporting this to other branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113598
Marek Polacek changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113558
--- Comment #4 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:90880e117aa70a5ecd9b7df4381410c2ea0dcfdb
commit r14-8429-g90880e117aa70a5ecd9b7df4381410c2ea0dcfdb
Author: Robin Dapp
Date: Tue Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971
--- Comment #23 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:660e17f00658b68115282e6de38243e3c6cc1ee2
commit r14-8430-g660e17f00658b68115282e6de38243e3c6cc1ee2
Author: Robin Dapp
Date: Mon Ja
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
--- Comment #20 from Alex Coplan ---
I think the testcase in #c10 went latent on the 13 branch but the following
(reduced from the attachment) still ICEs on the tip of the 13 branch with
-Ofast -fopenmp -fstack-protector-strong:
typedef struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113598
Andrew Pinski changed:
What|Removed |Added
Summary|GCC internal compiler error |[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113600
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113598
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113598
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113598
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113336
Victor Do Nascimento changed:
What|Removed |Added
CC||victor.donascimento at arm dot
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903
--- Comment #14 from Jonathan Wakely ---
Yes, that part's easy (and that's what we do in std::format for errors during
format string parsing). But accepting (a <=> b) < (1-1) and other zero-valued
constant expressions can't be solved by improvin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112987
--- Comment #3 from GCC Commits ---
The master branch has been updated by Szabolcs Nagy :
https://gcc.gnu.org/g:305fe4f136a3a3a78377a48c55d546000a3ba529
commit r14-8432-g305fe4f136a3a3a78377a48c55d546000a3ba529
Author: Szabolcs Nagy
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113601
Bug ID: 113601
Summary: avr: Wrong SRAM start for ATmega3208 and ATmega3209
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113601
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113601
--- Comment #1 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:6b678d8f96ad5ffb8de9e3f1f1694cb21d7a2c33
commit r14-8433-g6b678d8f96ad5ffb8de9e3f1f1694cb21d7a2c33
Author: Georg-Johann Lay
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113601
--- Comment #2 from GCC Commits ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
:
https://gcc.gnu.org/g:fe3093ca9333965ec00d43ed2e24e594901a6ff9
commit r13-8252-gfe3093ca9333965ec00d43ed2e24e594901a6ff9
Author: Georg-Johann
1 - 100 of 183 matches
Mail list logo
