Re: GCC problem, take two

On Wed, Jan 29, 2003 at 10:04:44AM -0500, Tom 'spot' Callaway wrote:
> On Wed, 2003-01-29 at 09:45, T. Ribbrock wrote:

> > With the installer - booted straight from CD-ROM.
> 
> Good to know that worked. :)

Yup! First time ever I ran an update with either RH or Aurora - I
usually install from scratch...


[...]
> More than likely, this is what happened.
> 
> 0.4 didn't install gcc-sparc32 (gcc-c++-sparc32, etc). Bug was fixed in
> 1.0's comps...
> ...but when you did an upgrade, 1.0 said "gcc-*sparc32* wasn't installed
> before, i don't need to install it now" I probably should have made it
> dep on that in the packages themselves.
> 
> To the best of my knowledge, the gcc-*sparc32* packages provide the
> sparc32 optimizations, which is why it fails building things with high
> optimization (e.g. crypto). It probably should always be present though,
> even though its technically optional.

Whoa there, it's "Thomas-is-confused-time" again... %-/

Ok, I'll list the facts the way I understand them at the moment:

- default gcc is 64bit, even on sparc32. I'll call it 'gcc-sparc64'
  henceforth.
- default gcc fails with certain files when using optimization - on
  both sparc32 and sparc64 (at least it did so in my tests - as far as
  I can see, gcc hasn't changed between 0.42 and 1.0, hence, I'll
  group the two tests on the U5 and SS20 together)
- you say that gcc-sparc32 should always be installed, even though
  it's "technically optional" (isn't that an oxymoron? ;-) )
- Jakub contradicts this and points to memory issues

Am I missing anything here?


In any case, the above leads me to the following questions/conclusions:

- Conclusion: The gcc-sparc64 included in Aurora has a bug. At least
  to me as a layman[0] gobbling up 1.5GB of (virtual) memory for a compile
  (which doesn't even finish) looks like a bug. The bug is
  optimization related and seemingly known, hence, I assume it's not
  an easy to fix bug.
  Sidenote: A quick search on mutt-user didn't bring up anything
  related. A google search brought up this:
  http://gcc.gnu.org/ml/gcc-bugs/1999-11n/msg00895.html
  which is on Solaris/Sparc
  
- Question: Why is gcc-sparc64 the default on 32bit Sparcs?

- Question: Am I right if I say that the "split" between 32bit and
  64bit gcc is a new thing when compared to RH 6.2? I'm asking 'cause
  I was able to compile the same SRPM (i.e. same mutt code) on an LX
  running RHL 6.2 with no problems.
  
- Question: Are these issues sparc-specific? At least I've never heard
  of any such problems on ix86...

Ok, that's all I can think of right now, so I'll shut up... :-}

Cheerio,

Thomas

[0] well, maybe better "to me as a test engineer"... ;-)
-- 
-----------------------------------------------------------------------------
                Thomas Ribbrock    http://www.ribbrock.org 
  "You have to live on the edge of reality - to make your dreams come true!"