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?
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=98519
--- Comment #22 from Segher Boessenkool ---
Don't replace the constraints. For one thing, this is very hard to do
correctly. Just make the "m" constraint not allow prefixed memory in
asms, like I said above. (So all "general_operand" even!)
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=70053
--- Comment #11 from Segher Boessenkool ---
Please open a separate bug for x86 problems.
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=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=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=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=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
Status|NEW |RESOLVED
Resolution|---
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 #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 #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 #16 from Segher Boessenkool ---
Needs -mcpu=power8. Confirmed with that (and the given options).
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 #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=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=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=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=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
--- 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=98549
Segher Boessenkool changed:
What|Removed |Added
Priority|P1 |P4
--- Comment #3 from Segher
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=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=98643
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2021-01-13
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=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=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 #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=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=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=98112
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
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=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=98020
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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).
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
/home/segher/src/gcc/gcc/testsuite/gcc.dg/pr97954.c: In function 'foo':
/home/segher/src/gcc/gcc/testsuite/gcc.dg/pr97954.c:12:1: error: too many
outgoing
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=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 #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=97972
--- Comment #2 from Segher Boessenkool ---
Confirmed.
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=97926
--- Comment #1 from Segher Boessenkool ---
Confirmed (needs -O0).
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=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=22326
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
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=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
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
int isfinite(double x) { return __builtin_isfinite (x); }
int isinf(double x) { return __builtin_isinf (x); }
int isinf_sign(double x) { return __builtin_isinf_sign (x); }
int isnan
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
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
When compiling something like
#define O +
long x4(long x, long a, long b, long c, long d) { return x O a O b O c O d; }
we
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 #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=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
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #23 from Segher
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
--- 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
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
--- Comment #9 from Segher Boessenkool ---
Yes, that looks correct.
: 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 #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=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 #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=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?
701 - 800 of 3144 matches
Mail list logo
