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")]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99352
Bug ID: 99352
Summary: check_effective_target_sqrt_insn for powerpc is wrong
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99352
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Target|
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
--- Comme
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
--- Comm
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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc--netbsd |powerpc
Last reconfirmed|
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
--- Comme
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
--- Comme
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97583
Bug ID: 97583
Summary: Unknown mode_attribute (or iterator) ignored
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
--- Comment #9 from Segher Boessenkool ---
Yes, that looks correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97676
Bug ID: 97676
Summary: "*" should skip a constraint, not just one char of it
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
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
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 th
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 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #23 from Segher B
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 re
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
> prob
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=97784
Bug ID: 97784
Summary: Expressions evaluated as long chain instead of as tree
or the like
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
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
ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97786
Bug ID: 97786
Summary: rs6000 isinf etc. are pretty horrible
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
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 correc
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=22326
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
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=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=97926
--- Comment #1 from Segher Boessenkool ---
Confirmed (needs -O0).
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=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=97972
--- Comment #2 from Segher Boessenkool ---
Confirmed.
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 y
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=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 #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 a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98179
Bug ID: 98179
Summary: gcc.dg/pr97954.c fails on (at least) BE powerpc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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).
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=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=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=97329
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2020-10-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97329
--- Comment #5 from Segher Boessenkool ---
So both the cache line size and the cache size are wrong for GCC 10
and before, but okay on trunk, on all compiler I tested (I tested on
Linux only so far).
1 - 100 of 897 matches
Mail list logo
