> It was OK until revision 187042:
>
> 2012-05-02 Richard Guenther
>
> * tree.c (valid_constant_size_p): New function.
> * tree.h (valid_constant_size_p): Declare.
> * cfgexpand.c (expand_one_var): Adjust check for too large
> variables by using valid_consta
On Wed, Oct 31, 2012 at 6:57 PM, H.J. Lu wrote:
> On Wed, Oct 31, 2012 at 3:53 PM, H.J. Lu wrote:
>> On Wed, Oct 31, 2012 at 7:29 AM, Eric Botcazou wrote:
>>>
>>> > It failed with revision 188008.
>>>
>>> OK, thanks. So the testcase never compiled on the trunk (except for about
>>> 24
>>> hours
On Wed, Oct 31, 2012 at 7:14 PM, H.J. Lu wrote:
> On Wed, Oct 31, 2012 at 6:57 PM, H.J. Lu wrote:
>> On Wed, Oct 31, 2012 at 3:53 PM, H.J. Lu wrote:
>>> On Wed, Oct 31, 2012 at 7:29 AM, Eric Botcazou
>>> wrote:
> It failed with revision 188008.
OK, thanks. So the testcase
On Wed, Oct 31, 2012 at 6:57 PM, H.J. Lu wrote:
> On Wed, Oct 31, 2012 at 3:53 PM, H.J. Lu wrote:
>> On Wed, Oct 31, 2012 at 7:29 AM, Eric Botcazou wrote:
>>>
>>> > It failed with revision 188008.
>>>
>>> OK, thanks. So the testcase never compiled on the trunk (except for about
>>> 24
>>> hours
On Wed, Oct 31, 2012 at 3:53 PM, H.J. Lu wrote:
> On Wed, Oct 31, 2012 at 7:29 AM, Eric Botcazou wrote:
>>
>> > It failed with revision 188008.
>>
>> OK, thanks. So the testcase never compiled on the trunk (except for about
>> 24
>> hours between 188009 & 188118) or did it compile before 188008
On Wed, Oct 31, 2012 at 7:29 AM, Eric Botcazou wrote:
>
> > It failed with revision 188008.
>
> OK, thanks. So the testcase never compiled on the trunk (except for about
> 24
> hours between 188009 & 188118) or did it compile before 188008 at some
> point?
>
> --
> Eric Botcazou
It was OK until
> It failed with revision 188008.
OK, thanks. So the testcase never compiled on the trunk (except for about 24
hours between 188009 & 188118) or did it compile before 188008 at some point?
--
Eric Botcazou
On Wed, Oct 31, 2012 at 5:42 AM, Eric Botcazou wrote:
>> Your change caused:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142
>
> Please check whether it worked before Richard's fix (r188009).
>
It failed with revision 188008.
--
H.J.
> Your change caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142
Please check whether it worked before Richard's fix (r188009).
--
Eric Botcazou
On Fri, Jun 1, 2012 at 3:29 AM, Eric Botcazou wrote:
>> Well, it would rather be
>>
>> TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg0))
>> && TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg1))
>>
>> but only in the !FLOAT_TYPE_P path.
>
> That works in all cases I think, see exis
On Fri, 1 Jun 2012, Eric Botcazou wrote:
> > Well, it would rather be
> >
> > TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg0))
> > && TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg1))
> >
> > but only in the !FLOAT_TYPE_P path.
>
> That works in all cases I think, see existing
> Well, it would rather be
>
> TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg0))
> && TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg1))
>
> but only in the !FLOAT_TYPE_P path.
That works in all cases I think, see existing cases in the folder.
> We could even compare
> TYPE_OVER
On Fri, 1 Jun 2012, Eric Botcazou wrote:
> > Ah, I see. So the proper fix would be to use STRIP_NOP()ed op0/op1,
> > something not readily available though.
>
> Why not just add
>
> TYPE_UNSIGNED (TREE_TYPE (op0)) == TYPE_UNSIGNED (TREE_TYPE (arg0))
> && TYPE_UNSIGNED (TREE_TYPE (op1)) == T
> Ah, I see. So the proper fix would be to use STRIP_NOP()ed op0/op1,
> something not readily available though.
Why not just add
TYPE_UNSIGNED (TREE_TYPE (op0)) == TYPE_UNSIGNED (TREE_TYPE (arg0))
&& TYPE_UNSIGNED (TREE_TYPE (op1)) == TYPE_UNSIGNED (TREE_TYPE (arg1))
with a small comment?
On Fri, 1 Jun 2012, Eric Botcazou wrote:
> > So, what case do you see disabled where there is no sign conversion
> > involved?
>
> For the Ada testcase I attached, in fold_binary_loc we have:
>
> (gdb) p debug_tree(op0)
> type size
> unit size
> align 64 symtab 0
> So, what case do you see disabled where there is no sign conversion
> involved?
For the Ada testcase I attached, in fold_binary_loc we have:
(gdb) p debug_tree(op0)
unit size
align 64 symtab 0 alias set -1 canonical type 0x76fdd0a8 precision
64 min max >
readonly
On Fri, 1 Jun 2012, Eric Botcazou wrote:
> > The issue is that fold_plusminus_mult re-writes the multiplication
> > from unsigned to signed for the failing testcase, introducing
> > undefined overflow.
>
> fold_plusminus_mult or fold_binary? My understanding is that the problem is
> fold_binary
> The issue is that fold_plusminus_mult re-writes the multiplication
> from unsigned to signed for the failing testcase, introducing
> undefined overflow.
fold_plusminus_mult or fold_binary? My understanding is that the problem is
fold_binary incorrectly stripping the outer signedness conversion
On Thu, 31 May 2012, Eric Botcazou wrote:
> > This fixes PR53501, fold_plusminus_mult_expr does not expect that
> > operands have a sign-conversion stripped. So don't call it with
> > such arguments.
> >
> > Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
> >
> > Richard.
> >
> > 2012-
> This fixes PR53501, fold_plusminus_mult_expr does not expect that
> operands have a sign-conversion stripped. So don't call it with
> such arguments.
>
> Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
>
> Richard.
>
> 2012-05-30 Richard Guenther
>
> PR middle-end/53501
>
This fixes PR53501, fold_plusminus_mult_expr does not expect that
operands have a sign-conversion stripped. So don't call it with
such arguments.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
Richard.
2012-05-30 Richard Guenther
PR middle-end/53501
* fold-const
21 matches
Mail list logo
