Re: Fix for PRs 36043, 58744 and 65408

[Richard Biener <richard.guenther@gmail.com>]

On Mon, Apr 13, 2015 at 6:48 AM, Alan Modra <amodra@gmail.com> wrote:
> 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?

Yes.

Thanks,
Richard.

> --
> Alan Modra
> Australia Development Lab, IBM