Re: [PATCH 10/12] always define EH_RETURN_HANDLER_RTX

[Trevor Saunders <tbsaunde at tbsaunde dot org>]

On Mon, Nov 09, 2015 at 03:07:21PM -0700, Jeff Law wrote:
> On 11/09/2015 02:30 PM, Trevor Saunders wrote:
> >
> >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.
> I'm finding config-list.mk fairly reliable, with the notable exception of
> the avr-rtems issue and interix.  But that may simply be function of running
> it regularly.

yeah, its reliable although I tend to find needing to have an installed
trunk compiler a little painful.  What I meant was that sometimes I've
made mistakes and introduced testsuite failures or the like.

> >
> >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.
> I usually save my results and only go back for a control build if something
> goes wrong.  Of course I'm usually stepping forward at least once a day, so
> the number of new tests is usually manageable and allows me to compare the
> first run of the day with the last run of the prior day.

SO my usual mode is to build up a branch just checking that a default
build works, and then at the end run a script that regtests all the
patches.  That can suffer from intermitant tests, but its low human
input so I like it.

>   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.
> FWIW, If we know what ports a particular patch would hit, I'd fully support
> folks doing builds that didn't hit all of config-list.mk.

sure

> In case it's not obvious I do hope that we'll get to a point where the class
> of bugs like "X is unused on port PDQ because it defines/does not define
> FROBIT" just go away and we can get good first level coverage with a native
> and perhaps a very small number of crosses (instead of the 200+ in
> config-list.mk now).
> 
> At some point I also want to see config-list.mk extended to do things like
> "build the crosses and run test tree-ssa/ssa-dom-thread-11.c on all of
> them".  I've got hacks to do that locally, but they're strictly hacks.  I
> think this selectively deeper testing will become more important as we put
> the first level coverage behind us.

yeah, I'd actually like to see config-list.mk become part of the "real"
build system at some point and you could do something like ./configure
--target=i686-linux-gnu,ppc64-linux-gnu,alpha-dec-vms and stuff.

> >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.
> That generally works for me.
> 
> >
> >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.
> I think Bernd and I just have different approaches, preferences and
> priorities on some stuff which results in slightly different priorities or
> approaches to certain issues.

Sure, we're all different ;)

> I've known Bernd a long time and will say he's very reasonable and his
> concerns/objections are well thought out and carry a ton of weight with me.

I don't really know him, but I don't really disagree with where he wants
to get to.  However I think we work fairly different ways, and review
things differently.  When I review patches (mostly for stuff more
directly related to Mozilla my standards are basically it needs to be an
improvement, and it needs to not introduce bugs.  So I find the it might
improve things, but it doesn't  also accomplish X to berather odd, and
hard to work with if I think getting directly to X might be hard.

Trev

> 
> Jeff