My desire is NOT to remain rooted in the past. Hence my interest in changing my code to meet the compiler of today.
If I'm killing the 3.x compiler with code that 2.96 accepted, it ought to be from well-known (by now) reasons like
(I'm making this up for an example)
"memset used to be a routine but now it is a macro ..:. don't give it macro parameters."
Known problem and solution:
We use a message that is a union comprising a char MsgIdT and the 117 message structures, (each of which has a char MsgIdT as the first element); we had a null message number macro #define MSG_NULL ((MsgIdT)0) under 2.96 we could allocate a message union, and initialize it with union msgstructT msg = {MSG_NULL}; // the 3.x compiler barfs on this so now we say union msgstructT msg = {0}; // the 3.x compiler is happy with this.
Why the compiler decided we can't initialize an auto union with a type-cast scalar when we used to do so with no problem *should* have been recorded somewhere, if so, that document *should* give me other clues about what's making the 3.x compiler barf on this 2.96-happy code.
Brian Brunner brian.t.brunner@gai-tronics.com (610)796-5838
mike.mccarty@sbcglobal.net 09/19/05 05:39PM >>>
Brian T. Brunner wrote:
Currently we have RH7.3 with compiler gcc 2.96.x
My mission, should I choose to accept it, involves moving our embedded application to CentOS 4.1 with gcc 3.x
Problem is that about 1/2 million lines of code that gcc 2.96 accepts gives fatal fits to the gcc 3.x compiler from CentOS 4.1
I don't know how many fatal fits, as some disguise others etc. "Can't find register to spill" is a common exit-barf from gcc 3.x.
Frankly, that sounds like an internal error in the compiler. Either the register allocater, the temporary creator, or the register spiller seems to be failing to do its job.
This does not appear to me to be a porting problem, but a defective compiler. Is there any reason you must use the later compiler?
[snip]
Mike