wrong-code regressions review

wrong-code regressions review

[Nathanael Nerode]

So, the bugs I worry about most are wrong-code regressions.  :-)

What strikes me most about these 25 bugs is the ones which appear
close to being fixed, but have sort of stalled.

Appear stalled (5):
17913:
  Patch available, needs global maintainer review
17053:
  Collect2 bug.  DJE said in August that he was developing a fix; no
  news since then.
18257:
  Tentative patch in October, no news since then
18191:
  Should default initializers be produced in the front end?  If so,
  this should have its component changed and be cloned.
18019:
  Pentium4.  Jan said he would write a patch "today" on the 2nd, no news
  since then
13300:
  "Withdrawn" patches, because of lack of review.  Still needed.  :-(

Appear in good shape (4):
15486:
  Fixed, fix being committed :-)
18666:
  Probably not-a-bug
18888:
  Jeff Law is actively working on it, I think.
18665:
  Patches in progress, should be fixed soon

Unknown (8):
17949:
  IVOPTS alignment bug.
18241:
  Not tracked down yet.
18628:
  Difficult interaction between passes, needs a CFG guru
18897:
  Analyzed, no patch yet
18785:
  Not much progress yet
17603:
  Not yet tracked down.
18916:
  No idea.
18987:
  New, no idea.

Don't look like anyone cares (7):
10692:
  Nobody's looking at it because nobody maintains m68k.  ;-/
14798:
  SH problems; SH maintainers have not looked at it, as far as I can see.
18701, 18330, 18346, 18329:
  MMIX problems, no analysis.
18170:
  No analysis.  m32r maintainer has not commented.

-- 
This space intentionally left blank.

Re: wrong-code regressions review

[Jeffrey A Law]

On Tue, 2004-12-14 at 14:52 -0500, Nathanael Nerode wrote:

> 18888:
>   Jeff Law is actively working on it, I think.
Yes.  I'll have the regression tests finished shortly.  Barring any
problems it ought to be wrapped up in an hour or so.

jeff

Re: wrong-code regressions review

[David Edelsohn]

>>>>> Nathanael Nerode writes:

Nathanael> Collect2 bug.  DJE said in August that he was developing a fix; no
Nathanael> news since then.

	This still is in progress, but more difficult to solve than
originally thought.  Also, this failure only occurs with infrequently used
-frepo option and artificial example programs, so it is not a high
priority when GCC developer find so many other creative ways to break GCC
on AIX :-).

David

Re: wrong-code regressions review

[Bradley Lucier]

On Dec 15, 2004, at 4:29 PM, Daniel Jacobowitz wrote:

> On Wed, Dec 15, 2004 at 04:23:39PM -0500, Bradley Lucier wrote:
>> (gdb) info locals
>> ___pc = dwarf2_read_address: Corrupted DWARF expression.
>
> This is some new bug in GDB I haven't seen before.
>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x081541ae in ___H__20___front (___ps=0x8481ea0) at _front.c:7075
>> 7075       ___SET_R2(___FIXMAX(___R3,___R2))
>> (gdb) info locals
>> ___pc = 137816529
>> ___start = 137799889
>> ___temp = Variable "___temp" is not available.
>
> This means GDB thinks it is in a call clobbered register.  It shouldn't
> happen in the topmost frame, so I don't know what's wrong.  I'd have to
> see the debug info.

After some more advice from Daniel, I've put the following information 
at

http://www.math.purdue.edu/~lucier/GNATS/GNATS-17

in the directories fomit-frame-pointer and fno-omit-frame-pointer.

gsc: the executable under x86-linux with

[lucier@cohomology gsc]$ uname -a
Linux cohomology 2.4.21-20.EL #1 Wed Aug 18 20:58:25 EDT 2004 i686 i686 
i386 GNU/Linux

fib.scm: the data that causes the executable to crash
_front.[iso]: The results from save-temps in the file where it crashes.
transcript: The transcript of the gdb sessions where these things 
happen, together with the compile lines.

Brad

Re: wrong-code regressions review

[Giovanni Bajo]

Bradley Lucier <lucier@math.purdue.edu> wrote:

> Should I be able to use "info locals"?  Or "p var_name"?  When I
> compile code with [...]


You probably want to report this to the GDB team.
-- 
Giovanni Bajo

Re: wrong-code regressions review

[Daniel Jacobowitz]

On Wed, Dec 15, 2004 at 04:23:39PM -0500, Bradley Lucier wrote:
> (gdb) info locals
> ___pc = dwarf2_read_address: Corrupted DWARF expression.

This is some new bug in GDB I haven't seen before.

> Program received signal SIGSEGV, Segmentation fault.
> 0x081541ae in ___H__20___front (___ps=0x8481ea0) at _front.c:7075
> 7075       ___SET_R2(___FIXMAX(___R3,___R2))
> (gdb) info locals
> ___pc = 137816529
> ___start = 137799889
> ___temp = Variable "___temp" is not available.

This means GDB thinks it is in a call clobbered register.  It shouldn't
happen in the topmost frame, so I don't know what's wrong.  I'd have to
see the debug info.

-- 
Daniel Jacobowitz

Re: wrong-code regressions review

[Bradley Lucier]

On Dec 15, 2004, at 10:14 AM, Giovanni Bajo wrote:

> Bradley Lucier <lucier@math.purdue.edu> wrote:
>
>> Can you recommend a debugger that will give me accurate information on
>> sparc-solaris2.9 or x86-linux?
>
> Most developers and I use GDB 6.1 or CVS HEAD. What's wrong with that? 
> What
> are you missing exactly?

Should I be able to use "info locals"?  Or "p var_name"?  When I 
compile code with

gcc -g -I../include -Wall -W -Wno-unused -O1 -fno-math-errno 
-fschedule-insns2 -fno-trapping-math -fno-strict-aliasing 
-fomit-frame-pointer -fPIC -fno-common -mieee-fp -DHAVE_CONFIG_H -c 
_front.c

this doesn't seem to work:

[lucier@cohomology gambit]$ env GAMBCDIR=../../../lib gdb  
../../../gsc/gsc
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and 
you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for 
details.
This GDB was configured as "i686-pc-linux-gnu"...Using host 
libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run  -:=../../.. fib.scm
Starting program: /home/lucier/programs/gambc40b11/gsc/gsc -:=../../.. 
fib.scm

Program received signal SIGSEGV, Segmentation fault.
0x081562c8 in ___H__20___front (___ps=0x8486700) at _front.c:7075
7075       ___SET_R2(___FIXMAX(___R3,___R2))
(gdb) ,e
Undefined command: "".  Try "help".
(gdb) info locals
___pc = dwarf2_read_address: Corrupted DWARF expression.
(gdb) p ___r4
Variable "___r4" is not available.
(gdb) p ___r1
Variable "___r1" is not available.
(gdb) p ___r2
Variable "___r2" is not available.

and if I compile it without the -fomit-frame-pointer, I get

[lucier@cohomology gambit]$ env GAMBCDIR=../../../lib gdb  
../../../gsc/gsc
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and 
you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for 
details.
This GDB was configured as "i686-pc-linux-gnu"...Using host 
libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run  -:=../../.. fib.scm
Starting program: /home/lucier/programs/gambc40b11/gsc/gsc -:=../../.. 
fib.scm

Program received signal SIGSEGV, Segmentation fault.
0x081541ae in ___H__20___front (___ps=0x8481ea0) at _front.c:7075
7075       ___SET_R2(___FIXMAX(___R3,___R2))
(gdb) info locals
___pc = 137816529
___start = 137799889
___temp = Variable "___temp" is not available.
(gdb) p ___r3
Variable "___r3" is not available.

and if I use the built-in gdb 6.1:

[lucier@cohomology gambit]$ env GAMBCDIR=../../../lib /usr/bin/gdb 
../../../gsc/gsc
GNU gdb Red Hat Linux (6.1post-1.20040607.17rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and 
you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for 
details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host 
libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run  -:=../../.. fib.scm
Starting program: /home/lucier/programs/gambc40b11/gsc/gsc -:=../../.. 
fib.scm

Program received signal SIGSEGV, Segmentation fault.
0x081541ae in ___H__20___front (___ps=0x8481ea0) at _front.c:7075
7075       ___SET_R2(___FIXMAX(___R3,___R2))
(gdb) info locals
___pc = 137816529
___start = 137799889
___temp = Variable "___temp" is not available.
(gdb)

Re: wrong-code regressions review

[Giovanni Bajo]

Bradley Lucier <lucier@math.purdue.edu> wrote:

> Can you recommend a debugger that will give me accurate information on
> sparc-solaris2.9 or x86-linux?

Most developers and I use GDB 6.1 or CVS HEAD. What's wrong with that? What
are you missing exactly?

> One thing that makes it a bit difficult is that I can only tickle the
> bug when I compile the complete Scheme file into one C function; when I
> compile each Scheme function to one C function then it doesn't break in
> the same way.

I see. Maybe you can start reducing the Scheme file, so that you reduce the
code you generate. After that, you can work on the preprocessed C source.
-- 
Giovanni Bajo

Re: wrong-code regressions review

[Bradley Lucier]

On Dec 15, 2004, at 8:12 AM, Giovanni Bajo wrote:

> you could for instance start by analyzing the
> assembly code to find out the miscompilation at assembly level.

I am willing to do this, and I have done this in the past for other 
problems.

Can you recommend a debugger that will give me accurate information on 
sparc-solaris2.9 or x86-linux?  (I just backed out the special cctools 
that are needed on powerpc-darwin because I couldn't seem to build 
something I needed from fink on MacOS X.)

One thing that makes it a bit difficult is that I can only tickle the 
bug when I compile the complete Scheme file into one C function; when I 
compile each Scheme function to one C function then it doesn't break in 
the same way.

Brad

Re: wrong-code regressions review

[Bradley Lucier]

On Dec 15, 2004, at 8:42 AM, Andrew Pinski wrote:

> And I would try again since there was a fix recently with respect with
> computed gotos.

It failed with this compiler yesterday:

[lucier@cohomology gambc40b11]$ ~/local/bin/gcc -v
Reading specs from 
/home/lucier/local/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../configure --prefix=/home/lucier/local/ 
--enable-languages=c --enable-checking=no
Thread model: posix
gcc version 4.0.0 20041215 (experimental)

Re: wrong-code regressions review

[Andrew Pinski]

On Dec 15, 2004, at 8:12 AM, Giovanni Bajo wrote:

> Bradley Lucier <lucier@math.purdue.edu> wrote:
>
>> 18548 is a regression (and it's not target specific, it happens on
>> sparc-solaris, x86-linux, and ppc-darwin), but it's very hard to 
>> figure
>> out what is causing the current problem.  There were two previous
>> wrong-code regressions on this code base that have been fixed by
>> unrelated patches, so I don't know if fixing 18548 will just bring
>> other problems to the surface.
>
> 34MB of preprocessed files is really too much. If you are really 
> interested
> in having this fixed (instead of waiting it to be caught and fixed 
> through a
> different testcase/language), you could for instance start by 
> analyzing the
> assembly code to find out the miscompilation at assembly level. If you 
> spot
> that, you can start reducing it even without begin able to run the file
> (just compiling it and looking at the assembly). When the testcase is 
> small,
> it's easy to reconstruct something around it to make it runnable.

And I would try again since there was a fix recently with respect with
computed gotos.

Thanks,
Andrew Pinski

Re: wrong-code regressions review

[Giovanni Bajo]

Bradley Lucier <lucier@math.purdue.edu> wrote:

> 18548 is a regression (and it's not target specific, it happens on
> sparc-solaris, x86-linux, and ppc-darwin), but it's very hard to figure
> out what is causing the current problem.  There were two previous
> wrong-code regressions on this code base that have been fixed by
> unrelated patches, so I don't know if fixing 18548 will just bring
> other problems to the surface.

34MB of preprocessed files is really too much. If you are really interested
in having this fixed (instead of waiting it to be caught and fixed through a
different testcase/language), you could for instance start by analyzing the
assembly code to find out the miscompilation at assembly level. If you spot
that, you can start reducing it even without begin able to run the file
(just compiling it and looking at the assembly). When the testcase is small,
it's easy to reconstruct something around it to make it runnable.
-- 
Giovanni Bajo

Re: wrong-code regressions review

[Bradley Lucier]

18548 is a regression (and it's not target specific, it happens on 
sparc-solaris, x86-linux, and ppc-darwin), but it's very hard to figure 
out what is causing the current problem.  There were two previous 
wrong-code regressions on this code base that have been fixed by 
unrelated patches, so I don't know if fixing 18548 will just bring 
other problems to the surface.

Brad