https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #22 from Richard Biener ---
(In reply to Jonathan Wakely from comment #20)
> (In reply to Jakub Jelinek from comment #16)
> > (In reply to Richard Biener from comment #15)
> > > where if I understand you correctly, bar () is not allo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #21 from Richard Biener ---
(In reply to Jakub Jelinek from comment #19)
> And on
> void bar (void);
> struct X {
> X (int);
> int i;
> int j;
> void baz (int);
> };
>
> X::X(int k)
> {
> i = k;
> bar ();
> j = i != k;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770
--- Comment #9 from Surya Kumari Jangala ---
RTL after dfinit pass for the vec_sub() and the vec_extract():
(insn 13 12 14 2 (set (reg:V2DI 132 [ vrD.3952 ])
(minus:V2DI (subreg:V2DI (reg:V2DF 117 [ _1 ]) 0)
(subreg:V2DI (re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770
--- Comment #8 from Surya Kumari Jangala ---
While the first two xxpermdi's are fine, the 3rd one is a bug. It is incorrect.
Here is the C code inlined into assembly:
_Z4cmp2dd:
.LFB1:
.cfi_startproc
// vector double va = ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974
Thomas Rodgers changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974
--- Comment #4 from Thomas Rodgers ---
(In reply to Jiang An from comment #3)
> > is_nothrow_invocable_v shall be true.
>
> If implementation divergence is not intendedly permitted, I don't think it
> makes much sense to introduce UB in this wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #3 from Jian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #14 from Andrew Pinski ---
So the problem is host_extra_objs gets included in libbackend.a but since
nothing references it inside the static library, it does not get linked into
the cc1 ...
Looks like other changes are needed to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #13 from Costas Argyris ---
With the changes in the attached patch, the utf8 object file gets linked into
gcc.exe but not cc1.exe - How can I achieve this?Basically this object file
has to be linked pretty much in every executabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107574
Marek Polacek changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107574
--- Comment #7 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:de81e06273c613d7e06cbe2c8d9e72826c638056
commit r13-6400-gde81e06273c613d7e06cbe2c8d9e72826c638056
Author: Marek Polacek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #6 from Kees Cook ---
I really want to avoid the changes to sizeof() -- this will confuse a lot of
other things. Sizeof is expected to be a constant expression, for example.
I think the attribute is best since it avoids colliding wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Richard Biener from comment #2)
> > Iff only (GNU) C would accept the following ...
> >
> > struct foo {
> > ...
> > unsigned i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #6 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
--- Comment #3 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:24ebc5404b88b765221b551dc5288f6d64ba3dc7
commit r13-6398-g24ebc5404b88b765221b551dc5288f6d64ba3dc7
Author: David Malcolm
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565
--- Comment #5 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:24ebc5404b88b765221b551dc5288f6d64ba3dc7
commit r13-6398-g24ebc5404b88b765221b551dc5288f6d64ba3dc7
Author: David Malcolm
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
Andrew Pinski changed:
What|Removed |Added
Keywords||internal-improvement
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
--- Comment #1 from David Malcolm ---
Replacement stmt is created here:
(gdb) bt
#0 gimple_set_op (gs=, i=1, op=) at ../../src/gcc/gimple.h:2629
#1 0x01093a6f in gimple_build_call_1 (fn=,
nargs=4) at ../../src/gcc/gimple.cc:234
#2 0x0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
Bug ID: 108988
Summary: gimple_fold_builtin_fputs doesn't preserve
gimple_builtin_call_types_compatible_p
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856
--- Comment #4 from anlauf at gcc dot gnu.org ---
Created attachment 54567
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54567&action=edit
Updated patch
The original patches started to bit-rot, so here is an updated version.
The current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108973
Andrew Pinski changed:
What|Removed |Added
Summary|Sufficiently narrow |[13 Regression]
|term
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108973
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108987
--- Comment #1 from Vineet Gupta ---
Fix posted here
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613106.html
Essentially:
case PLUS:
if (TARGET_ZBA
&& mode == word_mode
&& GET_CODE (XEXP (x, 0)) == MULT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108987
Bug ID: 108987
Summary: [13 Regression] RISC-V: shiftadd cost model bug
needlessly preferring syth_multiply
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219
Patrick Palka changed:
What|Removed |Added
Known to work||13.0
Summary|[12/13 Regressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218
--- Comment #14 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:096f034a8f5df41f610e62c1592fb90a3f551cd5
commit r13-6395-g096f034a8f5df41f610e62c1592fb90a3f551cd5
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219
--- Comment #3 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:096f034a8f5df41f610e62c1592fb90a3f551cd5
commit r13-6395-g096f034a8f5df41f610e62c1592fb90a3f551cd5
Author: Patrick Palka
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
--- Comment #9 from Thiago Macieira ---
Ah, got it. That also explains why I couldn't find anything wrong with my code,
and nothing I did that could likely be it made the warning go away.
Thanks for the quick turnaround.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
--- Comment #8 from Andrew Pinski ---
(In reply to Thiago Macieira from comment #7)
> The duplicate "note:" disappeared. But now there's no warning at all on the
> same file, with the same options. Was that intended?
Yes that was the intent of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
--- Comment #1 from Keith Thompson ---
A similar case. The warning refers to the size in bytes, but unlike
the first case it's not incorrect, though referring to the length
would IMHO be clearer.
Note also that the warning appears twice. It onl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
Bug ID: 108986
Summary: Incorrect warning for [static] array parameter
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
--- Comment #7 from Thiago Macieira ---
The duplicate "note:" disappeared. But now there's no warning at all on the
same file, with the same options. Was that intended?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639
--- Comment #4 from Steve Kargl ---
On Wed, Mar 01, 2023 at 05:51:29PM +, cessenat at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639
>
> --- Comment #2 from Olivier Cessenat ---
> integer(kind=4) valid range is -2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
--- Comment #15 from Jakub Jelinek ---
And please stop reopening this bugzilla bug. There is no bug on the GCC side,
and this should be handled on gcc-help mailing list, not here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980
--- Comment #6 from Thiago Macieira ---
Testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
vinay kumar changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639
--- Comment #2 from Olivier Cessenat ---
integer(kind=4) valid range is -2147483648_4 to +2147483647_4.
So I consider this is a gfortran bug.
Moreover, if -2147483648_4 is considered out of range, why
-2147483647_4 - 1_4 is not ? Constant elimin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
vinay kumar changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
vinay kumar changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #12 from Costas Argyris ---
Sent email to binutils about possible windres issue/limitation:
https://sourceware.org/pipermail/binutils/2023-March/126361.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106259
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959
--- Comment #7 from Martin Jambor ---
The situation is that in func_61 we have an unused parameter which
IPA-SRA wants to remove. It's caller constructs the unused parameter
with the following sequence (shortened):
int func_43 (int * p_44)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106259
--- Comment #4 from Marek Polacek ---
I know, in principle, how to fix it, but currently I'm struggling with getting
struct A::W
from
struct A::W
That we haven't found struct A::W in class2loc is actually OK, we don't
have a A specialization, s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #20 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Richard Biener from comment #15)
> > where if I understand you correctly, bar () is not allowed to modify *this
> > (unless I pass it an argumen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
Patrick Palka changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108985
Bug ID: 108985
Summary: new test case gcc.dg/vect/pr108950.c from
r13-6384-ge3837b6f6c28a1 fails
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
--- Comment #10 from Sam Mish ---
Great-- thanks for finding such a small reproducer, Andrew.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959
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=81675
Marcin Kowalczyk changed:
What|Removed |Added
CC||qrczakmk at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #19 from Jakub Jelinek ---
And on
void bar (void);
struct X {
X (int);
int i;
int j;
void baz (int);
};
X::X(int k)
{
i = k;
bar ();
j = i != k;
}
void
X::baz(int k)
{
i = k;
bar ();
j = i != k;
}
while I see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #18 from Jakub Jelinek ---
Does the FE really do that?
I certainly don't see it in the gimple dump:
void X::X (struct X * const this, int k)
{
*this = {CLOBBER};
{
this->i = k;
# USE = anything
# CLB = anything
ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #17 from Richard Biener ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Richard Biener from comment #15)
> > The compiler doesn't know that the allocation function cannot clobber *this.
> > The C++ frontend tries to c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565
--- Comment #4 from David Malcolm ---
Created attachment 54565
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54565&action=edit
Patch that reworks builtin handling
I've been testing this patch, but it might be too invasive at this point i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545
--- Comment #6 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:3843dc1460259fbca1f336b0259f0b6b527d77ae
commit r13-6394-g3843dc1460259fbca1f336b0259f0b6b527d77ae
Author: Tobias Burnus
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #15 from Richard Biener ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to Richard Biener from comment #11)
> > We can again work around this in libstdc++ by CSEing ->_M_size ourselves.
> > The following helps:
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108935
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
--- Comment #8 from Richard Biener ---
I realized I have some value-range patches in the tree where I ran into this
(besides the pending dwarf2out change). I'm now trying to reproduce on
r13-6384-ge3837b6f6c28a1 without changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108935
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:070523b9d4c6cfa69060255893006efaf39bf617
commit r13-6393-g070523b9d4c6cfa69060255893006efaf39bf617
Author: David Malcolm
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
--- Comment #58 from CVS Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:f769d22ab685671095525d09ef29d0ae3cee
commit r13-6392-gf769d22ab685671095525d09ef29d0ae3cee
Author: LIU Hao
Date: Tue May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
--- Comment #7 from Jakub Jelinek ---
Isn't what happens in i386.cc more like:
void foo (long);
int data[128];
static int bar (int i, long j)
{
if (j >= -64 && j <= 64)
return data[j+64];
foo (j);
}
int baz (unsigned int j)
{
int k =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
--- Comment #6 from Richard Biener ---
Estimating body: gen_rtx_CONST_INT.constprop/2274667
Known to be false: not inlined, op1,((unsigned long) #),(# + 64) > 128
size:6 time:4.533600 nonspec time:7.533600 loops with known
iterations:0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
--- Comment #5 from Richard Biener ---
But
void foo ();
int data[128];
static int bar (int i, int j)
{
if (j > -64 && j < 64)
return data[j+64];
foo ();
}
int baz (int j)
{
return bar (0, j);
}
seems to work fine with -O2 -fno-early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
--- Comment #4 from Richard Biener ---
So there's interesting IPA summary on gen_rtx_CONST_INT.constprop/2274667
find_slot_with_hash.constprop/2274668 function not considered for inlining
freq:0.49 loop depth: 0 size: 6 time: 15 calle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108546
--- Comment #3 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:96ff97ff6574666a5509ae9fa596e7f2b6ad4f88
commit r13-6390-g96ff97ff6574666a5509ae9fa596e7f2b6ad4f88
Author: Tobias Burnus
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839
--- Comment #5 from Jakub Jelinek ---
Not on the trunk. Note, the r13-4460, r13-4461, r13-5379 changes PR84469
changes weren't backported to older branches intentionally, it is quite risky
and had multiple follow-ups.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839
--- Comment #4 from northon_patrick3 at yahoo dot ca ---
Actually is still crash even on valid code:
```
template
void
foo (const T &x)
{
[&] (auto&& y)
{
#pragma omp parallel for
for (auto&& [v1, v2] : x)
;
} ([]{});
}
str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839
--- Comment #3 from Jakub Jelinek ---
Created attachment 54564
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54564&action=edit
gcc13-pr105839.patch
Untested fix for the error recovery issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839
Jakub Jelinek changed:
What|Removed |Added
Keywords|ice-on-valid-code |
--- Comment #2 from Jakub Jelinek ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
--- Comment #9 from Andrew Pinski ---
The trunk ICE is definitely lambda related:
/* Lambda closures are regenerated in tsubst_lambda_expr, not
instantiated here. */
gcc_assert (!LAMBDA_TYPE_P (template_type));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
--- Comment #8 from Andrew Pinski ---
A slightly more reduced:
int h(int);
template
auto hh() { return 0; }
template
void mm() {
const unsigned num_elements = 1;
constexpr int dim = 1;
[&]() {
typedef d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
Andrew Pinski changed:
What|Removed |Added
Known to work||8.2.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-03-01
Keywords|needs-red
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
Richard Biener changed:
What|Removed |Added
Target||x86_64-linux
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108971
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #11 from Costas Argyris ---
Capturing another data point:
I hex-compared an executable before and after applying the UTF-8 manifest with
mt.exe just to try and see what it does, and I noticed a few things:
1) The executable size wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Gaius Mulley ---
> Do the above fixes resolve this PR ?
The revised version did indeed. I'd included it in last night's
bootstraps and everything is fine again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956
--- Comment #6 from Gaius Mulley ---
Do the above fixes resolve this PR ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
Bug ID: 108984
Summary: [13 Regression] LTO bootstrap causes testsuite ICE
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
--- Comment #15 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f72c8918416f67aad907752f1892c19eda12eecb
commit r13-6389-gf72c8918416f67aad907752f1892c19eda12eecb
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967
Jakub Jelinek changed:
What|Removed |Added
Summary|internal compiler error: in |[11/12 Regression] internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108606
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:520403f324a6ed8b527f39239709dd0841b992e2
commit r13-6388-g520403f324a6ed8b527f39239709dd0841b992e2
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108606
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b222e725f53231a0bd9799ca93892a79d592a5f3
commit r13-6387-gb222e725f53231a0bd9799ca93892a79d592a5f3
Author: Jakub Jelinek
Date: W
1 - 100 of 111 matches
Mail list logo
