https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110717
--- Comment #12 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #9)
> Wonder how many important targets provide double-word shift patterns vs.
> ones which expand it through generic code.
Very long ago rs6000 had special
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
--- Comment #12 from Segher Boessenkool ---
> I guess that would be annoying if you couldn't have modifiers on constraints
There is no such thing as "operand modifiers". There are *output* modifiers:
they change how an operand is *printed*,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
--- Comment #10 from Segher Boessenkool ---
(In reply to Nicholas Piggin from comment #9)
> I don't know why constraint is wrong and mode is right
Simple: you would need O(2**T*N) constraints for our existing N register
constraints, together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
--- Comment #8 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #6)
> (In reply to Segher Boessenkool from comment #5)
> > Constraints are completely the wrong tool for this. Just use modes, which
> > *are* the right tool?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
--- Comment #5 from Segher Boessenkool ---
Constraints are completely the wrong tool for this. Just use modes, which
*are* the right tool?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
--- Comment #17 from Segher Boessenkool ---
(In reply to Roger Sayle from comment #16)
> Just to warn people in advance, the test case pr78904-1b.c is expected to
> start FAILing with the commit of
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #94 from Segher Boessenkool ---
(In reply to Alexander Klepikov from comment #92)
> I remembered why I used two different insns - first to eliminate infinite
> loop with help of marking insn with attribute, and second because I could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #9 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #4)
> These die because the struct we're using to check the alignment of uses long
> double as the "big" aligned type. We could either disable the tests using a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #88 from Segher Boessenkool ---
(In reply to Oleg Endo from comment #85)
> > +/* { dg-final { scan-assembler
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #87 from Segher Boessenkool ---
(In reply to Oleg Endo from comment #53)
> (In reply to Segher Boessenkool from comment #52)
> > There is TARGET_LEGITIMATE_COMBINED_INSN though, which is a workaround for
> > if
> > you really do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110254
--- Comment #1 from Segher Boessenkool ---
Off topic / pet peeve: it's not an array of functions, so it should not be
called
something_p .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71850
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #52 from Segher Boessenkool ---
(In reply to Alexander Klepikov from comment #50)
> But maybe there is a way to exclude particular insn from combine pass? (I
> guess not).
In general, it is best to let combine just work on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #6 from Segher Boessenkool ---
(In reply to Matthias Kretz (Vir) from comment #4)
> With -mcpu=power10 I see the issue. The problem has been there all the time
> and only surfaced with this test. (It should also have shown on `make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109949
--- Comment #5 from Segher Boessenkool ---
(In reply to Matthias Kretz (Vir) from comment #2)
> Yes, I stopped my backporting efforts when I became aware that it's failing
> on ARM. I'll get to PPC ASAP and then continue with the backports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858
--- Comment #10 from Segher Boessenkool ---
(In reply to Hongtao.liu from comment #8)
> (In reply to Segher Boessenkool from comment #7)
> > > The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and
> > > GENERAL_REGS(which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858
--- Comment #7 from Segher Boessenkool ---
> The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and
> GENERAL_REGS(which is the case in PR109610), hope it can also fix this
> regression.
That sounds more reasonable. But,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610
--- Comment #11 from Segher Boessenkool ---
(In reply to Hongtao.liu from comment #5)
> One solution is add an peephole for handle such redudancy.
Not okay.
> If powerpc maintainer doesn't like this way, another alternative is add a
> target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109610
--- Comment #10 from Segher Boessenkool ---
(In reply to Hongtao.liu from comment #5)
> One solution is add an peephole for handle such redudancy.
Not okay.
> If powerpc maintainer doesn't like this way, another alternative is add a
> target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566
--- Comment #17 from Segher Boessenkool ---
So, apparently powerpc-rtems uses -mpowerpc64 by default?! That is
problematic,
it changes the ABI, might not actually work at all (it requires your
setjmp/longjmp
and getcontext/setcontext to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #51 from Segher Boessenkool ---
(In reply to rusty from comment #47)
> Civility please.
Thank you.
> As Andrew Pinski says "people are mis-using this attribute", and Jakub
> Jelinek makes a similar point. The use of _wur has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
--- Comment #43 from Segher Boessenkool ---
(In reply to Andrew Church from comment #40)
> My rationale for changing the default behavior is that the wider community
> consensus, as evidenced by things like the C++ (and C2x) [[nodiscard]]
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2023-04-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #12 from Segher Boessenkool ---
With the modified compiler? Does it ICE with an unmodified compiler as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
--- Comment #7 from Segher Boessenkool ---
"For clarity of code, the following named constants are suggested. Preferably,
compilers will provide these constants in a header file, but this is not
required
for compliance."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #9 from Segher Boessenkool ---
That patch looks fine :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #5 from Segher Boessenkool ---
Correct, this certainly can not be done by combine, it see two independent
pseudos here. For hard registers it *can* do many tricks, but not for
pseudos like this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109447
Segher Boessenkool changed:
What|Removed |Added
CC||green at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |NEW
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #9 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #8)
> (In reply to Jonathan Wakely from comment #6)
> > Also, after 'make clean' you can no longer do 'make all'
>
> Of course you cannot. Where do you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #8 from Segher Boessenkool ---
(In reply to Jonathan Wakely from comment #6)
> Also, after 'make clean' you can no longer do 'make all'
Of course you cannot. Where do you see this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #7 from Segher Boessenkool ---
Thank you for looking at this!
(In reply to Jonathan Wakely from comment #5)
> c++tools/Makefile.in has:
>
> mostlyclean::
> rm -f $(MAPPER.O)
>
> clean::
> rm -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2023-03-30
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109329
Segher Boessenkool changed:
What|Removed |Added
Priority|P3 |P4
Target|
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
The testcases use ICmode, which exists fine on almost all systems. But we
get the error
cc1: error: '-mabi=ieeelongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103628
--- Comment #7 from Segher Boessenkool ---
(In reply to HaoChen Gui from comment #5)
> The memory representation of IBM long double is not unique. It's actually
> the sum of two 64-bit doubles.
Yes, and the first of those two DP numbers is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109067
--- Comment #1 from Segher Boessenkool ---
Do you have a testcase please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007
--- Comment #17 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #16)
> Or just make sure the libraries are still built with -mcpu=power8 even when
> the compiler defaults to something else.
That doesn't scale.
> That said,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784
--- Comment #12 from Segher Boessenkool ---
What David says :-)
We really could use something good for this, it has been a problem for all
GCC targets since forever; it hurts rs6000 more than most though.
Before RA this is a diamond, one side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007
--- Comment #15 from Segher Boessenkool ---
(In reply to bugreporter66 from comment #14)
> I should be able to workaround that by emulating all LE targets on POWER9,
> with a comment that building for POWER8 natively on target should work too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #16 from Segher Boessenkool ---
(In reply to Roger Sayle from comment #14)
> This really is a regression, that points to a previously latent/unnoticed
> bug in combine.
>
> In GCC 12, combine would take the input RTL and based on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109009
--- Comment #4 from Segher Boessenkool ---
Alternatively (or in addition), you can look how to make the shrink-wrap pass
transform the code with some simple added move instructions, maybe even
involving an extra pseudo, so that it can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #13 from Segher Boessenkool ---
Hi!
Either this should not be P1, or the proposed patch is taking completely the
wrong direction. P1 means there is a regression. There is no regression in
combine, in fact the proposed patch would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007
--- Comment #13 from Segher Boessenkool ---
(In reply to bugreporter66 from comment #10)
> Yes, it seems so. They've switched to POWER9 by default in Ubuntu 22.04, so
> it means that gcc itself (along with standard libraries) was compiled for
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #17 from Segher Boessenkool ---
What makes you think we need to tell the user to do something? There is
nothing that needs to be done as far as I can see? /confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #15 from Segher Boessenkool ---
(In reply to Alexander Monakov from comment #14)
> Are you guys really sure you want to blame the user here,
I apologise if this hasn't been a nice experience for you.
I'm not blaming anyone, least
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #13 from Segher Boessenkool ---
(In reply to Alexander Monakov from comment #10)
> (In reply to Rui Ueyama from comment #9)
> > I'm the maintainer of the mold linker. I didn't implement that POWER10 ABI
> > because I didn't have an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109009
--- Comment #1 from Segher Boessenkool ---
This is very target-specific. Could you please attach a test case (with any
significant compiler flags as well, and specific target mentioned, etc.) that
shows the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770
--- Comment #11 from Segher Boessenkool ---
(In reply to Jens Seifert from comment #6)
> The left part of VSX registers overlaps with floating point registers, that
> is why no register xxpermdi is required and mfvsrd can access all (left)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target|powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #8 from Segher Boessenkool ---
To expand a bit: st_other with value 1 was reserved before, and now it
isn't anymore. Any tool that silently ignores the "special case" of
reserved values will not work correctly (it might sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770
--- Comment #5 from Segher Boessenkool ---
(In reply to Jens Seifert from comment #4)
> PPCLE with no special option means -mcpu=power8 -maltivec (altivecle to be
> mor precise).
What? No.
$ sh config.sub ppcle
powerpcle-unknown-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108862
--- Comment #3 from Segher Boessenkool ---
With -fno-unroll-loops added we get
foo:
.LFB0:
.cfi_startproc
cmpwi 0,3,0
ble 0,.L4
mtctr 3
addi 10,4,-8
addi 5,5,8
li 3,0
.p2align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107949
--- Comment #6 from Segher Boessenkool ---
We generate loads into QImode regs, so we need to explicitly convert it to
whatever larger mode is wanted later. We also have define_insns to do a
zero-extended load directly into a bigger pseudo, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #33 from Segher Boessenkool ---
Yes, exactly. It was the X server I think? I try to forget such horrors :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #31 from Segher Boessenkool ---
Yes, there was a user who incorrectly used memcpy on non-memory memory.
This is not valid, and never has been.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #29 from Segher Boessenkool ---
(In reply to Florian Weimer from comment #28)
> Maybe this belongs in the ABI manual? For example, the POWER ABI says that
> memcpy needs to work on device memory.
Huh?!
Where do you see this? The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108787
--- Comment #9 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #7)
> Created attachment 54460 [details]
> gcc13-pr108787.patch
That patch is preapproved, but please add a comment (before umaddditi4)
saying we do not want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108787
--- Comment #8 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #6)
> we used to emit in GCC 12 4/4/4/5 instructions:
> mulld 9,3,4
> mulhdu 4,3,4
> addc 3,9,5
> adde 4,4,6
> and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108787
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2023-02-14
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108699
--- Comment #2 from Segher Boessenkool ---
Right, it needs a vpopcntb or similar first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #8 from Segher Boessenkool ---
No, addition and subtraction are well defined for all inputs, for unsigned
integers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #6 from Segher Boessenkool ---
No? Take a=59 as counterexample:
(a - (N*M)) / N + M = (59 - 2*30)/30 + 2 = ~0UL/30 + 2
but
a / N = 59/30 = 1
Integer division in C is division towards zero, almost no normal algebraic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
--- Comment #24 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #23)
> I also suspect many of these new warnings we are doing in recent years
> really should not be part of -Wall because of how many false positives we
> have.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #5 from Segher Boessenkool ---
The failure was not detected, only things down the road broke up, can we add
something for that? Just a strategically placed assert should do fine.
Less important if we grow the field all the way to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84514
--- Comment #2 from Segher Boessenkool ---
Still happens with current trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #24 from Segher Boessenkool ---
So this PR can be marked resolved now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108491
Segher Boessenkool changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108432
--- Comment #3 from Segher Boessenkool ---
(In reply to David Malcolm from comment #2)
> Unfortunately, some analyzer warnings work better with optimization
> *disabled*. -fanalyzer runs much later than most other static analyzers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108491
--- Comment #1 from Segher Boessenkool ---
This error is from sysv4.h SUBTARGET_OVERRIDE_OPTIONS. -msecure-plt is
unconditionally required.
It looks like an oversight that it is not required in the assembler you
used (which is that?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108432
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483
--- Comment #4 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #1)
> I doubt this will be changed anytime soon, see PR 4210 for the history on
> why.
That PR is about an UB case though. In this case the code is perfectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483
--- Comment #2 from Segher Boessenkool ---
The testcase needs a NULL defined as (void *)0 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #21 from Segher Boessenkool ---
As far as we (me, you; everybody) can tell it is fixed now. If one day we get
a testcase showing it has in fact not been fixed, the problem is still there,
we can reopen or link the testcases or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
--- Comment #12 from Segher Boessenkool ---
We really really REALLY should neuter -mmodulo. It is counter-productive
to have command-line flags for separate instructions at all (as opposed to
facilities), and it is downright destructive to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396
--- Comment #5 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #3)
> Is it hard to add one for all (or many) of the legacy builtins? Do we want
> to test more than just if it compiles?
Btw, "legacy"... I thought
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415
--- Comment #1 from Segher Boessenkool ---
Soft float does not conflict with anything (anything that does not need
FP registers that is). But yes, we really should neuter -mmodulo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396
--- Comment #3 from Segher Boessenkool ---
(In reply to Kewen Lin from comment #2)
> Yes, it's a typo, which makes the macro definition change to:
>
> #define vec_vsubcuqP __builtin_vec_vsubcuq
Yup.
> Unfortunately we don't have the testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108250
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
--- Comment #7 from Segher Boessenkool ---
-m64 requires 64-bit instructions. We will ICE if we try to generate code
for -m64 without support for 64-bit insns enabled in the compiler. For
example, the stdu insn is required to implement the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
--- Comment #4 from Segher Boessenkool ---
(In reply to Kewen Lin from comment #3)
> With the culprit commit r13-4894, we always implicitly enable powerpc64 for
> both explicit and implicit 64 bit, it's the same as before for the explicit
> 64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298
--- Comment #9 from Segher Boessenkool ---
It cannot be a duplicate: this bug was introduced much later than when
PR69482 was filed!
But glad the same patch seems to have fixed both, sure :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108004
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107949
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108004
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298
--- Comment #5 from Segher Boessenkool ---
This is not x86-specific. Like on powerpc64 we get
addi 3,3,3 # 11 [c=4 l=4] *addsi3/1
extsw 3,3# 17 [c=4 l=4] extendsidi2/1
blr # 25 [c=4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2023-01-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298
--- Comment #4 from Segher Boessenkool ---
But please use PR33053 for that, or open a new PR? Let's keep this one
for just this actual bug :-)
||2023-01-05
Status|RESOLVED|NEW
Ever confirmed|0 |1
CC||segher at gcc dot gnu.org
--- Comment #2 from Segher Boessenkool ---
This is not a dup of 33053 (see PR33053#c5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33053
--- Comment #6 from Segher Boessenkool ---
(In reply to Daniel Lundin from comment #5)
> This ought to result in stricter optimizing behavior from gcc, not the other
> way around.
Well, GCC did implement this already. My request was that we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784
--- Comment #7 from Segher Boessenkool ---
I do get that exact same code with everything from GCC 6 to GCC 12 as well
though (modulo a small regression in GCC 10).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784
--- Comment #6 from Segher Boessenkool ---
Ugh, this PR is for GCC 12 only, ignore me please :-)
101 - 200 of 3144 matches
Mail list logo
