[Bug c/35249] New: gcc miscompiles emacs' src/intervals.c when using optimisation on solaris 8

[Bug c/35249] New: gcc miscompiles emacs' src/intervals.c when using optimisation on solaris 8

[simon dot marshall at misys dot com]

I seem to have found a problem where gcc-4.1.2 and gcc-4.2.3 miscompile Emacs'
src/intervals.c when using optimisation on solaris 8.  

$ gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: ../configure --enable-languages=c,c++
Thread model: posix
gcc version 4.2.3

I discovered it when investigating a problem whereby Emacs periodically
determined that some internal state was inconsistent.  Unfortunately, even
though I managed to find a scenario that reliably reproduced it, other people
were unable to reproduce it on other platforms.  So, at someone else's
suggestion, I investigated it as something specific to my environment.

Here's how to reproduce the problem.  Untar emacs-22.1, do a minimal configure
and build it on a solaris 2.8 box:

$ ./configure --with-x-toolkit=lucid --without-xaw3d --without-xpm
--without-jpeg --without-tiff --without-gif --without-png
--without-toolkit-scroll-bars
$ make

This builds everything with "-g -O2 -Wno-pointer-sign", giving the executable
src/emacs.

$ gdb src/emacs
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...

Now put a breakpoint on the place where emacs is about to report that some
internal state is inconsistent.

(gdb) b intervals.c:794
Breakpoint 1 at 0x190db4: file intervals.c, line 794.
(gdb) r -Q
Starting program:
/homedev/marshals/ftp/emacs-22.2-pretests/gcc-4.2.3-g-O2/src/emacs -Q
warning: Temporarily disabling breakpoints for unloaded shared library
"/usr/lib/ld.so.1"

At this point, type C-x C-f src/intervals.c RET into the Emacs window.

Breakpoint 1, update_interval (i=0x81b6f4, pos=1771) at intervals.c:794
794                 error ("Point before start of properties");
(gdb) 

The breakpoint it hit, as emacs is about to report that some internal state is
inconsistent.  Now exit gdb and rebuild just intervals.c:

$ rm -f src/intervals.o
$ make CFLAGS=-g

This builds just intervals.o with "-g".  Repeat the above gdb session and you
will find that emacs does not hit the breakpoint, ie, the executable code is
functionally different.

I have reproduced this with gcc-4.1.2 and gcc-4.2.3.  I cannot reproduce it
using Sun Studio CC-5.7.  I also could not reproduce it on RHEL-5 with its
gcc-4.1.2, nor could a couple of other people who tried it on non-sparc
platforms.

I have also found that if I build everything else with "-g", but intervals.c
with "-g -O2", then I can reproduce this problem.  So, it seems specific to the
optimisation of intervals.c and specific to Solaris.  How could that be?

I appreciate that Emacs is not the smallest of test cases and I apologise in
advance for this crime.  Anything I can do to help determine the cause?


-- 
           Summary: gcc miscompiles emacs' src/intervals.c when using
                    optimisation on solaris 8
           Product: gcc
           Version: 4.2.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: simon dot marshall at misys dot com
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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

[Bug c/35249] gcc miscompiles emacs' src/intervals.c when using optimisation on solaris 8

[ebotcazou at gcc dot gnu dot org]

------- Comment #1 from ebotcazou at gcc dot gnu dot org  2008-02-18 17:51 -------
> I have reproduced this with gcc-4.1.2 and gcc-4.2.3.  I cannot reproduce it
> using Sun Studio CC-5.7.  I also could not reproduce it on RHEL-5 with its
> gcc-4.1.2, nor could a couple of other people who tried it on non-sparc
> platforms.

Thanks for the detailed report.

> I have also found that if I build everything else with "-g", but intervals.c
> with "-g -O2", then I can reproduce this problem.  So, it seems specific to
> the optimisation of intervals.c and specific to Solaris.  How could that be?

Some optimizations are target-dependent, so it's not uncommon.

> I appreciate that Emacs is not the smallest of test cases and I apologise in
> advance for this crime.  Anything I can do to help determine the cause?

Are you familiar with src/intervals.c?  If so, you could try to narrow down
the problem to a single function, if possible.  Try first to compile it at
-O1 only, then add -fno-unit-at-a-time.  What happens?


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org


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

[Bug c/35249] gcc miscompiles emacs' src/intervals.c when using optimisation on solaris 8

[simon dot marshall at misys dot com]

------- Comment #2 from simon dot marshall at misys dot com  2008-02-18 18:06 -------
> > I appreciate that Emacs is not the smallest of test cases and I apologise in
> > advance for this crime.  Anything I can do to help determine the cause?
> 
> Are you familiar with src/intervals.c?  If so, you could try to narrow down
> the problem to a single function, if possible.  Try first to compile it at
> -O1 only, then add -fno-unit-at-a-time.  What happens?

Thanks for the quick response.  Unfortunately, I'm not familiar with
src/intervals.c and I doubt if it is easy to split it up...

But, to answer your suggestion, I forgot to mention that I could reproduce the
problem with "-g -O" and "-g -O1".  Following your suggestion, I also tried "-g
-O1 -fno-unit-at-a-time" on src/intervals.c and the problem remains (the
breakpoint is hit).  The breakpoint is not hit with "-g -fno-unit-at-a-time"
(or with "-g", as I originally reported).  Does this help?


-- 


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

[Bug c/35249] gcc miscompiles emacs' src/intervals.c when using optimisation on solaris 8

[ebotcazou at gcc dot gnu dot org]

------- Comment #3 from ebotcazou at gcc dot gnu dot org  2008-02-18 18:21 -------
> Thanks for the quick response.  Unfortunately, I'm not familiar with
> src/intervals.c and I doubt if it is easy to split it up...

Is it possible to guess in what function things go awry?

> But, to answer your suggestion, I forgot to mention that I could reproduce
> the problem with "-g -O" and "-g -O1".  Following your suggestion, I also
> tried "-g -O1 -fno-unit-at-a-time" on src/intervals.c and the problem
> remains (the breakpoint is hit).

That the problem is present with -g -O1 -fno-unit-at-a-time means that it's
easier to pinpoint the bug, since there is no under the hood inlining at this
level.  So it presumably should be possible to find out which function is
miscompiled using source level debugging.


-- 


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

[Bug c/35249] gcc miscompiles emacs' src/intervals.c when using optimisation on solaris 8

[simon dot marshall at misys dot com]

------- Comment #4 from simon dot marshall at misys dot com  2008-02-19 12:04 -------
OK, before I start hacking, what is it that you need once I have found a
function?

What I can do is try to identify a function or minimal functions that, when
compiled in a file with optimisation, will cause Emacs to detect inconsistent
internal state, but not when compiled without optimisation.  I can compile this
file with "-g -O0 -fno-unit-at-a-time",  "-g -O1 -fno-unit-at-a-time" and "-g
-O2 -fno-unit-at-a-time".  I can compile all other files with "-g -O2
-fno-unit-at-a-time".  Does this sound right?

Once I've found it, what would be useful to you?  Output from -E for that file?
 Files generated by -S for that file using the flags above?  Some other
internal gcc output?

Assuming that I am able to debug this function, any pointers as to what I could
look for that might explain why it is functionally different when compiled with
optimisation?


-- 

simon dot marshall at misys dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |c


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

[Bug c/35249] gcc miscompiles emacs' src/intervals.c when using optimisation on solaris 8

[ebotcazou at gcc dot gnu dot org]

------- Comment #5 from ebotcazou at gcc dot gnu dot org  2008-02-19 12:36 -------
> Once I've found it, what would be useful to you?

See http://gcc.gnu.org/bugs.html

> Assuming that I am able to debug this function, any pointers as to what Icould
> look for that might explain why it is functionally different when compiled with
> optimisation?

Not really if it's a compiler bug.


-- 


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

[Bug c/35249] gcc miscompiles emacs' src/intervals.c when using optimisation on solaris 8

[simon dot marshall at misys dot com]

------- Comment #6 from simon dot marshall at misys dot com  2008-02-19 14:40 -------
Created an attachment (id=15184)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15184&action=view)
intervals2.c and output of -v -save-temps

Maybe it was easier than I thought.  I took out the function update_interval
from the file internals.c, in which Emacs was detecting internal data structure
inconsistency, and compiled it in a new file internals2.c.  With this separate
file, I can reproduce the error if I build with "-g -O1 -fno-unit-at-a-time" or
"-g -O2 -fno-unit-at-a-time", but not with "-g -O0 -fno-unit-at-a-time". 
Attached is the output generated by "-v -save-temps -g -O1 -fno-unit-at-a-time"
for this file, ie, the .c, .i, .s and the output of gcc itself.  All other
files in the Emacs executable were compiled with "-g -O2 -fno-unit-at-a-time".

The offending call of error occurs at internals.c:34:

          else if (NULL_PARENT (i))
            error ("Point before start of properties");

which according to internals.i is:

   else if (((i)->up_obj || (i)->up.interval == 0))
     error ("Point before start of properties");

Note the condition that needs to be true for error to be called.  However, when
error is called:

$ gdb emacs
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from
terminal]
DISPLAY = dtp020071.misys-risk.com:0.0
TERM = xterm
Breakpoint 1 at 0xe4ee4: file emacs.c, line 432.
Breakpoint 2 at 0x100138: file sysdep.c, line 1384.
(gdb) b intervals2.c:34
Breakpoint 3 at 0x19420c: file intervals2.c, line 34.
(gdb) r -Q
Starting program:
/homedev/marshals/ftp/emacs-22.2-pretests/gcc-4.2.3-g-O2/src/emacs -Q
warning: Temporarily disabling breakpoints for unloaded shared library
"/usr/lib/ld.so.1"
Breakpoint 4 at 0xc552c: file xterm.c, line 7866.

Breakpoint 3, update_interval (i=0x8286f4, pos=1771) at intervals2.c:34
34                  error ("Point before start of properties");
(gdb) p i->up_obj
$1 = 0
(gdb) p i->up.interval
$2 = (struct interval *) 0x828534
(gdb) p *i
$3 = {
  total_length = 36, 
  position = 1782, 
  left = 0x828710, 
  right = 0x828550, 
  up = {
    interval = 0x828534, 
    obj = 8553780
  }, 
  up_obj = 0, 
  gcmarkbit = 0, 
  write_protect = 0, 
  visible = 0, 
  front_sticky = 0, 
  rear_sticky = 0, 
  plist = 8527837
}
(gdb) p i->up_obj || i->up.interval == 0 
$4 = 0
(gdb) 

So, if the data appears to suggest that the condition should be false, why does
the behaviour appear as if the condition is true?

Or did I do something stupid?  Is this really a symptom of some other problem?


-- 


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

[Bug c/35249] gcc miscompiles emacs' src/intervals.c when using optimisation on solaris 8

[simon dot marshall at misys dot com]

------- Comment #7 from simon dot marshall at misys dot com  2008-02-19 14:44 -------
Sorry, for internals.c and internals.i, read intervals2.c and intervals2.i.


-- 


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

[Bug middle-end/35249] gcc miscompiles emacs' src/intervals.c when using optimisation on solaris 8

[ebotcazou at gcc dot gnu dot org]

------- Comment #8 from ebotcazou at gcc dot gnu dot org  2008-02-20 11:35 -------
Investigating.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-02-20 11:35:25
               date|                            |


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

[Bug middle-end/35249] miscompilation of Emacs at -O

[ebotcazou at gcc dot gnu dot org]

------- Comment #9 from ebotcazou at gcc dot gnu dot org  2008-02-24 21:47 -------
Could you put the breakpoint on the 'error' function rather than at line 34
and examine again the condition when it is hit?  Does the problem arise if
you add -fno-delayed-branch on the command line?


-- 


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

[Bug middle-end/35249] miscompilation of Emacs at -O

[simon dot marshall at misys dot com]

------- Comment #10 from simon dot marshall at misys dot com  2008-02-26 10:36 -------
With CFLAGS="-g -O1 -fno-unit-at-a-time -fno-crossjumping -Wno-pointer-sign", I
cannot hit the breakpoint on error (ie, if I put a breakpoint on error itself).

Also, I cannot hit the breakpoint at intervals2.c:34 if I add
-fno-delayed-branch to the compilation of intervals2.c.

The original motivation for this report was that I was trying to reproduce the
occasional problem of error being called (a "this should never happen" sanity
check) at this place in the code.  I thought I had managed to do that with the
bugzilla reported simple sequence of events immediately after starting emacs. 
Does your finding suggest that my supposed reproduction of the error call was
an illusion?  (And that there is no miscompilation either.)


-- 


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

[Bug middle-end/35249] miscompilation of Emacs at -O

[ebotcazou at gcc dot gnu dot org]

------- Comment #11 from ebotcazou at gcc dot gnu dot org  2008-03-04 09:14 -------
> The original motivation for this report was that I was trying to reproduce the
> occasional problem of error being called (a "this should never happen" sanity
> check) at this place in the code.  I thought I had managed to do that with the
> bugzilla reported simple sequence of events immediately after starting emacs. 
> Does your finding suggest that my supposed reproduction of the error call was
> an illusion?  (And that there is no miscompilation either.)

You really need to put the breakpoint on 'error' to be sure.  Source location
information is seriously shaken by optimization in the 4.x series of compilers
so I wouldn't rely on it to put breakpoints in optimized code.


-- 


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

[Bug middle-end/35249] miscompilation of Emacs at -O

[ebotcazou at gcc dot gnu dot org]

-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING


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

[Bug middle-end/35249] miscompilation of Emacs at -O

[simon dot marshall at misys dot com]

------- Comment #12 from simon dot marshall at misys dot com  2008-03-10 10:28 -------
> You really need to put the breakpoint on 'error' to be sure.  Source location
> information is seriously shaken by optimization in the 4.x series of compilers
> so I wouldn't rely on it to put breakpoints in optimized code.

I put the call of error into a new function and put a breakpoint on that.  The
breakpoint on the new function is not hit when Emacs is starting.  So, I can
only conclude that the underlying problem is not a miscompilation by gcc.

It seems to me that the underlying problem, which I still see and leads to the
breakpoint on the new function being eventually hit when Emacs has been running
for some time, is a bug in Emacs.  Does that seem reasonable?

Sorry for the wasted time, and thanks for looking at this.


-- 


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

[Bug middle-end/35249] miscompilation of Emacs at -O

[ebotcazou at gcc dot gnu dot org]

------- Comment #13 from ebotcazou at gcc dot gnu dot org  2008-03-10 10:36 -------
> I put the call of error into a new function and put a breakpoint on that.
> The breakpoint on the new function is not hit when Emacs is starting.  So,
> I can only conclude that the underlying problem is not a miscompilation by
> gcc.

Thanks for experimenting.

> It seems to me that the underlying problem, which I still see and leads to
> the breakpoint on the new function being eventually hit when Emacs has been
> running for some time, is a bug in Emacs.  Does that seem reasonable?

Probably.  You can try to recompile the whole Emacs at -O0 though and see what
happens.  Reopen the ticket if it behaves differently than at -O2.


-- 

ebotcazou at gcc dot gnu dot org changed:

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


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