https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986
--- Comment #4 from Aldy Hernandez ---
(In reply to Richard Biener from comment #3)
> This is peeling leaving us with unreachable code we warn on and somehow
> while figuring prephitmp_30 + -6 is -1 we don't figure nb_58 is zero on
> the path to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986
--- Comment #6 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #4)
> (In reply to Richard Biener from comment #3)
> > This is peeling leaving us with unreachable code we warn on and somehow
> > while figuring prephitmp_30 + -6 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
--- Comment #10 from Aldy Hernandez ---
(In reply to Richard Biener from comment #9)
> I think threading unlikely paths is never worth it and usually NULL pointer
> checks are statically predicted.
>
> I guess one idea would be to scale BB cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892
--- Comment #9 from Aldy Hernandez ---
This is an invalid test. The variable "a" is being used before being set. I
think we should actually remove the test from the testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105151
--- Comment #2 from Aldy Hernandez ---
(In reply to Richard Biener from comment #1)
> going down passes after errors is always tricky - we do stop but it seems
> the diagnostic passes are still run because they are part of "lowering"
> (why is p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #22 from Aldy Hernandez ---
> This doesn't take flag_rounding_math or not always exactly precise floating
> point computations into account.
> It is also missing real_convert after real_arithmetics that performs at least
> some of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #23 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #22)
> > This doesn't take flag_rounding_math or not always exactly precise floating
> > point computations into account.
> > It is also missing real_convert after r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105346
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105346
--- Comment #14 from Aldy Hernandez ---
(In reply to Richard Biener from comment #13)
> (In reply to Andrew Macleod from comment #11)
> > (In reply to Richard Biener from comment #6)
> >
> > >
> > >:
> > > bufp_2 = &buf;
> > > if (&buf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105346
--- Comment #16 from Aldy Hernandez ---
(In reply to Richard Biener from comment #15)
> If it isn't possible to use ranger at the moment to resolve this at
> the point of the free() call I wouldn't bother. I think the correct
Ranger at the mo
gcc dot gnu.org |aldyh at gcc dot gnu.org
Last reconfirmed||2022-04-29
Ever confirmed|0 |1
--- Comment #5 from Aldy Hernandez ---
set_range_info does not handle VR_VARYING because SSA_NAME_RANGE_TYPE can only
store VR_RANGE or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105432
--- Comment #6 from Aldy Hernandez ---
Created attachment 52910
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52910&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106432
--- Comment #3 from Aldy Hernandez ---
Created attachment 53346
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53346&action=edit
untested patch
Ughhh, mine.
We need to check if we support ranges of the given type before we query the
rang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106432
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106432
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106444
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106444
--- Comment #4 from Aldy Hernandez ---
Created attachment 53356
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53356&action=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106444
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422
Aldy Hernandez changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422
--- Comment #14 from Aldy Hernandez ---
Created attachment 53373
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53373&action=edit
Untested patch
The important part is the change to tree-ssa-threadupdate.cc. The rest is just
making sure t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #25 from Aldy Hernandez ---
Adding some notes here as I work through this PR...
Even with floating aware VRP, we won't be able to do much because SCEV (which
ranger and VRP use) does not work with non-integers.
At EVRP time we see:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106495
--- Comment #9 from Aldy Hernandez ---
(In reply to Richard Biener from comment #7)
> So in this case we have
>
> (gdb) p *path->m_vec->m_vecdata[0]
> $106 = {e = 7)>, type = EDGE_COPY_SRC_BLOCK}
> (gdb) p *path->m_vec->m_vecdata[1]
> $107 = {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #26 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #19)
> We can use the original testcase as the litmus test for basic support if we
> compile it with
>
> -O2 -fno-tree-fre -fno-tree-dominator-opts
>
> The unrol
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aldyh at gcc dot gnu.org
CC: amacleod at redhat dot com, jakub at gcc dot gnu.org
Target Milestone: ---
As mentioned in this thread, enabling frange operators in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106510
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2022-08-02
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106630
--- Comment #2 from Aldy Hernandez ---
Works with -fno-thread-jumps or with -fdisable-tree-dom3.
I haven't investigated whether the threading done in DOM2 is generating invalid
IL, but it looks like this match.pd pattern is going around in circ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106630
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106630
--- Comment #5 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #4)
> > It looks like DOM2, as a side-effect of using the ranger to do cprop, is
> > exporting a global range for a_9
> > Where a_9 has a global range of [0,0].
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106630
--- Comment #7 from Aldy Hernandez ---
(In reply to Richard Biener from comment #6)
> The comment about DOM + missing cprop remains of course.
This seems like a longstanding problem with DOM (cpropping into PHI args with
range information), as
||2022-08-17
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #2 from Aldy Hernandez ---
(In reply to Richard Biener from comment #1)
> Created attachment 53468 [details]
> patch res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106679
Aldy Hernandez changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106785
--- Comment #1 from Aldy Hernandez ---
(In reply to Martin Liška from comment #0)
> Fails for the following cross compilers:
> pdp11-aout rx-elf vax-linux-gnu vax-netbsdelf
>
> $ ./xgcc -v
> Using built-in specs.
> COLLECT_GCC=./xgcc
> Targe
|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from Aldy Hernandez ---
Nevermind, got it.
HONOR_NANS is off by default on VAX, and the tests assume NANs, which we drop
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106785
--- Comment #3 from Aldy Hernandez ---
Created attachment 53523
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53523&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106785
Aldy Hernandez changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106789
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106785
--- Comment #6 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #5)
> If !MODE_HAS_NANS, then NANs can't appear ever, that is the VAX case.
> Some floating point formats simply have no representation for those.
> If MODE_HAS_NANS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106785
--- Comment #7 from Aldy Hernandez ---
And how about __builtin_nan ("") == xxx ??
Is that undefined for !HONOR_NANS? Can I continue treating it as false?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106785
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106814
--- Comment #1 from Aldy Hernandez ---
How do I reproduce this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106819
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106819
--- Comment #3 from Aldy Hernandez ---
Created attachment 53532
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53532&action=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106814
Aldy Hernandez changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106819
--- Comment #4 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #1)
> Global Exported: iftmp.2_6 = [frange] double [0.0, 0.0] !SIGN
> Folding PHI node: iftmp.2_6 = PHI <0.0(4), Nan(5)>
> Queued PHI for removal. Folds to: 0.0
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106819
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106814
--- Comment #7 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #6)
> This may be a DUP of 106819. Does the patch in it solve this PR?
Patch committed upstream btw...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106819
--- Comment #7 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #1)
> BTW, regarding sign, generally NaNs can have either sign, though in this
> testcase we know the sign is clear (positive NaN). Not sure how much we can
> rely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106819
--- Comment #8 from Aldy Hernandez ---
Created attachment 53534
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53534&action=edit
Do not clobber signbit when unioning a NAN.
Untested patch to maintain signbit when unioning a NAN with anoth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106819
--- Comment #10 from Aldy Hernandez ---
Got it. Less work for me :-). Thanks for the explanation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106819
--- Comment #11 from Aldy Hernandez ---
I'll just fix union and implement copysign folding and leave it at that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106814
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824
--- Comment #4 from Aldy Hernandez ---
Yeah, that's all me.
I can't reproduce on x86-64, but there's been a couple patches in this area
over the weekend. Could you double check again on an updated trunk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
--- Comment #2 from Aldy Hernandez ---
And yes, I've started testing mpfr now for my frange patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2022-09-05
Status|RESOLVED
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Comment #10 from Aldy Hernandez ---
This is interesting.
We are trying to thread 5->7->8->9->3->??.
The path starts like this:
[local count: 81335936906]:
SR.30_3 = Nan;
goto ; [100.00%]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
--- Comment #6 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #5)
> BTW, I admit I don't know much about decimal{32,64,128}, but
> https://en.wikipedia.org/wiki/Decimal32_floating-point_format
> says:
> Because the significand i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824
--- Comment #11 from Aldy Hernandez ---
Created attachment 53539
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53539&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
--- Comment #8 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #7)
> I guess disabling them at least for now could be fine.
> If somebody involved with dfp wants to extend it for dfp, it can be done
> incrementally.
>
> BTW, thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106824
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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
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
1201 - 1300 of 1818 matches
Mail list logo
