Re: [RFC] Thoughts on reordering the source tree

[Joseph S. Myers]

On Fri, 1 May 2009, Steven Bosscher wrote:

> > config/h8300/h8300.c:#include "c-pragma.h"
> > config/i386/i386.c:#include "c-common.h"
> > config/sh/sh.c:#include "c-pragma.h"
> > config/spu/spu.c:#include "c-common.h"
> 
> These I will need to check via a cross compiler. Andrew P., maybe you
> can look at SPU?

Rechecking now, I see I missed this one:

config/arm/arm.c:#include "c-pragma.h"

-- 
Joseph S. Myers
jos...@codesourcery.com

exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Matthias Klose]

Noticed that some symbols introduced for the exception propagation support are
missing in libstdc++.so.6 on arm-linux-gnueabi, hppa-linux-gnu and
sparc-linux-gnu (no results for mips*-linux yet). The libstdc++ configure check
GLIBCXX_ENABLE_ATOMIC_BUILTINS fails, because three of the five __sync_*
functions are still seen in the asm code (not seen: __sync_lock_release and
__sync_synchronise).

libgcc.a has all of the __sync_* functions defined, and the configure (link)
tests in libgomp and libgfortran do succeed. Unsure what I'm doing wrong with
the libstdc++ configury. Is this seen on other linux builds for these targets as
well?

  Matthias

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Paolo Carlini]

Il giorno 02/mag/09, alle ore 13:05, Matthias Klose   
ha scritto:


Noticed that some symbols introduced for the exception propagation  
support are

missing in libstdc++.so.6 on arm-linux-gnueabi, hppa-linux-gnu and
sparc-linux-gnu (no results for mips*-linux yet). The libstdc++  
configure check
GLIBCXX_ENABLE_ATOMIC_BUILTINS fails, because three of the five  
__sync_*
functions are still seen in the asm code (not seen:  
__sync_lock_release and

__sync_synchronise).

libgcc.a has all of the __sync_* functions defined, and the  
configure (link)
tests in libgomp and libgfortran do succeed. Unsure what I'm doing  
wrong with
the libstdc++ configury. Is this seen on other linux builds for  
these targets as

well?

 Matthias

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Paolo Carlini]

Hi,

libgcc.a has all of the __sync_* functions defined, and the  
configure (link)
tests in libgomp and libgfortran do succeed. Unsure what I'm doing  
wrong with

the libstdc++ configury.


I don't think you are doing anything wrong, it's just that in libstdc+ 
+ we are moving away from doing link tests. In my understanding, that  
would be nice also for the other libraries but of course leads yo  
weaker tests. Now, in order to make progress, I think we should first  
figure out if and to what extent we have now a libgcc such that  the  
atomic builtins can be assumed to be unconditionally available to the  
user, thus either expanded inline or provided on all the supported  
targets in libgcc. Besides that, we could maybe add a configure time  
option to tell the library to just assume the availability of the  
atomic builtins, thus not relying on weak compile-type tests. We could  
also add safe special cases to the configury, like assuming all the  
linux targets are now ok, one way or another.


I would appreciate some guidance from Mark and core compiler people,  
here...


To end, just want to remind that this issue is essentially very old,  
just less to the fore now thanks to the fact that x86_64 is so  
popular: eg, it woul be so nice if people targeting i?86 could assume  
the builtins to be always available.


Paolo

Problems with in-tree host libraries (gmp, ppl, etc)

[Anthony Green]

The top level configury suggests that you can simply drop gmp, ppl, etc
into the top level source dir and they will get configured and used.
Does this really work?

At the very least, I think ppl requires that gmp be configured with
--enable-cxx, like so:

Index: Makefile.def
===
--- Makefile.def(revision 146995)
+++ Makefile.def(working copy)
@@ -60,7 +60,7 @@
 host_modules= { module= gawk; };
 host_modules= { module= gettext; };
 host_modules= { module= gmp; lib_path=.libs; bootstrap=true;
-   extra_configure_flags='--disable-shared';
+   extra_configure_flags='--disable-shared --enable-cxx';
no_install= true; 
host="none-${host_vendor}-${host_os}";
target="none-${host_vendor}-${host_os}"; };

Even then, the ppl configury isn't detecting the gmp we just built.  It
seems as though we should install gmp in a local temporary install tree
and point ppl at that.  See below for a trace of the ppl configury as it
attempts to detect an in-tree gmp (after applying the patch above).

AG



+ test -n /builddir/build/BUILD/gcc/build/./gmp/
+ test -z /builddir/build/BUILD/gcc/build/./gmp/
+ test -n /builddir/build/BUILD/gcc/build/./gmp/
+ test -z /builddir/build/BUILD/gcc/build/./gmp/
+ printf '%s\n' 'configure:15514: checking how to link with libgmp'
+ printf %s 'checking how to link with libgmp... '
checking how to link with libgmp... + test '' = set
+ use_additional=yes
+ acl_save_prefix=/usr
+ prefix=/usr
+ acl_save_exec_prefix=/usr
+ exec_prefix=/usr
+ eval 'additional_includedir="/usr/include"'
++ additional_includedir=/usr/include
+ eval 'additional_libdir="/usr/lib"'
++ additional_libdir=/usr/lib
+ exec_prefix=/usr
+ prefix=/usr
+ test set = set
+ withval=/builddir/build/BUILD/gcc/build/./gmp/
+ test X/builddir/build/BUILD/gcc/build/./gmp/ = Xno
+ test X/builddir/build/BUILD/gcc/build/./gmp/ = X
+ additional_includedir=/builddir/build/BUILD/gcc/build/./gmp//include
+ additional_libdir=/builddir/build/BUILD/gcc/build/./gmp//lib
+ LIBGMP=
+ LTLIBGMP=
+ INCGMP=
+ rpathdirs=
+ ltrpathdirs=
+ names_already_handled=
+ names_next_round='gmp '
+ test -n 'gmp '
+ names_this_round='gmp '
+ names_next_round=
+ for name in '$names_this_round'
+ already_handled=
+ test -z ''
+ names_already_handled=' gmp'
++ echo gmp
++ sed -e 'y|abcdefghijklmnopqrstuvwxyz./-|
ABCDEFGHIJKLMNOPQRSTUVWXYZ___|'
+ uppername=GMP
+ eval 'value="$HAVE_LIBGMP"'
++ value=
+ test -n ''
+ found_dir=
+ found_la=
+ found_so=
+ found_a=
+ test yes = yes
+ test -n so
+ test -f /builddir/build/BUILD/gcc/build/./gmp//lib/libgmp.so
+ test -f /builddir/build/BUILD/gcc/build/./gmp//lib/libgmp.a
+ test X = X
+ test X '!=' X
+ LIBGMP=-lgmp
+ LTLIBGMP=-lgmp
+ test -n ''
+ test X '!=' X
+ test X '!=' X
+ ac_cv_libgmp_libs=-lgmp
+ ac_cv_libgmp_ltlibs=-lgmp
+ ac_cv_libgmp_cppflags=
+ printf '%s\n' 'configure:15903: result: -lgmp'
+ printf '%s\n' -lgmp
-lgmp
+ LIBGMP=-lgmp
+ LTLIBGMP=-lgmp
+ INCGMP=
+ HAVE_LIBGMP=yes
+ printf '%s\n' 'configure:15943: checking how to link with libgmpxx'
+ printf %s 'checking how to link with libgmpxx... '
checking how to link with libgmpxx... + test '' = set
+ use_additional=yes
+ acl_save_prefix=/usr
+ prefix=/usr
+ acl_save_exec_prefix=/usr
+ exec_prefix=/usr
+ eval 'additional_includedir="/usr/include"'
++ additional_includedir=/usr/include
+ eval 'additional_libdir="/usr/lib"'
++ additional_libdir=/usr/lib
+ exec_prefix=/usr
+ prefix=/usr
+ test set = set
+ withval=/builddir/build/BUILD/gcc/build/./gmp/
+ test X/builddir/build/BUILD/gcc/build/./gmp/ = Xno
+ test X/builddir/build/BUILD/gcc/build/./gmp/ = X
+ additional_includedir=/builddir/build/BUILD/gcc/build/./gmp//include
+ additional_libdir=/builddir/build/BUILD/gcc/build/./gmp//lib
+ LIBGMPXX=
+ LTLIBGMPXX=
+ INCGMPXX=
+ rpathdirs=
+ ltrpathdirs=
+ names_already_handled=
+ names_next_round='gmpxx gmp'
+ test -n 'gmpxx gmp'
+ names_this_round='gmpxx gmp'
+ names_next_round=
+ for name in '$names_this_round'
+ already_handled=
+ test -z ''
+ names_already_handled=' gmpxx'
++ echo gmpxx
++ sed -e 'y|abcdefghijklmnopqrstuvwxyz./-|
ABCDEFGHIJKLMNOPQRSTUVWXYZ___|'
+ uppername=GMPXX
+ eval 'value="$HAVE_LIBGMPXX"'
++ value=
+ test -n ''
+ found_dir=
+ found_la=
+ found_so=
+ found_a=
+ test yes = yes
+ test -n so
+ test -f /builddir/build/BUILD/gcc/build/./gmp//lib/libgmpxx.so
+ test -f /builddir/build/BUILD/gcc/build/./gmp//lib/libgmpxx.a
+ test X = X
+ test X '!=' X
+ LIBGMPXX=-lgmpxx
+ LTLIBGMPXX=-lgmpxx
+ for name in '$names_this_round'
+ already_handled=
+ for n in '$names_already_handled'
+ test gmpxx = gmp
+ test -z ''
+ names_already_handled=' gmpxx gmp'
++ echo gmp
++ sed -e 'y|abcdefghijklmnopqrstuvwxyz./-|
ABCDEFGHIJKLMNOPQRSTUVWXYZ___|'
+ uppername=GMP
+ eval 'value="$HAVE_LIBGMP"'
++ value=yes
+ test -n yes
+ test yes = yes
+ eval 'value="$LIBGMP"'
++ value=-lgmp
+ test -z -lgmp
+ LIBGMPXX='-lgmpxx -lgmp'
+ eval 'value

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Joseph S. Myers]

On Sat, 2 May 2009, Paolo Carlini wrote:

> I don't think you are doing anything wrong, it's just that in libstdc++ we are
> moving away from doing link tests. In my understanding, that would be nice
> also for the other libraries but of course leads yo weaker tests. Now, in
> order to make progress, I think we should first figure out if and to what
> extent we have now a libgcc such that  the atomic builtins can be assumed to
> be unconditionally available to the user, thus either expanded inline or
> provided on all the supported targets in libgcc. Besides that, we could maybe
> add a configure time option to tell the library to just assume the
> availability of the atomic builtins, thus not relying on weak compile-type
> tests. We could also add safe special cases to the configury, like assuming
> all the linux targets are now ok, one way or another.

Linux targets *don't* necessarily have the __sync_* functions.  For 
example, they are not available on ColdFire (even with Maxim's TLS patch 
which I imagine will be updated and reposted in due course now we are in 
Stage 1), since atomic operations there use a kernel helper in a vDSO.  It 
would be possible for libc to provide these functions, but that's not in 
the present specification or implementation.  If anyone is still using ARM 
old-ABI, they aren't in libgcc there either.

It is however safe on Linux targets to do link tests rather than just 
looking at the .s output of the compiler (looking at .s output being what 
gives misleading results when the functions are in libgcc or libc rather 
than built in).

But there is one further complication.  C++ shared libraries are linked 
with -shared-libgcc by default.  The __sync_* functions on ARM and PA are 
in static libgcc only (and it looks like those on SH are always hidden, so 
effectively also static-only).  So you can't actually link a C++ shared 
library that uses these functions.  I consider this a compiler bug; even 
with -shared-libgcc I think the compiler needs to link with the static 
libgcc, after the shared one, so that undefined references to 
static-libgcc-only functions such as these can be resolved.

> To end, just want to remind that this issue is essentially very old, just less
> to the fore now thanks to the fact that x86_64 is so popular: eg, it woul be
> so nice if people targeting i?86 could assume the builtins to be always
> available.

On i486 and later they are available.  As for i686-pc-linux-gnu not 
defaulting to -march=i686 in the compiler (libstdc++ does select 
directories based on the target name as if it did mean -march not -mtune, 
however), perhaps someone could review HJ's patch 
?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Paolo Carlini]

Hi,

and, first, thanks for the various clarifications.
> Linux targets *don't* necessarily have the __sync_* functions.  For 
> example, they are not available on ColdFire (even with Maxim's TLS patch 
> which I imagine will be updated and reposted in due course now we are in 
> Stage 1), since atomic operations there use a kernel helper in a vDSO.  It 
> would be possible for libc to provide these functions, but that's not in 
> the present specification or implementation.  If anyone is still using ARM 
> old-ABI, they aren't in libgcc there either.
>
> It is however safe on Linux targets to do link tests rather than just 
> looking at the .s output of the compiler (looking at .s output being what 
> gives misleading results when the functions are in libgcc or libc rather 
> than built in).
>   
I'm not sure if we already discussed a bit the following: would it make
sense to change those tests along the lines of GCC_TRY_COMPILE_OR_LINK?
I mean, if gcc_no_link  is yes, then we just do what we currently do, 
we look at the .s output, otherwise we do a test, completely analogous
to the one used already in libgomp, for example. That would be not just
for linux, but for all targets.

Thanks,
Paolo.

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Joseph S. Myers]

On Sat, 2 May 2009, Paolo Carlini wrote:

> I'm not sure if we already discussed a bit the following: would it make
> sense to change those tests along the lines of GCC_TRY_COMPILE_OR_LINK?
> I mean, if gcc_no_link  is yes, then we just do what we currently do, 
> we look at the .s output, otherwise we do a test, completely analogous
> to the one used already in libgomp, for example. That would be not just
> for linux, but for all targets.

Subject to fixing the bug I think is present with static-only libgcc 
functions and C++ shared libraries (so that being able to link an 
executable with the functions means it is also possible to link libstdc++ 
and have the symbols resolved in that link), it would make sense to test 
linking if possible, failing that the .s file.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa,sparc}-linux

[Paolo Carlini]

Hi,
>> I'm not sure if we already discussed a bit the following: would it make
>> sense to change those tests along the lines of GCC_TRY_COMPILE_OR_LINK?
>> I mean, if gcc_no_link  is yes, then we just do what we currently do, 
>> we look at the .s output, otherwise we do a test, completely analogous
>> to the one used already in libgomp, for example. That would be not just
>> for linux, but for all targets.
>> 
> Subject to fixing the bug I think is present with static-only libgcc 
> functions and C++ shared libraries (so that being able to link an 
> executable with the functions means it is also possible to link libstdc++ 
> and have the symbols resolved in that link), it would make sense to test 
> linking if possible, failing that the .s file.
>   
Ok, thanks. Then, I think I'll implement this, for now. Seems in any
case conservative to have a link type test identical to the one used in
libgomp and libgfortran and a fall back to the .s file (as currently used).

Paolo.

Re: [RFC] Thoughts on reordering the source tree

[Kaz Kojima]

Steven Bosscher  wrote:
[snip]
> config/sh/sh.c:#include "c-pragma.h"

FYI, I've confirmed that there are no problems without
this line for sh4-unknown-linux-gnu.

Regards,
kaz