From: Jeff Law <law@redhat.com>
To: Martin Sebor <msebor@gmail.com>, Joseph Myers <joseph@codesourcery.com>
Cc: James Greenhalgh <James.Greenhalgh@arm.com>,
Jason Merrill <jason@redhat.com>,
Gcc Patch List <gcc-patches@gcc.gnu.org>, nd <nd@arm.com>
Subject: Re: [PATCH] convert braced initializers to strings (PR 71625)
Date: Wed, 15 Aug 2018 21:14:00 -0000 [thread overview]
Message-ID: <747782e0-9ca0-e4e9-6f5c-969fc21dc4dd@redhat.com> (raw)
In-Reply-To: <411acfaa-7015-bdf4-43c1-84096009817c@gmail.com>
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.
>
> There are also only a handful of transformed arrays in the file
> and they all look reasonable to me (see the attachment named
> plural-array-to-string.txt). The only arrays in the .sdata
> section are yydefgoto and yypgoto, both before and after.
> They are each just 3 bytes in size.
>
> There is one unusual difference in the loads of one of them in
> the assembly emitted by GCC for __gettextparse.
>
> Before:
>
> Â Â Â Â ldah $22,yypgoto($29)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â !gprelhigh
> Â Â Â Â ...
> Â Â Â Â lda $2,yypgoto($22)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â !gprellow
>
> After:
>
> Â Â Â Â ldah $2,yypgoto+2305843009213693936($29)Â Â Â !gprelhigh
> Â Â Â Â ...
> Â Â Â Â lda $2,yypgoto+2305843009213693936($2)Â Â Â Â Â Â Â !gprellow
>
> I don't know if it's significant -- the lda instruction uses
> just the least significant 16 bits of the constant displacement,
> shifted left by 16. I don't see any obviously bogus constants
> in the disassembly produced by objdump.
>
> I'll need some help from someone who knows more about Alpha
> to understand what's going on.
I wonder if the change to how we set up the initializers is ultimately
changing the section those go into and ultimately causing an overflow of
the .sdata section.
Jeff
>
> Martin
next prev parent reply other threads:[~2018-08-15 21:14 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-30 23:51 Martin Sebor
2018-07-31 13:39 ` Jason Merrill
2018-07-31 14:49 ` Martin Sebor
2018-08-07 8:58 ` Jason Merrill
2018-08-07 23:04 ` Martin Sebor
2018-08-08 11:09 ` Jason Merrill
2018-08-09 0:17 ` Martin Sebor
2018-08-09 22:07 ` Joseph Myers
2018-08-13 10:36 ` Jason Merrill
2018-08-14 13:27 ` James Greenhalgh
2018-08-14 15:08 ` Martin Sebor
2018-08-14 15:24 ` Martin Sebor
2018-08-15 2:34 ` Martin Sebor
2018-08-15 10:29 ` James Greenhalgh
2018-08-15 15:04 ` Richard Biener
2018-08-15 15:51 ` Martin Sebor
2018-08-17 17:19 ` [PATCH] Fix poly types after PR tree-optimization/71625 strlen optimization Szabolcs Nagy
2018-08-17 17:22 ` Kyrill Tkachov
2018-08-14 21:14 ` [PATCH] convert braced initializers to strings (PR 71625) Joseph Myers
2018-08-14 22:18 ` Martin Sebor
2018-08-15 12:07 ` Joseph Myers
2018-08-15 21:02 ` Martin Sebor
2018-08-15 21:14 ` Jeff Law [this message]
2018-08-15 21:34 ` Jeff Law
2018-08-16 15:23 ` Martin Sebor
2018-08-16 15:32 ` Jeff Law
2018-08-06 16:41 ` Martin Sebor
2018-08-06 17:04 ` Joseph Myers
2018-08-07 2:02 ` Martin Sebor
2018-08-07 11:31 ` Joseph Myers
2018-08-07 23:05 ` Martin Sebor
2018-08-08 17:33 Bernd Edlinger
2018-08-08 18:34 ` Bernd Edlinger
2018-08-08 19:50 ` Martin Sebor
2018-08-08 20:35 ` Bernd Edlinger
2018-08-08 20:48 ` Joseph Myers
2018-08-09 0:23 ` Martin Sebor
2018-08-09 10:47 ` Joseph Myers
2018-08-16 6:37 Bernd Edlinger
2018-08-17 22:26 ` Bernd Edlinger
2018-08-18 4:13 ` Jeff Law
2018-08-18 10:40 ` Richard Sandiford
2018-08-18 14:25 ` Bernd Edlinger
2018-08-18 16:46 ` Richard Sandiford
2018-08-18 17:09 ` Bernd Edlinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=747782e0-9ca0-e4e9-6f5c-969fc21dc4dd@redhat.com \
--to=law@redhat.com \
--cc=James.Greenhalgh@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
--cc=joseph@codesourcery.com \
--cc=msebor@gmail.com \
--cc=nd@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).