[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: DAC960 and GCC

What do you mean by removing -O2?
I am trying to compile a DAC960 on a Alpha and I am running into this same


AJ Schroeder

-----Original Message-----
From: Wakko Warner [mailto:wakko@animx.eu.org] 
Sent: Friday, January 25, 2002 3:17 PM
To: Christopher C. Chimelis
Cc: debian-alpha@lists.debian.org
Subject: Re: DAC960 and GCC

> > There's no gcc in debian that will compile the DAC960 module on my 
> > alpha noritake system (as1000a)  gcc-3.0 doesn't compile 2.4.17 
> > right, gcc 2.95.4 bombs with an error compiling the module, and gcc 
> > 2.95.2 (debian potato) just eats all memory and bomb compiling that 
> > module.
> This is an old problem, but one that was unfortunately never fixed.  
> Can you try compiling it without optimisation?  IIRC, it still won't 
> compile, but it may be worth checking again.

Actually, it did compile when I removed -O2.  I haven't tried it yet

What kind of performance hit will happen with -O2 removed?

> > Someone running rh 7.1 and gcc 2.96 was able to compile a kernel for 
> > me and it's working great.
> DAC960's are strange beasts in some Alphas (only certain firmware revs 
> work and they're not easily upgradable since the flash chips are hard 
> to find now), so I personally never saw a great need to bump it up on 
> my list of things to look into.  Plus, I don't have a DAC960 to test 
> with anyway, so I couldn't verify anything other than the "it compiles 
> now" type of results.

On my alpha, I have firmare 2.70 (I modded the module the other guy compiled
for me so it would work.  thankfully it was just a string I changed from
2.73 to 2.00) and it works w/o any problems.  9.89mb/sec read from a raid0
of 3 2gb disks.

A friend of mine on a SMP pc is running the same card (nec branded firmware)
with firmware 2.39 and is getting speeds about 2mb slower than me but he's
using a raid 5 on 4 4gb disks

> > Why is there no gcc 2.96 for alpha (or for that matter, no other 
> > arch than
> > ia64)
> Because it's an abomination unto the GNU.  Just kidding.  RedHat 
> "fathered" 2.96; it was never an official GNU release.  In the 
> beginning of 2.96, it had some major problems with it and it would've 
> been impossible to turn to the main GCC folks to fix those problems 
> since they didn't sanction the release (and they had made enough 
> changes to the CVS tree since RH found a snapshot that they could call 
> "2.96" that they couldn't easily backport many of the changes).  So, 
> that means that, if we needed to file bugs, we'd have to rely on 
> RedHat as our "support".  I don't know about you, but I wouldn't 
> consider having Debian rely on RedHat support for something as 
> important as the toolchain :-P
> In the IA-64 case, though, it's a little different.  Until 3.1 comes 
> out, I don't think IA-64 support in even the 3.x series is fantastic.  
> Most of the work that is being done is being done in either gcc 
> mainline CVS (which we don't want to package for main Debian use for a 
> number of
> reasons) or against the 2.96 sources that were released by RedHat and
> affiliates.  I wasn't in on the decision-making process with IA-64, but I
> can agree with their choice as far as that goes even in hindsight.  The
> platform is new enough that a working toolchain is needed...doesn't matter
> where it comes from yet.  Once the GCC make an official release that works
> well on IA-64, I have no doubts that they'll be switching over to an
> official release for their default compiler.

what about gcc 3.0?  It doesn't work well on my alpha, but is it not

 Lab tests show that use of micro$oft causes cancer in lab animals

To UNSUBSCRIBE, email to debian-alpha-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact

Reply to: