https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106867
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106936
--- Comment #2 from Aldy Hernandez ---
This assert was put here to make sure that the legacy get_value_range() wasn't
being called on stuff that legacy couldn't handle (floats, etc), because the
result would ultimately be copied into a value_ran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106936
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654
--- Comment #7 from Aldy Hernandez ---
You could provide an API to access the different relations that hold in either
the outline function, or the .IFN_ASSUME construct. Then ranger could use that
API to access and record the different assertio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654
--- Comment #9 from Aldy Hernandez ---
(In reply to Jason Merrill from comment #8)
> (In reply to Aldy Hernandez from comment #7)
> > Silly question, why can't you expand the [[assume]] construct into:
> >
> > if (x > 5)
> > __builtin_unreach
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654
--- Comment #11 from Aldy Hernandez ---
(In reply to Jason Merrill from comment #10)
> > But wait a minute, is calling a non-const function from [[assume]] even
> > allowed?
>
> Yep, that's the tricky part. Of course, as functions get more co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68097
--- Comment #8 from Aldy Hernandez ---
(In reply to Richard Biener from comment #7)
> Yes, I think fixed in that we can now record info on FP SSA names. There
> are other bugs for specific things.
>
> What's not fixed is that we still recurse t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106970
--- Comment #2 from Aldy Hernandez ---
Works on mainline. I can add a testcase though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967
--- Comment #5 from Aldy Hernandez ---
Does that mean we can assume the incoming edge from BB9 as unreachable?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967
--- Comment #6 from Aldy Hernandez ---
>
> finite_operands_p() must be adjusted for the case where there is a NAN in
> the source...but still.. is PRE supposed to be adding NANs?
What i meant to say here was the users of finite operands p mus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106970
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967
--- Comment #8 from Aldy Hernandez ---
Created attachment 53595
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53595&action=edit
patch in testing
This was painful. I had audit all the relational code to make sure we're
handling NANs befo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967
--- Comment #9 from Aldy Hernandez ---
Created attachment 53596
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53596&action=edit
another patch in testing
This one may be needed as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106970
Aldy Hernandez changed:
What|Removed |Added
Resolution|WORKSFORME |DUPLICATE
--- Comment #6 from Aldy Her
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967
--- Comment #10 from Aldy Hernandez ---
*** Bug 106970 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106970
--- Comment #8 from Aldy Hernandez ---
abulafia:~/bld/t/gcc$ cat a.c
int script_obj_as_number_obj, script_obj_as_number_obj_0_0;
double script_obj_as_number() {
if (script_obj_as_number_obj)
return script_obj_as_number_obj_0_0;
return _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967
--- Comment #12 from Aldy Hernandez ---
(In reply to Richard Biener from comment #11)
> Btw,
>
> static inline bool
> finite_operands_p (const frange &op1, const frange &op2)
> {
> return flag_finite_math_only || (!op1.maybe_isnan () && !op2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106967
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009
--- Comment #2 from Aldy Hernandez ---
(In reply to Marek Polacek from comment #1)
> Looks like it was caused by r13-1268-g8c99e307b20c50:
>
> commit 8c99e307b20c502e55c425897fb3884ba8f05882
> Author: Aldy Hernandez
> Date: Sat Jun 25 18:58:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009
--- Comment #4 from Aldy Hernandez ---
(In reply to Richard Biener from comment #3)
> # RANGE [irange] size_t [1, +INF]
> size_t n_12(D) = n;
>
> the nonzero bits info on 'n' is gone. DOM2 used to produce that and
> CCP3 elides the __built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009
--- Comment #5 from Aldy Hernandez ---
There are two things needed to fix this regression.
First, we need an op1_range entry for bitwise-and, so that the 2->4 edge range
has the correct nonzero bits for n_12.
[local count: 118111600]:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009
--- Comment #6 from Aldy Hernandez ---
Created attachment 53621
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53621&action=edit
bitwise and op1_range patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009
--- Comment #7 from Aldy Hernandez ---
Created attachment 53622
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53622&action=edit
DOM patch in testing to calculate ranges for all ranges involving unreachable
edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107046
--- Comment #1 from Aldy Hernandez ---
The target seems to set flag_finite_math_only. We are much more aggressive at
folding comparisons involving infinities with this flag.
config/rx/rx.cc:
/* Alert the user if they are changing the op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107046
--- Comment #4 from Aldy Hernandez ---
(In reply to Richard Biener from comment #3)
> Ah, probably the
>
> void test(double f, double i)
> {
> ...
> if (i != __builtin_inf())
> abort ();
>
> int main()
> {
> test (34.0, __builtin_inf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107043
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107053
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107052
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2022-09-27
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107052
--- Comment #4 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Aldy Hernandez from comment #2)
> > Don't you mean the only values for popcount are 0-2? I mean, there are only
> > two bits that could be 1 with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107052
--- Comment #5 from Aldy Hernandez ---
Created attachment 53633
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53633&action=edit
patch in testing
This might do it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107053
Aldy Hernandez changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107130
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107130
--- Comment #5 from Aldy Hernandez ---
Created attachment 53656
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53656&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107130
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107052
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107170
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107170
--- Comment #1 from Aldy Hernandez ---
Created attachment 53672
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53672&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107170
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #3 from Aldy Hernandez ---
(In reply to Martin Liška from comment #2)
> Started with r13-1268-g8c99e307b20c502e.
Disabling DOM with -fno-tree-dominator-opts still causes the crash, so it's not
this patch that caused the problem. Fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107195
--- Comment #4 from Aldy Hernandez ---
*** Bug 107194 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107194
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107195
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107195
--- Comment #6 from Aldy Hernandez ---
Created attachment 53687
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53687&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107195
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107286
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107293
--- Comment #2 from Aldy Hernandez ---
Created attachment 53717
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53717&action=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107293
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299
--- Comment #1 from Aldy Hernandez ---
I can't reproduce on gcc135.fsffrance.org with default parameters on a
bootstrap.
Is there a way to reproduce this on said machine? Or could you provide a .i
file that could be used with a cross?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299
--- Comment #4 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #3)
> We are failing while trying to fold:
>
> c_92 = __builtin_copysignf128 (0.0, c_80(D));
>
> The problem is that c_92 is TFtype but 0.0 is _Float128. TFtype h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299
--- Comment #6 from Aldy Hernandez ---
Created attachment 53718
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53718&action=edit
preprocessed testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299
--- Comment #7 from Aldy Hernandez ---
It looks like the 0.0 with the wrong type is there quite early in the pipeline.
At least by einline (after SSA and CFG have been built) we have:
(gdb) p debug(gs)
c_92 = __builtin_copysignf128 (0.0, c_80(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107312
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107312
--- Comment #3 from Aldy Hernandez ---
Created attachment 53730
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53730&action=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107312
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107342
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107342
--- Comment #2 from Aldy Hernandez ---
Created attachment 53749
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53749&action=edit
untested patch
I'm sure somebody smarter could handle other shift amounts that are not powers
of 2, but this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107342
Aldy Hernandez changed:
What|Removed |Added
Attachment #53749|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
--- Comment #6 from Aldy Hernandez ---
Please bear with me, as I'm coming up to speed, and my head hurts from all
these equivalences.
The problem seems to be what Jeff mentioned in comment #4.
We think _5 == _6, which makes the conditional in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
--- Comment #7 from Aldy Hernandez ---
After chatting with Andrew about this, it seems the problem is we are starting
a path mid-loop and crossing a backedge. This causes us to use relations we
had on one iteration in another iteration.
[lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104067
--- Comment #6 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #5)
> I briefly looked at the other BZ last week, but didn't make much headway.
> The first thing that stood out was why are we threading around the loop. I
> thou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
--- Comment #11 from Aldy Hernandez ---
The testcase for PR104067 shows an example where the dominance matters,
irregardless of if we reset relations at the backedge point. There we have a
path that looks like 9->3->5->...:
[local count: 106
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
--- Comment #12 from Aldy Hernandez ---
Created attachment 52240
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52240&action=edit
proposed untested patch
This is a proposed patch that fixes both PRs. Perhaps we can tweak the
dominance ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104067
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
Aldy Hernandez changed:
What|Removed |Added
CC||bonzini at gnu dot org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
Aldy Hernandez changed:
What|Removed |Added
CC||jeffreyalaw at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #8 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #7)
> Very cool. ANd no, I'm not enough of an expert on the FP side to shepherd
> that though. I would expect it to be exceptionally tricky on the solver
> side.
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #11 from Aldy Hernandez ---
Created attachment 51726
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51726&action=edit
untested improvement to ranger cache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103062
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
Resol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
Aldy Hernandez changed:
What|Removed |Added
Depends on||103058
--- Comment #18 from Aldy Herna
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #20 from Aldy Hernandez ---
With attachment 51726 and current trunk, the present damage is 22% for the
ltrans105 unit, which AFAICT, is the worst offender. This is much better than
the original 44%, but still not ideal.
After some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #22 from Aldy Hernandez ---
(In reply to Martin Liška from comment #21)
> > For the record, I hate the SPEC build system :).
>
> Then you're the first one! No, just kidding, it's cumbersome, and feel free
> to contact me with questi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #4 from Aldy Hernandez ---
(In reply to Martin Liška from comment #1)
> The following file is miscompiled:
>
> gfortran -c -o m_MergeSorts.fppized.o -I. -Iinclude -Inetcdf/include -O2
> -march=native -g -std=legacy m_MergeSorts.fppi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #5 from Aldy Hernandez ---
> That is, is signed overflow undefined in overflow?
Errr, "is signed overflow undefined for integer(kind=4)?"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #7 from Aldy Hernandez ---
Simplified version without the noise:
[local count: 56063504182]:
_134 = M.10_120 + 1;
if (_71 <= _134)
goto ; [11.00%]
else
goto ; [89.00%]
...
...
[local count: 49896518755]:
[l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #9 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Aldy Hernandez from comment #5)
> > > That is, is signed overflow undefined in overflow?
> >
> > Errr, "is signed overflow undefined for integer(k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #13 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #12)
> I dont understand why? isnt m.10_120 killed in bb20? whats the basis
> for threading that? I dont see it
Huh. The last thing we do in the solver is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #15 from Aldy Hernandez ---
Created attachment 51740
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51740&action=edit
untested patch
This should do it. Martin, can you verify this fixes it on your end?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101240
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 103061, which changed state.
Bug 103061 Summary: [12 Regression] 527.cam4_r miscompiled with -O2
-march=znver1 since r12-4790-g4b3a325f07acebf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
What|Remo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #26 from Aldy Hernandez ---
(In reply to Jan Hubicka from comment #25)
> LNT sees new regresion on WRF build times (around 6%) at Nov 3
>
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=287.548.8
> https://lnt.opensuse.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #5 from Aldy Hernandez ---
(In reply to Christophe Lyon from comment #4)
> If I'm not mistaken, if you click on "REGRESSED" for that specific line,
> you'll see that only ssa-dom-thread-7.c actually regressed with the
> corresponding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #11 from Aldy Hernandez ---
>From what I gather, this is only reproducible with PGO. If so, it may be worth
nothing that Jeff has mentioned that the backward threader probably does not do
a very good job with keeping profile counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #12 from Aldy Hernandez ---
It's been mentioned that this SPEC test has irreconcilable differences between
the train and peak runs, and cannot be reasonably compared. Is the slowdown
reported between two runs of compatible runs (two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #13 from Aldy Hernandez ---
Since DOM is the only threading pass that keeps more or less accurate
profiling data, here's a very wild guess.
The pre-loop DOM threading pass does not thread some paths because of
the restrictions in pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
Aldy Hernandez changed:
What|Removed |Added
Component|middle-end |testsuite
--- Comment #7 from Aldy Her
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
Aldy Hernandez changed:
What|Removed |Added
CC||jeffreyalaw at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #18 from Aldy Hernandez ---
> If I read it correctly, for a path that enters the loop and later leaves
> it (where threading is desirable since we skip the whole loop) the logic
> above will still return true (after finishing the wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #8 from Aldy Hernandez ---
This may be related to the discussion in PR102997, particularly comment 16.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103120
--- Comment #5 from Aldy Hernandez ---
This is an ordering issue in the path solver, and it's not even relation
related! How interesting.
./xgcc -B./ a.c -O2 -fdisable-tree-ethread -fdisable-tree-thread1
-fdisable-tree-thread2 -fdisable-tree-t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103120
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #27 from Aldy Hernandez ---
(In reply to Richard Biener from comment #20)
> (In reply to hubicka from comment #19)
> > The testcase would be
> >
> > void test ()
> > {
> > int i;
> > if (test())
> > i=0;
>
201 - 300 of 752 matches
Mail list logo
