On 12/14/2016 08:46 AM, Bernd Schmidt wrote:
On 12/12/2016 03:21 PM, Bernd Schmidt wrote:
On 12/10/2016 08:58 PM, Segher Boessenkool wrote:
On Thu, Dec 08, 2016 at 01:21:04PM +0100, Bernd Schmidt wrote:
This is another case where an optimization turns a trap_if
unconditional. We have to defer
On Wed, Dec 14, 2016 at 11:49:26AM -0600, Segher Boessenkool wrote:
> On Wed, Dec 14, 2016 at 04:46:09PM +0100, Bernd Schmidt wrote:
> > That would be this patch. Tested as before. The two new testcases seem
> > to pass with a ppc cross (but I would appreciate if someone were to run
> > full
On Wed, Dec 14, 2016 at 04:46:09PM +0100, Bernd Schmidt wrote:
> That would be this patch. Tested as before. The two new testcases seem
> to pass with a ppc cross (but I would appreciate if someone were to run
> full tests on ppc).
Thanks, will do.
Segher
On 12/12/2016 03:21 PM, Bernd Schmidt wrote:
On 12/10/2016 08:58 PM, Segher Boessenkool wrote:
On Thu, Dec 08, 2016 at 01:21:04PM +0100, Bernd Schmidt wrote:
This is another case where an optimization turns a trap_if
unconditional. We have to defer changing the CFG, since the rest of
cprop
On 12/10/2016 08:58 PM, Segher Boessenkool wrote:
On Thu, Dec 08, 2016 at 01:21:04PM +0100, Bernd Schmidt wrote:
This is another case where an optimization turns a trap_if
unconditional. We have to defer changing the CFG, since the rest of
cprop seems to blow up when we modify things while
On Thu, Dec 08, 2016 at 01:21:04PM +0100, Bernd Schmidt wrote:
> This is another case where an optimization turns a trap_if
> unconditional. We have to defer changing the CFG, since the rest of
> cprop seems to blow up when we modify things while scanning.
>
> Bootstrapped and tested on
This is another case where an optimization turns a trap_if
unconditional. We have to defer changing the CFG, since the rest of
cprop seems to blow up when we modify things while scanning.
Bootstrapped and tested on x86_64-linux, and reportedly fixes the
problem on ppc, ok?
Bernd
PR
