* RFA: Improve 128-bit long double configure test
@ 2007-11-15 20:18 Daniel Jacobowitz
2007-11-24 10:06 ` Mark Mitchell
2008-03-06 20:33 ` [ping] " Daniel Jacobowitz
0 siblings, 2 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2007-11-15 20:18 UTC (permalink / raw)
To: gcc-patches
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFA: Improve 128-bit long double configure test
2007-11-15 20:18 RFA: Improve 128-bit long double configure test Daniel Jacobowitz
@ 2007-11-24 10:06 ` Mark Mitchell
2007-11-26 6:45 ` Daniel Jacobowitz
2008-03-06 20:33 ` [ping] " Daniel Jacobowitz
1 sibling, 1 reply; 11+ messages in thread
From: Mark Mitchell @ 2007-11-24 10:06 UTC (permalink / raw)
To: gcc-patches
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFA: Improve 128-bit long double configure test
2007-11-24 10:06 ` Mark Mitchell
@ 2007-11-26 6:45 ` Daniel Jacobowitz
2007-11-26 21:09 ` Mark Mitchell
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Jacobowitz @ 2007-11-26 6:45 UTC (permalink / raw)
To: gcc-patches
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: RFA: Improve 128-bit long double configure test
2007-11-26 6:45 ` Daniel Jacobowitz
@ 2007-11-26 21:09 ` Mark Mitchell
0 siblings, 0 replies; 11+ messages in thread
From: Mark Mitchell @ 2007-11-26 21:09 UTC (permalink / raw)
To: gcc-patches
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [ping] Re: RFA: Improve 128-bit long double configure test
2007-11-15 20:18 RFA: Improve 128-bit long double configure test Daniel Jacobowitz
2007-11-24 10:06 ` Mark Mitchell
@ 2008-03-06 20:33 ` Daniel Jacobowitz
2008-04-09 0:40 ` Mark Mitchell
1 sibling, 1 reply; 11+ messages in thread
From: Daniel Jacobowitz @ 2008-03-06 20:33 UTC (permalink / raw)
To: gcc-patches
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ping] Re: RFA: Improve 128-bit long double configure test
2008-03-06 20:33 ` [ping] " Daniel Jacobowitz
@ 2008-04-09 0:40 ` Mark Mitchell
2008-04-09 2:59 ` David Edelsohn
0 siblings, 1 reply; 11+ messages in thread
From: Mark Mitchell @ 2008-04-09 0:40 UTC (permalink / raw)
To: gcc-patches; +Cc: David Edelsohn
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ping] Re: RFA: Improve 128-bit long double configure test
2008-04-09 0:40 ` Mark Mitchell
@ 2008-04-09 2:59 ` David Edelsohn
2008-04-09 6:48 ` Mark Mitchell
0 siblings, 1 reply; 11+ messages in thread
From: David Edelsohn @ 2008-04-09 2:59 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc-patches
>>>>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ping] Re: RFA: Improve 128-bit long double configure test
2008-04-09 2:59 ` David Edelsohn
@ 2008-04-09 6:48 ` Mark Mitchell
2008-04-09 13:16 ` David Edelsohn
0 siblings, 1 reply; 11+ messages in thread
From: Mark Mitchell @ 2008-04-09 6:48 UTC (permalink / raw)
To: David Edelsohn; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ping] Re: RFA: Improve 128-bit long double configure test
2008-04-09 6:48 ` Mark Mitchell
@ 2008-04-09 13:16 ` David Edelsohn
2008-04-09 13:37 ` Paolo Bonzini
2008-04-09 16:02 ` Mark Mitchell
0 siblings, 2 replies; 11+ messages in thread
From: David Edelsohn @ 2008-04-09 13:16 UTC (permalink / raw)
To: Mark Mitchell; +Cc: gcc-patches
>>>>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ping] Re: RFA: Improve 128-bit long double configure test
2008-04-09 13:16 ` David Edelsohn
@ 2008-04-09 13:37 ` Paolo Bonzini
2008-04-09 16:02 ` Mark Mitchell
1 sibling, 0 replies; 11+ messages in thread
From: Paolo Bonzini @ 2008-04-09 13:37 UTC (permalink / raw)
To: David Edelsohn; +Cc: Mark Mitchell, gcc-patches
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ping] Re: RFA: Improve 128-bit long double configure test
2008-04-09 13:16 ` David Edelsohn
2008-04-09 13:37 ` Paolo Bonzini
@ 2008-04-09 16:02 ` Mark Mitchell
1 sibling, 0 replies; 11+ messages in thread
From: Mark Mitchell @ 2008-04-09 16:02 UTC (permalink / raw)
To: David Edelsohn; +Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2008-04-09 15:23 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-11-15 20:18 RFA: Improve 128-bit long double configure test Daniel Jacobowitz
2007-11-24 10:06 ` Mark Mitchell
2007-11-26 6:45 ` Daniel Jacobowitz
2007-11-26 21:09 ` Mark Mitchell
2008-03-06 20:33 ` [ping] " Daniel Jacobowitz
2008-04-09 0:40 ` Mark Mitchell
2008-04-09 2:59 ` David Edelsohn
2008-04-09 6:48 ` Mark Mitchell
2008-04-09 13:16 ` David Edelsohn
2008-04-09 13:37 ` Paolo Bonzini
2008-04-09 16:02 ` Mark Mitchell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).