I have an example where GCC produces bad code, where a function call
causes variables in the caller (held in registers) to be over-written.
Does anybody want to take a look at it? Unfortunately I cannot give
you something that you can compile and run, but I can give you the
source and assembly for the offending functions, along with the
compilation lines that were used.
Andrew
Previously, Andrew Thomas wrote in qdn.public.qnxrtp.devtools:
I have an example where GCC produces bad code, where a function call
causes variables in the caller (held in registers) to be over-written.Does anybody want to take a look at it? Unfortunately I cannot give
you something that you can compile and run, but I can give you the
source and assembly for the offending functions, along with the
compilation lines that were used.
For two days I truly believed that I was seeing bad code generation,
and only after read and re-reading the assembler, generating test
cases, etc., have I finally come to the conclusion that C programmers
should never read assembler code.
False alarm. My apologies.
Andrew
Andrew Thomas wrote:
Previously, Andrew Thomas wrote in qdn.public.qnxrtp.devtools:
I have an example where GCC produces bad code, where a function call
causes variables in the caller (held in registers) to be over-written.Does anybody want to take a look at it? Unfortunately I cannot give
you something that you can compile and run, but I can give you the
source and assembly for the offending functions, along with the
compilation lines that were used.For two days I truly believed that I was seeing bad code generation,
and only after read and re-reading the assembler, generating test
cases, etc., have I finally come to the conclusion that C programmers
should never read assembler code.False alarm. My apologies.
For what it worth, I have some doubts about optimized code too. I have
some code which manipulates and prints 64-bit integers and that code
prints different values when compiled with and without -O. Those printed
with -O are incorrect.
I’ve also heard ‘rumors from credible sources’ ™ that there appears
to be problem with NTO linker related to optimization (not that I know
what that could possibly mean anyway). It also generates unnecessarily
bloated executables and apparently is being re-written now. Feed me
Colin 
I’ve also heard ‘rumors from credible sources’ ™ that there appears
to be problem with NTO linker related to optimization (not that I know
what that could possibly mean anyway). It also generates unnecessarily
bloated executables and apparently is being re-written now. Feed me
Colin >
No, you’re getting too fat.
Colin Burgess wrote:
I’ve also heard ‘rumors from credible sources’ ™ that there appears
to be problem with NTO linker related to optimization (not that I know
what that could possibly mean anyway). It also generates unnecessarily
bloated executables and apparently is being re-written now. Feed me
Colin >No, you’re getting too fat.
Hey, look who’s talking 
Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:
Colin Burgess wrote:
I’ve also heard ‘rumors from credible sources’ ™ that there appears
to be problem with NTO linker related to optimization (not that I know
what that could possibly mean anyway). It also generates unnecessarily
bloated executables and apparently is being re-written now. Feed me
Colin >No, you’re getting too fat.
Hey, look who’s talking >
Now you’ve hurt my feelings! Where’s that cookie dough! ;v)
Bill Caroselli <Bill@sattel.com> wrote:
Remember, the most dangerious animal in the world is a programmer with a
screw driver.
BS… the most dangerous animal is a hardware engineer with a compiler.
Bill Caroselli <> Bill@sattel.com> > wrote:
Remember, the most dangerious animal in the world is a programmer
with a
screw driver.BS… the most dangerous animal is a hardware engineer with a compiler.
Specifically, a C++ compiler (the damage wrought by a h/w engineer with
a C compiler can, at least, be fathomed .
Remember, the most dangerious animal in the world is a programmer with a
screw driver.
–
Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122
“Andrew Thomas” <Andrew@cogent.ca> wrote in message
For two days I truly believed that I was seeing bad code generation,
and only after read and re-reading the assembler, generating test
cases, etc., have I finally come to the conclusion that C programmers
should never read assembler code.False alarm. My apologies.
Andrew
You guys are scaring me. You see, I’m officially trained as a
hardware/software mix – as a former colleague termed it, a “cross dresser”.
Fortunately, I’ve hardly ever touched C++, so at least I’m only wreaking
fathomable damage.
The real trouble for me is that I’m constantly engaged on both the hardware
and software sides of a project, so when something doesn’t work, I can’t
blame anyone else!
–
Bert Menkveld
“Rennie Allen” <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C9033A75@exchangecal.hq.csical.com…
Bill Caroselli <> Bill@sattel.com> > wrote:
Remember, the most dangerious animal in the world is a programmer
with a
screw driver.BS… the most dangerous animal is a hardware engineer with a compiler.
Specifically, a C++ compiler (the damage wrought by a h/w engineer with
a C compiler can, at least, be fathomed >
Previously, pete@qnx.com wrote in qdn.public.qnxrtp.devtools:
Bill Caroselli <> Bill@sattel.com> > wrote:
Remember, the most dangerious animal in the world is a programmer with a
screw driver.BS… the most dangerous animal is a hardware engineer with a compiler.
Are you implying that that’s more dangerous than a hardware engineer
with a Visual Basic interpreter?
Andrew