Re: guile loses on NetBSD/sparc64 1.6.2 with gcc 3.3.2

[Rob Browning]

address@hidden (Paul Jarc) writes:

> What sorts of changes would be needed to make -fno-strict-aliasing
> unnecessary?

Not sure offhand.  We're not likely worry about that in 1.6, but we
probably will in 1.7.  In general gcc will warn you about some of the
problems, but I'd presume that it can't detect all of them.

You may already be familiar with the general issue, but in case not,
the change is that gcc now follows the C standard more strictly by
default when optimizing, and so (if I have this right off the top of
my head) it's no longer safe to access data through any pointer that's
not of a type that's "compatible" with the type of the actual data,
i.e. given

  double x = 5;
  double *dptr = &x;
  int *iptr = (int *) &x;

  *iptr = 12;
  *dptr = 42;
  foo(x);

I believe the compiler is now within its rights to generate code that
re-orders the iptr and dptr assignments, leaving x with some value
other than 42 by the time foo is called.

That's because the optimizer is legally allowed to presume that
incompatible pointers do not alias the same memory locations, even if
they do.  Although I believe char* is at least one (maybe the only)
exception to this; according to the standard a char* must be presumed
to alias any location. Also, I think you may be able to use a union
safely as an alternative with gcc, but from what I recall, that's
non-standard.

With respect to guile, I'm not sure what, if anything, needs fixing in
1.7, but we'll need to check into it before we disable
-fno-strict-aliasing.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4