On Sat, 3 Sep 2011, Eric Botcazou wrote:
Well, even when sign-extended there is a constant you can't negate
without overflow. I would start digging for a testcase with
such case - but as said, testcases involving TYPE_IS_SIZETYPE are
very hard to generate for me.
We run thousands of
Well, even when sign-extended there is a constant you can't negate
without overflow. I would start digging for a testcase with
such case - but as said, testcases involving TYPE_IS_SIZETYPE are
very hard to generate for me.
We run thousands of Ada tests every night on many platforms and never
On Sat, Sep 3, 2011 at 11:24 AM, Eric Botcazou ebotca...@adacore.com wrote:
Well, even when sign-extended there is a constant you can't negate
without overflow. I would start digging for a testcase with
such case - but as said, testcases involving TYPE_IS_SIZETYPE are
very hard to generate
Well, for real-world code I believe that. But see all the recent testcases
for corner-cases of our signed-overflow stuff, they all require
hand-crafted testcases involving INT_MIN, no inlining and even -ftrapv.
What I meant to say is, given Ada can construct arbitrary layouted types it
On Sat, Sep 3, 2011 at 5:08 PM, Eric Botcazou ebotca...@adacore.com wrote:
Well, for real-world code I believe that. But see all the recent testcases
for corner-cases of our signed-overflow stuff, they all require
hand-crafted testcases involving INT_MIN, no inlining and even -ftrapv.
What I
Let me jump in on this a little bit, since much of the code in this area
was originally written by me.
Are all sizetype (sub-)expressions always of value in that range?
What do we do about the fact that sizetype is unsigned, so -x always
overflows for x != 0? Thus, do we need to disable all a
On Sat, Sep 3, 2011 at 9:47 PM, Richard Kenner
ken...@vlsi1.ultra.nyu.edu wrote:
Let me jump in on this a little bit, since much of the code in this area
was originally written by me.
Are all sizetype (sub-)expressions always of value in that range?
What do we do about the fact that sizetype
On Sat, Sep 3, 2011 at 10:37 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Sat, Sep 3, 2011 at 9:47 PM, Richard Kenner
ken...@vlsi1.ultra.nyu.edu wrote:
Let me jump in on this a little bit, since much of the code in this area
was originally written by me.
Are all sizetype
So what's your opinion on the bug that triggered the patch in question?
Namely extract_muldiv_1 folding
(((10240 - (sizetype) first) + 1) * 8) /[cl] 8
to
((sizetype) first * 0x0fff8 + 81928) /[cl] 8
to
((sizetype) first * 2305843009213693951 + 10241)
thus, folding A
So what's your opinion on the bug that triggered the patch in question?\
Namely extract_muldiv_1 folding
(((10240 - (sizetype) first) + 1) * 8) /[cl] 8
to
((sizetype) first * 0x0fff8 + 81928) /[cl] 8
to
((sizetype) first * 2305843009213693951 + 10241)
I think this
But they _do_ overflow as my debugging showed, caused by that exact
same extract_muldiv_1 function here:
case PLUS_EXPR: case MINUS_EXPR:
/* See if we can eliminate the operation on both sides. If we can,
we
can return a new PLUS or MINUS. If we can't, the only
On Fri, 2 Sep 2011, Eric Botcazou wrote:
But they _do_ overflow as my debugging showed, caused by that exact
same extract_muldiv_1 function here:
case PLUS_EXPR: case MINUS_EXPR:
/* See if we can eliminate the operation on both sides. If we can,
we
can return a
When making sizetypes no longer sign-extended (they are unsigned)
we run into extract_muldiv_1 miscompiling the Ada RTS during
secondary stack initialization while folding sizes for an allocation.
From
((sizetype) (_GLOBAL.SZ4_system.secondary_stack (PLACEHOLDER_EXPR struct
13 matches
Mail list logo
