public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "regehr at cs dot utah dot edu" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/39232] New: apparent bizarre miscompilation on AVR Date: Wed, 18 Feb 2009 16:40:00 -0000 [thread overview] Message-ID: <bug-39232-12544@http.gcc.gnu.org/bugzilla/> (raw) This is seen on the version of avr-gcc 4.3.3 that gets built by the script that comes with FemtoOS 0.88. I'm compiling like this: avr-gcc -mmcu=atmega128 -O0 small_preprocessed.c -o small.elf And observing the result of a run like this: java -server avrora.Main -platform=mica2 -simulation=sensor-network -monitors=break -colors=false -seconds=15 small.elf Of course you need Avrora installed to do this. The program computes a checksum over its globals before terminating, this is found in the Avrora output as: r30:r31 = 0x5DAD It can be seen that the checksum computed at -O0 is different from higher optimization levels, which give 0xDBFA. My belief is that the -O0 result is wrong, and here's why: deleting almost any line of code from the program causes it to have the same checksum at all optimization levels. To see this, delete for example the line "int16_t l_46 = 1;" in func_43(). This line obviously has no effect on the computation. This changes the checksum to 0xDBFA, which is in agreement with higher optimization levels. The test code is obviously nonsense. However, I cannot give a smaller testcase since deleting code makes the problem go away. My belief is that this problem in not the result of a stack overflow: my stack analysis tool estimates that maximum RAM usage (including stack) is 2496 bytes, leaving plenty of free space on the mega128. My believe is that this problem is no due to undefined behavior in the C code. -- Summary: apparent bizarre miscompilation on AVR Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: regehr at cs dot utah dot edu GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39232
next reply other threads:[~2009-02-18 16:40 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-02-18 16:40 regehr at cs dot utah dot edu [this message] 2009-02-18 16:41 ` [Bug c/39232] " regehr at cs dot utah dot edu 2009-02-20 3:33 ` [Bug target/39232] " regehr at cs dot utah dot edu 2009-02-20 3:44 ` regehr at cs dot utah dot edu 2009-03-04 22:22 ` regehr at cs dot utah dot edu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-39232-12544@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).