public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/54951] New: Incorrect pointer handling on 32K boundary
@ 2012-10-17 14:37 m.galante at centrosistemi dot it
  2012-10-18  2:15 ` [Bug target/54951] " dj at redhat dot com
  2012-12-09  2:12 ` pinskia at gcc dot gnu.org
  0 siblings, 2 replies; 3+ messages in thread
From: m.galante at centrosistemi dot it @ 2012-10-17 14:37 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54951

             Bug #: 54951
           Summary: Incorrect pointer handling on 32K boundary
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: m.galante@centrosistemi.it


Created attachment 28460
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28460
Simple test case to reproduce the bug

m32c-elf-gcc (GCC) 4.7.2 hosted on Windows XP.

The attached "run.bat" batch compiles and runs a simple program that adds a
constant value (COUNT) to a pointer (0x10000) and prints the result.
The first result (a) is calculated by adding COUNT to the pointer, the second
result (b) is calculated by incrementing the pointer COUNT times.

When COUNT is 0x7FFF the result is correct for both a and b (0x17FFF).

When COUNT is 0x8000 the result is incorrect for a (0x8000) but correct for b
(0x18000).

When COUNT is 0xFFFF the result is incorrect for a (0xFFFF) but correct for b
(0x1FFFF) when compiled with -O0, and incorrect for both a and b (0xFFFF) when
compiled with -O1.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug target/54951] Incorrect pointer handling on 32K boundary
  2012-10-17 14:37 [Bug c/54951] New: Incorrect pointer handling on 32K boundary m.galante at centrosistemi dot it
@ 2012-10-18  2:15 ` dj at redhat dot com
  2012-12-09  2:12 ` pinskia at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: dj at redhat dot com @ 2012-10-18  2:15 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54951

DJ Delorie <dj at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dj at redhat dot com

--- Comment #1 from DJ Delorie <dj at redhat dot com> 2012-10-18 02:14:48 UTC ---
This is, unfortunately, the expected behavior for m32c.  The m32c has 20-bit
pointers but 16-bit math operations, so size_t is 16 bits resulting in many
pointer math operations being truncated to 16 bits.  So, a COUNT of 0xFFFF may
be interpreted as -1 instead of 65536, etc.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug target/54951] Incorrect pointer handling on 32K boundary
  2012-10-17 14:37 [Bug c/54951] New: Incorrect pointer handling on 32K boundary m.galante at centrosistemi dot it
  2012-10-18  2:15 ` [Bug target/54951] " dj at redhat dot com
@ 2012-12-09  2:12 ` pinskia at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu.org @ 2012-12-09  2:12 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54951

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-12-09  2:12 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-17 14:37 [Bug c/54951] New: Incorrect pointer handling on 32K boundary m.galante at centrosistemi dot it
2012-10-18  2:15 ` [Bug target/54951] " dj at redhat dot com
2012-12-09  2:12 ` pinskia at gcc dot gnu.org

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).