Re: [patch] Fix array aliasing conftest

[Ken Werner <ken at linux dot vnet dot ibm dot com>]

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?
>
> (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