libada configure contains wrong code and GNAT as a cross compiler in general
Hi,
I'm trying to add GNAT to Yocto and still coming across problems. I have
a number of questions about GNAT as a cross compiler, I know it wasn't
designed as one within the GCC tree, but I think it needs to be capable
of building as one to match the other compilers.
1) The latest problem I'm having is that it fails to build
libgnat-4.6.so, I've managed to track it down to the following code
inside libada/configure:
# Determine what to build for 'gnatlib'
if test $build = $target \
&& test ${enable_shared} = yes ; then
# Note that build=target is almost certainly the wrong test; FIXME
default_gnatlib_target="gnatlib-shared"
else
default_gnatlib_target="gnatlib-plain"
fi
Surely, it shouldn't matter whether the $build = $target is true or not,
it should be whether the target supports shared libs or not. So, am I ok
to remove this test (keeping the enable_shared test)? Is there anything
else that could break because of this change?
In fact, should the code in libada/configure script actually do platform
tests, just as they are done in the gnattools/configure script?
2) I also want to point out that inside
gcc/ada/gcc-interface/Makefile.in there are lines such as:
GNATLIB_SHARED = gnatlib-shared-dual
Is these relics? If so, shouldn't the above configure script also use
the "-dual" and the other options available to it?
3) Coming back to gnattools, there are tests in there to set the
TOOLS_TARGET_PAIRS variable, which are also set in
gcc/ada/gcc-interface/Makefile.in, are the ones set in the Makefile.in
also relics? Can they be removed from there?
4) What is the point of the --disable-libada flag exactly? I've seen a
reference to there being a point, just not what that point is,
especially considering it disabled the build of gnattools and if you
disable the link between the two, the gnattools use the system runtime.
I don't understand this at all.
Thanks,
Luke.
Re: libada configure contains wrong code and GNAT as a cross compiler in general
On Wed, Jan 09, 2013 at 08:43:11AM +, Luke A. Guest wrote:
> Hi,
>
> I'm trying to add GNAT to Yocto and still coming across problems. I have
> a number of questions about GNAT as a cross compiler, I know it wasn't
> designed as one within the GCC tree, but I think it needs to be capable
> of building as one to match the other compilers.
>
> 1) The latest problem I'm having is that it fails to build
> libgnat-4.6.so, I've managed to track it down to the following code
> inside libada/configure:
>
> # Determine what to build for 'gnatlib'
> if test $build = $target \
>&& test ${enable_shared} = yes ; then
> # Note that build=target is almost certainly the wrong test; FIXME
> default_gnatlib_target="gnatlib-shared"
> else
> default_gnatlib_target="gnatlib-plain"
> fi
>
> Surely, it shouldn't matter whether the $build = $target is true or not,
> it should be whether the target supports shared libs or not. So, am I ok
> to remove this test (keeping the enable_shared test)? Is there anything
> else that could break because of this change?
>
> In fact, should the code in libada/configure script actually do platform
> tests, just as they are done in the gnattools/configure script?
I can't speak for libada/*, I'm not familiar enough with these, but they may
well contain errors indeed.
> 2) I also want to point out that inside
> gcc/ada/gcc-interface/Makefile.in there are lines such as:
>
> GNATLIB_SHARED = gnatlib-shared-dual
>
> Is these relics?
No, these are correct settings. If there's a mistake, it might be in libada.
> If so, shouldn't the above configure script also use
> the "-dual" and the other options available to it?
>
> 3) Coming back to gnattools, there are tests in there to set the
> TOOLS_TARGET_PAIRS variable, which are also set in
> gcc/ada/gcc-interface/Makefile.in, are the ones set in the Makefile.in
> also relics? Can they be removed from there?
No, these are not relics, these are actually the reference settings,
and used e.g. when using --disable-libada
> 4) What is the point of the --disable-libada flag exactly? I've seen a
To disable automatic build of gnatlib and gnattools. This is used e.g. at
AdaCore to configure in a more fine grained manner how gnatlib and gnattools
are built. Ideally we'd like to use the libada/gnatools mechanism, but
this mechanism isn't quite working as we'd need it, so this hasn't happened
yet.
gnattools will either use the run-time just built in case of a native compiler,
and will use the base compiler's run-time in case of a cross (hence the
requirement that you first need to build a native GNAT before building a cross,
using matching sources).
Arno
Re: libada configure contains wrong code and GNAT as a cross compiler in general
> 1) The latest problem I'm having is that it fails to build
> libgnat-4.6.so, I've managed to track it down to the following code
> inside libada/configure:
>
> # Determine what to build for 'gnatlib'
> if test $build = $target \
>&& test ${enable_shared} = yes ; then
> # Note that build=target is almost certainly the wrong test; FIXME
> default_gnatlib_target="gnatlib-shared"
> else
> default_gnatlib_target="gnatlib-plain"
> fi
>
> Surely, it shouldn't matter whether the $build = $target is true or not,
> it should be whether the target supports shared libs or not. So, am I ok
> to remove this test (keeping the enable_shared test)? Is there anything
> else that could break because of this change?
Yes, I think that you can remove the build=target part, provided that this
makes it possible to build the shared library. If there are other problems
downhill, then they will need to be addressed first.
> In fact, should the code in libada/configure script actually do platform
> tests, just as they are done in the gnattools/configure script?
Maybe, but whether it's the right thing to do for the problem at hand is not
clear. libada is for the target while gnattools are for the host. The libada
configury should bear a ressemblance to the other target libraries.
--
Eric Botcazou
optimize malloc to stack allocation.
Hello,
gcc currently does not even optimize following fragment:
int foo(){
char *x=malloc(64);
free(x);
}
It should be possible to change malloc with small size and there is free
that dominates that malloc into alloca.
Also when size it is not known it could be (perhaps with profiling)
turned into conditional alloca.
--
static from nylon underwear
Re: optimize malloc to stack allocation.
On Wed, 9 Jan 2013, Ondřej Bílka wrote:
gcc currently does not even optimize following fragment:
int foo(){
char *x=malloc(64);
free(x);
}
Yes it does.
(not that more optimizations aren't possible, but it does this one)
--
Marc Glisse
Re: optimize malloc to stack allocation.
On Wed, Jan 09, 2013 at 05:12:06PM +0100, Marc Glisse wrote:
> On Wed, 9 Jan 2013, Ondřej Bílka wrote:
>
> >gcc currently does not even optimize following fragment:
> >
> >int foo(){
> > char *x=malloc(64);
> > free(x);
> >}
>
> Yes it does.
> (not that more optimizations aren't possible, but it does this one)
Sorry I did checked this only with old gcc. Recent gcc does eliminates
this by DCE which was not point of that example.
This is correct example.
int foo(){
char *x=malloc(64);
x[3]=4;
int z=x[3];
free(x);
return z;
}
>
> --
> Marc Glisse
Re: libada configure contains wrong code and GNAT as a cross compiler in general
On Wed, 2013-01-09 at 09:57 +0100, Arnaud Charlet wrote: > > 2) I also want to point out that inside > > gcc/ada/gcc-interface/Makefile.in there are lines such as: > > > > GNATLIB_SHARED = gnatlib-shared-dual > > > > Is these relics? > > No, these are correct settings. If there's a mistake, it might be in libada. These don't get picked up in libada and AFAICS there is no way for it to be passed from gcc/ada/gcc-interface/Makefile.in to libada, much like the next part below... > > If so, shouldn't the above configure script also use > > the "-dual" and the other options available to it? > > > > 3) Coming back to gnattools, there are tests in there to set the > > TOOLS_TARGET_PAIRS variable, which are also set in > > gcc/ada/gcc-interface/Makefile.in, are the ones set in the Makefile.in > > also relics? Can they be removed from there? > > No, these are not relics, these are actually the reference settings, When using --libada, these don't get used, you have to manually patch the configure in gnattools to get the correct working version of mlib, i.e. you won't get an mlib that supports library building on arm-none-eabi-gnulinux. > and used e.g. when using --disable-libada Ok, so they are used when that flag is in force? > > 4) What is the point of the --disable-libada flag exactly? I've seen a > > To disable automatic build of gnatlib and gnattools. This is used e.g. at > AdaCore to configure in a more fine grained manner how gnatlib and gnattools > are built. Ideally we'd like to use the libada/gnatools mechanism, but > this mechanism isn't quite working as we'd need it, so this hasn't happened > yet. How is this mechanism supposed to work? What is it really supposed to do? Is there a doc or spec somewhere that outlines what it was meant for? We need a bit more information if it is to be fixed. Thanks, Luke.
Re: optimize malloc to stack allocation.
On Wed, Jan 9, 2013 at 5:33 PM, Ondřej Bílka wrote:
> On Wed, Jan 09, 2013 at 05:12:06PM +0100, Marc Glisse wrote:
>> On Wed, 9 Jan 2013, Ondřej Bílka wrote:
>>
>> >gcc currently does not even optimize following fragment:
>> >
>> >int foo(){
>> > char *x=malloc(64);
>> > free(x);
>> >}
>>
>> Yes it does.
>> (not that more optimizations aren't possible, but it does this one)
> Sorry I did checked this only with old gcc. Recent gcc does eliminates
> this by DCE which was not point of that example.
>
> This is correct example.
>
> int foo(){
> char *x=malloc(64);
> x[3]=4;
> int z=x[3];
> free(x);
> return z;
> }
There is a bug that tracks this already.
Richard.
>>
>> --
>> Marc Glisse
>
Re: libada configure contains wrong code and GNAT as a cross compiler in general
On Wed, 2013-01-09 at 08:43 +, Luke A. Guest wrote:
> 1) The latest problem I'm having is that it fails to build
> libgnat-4.6.so, I've managed to track it down to the following code
> inside libada/configure:
>
> # Determine what to build for 'gnatlib'
> if test $build = $target \
>&& test ${enable_shared} = yes ; then
> # Note that build=target is almost certainly the wrong test; FIXME
> default_gnatlib_target="gnatlib-shared"
> else
> default_gnatlib_target="gnatlib-plain"
> fi
>
> Surely, it shouldn't matter whether the $build = $target is true or not,
> it should be whether the target supports shared libs or not. So, am I ok
> to remove this test (keeping the enable_shared test)? Is there anything
> else that could break because of this change?
Ok, I will do a full build tonight with the testuite and take this "test
$build = $target" out of the build. I can only do a x86_64 linux test,
should I send the results to the list?
Luke.
Re: libada configure contains wrong code and GNAT as a cross compiler in general
> Ok, I will do a full build tonight with the testuite and take this "test > $build = $target" out of the build. I can only do a x86_64 linux test, > should I send the results to the list? You obviously need to test on a configuration that exercises the path. -- Eric Botcazou
lm32 unknown exception model (side-effect of libgcc reorg)
Hi lm32-rtems fails building C++ with this error: configure: WARNING: decimal float is not supported for this target, ignored checking whether fixed-point is supported... no checking whether to use setjmp/longjmp exceptions... unknown configure: error: unable to detect exception model make[1]: *** [configure-target-libgcc] Error 1 Any suggestions on how to approach fixing this other than disabling C++? I think this was broken by the libgcc reorganization. FWIW this has been around a while but the lm32 was incapable of building C for a while and it finally gets this far again: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35806 Support Available (256) 722-9985
