This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: PR target/35657: TDmode isn't aligned at 128bit when passing to a function
On Thu, Mar 27, 2008 at 9:47 AM, H.J. Lu <email@example.com> wrote:
> On Thu, Mar 27, 2008 at 7:02 AM, Uros Bizjak <firstname.lastname@example.org> wrote:
> > On Thu, Mar 27, 2008 at 2:33 PM, H.J. Lu <email@example.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  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 
> > 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.
> >  http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01716.html
> >  http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01863.html
> >  http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01171.html
> 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:
Here is the result of reverting DFP unaligned check + my DFP alignment
Reverting DFP unaligned check + my DFP alignment patch has following
Running target unix/-m32
Gcc 4.3 with reverting DFP unaligned check + my DFP alignment
patch show the similar result:
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:
But our testsuite doesn't check it.
I am checking only my patch into trunk/4.3 without reverting DFP