From: Richard Biener <rguenther@suse.de>
To: Alan Lawrence <alan.lawrence@arm.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
Marcus Shawcroft <Marcus.Shawcroft@arm.com>
Subject: Re: New regression on ARM Linux
Date: Mon, 30 Mar 2015 13:16:00 -0000 [thread overview]
Message-ID: <alpine.LSU.2.11.1503301509150.31545@zhemvz.fhfr.qr> (raw)
In-Reply-To: <alpine.LSU.2.11.1503301501070.31545@zhemvz.fhfr.qr>
On Mon, 30 Mar 2015, Richard Biener wrote:
> On Mon, 30 Mar 2015, Alan Lawrence wrote:
>
> > ...actually attach the testcase...
>
> What compile options?
Just tried -O2. The GIMPLE IL assumes 64bit alignment of .LC0 but
I can't see anything not guaranteeing that:
.section .rodata
.align 3
.LANCHOR0 = . + 0
.LC1:
.ascii "%d %g %d\012\000"
.space 6
.LC0:
.word 7
.space 4
.word 0
.word 1075838976
.word 9
.space 4
maybe there is some more generic code-gen bug for aligned aggregate
copy? That is, the patch tells the backend that the loads and
stores to the 'int' vars (which have padding followed) is aligned
to 8 bytes.
I don't see what is wrong in the final assembler, but maybe
some endian issue exists? The code looks quite ugly though ;)
Richard.
>
> > Alan Lawrence wrote:
> > > We've been seeing a bunch of new failures in the *libffi* testsuite on ARM
> > > Linux (arm-none-linux-gnueabi, arm-none-linux-gnueabihf), following this
> > > one-liner fix. I've reduced the testcase down to the attached (including
> > > removing any dependency on libffi); with gcc r221347, this prints the
> > > expected
> > > 7 8 9
> > > whereas with gcc r221348, instead it prints
> > > 0 8 0
> > >
> > > The action of r221348 is to change the alignment of a mem_ref, and a
> > > var_decl of b1, from 32 to 64; both have type
> > > type <record_type 0x2b9b8d428d20 cls_struct_16byte sizes-gimplified type_0
> > > BLK
> > > size <integer_cst 0x2b9b8d3720a8 constant 192>
> > > unit size <integer_cst 0x2b9b8d372078 constant 24>
> > > align 64 symtab 0 alias set 1 canonical type 0x2b9b8d428d20
> > > fields <field_decl 0x2b9b8d42b098 a type <integer_type
> > > 0x2b9b8d092690 int>
> > > SI file reduced.c line 12 col 7
> > > size <integer_cst 0x2b9b8d08eeb8 constant 32>
> > > unit size <integer_cst 0x2b9b8d08eed0 constant 4>
> > > align 32 offset_align 64
> > > offset <integer_cst 0x2b9b8d08eee8 constant 0>
> > > bit offset <integer_cst 0x2b9b8d08ef48 constant 0> context
> > > <record_type 0x2b9b8d428d20 cls_struct_16byte> chain <field_decl
> > > 0x2b9b8d42b130 b>> context <translation_unit_decl 0x2b9b8d4232d0 D.6070>
> > > pointer_to_this <pointer_type 0x2b9b8d42d0a8> chain <type_decl
> > > 0x2b9b8d42b000 D.6044>>
> > >
> > > The tree-optimized output is the same with both compilers (as this does not
> > > mention alignment); the expand output differs.
> > >
> > > Still investigating...
> > >
> > > --Alan
> > >
> > >
> > > Richard Biener wrote:
> > > > This fixes a vectorizer testcase regression on powerpc where SRA
> > > > drops alignment info unnecessarily.
> > > >
> > > > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
> > > >
> > > > Richard.
> > > >
> > > > 2015-03-11 Richard Biener <rguenther@suse.de>
> > > >
> > > > PR tree-optimization/65310
> > > > * tree-sra.c (build_ref_for_offset): Also preserve larger
> > > > alignment.
> > > >
> > > > Index: gcc/tree-sra.c
> > > > ===================================================================
> > > > --- gcc/tree-sra.c (revision 221324)
> > > > +++ gcc/tree-sra.c (working copy)
> > > > @@ -1597,7 +1597,7 @@ build_ref_for_offset (location_t loc, tr
> > > > misalign = (misalign + offset) & (align - 1);
> > > > if (misalign != 0)
> > > > align = (misalign & -misalign);
> > > > - if (align < TYPE_ALIGN (exp_type))
> > > > + if (align != TYPE_ALIGN (exp_type))
> > > > exp_type = build_aligned_type (exp_type, align);
> > > > mem_ref = fold_build2_loc (loc, MEM_REF, exp_type, base, off);
> > > >
> > > >
> > >
> > >
> >
> >
> >
> >
>
>
--
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild,
Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg)
next prev parent reply other threads:[~2015-03-30 13:16 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-11 15:09 [PATCH] Fix regression caused by PR65310 fix Richard Biener
2015-03-30 12:15 ` New regression on ARM Linux (was: Re: [PATCH] Fix regression caused by PR65310 fix) Alan Lawrence
2015-03-30 12:18 ` New regression on ARM Linux Alan Lawrence
2015-03-30 13:01 ` Richard Biener
2015-03-30 13:16 ` Richard Biener [this message]
2015-03-30 16:45 ` Alan Lawrence
2015-03-30 20:13 ` Richard Biener
2015-03-31 7:50 ` Richard Biener
2015-03-31 9:43 ` Richard Earnshaw
2015-03-31 10:00 ` Richard Biener
2015-03-31 10:10 ` Richard Earnshaw
2015-03-31 10:32 ` Jakub Jelinek
2015-03-31 10:36 ` Richard Biener
2015-03-31 10:40 ` Richard Earnshaw
2015-03-31 10:45 ` Richard Biener
2015-03-31 10:51 ` Richard Earnshaw
2015-03-31 11:09 ` Richard Biener
2015-03-31 12:15 ` Richard Earnshaw
2015-03-31 12:11 ` Alan Lawrence
2015-03-31 10:47 ` Alan Lawrence
2015-03-31 11:05 ` Richard Biener
2015-03-31 11:07 ` Jakub Jelinek
2015-03-31 11:11 ` Richard Biener
2015-03-31 13:11 ` Alan Lawrence
2015-03-31 13:25 ` Richard Biener
2015-04-02 14:59 ` Alan Lawrence
2015-03-31 10:20 ` Richard Biener
2015-03-31 10:31 ` Richard Earnshaw
2015-03-31 10:45 ` Richard Biener
2015-03-31 10:53 ` Richard Earnshaw
2015-03-31 9:50 ` Alan Lawrence
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=alpine.LSU.2.11.1503301509150.31545@zhemvz.fhfr.qr \
--to=rguenther@suse.de \
--cc=Marcus.Shawcroft@arm.com \
--cc=alan.lawrence@arm.com \
--cc=gcc-patches@gcc.gnu.org \
/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).