[Vm-dev] patch: fix double alignment detection on Solaris/SPARC
with gcc-4.4.x
David T. Lewis
lewis at mail.msen.com
Fri Jul 31 02:47:47 UTC 2009
Excellent, thanks for the follow up Andrew.
Ian,
There is a patch for platforms/unix/config/acinclude.m4 at the end of this
email that addresses an issue for newer GCCs on SPARC. When you get a chance,
can you please update the acinclude.m4 and do a make configure?
Thanks,
Dave
On Thu, Jul 30, 2009 at 10:47:23PM +0200, Andrew Gaylard wrote:
>
> On Mon, Jul 20, 2009 at 7:02 PM, David T. Lewis<lewis at mail.msen.com> wrote:
> >
> > On Sat, Jul 18, 2009 at 05:25:48PM +0200, Andrew Gaylard wrote:
> >>
> >> The main issue that I'm facing at the moment is that gcc-4.4.0 generates
> >> code that causes unaligned accesses in fetchFloatAtinto; the same code
> >> works in gcc-4.2.4 on SPARC. ?Until I or someone else (hint!) fixes this,
> >> I'm continuing to build with gcc-4.2.4.
> >
> > fetchFloatAtInto() is implemented in platforms/Cross/vm/sqMemoryAccess.h
> > in the form of cpp macros. It might be tricky to debug this, but I note
> > that the implementation depends on DOUBLE_WORD_ALIGNMENT, which is a macro
> > that would have been set when you run configure. You might playing with
> > this setting to see if it gives you the results you want. For example, as
> > a complete SWAG, it might be the case that SPARC plus gcc-4.2.4 needs this
> > macro defined but for some reason configure is not setting it for you.
>
> David, thanks for the tip. This message from configure showed
> you are right (the 'yes' should be 'no'):
>
> checking whether unaligned access to doubles is ok... yes
>
> It turns out that newer GCCs, from 4.3.x onward, are smart
> enough to optimise out the code used to detect strict alignment:
>
> bash-3.2$ gcc -O2 double-test.c
> double-test.c: In function 'main':
> double-test.c:6: warning: passing argument 1 of 'f' makes integer from
> pointer without a cast
> double-test.c:1: note: expected 'int' but argument is of type 'char *'
> bash-3.2$ ./a.out
> bash-3.2$ echo $?
> 0
>
> But when compiling without optimisation:
>
> bash-3.2$ gcc double-test.c
> double-test.c: In function 'main':
> double-test.c:6: warning: passing argument 1 of 'f' makes integer from
> pointer without a cast
> double-test.c:1: note: expected 'int' but argument is of type 'char *'
> bash-3.2$ ./a.out
> Bus Error (core dumped)
>
> ... as expected.
>
> This patch complicates the code sufficiently (by using the results
> of the function) so that it triggers a bus error both with and without
> optimisation, as would be expected. Of course, configure needs
> to be regenerated after applying this patch.
>
> Running our internal benchmark reveals that it is worth it getting
> 4.4.1 to work:
>
> gcc-4.4.1:
>
> real 61m45.975s
> user 56m16.247s
> sys 4m57.253s
>
> gcc-4.2.4:
>
> real 67m29.260s
> user 61m40.666s
> sys 5m7.937s
>
> This means the VM is sped up by 9%.
>
> - Andrew
>
> --- Squeak-3.10-4/platforms/unix/config/acinclude.m4.orig
> 2008-09-02 20:49:43.000000000 +0200
> +++ Squeak-3.10-4/platforms/unix/config/acinclude.m4 2009-07-30
> 16:16:55.828929831 +0200
> @@ -230,10 +230,33 @@
>
>
> AC_DEFUN([AC_C_DOUBLE_ALIGNMENT],
> [AC_CACHE_CHECK([whether unaligned access to doubles is ok],
> ac_cv_double_align,
> - AC_TRY_RUN([f(int i){*(double *)i=*(double *)(i+4);}
> - int main(){char b[[12]];f(b);return 0;}],
> + AC_TRY_RUN([
> +
> +int f(void* i){
> + *(double *)i=*(double *)(i+4);
> + return *(char*)i;
> +}
> +int main(){
> + char b[[12]];
> + b[[0]]=1;
> + b[[1]]=2;
> + b[[2]]=3;
> + b[[3]]=4;
> + b[[4]]=0;
> + b[[5]]=0;
> + b[[6]]=0;
> + b[[7]]=0;
> + b[[8]]=0;
> + b[[9]]=0;
> + b[[10]]=0;
> + b[[11]]=0;
> +
> + return f(b);
> +}
> +],
> +
> ac_cv_double_align="yes", ac_cv_double_align="no"))
> test "$ac_cv_double_align" = "no" && AC_DEFINE(DOUBLE_WORD_ALIGNMENT)])
>
> AC_DEFUN([AC_C_DOUBLE_ORDER],
More information about the Vm-dev
mailing list