https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #18 from Segher Boessenkool ---
Ah, I didn't see the
else
ieee128_float_type_node = ibm128_float_type_node = long_double_type_node;
which looks completely garbage. It long double is just DP float, we certainly
do not want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #17 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #13)
> I see
> Doesn't this mean that ieee128_float_type_node and ibm128_float_type_node is
> always non-NULL?
No. All of that code is inside
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104643
--- Comment #3 from Segher Boessenkool ---
Note that the called function is not pure (it writes to some global vars), so
perhaps this was on purpose even? Andreas?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #12 from Segher Boessenkool ---
(In reply to Jonathan Wakely from comment #10)
> Maybe we could do this instead:
>
> --- a/gcc/config/rs6000/rs6000-c.cc
> +++ b/gcc/config/rs6000/rs6000-c.cc
> @@ -623,11 +623,13 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711
--- Comment #8 from Segher Boessenkool ---
Arnd's request was to not have -Wshift-negative-value implied by -W, or at
least not if -fwrapv (-pedantic would be wrong btw, the standard does not
require a diagnostic here, and that is what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104208
--- Comment #2 from Segher Boessenkool ---
If you want -mlong-double-64 to override -mabi={ibm,ieee}longdouble, you need
make sure that the last of those options on the command line wins. And what
should -mlong-double-128 do in that scheme?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711
--- Comment #4 from Segher Boessenkool ---
Created attachment 52522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52522=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711
--- Comment #3 from Segher Boessenkool ---
... does NOT have a good enough balance ...
Sorry :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2022-02-27
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104698
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104698
--- Comment #1 from Segher Boessenkool ---
GCC should not use unspecs for any basic operations like this. *That* is
the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #22 from Segher Boessenkool ---
Well, we do not do anything AT here; but the patch is not on the GCC 11
branch either.
Xiong Hu, does it backport there cleanly?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104681
--- Comment #4 from Segher Boessenkool ---
We also do the same in define_insn bodies, with a force_reg if needed.
But we do indirect via rs6000_emit_move elsewhere, so let's do that here as
well; it isn't a great idea, but consistency wins,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104681
--- Comment #2 from Segher Boessenkool ---
Could you just change the insn condition to test if at least one of the
operands is a reg?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |REOPENED
--- Comment #20 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #19 from Segher Boessenkool ---
And the same with all of GCC 8, GCC 9, GCC 10, GCC 11, and current trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
Segher Boessenkool changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #18 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103353
--- Comment #7 from Segher Boessenkool ---
(In reply to Kewen Lin from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > You miss all extra errors the expand_call can generate. This is the general
> > reason why we try to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103926
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2022-02-23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88197
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104627
--- Comment #4 from Segher Boessenkool ---
The old warning was more helpful and specific, it would be nice if we could
have that back.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103353
--- Comment #4 from Segher Boessenkool ---
You miss all extra errors the expand_call can generate. This is the general
reason why we try to continue instead of stopping after the first error. The
reason is that later errors may be more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104627
--- Comment #2 from Segher Boessenkool ---
It started somewhere in the last four days:
-Compiler version: 12.0.1 20220217 (experimental) (GCC)
+Compiler version: 12.0.1 20220221 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #31 from Segher Boessenkool ---
A straightforward backport of that gives
In file included from /home/segher/src/gcc/gcc/config/rs6000/rs6000.cc:28765:
./gt-rs6000.h:143:6: error: 'atomic_update_decl' was not declared in this scope
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
New regressions:
-m32:
+FAIL: gcc.dg/deprecated.c (test for warnings, line 28)
+FAIL: gcc.dg/deprecated.c (test for excess errors)
and that warning is
/home/segher/src/gcc/gcc/testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98179
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |WORKSFORME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #30 from Segher Boessenkool ---
(In reply to Richard Biener from comment #28)
> Huh, yes - I assumed that had been fixed. Segher? Can you please fix that
> GTY bug?
I'll look at it. It's over three years old, will need some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #30 from Segher Boessenkool ---
Btw, does this issue exist for the corresponding __builtin_{un,}pack_ibm128
builtins as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #29 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #28)
> (In reply to Segher Boessenkool from comment #27)
> > OTOH, it makes no sense to test if we have hard float. The pack and unpack
> > builtins should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104024
--- Comment #3 from Segher Boessenkool ---
Most of those options were removed. Does this problem (adjusted properly,
those options are now enabled iff you use -mcpu=power10 or later) still
happen on trunk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #27 from Segher Boessenkool ---
OTOH, it makes no sense to test if we have hard float. The pack and unpack
builtins should work (and work the same) whenever long double is double-double.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104595
--- Comment #2 from Segher Boessenkool ---
This is exactly the same as the char case here though, so it is a bit silly
that we miss it :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104590
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91903
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104353
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95082
--- Comment #9 from Segher Boessenkool ---
It still needs fixing on trunk as well, as discussed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
--- Comment #8 from Segher Boessenkool ---
So I am wondering if this is something we want to do at all. It seems not
suitable for stage 4 at all.
The problem is that a "comparison" of a CC against 0 is not a comparison
at all, but the result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104446
--- Comment #5 from Segher Boessenkool ---
This testcase is invalid code of course, so anything can happen. ICEs are bad
though ;-)
Please add to the comment that you don't want this substitution because it
leads
to ICEs, and mention the PR #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104438
--- Comment #3 from Segher Boessenkool ---
Also combine could work that late in principle: it can deal with hard
registers, after all. But it would be a terrible idea. A single combine
pass is expensive enough, we don't want to run it N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
--- Comment #12 from Segher Boessenkool ---
(In reply to HaoChen Gui from comment #11)
> Segher,
> Will you commit your patch in stage4? Several issues are supposed to be
> fixed by your patch. Thanks.
Yes, of course, but there have been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101885
--- Comment #12 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #8)> The failed match attempt
> (parallel [
> (set (reg:QI 82 [ b_lsm_flag.26 ])
> (and:QI (reg:QI 143)
> (reg:QI 145)))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
--- Comment #5 from Segher Boessenkool ---
(In reply to rdapp from comment #4)
> originally ifcvt would only pass e.g.
>
> (unle (reg:SF 129 [ _29 ])
> (reg/v:SF 118 [ highScore ]))
>
> as condition to rs6000_emit_cmove via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
--- Comment #3 from Segher Boessenkool ---
Hi Robin,
Can you please explain what really happens now? What arguments
rs6000_emit_cmove
is called with, and when that goes wrong?
||segher at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #5 from Segher Boessenkool ---
Should be fixed now.
|--- |FIXED
CC||segher at gcc dot gnu.org
--- Comment #3 from Segher Boessenkool ---
Raoni says this is fixed now. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104172
--- Comment #14 from Segher Boessenkool ---
I already approved the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194
--- Comment #5 from Segher Boessenkool ---
Abusing complex fp, what a dastardly plan! :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194
--- Comment #1 from Segher Boessenkool ---
Maybe we should say what actual mode is used in the DWARF info, not the C
way of getting there? So something that denotes DP / double-double / QP,
for our three options for long double?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
--- Comment #8 from Segher Boessenkool ---
Somewhat more constructive... The problem here is that neg isn't pushed
"through" isel insns. This in general means you need to negate both inputs
to the isel of course, but there are cases where that
||segher at gcc dot gnu.org
--- Comment #2 from Segher Boessenkool ---
Do you have a testcase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
--- Comment #7 from Segher Boessenkool ---
> Seems cmp+isel on P9 is sub-optimal.
For this particular test, perhaps. But it is better overall, at least some
years ago. It was benchmarked (with spec), on p9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97071
--- Comment #8 from Segher Boessenkool ---
(In reply to Richard Biener from comment #7)
> Another possibility would be to do this on GIMPLE, creating parts of the
> constant pool early with CONST_DECLs and loads from them for constants that
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
Segher Boessenkool changed:
What|Removed |Added
CC||npiggin at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102169
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
--- Comment #9 from Segher Boessenkool ---
Created attachment 52131
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52131=edit
Proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103686
--- Comment #8 from Segher Boessenkool ---
It is an internal (debugging) option. It isn't documented in the manual, but
indeed it is not marked as Undocumented in rs6000.opt .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #18 from Segher Boessenkool ---
Yes, it is slow. Five sequential dependent integer instructions instead of
one load instruction. Depending on how you benchmark this you possibly won't
see the slowness, the values are stored to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103860
--- Comment #7 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 52089 [details]
> gcc12-pr103860.patch
>
> Not sure I understand what you'd like to see.
Exactly what you did :-) Well, I didn't see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103860
--- Comment #5 from Segher Boessenkool ---
That looks good. But can you always set maybe_check_pro to true (and then
optimise it away of course)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #19 from Segher Boessenkool ---
(In reply to luoxhu from comment #17)
> And what do you mean"This is not canonical form on RTL, and it's not a
> useful form either" in c#7, please? Not understanding the point...
On Gimple it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #18 from Segher Boessenkool ---
(In reply to luoxhu from comment #16)
> > +2016-11-09 Segher Boessenkool
> > +
> > + * simplify-rtx.c (simplify_binary_operation_1): Simplify
> > + (xor (and (xor A B) C) B) to (ior (and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #13 from Segher Boessenkool ---
If we need more than three insns to create a constant we are better off loading
it from memory, in all cases. Maybe three is too much already, at least on
some processors?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #12 from Segher Boessenkool ---
This is my g:72b2f3317b44, two years and a day old :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68150
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103739
--- Comment #4 from Segher Boessenkool ---
Thanks. But the point of this PR is that bootstrapping trunk is broken.
That needs fixing some way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103739
--- Comment #2 from Segher Boessenkool ---
Hi!
I have no idea why not.
$ gdc --version
gdc (GCC) 9.3.1 20200410
and it says
Configured with: /home/segher/src/gcc/configure --prefix=/home/segher/tot
Assignee: ibuclaw at gdcproject dot org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
gdc -fno-PIE -c -g -O2 -fversion=IN_GCC -Wall -Wdeprecated -fno-common -o
d/access.o -MT d/access.o -MMD -MP -MF d/.deps/access.TPo
-I/home/segher/src/gcc/gcc/d -J/home/segher/src
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624
--- Comment #8 from Segher Boessenkool ---
(In reply to Bill Schmidt from comment #6)
> We have __builtin_darn_32 for the 32-bit case. The changes for the two
> 64-bit-only interfaces reflect the previous behavior.
No, that has nothing to do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624
--- Comment #5 from Segher Boessenkool ---
It should work for 32-bit though?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995
--- Comment #11 from Segher Boessenkool ---
Yeah, that could be much more robust.
OTOH this stuff is completely opportunistic in the first place: it handles
only function return values, not any other hard registers (like local
register vars).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100736
--- Comment #3 from Segher Boessenkool ---
Send patches to gcc-patches@, please. Or is there a question? Ask that
question then, please :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995
--- Comment #9 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #7)
> What is this REG_RETURNED thing?
Ah, something added in ira-lives.c, and you call *that* code fragile?
I agree :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995
--- Comment #8 from Segher Boessenkool ---
Also, what is fragile here? This is *removing* fragility and premature
choices!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995
--- Comment #7 from Segher Boessenkool ---
I don't see any problem with aarch64 fwiw.
If RA decides it does not want to tie the new pseudo to the argument
register, it may have a reason for it? Or suboptimal heuristics.
What is this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103568
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103568
--- Comment #1 from Segher Boessenkool ---
Confirmed.
This is cheaper in GPRs until we had the lxvrdx insn, which is power10 (ISA
3.1)
itself.
Wrt dword 1 being zeroed by fp insns. ISA 3.1 has a note saying this was true
on all earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239
--- Comment #10 from Segher Boessenkool ---
(In reply to luoxhu from comment #9)
> > It does matter, if what you are want to see is if it is smaller than zero or
> > greater than zero. CCmode includes those things. There is a CCEQmode for
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063
--- Comment #23 from Segher Boessenkool ---
Trunk does
lookup:
.quad .L.lookup,.TOC.@tocbase,0
.previous
.type lookup, @function
.L.lookup:
.LFB0:
.cfi_startproc
addis 9,2,.LANCHOR0@toc@ha
ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239
--- Comment #8 from Segher Boessenkool ---
(In reply to luoxhu from comment #6)
> > > foo:
> > > .LFB0:
> > > .cfi_startproc
> > > rldicr. 3,3,29,1
> > > beq 0,.L2
> >
> > This is fine, but only because it tests the EQ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239
--- Comment #5 from Segher Boessenkool ---
(In reply to luoxhu from comment #4)
> Simply adjust the sequence of dot instruction could produce expected code,
> is this correct?
No it isn't. Sorry.
> foo:
> .LFB0:
> .cfi_startproc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
--- Comment #9 from Segher Boessenkool ---
Yeah that looks better already, thanks. Please get rid of the debug stuff
still in here, and send to gcc-patches@?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239
--- Comment #3 from Segher Boessenkool ---
(In reply to luoxhu from comment #2)
> (In reply to Segher Boessenkool from comment #1)
> > Confirmed.
> >
> > So the relevant insn
> >
> > (parallel [(set (reg:CC 123)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
--- Comment #7 from Segher Boessenkool ---
(In reply to HaoChen Gui from comment #6)
> Yes, I found that the nonzero_bits doesn't return exact value in other
> pass.
It returns a different value. Neither is "exact".
The version used by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
--- Comment #5 from Segher Boessenkool ---
(In reply to HaoChen Gui from comment #4)
> (define_insn_and_split "*rotl3_insert_8"
> [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
> (plus_ior_xor:GPR (ashift:GPR (match_operand:GPR 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #13 from Segher Boessenkool ---
(In reply to Bill Schmidt from comment #11)
> As I mentioned privately, we could do with an audit of our implementation of
> standard patterns in general, since we tend to find such missing cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #12 from Segher Boessenkool ---
When is the lowering done currently? Only for the ops that have no other way
of doing, and things are merged back to an __int128 immediately after that?
If that is what is going on, then that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #9 from Segher Boessenkool ---
(In reply to Richard Biener from comment #7)
> > I still think it would be best if Gimple did *never* split data. It
> > simply does not know enough about the machine and what the eventual
> > machine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #8 from Segher Boessenkool ---
Btw:
> mfvsrd 9,34
> mfvsrld 8,34
> mfvsrd 11,35
> mfvsrld 10,35
> li 7,1
> cmpd 0,9,11
> bgt 0,.L2
> cmpld 0,9,11
> beq 0,.L5
> .L3:
> li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #6 from Segher Boessenkool ---
Ah, now I see. Thanks!
Power10 has some new 128-bit insns (and p9 and p8 did before, too).
I still think it would be best if Gimple did *never* split data. It
simply does not know enough about the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #2 from Segher Boessenkool ---
Do you maybe have some simple example (of what we generate, and what you say
it should be)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
--- Comment #8 from Segher Boessenkool ---
So it seems to think that all registers in the preferred class,
GEN_OR_VSX_REGS,
are the same cost? They very much are not :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
--- Comment #6 from Segher Boessenkool ---
Not only is this a missed-optimization, it also is a regression (in GCC 10
already). It seems like the root cause here may be the same as in PR102169.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103251
--- Comment #2 from Segher Boessenkool ---
It makes results not reproducable. It is a bug in the test. It is good to
have the pid in the testcase output somewhere of course, just not in the
summary.
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 gnu.org
Target Milestone: ---
TSAN testsuite
401 - 500 of 3144 matches
Mail list logo
