Bug 32000 - x86 backend uses aligned load on unaligned memory
Summary: x86 backend uses aligned load on unaligned memory
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: 4.4.0
Assignee: Not yet assigned to anyone
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords: wrong-code
Depends on:
Blocks: 35767
  Show dependency treegraph
 
Reported: 2007-05-19 09:40 UTC by rsandifo@gcc.gnu.org
Modified: 2008-05-28 16:58 UTC (History)
2 users (show)

See Also:
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
Known to work: 4.4.0
Known to fail: 4.3.0
Last reconfirmed: 2008-05-28 13:32:56


Attachments
Reduced testcase (214 bytes, text/plain)
2007-05-19 09:41 UTC, rsandifo@gcc.gnu.org
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rsandifo@gcc.gnu.org 2007-05-19 09:40:58 UTC
Running struct-layout-1.exp with CFLAGS_FOR_TARGET=-O2 produces:

FAIL: tmpdir-gcc.dg-struct-layout-1/t022 c_compat_x_tst.o-c_compat_y_tst.o execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t023 c_compat_x_tst.o-c_compat_y_tst.o execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t024 c_compat_x_tst.o-c_compat_y_tst.o execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o-c_compat_y_tst.o execute

I think the problem is with 128-bit packed quantities being passed
at unaligned addresses on the stack, but still being accessed using
aligned SSE operations.  A simple reduced testcase is attached;
it passes with -O0 and fails with -O and -O2.
Comment 1 rsandifo@gcc.gnu.org 2007-05-19 09:41:26 UTC
Created attachment 13583 [details]
Reduced testcase
Comment 2 H.J. Lu 2008-03-25 14:53:22 UTC
I think gcc should issue an error for

typedef struct { _Decimal128 f __attribute__((packed)); } packed;
typedef struct { __m128 f __attribute__((packed)); } packed;

when there is a hardware alignment requirement on a field to be
packed.
Comment 3 pinskia@gmail.com 2008-03-25 15:20:13 UTC
Subject: Re:  struct-layout-1.exp fails at -O2

No the compiler should be able to load the packed struct no matter  
what. If that means doing byte by byte loads then so be it.
-- Pinski

Sent from my iPhone

On Mar 25, 2008, at 7:53, "hjl dot tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org 
 > wrote:

>
>
> ------- Comment #2 from hjl dot tools at gmail dot com  2008-03-25  
> 14:53 -------
> I think gcc should issue an error for
>
> typedef struct { _Decimal128 f __attribute__((packed)); } packed;
> typedef struct { __m128 f __attribute__((packed)); } packed;
>
> when there is a hardware alignment requirement on a field to be
> packed.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32000
>
Comment 4 H.J. Lu 2008-03-25 21:52:34 UTC
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01536.html
Comment 5 H.J. Lu 2008-03-30 21:28:54 UTC
The updated patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01916.html
Comment 6 hjl@gcc.gnu.org 2008-03-31 13:33:20 UTC
Subject: Bug 32000

Author: hjl
Date: Mon Mar 31 13:32:38 2008
New Revision: 133753

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133753
Log:
gcc/

2008-03-31  H.J. Lu  <hongjiu.lu@intel.com>

	PR target/32000
	* config/i386/i386.md (*movti_internal): Emit unaligned SSE
	load/store if memory is unaligned.
	(*movti_rex64): Likewise.

	* config/i386/predicates.md (misaligned_operand): New.

gcc/testsuite/

2008-03-31  H.J. Lu  <hongjiu.lu@intel.com>

	PR target/32000
	* gcc.target/i386/pr32000-1.c: New.

Added:
    trunk/gcc/testsuite/gcc.target/i386/pr32000-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.md
    trunk/gcc/config/i386/predicates.md
    trunk/gcc/testsuite/ChangeLog

Comment 7 Uroš Bizjak 2008-05-28 05:45:44 UTC
Fixed?
Comment 8 H.J. Lu 2008-05-28 13:32:56 UTC
(In reply to comment #7)
> Fixed?
> 

The bug report was opened against gcc 4.3. To fix it in 4.3, we need to
backport the fix from trunk.
Comment 9 Andrew Pinski 2008-05-28 16:58:59 UTC
Not a regression so closing as fixed.