https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #30 from Aldy Hernandez ---
On 5/26/21 3:23 PM, rguenther at suse dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
>
> --- Comment #29 from rguenther at suse dot de ---
> On Wed, 26 May 2021, amacleod at redhat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #29 from rguenther at suse dot de ---
On Wed, 26 May 2021, amacleod at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
>
> --- Comment #28 from Andrew Macleod ---
> (In reply to rguent...@suse.de from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #28 from Andrew Macleod ---
(In reply to rguent...@suse.de from comment #27)
> On Wed, 26 May 2021, aldyh at redhat dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
> >
> > --- Comment #26 from Aldy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #27 from rguenther at suse dot de ---
On Wed, 26 May 2021, aldyh at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
>
> --- Comment #26 from Aldy Hernandez ---
> On Wed, May 26, 2021 at 10:34 AM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #26 from Aldy Hernandez ---
On Wed, May 26, 2021 at 10:34 AM rguenther at suse dot de
wrote:
> It's probably too strict for multiple_of_p which is fine with
> overflows that preserve modulo behavior.
Could you provide an example?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #25 from rguenther at suse dot de ---
On Wed, 26 May 2021, aldyh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
>
> --- Comment #23 from Aldy Hernandez ---
> I have an upcoming patchset that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #24 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #23)
> The above yields overflow for the 16-bit expression in question:
>
> (gdb) p debug(top)
> g_2823_lsm.5_6 * 7854 + 57682
>
> (gdb) p may_overflow_p (top)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #23 from Aldy Hernandez ---
I have an upcoming patchset that implements a range evaluator for tree
expressions (similar to determine_value_range), as well as a gimple_ranger that
evaluates expressions in a higher precision. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #22 from Jeffrey A. Law ---
I have vague memories of it, but it wasn't my code. It was actually Craig
Burley. It's original purpose was merely to allow converting *_DIV_EXPR into
EXACT_DIV_EXPR which presumably was important for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #21 from Andrew Macleod ---
> >
> > Would this be useful? and would it solve this problem? I'm sure there are
> > other details to work out related to the increased precision, but it seems
> > like it might work?
>
> Hmm, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #20 from Aldy Hernandez ---
On Wed, May 19, 2021 at 8:31 AM rguenth at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
>
> --- Comment #17 from Richard Biener ---
> (In reply to Andrew Macleod from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #19 from bin cheng ---
(In reply to bin cheng from comment #18)
> Did some experiments, there are two fallouts after explicitly returning
> false for unsigned/wrapping types in MULT_EXPR/MINUS_EXPR/PLUS_EXPR. One is
> the mentioned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #18 from bin cheng ---
Did some experiments, there are two fallouts after explicitly returning false
for unsigned/wrapping types in MULT_EXPR/MINUS_EXPR/PLUS_EXPR. One is the
mentioned use of multiple_of_p in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #17 from Richard Biener ---
(In reply to Andrew Macleod from comment #16)
> Aldy and I are discussing this.
>
> Ranger itself can't do anything outside of the gimple IL, its effectively
> just a GIMPLE interface to range-ops. ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
Andrew Macleod changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #15 from rguenther at suse dot de ---
On Tue, 18 May 2021, amker at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
>
> --- Comment #14 from bin cheng ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #14 from bin cheng ---
(In reply to Richard Biener from comment #12)
> So in number_of_iterations_ne it looks like the step 's' is always constant
> which makes me wonder if we can somehow use ranger to tell multiple_of_p
> (type,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #13 from bin cheng ---
(In reply to Richard Biener from comment #10)
> (In reply to bin cheng from comment #9)
> > Seems we have a long standing bug in fold-const.c:multiple_of_p in case of
> > wrapping types. Take unsigned int as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
Richard Biener changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #10 from Richard Biener ---
(In reply to bin cheng from comment #9)
> Seems we have a long standing bug in fold-const.c:multiple_of_p in case of
> wrapping types. Take unsigned int as an example:
> (0xfffc * 0x3) % 0x3 = 0x1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #9 from bin cheng ---
Seems we have a long standing bug in fold-const.c:multiple_of_p in case of
wrapping types. Take unsigned int as an example:
(0xfffc * 0x3) % 0x3 = 0x1
But multiple_of_p returns true here.
The same issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #8 from Martin Liška ---
(In reply to bin cheng from comment #7)
> (In reply to Martin Liška from comment #4)
> > (In reply to Martin Liška from comment #3)
> > > But expected result is end g_2823 = 32768, right?
> > > Clang returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
bin cheng changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
Richard Biener changed:
What|Removed |Added
Known to work|11.1.0 |
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #5 from John Dong ---
(In reply to Martin Liška from comment #3)
> But expected result is end g_2823 = 32768, right?
> Clang returns the same result 32768.
Yes, I think so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
Martin Liška changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #3 from Martin Liška ---
But expected result is end g_2823 = 32768, right?
Clang returns the same result 32768.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
Richard Biener changed:
What|Removed |Added
Known to work||11.1.0
Ever confirmed|0
30 matches
Mail list logo
