PATCH: PR target/35657: TDmode isn't aligned at 128bit when passing to a function

[H.J. Lu]

On Thu, Mar 27, 2008 at 9:47 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Thu, Mar 27, 2008 at 7:02 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>  >
>  > On Thu, Mar 27, 2008 at 2:33 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>  >
>  >  >  Decimal floating point isn't covered by the ia32 psABI. Gcc is the
>  >  >  first compiler
>  >  >  which implements DFP on ia32 and is defining the de facto DFP psABI. I don't
>  >  >  see a reason not to align them to their natural boundary when passing them
>  >  >  on stack. I'd like to install it on trunk and 4.3.1.
>  >
>  >  I assume that DFP passing will be specified in the next revision of psABI.
>  >
>  >  The patch is OK for mainline, but please revert runtime part of my
>  >  previous patch [1][2] that forced unaligned moves when TDmode (TImode)
>  >  values were moved to/from the stack. There is no need for this
>  >  functionality, once TDmode values are aligned to their natural
>  >  boundaries.
>  >
>  >  Also, please re-test your change (with my patch reverted) with
>  >  "--with-arch=core2" configured compiler, to check if problems [3]
>  >  resurfaced.
>  >
>  >  Regarding 4.3.1 support - since this is an ABI change w.r.t released
>  >  compiler, RMs should have their last word. IMO, at least a notice in
>  >  release notes is needed
>  >
>  >  Thanks,
>  >  Uros.
>  >
>  >  [1] http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01716.html
>  >  [2] http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01863.html
>  >  [3] http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01171.html
>  >
>
>  Hi,
>
>  I am testing this patch to revert TDmode unaligned memory check.
>  I applied it to trunk without my DFP alignment patch and configure gcc
>  with --with-arch=core2. I should get some DFP failures in 32bit. I will
>  then add my patch and re-run "make check". If all DFP failures are
>  gone, I will apply 2 patches to trunk first.
>

Here is the result of reverting DFP unaligned check:

http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg02123.html

Here is the result of reverting DFP unaligned check + my DFP alignment
patch:

http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg02125.html

Reverting DFP unaligned check + my DFP alignment patch has following
regressions:

Running target unix/-m32
FAIL: tmpdir-gcc.dg-struct-layout-1/t015
c_compat_x_tst.o-c_compat_y_tst.o execute
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/t026
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

Gcc 4.3 with reverting DFP unaligned check + my DFP alignment
patch show the similar result:

http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg02126.html

The problem is those tests define

typedef _Decimal128 Tal1Decimal128 __attribute__((aligned (1)));

That is TImode may be unaligned. We still need to check unaligned
TImode. In fact,
we should see extra failures in 64bit when unaligned _Decimal128 is
passed on stack:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32000

But our testsuite doesn't check it.

I am checking only my patch into trunk/4.3 without reverting DFP
unaligned check.

Thanks.

H.J.