public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/40096] incremental pointer logic that used to work in older gcc versions
  2009-05-10 22:21 [Bug c/40096] New: incremental pointer logic that used to work in older gcc versions stian at nixia dot no
@ 2009-05-10 22:21 ` stian at nixia dot no
  2009-05-10 22:38 ` pinskia at gcc dot gnu dot org
  1 sibling, 0 replies; 3+ messages in thread
From: stian at nixia dot no @ 2009-05-10 22:21 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from stian at nixia dot no  2009-05-10 22:21 -------
Created an attachment (id=17849)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17849&action=view)
test.c

test-case


-- 


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


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

* [Bug c/40096]  New: incremental pointer logic that used to work in older gcc versions
@ 2009-05-10 22:21 stian at nixia dot no
  2009-05-10 22:21 ` [Bug c/40096] " stian at nixia dot no
  2009-05-10 22:38 ` pinskia at gcc dot gnu dot org
  0 siblings, 2 replies; 3+ messages in thread
From: stian at nixia dot no @ 2009-05-10 22:21 UTC (permalink / raw)
  To: gcc-bugs

Hi

I'm going to attach a small test case that used to work until my gentoo system
upgraded gcc to 4.3.2. It is not a vanilla build, but I'm not able to easy test
this on a vanilla system.

For my failing system, the output from the test case is:

0x81 0x82 0x03 => 0x00004103
0x81 0x82 0x03 => 0x00004103
0xbf971bdd vs 0xbf971bda


(number before and after "vs" should have been the same).

Same output from an okey system (redhat with gcc 4.1.2):

0x81 0x82 0x03 => 0x00004103
0x81 0x82 0x03 => 0x00004103
0xbf93c4c9 vs 0xbf93c4c9


-- 
           Summary: incremental pointer logic that used to work in older gcc
                    versions
           Product: gcc
           Version: 4.3.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: stian at nixia dot no
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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


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

* [Bug c/40096] incremental pointer logic that used to work in older gcc versions
  2009-05-10 22:21 [Bug c/40096] New: incremental pointer logic that used to work in older gcc versions stian at nixia dot no
  2009-05-10 22:21 ` [Bug c/40096] " stian at nixia dot no
@ 2009-05-10 22:38 ` pinskia at gcc dot gnu dot org
  1 sibling, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2009-05-10 22:38 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from pinskia at gcc dot gnu dot org  2009-05-10 22:38 -------
This code is undefined because are there are two stores to test2 without a
sequence point.
        test2+=readvlnum(&test2);
Can be evaluated like:
tmp1 = test2;
tmp2 = readvlnum(&test2);
test2 = tmp1 + tmp2;
Or:
tmp2 = readvlnum(&test2);
tmp1 = test2;
test2 = tmp1 + tmp2;

Both are what the C/C++ standards say it could evaluate this statement.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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


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

end of thread, other threads:[~2009-05-10 22:38 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-10 22:21 [Bug c/40096] New: incremental pointer logic that used to work in older gcc versions stian at nixia dot no
2009-05-10 22:21 ` [Bug c/40096] " stian at nixia dot no
2009-05-10 22:38 ` pinskia at gcc dot gnu dot 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).