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.
Martin
