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. What I'd like to find is a comparison of gcc 2.96.x to 3.x from the perspective of porting something from RH7.x to CentOS/RHEL 4.x What I did was make a fresh install of CentOS 4.1 and then load the source code for the application and try to make. What gcc 2.96 compiler assumed about the underlying OS, and what gcc 3.x assumes about the underlying OS, may be relatively skew. Whether any of the application code assumes a 2.96 set of assumptions, where this set of assumptions is broken under 3.x, is unknown (and is the kind of detail I'd like to see in the above-hinted-at porting guide). Links? Pointers? Tips? Clues? Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838 ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated
On Mon, 2005-09-19 at 11:53 -0700, 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. > > What I'd like to find is a comparison of gcc 2.96.x to 3.x from the > perspective of porting something from RH7.x to CentOS/RHEL 4.x > > What I did was make a fresh install of CentOS 4.1 and then load > the source code for the application and try to make. What gcc 2.96 > compiler assumed about the underlying OS, and what gcc 3.x > assumes about the underlying OS, may be relatively skew. Whether > any of the application code assumes a 2.96 set of assumptions, where > this set of assumptions is broken under 3.x, is unknown (and is the > kind of detail I'd like to see in the above-hinted-at porting guide). > > Links? Pointers? Tips? Clues?Brian, There is a compat-libstdc++-296-2.96-132.7.2 ... so you might be able to install that and run your applications. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20050919/5e52bc1c/attachment.sig>
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 -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that!
This advice completely misses my point.> What I'd like to find is a comparison of gcc 2.96.x to 3.x from the > perspective of porting something from RH7.x to CentOS/RHEL 4.xI don't want my code to stay rooted in The Dead Past. I want to know what kinds of things changed to give me clues how to CHANGE MY CODE TO FIT TODAY. Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838 Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838>>> mailing-lists at hughesjr.com 09/19/05 04:46PM >>>On Mon, 2005-09-19 at 11:53 -0700, 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. > > What I'd like to find is a comparison of gcc 2.96.x to 3.x from the > perspective of porting something from RH7.x to CentOS/RHEL 4.x > > What I did was make a fresh install of CentOS 4.1 and then load > the source code for the application and try to make. What gcc 2.96 > compiler assumed about the underlying OS, and what gcc 3.x > assumes about the underlying OS, may be relatively skew. Whether > any of the application code assumes a 2.96 set of assumptions, where > this set of assumptions is broken under 3.x, is unknown (and is the > kind of detail I'd like to see in the above-hinted-at porting guide). > > Links? Pointers? Tips? Clues?Brian, There is a compat-libstdc++-296-2.96-132.7.2 ... so you might be able to install that and run your applications. ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated
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 at gai-tronics.com
(610)796-5838
>>> mike.mccarty at 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
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
_______________________________________________
CentOS mailing list
CentOS at centos.org
http://lists.centos.org/mailman/listinfo/centos
*******************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept
for the presence of computer viruses.
www.hubbell.com - Hubbell Incorporated
As to whether C or C++ changed between when 2.96 came out and Centos 4.1, there is another conundrum: Does the compiler define the language, or vice versa? Acknowledging the human factor in the implementation of the compiler, we ought to stipulate that both 2.96 and 3.x are B - R - O - K - E - N; the question I've asked is in what way is 3.x different in how it's broken compared to 2.96 2.96 allowed some things not strictly kosher under the C/C++ language definitions, some of these are no longer winked at by the 3.x compiler. I'm looking for a pragmatic answer, not a theorist answer, about the differences between 2.96 and 3.x. Since nothing is coming to mind among the Notable Ones here, I'll take my question to the compiler groups... Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838>>> mike.mccarty at sbcglobal.net 09/20/05 10:33AM >>>Brian T. Brunner wrote:> This advice completely misses my point.I think you missed the point.>>What I'd like to find is a comparison of gcc 2.96.x to 3.x from the >>perspective of porting something from RH7.x to CentOS/RHEL 4.x > > > I don't want my code to stay rooted in The Dead Past. > I want to know what kinds of things changed to give me clues > how to CHANGE MY CODE TO FIT TODAY.The C programming language did not change. The most likely reason your code won't compile is that the compiler is B-R-O-K-E-N. [snip] Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that! _______________________________________________ CentOS mailing list CentOS at centos.org http://lists.centos.org/mailman/listinfo/centos ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated
My mailer has no quoted-text-prefix capability. ***embedded replies*** Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838>>> mike.mccarty at sbcglobal.net 09/20/05 11:16AM >>>Brian T. Brunner wrote:> My desire is NOT to remain rooted in the past. Hence > my interest in changing my code to meet the compiler of today.You should not use what some compiler accepts as your guide for writing code. You should use the Language Definition. ***pedantic*** I have to get the compiler to compile the code, the language definition won't do that. ***pragmatic*** I'm here to drain the swamp, not analyze the alligators. ***overall** How did the compilers change in what they tolerate. See below.> 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 >Also, the C Language did not recently change. ***the compiler is the cop, the language definition is the law***> Known problem and solution: (amended to clarify my mumbling, for which I apologize) > > We have typedef char MsgIdT > We use a message that is a union comprising a > MsgIdT MsgId; > and the > 117 message structures, (each of which has a MsgIdT MsgId 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 but 2.96 didn't care > so now we say > union msgstructT msg = {0}; // the 3.x compiler is happy with this. So is 2.96 > > 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.Your guide to writing proper code should not be what a compiler accepts, but what the language definition specifies. ***the compiler creates the marketable product, that's what I have to please.*** ***As a theorist, the C and C++ language definitions (law) are fascinating*** ***As an engineer porting 2.96 code to a 3.4 compiler, the (get this)*** ***LANGUAGE DEFINITION IS UTTERLY IRRELEVANT*** ***I've met plenty of cops to whom the law is irrelevant, we do things his way or there's trouble.*** ***the compiler is my cop. He's the one I have to please.*** gcc --ansi --pedantic -Wall to get maximum conformance and portability of my code. ***this is what I inherited: ***COMPILER_OPTIONS = -D_GCC_ -g -g3 -pipe -march=i586 -fstack-check -fcse-follow-jumps -fexpensive-optimizations -fcse-skip-blocks -fforce-mem -frerun-cse-after-loop -fschedule-insns -fschedule-insns2 -fshort-enums -fstrength-reduce -fthread-jumps -fverbose-asm -O2 -Wall -Waggregate-return -Wcast-align -Wcast-qual -Wconversion -Winline -Wpointer-arith -Wshadow -Wwrite-strings *** probably more than I need, I might take a (sub) project of stripping this list down to just those needed to get in-spec performance of the object code. ** neither ansi nor pedantic are currently in the list of options. should be reported as a defect. ***My mission is to get the code running under the new compiler. The code pleased the 2.96 compiler. Things worked! ***Now, the new compiler is really displeased with my code. ***I'd like to know what the differences are in the two compiler versions relative to what (possibly) non-conforming code is no longer tolerated. ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated
Brian T. Brunner wrote:> What I'd like to find is a comparison of gcc 2.96.x to 3.x from the > perspective of porting something from RH7.x to CentOS/RHEL 4.xYou're probably better off asking on the gcc list or some other C/developer oriented forum. This list is mainly sysadmins. -jim
>>>>mike.mccarty at sbcglobal.net 09/20/05 11:16AM >>> > ***pedantic*** I have to get the compiler to compile the code, the language definition won't do that. > ***pragmatic*** I'm here to drain the swamp, not analyze the alligators. > ***overall** How did the compilers change in what they tolerate.Certainly. I didn't mean something silly like "Well, the compiler is broken today. I guess I'll go home and watch TV." ***Good... because I don't have one (Troglodyte!)*** If the compiler is broken, then it will soon be fixed. ***Until then I gotta adapt code that worked with one broken compiler to another broken compiler.> Also, the C Language did not recently change. > > ***the compiler is the cop, the language definition is the law***Cops which break the law go to jail just like everyone else. Eventually, the cops enforce the law as written. ***I'm going to guess: you're white, male, and economically rather well off. ***Because of this, your "world" basically "works" and crooked cops are the exception that get brought to justice for breaking the rules. ***(some) Cops ignoring (some of) the law is the way things are; in some places that *is* the rule the judges uphold. BTDT. ***It isn't what's wanted, it's what is. All compilers are partly broken, yes? ***Microsoft fixes theirs faster because they're a bigger corporation, Yes? Or is it a law unto itself immune to outside judgment? ***GCC will improve. It will go from broken to broken-differently. ***It is (truthfully) believed that the subsequent implementations are broken less where they were broken before, and increases in breakage come in part from new technology (HT/MP/SSE/etc) ***A summary of the brokenness in 2.96 addressed in 3.4 is what's wanted. what you had looks like it should have worked. But the compiler seems to have an internal problem. If "{0}" works, then "{((MsgIdT)0)}" should also work. *** We agree. When theory meets reality, theory ALWAYS wins, and reality NEVER cares. I'd suggest creating a minimal file which reproduces the problem and filing an error report. In the meantime, I'd change the source to look like this: *** I'll have to do this: experiment my way around this newer, differently-broken compiler. ***Why? Because the summary-of-changes I seek appears to not have been created.>>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.I find the "-D_GCC_" to be highly suspicious for these reasons (at least) **Trimming the compiler option line is one thing I'll try. I wouldn't duplicate the message id like that, ***It allows testing the message ID whether you've got a pointer-to-the-union OR a pointer-to-a-subordinate-structure. The message you reported sounds like an internal error. ***The "can't find register to spill" came from other code. Brian Brunner brian.t.brunner at gai-tronics.com (610)796-5838 ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.hubbell.com - Hubbell Incorporated