Re: RFA: Darwin x86 alignment

2005-07-23 Thread Dale Johannesen
On Jul 23, 2005, at 6:40 AM, Tobias Schlüter wrote: I have a strong suspicion there is a reason why the two are linked, and that that reason is FORTRAN. A lot of FORTRAN code assumes EQUIVALENCE of floating-point and integer types of equal size. Such code will in all likelyhood break if those

Re: RFA: Darwin x86 alignment

2005-07-23 Thread Tobias Schlüter
Mark Kettenis wrote: >From: Dale Johannesen <[EMAIL PROTECTED]> >Date: Thu, 21 Jul 2005 16:56:01 -0700 > >On x86 currently the alignments of double and long long are linked: >they are either 4 or 8 depending on whether -malign-double is set. >This follows the documentation of -

Re: RFA: Darwin x86 alignment

2005-07-23 Thread Mark Kettenis
From: Dale Johannesen <[EMAIL PROTECTED]> Date: Thu, 21 Jul 2005 16:56:01 -0700 On x86 currently the alignments of double and long long are linked: they are either 4 or 8 depending on whether -malign-double is set. This follows the documentation of -malign-double. But it's wrong fo

Re: RFA: Darwin x86 alignment

2005-07-21 Thread Richard Henderson
On Thu, Jul 21, 2005 at 05:21:58PM -0700, Dale Johannesen wrote: > >Nah, you just remove it from target_flags, and control the two > >new variables from ix86_handle_option. > > OK. Think that's the better approach? *shrug* It's not horrible, I guess. It preseves existing semantics when people

Re: RFA: Darwin x86 alignment

2005-07-21 Thread Dale Johannesen
On Jul 21, 2005, at 5:00 PM, Richard Henderson wrote: On Thu, Jul 21, 2005 at 04:56:01PM -0700, Dale Johannesen wrote: - Have flags work as now: -malign-double makes both 8, -mno-align-double makes both 4. Problem with that is the default is neither of these, and this doesn't fit neatly

Re: RFA: Darwin x86 alignment

2005-07-21 Thread Richard Henderson
On Thu, Jul 21, 2005 at 04:56:01PM -0700, Dale Johannesen wrote: > - Have flags work as now: -malign-double makes both 8, > -mno-align-double > makes both 4. Problem with that is the default is neither of these, > and > this doesn't fit neatly into gcc's model of two-valued flags; it's > a