https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2020-10-08
Ever confirmed|0
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).
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=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=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 #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 #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=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=94761
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
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=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=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 #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=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=97543
--- Comment #9 from Segher Boessenkool ---
Yes, that looks correct.
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=97583
Bug ID: 97583
Summary: Unknown mode_attribute (or iterator) ignored
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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=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=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 #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=97972
--- Comment #2 from Segher Boessenkool ---
Confirmed.
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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98179
Bug ID: 98179
Summary: gcc.dg/pr97954.c fails on (at least) BE powerpc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
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=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=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=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=97786
Bug ID: 97786
Summary: rs6000 isinf etc. are pretty horrible
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97784
Bug ID: 97784
Summary: Expressions evaluated as long chain instead of as tree
or the like
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
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
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
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=97926
--- Comment #1 from Segher Boessenkool ---
Confirmed (needs -O0).
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
--- 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=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=97676
Bug ID: 97676
Summary: "*" should skip a constraint, not just one char of it
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
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
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=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
--- 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
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #23 from Segher
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 #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
--- 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=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=98549
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
Segher Boessenkool changed:
What|Removed |Added
Priority|P1 |P4
--- Comment #3 from Segher
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=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=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=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=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=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
Attachment #49996|0 |1
is obsolete|
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=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 #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 #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=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=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=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 #16 from Segher Boessenkool ---
Needs -mcpu=power8. Confirmed with that (and the given options).
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=98112
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
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=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 #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=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=98210
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
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=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=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=101103
Bug ID: 101103
Summary: -fsanitise=undef gives better help than
-fsanitize=undef
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100953
Bug ID: 100953
Summary: Add memory clobbers just for reads or just for writes
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595
--- Comment #12 from Segher Boessenkool ---
(In reply to H. Peter Anvin from comment #9)
> How is this different from raise(SIGTRAP);?
It does an architecture-specific trap instruction, not a SIGTRAP signal.
The former is useful even if you do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100944
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #14 from Segher Boessenkool ---
We *have* TImode already, but most 128-bit scalars currently use V1TImode.
This often leads to reduced performance because that is not a scalar mode,
does not get all optimisations we have generically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #3 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #2)
> The first test is for _Float128. What goes wrong there?
>
> For all these tests yo
..u have to figure out what is going wrong. After that it will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #2 from Segher Boessenkool ---
The first test is for _Float128. What goes wrong there?
For all these tests yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #14 from Segher Boessenkool ---
(In reply to luoxhu from comment #13)
> It is not visible in combine due to the constant data is in *.LC0 and
combine can see things in the constant pool in various ways though (just
like many other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #12 from Segher Boessenkool ---
(In reply to Bill Schmidt from comment #11)
> Segher, does this fit naturally in combine?
This is just constant folding, combine won't have much to do with it.
It is always better (namely, lower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622
--- Comment #7 from Segher Boessenkool ---
Nice :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #4 from Segher Boessenkool ---
This PR is specifically about the vec_revb builtin. But yes, we should
look at what is generated for all other code (having only the builtin
generate good code is suboptimal for a generic thing like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100953
--- Comment #2 from Segher Boessenkool ---
Sure :-) But syntactically it probably is best put amongst the clobbers,
all code parsing that already knows about handling various special cases
of syntax (well, just "memory" and "cc", and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #12 from Segher Boessenkool ---
We want to use plain TImode instead of V1TImode on newer cpus. It probably is
a good idea (for performance) on p9 already, but this will need testing. That's
only sideways related to this issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc-*-* |powerpc*
Resolution|---
1 - 100 of 803 matches
Mail list logo
