https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #19 from Segher Boessenkool ---
And the same with all of GCC 8, GCC 9, GCC 10, GCC 11, and current trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |REOPENED
--- Comment #20 from Segh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104681
--- Comment #2 from Segher Boessenkool ---
Could you just change the insn condition to test if at least one of the
operands is a reg?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104681
--- Comment #4 from Segher Boessenkool ---
We also do the same in define_insn bodies, with a force_reg if needed.
But we do indirect via rs6000_emit_move elsewhere, so let's do that here as
well; it isn't a great idea, but consistency wins, cer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #22 from Segher Boessenkool ---
Well, we do not do anything AT here; but the patch is not on the GCC 11
branch either.
Xiong Hu, does it backport there cleanly?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104698
--- Comment #1 from Segher Boessenkool ---
GCC should not use unspecs for any basic operations like this. *That* is
the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104698
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2022-02-27
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711
--- Comment #3 from Segher Boessenkool ---
... does NOT have a good enough balance ...
Sorry :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711
--- Comment #4 from Segher Boessenkool ---
Created attachment 52522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52522&action=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104208
--- Comment #2 from Segher Boessenkool ---
If you want -mlong-double-64 to override -mabi={ibm,ieee}longdouble, you need
make sure that the last of those options on the command line wins. And what
should -mlong-double-128 do in that scheme?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711
--- Comment #8 from Segher Boessenkool ---
Arnd's request was to not have -Wshift-negative-value implied by -W, or at
least not if -fwrapv (-pedantic would be wrong btw, the standard does not
require a diagnostic here, and that is what -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #12 from Segher Boessenkool ---
(In reply to Jonathan Wakely from comment #10)
> Maybe we could do this instead:
>
> --- a/gcc/config/rs6000/rs6000-c.cc
> +++ b/gcc/config/rs6000/rs6000-c.cc
> @@ -623,11 +623,13 @@ rs6000_cpu_cpp_bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104643
--- Comment #3 from Segher Boessenkool ---
Note that the called function is not pure (it writes to some global vars), so
perhaps this was on purpose even? Andreas?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #17 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #13)
> I see
> Doesn't this mean that ieee128_float_type_node and ibm128_float_type_node is
> always non-NULL?
No. All of that code is inside
if (TARGET_F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #18 from Segher Boessenkool ---
Ah, I didn't see the
else
ieee128_float_type_node = ibm128_float_type_node = long_double_type_node;
which looks completely garbage. It long double is just DP float, we certainly
do not want eithe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #20 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #19)
> I'd guess that else ieee128_float_type_node = ibm128_float_type_node =
> long_double_type_node;
> is there so that we don't ICE during the builtins creatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #22 from Segher Boessenkool ---
In rs6000_type_string, please just handle the error !type_node case first,
so you don't have to consider it in all other cases separately.
Do you need to change the __SIZEOF_FLOAT128__ code at all now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #23 from Segher Boessenkool ---
Oh, and looks great, thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #25 from Segher Boessenkool ---
It is defined to __ieee128 whenever that exists, and not defined otherwise?
Yes, the logic and control flow are byzantine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #27 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #26)
> (In reply to Segher Boessenkool from comment #25)
> > It is defined to __ieee128 whenever that exists, and not defined otherwise?
> > Yes, the logic and co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #16 from Segher Boessenkool ---
There are many patterns that use VEC_I, and not all have a V1TI variant
currently, so adding V1TI to it is not suitable for now. It is better to
add a new iterator for now.
This whole thing desperate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #30 from Segher Boessenkool ---
There should be a __SIZEOF_IEEE128__ as well, of course.
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
In <https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591322.html> Joseph
reports that I have broken the default build for powerpc-linux. Whoops.
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829
--- Comment #3 from Segher Boessenkool ---
I cannot reproduce it either. The machine instruction that gives the error is
lfiwzx, a power7 insn; GCC will not generate this instruction unless you are
compiling for power7 or later. That is not th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829
--- Comment #5 from Segher Boessenkool ---
No difference with binutils-2.38 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829
--- Comment #10 from Segher Boessenkool ---
(In reply to jos...@codesourcery.com from comment #6)
> The generated .s file has ".machine ppc". Maybe there is some
> inconsistency arising from the use of -mvsx -mfloat128 for this 32-bit
> confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829
--- Comment #11 from Segher Boessenkool ---
Created attachment 52599
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52599&action=edit
proposed patch
This patch should restore the previous behaviour. Joseph, can you test it
please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868
--- Comment #2 from Segher Boessenkool ---
Well that doesn't do the right thing... mtvsrdd has RA|0. So we either need
some third alternative to handle the case it get assigned hard reg 0, or we
should prevent that some other way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868
--- Comment #3 from Segher Boessenkool ---
Created attachment 52601
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52601&action=edit
proposed patch
Try the attached, instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868
Segher Boessenkool changed:
What|Removed |Added
Attachment #52601|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829
Segher Boessenkool changed:
What|Removed |Added
Attachment #52599|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104901
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
,
||segher at gcc dot gnu.org
--- Comment #3 from Segher Boessenkool ---
For C this is DR 476, which is on the way for C2x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104901
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104901
--- Comment #8 from Segher Boessenkool ---
Sure, but c1 as well as c2 are not constants here!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104901
--- Comment #11 from Segher Boessenkool ---
$ cat vcc.c
int f(int x) { return x == 31 && x == 42; }
-Wlogical-op gives
vcc.c: In function 'f':
vcc.c:1:31: warning: logical 'and' of mutually exclusive tests is always false
[-Wlogical-op]
1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964
--- Comment #20 from Segher Boessenkool ---
FAIL: g++.dg/other/pr84964.C -std=c++14 (internal compiler error: Aborted
signal terminated program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964
--- Comment #22 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #21)
> It did so even before my or Roger's patch.
It was my first successful bootstrap in a few days, and I replied to this old
PR
without looking everywhere els
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105023
--- Comment #2 from Segher Boessenkool ---
@findex BLKmode
@item BLKmode
``Block'' mode represents values that are aggregates to which none of
the other modes apply. In RTL, only memory references can have this mode,
and only if they appear in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
--- Comment #4 from Segher Boessenkool ---
Have you tried with something with
commit 80fcc4b6afee72443bef551064826b3b4b6785e6
Author: Segher Boessenkool
Date: Fri Mar 11 21:15:18 2022 +
rs6000: Do not use rs6000_cpu for .machine ppc
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
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=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.
||
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=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
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 ;-)
||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 #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
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=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=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=105147
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Segher Boe
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|NEW |RESOLVED
Resolution|---
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=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 #5 from Segher Boessenkool ---
It does not show up with any configuration I have tried, so clearly it needs
something more :-(
|--- |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=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
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 #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=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=105334
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCON
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
Last reconfirmed||2022-04-21
Resolution|DUPL
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
--- 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 #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=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=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 #2 from Segher Boessenkool ---
Oh, or you didn't see the next commit?
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 #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 #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 #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 #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
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
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
Attachment #52871|0 |1
is obsolete|
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=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=105427
--- Comment #1 from Segher Boessenkool ---
mtvsrdd requires ISA 3.0 though (i.e. power9).
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=105325
Segher Boessenkool changed:
What|Removed |Added
Priority|P3 |P1
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=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=106091
--- Comment #4 from Segher Boessenkool ---
That patch looks good :-)
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=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=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=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 #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=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=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
2601 - 2700 of 3229 matches
Mail list logo
