aliasing problem with va_arg

[Jeffrey A Law]

  In message < 199810262036.MAA12026@rtl.cygnus.com >you write:
  > 	Right, as per our discussion on Tuesday.  Is it really as hard as you
  > 	say to do this?  This is clearly the right fix.  For now, we don't
  > 	have to give good alias sets to the things we're loading; just 0 will
  > 	do for safety sake.
  > 
  > It shouldn't be hard for most targets.  Primarily it will be time consuming
  > ,
  > because there are 30 different ports that will need to be fixed.  I'd rathe
  > r
  > see them all fixed than to just fix a few, because if we don't fix them
  > all now, we probably never will, and that could lead to long term maintenan
  > ce
  > problems.
  > 
  > There are a few targets where making the change will be hard.  The MIPS
  > for instance supports many different macros, big endian vs little endian,
  > hard-float vs soft-float, 32 bit vs 64 bit, plus the effects of supporting
  > multiple ABIs (o32, n32, n64, EABI).  I'd expect it to get a little tricky
  > to get them all right.
  > 
  > 	How hard would fixing the macros be?  Would you mind sending me the
  > 	preprocessed sun-solaris2 source for your example, so that I could
  > 	look at it with a cross-compiler?
  > 
  > I didn't even think of fixing va-sparc.h.  I just assumed it couldn't be.
  > It is possible that we might be able to do something there.
One possibility would be to have the va_arg macro expand in the normal fashion,
but also emit something similar to __builtin_saveregs -- ie a marker to
indicate that we're accessing stuff on a varargs list.

When we see the marker we turn off type based alias analysis, or just generate
alias set zero for all mems.

We then have a different marker emitted by va_end which returns us to normal
behavior.

That's easier than fixing the varargs stuff to work strictly with builtins. 

We could even have the builtins be named __builtin_va_arg (ap, type) and
__builtin_va_end (ap) as a step towards actually implementing them as builtins.

jeff