On 02/23/2017 02:52 AM, Alan Modra wrote:
On Thu, Feb 23, 2017 at 12:46:17AM -0700, Jeff Law wrote:
And thus we keep the equivalence. Ultimately may_trap_p considers a PIC
memory reference as non-trapping.
Which is obviously a bug, because this access is segfaulting..
Not that I want to poke
On Thu, Feb 23, 2017 at 12:46:17AM -0700, Jeff Law wrote:
> And thus we keep the equivalence. Ultimately may_trap_p considers a PIC
> memory reference as non-trapping.
Which is obviously a bug, because this access is segfaulting..
Not that I want to poke at the bug. :)
> I really wonder if we s
On 02/22/2017 09:32 AM, Dominique d'Humières wrote:
Let me stand up an i686 linux instance and see if I can twiddle things without
compromising the test.
Also darwin is a -fpic platform.
Which is the key here :-) The test works fine without PIC, but once PIC
is introduced, it blows up.
It'
> Le 22 févr. 2017 à 17:06, Jeff Law a écrit :
>
> On 02/22/2017 04:32 AM, Dominique d'Humières wrote:
>>
>>> Le 21 févr. 2017 à 23:48, Alan Modra a écrit :
>>>
>>> On Sat, Feb 18, 2017 at 12:39:08PM +0100, Dominique d'Humières wrote:
> I'm slightly concerned about the test and how it'll
On 02/22/2017 04:32 AM, Dominique d'Humières wrote:
Le 21 févr. 2017 à 23:48, Alan Modra a écrit :
On Sat, Feb 18, 2017 at 12:39:08PM +0100, Dominique d'Humières wrote:
I'm slightly concerned about the test and how it'll behave on targets with
small address spaces. If it's a problem we can
> Le 21 févr. 2017 à 23:48, Alan Modra a écrit :
>
> On Sat, Feb 18, 2017 at 12:39:08PM +0100, Dominique d'Humières wrote:
>>> I'm slightly concerned about the test and how it'll behave on targets with
>>> small address spaces. If it's a problem we can fault in adjustments.
>>
>> The test fail
On Sat, Feb 18, 2017 at 12:39:08PM +0100, Dominique d'Humières wrote:
> > I'm slightly concerned about the test and how it'll behave on targets with
> > small address spaces. If it's a problem we can fault in adjustments.
>
> The test fails on x86_64-apple-darwin16 with -m32 and -O1 and above.
H
> I'm slightly concerned about the test and how it'll behave on targets with
> small address spaces. If it's a problem we can fault in adjustments.
The test fails on x86_64-apple-darwin16 with -m32 and -O1 and above.
TIA
Dominique
On 02/10/2017 05:29 PM, Alan Modra wrote:
On Fri, Feb 03, 2017 at 01:55:33AM -0700, Jeff Law wrote:
That seems pretty pessimistic -- do we have dominance information at this
point? If so we could check that the assignment to the register dominates
the use. If they are in the same block, then
On Fri, Feb 03, 2017 at 01:55:33AM -0700, Jeff Law wrote:
> That seems pretty pessimistic -- do we have dominance information at this
> point? If so we could check that the assignment to the register dominates
> the use. If they are in the same block, then you have to look at LUIDs or
> somesuch
On 02/02/2017 02:31 AM, Alan Modra wrote:
Revised patch that cures the lra related -m32 -Os regression too.
The code that I'm patching here is changing a REG_EQUAL note to
REG_EQUIV, ie. asserting that the value of the reg is always the value
set by the current instruction. Which is not always
On 02/02/2017 02:31 AM, Alan Modra wrote:
Revised patch that cures the lra related -m32 -Os regression too.
The code that I'm patching here is changing a REG_EQUAL note to
REG_EQUIV, ie. asserting that the value of the reg is always the value
set by the current instruction. Which is not always
Revised patch that cures the lra related -m32 -Os regression too.
The code that I'm patching here is changing a REG_EQUAL note to
REG_EQUIV, ie. asserting that the value of the reg is always the value
set by the current instruction. Which is not always true when the
insn is in a loop and the use
On Thu, Feb 02, 2017 at 12:18:31AM +1030, Alan Modra wrote:
> This patch cures PR79286 by restoring the REG_DEAD note test used
> prior to r235660, but modified to only exclude insns that may trap.
> I'd like to allow combine/move without a REG_DEAD note in loops
> because insns in loops often lack
This patch cures PR79286 by restoring the REG_DEAD note test used
prior to r235660, but modified to only exclude insns that may trap.
I'd like to allow combine/move without a REG_DEAD note in loops
because insns in loops often lack such notes, and I recall seeing
quite a few cases at the time I wro
15 matches
Mail list logo
