https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98952
--- Comment #2 from Segher Boessenkool ---
And after that it always copies r4 bytes, too (rounded down to a multiple
of four bytes).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #22 from Segher Boessenkool ---
Don't replace the constraints. For one thing, this is very hard to do
correctly. Just make the "m" constraint not allow prefixed memory in
asms, like I said above. (So all "general_operand" even!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98093
--- Comment #6 from Segher Boessenkool ---
(In reply to Martin Liška from comment #5)
> It's fixed on master, can we close it now or do we need a backport to active
> branches?
If someone filled in the known-to-work / known-to-fail fields we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053
--- Comment #11 from Segher Boessenkool ---
Please open a separate bug for x86 problems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960
--- Comment #26 from Segher Boessenkool ---
(In reply to Richard Biener from comment #23)
> (that combine number prevails on trunk as well, I can't spot any code
> that disables combine on large BBs so not sure what goes on here)
There is no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #8 from Segher Boessenkool ---
I say nothing like that. I say that
.text.hot.
is nasty (is easily mistaken for .text.hot).
I also say that and that named-per-function sections are better as
.text%name
than as
.text.name
(just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #6 from Segher Boessenkool ---
I was under the impression this unique section thing needed the trailing
dot thing. This probably is not true.
I still think the old "%" thing is much superior to the trailing dot thing,
but that then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98092
--- Comment #3 from Segher Boessenkool ---
Created attachment 50040
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50040=edit
Patch
Patch in testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #19 from Segher Boessenkool ---
We cannot allow "m" to allow pcrel memory accesses, because most
existing inline assembler code will break then. So we then need
some way to tell the compiler that some instruction *does* allow
pcrel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Segher Boessenkool changed:
What|Removed |Added
Attachment #49996|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #18 from Segher Boessenkool ---
Created attachment 49996
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49996=edit
Patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #17 from Segher Boessenkool ---
(In reply to jos...@codesourcery.com from comment #15)
> Only if the undefined behavior is a property of the program, or of all
> possible executions of the program, as opposed to a property of a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #16 from Segher Boessenkool ---
Needs -mcpu=power8. Confirmed with that (and the given options).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #14 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #13)
> For UB at runtime, we can warn, but shouldn't error because the code might
> never be invoked at runtime.
As far as I can see at least the C standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #12 from Segher Boessenkool ---
for (long i; i != compress_n_blocks; ++i)
"i" is uninitialized; accessing it is UB. So this is ice-on-invalid.
I have no doubt there is an actual bug somewhere here. We just do not
have valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095
--- Comment #2 from Segher Boessenkool ---
Can't we use ".text%name" for -ffunction-sections, like we did originally,
in 1996? See cf4403481dd6. This does not conflict with other section
names, and does not have all the problems you get from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #10 from Segher Boessenkool ---
(And that new test case is full of obvious invalid code as well, fwiw.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #9 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #6)
> The warning often warns on dead code.
> But even if the warning is right, that doesn't make it ice-on-invalid-code.
> The code may have UB at runtime, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
Segher Boessenkool changed:
What|Removed |Added
CC||acsawdey at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #4 from Segher Boessenkool ---
Are you sure that target is correct?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
--- Comment #5 from Segher Boessenkool ---
The "warninb" says
warning: ‘void* memcpy(void*, const void*, long unsigned int)’ writing 32
bytes into a region of size 8 overflows the destination [-Wstringop-overflow=]
It says it is wrong, so it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98549
Segher Boessenkool changed:
What|Removed |Added
Priority|P1 |P4
--- Comment #3 from Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #17 from Segher Boessenkool ---
(What i was referring to in Comment 4 was asm_operand_ok in recog.c --
it may need some surgery if we need to hook into that).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #16 from Segher Boessenkool ---
No, this cannot be fixed in this hook, or in any other hook. The compiler
can never see *at all* what instructions there are, the template is just a
piece of text to it (there could be assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98643
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2021-01-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98645
--- Comment #1 from Segher Boessenkool ---
(In reply to Michael Meissner from comment #0)
> I am tuning up the final patches for providing support to enable the PowerPC
> server compilers to change the default long double from using the IBM
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #11 from Segher Boessenkool ---
(In reply to Bill Schmidt from comment #10)
> But it seems we would also need a new constraint that does permit
> PC-relative addresses, since new code will/may not have a TOC.
How could that work?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #8 from Segher Boessenkool ---
Yes, "m" can not allow PC-relative, in inline asm (just think of all existing
code that uses "m").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #6 from Segher Boessenkool ---
You cannot look at the instruction, ever. The inline asm template is
just text, nothing else. You cannot assume it is valid instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #4 from Segher Boessenkool ---
"m" is already handled differently for inline asm, so perhaps we can just
extend that? ("m" in machine descriptions is "m<>" in asm, for example).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
--- Comment #6 from Segher Boessenkool ---
(In reply to Fangrui Song from comment #5)
> Please read my first comment why copy relocs is a bad name.
Since I reply to some of that (namely, your argument 1)), you could assume I
have read your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #20 from Segher Boessenkool ---
Yes, that is clear... But we have ***double*** x in that example even,
as the declared type of the parameter, so converting that to float is
almost certainly a bad idea?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #18 from Segher Boessenkool ---
Why is it correct to convert the double x to single precision here?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98020
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98178
--- Comment #3 from Segher Boessenkool ---
Yup, this is true in general, we almost never say why we don't combine so
far. Patches welcome! (Make sure you use TDF_DETAILS for such prints).
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
/home/segher/src/gcc/gcc/testsuite/gcc.dg/pr97954.c: In function 'foo':
/home/segher/src/gcc/gcc/testsuite/gcc.dg/pr97954.c:12:1: error: too many
outgoing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #23 from Segher Boessenkool ---
Changing the ABI (silently, even!) is never an expected thing. All of the
four 32-bit ABIs we support have an AltiVec variant that isn't fully
compatible to the non-AltiVec base variant. It would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97972
--- Comment #3 from Segher Boessenkool ---
#0 moving_insn_creates_bookkeeping_block_p (through_insn=0x3fffb5b23138,
insn=0x3fffb5b736c0) at /home/segher/src/gcc/gcc/sel-sched.c:2031
It crashes here because the insn is not in any BB; which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #20 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #18)
> So why don't we default to the Altivec ABI with -m32 on cpus that have
> Altivec and VSX units???
History. I'm not sure all our ABIs are compatible with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #19 from Segher Boessenkool ---
(In reply to Arseny Solokha from comment #17)
> (In reply to Segher Boessenkool from comment #16)
> > Oh, it's a different testcase, in comment 6. Yeah a new PR would
> > have been better ;-/
>
> Do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97972
--- Comment #2 from Segher Boessenkool ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #16 from Segher Boessenkool ---
Oh, it's a different testcase, in comment 6. Yeah a new PR would
have been better ;-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #15 from Segher Boessenkool ---
Why does that compiler default to -mcpu=power10?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97926
--- Comment #1 from Segher Boessenkool ---
Confirmed (needs -O0).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97847
--- Comment #4 from Segher Boessenkool ---
This was caused (or exposed) by e3b3b59683c1:
commit e3b3b59683c1e7d31a9d313dd97394abebf644be
Author: Vladimir N. Makarov
Date: Fri Nov 13 12:45:59 2020 -0500
[PATCH] Implementation of asm goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97847
--- Comment #3 from Segher Boessenkool ---
I can now reproduce it, with a compiler built yesterday (previous was a
few days older), and -O0.
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97847
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #1 from Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97784
--- Comment #6 from Segher Boessenkool ---
(In reply to Richard Biener from comment #3)
> There is targetm.sched.reassociation_width which specifies how re-assocation
> should make such sequence "wide".
Ah cool, thank you :-)
> Andrew is
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
int isfinite(double x) { return __builtin_isfinite (x); }
int isinf(double x) { return __builtin_isinf (x); }
int isinf_sign(double x) { return __builtin_isinf_sign (x); }
int isnan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97784
--- Comment #2 from Segher Boessenkool ---
No, it is exactly the same with unsigned types :-(
Use -Dlong="unsigned long" or use #define O ^ (as in my original test).
I forgot about this signed thing, but it has nothing to do with it (that
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
When compiling something like
#define O +
long x4(long x, long a, long b, long c, long d) { return x O a O b O c O d; }
we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #29 from Segher Boessenkool ---
(In reply to Richard Biener from comment #26)
> So it would need to be diagnosed in the FE (only), making a + 0 valid and
> a not. Eh.
We do not *have* to diagnose anything, certainly not things that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #28 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #25)
> Even if we wanted to do something about it (which I disagree with, e.g.
> given that the implementation matches the documentation), you run into the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #27 from Segher Boessenkool ---
(In reply to Alexander Monakov from comment #24)
> Segher, did you really mean to mark the bug resolved/fixed?
No, if I did that, I have no idea how :-)
> Given that the only supported use of local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #23 from Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #21 from Segher Boessenkool ---
register float foo asm ("xmm0") = 0.99f;
asm volatile("movl %0, %%r8d\n\t"
"vmcall\n\t"
:: "g" (foo));
The user said operands[0] should go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #19 from Segher Boessenkool ---
Documenting that GCC behaves differently is just documenting a bug :-(
It should not be hard to detect this and give an error somewhere?
Saying "the user did something wrong" is true of course, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
iority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
See https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557759.html and
the thread leading up to it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
--- Comment #9 from Segher Boessenkool ---
Yes, that looks correct.
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
This leads to errors at compiler runtime instead of at compiler build time.
See https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556998.html .
Code from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
--- Comment #3 from Segher Boessenkool ---
This part of the attribute (all but the low 2 bits) is not documented
in the as manual, btw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #31 from Segher Boessenkool ---
Performing a jump based on the carry bit is not something we can
easily do (there are no simple insns for it, and those sequences
that will do the trick are expensive). But I'll look at that,
thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #29 from Segher Boessenkool ---
Yup, and that is a more elegant way of writing this anyway. But we
still do not handle the exact testcase code optimally ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #46 from Segher Boessenkool ---
(In reply to Christophe Leroy from comment #43)
> int g(int x)
> {
> return __builtin_clz(0);
> }
>
> Gives
>
> 0018 :
> 18: 38 60 00 20 li r3,32
> 1c: 4e 80 00 20 blr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #35 from Segher Boessenkool ---
Send it to gcc-patches@ please, with explanation and everything?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #26 from Segher Boessenkool ---
It isn't easy to do. Feel free to try your hand at it :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #31 from Segher Boessenkool ---
(In reply to Jan Hubicka from comment #27)
> It is because --param inline-insns-single was reduced for -O2 from 200
> to 70. GCC 10 has newly different set of parameters for -O2 and -O3 and
> enables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94761
--- Comment #3 from Segher Boessenkool ---
Commit e69bf64be925 added the host and target flags originally, and it
seems to have been just a mistake that is used --build=${build_alias}
--host=${build_alias}. (Now of course that has spread to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94761
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97437
--- Comment #10 from Segher Boessenkool ---
Not even an alternative SELECT_CC_MODE; just add an argument to it, giving
the original mode? We already have that in combine, so we can trivially
pass it. Will that work for x86 here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97437
--- Comment #8 from Segher Boessenkool ---
So is that something than can/should be improved in ix86_cc_mode?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97437
--- Comment #6 from Segher Boessenkool ---
I forgot to add: subtract immediate is the same as add immediate for us,
we don't change the sense of the carry bit to a "borrow bit" (and instead,
we have a subtract-from-immediate). But this doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97437
--- Comment #5 from Segher Boessenkool ---
Trying 7 -> 9:
7: r97:SI=0x2a
9: {flags:CCC=cmp(r97:SI+r98:SI,r97:SI);r99:SI=r97:SI+r98:SI;}
REG_DEAD r98:SI
REG_DEAD r97:SI
Failed to match this instruction:
(parallel [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97249
--- Comment #5 from Segher Boessenkool ---
(In reply to Richard Biener from comment #3)
> Guess you want to figure what built the (vec_select:V8QI (V16QI)) and if
> it was appropriately simplified (and simplify_rtx would handle this case).
> In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
--- Comment #8 from Segher Boessenkool ---
The default -mcpu= for a compiler targeting powerpc64le-linux is
normally power8 (you can change this with the --with-cpu= configure
option though). -mcpu=powerpc64le is also (currently) equal to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
--- Comment #5 from Segher Boessenkool ---
So both the cache line size and the cache size are wrong for GCC 10
and before, but okay on trunk, on all compiler I tested (I tested on
Linux only so far).
|1
Status|UNCONFIRMED |NEW
CC||segher at gcc dot gnu.org
--- Comment #3 from Segher Boessenkool ---
At least as far back as GCC 5 we report D-L1 size 64kB (for most CPUs,
not just p9). Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97163
--- Comment #7 from Segher Boessenkool ---
Ah.
Is there no better way to detect GCC impostors? Oh well.
Since we require 4.5 as bootstrap compiler, this makes no difference
at all for compilers that truthfully claim to be GCC, so it has my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97163
--- Comment #5 from Segher Boessenkool ---
Yeah, good point.
So either we can convert to the normal intrinsics, or (much easier)
check we are building with GCC at all. But why 4.5? Do earlier
versions not work?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97163
--- Comment #3 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #2)
> Guess we need something like:
> -#elif defined(_ARCH_PWR8) && defined(__ALTIVEC__)
> +#elif (GCC_VERSION >= 4005) && defined(_ARCH_PWR8) &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #8 from Segher Boessenkool ---
I don't think we have an instruction for that? But we can inline the
code we need instead of doing a library call, which is much faster.
(We probably can use FMAs here usefully, btw; maybe even without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710
--- Comment #16 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #15)
> Fixed.
Yes. Thanks!
|NEW
CC||segher at gcc dot gnu.org
Last reconfirmed||2020-09-16
--- Comment #6 from Segher Boessenkool ---
Confirmed.
Maaybe cse2 should do this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2020-09-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
--- Comment #8 from Segher Boessenkool ---
(In reply to Alan Modra from comment #7)
> and of course, li 0x is li -1 which sets all bits.
Erm, yes. Duh.
So that g:5d3ae76af13 splitter should not fire for numbers that fit in
32 bits but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
--- Comment #26 from Segher Boessenkool ---
What Joseph says in c#25. Also, the documentation currently says
The @code{KIND} value matches the storage size in bytes, [...]
which will have to change, too (the standard does not require this,
it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
--- Comment #5 from Segher Boessenkool ---
So hrm, why did GCC generate lis 0x ; ori 0x ; rldicl instead of
li 0x ; oris 0x ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #20 from Segher Boessenkool ---
Could you guys please test the attached patch? Thanks in advance!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #19 from Segher Boessenkool ---
Created attachment 49215
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49215=edit
proposed patch for the ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
Segher Boessenkool changed:
What|Removed |Added
Attachment #49214|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
--- Comment #3 from Segher Boessenkool ---
Created attachment 49214
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49214=edit
proposed patch for the ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
--- Comment #18 from Segher Boessenkool ---
I have a patch.
701 - 800 of 3115 matches
Mail list logo
