On Mon, Jul 20, 2009 at 7:02 PM, David T. Lewislewis@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],