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=100622
--- Comment #7 from Segher Boessenkool ---
Nice :-)
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
See
<https://lore.kernel.org/linux-toolchains/20210604182357.ga1688...@rowland.harvard.edu/T/#mb0e293105ae45974af7ed435847e2a6f72158a0a>
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #35 from Segher Boessenkool ---
You get something like
.L5:
lwzu 9,4(10)
addc 8,3,9
adde 3,9,3
bdnz .L5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
--- Comment #33 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #32)
> So it is more about the back-end of PowerPC at this point.
For the testcase
===
typedef unsigned int u32;
typedef unsigned long long u64;
u32 f(u32 a,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100736
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2021-06-03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100703
--- Comment #2 from Segher Boessenkool ---
This compiles just fine for me, even with -O0. Does this only happen with
some older version of the compiler? Are some special flags needed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808
--- Comment #2 from Segher Boessenkool ---
(In reply to Jens Seifert from comment #0)
> - Avoid additional "int" unsigned long long int => unsigned long long
Why? Those are exactly the same types!
> - add missing line breaks between builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100868
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc-*-*-* |powerpc*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #3 from Segher Boessenkool ---
Hi Alexander,
You do not say what the actual target you used is? powerpc-linux,
powerpc64-linux, powerpc64le-linux, something else entirely?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96762
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acsawdey at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711
--- Comment #5 from Segher Boessenkool ---
(In reply to Hongtao.liu from comment #4)
> > Even w/ canonical RTL, i think a combine splitter is also needed here, the
> > canonical RTL only helps combine/forwprop to match more possibility but
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #8 from Segher Boessenkool ---
(In reply to luoxhu from comment #7)
> (In reply to Segher Boessenkool from comment #3)
> > The rotates in 6 and 7 are not merged, and neither are the vec_selects in
> > 8 and 9. Both should be pretty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100712
--- Comment #1 from Segher Boessenkool ---
As background, the ISA has in the xxspltidp description
If IMM32 specifies a single-precision denormal value
(i.e., bits 1:8 equal to 0 and bits 9:31 not equal to 0),
the result is undefined.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
-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/2021-May/570728.html (needed to
resolve PR99888).
We need some new hook(s) and/or refactoring of the generic code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100693
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100693
--- Comment #1 from Segher Boessenkool ---
Confirmed. The define_insn for it is for SImode only as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100694
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2021-05-20
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100622
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|--- |FIXED
Status|NEW |RESOLVED
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #16 from Segher Boessenkool ---
I overhauled the Power machine-specific constraints documentation in
e01975f97cbb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100169
--- Comment #1 from Segher Boessenkool ---
The SMS pass is notorious for slight changes making its cost model decide
too do things the other way around. Is that what is happening here? Was
SMS' decision a good decision (or at least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98952
--- Comment #4 from Segher Boessenkool ---
Fixed on trunk. Needs backports to 11 and whatever else is still an open
branch when the backports are done :-)
||2021-04-19
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108
--- Comment #5 from Segher Boessenkool ---
Created attachment 50629
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50629=edit
Proposed simpler patch
A simpler patch. I'll commit this later today (if no one stops me).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108
--- Comment #4 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #1)
> e500 support had been moved to the powerpcspe target; so assuming power9 for
> -misel is correct.
>
> e500mc support is still there though.
There never
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #18 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #3 from Segher Boessenkool ---
The rotates in 6 and 7 are not merged, and neither are the vec_selects in
8 and 9. Both should be pretty easy to do, there is no unspec in sight,
etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97142
--- Comment #11 from Segher Boessenkool ---
(In reply to luoxhu from comment #10)
> If not built with fast-math, gimple_has_side_effects will return true and
> cause the expand_call_stmt fail to expand the "_1 = fmod (x_2(D), y_3(D));"
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #14 from Segher Boessenkool ---
(In reply to luoxhu from comment #12)
> That code was called by combine pass but fail to match.
>
> pr newpat
> (set (reg:DI 125 [ l ])
> (xor:DI (and:DI (xor:DI (reg/v:DI 120 [ l ])
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #13 from Segher Boessenkool ---
(In reply to luoxhu from comment #11)
> I noticed that you added the below optimization with commit
> a62436c0a505155fc8becac07a8c0abe2c265bfe. But it doesn't even handle this
> case, cse1 pass will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927
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=99830
--- Comment #14 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #13)
> Seems the exact spot where the clobber is optimized away is e.g. when
> simplify_and_const_int_1 (SImode, (ashift:SI (subreg:SI (and:TI (clobber:TI
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99830
--- Comment #12 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #11)
> I don't understand what is wrong about that.
> (clobber:TI (const_int 0 [0])) in there stands for couldn't figure out what
> this value is or how to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15
--- Comment #3 from Segher Boessenkool ---
I'm not sure how/why "artificial" should prevent taking the address though?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99830
--- Comment #10 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #8)
> In particular, it is combine_simplify_rtx that is called on:
> (zero_extend:SI (subreg:QI (ior:TI (and:TI (reg/v:TI 103 [ f ])
> (const_int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99830
--- Comment #7 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #6)
> In the end on the actual instruction the clobber is optimized away
That is a very serious bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99830
--- Comment #5 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #3)
> In normal insns such clobbers would be rejected by recog, but for
> DEBUG_INSNs we don't have strict validity tests, but guess we need to throw
> away at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99930
--- Comment #10 from Segher Boessenkool ---
That is a USE of a constant, which is a no-op always. Here we have a USE
of a register, which is not. We actually have *two* uses of pseudos, and
combine cannot know what that means for the target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #10 from Segher Boessenkool ---
You cannot fix a simplify-rtx problem in much earlier passes! It may be
useful of course (I have no idea, I don't know gimple well enough), but
it is no solution to the problem at all. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927
--- Comment #14 from Segher Boessenkool ---
distribute_notes says
Any clobbers from i2 or i1 can only exist if they were added by
recog_for_combine.
which is not true apparently. But all of this code *does* depend
on that, it just doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927
--- Comment #13 from Segher Boessenkool ---
Yes, combine just drops that clobber of flags, that was a thinko :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927
--- Comment #11 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #7)
> Ah, create_log_links wants to work like that.
> So, the bug seems to be that insn 108 has REG_DEAD (reg:CC 17 flags) note.
> It doesn't initially, but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99930
--- Comment #8 from Segher Boessenkool ---
That patch is no good. The combination is not allowed because it is not
known what the "use"s are *for*. Checking if something is from the constant
pools is not enough at all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99927
--- Comment #9 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #5)
> But what is wrong is that try_combine has been called at all, because
> (reg:CCZ 17 flags) is used in 3 instructions rather than just one.
That is not a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99930
--- Comment #3 from Segher Boessenkool ---
What happens here is
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/combine.c;h=3294575357bfcb19e589868da34364498a860dcf;hb=HEAD#l1884
"*2_1" for absneg:MODEF has a bare "use". And then we trigger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #18 from Segher Boessenkool ---
(In reply to luoxhu from comment #12)
> Not sure whether TARGET_DIRECT_MOVE_64BIT is the right MACRO to correctly
> differentiate m32 and m64?
It is not. It looks at TARGET_POWERPC64 only, and that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #17 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #10)
> https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567215.html
Ah, that is more recent than anything I have replied to :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #7 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #6)
> I did not know whether it is implementable (in VSX or in Altivec) for 32-bit
> targets etc., all I was suggesting was what to do if it is not implementable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #6 from Segher Boessenkool ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Segher Boessenkool from comment #3)
> > In an ideal world the user can just assume those types exist always.
> Arguably a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99718
--- Comment #5 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #3)
> If the non-constant vec_set can't be supported when
> !(TARGET_P8_VECTOR && TARGET_DIRECT_MOVE_64BIT)
I don't see why not? It may need different code,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
--- Comment #10 from Segher Boessenkool ---
GCC 11 stage 4 will be fine.
I doubt you can ever measure a difference, but you can try :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #3 from Segher Boessenkool ---
The only such __SIZEOF_* macro that is not about a standards-required type
is for int128. Not the best example ;-)
There are not predefines for __SIZEOF_FLOAT128__ etc. either.
In an ideal world the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #1 from Segher Boessenkool ---
Yes, the __SIZEOF_* macros do not say whether some type can be used. This is
true for all targets!
What would it be useful for to define these macros? They all are equivalent to
#define SIXTEEN 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97926
Segher Boessenkool changed:
What|Removed |Added
Component|target |testsuite
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #14 from Segher Boessenkool ---
Well, V=m-o (not the same thing, these are sets) -- but, it is clear that "o"
should be a subset of "m":
(define_memory_constraint "TARGET_MEM_CONSTRAINT"
"Matches any valid memory."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97926
--- Comment #5 from Segher Boessenkool ---
It helps if you test the compiler you just built, not something old. Sigh.
Patch is testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97926
Segher Boessenkool changed:
What|Removed |Added
Assignee|acsawdey at gcc dot gnu.org|segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98092
Segher Boessenkool changed:
What|Removed |Added
Attachment #50040|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #7 from Segher Boessenkool ---
>From the offending patch:
-/* Return true if the eliminated form of AD is a legitimate target address.
*/
+/* Return true if the eliminated form of AD is a legitimate target address.
+ If OP is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99496
--- Comment #13 from Segher Boessenkool ---
Hi Nathan,
I think you didn't push the branch that is on?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581
--- Comment #5 from Segher Boessenkool ---
Thanks Vladimir. It is indeed a problem in LRA (or triggered by it).
We have
8: {[r121:DI+low(unspec[`*.LANCHOR0',%2:DI]
47+0x92a4)]=asm_operands;clobber
so this is an offset that is too big for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99352
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #20 from Segher Boessenkool ---
(In reply to Bill Schmidt from comment #14)
> We should definitely not be allowing the AltiVec "& ~16" flavors into these
> patterns. I'm not certain whether your fix is the best way to achieve that,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99496
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99352
--- Comment #3 from Segher Boessenkool ---
rs6000 has check_effective_target_powerpc_fprs already (with slightly
different semantics).
||powerpc*-*-*
Last reconfirmed||2021-03-02
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Segher Boessenkool ---
Mine.
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
It just just says
[istarget powerpc*-*-*]
but it should test whether the preprocessor symbol "_ARCH_PPCSQ" is defined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #9 from Segher Boessenkool ---
The i386 port has
===
(define_insn "trap"
[(trap_if (const_int 1) (const_int 6))]
""
{
#ifdef HAVE_AS_IX86_UD2
return "ud2";
#else
return ASM_SHORT "0x0b0f";
#endif
}
[(set_attr "length"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #7 from Segher Boessenkool ---
(In reply to Franz Sirl from comment #5)
> For the naming I suggest __builtin_debugtrap() to align with clang. Maybe
> with an aliased __debugbreak() on Windows platforms.
Those are terrible names.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #6 from Segher Boessenkool ---
(In reply to Richard Biener from comment #4)
> I'm not sure what your proposed not noreturn trap() would do in terms of
> IL semantics compared to a not specially annotated general call?
Nothing I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #3 from Segher Boessenkool ---
Ah, thank you. Well except there is no keyword called that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93353
--- Comment #9 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #7)
> if (low_int >= 0x8000 - extra)
> is not true and 0x7fff - -1 is 0x8000 (with UB on the compiler side).
These are HWIs, so there is no UB.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93353
--- Comment #8 from Segher Boessenkool ---
(In reply to Arseny Solokha from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > I cannot get the reduced testcase to fail. Are any special options needed?
>
> If you've been asking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99293
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93353
--- Comment #4 from Segher Boessenkool ---
I cannot get the reduced testcase to fail. Are any special options needed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98181
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #26 from Segher Boessenkool ---
Can you show the code you tried in comment 23? It is near impossible to see
what happened there without that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99068
--- Comment #8 from Segher Boessenkool ---
Using update form instructions constrains register allocation and scheduling.
It is *not* always a good idea.
That is one of the reasons why we currently use update form instructions only
when insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99068
--- Comment #6 from Segher Boessenkool ---
(In reply to Brian Grayson from comment #4)
> (In reply to Segher Boessenkool from comment #3)
> > Then you get
> >
> > addi 9,9,-2
> > lhau 10,2(9)
> > addi 9,9,2
> >
> > which is worse than just
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99068
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99068
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98468
--- Comment #3 from Segher Boessenkool ---
git tag -l 'releases*' --contains 8d2d39587d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99048
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99048
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
|--- |INVALID
CC||segher at gcc dot gnu.org
--- Comment #1 from Segher Boessenkool ---
Because it would be incorrect? lhau is pre-modify (like all update
form instructions).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
--- Comment #7 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #6)
> The mma_assemble_pair/mma_assemble_acc patterns both generate lxv or lxvp
> at, which both use a DQ offset and we already have function to
> test for that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
--- Comment #6 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #4)
> So this is where the "autogenerated" part comes in. We should have
> an idea what might be useful and what isn't even worth trying by
> looking at the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
--- Comment #5 from Segher Boessenkool ---
(In reply to rsand...@gcc.gnu.org from comment #3)
> FWIW, another similar thing I've wanted in the past is to try
> recognising multiple possible constants in an (and X (const_int N))
> when X is known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #24 from Segher Boessenkool ---
I do see the problems for savegpr/restgpr with that suggestion, but maybe
something
in that vein can be done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #23 from Segher Boessenkool ---
savegpr/restgpr are special ABI-defined functions that do not have all the same
ABI
calling conventions as normal functions. They indeed write into the parent's
frame
(red zone, in this case).
Maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #16 from Segher Boessenkool ---
(In reply to Mark Wielaard from comment #13)
> ==25741== Use of uninitialised value of size 8
> ==25741==at 0x1504: main (pr9862.C:16)
r4 is argv here
>0x14f0 <+16>: ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #15 from Segher Boessenkool ---
(In reply to Will Schmidt from comment #14)
> The _restgpr* and _savegpr* functions are not referenced when the test is
> built at other optimization levels. (I've looked at disassembly from -O0 ..
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
--- Comment #5 from Segher Boessenkool ---
(As Jakub said; I'm just slow).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
--- Comment #4 from Segher Boessenkool ---
combine always asks recog(), so that must have said it is okay?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98986
--- Comment #2 from Segher Boessenkool ---
I agree it makes sense to have the one arm with vec_duplicate first in the
canonical order. Problem is that this is deep in the arms, but it can be
done of course.
Autogenerating part of combine?
601 - 700 of 3115 matches
Mail list logo
