[Bug target/52301] avr-gcc 4.6.2 produces NOP loop in simple while statement

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52301 --- Comment #6 from rickyrockrat 2012-02-22 05:05:56 UTC --- I guess I'm a little confused. How can GCC NOT know it can change? Any RAM location not only can but usually does change. It seems that volatile should be the norm. Whatever. I'll jus

[Bug target/52301] avr-gcc 4.6.2 produces NOP loop in simple while statement

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52301 --- Comment #4 from rickyrockrat 2012-02-22 04:31:11 UTC --- Created attachment 26724 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26724 Assembly generated using script and original source Resulting assembly from recently supplied files -

[Bug target/52301] avr-gcc 4.6.2 produces NOP loop in simple while statement

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52301 --- Comment #3 from rickyrockrat 2012-02-22 04:29:21 UTC --- Created attachment 26723 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26723 Script to compile bug52301.c Script to run avr-gcc on the subject file.

[Bug target/52301] avr-gcc 4.6.2 produces NOP loop in simple while statement

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52301 --- Comment #2 from rickyrockrat 2012-02-22 04:27:01 UTC --- Created attachment 26722 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26722 Intermediate file Intermediate file, as requested. Changed name to bug52301.

[Bug c/52301] New: avr-gcc 4.6.2 produces NOP loop in simple while statement

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52301 Bug #: 52301 Summary: avr-gcc 4.6.2 produces NOP loop in simple while statement Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED

[Bug c/50695] double comparison broken after computation

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695 --- Comment #11 from rickyrockrat 2011-10-12 17:40:25 UTC --- Richard, The original issue involved strtof, with -Wall enabled in the Makefile, and stdlib.h included. That is the case that brought all this up, and that is the case where it prints

[Bug c/50695] double comparison broken after computation

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695 --- Comment #9 from rickyrockrat 2011-10-11 19:38:51 UTC --- One further note, with stdio.h, string.h and using strtod, I get the correct answer suggested by Andreas Schwab: Bug!!0.00E+00 If I put stdio.h, string.h, and stdlib.h, I get Nobug

[Bug c/50695] double comparison broken after computation

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695 --- Comment #8 from rickyrockrat 2011-10-11 19:33:47 UTC --- Created attachment 25469 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25469 stdlib.h Tar for string.h, stdlib.h, and stdio.h on the system.

[Bug c/50695] double comparison broken after computation

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695 --- Comment #7 from rickyrockrat 2011-10-11 19:25:10 UTC --- I removed the ','at the beginning of the string (which was not there in the original test case), and I now get Bug!!4.074850E+05 In any case, it should return 0, if +1.xxE-6 is an inv

[Bug c/50695] double comparison broken after computation

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695 rickyrockrat changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug c/50695] double comparison broken after computation

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695 --- Comment #5 from rickyrockrat 2011-10-11 19:05:28 UTC --- >+1.0E-06," does not start with a valid >floating point number and will always be parsed as 0. I don't know what 'always will be', nor who exactly is doing the parsing, but strtof

[Bug c/50695] New: double comparison broken after computation

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695 Bug #: 50695 Summary: double comparison broken after computation Classification: Unclassified Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priorit