On Wed, Jul 26, 2017 at 1:35 PM, Marek Polacek wrote:
> On Tue, Jul 25, 2017 at 03:47:31PM +0200, Richard Biener wrote:
>> On Tue, Jul 25, 2017 at 3:30 PM, Eric Botcazou wrote:
>> >> Eric, any comments?
>> >
>> > No objection for the build2_stat hunk, I think it's in keeping with the Ada
>> > sem
On Tue, Jul 25, 2017 at 03:47:31PM +0200, Richard Biener wrote:
> On Tue, Jul 25, 2017 at 3:30 PM, Eric Botcazou wrote:
> >> Eric, any comments?
> >
> > No objection for the build2_stat hunk, I think it's in keeping with the Ada
> > semantics. But the tree_could_trap_p hunk is certainly an abomin
On Tue, Jul 25, 2017 at 3:30 PM, Eric Botcazou wrote:
>> Eric, any comments?
>
> No objection for the build2_stat hunk, I think it's in keeping with the Ada
> semantics. But the tree_could_trap_p hunk is certainly an abomination...
>
>> We could also avoid tree_could_trap_p by special-casing only
> Eric, any comments?
No objection for the build2_stat hunk, I think it's in keeping with the Ada
semantics. But the tree_could_trap_p hunk is certainly an abomination...
> We could also avoid tree_could_trap_p by special-casing only
> *_DIV_EXPR and *_MOD_EXPR
> with integer zero 2nd operand e
On Tue, Jul 25, 2017 at 2:19 PM, Marek Polacek wrote:
> On Thu, Jul 20, 2017 at 08:22:59PM +0200, Richard Biener wrote:
>> No, we shouldn't. Maybe trapping ops shouldn't be marked TREE_CONSTANT?
>> (Make sure to test with Ada...)
>
> That works for both testcases, but I can't say I really like th
On Thu, Jul 20, 2017 at 08:22:59PM +0200, Richard Biener wrote:
> No, we shouldn't. Maybe trapping ops shouldn't be marked TREE_CONSTANT?
> (Make sure to test with Ada...)
That works for both testcases, but I can't say I really like the idea of
modifying build2... but it's where the TREE_CONSTANT
On July 20, 2017 4:20:00 PM GMT+02:00, Marek Polacek wrote:
>On Thu, Jul 20, 2017 at 12:55:10PM +0200, Richard Biener wrote:
>> On Wed, Jul 19, 2017 at 3:55 PM, Marek Polacek
>wrote:
>> > On Wed, Jul 19, 2017 at 12:45:12PM +0200, Richard Biener wrote:
>> >> On Tue, Jul 18, 2017 at 6:05 PM, Marek
On Thu, Jul 20, 2017 at 12:55:10PM +0200, Richard Biener wrote:
> On Wed, Jul 19, 2017 at 3:55 PM, Marek Polacek wrote:
> > On Wed, Jul 19, 2017 at 12:45:12PM +0200, Richard Biener wrote:
> >> On Tue, Jul 18, 2017 at 6:05 PM, Marek Polacek wrote:
> >> > We ended up in infinite recursion between e
On Wed, Jul 19, 2017 at 3:55 PM, Marek Polacek wrote:
> On Wed, Jul 19, 2017 at 12:45:12PM +0200, Richard Biener wrote:
>> On Tue, Jul 18, 2017 at 6:05 PM, Marek Polacek wrote:
>> > We ended up in infinite recursion between extract_muldiv_1 and
>> > fold_plusminus_mult_expr, because one turns thi
On Wed, Jul 19, 2017 at 12:45:12PM +0200, Richard Biener wrote:
> On Tue, Jul 18, 2017 at 6:05 PM, Marek Polacek wrote:
> > We ended up in infinite recursion between extract_muldiv_1 and
> > fold_plusminus_mult_expr, because one turns this expression into the other
> > and the other does the rever
On Tue, Jul 18, 2017 at 6:05 PM, Marek Polacek wrote:
> We ended up in infinite recursion between extract_muldiv_1 and
> fold_plusminus_mult_expr, because one turns this expression into the other
> and the other does the reverse:
>
> ((2147483648 / 0) * 2) + 2 <-> 2 * (2147483648 / 0 + 1)
>
> I tr
We ended up in infinite recursion between extract_muldiv_1 and
fold_plusminus_mult_expr, because one turns this expression into the other
and the other does the reverse:
((2147483648 / 0) * 2) + 2 <-> 2 * (2147483648 / 0 + 1)
I tried (unsuccessfully) to fix it in either extract_muldiv_1 or
fold_p
12 matches
Mail list logo
