[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