ecasey:
The problem is the "#include <iostream>" itself;
the include chain leads to the file:
C:\nburn\gcc-m68k\m68k-elf\include\c++\4.2.1\string
within this I found:
#undef strcoll
#undef strxfrm
which seems not to have been defined before.
----------------------------------------------------------------------------------------
tod:
I'm using NNDK Release 2.6.1 and GNU compiler Version 4.2.1.
I disabled the optimization, as you suggested, and it worked!
-O1 and -O2 produced the error, as before.
I'm not sure if we can go without optimization - I'm gonna go in for a closer look on your discussion with linhm (who seems to have had a similar problem some years ago) next week.
MOD5234 - problem with float-to-string routines
Re: MOD5234 - problem with float-to-string routines
Do you change the locale?
I note that the problem with "::strcoll" and "::strxfrm" relate back to the <local.h> file. The locale can also affect on how the decimal character is presented in formatted output. Perhaps something touches the locale or there is something corrupted in the file that is underlying both problems.
It is difficult to tell without looking at all of the code. It may be necessary to re-load the NNDK. I am finding that 2.6.2 is more stable than 2.6.1.
I note that the problem with "::strcoll" and "::strxfrm" relate back to the <local.h> file. The locale can also affect on how the decimal character is presented in formatted output. Perhaps something touches the locale or there is something corrupted in the file that is underlying both problems.
It is difficult to tell without looking at all of the code. It may be necessary to re-load the NNDK. I am finding that 2.6.2 is more stable than 2.6.1.
Re: MOD5234 - problem with float-to-string routines
I just went back through my old tickets. In February of 2007 I submitted a ticket of
If you try 2.6.2 and it doesn't help you might try moving back to 2.6.0.026 (the last stable release) it might help. The fact that you can't use the std C++ lib is pretty good motivation to try a different release. Otherwise you may have no choice but to use -O0, you can always rewrite any slow parts in assembly!
In my case I needed the volatile to communicate with an FPGA and the compiler was ignoring the volatile keyword and optimizing away the code. This was in code that worked for years up through NNDK 1.8 and then in NNDK 2.0 it broke. Turning the optimization down from -O2 to -O0 solved the problem and I just lived with it for a few years. At some point I tested again on a newer NNDK and the optimization bug went away and I went back to using -O2.Possible compiler bug with -O2 C++ flag and volatile
If you try 2.6.2 and it doesn't help you might try moving back to 2.6.0.026 (the last stable release) it might help. The fact that you can't use the std C++ lib is pretty good motivation to try a different release. Otherwise you may have no choice but to use -O0, you can always rewrite any slow parts in assembly!