Re: [PATCH 10/12] always define EH_RETURN_HANDLER_RTX

[Trevor Saunders <tbsaunde at tbsaunde dot org>]

On Mon, Nov 09, 2015 at 12:46:33PM -0700, Jeff Law wrote:
> On 11/09/2015 12:38 PM, Bernd Schmidt wrote:
> >On 11/09/2015 07:52 PM, Trevor Saunders wrote:
> >
> >>yeah, that's more or less my thought, and this makes hookization easier
> >>since you can now mechanically add a hook for each thing in defaults.h
> >>that invokes the macro.  Then for each target you can go through and
> >>replace the macro with an override of the hooks.  That ends up with the
> >>macros replaced by hooks without writing a lot of patches that need to
> >>go through config-list.mk, and testing on multiple targets which imho is
> >>a giant pain, and rather slow.
> >
> >We might want to think about making a policy decision to try waiving
> >some of the testing requirements for target macro -> hook conversions.
> >Maybe try only a "build to cc1" requirement and see whether that causes
> >too much breakage.
> A config-list.mk build is a build to cc1*, f951, gnat1, so we're not
> requiring deep tests on the affected targets.  Not sure how much we're
> getting by forcing a bootstrap & regression test of that kind of change.

So in general when I've done cross target things I think I've found more
bugs with config-list.mk than with a regtest, but the regtest has found
some things I think.

However I actually don't mind bootstrapping and regtesting that much,
its more or less a few hours for the control and then another few for
each patch.  On the other hand config-list.mk takes on the order of 12
hours, and setting up a cross for a quick test isn't really that quick.
Which means that if you have a patch touching a number of targets you
end up not checking it compiles at all until you run config-list.mk, and
then its a heavy weight operation.

So at least for the way I work I'd really rather write series that I can
incrementally test on just one target and be reasonably confident they
won't break other targets.

The add default macro definitions then wrap those with hooks, then
target by target replace the macro by hook overrides approach seems to
provide that you can incrementally test and fiind most of the issues,
but the change a macro every where approach doesn't really.

Trev

The add default macros then use those in hooks, and finally add overides
> 
> I'm certainly open to this kind of relaxed testing to help this stuff move
> forward an complete before we're all retired :-)
> 
> Jeff
>