https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #6 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #5)
> "structure layout happens before the zero width bitfields are removed by the
> FE".
>
> So, what can break still, then?
Homogeneous aggregates can br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #5 from Segher Boessenkool ---
"structure layout happens before the zero width bitfields are removed by the
FE".
So, what can break still, then?
- li 9,0
- sldi 9,9,32
- mtvsrd 1,9
+ li 3,0
std 0,16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #5 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #4)
> Started with r9-3950-g2f0b80c7a4ab4254f57ba63de26ebb7896e3742d
> Does the modsw instruction really need the early-clobber (i.e. does it first
> overwrite th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82940
--- Comment #8 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #7)
> (In reply to Peter Cordes from comment #6)
> > # power64 GCC 9.2.1 (ATI13.0)
> > rlwimi 3,4,0,255# bit-blend according to mask, rotate count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82940
--- Comment #7 from Segher Boessenkool ---
(In reply to Peter Cordes from comment #6)
> # power64 GCC 9.2.1 (ATI13.0)
> rlwimi 3,4,0,255# bit-blend according to mask, rotate count=0
> rldicl 3,3,0,32 # Is this zero-extensi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55549
--- Comment #2 from Segher Boessenkool ---
Three things:
1) It was invalid *before* this, already (vector mode paradoxical subregs
make no sense);
2) The subreg needs to be fixed up *somehow*, too;
3) subreg of mem will go away any day now (or,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101882
--- Comment #3 from Segher Boessenkool ---
(In reply to Marek Polacek from comment #2)
> Assignee present -> ASSIGNED.
Hrm, this used to work automatically when you press "take"? What changed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #3 from Segher Boessenkool ---
The current code reads
if ((flags & OPTION_MASK_DIRECT_MOVE) != 0)
rs6000_define_or_undefine_macro (define_p, "_ARCH_PWR8");
if ((flags & OPTION_MASK_MODULO) != 0)
rs6000_define_or_undefine
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
FAIL: gcc.target/powerpc/sse4_1-phminposuw.c (test for excess errors)
Excess errors:
/home/segher/build/tot-master/gcc/include/smmintrin.h:103:3: error: AltiVec
argument passed to unprototyped
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Segher Boessenkool ---
Confirmed. I'll take it.
|NEW
CC||segher at gcc dot gnu.org
Last reconfirmed||2021-08-11
--- Comment #1 from Segher Boessenkool ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830
--- Comment #4 from Segher Boessenkool ---
(In reply to Bill Schmidt from comment #0)
> (1) linebuf and pos are global variables, and the compiler cannot tell
> whether or not there are problems with array bounds accesses here. Indeed,
> pos is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82940
--- Comment #5 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #4)
> As long as nothing on the rtl level (combine) does not mess this up, it
> should produce the best code.
combine cannot ever create worse code than it had as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89847
--- Comment #2 from Segher Boessenkool ---
Interestingly, while this gives optimal code for power8 and power9, we still
get an unnecessary mulli for power10. This is because multiplication by 31
is expanded to a multiplication on power10 (just l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103
--- Comment #21 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #19)
> Created attachment 51211 [details]
> gcc12-pr78103.patch
>
> Updated untested patch that uses define_insn_and_split in 2 cases instead of
> the combine sp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103
--- Comment #20 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #18)
> (In reply to Segher Boessenkool from comment #17)
> > > Nothing changes for combine though, I think it really would be nice if it
> > > could either change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103
--- Comment #17 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #16)
> Created attachment 51209 [details]
> gcc12-pr78103.patch
>
> Updated patch. This one fixes the reuse of a pseudo you've mentioned above,
> and fixes gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103
--- Comment #15 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Segher Boessenkool from comment #13)
> > (In reply to Jakub Jelinek from comment #10)
> > > Unfortunately, it doesn't work for the #c0 testcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103
--- Comment #13 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #10)
> Unfortunately, it doesn't work for the #c0 testcase, after the combiner
> splitter kicks in, the combiner doesn't even try that 4 insn combination.
It do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67382
--- Comment #5 from Segher Boessenkool ---
It turns out that noop other_insn is fine, and is accepted etc., but the
resulting i3 in this case is not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67382
--- Comment #4 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #3)
> Note combine is able to figure out the jump is unconditional but there is no
> "pattern" to match it:
> Trying 10 -> 17:
>10: r85:QI=0x1
>17: {flags:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #17 from Segher Boessenkool ---
(In reply to Franz Sirl from comment #15)
> > "7400" and "403" are not supported target attribute values, fwiw (says the
> > manual).
>
> Hmm, I don't understand what you mean.
I mean that I cannot r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #14 from Segher Boessenkool ---
(In reply to Franz Sirl from comment #12)
> The emitted .machine is easy to fix, what's not so easy to fix is the
> intention behind Segher's change that caused the wrong .machine.
>
> Consider this s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
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=101393
--- Comment #10 from Segher Boessenkool ---
(In reply to Franz Sirl from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > I don't think it is a good idea to add workaround upon workaround to avoid
> > some of the not-so-useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
Segher Boessenkool changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
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=99927
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43073
--- Comment #8 from Segher Boessenkool ---
Much more importantly, gcc-core doesn't exist anymore (so WORKSFORME is a
strange resolution).
Using the documented build procedures is recommended, and is what is
supported here (not any cross tool wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #6 from Segher Boessenkool ---
(In reply to Franz Sirl from comment #4)
> How about something along this patch? It's not fully done (no good idea
> about SPEC stuff like "mcpu=7400: -mppc %{!mvsx:%{!maltivec:-maltivec}};"
> yet), but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #5 from Segher Boessenkool ---
(In reply to Franz Sirl from comment #3)
> (In reply to Segher Boessenkool from comment #1)
> > The -many is problematic, that is the whole point of this. As in this
> > example: on different subtarget
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129
--- Comment #7 from Segher Boessenkool ---
That patch is pre-approved (if it works ;-) ) Bill. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288
--- Comment #23 from Segher Boessenkool ---
-m32 is required here. With -fno-unroll-loops -m32 you now get
flush_dcache_range:
rlwinm 3,3,0,0,27
addi 4,4,15
subf 4,3,4
srwi. 4,4,4
beqlr 0
mtctr 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101384
--- Comment #6 from Segher Boessenkool ---
I did run on the cfarm. What kind of machine does it need to fail? p8? p9?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101323
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2021-07-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #2 from Segher Boessenkool ---
A good solution would add all those historical targets to
rs6000_machine_from_flags.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101384
--- Comment #4 from Segher Boessenkool ---
The testcase works fine for me? What does it need to fail?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101372
--- Comment #5 from Segher Boessenkool ---
On powerpc64-linux the failure is
In file included from /home/segher/src/gcc/gcc/c-family/c-common.h:26,
from /home/segher/src/gcc/gcc/cp/cp-tree.h:40,
from /home/segh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101177
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301
--- Comment #9 from Segher Boessenkool ---
(In reply to Thomas Koenig from comment #8)
> (In reply to Segher Boessenkool from comment #7)
>
> > Yeah :-) Of course in your testing the nine named cases have the same
> > probability,
> > which i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
Segher Boessenkool changed:
What|Removed |Added
CC||mliska at suse dot cz
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
--- Comment #2 from Segher Boessenkool ---
So, even if I use
-fno-shrink-wrap
and, although rs6000.c has anyway
/* If we are inserting ROP-protect instructions, disable shrink wrap. */
if (rs6000_rop_protect)
flag_shrink_wrap = 0;
we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324
--- Comment #1 from Segher Boessenkool ---
Could you attach something that is a valid input to the compiler? Something
that does not include the preprocessor directives... did you use -dM?
Don't :-)
(I can reproduce with this code, but there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301
--- Comment #7 from Segher Boessenkool ---
Assuming that you divide the "default" case into ten pieces of 0.01 each,
some slight corrections:
(In reply to Thomas Koenig from comment #6)
> int foo3 (int n)
> {
> if (__builtin_expect_with_proba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301
--- Comment #5 from Segher Boessenkool ---
Looking at -fdump-tree-all-all, things are fine with "foo" until the
switchlower pass. Before that all nine switch cases and the default
case all had probability 0.10; after the switch conversion there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101301
--- Comment #3 from Segher Boessenkool ---
What CPU is in your Power system, and what -mcpu= did you compile with?
What is the ABI you are using? (That last one doesn't seem to matter in
this particular case, but :-) )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101235
--- Comment #4 from Segher Boessenkool ---
(In reply to Kewen Lin from comment #3)
> Will backport the fix after 2021 July 7th (two weeks since it's into trunk)
> if this isn't urgent meanwhile got the backport approval.
The reason to not backp
||2021-06-24
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
Resolution|WONTFIX |---
--- Comment #9 from Segher Boessenkool ---
(In reply to Martin Sebor from comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #14 from Segher Boessenkool ---
(In reply to luoxhu from comment #13)
> It is not visible in combine due to the constant data is in *.LC0 and
combine can see things in the constant pool in various ways though (just
like many other p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #12 from Segher Boessenkool ---
(In reply to Bill Schmidt from comment #11)
> Segher, does this fit naturally in combine?
This is just constant folding, combine won't have much to do with it.
It is always better (namely, lower late
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #4 from Segher Boessenkool ---
This PR is specifically about the vec_revb builtin. But yes, we should
look at what is generated for all other code (having only the builtin
generate good code is suboptimal for a generic thing like th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100944
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #3 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #2)
> The first test is for _Float128. What goes wrong there?
>
> For all these tests yo
..u have to figure out what is going wrong. After that it will
l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #2 from Segher Boessenkool ---
The first test is for _Float128. What goes wrong there?
For all these tests yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #14 from Segher Boessenkool ---
We *have* TImode already, but most 128-bit scalars currently use V1TImode.
This often leads to reduced performance because that is not a scalar mode,
does not get all optimisations we have generically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #12 from Segher Boessenkool ---
We want to use plain TImode instead of V1TImode on newer cpus. It probably is
a good idea (for performance) on p9 already, but this will need testing. That's
only sideways related to this issue though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595
--- Comment #12 from Segher Boessenkool ---
(In reply to H. Peter Anvin from comment #9)
> How is this different from raise(SIGTRAP);?
It does an architecture-specific trap instruction, not a SIGTRAP signal.
The former is useful even if you do n
||segher at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-06-09
--- Comment #11 from Segher Boessenkool ---
(In reply to Richard Biener from comment #7)
> I frequently use raise(SIGSTOP) ... (or x86 speci
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
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 variou
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, u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100736
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2021-06-03
Status|UNCO
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*
Severity|normal
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
> > w
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 s
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 reasonable)
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&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
--- 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=99927
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #18 from Seghe
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 inter
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 cal
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
> (cons
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=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
601 - 700 of 3177 matches
Mail list logo
