This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: sparc vs lapack


  In message <19990714150355.15728.qmail@deer>you write:
  > >Agreed.  But the support for __complex__ is badly broken, even for simple
  > >stuff.  In a nutshell, it falls on its face anytime one tries to get the
  > >components out of a hard register that is wider than the component.
  > 
  > I'm still wondering how those components got *in* that hard register.  ;-)
Presumably argument setup for the statement function.  Remember, if it looks
like a function call at the tree level, it's going to be expanded via the 
normal
function call mechanisms, which include copying of arguments into hard 
registers
on targets which pass parameters in registers.

  > >  b. Not change the default and abort if the compiler detects an access to
  > >     the high part of complex value in a hard register.

  > I prefer the latter, but don't understand the issues (especially the
  > implementation) well enough to have a clear picture of the various
  > risks.
Risk for this is very low.  All access to complex values runs through two
special routines (gen_realpart, gen_imagpart) which have no other purpose.

For a WORDS_BIG_ENDIAN machine we would abort in gen_realpart if X was a
hard register and BITS_PER_WORD > # bits in MODE.

For !WORDS_BIT_ENDIAN we would abort in gen_imagpart under the same conditions.

I'm leaning strongly towards b.

About the only thing that would convince me to switch the default for 64bit
stuff at this point would be to see results that show -femulate-complex works
consistently better on 64bit targets.  So far I have not seen convincing
evidence of that either from testresults others have sent to this group or my
own testing.


  > I think the likely-case scenario, if we choose b), is that we abort only
  > on *some* codes, which we tell people to then try compiling with
  > -femulate-complex to see if that works.  (Can we put such a message
  > into the ICE itself?  Please?  Please?  ;-)
Not appropriate since the message would come out of the language independent
parts of the compiler and -femulate-complex is a language dependent option.
The message can certainly mention it's a problem with access to the real or
imaginary part of a complex type.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]