https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71216
--- Comment #2 from Segher Boessenkool ---
Author: segher
Date: Fri Jul 22 13:08:19 2016
New Revision: 238639
URL: https://gcc.gnu.org/viewcvs?rev=238639&root=gcc&view=rev
Log:
Subject: [PATCH] rs6000: Fix logic for when to emit .machine (PR7121
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71216
--- Comment #3 from Segher Boessenkool ---
Author: segher
Date: Wed Jul 27 16:12:05 2016
New Revision: 238788
URL: https://gcc.gnu.org/viewcvs?rev=238788&root=gcc&view=rev
Log:
rs6000: Fix logic for when to emit .machine (PR71216)
The current l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71216
--- Comment #4 from Segher Boessenkool ---
Author: segher
Date: Wed Jul 27 16:14:12 2016
New Revision: 238789
URL: https://gcc.gnu.org/viewcvs?rev=238789&root=gcc&view=rev
Log:
rs6000: Fix logic for when to emit .machine (PR71216)
The current l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71216
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72771
--- Comment #2 from Segher Boessenkool ---
Needs -O3 -mcpu=power9 -mno-lra, and a binutils that supports power9,
to fail. Same on BE as on LE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72802
--- Comment #2 from Segher Boessenkool ---
Why is "wY" wrong for 32-bit? I don't see it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72802
--- Comment #4 from Segher Boessenkool ---
When -mno-powerpc64, I see. Thanks. Yeah this needs some untangling.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72746
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71724
Segher Boessenkool changed:
What|Removed |Added
CC||helloqirun at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73650
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73650
--- Comment #2 from Segher Boessenkool ---
It fails with -mtune={e55,e500mc,e5500,e6500} and works without it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73650
--- Comment #3 from Segher Boessenkool ---
it fails with -misel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73650
--- Comment #4 from Segher Boessenkool ---
First bad revision is r237376. Fails with -m32 -mcpu=e5500 -mlra.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73650
--- Comment #7 from Segher Boessenkool ---
[ i have a patch, it is bootstrapping+checking ]
[ the revision in #c4 is a red herring ]
Yeah, single_set holds for that, and LRA then treats it as a reg-reg
move (because that is what the single set i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43669
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588
--- Comment #6 from Segher Boessenkool ---
Yeah let's close this. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67771
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71629
--- Comment #3 from Segher Boessenkool ---
I cannot reproduce either with a non-SPE compiler. Does it happen with
current trunk for you?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71846
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71629
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
||segher at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #2 from Segher Boessenkool ---
This looks to be the same as PR73650 (which has a patch on gcc-patches). If
not, please reopen.
*** This bug has been marked as a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73650
Segher Boessenkool changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73650
--- Comment #9 from Segher Boessenkool ---
Author: segher
Date: Mon Aug 15 16:17:21 2016
New Revision: 239483
URL: https://gcc.gnu.org/viewcvs?rev=239483&root=gcc&view=rev
Log:
lra: A multiple_sets is not a simple_move_p (PR73650)
In the PR we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77292
--- Comment #13 from Segher Boessenkool ---
(In reply to Manuel López-Ibáñez from comment #12)
> (In reply to Segher Boessenkool from comment #11)
> > Both of these suggestions are not so good. "!(a == b)" is better written
> > as "a != b", and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18154
--- Comment #11 from Segher Boessenkool ---
The signed version can be done in four insns:
1: subfc r5,r3,r4
subfe r6,r6,r6
and r7,r6,r5
addcr8,r7,r3
(superopt finds 16 versions, all similar).
The unsign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18154
--- Comment #12 from Segher Boessenkool ---
(Never mind those last "addc" insn, they can just as well be plain
"add", I pasted the wrong ones).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77289
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77289
--- Comment #3 from Segher Boessenkool ---
And this 208 vs. sfp is created by combine:
Trying 76 -> 77:
Successfully matched this instruction:
(parallel [
(set (reg:SF 33 1)
(mem:SF (plus:SI (reg/f:SI 113 sfp)
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 think
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. Thi
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" "2")]
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.
||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.
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).
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=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=99352
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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 #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 ME
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=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=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=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."
(define_memory_
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=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=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 u
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=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, sure
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 __SIZEOF_
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=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 #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 ca
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=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 pro
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 #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 is
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 #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 ma
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 xor/and/xor
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 (al
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 lea
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 #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=15
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
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=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 repres
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
> (cons
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=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 cal
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=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 inter
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=99927
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #18 from Seghe
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 *w
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&action=edit
Proposed simpler patch
A simpler patch. I'll commit this later today (if no one stops me).
||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=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 :-)
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
-mcpu=
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 a
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 [
(set
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 c
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 #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=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=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 many
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 a
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=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=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
That
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=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 fo
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.
: 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 #9 from Segher Boessenkool ---
Yes, that looks correct.
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.
2301 - 2400 of 3229 matches
Mail list logo
