> The issue is that using the plugin interface makes breakage only
> detectable when you are able to test a target, not by merely
> building it.
You just described *most* of the bugs I have to deal with.
On Wed, Aug 8, 2012 at 5:29 PM, Richard Henderson wrote:
> On 08/08/2012 07:19 AM, Ian Lance Taylor wrote:
>>> > I was suggesting to for example register a 2nd mdreorg-like pass and
>>> > add a 2nd target hook. regstack should get the same treatment.
>> If the mechanism is a proliferation of mdre
> But we should definitely have a way to register machine dependent
> passes, and what's wrong with the plugin interface?
IIRC I asked about how to schedule that pass when I wrote it, and "use
the plugin API" was the recommendation.
Some background...
The RL78 devirtualization pass is *not* a r
On 08/08/2012 07:19 AM, Ian Lance Taylor wrote:
>> > I was suggesting to for example register a 2nd mdreorg-like pass and
>> > add a 2nd target hook. regstack should get the same treatment.
> If the mechanism is a proliferation of mdreorg passes in every place
> we want a target-specific pass, tha
On Wed, Aug 8, 2012 at 7:11 AM, Richard Guenther
wrote:
> On Wed, Aug 8, 2012 at 4:06 PM, Ian Lance Taylor wrote:
>> On Wed, Aug 8, 2012 at 7:03 AM, Richard Guenther
>> wrote:
>>
>>> I don't think we really want that (machine dependent passes). It seems
>>> we cannot get away with it (so we hav
On Wed, Aug 8, 2012 at 4:06 PM, Ian Lance Taylor wrote:
> On Wed, Aug 8, 2012 at 7:03 AM, Richard Guenther
> wrote:
>
>> I don't think we really want that (machine dependent passes). It seems
>> we cannot get away with it (so we have mdreorg). Allowing (some) flexibility
>> where to put mdreorg
On Wed, Aug 8, 2012 at 7:03 AM, Richard Guenther
wrote:
> I don't think we really want that (machine dependent passes). It seems
> we cannot get away with it (so we have mdreorg). Allowing (some) flexibility
> where to put mdreorg is ok, using two different mechanisms (mdreorg and
> a "plugin")
On Wed, Aug 8, 2012 at 3:35 PM, Ian Lance Taylor wrote:
> On Wed, Aug 8, 2012 at 1:45 AM, Richard Guenther
> wrote:
>> On Wed, Aug 8, 2012 at 10:28 AM, Nick Clifton wrote:
>>> Hi DJ,
>>>
>>> I am applying the following patch to the gcc mainline as an obvious
>>> fix for the following problem
On Wed, Aug 8, 2012 at 1:45 AM, Richard Guenther
wrote:
> On Wed, Aug 8, 2012 at 10:28 AM, Nick Clifton wrote:
>> Hi DJ,
>>
>> I am applying the following patch to the gcc mainline as an obvious
>> fix for the following problem building the RL78 backend:
>>
>> gcc/config/rl78/rl78.c:151:3
On Wed, Aug 8, 2012 at 11:02 AM, nick clifton wrote:
> Hi Richard,
>
>
>> Err - you are inside the compiler and should not use plugin stuff to
>> register your machine dependent pass.
>
>
> Umm, OK, what is the correct method for registering target specific passes ?
> (Ones that need to run at tim
Hi Richard,
Err - you are inside the compiler and should not use plugin stuff to
register your machine dependent pass.
Umm, OK, what is the correct method for registering target specific
passes ? (Ones that need to run at times other than
TARGET_MACHINE_DEPENDENT_REORG).
Cheers
Nick
On Wed, Aug 8, 2012 at 10:28 AM, Nick Clifton wrote:
> Hi DJ,
>
> I am applying the following patch to the gcc mainline as an obvious
> fix for the following problem building the RL78 backend:
>
> gcc/config/rl78/rl78.c:151:3: error: 'PASS_POS_INSERT_BEFORE' undeclared
> here (not in a fu
Hi DJ,
I am applying the following patch to the gcc mainline as an obvious
fix for the following problem building the RL78 backend:
gcc/config/rl78/rl78.c:151:3: error: 'PASS_POS_INSERT_BEFORE' undeclared
here (not in a function)
Cheers
Nick
gcc/ChangeLog
2012-08-08 Nick Clifton
13 matches
Mail list logo
