Remove restriction for remote testing

Hi,

The attached patch fixes a problem when doing remote testing.
Specifically, testing of the atomic tests found in gcc/atomic.
The code in atomic_init precludes the setting of the variable
'link_flags' when doing remote testing. The conditional test
can be safely removed as get_multilibs will return "", and
atomic_link_flags will return the necessary '-latomic' that
will allow the atomic tests to successfully link.

OK for trunk?

Thanks,
Jim

On 09/28/2015 02:35 PM, James Norris wrote:
> The attached patch fixes a problem when doing remote testing.
> Specifically, testing of the atomic tests found in gcc/atomic.
> The code in atomic_init precludes the setting of the variable
> 'link_flags' when doing remote testing. The conditional test
> can be safely removed as get_multilibs will return "", and
> atomic_link_flags will return the necessary '-latomic' that
> will allow the atomic tests to successfully link.

I guess remote host is sufficiently exotic that no one has noticed until 
now?

It looks like this pattern occurs across many .exp files, at least:
   asan-dg.exp
   cilk-plus-dg.exp
   mpx-dg.exp
   tsan-dg.exp
   ubsan-dg.exp
We should check that these don't need fixing (did you only see 
unexpected atomic failures?) It looks like they may be ok; for example 
-mmpx seems to imply -lmpx at the specs level.

I'm slightly worried about whether the code in atomic_link_flags will 
reliably find the right -L options and LD_LIBRARY_PATH on all possible 
setups. It looks like it's searching for things on the build machine, 
and I expect you have a setup where the host has the build directory 
mounted in the same location.

Maybe it's better to just append "-latomic" unconditionally, and remove 
it from atomic_link_flags, so that the latter function only sets up 
LD_LIBRARY_PATH etc. That would make atomic-dg closer in behaviour to 
e.g. mpx-dg. Mike, any thoughts?


Bernd

Ping.

On 09/28/2015 07:35 AM, James Norris wrote:
> Hi,
>
> The attached patch fixes a problem when doing remote testing.
> Specifically, testing of the atomic tests found in gcc/atomic.
> The code in atomic_init precludes the setting of the variable
> 'link_flags' when doing remote testing. The conditional test
> can be safely removed as get_multilibs will return "", and
> atomic_link_flags will return the necessary '-latomic' that
> will allow the atomic tests to successfully link.
>
> OK for trunk?
>
> Thanks,
> Jim

On 10/05/2015 02:00 PM, James Norris wrote:
> Ping.

As I said previously, I think appending "-latomic" unconditionally in 
atomic_init is probably a better solution because I'm not convinced that 
the things atomic_link_flags does are appropriate in a remote host 
situation.


Bernd

On Sep 28, 2015, at 5:35 AM, James Norris <jnorris@codesourcery.com> wrote:
> The attached patch fixes a problem when doing remote testing.
> Specifically, testing of the atomic tests found in gcc/atomic.
> The code in atomic_init precludes the setting of the variable
> 'link_flags' when doing remote testing. The conditional test
> can be safely removed as get_multilibs will return "", and
> atomic_link_flags will return the necessary '-latomic' that
> will allow the atomic tests to successfully link.
> 
> OK for trunk?

I don't think this is appropriate.  The design is for remote host testing to have the compete shape of an installed compiler as I recall.  When it does, it then is indistinguishable from an installed compiler, and when it is installed, then no -L nor -B flag is necessary for it to work.  The link_flags only exists to add these flags, not the -l flag.  That is the thing that is wrong.  Remove that, and add

 "libs=-latomic”

to someplace that will inject that option.  I stole that line from objc.exp:

  append options "libs=-lobjc”

or otherwise unconditionally put -latomic on the link line (some place that isn’t protected by is_remote host).

On Mon, 5 Oct 2015, Mike Stump wrote:

> or otherwise unconditionally put -latomic on the link line (some place 
> that isn’t protected by is_remote host).

Remembering of course that it needs to be done in a way that doesn't leave 
it there for other .exp files executed after atomic.exp.