Re: [committed] Add fpic requirement to tests that use PIC options

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Fri, 16 Mar 2007, Richard Sandiford wrote:
> Argh, yes indeed.  I was supposedly trying to make sure that when the
> default options were non-PIC, I'd patched the offending PIC dg-options
> instead (as in 981006.c), but I fluffed it in this case.  Fixed with
> the patch below, thanks.

I saw no patch "below", but in SVN was the obvious change save
for it being non-obvious that "{ ... } && ilp32 && fpic" is
invalid syntax and must be expressed as "{ ... } && { ilp32 && fpic }"
(right?)

> > I guess you
> > missed that that you don't have to use
> > dg-require-effective-target, right?
>
> No, I didn't miss it: it was actually a deliberate decision.

Alas, my guess was wrong. ;)

> As you can
> see from the example you quote, dg-effective-target is already used for
> other such things,

I'm not sure much can be deduced from earlier changes to the
test-suite; there's too high a uninformedness-factor and
carpet-change-factor to tell what are conscious changes and what
just "works". :)

> and I personally find:
>
> /* { dg-do run { target { { i?86-*-* x86_64-*-* } && { ilp32 && fpic } } } } */
>
> much less easy to parse at first glance than:
>
> /* { dg-do run { target i?86-*-* x86_64-*-* } } */
> /* { dg-require-effective-target ilp32 } */
> /* { dg-require-effective-target fpic } */

I can certainly agree there's a readability-threshold for the
complexity, though not a generic this-better-than-that argument.

> I didn't think it was an edict
> that everything should now use target selectors.

Definitely not!  But it's not unusual for people to totally miss
the finer details of the very nice target-selection machinery,
so I thought a hint was in place and your patch looked like a
carpet-change.  My bad. :)

brgds, H-P