Re: Fix for PRs 36043, 58744 and 65408

[Alan Modra <amodra@gmail.com>]

On Wed, Mar 18, 2015 at 12:12:17PM +0100, Richard Biener wrote:
> On Wed, Mar 18, 2015 at 5:22 AM, Alan Modra <amodra@gmail.com> wrote:
> > On Tue, Mar 17, 2015 at 01:28:41PM -0600, Jeff Law wrote:
> >> On 03/14/2015 07:02 AM, Alan Modra wrote:
> >> >     PR target/65408
> >> >     PR target/58744
> >> >     PR middle-end/36043
> >> >     * calls.c (load_register_parameters): Don't load past end of
> >> >     mem unless suitably aligned.
> >> I think this is probably a stage1 item.  Richi, Jakub, Joseph, do any of you
> >> think we should try to push this into gcc-5?
> >
> > Some (severity) background to PR65408.  The bug came from SAP HANA
> > (en.wikipedia.org/wiki/SAP_HANA), a crash that happens on powerpc64
> > and powerpc64le.  aarch64 would also be susceptible to the crash since
> > it also loads 16 bytes for the 12-byte struct.  x86_64 only loads 12
> > bytes (i386.c:construct_container generates a parallel with a DImode
> > and SImode load).  However the underlying bug is there and hits x86_64
> > too for the pr58744 and pr36043 testcases..
> 
> It's a very very very old bug though.  I'd be interested in any odd
> code-generation difference for compiling, say, the linux kernel
> (you _can_ get quite ugly code generated because of this fix).

Yes, all those byte loads..  As far as the kernel goes, x86_64 shows
some differences in calls to rgb_{fore,back}ground in
drivers/tty/vt/vt.c.  Both before and after look ugly to me.  :)

    4d73:       8b 82 24 02 00 00       mov    0x224(%rdx),%eax
    4d79:       48 89 df                mov    %rbx,%rdi
    4d7c:       41 83 c4 04             add    $0x4,%r12d
    4d80:       88 45 b2                mov    %al,-0x4e(%rbp)
    4d83:       8b 82 28 02 00 00       mov    0x228(%rdx),%eax
    4d89:       88 45 b3                mov    %al,-0x4d(%rbp)
    4d8c:       8b 82 2c 02 00 00       mov    0x22c(%rdx),%eax
    4d92:       88 45 b4                mov    %al,-0x4c(%rbp)
    4d95:       48 8b 75 b2             mov    -0x4e(%rbp),%rsi
    4d99:       e8 00 00 00 00          callq  <rgb_background>
 vs.
    4d73:       8b 82 24 02 00 00       mov    0x224(%rdx),%eax
    4d79:       0f b6 b2 2c 02 00 00    movzbl 0x22c(%rdx),%esi
    4d80:       48 89 df                mov    %rbx,%rdi
    4d83:       41 83 c4 04             add    $0x4,%r12d
    4d87:       88 45 b2                mov    %al,-0x4e(%rbp)
    4d8a:       8b 82 28 02 00 00       mov    0x228(%rdx),%eax
    4d90:       48 c1 e6 10             shl    $0x10,%rsi
    4d94:       88 45 b3                mov    %al,-0x4d(%rbp)
    4d97:       0f b7 45 b2             movzwl -0x4e(%rbp),%eax
    4d9b:       48 09 c6                or     %rax,%rsi
    4d9e:       e8 00 00 00 00          callq  <rgb_background>

Is the patch OK for stage1?

-- 
Alan Modra
Australia Development Lab, IBM