https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #17 from Segher Boessenkool ---
(In reply to Andreas Krebbel from comment #16)
> (In reply to Segher Boessenkool from comment #15)
> > (In reply to Andreas Krebbel from comment #14)
> > > > So you are suggesting that every strict_low
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #15 from Segher Boessenkool ---
(In reply to Andreas Krebbel from comment #14)
> > So you are suggesting that every strict_low_part after reload can just be
> > removed? If that is true, should we not just do exactly that then?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #13 from Segher Boessenkool ---
(Sorry I missed this)
(In reply to Andreas Krebbel from comment #11)
> I've tried to change our movstrict backend patterns to use a predicate on
> the dest operand which enforces a subreg. However, si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #27 from Segher Boessenkool ---
So this particular bug is no longer there, and this PR can be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #19 from Segher Boessenkool ---
Hi guys,
What testcases are still failing? I'm a bit lost :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #9 from Segher Boessenkool ---
(In reply to Alan Modra from comment #8)
> (In reply to Segher Boessenkool from comment #7)
> > '-fpatchable-function-entry=N[,M]'
> > Generate N NOPs right at the beginning of each function, with t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #7 from Segher Boessenkool ---
'-fpatchable-function-entry=N[,M]'
Generate N NOPs right at the beginning of each function, with the
function entry point before the Mth NOP.
The nops have to be consecutive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96786
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103498
--- Comment #2 from Segher Boessenkool ---
Mike, do you still see this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #3 from Segher Boessenkool ---
Your second option isn't correct: all these nops should be consecutive. Your
option 1 is fine :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #28 from Segher Boessenkool ---
(In reply to rsand...@gcc.gnu.org from comment #25)
> - On big-endian targets, vector loads and stores are assumed to put the
> first memory element at the most significant end of the vector register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #27 from Segher Boessenkool ---
IMO what vec_select calls element 0 is always in the first argument of the
vec_concat it works on, in BE as well as LE. But yes this is quite
underdefined
in our documentation, and who know what is ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106419
--- Comment #10 from Segher Boessenkool ---
(In reply to Kewen Lin from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > So for which pseudo and which hard register did this ICE, and what did the
> > code look like at that poin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106419
--- Comment #8 from Segher Boessenkool ---
So for which pseudo and which hard register did this ICE, and what did the
code look like at that point?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106419
--- Comment #7 from Segher Boessenkool ---
That mfctr;mtctr is extremely slow of course, and that mtctr is superfluous
completely (this is true for all registers, not just CTR, nothing special to
PowerPC even). I know this is just -Og, but stil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #11 from Segher Boessenkool ---
I mean, if that patch is actually flawed, this is GCC 12 and latter; if the
problem is more generic (combine, probably simplify-rtx to be exact) it is
more widespread.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #10 from Segher Boessenkool ---
This happened after
commit 0910c516a3d72af048af27308349167f25c406c2
Author: Xionghu Luo
Date: Tue Oct 19 04:02:04 2021 -0500
which probably caused it. That means it would be GCC 12 and later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106091
--- Comment #4 from Segher Boessenkool ---
That patch looks good :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #13 from Segher Boessenkool ---
(In reply to Alexander Grund from comment #11)
> Some more experiments with GCC 10.3, OpenBLAS 0.3.15 and FlexiBLAS 3.0.4:
>
> Baseline: Broken at -O1, working at -Og
>
> I got it to break with "-Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #12 from Segher Boessenkool ---
(In reply to Alexander Grund from comment #10)
> (In reply to Peter Bergner from comment #2)
> > The failure with GCC 7 and later coincides with the PPC port starting to
> > default to LRA instead of r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106210
--- Comment #6 from Segher Boessenkool ---
The prepare_shrink_wrap code handles only very limited very simple cases.
After g:8d2d39587d94 there is another copy at this point (which is an
*improvement*, it gives more freedom). I don't see how t
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
struct s { volatile int x[42]; } a;
void f(struct s b) { a = b; }
results in machine code calling memcpy(), which is not valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100694
--- Comment #4 from Segher Boessenkool ---
On aarch64 we have (in expand):
;; i_4 = i_3 << 64;
(insn 10 9 11 (set (subreg:DI (reg/v:TI 94 [ i ]) 8)
(subreg:DI (reg/v:TI 93 [ i ]) 0)) "100694.c":4:6 -1
(nil))
(insn 11 10 0 (set (s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100694
--- Comment #3 from Segher Boessenkool ---
Should this not be handled by the subreg passes?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #7 from Segher Boessenkool ---
(The original insns, before this combination.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #6 from Segher Boessenkool ---
What is wrong there? It isn't obvious. You may need to show insns 188 and 199
in non-slim form, "slim" is very lossy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #8 from Segher Boessenkool ---
There is structural RTL checking in rtl.h (see RTL_CHECK{1,2,C1,C2,C3} and the
various ELT and INT accessors). This would be easier to use here if we used
some STRICT_LOW_PART_P everywhere :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #6 from Segher Boessenkool ---
It looks like quite a few more backends use strict_low_part on random RTL,
which
is completely meaningless :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #5 from Segher Boessenkool ---
Thanks for tracking this down!
Interesting it survived so long. We could use some RTL checking on this :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #3 from Segher Boessenkool ---
STRICT_LOW_PART is required to contain a SUBREG though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026
--- Comment #11 from Segher Boessenkool ---
Wrt rs6000: we have shift+mask+compare in just one insn (it is basic powerpc),
and our
(define_insn "*and3_imm_dot_shifted"
pattern outputs this as just an "andi." insn when it can. But indeed the sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026
--- Comment #10 from Segher Boessenkool ---
So on Arm we get
Trying 6 -> 8:
6: r119:SI=r123:SI>>0x8
REG_DEAD r123:SI
8: {cc:CC_NZ=cmp(r119:SI&0x6,0);clobber scratch;}
REG_DEAD r119:SI
Failed to match this instruction:
(parall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026
--- Comment #9 from Segher Boessenkool ---
This is all handled in combine, nothing is specific to rs6000 (only the
description of all of our insns is, of course, but there is really no way
around that, nor should there be :-) )
Why does combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106059
--- Comment #5 from Segher Boessenkool ---
Thank you for the quick fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026
--- Comment #7 from Segher Boessenkool ---
For Power, both the original testcase and the one in comment 5 generate perfect
code, for all -mcpu= I tested. Should this be a target bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105991
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106059
--- Comment #1 from Segher Boessenkool ---
Well, this patch should not have changed behaviour at all!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016
Segher Boessenkool changed:
What|Removed |Added
Component|target |middle-end
--- Comment #10 from Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105991
--- Comment #4 from Segher Boessenkool ---
(In reply to Marek Polacek from comment #0)
> It doesn't look like a wrong code problem, but it seems more optimal to use
> rldimi (rotate left, mask insert) rather than rotate left by 0 bits, AND
> wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106017
--- Comment #6 from Segher Boessenkool ---
FWIW, reinterpret_cast allows exactly the same things as C casts (but with the
obvious C++ extensions: member objects, member functions, C++'s concept of
lvalue, that kins of thing). It is not similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016
--- Comment #6 from Segher Boessenkool ---
Like that yes. Pre-approved if it survives regcheck, too. Thanks!
Please add the testcase as well of course :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106017
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016
--- Comment #3 from Segher Boessenkool ---
Yeah. It should just return 1 like the other scalar types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106017
--- Comment #3 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #2)
> We do not want or allow automatic conversions between the opaque
> __vector_pair and __vector_quad types and other types and those are
> correctly disallowe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106015
--- Comment #2 from Segher Boessenkool ---
Confirmed. Likely the same cause as PR106017.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106017
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87656
--- Comment #17 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #16)
> Note, what is most important with this are configure scripts, if we start
> warning on something still widely used in configure snippets, we'll get
> silen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #47 from Segher Boessenkool ---
(In reply to Sam James from comment #46)
> Even partially making the build less recursive would likely help a fair bit.
It will help a bit, sure, but not nearly as much as you perhaps hope for.
There
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105586
--- Comment #2 from Segher Boessenkool ---
We have
+(debug_insn 11 10 81 2 (var_location:QI u8_1 (mem/c:QI (plus:DI (unspec:DI [
+(symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
+(reg:DI 2 2)
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103605
--- Comment #8 from Segher Boessenkool ---
(In reply to jos...@codesourcery.com from comment #4)
> > xsmindp
> > The minimum of a QNaN and any value is that value. The minimum of any value
> > and
> > an SNaN is that SNaN converted to a QNaN.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105325
Segher Boessenkool changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105427
--- Comment #2 from Segher Boessenkool ---
Maybe it needs a dg-skip-if for the has_arch_XXX, instead of in the dg-do
target clause?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105427
--- Comment #1 from Segher Boessenkool ---
mtvsrdd requires ISA 3.0 though (i.e. power9).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87656
--- Comment #12 from Segher Boessenkool ---
(In reply to David Binderman from comment #11)
> -Wold-style-definition
>
> KnR style function definitions have been deprecated for about 35 years.
+1
> Yes, there is a warning for it in gcc, but tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105325
--- Comment #11 from Segher Boessenkool ---
It should use "YZ" as constraint (Y is DS-mode, Z is X-mode). The predicate
should probably be lwa_operand ("lwau" does not exist, that's the irregularity
this predicate is for).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
Segher Boessenkool changed:
What|Removed |Added
Attachment #52871|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
Segher Boessenkool changed:
What|Removed |Added
Attachment #52870|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #13 from Segher Boessenkool ---
Ah, it needs check_no_compiler_messages_nocache in these tests. Patch
attached.
Could you please test with it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #10 from Segher Boessenkool ---
The feature test output you show was run without the dg-options... Something
is seriously wrong if that is the one that was used!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #9 from Segher Boessenkool ---
Ah, lol. Yes. But please don't change this yet, it should work thew way it
is now, this should be fixed. Do you see what makes the _ARCH_PWR10 test
fail on your system?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #7 from Segher Boessenkool ---
The test generates the expected code for all other cpus.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #5 from Segher Boessenkool ---
And that is what the {xfail {has_arch_pwr10 && {! has_arch_ppc64}}}
is for. Does that not work for you? Why doesn't it, it works fine here?
It would be nice if this unimportant edge case was costed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #2 from Segher Boessenkool ---
Oh, or you didn't see the next commit?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181
--- Comment #14 from Segher Boessenkool ---
It is *impossible* to have the stack registers as inputs to an inline asm, and
reliably generate correct code for it that does what the writer of that code
expected: loading up the operands to the asm m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #1 from Segher Boessenkool ---
I actually had tested that:
$ make check-gcc-c
RUNTESTFLAGS="--target_board=unix'{-m64,-m32,-m32/-mpowerpc64}{-mcpu=power7,-mcpu=power8,-mcpu=power9,-mcpu=power10}'
powerpc.exp=bswap-br*"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105334
--- Comment #7 from Segher Boessenkool ---
Should be fixed now. Testcase for this and PR103623 forthcoming, leaving
this PR open until then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105334
--- Comment #4 from Segher Boessenkool ---
Created attachment 52849
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52849&action=edit
proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105334
--- Comment #3 from Segher Boessenkool ---
Oh duh, this is pack, not unpack. I see the problem now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105334
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2022-04-21
Resolution|DUPL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #34 from Segher Boessenkool ---
*** Bug 105334 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105334
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105203
--- Comment #8 from Segher Boessenkool ---
(In reply to Martin Liška from comment #6)
> @Segher: Have you tried running it on x86_64-linux-gnu?
No, only with crosscompilers. This PR does not say it needs native.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #26 from Segher Boessenkool ---
(In reply to Richard Biener from comment #25)
> (In reply to Segher Boessenkool from comment #24)
> > Wrt keeping REG_EQUAL notes... If you want to keep them you need to make
> > sure
> > they still a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #24 from Segher Boessenkool ---
Wrt keeping REG_EQUAL notes... If you want to keep them you need to make sure
they still are valid. GCC keeps those on i3, it is much too hard in general to
validate other such notes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #23 from Segher Boessenkool ---
i3 is not always the sole instruction that results from the combine: if a
single insn does not work, two are tried, and one of them is placed at i2.
It's something to consider, it has to be checked for
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #2 from Segher Boessenkool ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105203
--- Comment #5 from Segher Boessenkool ---
It does not show up with any configuration I have tried, so clearly it needs
something more :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105203
--- Comment #3 from Segher Boessenkool ---
Lol, this isn't a PowerPC issue at all. Please fill out the target field?
How can there be a difference in the number of uses only (and no difference
in actual uses!)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105203
--- Comment #2 from Segher Boessenkool ---
I cannot reproduce this problem, what other flags does it need to reproduce?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105147
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105041
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105147
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Segher Boe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985
--- Comment #16 from Segher Boessenkool ---
"machine_mode m" I understand of course. "rtx m" is something different :-)
I didn't see the patch yet, sorry, will get to it later today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985
--- Comment #14 from Segher Boessenkool ---
Are you sure this only ever handles pseudos? It is completely broken if not.
Changing the mode of regno_reg_rtx[...] is always wrong, too.
Patches 2 and 3 look better, but need a lot more explanatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
Segher Boessenkool changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #38 from Segher Boessenkool ---
+ cat test.c
struct foo
{
int : 0;
double a;
int : 0;
double b;
int : 0;
};
extern void func(struct foo);
void
pass_foo(void)
{
struct foo test;
test.a = 114;
test.b = 514;
func(te
||segher at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #4 from Segher Boessenkool ---
Fixed now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #31 from Segher Boessenkool ---
Well, what do other compilers do? It's not such a good idea to break ABI
compatibility with the 1990's compilers ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
--- Comment #12 from Segher Boessenkool ---
What I still cannot figure out is how you get TARGET_MFCRF with your
configuration and command line, so, ISA 2.01 . This is -m32 so *should*
default to -mcpu=7450. But apparently it uses the PROCESSO
||
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #10 from Segher Boessenkool ---
Created attachment 52675
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52675&action=edit
proposed patch v2
Bah. Try this one :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105023
--- Comment #6 from Segher Boessenkool ---
BLKmode is *not* valid for registers. reg:BLK at one time was a special
marker for invalid asm operands, apparently.
:BLK is for mem, and for parallel as well in some cases, but not for reg.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105023
--- Comment #4 from Segher Boessenkool ---
It never even executes rs6000_function_arg for that testcase. What are you
doing differently? ... Oh, C++. Duh.
It happens because we do
return gen_rtx_REG (mode, gregno);
which is perfectly vali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
--- Comment #7 from Segher Boessenkool ---
Created attachment 52670
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52670&action=edit
proposed patch
Does this help? The 7450 (which is what freebsd64 defaults to) indeed does
not support th
301 - 400 of 3173 matches
Mail list logo
