https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #20 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Segher Boessenkool from comment #16)
> > (In reply to Jakub Jelinek from comment #15)
> > > PowerPC I think does, not sure about s390.
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #16 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #15)
> PowerPC I think does, not sure about s390.
Does what?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353
--- Comment #5 from Segher Boessenkool ---
Please revert until it is fixed? It breaks way too many targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #45 from Segher Boessenkool ---
Yes, that is fine afaics.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #42 from Segher Boessenkool ---
(In reply to H.J. Lu from comment #41)
> (In reply to Segher Boessenkool from comment #40)
> > Let me repeat: A const_int cannot be assigned to a MODE_CC. It has no
> > meaning.
> > This is invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #40 from Segher Boessenkool ---
Let me repeat: A const_int cannot be assigned to a MODE_CC. It has no meaning.
This is invalid RTL. If it ever works, or worked, that is an accident.
A MODE_CC stands for a comparison (in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #38 from Segher Boessenkool ---
You cannot put a const_int in a MODE_CC. It is meaningless.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #33 from Segher Boessenkool ---
(In reply to H.J. Lu from comment #32)
> > There is no actual comparison with 0, that is just notation.
>
> True. But simplify-rtx.cc simplifies
>
> (ltu (reg 17) (const_int 0))
>
> to false when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240
--- Comment #5 from Segher Boessenkool ---
So perhaps this needs instructions new on P8 (which fleshed out the integer
support amongst other things, but that sounds relevant here?) Test that with
{ powerpc*-*-* && has_arch_pwr8 }
or such?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107240
--- Comment #3 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #1)
> I guess the first question is, is it expected that the
> vect-bitfield-write-2.c loop should be vectorized on power7 which only has
> Altivec and not VSX?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #30 from Segher Boessenkool ---
(In reply to H.J. Lu from comment #26)
> LTU/GEU are only used to check FLAGS_REG against constant 0.
That is not what
(ltu (reg 17) (const_int 0))
means though?
Together with a previous
(set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #29 from Segher Boessenkool ---
(In reply to Hongtao.liu from comment #23)
> looking at i386.c put_condition_code used by *setcc_qi, it looks like (EQ
> (reg:CCCmode FLAG_REG) (const_int 0)) means get carry flag.
> Not (LTU:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #28 from Segher Boessenkool ---
> So the issue is with the consumer:
>
> (insn 50 49 51 2 (parallel [
> (set (reg:SI 93)
> (neg:SI (ltu:SI (reg:CCC 17 flags)
> (const_int 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #21 from Segher Boessenkool ---
(In reply to Hongtao.liu from comment #19)
> (In reply to H.J. Lu from comment #18)
> > (In reply to Segher Boessenkool from comment #16)
> > > Hi Roger,
> > >
> > > (In reply to Roger Sayle from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #16 from Segher Boessenkool ---
Hi Roger,
(In reply to Roger Sayle from comment #15)
> Yes, a COMPARE rtx can be used to set various flags on x86, but many other
> operations also legitimately set and/or use MODE_CC, often in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #14 from Segher Boessenkool ---
(In reply to H.J. Lu from comment #13)
> (In reply to Segher Boessenkool from comment #12)
> >
> > To determine the semantics of this piece of RTL you need to see the
> > setter(s)
> > of reg 17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #12 from Segher Boessenkool ---
(In reply to H.J. Lu from comment #11)
> Assuming (reg:CCC 17 flags) is set to 1 by compare properly, how should
A MODE_CC RTL reg is never set to "1". It is set to the result of a
comparison,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #10 from Segher Boessenkool ---
The input to combine has
(insn 49 10 50 2 (parallel [
(set (reg:CCC 17 flags)
(ne:CCC (reg:SI 82 [ a.1_2 ])
(const_int 0 [0])))
(set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #8 from Segher Boessenkool ---
Bah, scratch that last part, of course it is valid (I thought this was using 0
in a MODE_CC but I just cannot read).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #32 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #31)
> (In reply to Segher Boessenkool from comment #30)
> > We have to disallow all (*all*) operands that require prefixed insns, until
> > we can handle those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #30 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #29)
> (In reply to Segher Boessenkool from comment #28)
> > All prefixed addresses, pcrel or R=0, are valid always. The original code
> > is correct.
>
> Well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #28 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #27)
> (In reply to Michael Meissner from comment #23)
> > If we change rs6000_legitimate_address_p to return false if we have a
> > prefixed address and we are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107050
--- Comment #2 from Segher Boessenkool ---
Splitting blocks in shrink-wrap will cause degraded performance compared
to the status quo, on average. If I understand what will be split how,
that is? It certainly can be good to move more code,
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
The semantics of global register variables are a strict superset of the
semantics
of local register variables, but this isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #16 from Segher Boessenkool ---
It cannot be -mcpu=power8, that cannot generate isel. -mcpu=power9 comes
closer, but I still do not see exactly the same output, and crucially not
the strange store either.
What the what.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96072
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #14 from Segher Boessenkool ---
What is the exact command line (and relevant configuration!) required to
reproduce this?
||2022-09-13
Status|UNCONFIRMED |NEW
CC||segher at gcc dot gnu.org
--- Comment #1 from Segher Boessenkool ---
Confirmed.
GCC uses conditional branches here in expand already. It is hard to optimise
this over
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106751
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #12 from Segher Boessenkool ---
(In reply to Kewen Lin from comment #10)
> (In reply to Segher Boessenkool from comment #9)
> > Although, preferably we should not allow assigning one opaque type to
> > another
> > opaque type just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #9 from Segher Boessenkool ---
Although, preferably we should not allow assigning one opaque type to another
opaque type just because they will eventually use the same mode, not without
warning anyway? Or is that unavoidable?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106840
--- Comment #2 from Segher Boessenkool ---
This is inside #ifdef __ASSEMBLER__ . Running assembler code (or anything else
that isn't C) through the C preprocessor is the subject of one of my "why would
you ever do that" rants: the assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #7 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #6)
> Ah, that special "mode". I think verify_types shouldn't do anything
> for OPAQUE_TYPES or alternatively trust the targets setup of
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #11 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #10)
> (In reply to Segher Boessenkool from comment #9)
> > When MMA is not enabled,
> ...
> > the __vector_{quad,pair} types should not exist,
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #9 from Segher Boessenkool ---
When MMA is not enabled, the movxo and movoo patterns should never be reached
at all; the __vector_{quad,pair} types should not exist, and the
{XO,OO}mode-using
code should then never be created. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106755
--- Comment #5 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #2)
> So the tests (I've removed all static inline usage and always use
> -fno-inline) pass with -O1 and fail with -O2 and -O3. Looking at all of the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #23 from Segher Boessenkool ---
(In reply to Andreas Krebbel from comment #22)
> The longer a have been looking at these STRICT_LOW_PART issue the more I
> think that STRICT_LOW_PART is an awful way to express what we need:
>
> -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100736
--- Comment #6 from Segher Boessenkool ---
There are so many things here, it's hard to start. Two big things:
Firstly, this is not floating point at all, so -ffinite-math-only should not
make any difference. We currently abuse CCFP (in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #19 from Segher Boessenkool ---
(In reply to Andreas Krebbel from comment #18)
> (In reply to Segher Boessenkool from comment #17)
> ...
> > Yes, but that says the high 48 bits of the hardware reg are untouched, which
> > is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #17 from Segher Boessenkool ---
(In reply to Andreas Krebbel from comment #16)
> (In reply to Segher Boessenkool from comment #15)
> > (In reply to Andreas Krebbel from comment #14)
> > > > So you are suggesting that every
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #15 from Segher Boessenkool ---
(In reply to Andreas Krebbel from comment #14)
> > So you are suggesting that every strict_low_part after reload can just be
> > removed? If that is true, should we not just do exactly that then?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #13 from Segher Boessenkool ---
(Sorry I missed this)
(In reply to Andreas Krebbel from comment #11)
> I've tried to change our movstrict backend patterns to use a predicate on
> the dest operand which enforces a subreg. However,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #27 from Segher Boessenkool ---
So this particular bug is no longer there, and this PR can be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
--- Comment #19 from Segher Boessenkool ---
Hi guys,
What testcases are still failing? I'm a bit lost :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #9 from Segher Boessenkool ---
(In reply to Alan Modra from comment #8)
> (In reply to Segher Boessenkool from comment #7)
> > '-fpatchable-function-entry=N[,M]'
> > Generate N NOPs right at the beginning of each function, with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #7 from Segher Boessenkool ---
'-fpatchable-function-entry=N[,M]'
Generate N NOPs right at the beginning of each function, with the
function entry point before the Mth NOP.
The nops have to be consecutive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96786
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103498
--- Comment #2 from Segher Boessenkool ---
Mike, do you still see this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
--- Comment #3 from Segher Boessenkool ---
Your second option isn't correct: all these nops should be consecutive. Your
option 1 is fine :-)
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
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
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
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 #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
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=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
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=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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106210
--- Comment #6 from Segher Boessenkool ---
The prepare_shrink_wrap code handles only very limited very simple cases.
After g:8d2d39587d94 there is another copy at this point (which is an
*improvement*, it gives more freedom). I don't see how
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
struct s { volatile int x[42]; } a;
void f(struct s b) { a = b; }
results in machine code calling memcpy(), which is not valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100694
--- Comment #4 from Segher Boessenkool ---
On aarch64 we have (in expand):
;; i_4 = i_3 << 64;
(insn 10 9 11 (set (subreg:DI (reg/v:TI 94 [ i ]) 8)
(subreg:DI (reg/v:TI 93 [ i ]) 0)) "100694.c":4:6 -1
(nil))
(insn 11 10 0 (set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100694
--- Comment #3 from Segher Boessenkool ---
Should this not be handled by the subreg passes?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #7 from Segher Boessenkool ---
(The original insns, before this combination.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #6 from Segher Boessenkool ---
What is wrong there? It isn't obvious. You may need to show insns 188 and 199
in non-slim form, "slim" is very lossy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #8 from Segher Boessenkool ---
There is structural RTL checking in rtl.h (see RTL_CHECK{1,2,C1,C2,C3} and the
various ELT and INT accessors). This would be easier to use here if we used
some STRICT_LOW_PART_P everywhere :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #6 from Segher Boessenkool ---
It looks like quite a few more backends use strict_low_part on random RTL,
which
is completely meaningless :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #5 from Segher Boessenkool ---
Thanks for tracking this down!
Interesting it survived so long. We could use some RTL checking on this :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #3 from Segher Boessenkool ---
STRICT_LOW_PART is required to contain a SUBREG though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026
--- Comment #11 from Segher Boessenkool ---
Wrt rs6000: we have shift+mask+compare in just one insn (it is basic powerpc),
and our
(define_insn "*and3_imm_dot_shifted"
pattern outputs this as just an "andi." insn when it can. But indeed the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026
--- Comment #10 from Segher Boessenkool ---
So on Arm we get
Trying 6 -> 8:
6: r119:SI=r123:SI>>0x8
REG_DEAD r123:SI
8: {cc:CC_NZ=cmp(r119:SI&0x6,0);clobber scratch;}
REG_DEAD r119:SI
Failed to match this instruction:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026
--- Comment #9 from Segher Boessenkool ---
This is all handled in combine, nothing is specific to rs6000 (only the
description of all of our insns is, of course, but there is really no way
around that, nor should there be :-) )
Why does combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106059
--- Comment #5 from Segher Boessenkool ---
Thank you for the quick fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026
--- Comment #7 from Segher Boessenkool ---
For Power, both the original testcase and the one in comment 5 generate perfect
code, for all -mcpu= I tested. Should this be a target bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105991
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106059
--- Comment #1 from Segher Boessenkool ---
Well, this patch should not have changed behaviour at all!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016
Segher Boessenkool changed:
What|Removed |Added
Component|target |middle-end
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105991
--- Comment #4 from Segher Boessenkool ---
(In reply to Marek Polacek from comment #0)
> It doesn't look like a wrong code problem, but it seems more optimal to use
> rldimi (rotate left, mask insert) rather than rotate left by 0 bits, AND
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106017
--- Comment #6 from Segher Boessenkool ---
FWIW, reinterpret_cast allows exactly the same things as C casts (but with the
obvious C++ extensions: member objects, member functions, C++'s concept of
lvalue, that kins of thing). It is not similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016
--- Comment #6 from Segher Boessenkool ---
Like that yes. Pre-approved if it survives regcheck, too. Thanks!
Please add the testcase as well of course :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106017
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=106016
--- Comment #3 from Segher Boessenkool ---
Yeah. It should just return 1 like the other scalar types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106017
--- Comment #3 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #2)
> We do not want or allow automatic conversions between the opaque
> __vector_pair and __vector_quad types and other types and those are
> correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106015
--- Comment #2 from Segher Boessenkool ---
Confirmed. Likely the same cause as PR106017.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106017
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87656
--- Comment #17 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #16)
> Note, what is most important with this are configure scripts, if we start
> warning on something still widely used in configure snippets, we'll get
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #47 from Segher Boessenkool ---
(In reply to Sam James from comment #46)
> Even partially making the build less recursive would likely help a fair bit.
It will help a bit, sure, but not nearly as much as you perhaps hope for.
There
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105586
--- Comment #2 from Segher Boessenkool ---
We have
+(debug_insn 11 10 81 2 (var_location:QI u8_1 (mem/c:QI (plus:DI (unspec:DI [
+(symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
+(reg:DI 2 2)
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103605
--- Comment #8 from Segher Boessenkool ---
(In reply to jos...@codesourcery.com from comment #4)
> > xsmindp
> > The minimum of a QNaN and any value is that value. The minimum of any value
> > and
> > an SNaN is that SNaN converted to a QNaN.
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=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?
201 - 300 of 3115 matches
Mail list logo
