RFA: Improve 128-bit long double configure test

RFA: Improve 128-bit long double configure test

[Daniel Jacobowitz]

MontaVista builds both cross compilers (Linux or Windows -> MVL
target) and native compilers (MVL host) on their Linux-based build
systems.  We discovered that the two compilers disagreed on the
size of long double for PowerPC.  Have I mentioned that I think
making ABI choices based on configure tests is a really lousy idea?

This is the best I could think of to solve the problem.  Configure
wants to grep through /usr/include; if we're building with $build
!= $host (and $host = $target is assured by the previous test, above
the context of the diff), then ask GCC where glibc's headers are.

What do you think?  Is the approach OK?  How about the shell scripting
choices?

-- 
Daniel Jacobowitz
CodeSourcery

2007-11-15  Daniel Jacobowitz  <dan@codesourcery.com>

	* configure.ac: For $build != $host, use the preprocessor to
	find glibc headers.
	* configure: Regenerate.

Index: configure.ac
===================================================================
--- configure.ac	(revision 129996)
+++ configure.ac	(working copy)
@@ -3392,6 +3392,8 @@ AC_CACHE_CHECK(__stack_chk_fail in targe
 	else
 	  glibc_header_dir="${with_sysroot}/usr/include"
 	fi
+      elif test x$build != x$host && test x$GCC = xyes; then
+	glibc_header_dir=`echo "#include <features.h>" | $CPP -x c - | sed '/features/ { s,/features.h".*,,; s,.*",,; q }; d'`
       else
 	glibc_header_dir=/usr/include
       fi
@@ -3446,6 +3448,8 @@ case "$target" in
 	else
 	  glibc_header_dir="${with_sysroot}/usr/include"
 	fi
+      elif test x$build != x$host && test x$GCC = xyes; then
+	glibc_header_dir=`echo "#include <features.h>" | $CPP -x c - | sed '/features/ { s,/features.h".*,,; s,.*",,; q }; d'`
       else
 	glibc_header_dir=/usr/include
       fi

Re: RFA: Improve 128-bit long double configure test

[Mark Mitchell]

Daniel Jacobowitz wrote:
> MontaVista builds both cross compilers (Linux or Windows -> MVL
> target) and native compilers (MVL host) on their Linux-based build
> systems.  We discovered that the two compilers disagreed on the
> size of long double for PowerPC.  Have I mentioned that I think
> making ABI choices based on configure tests is a really lousy idea?

I strongly agree.  We've been getting into trouble by using autoconf to
try to probe the target for a while, and these kinds of differences
between cross- and native- compilers keep coming up.

In general, automated probing of the *host* system was what autoconf was
originally designed to do.  Probing the *target* system isn't a very
good idea, since, in general, we can't run programs on it, may not have
headers and libraries for it, etc.  In my opinion, configuration that
affects the target should either be part of the config/ files (t-files,
.h files, etc.) or handled explicitly via configuration options.

In this specific case, I think it would be better just to use the
--with-long-double-128 configuration switch and remove the automated
probing altogether.  Users that get binary compilers from a distributor
won't be affected.  Users that build from source will be able to figure
this out, just as they do lots of other things.  Also, would be to use
AC_WARN to tell the user that we think they may have set the option
wrong, but still not try to set the option automatically.  However, I
think that the decision here should be up to the Power maintainers; I'm
not trying to set policy unilaterally.

Assuming that we don't want to move away from probing here, I have a
couple of questions about your patch.  It looks like we've got
target-probing code for __stack_chk_fail right aboe the code you changed
that does the same kind of search for GLIBC headers.  I'd expect that
your change should be applied to that code too, or, better, that the
code that finds GLIBC headers should be factored out.  Also, why
wouldn't your method (using CPP) going to work on all host/target
combinations?  If so, we should use it everywhere, rather than just in
the ($host = $target) != $build case.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: RFA: Improve 128-bit long double configure test

[Daniel Jacobowitz]

On Fri, Nov 23, 2007 at 05:52:43PM -0800, Mark Mitchell wrote:
> Assuming that we don't want to move away from probing here, I have a
> couple of questions about your patch.  It looks like we've got
> target-probing code for __stack_chk_fail right aboe the code you changed
> that does the same kind of search for GLIBC headers.  I'd expect that
> your change should be applied to that code too, or, better, that the
> code that finds GLIBC headers should be factored out.

It was - that's why there were two pieces of the patch.

> Also, why wouldn't your method (using CPP) going to work on all
> host/target combinations?  If so, we should use it everywhere,
> rather than just in the ($host = $target) != $build case.

It relies on the compiler being GCC; I don't know if I can get away
with that for any other compiler one might use to build a
Linux-targeted GCC.

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFA: Improve 128-bit long double configure test

[Mark Mitchell]

Daniel Jacobowitz wrote:
> On Fri, Nov 23, 2007 at 05:52:43PM -0800, Mark Mitchell wrote:
>> Assuming that we don't want to move away from probing here, I have a
>> couple of questions about your patch.  It looks like we've got
>> target-probing code for __stack_chk_fail right aboe the code you changed
>> that does the same kind of search for GLIBC headers.  I'd expect that
>> your change should be applied to that code too, or, better, that the
>> code that finds GLIBC headers should be factored out.
> 
> It was - that's why there were two pieces of the patch.

Sorry, I must have missed that.  I apologize.

>> Also, why wouldn't your method (using CPP) going to work on all
>> host/target combinations?  If so, we should use it everywhere,
>> rather than just in the ($host = $target) != $build case.
> 
> It relies on the compiler being GCC; I don't know if I can get away
> with that for any other compiler one might use to build a
> Linux-targeted GCC.

That makes sense.  Personally, I'd be happy to stop trying to support
building GCC with non-GCC compilers, but I understand that's certain to
be controversial and I'm not advocating it.

I would like to hear from the Power maintainers, though, about whether
we can just remove this attempt at auto-probing the target altogether,
though.  I'd rather make people building the compiler work pass an
explicit configuration option and simplify this logic.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

[ping] Re: RFA: Improve 128-bit long double configure test

[Daniel Jacobowitz]

On Thu, Nov 15, 2007 at 02:27:57PM -0500, Daniel Jacobowitz wrote:
> MontaVista builds both cross compilers (Linux or Windows -> MVL
> target) and native compilers (MVL host) on their Linux-based build
> systems.  We discovered that the two compilers disagreed on the
> size of long double for PowerPC.  Have I mentioned that I think
> making ABI choices based on configure tests is a really lousy idea?
> 
> This is the best I could think of to solve the problem.  Configure
> wants to grep through /usr/include; if we're building with $build
> != $host (and $host = $target is assured by the previous test, above
> the context of the diff), then ask GCC where glibc's headers are.
> 
> What do you think?  Is the approach OK?  How about the shell scripting
> choices?

Ping.  Patch is here:
  http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00861.html

Mark asked whether we could remove the autodetection entirely, or
use it to AC_WARN instead of changing the ABI based on configure
tests.  I have no strong feeling about this, but while the check is
there I would like it to be more reliable.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [ping] Re: RFA: Improve 128-bit long double configure test

[Mark Mitchell]

Daniel Jacobowitz wrote:

>> What do you think?  Is the approach OK?  How about the shell scripting
>> choices?
> 
> Ping.  Patch is here:
>   http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00861.html

> Mark asked whether we could remove the autodetection entirely, or
> use it to AC_WARN instead of changing the ABI based on configure
> tests.  I have no strong feeling about this, but while the check is
> there I would like it to be more reliable.

I still think it would be better to ditch this, but I don't want to do 
anything here without PowerPC maintainer approval.

So, if David doesn't comment (positively) on removing the check entirely 
within 72 hours, please go ahead with your patch.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [ping] Re: RFA: Improve 128-bit long double configure test

[David Edelsohn]

>>>>> Mark Mitchell writes:

Mark> I still think it would be better to ditch this, but I don't want to do 
Mark> anything here without PowerPC maintainer approval.

Mark> So, if David doesn't comment (positively) on removing the check entirely 
Mark> within 72 hours, please go ahead with your patch.

	I'm not sure what you are asking me?  What exact change?  Doesn't
removing the test completely affect more than PowerPC?  We should use 128
bit long double on PowerPC as widely as possible, where appropriate.

David

Re: [ping] Re: RFA: Improve 128-bit long double configure test

[Mark Mitchell]

David Edelsohn wrote:

> 	I'm not sure what you are asking me?  What exact change?  Doesn't
> removing the test completely affect more than PowerPC?  We should use 128
> bit long double on PowerPC as widely as possible, where appropriate.

I don't have an exact patch.  But, I will try to explain what I meant, 
and see what you think in principle.

The problem that Daniel discovered is that the choice of ABI (whether to 
use 128-bit long double or not) is determined by configure -- rather 
than being either a property of the target triplet or an explicit 
configuration option.  Daniel's patch makes the configure script 
smarter, so that it gets the right answer more of the time, which is 
certainly progress.  So, I think Daniel's patch is good.

However, I think using autoconf probes to determine the target ABI is 
just wrong.  Daniel says:

> Have I mentioned that I think
> making ABI choices based on configure tests is a really lousy idea?

and I agree.  I think that autoconf should be used to determine 
properties of the host, but not the target.  Trying to probe the target 
is too fragile, as the problem that Daniel found demonstrates.

So, in particular, I would like to change the code in configure.ac here:

case "$target" in
   powerpc*-*-linux* | \
   powerpc*-*-gnu* | \
   sparc*-*-linux* | \
   s390*-*-linux* | \
   alpha*-*-linux*)
     AC_ARG_WITH(long-double-128,
[  --with-long-double-128  Use 128-bit long double by default.],
       gcc_cv_target_ldbl128="$with_long_double_128",
       [gcc_cv_target_ldbl128=no
...
       grep '^[  ]*#[    ]*define[       ][ 
]*__LONG_DOUBLE_MATH_OPTIONAL' \
\ 

         $glibc_header_dir/bits/wordsize.h > /dev/null 2>&1 \
       && gcc_cv_target_ldbl128=yes


to just do:

AC_ARG_WITH(long-double-128,
   [  -- ...],
   gcc_cv_target_lbdbl128="$with_long_double_128",
   [gcc_cv_target_ldbl128=yes]
   )

(I hadn't realized until just now that the same logic is also used for 
SPARC, s390, and Alpha.   But, even even so, I think you can answer as a 
PowerPC maintainer how you feel about this for PowerPC.)

The change I'm suggesting will stop us trying to auto-detect this 
property of the target.  If the user explicitly provides a configure 
option (--with-long-double-128, or --without-long-double-128), we'll 
honor their choice, just as we do now.  If they do not provide such an 
option, we'll just use 128-bit long double unconditionally.  If they're 
using an older system that doesn't support that, they get to rebuild, 
with the right configure options.  If we make this change in 4.4, by the 
time it's released, most systems will have the new GLIBC anyhow.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [ping] Re: RFA: Improve 128-bit long double configure test

[David Edelsohn]

>>>>> Mark Mitchell writes:

Mark> The change I'm suggesting will stop us trying to auto-detect this 
Mark> property of the target.  If the user explicitly provides a configure 
Mark> option (--with-long-double-128, or --without-long-double-128), we'll 
Mark> honor their choice, just as we do now.  If they do not provide such an 
Mark> option, we'll just use 128-bit long double unconditionally.  If they're 
Mark> using an older system that doesn't support that, they get to rebuild, 
Mark> with the right configure options.  If we make this change in 4.4, by the 
Mark> time it's released, most systems will have the new GLIBC anyhow.

	Isn't this the opposite argument that was made about the x86 flag
bit: people will install newer GCC on older systems.

	The C library is decoupled from the compiler and we need to deal
with that.

	If you want to announce that GCC 4.4 has terminated support for
older versions of GLIBC on all targets, that is fine.  If you want to say
that GCC 4.4 cannot automatically detect the correct configuration for
powerpc, sparc, s390, and alpha, that is not fine.

David

Re: [ping] Re: RFA: Improve 128-bit long double configure test

[Paolo Bonzini]

David Edelsohn wrote:
>>>>>> Mark Mitchell writes:
> 
> Mark> If we make this change in 4.4, by the 
> Mark> time it's released, most systems will have the new GLIBC anyhow.
> 
> 	Isn't this the opposite argument that was made about the x86 flag
> bit: people will install newer GCC on older systems.

Not really, the point there was people will run things compiled with a 
new GCC on any kind of system.  Here you have two ABIs, so you spot at 
once if something's wrong with the compilation.

> 	If you want to announce that GCC 4.4 has terminated support for
> older versions of GLIBC on all targets, that is fine.  If you want to say
> that GCC 4.4 cannot automatically detect the correct configuration for
> powerpc, sparc, s390, and alpha, that is not fine.

I see your point on this though -- just wanted to point out.

Paolo

Re: [ping] Re: RFA: Improve 128-bit long double configure test

[Mark Mitchell]

David Edelsohn wrote:
>>>>>> Mark Mitchell writes:
> 
> Mark> The change I'm suggesting will stop us trying to auto-detect this 
> Mark> property of the target.  If the user explicitly provides a configure 
> Mark> option (--with-long-double-128, or --without-long-double-128), we'll 
> Mark> honor their choice, just as we do now.  If they do not provide such an 
> Mark> option, we'll just use 128-bit long double unconditionally.  If they're 
> Mark> using an older system that doesn't support that, they get to rebuild, 
> Mark> with the right configure options.  If we make this change in 4.4, by the 
> Mark> time it's released, most systems will have the new GLIBC anyhow.
> 
> 	Isn't this the opposite argument that was made about the x86 flag
> bit: people will install newer GCC on older systems.

Probing on the host is proven to be reliable; probing on the target is, 
IMO, inherently unreliable.  It's OK to run the build->target assembler 
or build->target linker to see what it does, but poking at the target 
GLIBC header files by looking for magic strings in magic headers is bad. 
  Note that what happened here was that for a *native* configuration we 
guessed wrong about where the GLIBC header files lived, and therefore 
got the ABI wrong.  Daniel's change makes us guess better -- but it's 
still a guess.

(Note that the code in configure.ac that looks for headers has nothing 
to do with whatever the target configuration might say about where to 
look for headers; if the config/$arch/$target.h says system headers are 
in /my/include, then configure.ac will never know.)

> 	The C library is decoupled from the compiler and we need to deal
> with that.

Yes, I agree -- and the right way to deal with that, IMO, is not to have 
the compiler assume that it can grep around in the header files for the 
C library to figure out what ABI it should be using.

> 	If you want to announce that GCC 4.4 has terminated support for
> older versions of GLIBC on all targets, that is fine.  If you want to say
> that GCC 4.4 cannot automatically detect the correct configuration for
> powerpc, sparc, s390, and alpha, that is not fine.

You need a lot of information to correctly configure GCC and you need to 
test the compiler you've built to make sure it works.  If you notice 
that you've got long double sizes wrong (floating point doesn't work), 
then I'd rather you have a relatively obvious cause (oh, my system 
doesn't have 128-bit long double, so I have to pass 
--without-long-double-128) than having to debug the sort of thing Daniel 
did where the compiler is guessing at the wrong set of headers.  Putting 
users at risk of debugging configure scripts seems wrong.

In fact, I'd be perfectly happy to make it be a required switch on these 
systems; make users specify which way they want to go up front.  That 
would reduce the risk of accidental misconfiguration.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713