Re: [patch] Fix array aliasing conftest

[Jeff Johnston <jjohnstn at redhat dot com>]

Ken Werner wrote:
> On Friday 17 April 2009 16:32:42 you wrote:
>   
> > > From: Ken Werner <ken@linux.vnet.ibm.com>
> > > Date: Wed, 8 Apr 2009 16:57:35 +0200
> > >
> > > while looking at the autoconf scripts I noticed newlibs check for array
> > > aliasing support (_HAVE_ARRAY_ALIASING). The configure.in specifies the
> > > following conftest:
> > >   char x[3] = { 'a', 'b', 'c' };
> > >   extern char y[2] __attribute__((alias ("x+1")));
> > > This looks valid but autoconf strips the square brackets. The generated
> > > configure states:
> > >   char x3 = { 'a', 'b', 'c' };
> > >   extern char y2 __attribute__((alias ("x+1")));
> > > I think this has never compiled as intended. Adding additional square
> > > brackets in the configure.in seem to fix that.
> > >       
> > Except that the construct as such is _invalid_ and must not be
> > used.  You can only alias to symbols, not offset expressions.
> > It accidentally worked for older gcc.  See
> > <http://sourceware.org/ml/newlib/2001/msg00466.html> and
> > <http://sourceware.org/ml/newlib/2005/msg00474.html>.
> >
> > I'm a bit surprised it's still used (even conditionally) and
> > apparently working somewhere, supposedly cygwin?
> >
> > It seems the above fixing of the test now causes the build to
> > break for e.g. cris-elf:
> >
> > checking for cris-elf-gcc... (cached) /tmp/newnewlib/gccobj/./gcc/xgcc
> > -B/tmp/newnewlib/gccobj/./gcc/ -nostdinc
> > -B/tmp/newnewlib/gccobj/cris-elf/v10/newlib/ -isystem
> > /tmp/newnewlib/gccobj/cris-elf/v10/newlib/targ-include -isystem
> > /tmp/newnewlib/gcc/newlib/libc/include
> > -B/tmp/newnewlib/gccobj/cris-elf/v10/libgloss/cris
> > -L/tmp/newnewlib/gccobj/cris-elf/v10/libgloss/libnosys
> > -L/tmp/newnewlib/gcc/libgloss/cris -B/tmp/newnewlib/pre/cris-elf/bin/
> > -B/tmp/newnewlib/pre/cris-elf/lib/ -isystem
> > /tmp/newnewlib/pre/cris-elf/include -isystem
> > /tmp/newnewlib/pre/cris-elf/sys-include  -march=v10 -mbest-lib-options
> > checking for C compiler default output file name... configure: error: C
> > compiler cannot create executables See `config.log' for more details.
> > configure: error: /tmp/newnewlib/gcc/newlib/libm/configure failed for libm
> > make[1]: *** [configure-target-newlib] Error 1
> > make[1]: Leaving directory `/tmp/newnewlib/gccobj'
> > make: *** [all] Error 2
> >
> > And in tmp/newnewlib/gcc/newlib/config.log, the last compile
> > test is:
> >
> > configure:11916: /tmp/newnewlib/gccobj/./gcc/xgcc
> > -B/tmp/newnewlib/gccobj/./gcc/ -nostdinc
> > -B/tmp/newnewlib/gccobj/cris-elf/newlib/ -isystem
> > /tmp/newnewlib/gccobj/cris-elf/newlib/targ-include -isystem
> > /tmp/newnewlib/gcc/newlib/libc/include
> > -B/tmp/newnewlib/gccobj/cris-elf/libgloss/cris
> > -L/tmp/newnewlib/gccobj/cris-elf/libgloss/libnosys
> > -L/tmp/newnewlib/gcc/libgloss/cris -B/tmp/newnewlib/pre/cris-elf/bin/
> > -B/tmp/newnewlib/pre/cris-elf/lib/ -isystem
> > /tmp/newnewlib/pre/cris-elf/include -isystem
> > /tmp/newnewlib/pre/cris-elf/sys-include   -c conftest.c 1>&5
> > conftest.c:2: error: 'y' aliased to undefined symbol 'x+1'
> >
> > Why is that?  Isn't it a test for an optional feature?  Is it
> > somehow an autoconf bug that the last feature test has to
> > succeed?  Am I barking up the wrong tree?
> >
> >     
It's an autoconf stupidity.  The AC_TRY_COMPILE macro cannot be used 
because in it's guts
it attempts to build an executable even though you are only interested 
in "compiling".  We cannot
build executables because there is no library yet which is why we create 
our own version of AC_PROG_CC
in acinclude.m4.

That said, the _HAVE_ARRAY_ALIASING check is removed because it was for 
CYGWIN backward
compatibility and isn't being used there.

The AC_TRY_COMPILE in libm/configure.in has been translated to 
AC_TRY_COMMAND.

I have just checked in a patch.

-- Jeff J.
> > (Not that the tree isn't worthy of barking up against, but maybe
> > it's not *that* cat I'm chasing.)
> >
> > brgds, H-P
> >     
>
> Hi,
>
> Assuming you're using recent GCC versions the conftest fails independently of 
> the applied patch. It's failing for a long time in fact. So, I'm not sure this 
> is the root cause of the cris-elf build failure.
> However, the resulting _HAVE_ARRAY_ALIASING define is only used in 
> newlib/libc/ctype/ctype_.c. Since the configure test did not define this flag for 
> about four years we might omit the whole test and remove the guarded code. 
> Maybe Jeff can give some insights on that.
>
> Regards
> Ken
>