Re: g++ -Wl,--as-needed -pthread behaviour
On Tue, Sep 24, 2013 at 01:13:53PM +0100, Jonathan Wakely wrote: > On 24 September 2013 02:22, Alan Modra wrote: > > > > Try compiling that testcase with -static rather than -Wl,--as-needed. > > You'll hit std::system_error just like you do here. I believe that is > > a libstdc++ bug, and can be solved by making libstdc++.a use strong > > references to pthread symbols from std::thread::join() (and perhaps > > other objects that provide c++ thread support, if there are such). > > It's the std::thread constructor template that needs pthread_create. > std::thread::join() needs pthread_join. Ah, OK, I commented without looking at the source first, and it shows. :) > > Otherwise we'd need to solve the transitive reference somehow. > > ie. Teach the linker that a reference to std::thread::join() means > > that pthread_create is required. One obvious way to do that is have > > the compiler reference pthread_create in objects that use > > std::thread::join(). > > How would we have the compiler do that? The std::thread constructor needs to emit a strong reference to pthread_create in the user object file. Probably the best way to do that is as Jakub said, inline it and modify __gthread_create to only use weak references to pthread symbols when compiling for a shared library. (When I wrote the above comment I was thing more along the lines of a dummy reference via a pointer variable initialised to pthread_create, but inlining the lot is simpler.) -- Alan Modra Australia Development Lab, IBM
Re: Question about clobbering registers in prologue/epilogue code
Steve Ellcey writes: > On Fri, 2013-09-20 at 07:39 +0100, Richard Sandiford wrote: >> Well, it's really backend code that works out what registers need >> to be saved and restored, although it's based on generic information. >> So it should just be a case of making mips_save_reg_p return true for >> all FP registers in an fp64_compat function. The prologue would then >> need to restore any incoming float arguments after the mode switch. >> >> Thanks, >> Richard > > Thanks for the ideas Richard, I have played around with this some more > and one of the things I am having trouble with is trying to determine if > any floating point registers were used for arguments. I could just save > and restore $f12 and $f14 every time, but ideally I would only want to > do that if they were actually used for arguments. I can't seem to > figure out how to determine that. It looks like I can determine if $f0 > is used for a return value by using mips_return_mode_in_fpr_p but I > can't find something equivalent for argument registers. Any ideas? The live-in set for the entry block says which float registers contain arguments, but that probably isn't enough, since you need to cope with double arguments that are passed in a register pair but are presumably used as a single register. So you probably need to iterate over the arguments of the current function using the cumulative_args functions. It looks like the microblaze prologue does something similar. Thanks, Richard
Re: Question about clobbering registers in prologue/epilogue code
On Fri, 2013-09-20 at 07:39 +0100, Richard Sandiford wrote: > Well, it's really backend code that works out what registers need > to be saved and restored, although it's based on generic information. > So it should just be a case of making mips_save_reg_p return true for > all FP registers in an fp64_compat function. The prologue would then > need to restore any incoming float arguments after the mode switch. > > Thanks, > Richard Thanks for the ideas Richard, I have played around with this some more and one of the things I am having trouble with is trying to determine if any floating point registers were used for arguments. I could just save and restore $f12 and $f14 every time, but ideally I would only want to do that if they were actually used for arguments. I can't seem to figure out how to determine that. It looks like I can determine if $f0 is used for a return value by using mips_return_mode_in_fpr_p but I can't find something equivalent for argument registers. Any ideas? Steve Ellcey sell...@mips.com
Re: GNU Toolchain on Google+ and Twitter
On Tue, Sep 24, 2013 at 10:38 AM, Diego Novillo wrote: > On Tue, Sep 24, 2013 at 11:33 AM, David Edelsohn wrote: >> I have established Google+ and Twitter pages for the GNU Toolchain >> (GCC, Binutils, GDB) as additional, un-official communication channels >> for announcements and highlights of interesting mailing list >> discussions. > > Thanks David. Definitely useful. I totally agree. Thanks David for doing this. I have been so behind on reading emails from the list the last few weeks (due to a few different reasons) and this definitely has been useful. -- Andrew > > > Diego.
Re: GNU Toolchain on Google+ and Twitter
On Tue, Sep 24, 2013 at 11:33 AM, David Edelsohn wrote: > I have established Google+ and Twitter pages for the GNU Toolchain > (GCC, Binutils, GDB) as additional, un-official communication channels > for announcements and highlights of interesting mailing list > discussions. Thanks David. Definitely useful. Diego.
Re: GNU Toolchain on Google+ and Twitter
On Tue, Sep 24, 2013 at 11:54 AM, Joseph S. Myers wrote: > On Tue, 24 Sep 2013, David Edelsohn wrote: > >> I have established Google+ and Twitter pages for the GNU Toolchain >> (GCC, Binutils, GDB) as additional, un-official communication channels > > What about covering glibc there as well? I will add coverage of GLIBC as well. Assistance with topics to highlight is appreciated. Thanks, David
Re: [RFC] Vectorization of indexed elements
On Mon, Sep 09, 2013 at 07:02:52PM +0100, Marc Glisse wrote:
> On Mon, 9 Sep 2013, Vidya Praveen wrote:
>
> > Hello,
> >
> > This post details some thoughts on an enhancement to the vectorizer that
> > could take advantage of the SIMD instructions that allows indexed element
> > as an operand thus reducing the need for duplication and possibly improve
> > reuse of previously loaded data.
> >
> > Appreciate your opinion on this.
> >
> > ---
> >
> > A phrase like this:
> >
> > for(i=0;i<4;i++)
> > a[i] = b[i] c[2];
> >
> > is usually vectorized as:
> >
> > va:V4SI = a[0:3]
> > vb:V4SI = b[0:3]
> > t = c[2]
> > vc:V4SI = { t, t, t, t } // typically expanded as vec_duplicate at vec_init
> > ...
> > va:V4SI = vb:V4SI vc:V4SI
> >
> > But this could be simplified further if a target has instructions that
> > support
> > indexed element as a parameter. For example an instruction like this:
> >
> > mul v0.4s, v1.4s, v2.4s[2]
> >
> > can perform multiplication of each element of v2.4s with the third element
> > of
> > v2.4s (specified as v2.4s[2]) and store the results in the corresponding
> > elements of v0.4s.
> >
> > For this to happen, vectorizer needs to understand this idiom and treat the
> > operand c[2] specially (and by taking in to consideration if the machine
> > supports indexed element as an operand for through a target hook or
> > macro)
> > and consider this as vectorizable statement without having to duplicate the
> > elements explicitly.
> >
> > There are fews ways this could be represented at gimple:
> >
> > ...
> > va:V4SI = vb:V4SI VEC_DUPLICATE_EXPR (VEC_SELECT_EXPR (vc:V4SI 2))
> > ...
> >
> > or by allowing a vectorizer treat an indexed element as a valid operand in a
> > vectorizable statement:
>
> Might as well allow any scalar then...
Yes, I had given an example below.
>
> > ...
> > va:V4SI = vb:V4SI VEC_SELECT_EXPR (vc:V4SI 2)
> > ...
> >
> > For the sake of explanation, the above two representations assumes that
> > c[0:3] is loaded in vc for some other use and reused here. But when c[2] is
> > the
> > only use of 'c' then it may be safer to just load one element and use it
> > like
> > this:
> >
> > vc:V4SI[0] = c[2]
> > va:V4SI = vb:V4SI VEC_SELECT_EXPR (vc:V4SI 0)
> >
> > This could also mean that expressions involving scalar could be treated
> > similarly. For example,
> >
> > for(i=0;i<4;i++)
> >a[i] = b[i] c
> >
> > could be vectorized as:
> >
> > vc:V4SI[0] = c
> > va:V4SI = vb:V4SI VEC_SELECT_EXPR (vc:V4SI 0)
> >
> > Such a change would also require new standard pattern names to be defined
> > for
> > each .
> >
> > Alternatively, having something like this:
> >
> > ...
> > vt:V4SI = VEC_DUPLICATE_EXPR (VEC_SELECT_EXPR (vc:V4SI 2))
> > va:V4SI = vb:V4SI vt:V4SI
> > ...
> >
> > would remove the need to introduce several new standard pattern names but
> > have
> > just one to represent vec_duplicate(vec_select()) but ofcourse this will
> > expect
> > the target to have combiner patterns.
>
> The cost estimation wouldn't be very good, but aren't combine patterns
> enough for the whole thing? Don't you model your mul instruction as:
>
> (mult:V4SI
>(match_operand:V4SI)
>(vec_duplicate:V4SI (vec_select:SI (match_operand:V4SI
>
> anyway? Seems that combine should be able to handle it. What currently
> happens that we fail to generate the right instruction?
At vec_init, I can recognize an idiom in order to generate vec_duplicate but
I can't really insist on the single lane load.. something like:
vc:V4SI[0] = c
vt:V4SI = vec_duplicate:V4SI (vec_select:SI vc:V4SI 0)
va:V4SI = vb:V4SI vt:V4SI
Or is there any other way to do this?
Cheers
VP
>
> In gimple, we already have BIT_FIELD_REF for vec_select and CONSTRUCTOR
> for vec_duplicate, adding new nodes is always painful.
>
> > This enhancement could possibly help further optimizing larger scenarios
> > such
> > as linear systems.
> >
> > Regards
> > VP
>
> --
> Marc Glisse
>
Re: GNU Toolchain on Google+ and Twitter
On Tue, 24 Sep 2013, David Edelsohn wrote: > I have established Google+ and Twitter pages for the GNU Toolchain > (GCC, Binutils, GDB) as additional, un-official communication channels What about covering glibc there as well? -- Joseph S. Myers jos...@codesourcery.com
Re: GNU Toolchain on Google+ and Twitter
On Tue, Sep 24, 2013 at 11:33:31AM -0400, David Edelsohn wrote: > I have established Google+ and Twitter pages for the GNU Toolchain > (GCC, Binutils, GDB) as additional, un-official communication channels > for announcements and highlights of interesting mailing list > discussions. > > https://plus.google.com/108467477471815191158 > > https://twitter.com/gnutools > > Anyone interested is welcome to follow. I'm finding the twitter account to be really useful and the number of followers is steadily increasing -- so thanks for doing that. It's a good thing to have. Marek
GNU Toolchain on Google+ and Twitter
I have established Google+ and Twitter pages for the GNU Toolchain (GCC, Binutils, GDB) as additional, un-official communication channels for announcements and highlights of interesting mailing list discussions. https://plus.google.com/108467477471815191158 https://twitter.com/gnutools Anyone interested is welcome to follow. - David P.S. If you are concerned that these social networks and pages interfere with your freedom, you can ignore them.
Re: [RFC] Vectorization of indexed elements
On Tue, Sep 10, 2013 at 09:25:32AM +0100, Richard Biener wrote:
> On Mon, 9 Sep 2013, Marc Glisse wrote:
>
> > On Mon, 9 Sep 2013, Vidya Praveen wrote:
> >
> > > Hello,
> > >
> > > This post details some thoughts on an enhancement to the vectorizer that
> > > could take advantage of the SIMD instructions that allows indexed element
> > > as an operand thus reducing the need for duplication and possibly improve
> > > reuse of previously loaded data.
> > >
> > > Appreciate your opinion on this.
> > >
> > > ---
> > >
> > > A phrase like this:
> > >
> > > for(i=0;i<4;i++)
> > > a[i] = b[i] c[2];
> > >
> > > is usually vectorized as:
> > >
> > > va:V4SI = a[0:3]
> > > vb:V4SI = b[0:3]
> > > t = c[2]
> > > vc:V4SI = { t, t, t, t } // typically expanded as vec_duplicate at
> > > vec_init
> > > ...
> > > va:V4SI = vb:V4SI vc:V4SI
> > >
> > > But this could be simplified further if a target has instructions that
> > > support
> > > indexed element as a parameter. For example an instruction like this:
> > >
> > > mul v0.4s, v1.4s, v2.4s[2]
> > >
> > > can perform multiplication of each element of v2.4s with the third element
> > > of
> > > v2.4s (specified as v2.4s[2]) and store the results in the corresponding
> > > elements of v0.4s.
> > >
> > > For this to happen, vectorizer needs to understand this idiom and treat
> > > the
> > > operand c[2] specially (and by taking in to consideration if the machine
> > > supports indexed element as an operand for through a target hook or
> > > macro)
> > > and consider this as vectorizable statement without having to duplicate
> > > the
> > > elements explicitly.
> > >
> > > There are fews ways this could be represented at gimple:
> > >
> > > ...
> > > va:V4SI = vb:V4SI VEC_DUPLICATE_EXPR (VEC_SELECT_EXPR (vc:V4SI 2))
> > > ...
> > >
> > > or by allowing a vectorizer treat an indexed element as a valid operand
> > > in a
> > > vectorizable statement:
> >
> > Might as well allow any scalar then...
>
> I agree. The VEC_DUPLICATE_EXPR (VEC_SELECT_EXPR (vc:V4SI 2)) form
> would necessarily be two extra separate statements and thus subject
> to CSE obfuscating it enough for RTL expansion to no longer notice it.
I also thought about having a specialized expression like
VEC_INDEXED__EXPR < arg0, arg1, arg2, index>
to mean:
arg0 = arg1 arg2[index]
and handle it directly in the expander, like (for eg.) how VEC_LSHIFT_EXPR
is handled in expr.c. But I dropped this idea since we may need to introduce
many such nodes.
>
> That said, allowing mixed scalar/vector ops isn't very nice and
> your scheme can be simplified by just using
>
> vc:V4SI = VEC_DUPLICATE_EXPR <...>
> va:V4SI = vb:V4SI vc:V4SI
>
> where the expander only has to see that vc:V4SI is defined by
> a duplicate.
I did try out something like this quickly before I posted this RFC, though
I called it VEC_DUP to mean a equivalent of vec_duplicate(vec_select())
for:
for(i=0;i<8;i++)
a[i] = b[2] * c[i];
I could generate:
...
:
_88 = prolog_loop_adjusted_niters.6_60 * 4;
vectp_c.13_87 = c_10(D) + _88;
vect_ldidx_.16_92 = MEM[(int *)b_8(D) + 8B];
vect_idxed_.17_93 = (vect_ldidx_.16_92) <<< ??? >>> (0);
_96 = prolog_loop_adjusted_niters.6_60 * 4;
vectp_a.19_95 = a_6(D) + _96;
vect__12.14_115 = MEM[(int *)vectp_c.13_87];
vect_patt_40.15_116 = vect__12.14_115 * vect_idxed_.17_93;
MEM[(int *)vectp_a.19_95] = vect_patt_40.15_116;
vectp_c.12_118 = vectp_c.13_87 + 16;
vectp_a.18_119 = vectp_a.19_95 + 16;
ivtmp_120 = 1;
if (ivtmp_120 < bnd.8_62)
goto ;
else
goto ;
:
# vectp_c.12_89 = PHI
# vectp_a.18_97 = PHI
# ivtmp_14 = PHI
vect__12.14_91 = MEM[(int *)vectp_c.12_89];
vect_patt_40.15_94 = vect__12.14_91 * vect_idxed_.17_93;
MEM[(int *)vectp_a.18_97] = vect_patt_40.15_94;
...
It's a crude implementation so VEC_DUP is printed as:
(vect_ldidx_.16_92) <<< ??? >>> (0);
> > > ...
> > > va:V4SI = vb:V4SI VEC_SELECT_EXPR (vc:V4SI 2)
> > > ...
> > >
> > > For the sake of explanation, the above two representations assumes that
> > > c[0:3] is loaded in vc for some other use and reused here. But when c[2]
> > > is
> > > the
> > > only use of 'c' then it may be safer to just load one element and use it
> > > like
> > > this:
> > >
> > > vc:V4SI[0] = c[2]
> > > va:V4SI = vb:V4SI VEC_SELECT_EXPR (vc:V4SI 0)
> > >
> > > This could also mean that expressions involving scalar could be treated
> > > similarly. For example,
> > >
> > > for(i=0;i<4;i++)
> > >a[i] = b[i] c
> > >
> > > could be vectorized as:
> > >
> > > vc:V4SI[0] = c
> > > va:V4SI = vb:V4SI VEC_SELECT_EXPR (vc:V4SI 0)
> > >
> > > Such a change would also require new standard pattern names to be defined
> > > for
> > > each .
> > >
> > > Alternatively, having something like this:
> > >
> > > ...
> > > vt:V4S
Re: g++ -Wl,--as-needed -pthread behaviour
On 24 September 2013 13:45, Jakub Jelinek wrote: > On Tue, Sep 24, 2013 at 01:34:52PM +0100, Jonathan Wakely wrote: >> On 24 September 2013 13:24, Jakub Jelinek wrote: >> > On Tue, Sep 24, 2013 at 01:13:53PM +0100, Jonathan Wakely wrote: >> >> It's the std::thread constructor template that needs pthread_create. >> >> std::thread::join() needs pthread_join. >> > >> > Are any references to that needed in libstdc++.so.6, or just in headers? >> >> It's called from libstdc++-v3/src/c++11/thread.cc which ends up in >> libstdc++.so.6 > > Ah, then it has to use __gthread_create. > >> > Having libstdc++.so.6 depend on libpthread.so is not a good idea, the >> > latter might be possible by just referencing pthread_* instead of >> > __gthread_* where you actually require it. >> >> For targets that don't use gthr-posix.h __gthread_create is not a >> wrapper for pthread_create. > > Grep tells me that other gthr* headers don't define __gthread_create at all. Yet :-) I have tried to implement the full C++11 thread facilities on Windows, but gave up because mingw was such a PITA to build, let alone test. I decided I'd rather smash my teeth out with a hammer than continue wasting time on such an annoying target, but someone more patient might want to make it work one day. > Anyway, either we just declare that people who use --as-needed without > thinking about the consequences get what they deserve, or you'd need to > keep the current std::thread::_M_start_thread as is in libstdc++.so.6, but > in newer headers inline it, perhaps under a different name (using > pthread_create > rather than the wrapper). Yes, that would be an option. > I guess for other routines it isn't really needed, thread::join if > nobody started a thread doesn't look like a good idea, similarly detach. Agreed.
Re: g++ -Wl,--as-needed -pthread behaviour
On Tue, Sep 24, 2013 at 01:34:52PM +0100, Jonathan Wakely wrote: > On 24 September 2013 13:24, Jakub Jelinek wrote: > > On Tue, Sep 24, 2013 at 01:13:53PM +0100, Jonathan Wakely wrote: > >> It's the std::thread constructor template that needs pthread_create. > >> std::thread::join() needs pthread_join. > > > > Are any references to that needed in libstdc++.so.6, or just in headers? > > It's called from libstdc++-v3/src/c++11/thread.cc which ends up in > libstdc++.so.6 Ah, then it has to use __gthread_create. > > Having libstdc++.so.6 depend on libpthread.so is not a good idea, the > > latter might be possible by just referencing pthread_* instead of > > __gthread_* where you actually require it. > > For targets that don't use gthr-posix.h __gthread_create is not a > wrapper for pthread_create. Grep tells me that other gthr* headers don't define __gthread_create at all. Anyway, either we just declare that people who use --as-needed without thinking about the consequences get what they deserve, or you'd need to keep the current std::thread::_M_start_thread as is in libstdc++.so.6, but in newer headers inline it, perhaps under a different name (using pthread_create rather than the wrapper). I guess for other routines it isn't really needed, thread::join if nobody started a thread doesn't look like a good idea, similarly detach. Jakub
Re: g++ -Wl,--as-needed -pthread behaviour
On 24 September 2013 13:24, Jakub Jelinek wrote:
> On Tue, Sep 24, 2013 at 01:13:53PM +0100, Jonathan Wakely wrote:
>> It's the std::thread constructor template that needs pthread_create.
>> std::thread::join() needs pthread_join.
>
> Are any references to that needed in libstdc++.so.6, or just in headers?
It's called from libstdc++-v3/src/c++11/thread.cc which ends up in
libstdc++.so.6
> Having libstdc++.so.6 depend on libpthread.so is not a good idea, the
> latter might be possible by just referencing pthread_* instead of
> __gthread_* where you actually require it.
For targets that don't use gthr-posix.h __gthread_create is not a
wrapper for pthread_create.
>> It's complicated by the fact that the source code doesn't mention
>> pthread_create, it uses __gthread_create instead, which is the weak
>> reference.
>
> If it requires pthread_{create,join} rather then it should be using
> those rather than the wrappers, those are there just to not require
> libpthread and just fail if it is not linked in.
And also to be platform independent, not all targets use pthreads.
>> It has the huge disadvantage of breaking the ABI by removing symbols
>> from libstdc++.so
>
> That is not possible.
Indeed.
Re: g++ -Wl,--as-needed -pthread behaviour
On Tue, Sep 24, 2013 at 01:13:53PM +0100, Jonathan Wakely wrote:
> > Try compiling that testcase with -static rather than -Wl,--as-needed.
> > You'll hit std::system_error just like you do here. I believe that is
> > a libstdc++ bug, and can be solved by making libstdc++.a use strong
> > references to pthread symbols from std::thread::join() (and perhaps
> > other objects that provide c++ thread support, if there are such).
>
> It's the std::thread constructor template that needs pthread_create.
> std::thread::join() needs pthread_join.
Are any references to that needed in libstdc++.so.6, or just in headers?
Having libstdc++.so.6 depend on libpthread.so is not a good idea, the
latter might be possible by just referencing pthread_* instead of
__gthread_* where you actually require it.
> It's complicated by the fact that the source code doesn't mention
> pthread_create, it uses __gthread_create instead, which is the weak
> reference.
If it requires pthread_{create,join} rather then it should be using
those rather than the wrappers, those are there just to not require
libpthread and just fail if it is not linked in.
> It has the huge disadvantage of breaking the ABI by removing symbols
> from libstdc++.so
That is not possible.
Jakub
Re: g++ -Wl,--as-needed -pthread behaviour
On 24 September 2013 02:22, Alan Modra wrote: > > Try compiling that testcase with -static rather than -Wl,--as-needed. > You'll hit std::system_error just like you do here. I believe that is > a libstdc++ bug, and can be solved by making libstdc++.a use strong > references to pthread symbols from std::thread::join() (and perhaps > other objects that provide c++ thread support, if there are such). It's the std::thread constructor template that needs pthread_create. std::thread::join() needs pthread_join. It's complicated by the fact that the source code doesn't mention pthread_create, it uses __gthread_create instead, which is the weak reference. > libstdc++.a objects that are just testing "is this program threaded" > should continue to use weak references. > > Solving the problem with --as-needed and libstdc++.so isn't so easy. > One solution might be to split off thread support from libstdc++.so.6. Yes, I've suggested that before. It has the additional benefit that users don't need to say -pthread to use C++11 threads (they shouldn't need to care that it uses pthreads under the covers) they could just say something like -lstdc++thr where that lib would depend on libpthread.so. It has the huge disadvantage of breaking the ABI by removing symbols from libstdc++.so > Otherwise we'd need to solve the transitive reference somehow. > ie. Teach the linker that a reference to std::thread::join() means > that pthread_create is required. One obvious way to do that is have > the compiler reference pthread_create in objects that use > std::thread::join(). How would we have the compiler do that?
Re: dejagnu multilib options and dg-{add|additional-}options
On Tue, Aug 27, 2013 at 04:34:09PM +0100, Janis Johnson wrote:
> On 08/27/2013 06:52 AM, Marcus Shawcroft wrote:
> > On 23 July 2013 17:40, Janis Johnson wrote:
> >> On 07/22/2013 02:59 AM, Vidya Praveen wrote:
> >>> Hello,
> >>>
> >>> There are 42 test files (25 under gcc.dg) that specifies
> >>>
> >>> { dg-add-options bind_pic_locally }
> >>>
> >>> in the regression testsuite. The procedure
> >>> add_options_for_bind_pic_locally
> >>> from lib/target-supports.exp adds -fPIE or -fpie when -fPIC or -fpic is
> >>> passed
> >>> respectively. But this is added before the dejagnu multilib options are
> >>> added.
> >>> So when -fPIC is passed as a multilib option, -fPIE will be unset by -fPIC
> >>> (see gcc/common.opt). This should have been the behaviour since the patch
> >>> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01026.html that brings all
> >>> -fPIC
> >>> & -fPIE variants in a Negative loop, was applied.
> >>>
> >>> I tried fixing this in dejagnu/target.exp by adding the multilib options
> >>> before
> >>> the other options:
> >>>
> >>> default_target_compile:
> >>>
> >>> < append add_flags " [board_info $dest multilib_flags]"
> >>> ---
> set add_flags " [board_info $dest multilib_flags] $add_flags"
> >>>
> >>> and ran regressions for x86_64-unknown-linux-gnu before and after the
> >>> change.
> >>> The only difference in the results after the change was 24 new PASSes
> >>> which
> >>> are from the testcases which either use bind_pic_locally or that use
> >>> -fno-pic.
> >>>
> >>> (Interestingly, there are many test files that bind_pic_locally pass
> >>> without
> >>> any issue before and after the change.)
> >>>
> >>> I tend to think that the options added from the test files should always
> >>> win.
> >>> Please correct me if I'm wrong. If I'm right, is dejagnu/target.exp is the
> >>> best place to fix this and the way it tried to fix? Any better
> >>> suggestions?
> >>>
> >>> Though this case is to do with -fPIC, I'm sure there are other options
> >>> which
> >>> when they come as multilib options might have same issue with the some of
> >>> the
> >>> options added by the test files or the default options.
> >>>
> >>> Regards
> >>> VP
> >>
> >> Ideally we would ask for that change in DejaGnu, but relying on such a
> >> change would require everyone testing GCC to upgrade to a version of
> >> DejaGnu with that fix, and I don't think we're ready to do that.
> >>
> >> Tests that add options that might override or conflict with multilib
> >> flags should check for those flags first and skip the test if they are
> >> used. For examples, see tests in gcc.target/arm that use dg-skip-if.
> >
> > Umm, the purpose of bind_pic_locally appears to be to detect the use
> > of -fPIC and override that behavior with -fPIE. If I understand the
> > above paragraph correctly then bind_pic_locally is fundamentally
> > broken and all of the tests that use it need rewriting to skip if
> > -fPIC or -fpic is in use?
> >
> > Cheers
> > /Marcus
> >
>
> That is correct. There should probably be an effective-target check
> bind_pic_locally_ok that fails if adding -fpie or -fPIE doesn't have the
> expected result, and the tests that use "dg-add-options bind_pic_locally"
> should be skipped if bind_pic_locally_ok fails.
>
> Janis
>
Janis, whether we pass -fPIC/-fpic through multilib_flags or through cflags
bind_pic_locally remains to be broken. So I am wondering if it's really
necessary to go through bind_pic_locally_ok route. Instead could we just
replace all the uses of bind_pic_locally with dg-skip-if and perhaps remove
the definition of bind_pic_locally to avoid future use of it?
Cheers
VP
