On 08/16/2018 09:23 AM, Martin Sebor wrote:
> On 08/15/2018 03:34 PM, Jeff Law wrote:
>> On 08/15/2018 03:02 PM, Martin Sebor wrote:
>>> On 08/15/2018 06:07 AM, Joseph Myers wrote:
>>>> On Tue, 14 Aug 2018, Martin Sebor wrote:
>>>>
>>>>>> This is with Bison 3.0.4, should the version used to produce
>>>>>> intl/plural.c
>>>>>> prove relevant.
>>>>>
>>>>> Can you send me the translation unit and the options it was compiled
>>>>> with that triggered the errors?
>>>>
>>>> I've attached plural.i. The error is a static link error linking sln,
>>>> but
>>>> maybe comparing results of compiling plural.i before and after the
>>>> changes
>>>> may be enlightening (unless it's actually a difference in code
>>>> elsewhere
>>>> in glibc causing a link error reported in plural.o).
>>>>
>>>> Compiled with:
>>>>
>>>> alpha-glibc-linux-gnu-gcc
>>>> /scratch/jmyers/glibc/many9/build/compilers/alpha-linux-gnu/glibc/alpha-linux-gnu/intl/plural.c
>>>>
>>>>
>>>> -c -std=gnu11 -fgnu89-inline -O2 -Wall -Werror -Wundef -Wwrite-strings
>>>> -fmerge-all-constants -fno-stack-protector -frounding-math -g
>>>> -Wstrict-prototypes -Wold-style-definition -fno-math-errno
>>>> -mlong-double-128 -mieee -mfp-rounding-mode=d
>>>> -ftls-model=initial-exec
>>>> -I../include
>>>> -I/scratch/jmyers/glibc/many9/build/compilers/alpha-linux-gnu/glibc/alpha-linux-gnu/intl
>>>>
>>>>
>>>> -I/scratch/jmyers/glibc/many9/build/compilers/alpha-linux-gnu/glibc/alpha-linux-gnu
>>>>
>>>>
>>>> -I../sysdeps/unix/sysv/linux/alpha/alpha
>>>> -I../sysdeps/unix/sysv/linux/alpha/fpu -I../sysdeps/alpha/fpu
>>>> -I../sysdeps/unix/sysv/linux/alpha -I../sysdeps/alpha/nptl
>>>> -I../sysdeps/unix/sysv/linux/wordsize-64
>>>> -I../sysdeps/ieee754/ldbl-64-128
>>>> -I../sysdeps/ieee754/ldbl-opt -I../sysdeps/unix/sysv/linux/include
>>>> -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread
>>>> -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
>>>> -I../sysdeps/unix/alpha -I../sysdeps/unix -I../sysdeps/posix
>>>> -I../sysdeps/alpha -I../sysdeps/wordsize-64
>>>> -I../sysdeps/ieee754/ldbl-128 -I../sysdeps/ieee754/dbl-64/wordsize-64
>>>> -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32
>>>> -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I.
>>>> -D_LIBC_REENTRANT -include
>>>> /scratch/jmyers/glibc/many9/build/compilers/alpha-linux-gnu/glibc/alpha-linux-gnu/libc-modules.h
>>>>
>>>>
>>>> -DMODULE_NAME=libc -include ../include/libc-symbols.h
>>>> -DTOP_NAMESPACE=glibc -D'LOCALEDIR="/usr/share/locale"'
>>>> -D'LOCALE_ALIAS_PATH="/usr/share/locale"' -o
>>>> /scratch/jmyers/glibc/many9/build/compilers/alpha-linux-gnu/glibc/alpha-linux-gnu/intl/plural.o
>>>>
>>>>
>>>> -MD -MP -MF
>>>> /scratch/jmyers/glibc/many9/build/compilers/alpha-linux-gnu/glibc/alpha-linux-gnu/intl/plural.o.dt
>>>>
>>>>
>>>> -MT
>>>> /scratch/jmyers/glibc/many9/build/compilers/alpha-linux-gnu/glibc/alpha-linux-gnu/intl/plural.o
>>>>
>>>>
>>>>
>>>
>>> Thanks. I don't see anything obviously wrong but I don't know
>>> much about Alpha assembly. Attached are the two .s files, with
>>> (plural-new.s) and without (plural-old.s) the array-to-string
>>> transformation.
>> I'd focus on these insns which correspond to the error from the linker:
>>
>> They're in plural.o within the fucntion gettextparse
>>
>>
>> ldah $2,yypgoto+2305843009213693936($29)
>> !gprelhigh
>>
>> Something certainly doesn't look right...
>
> Thanks. I also get the same exact same assembly with both
> forms of initializers for the two constant arrays, i.e.,
>
> static const yytype_int8 yypgoto[3] = "\366\366\377";
> static const yytype_int8 yydefgoto[3] = "\377\005\006";
>
> and
>
> static const yytype_int8 yypgoto[] = { -10, -10, -1 };
> static const yytype_int8 yydefgoto[] = { -1, 5, 6 };
>
> They end up in the .sdata section either way (the former
> both with and without the GCC change as might be expected):
>
> .section .sdata,"aws"
> .type yydefgoto, @object
> .size yydefgoto, 3
> yydefgoto:
> .ascii "\377\005\006"
> .type yypgoto, @object
> .size yypgoto, 3
> yypgoto:
> .ascii "\366\366\377"
> .section .rodata
>
> and also before the GCC change:
>
> .section .sdata,"aws"
> .type yydefgoto, @object
> .size yydefgoto, 3
> yydefgoto:
> .byte -1
> .byte 5
> .byte 6
> .type yypgoto, @object
> .size yypgoto, 3
> yypgoto:
> .byte -10
> .byte -10
> .byte -1
>
>> At the .o level this turns into:
>> 218: 00 00 5d 24 ldah t1,0(gp)
>> 218: GPRELHIGH .sdata+0x1ffffffffffffff3
>>
>>
>> 300: 00 00 5d 24 ldah t1,0(gp)
>> 300: GPRELHIGH .sdata+0x1ffffffffffffff3
>>
>> It's not really a matter of what the instruction does, but a matter of
>> the relocation. You'd have to look at the definition of GPRELHIGH which
>> you can find in BFD.
>
> The definitions match the assembly with both kinds of
> initializers, and with the string literal also with GCC before
> the change:
>
> 0000000000000218 GPRELHIGH .sdata+0x1ffffffffffffff3
> 0000000000000238 GPRELLOW .sdata+0x1ffffffffffffff3
> 0000000000000300 GPRELHIGH .sdata+0x1ffffffffffffff3
> 0000000000000308 GPRELLOW .sdata+0x1ffffffffffffff3
> 0000000000000458 GPRELHIGH .sdata+0x0000000000000003
> 0000000000000468 GPRELLOW .sdata+0x0000000000000003
>
> vs the array form before the GCC change:
>
> 0000000000000468 GPRELHIGH .sdata+0x0000000000000003
> 0000000000000488 GPRELLOW .sdata+0x0000000000000003
> 000000000000057c GPRELHIGH .sdata
> 0000000000000580 GPRELLOW .sdata
>
> So it seems as though using the string literal as an initializer
> tickles a latent bug in GCC and the question is where.
I'd start working backwards from alpha_print_operand_address using a
cross compiler. I'd also get a -dap dump and look at the actual address
in the insn that's emitting the offending ldah instructions.
Jeff
