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 test
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 seem
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 scann
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 x86_64-l
