Re: Strange bug in GCC-Optimization

Re: Strange bug in GCC-Optimization

[Mike Stump]

> Date: Mon, 24 Jul 2000 00:27:24 +0200
> From: Norbert Nemec <nobbi@cheerful.com>
> To: gcc-bugs@gcc.gnu.org

> I would love to send you the offending code, but it is, as I said, machine
> generated, and therefore extremely ugly, and I do not know, how I should
> separate out the offending piece. It is something like:

> Do you have any ideas what to do?

Three possibilities come to mind.  One, check a recent snapshot, and
assume that if it works, that the bugs has been fixed and do nothing.
See gcc.gnu.org for snapshots.

Two, do nothing and hope that someone else can find and report the
bug.  In time, someone will, but it could take a few years.

Three, find a testcase, and send it in.


Off hand, I'd recommend one, then three.  I can help you with option
three.  First, run gcc -E to get the output of the preprocessor.  This
gives you a testcase, worse case scenario.  From there, if you can
trim it up, that would be helpful. I'd start by removing the end of
the file (all functions past the one in question) and see if that
still can reproduce it.  From there, you can remove all non-dependent
code before the function, verifying the testcase still works as you
go.  Then you can remove all non-dependent code in the function,
verifying as you go.  After those steps, one usually has about 5-20
lines of testcase.

The benefit of finding the small testcase, is that it can be added to
the testsuite and we can ensure that no future gcc release contains
that bug.

Bear in mind, even if you cannot trim the testcase, you can still put
it up for anon ftp or put it on the web, and mail a pointer to the
larger testcase.  Just be sure to include pointers to the wrong
routine and what is wrong with it.  Pointers into the assembly is
nice.

Hope this helps.
>From mrs@windriver.com Mon Jul 24 11:40:00 2000
From: Mike Stump <mrs@windriver.com>
To: aoliva@redhat.com, root@ihack.net
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: UltraSPARC 16-bit assignments severely broken [analysis]
Date: Mon, 24 Jul 2000 11:40:00 -0000
Message-id: <200007241840.LAA02089@kankakee.wrs.com>
X-SW-Source: 2000-07/msg00612.html
Content-length: 1029

> Date: Sun, 23 Jul 2000 22:54:11 -0400 (EDT)
> From: "Charles M. Hannum" <root@ihack.net>
> To: Alexandre Oliva <aoliva@redhat.com>

> That is, unfortunately, a rather unhelpful answer.  The point of this
> exercise is that I *need* a working UltraSPARC compiler, badly enough
> that I'm willing to fix it myself.  I just want to know if people have
> specific thoughts on which way I should do it.

gcc is a better place to ask such questions than gcc-bugs.
gcc-patches could be an even better place, though the way I normally
would do that, is to come up with what I think are the best patches to
solve a problem, and then send them in.  You can discuss the
alternatives and limitations in the patch email, and ask, or is it
better to do it the other way?  By sending in a solution, it lets
others kow that you're serious about it, and don't mind rolling up
your sleeves.

Not all the people that read gcc and gcc-patches read gcc-bugs.

Also, if you submit work, you'll need a copyright disclaimer on file,
see the web site.
>From mrs@windriver.com Mon Jul 24 12:15:00 2000
From: Mike Stump <mrs@windriver.com>
To: Derek.Coleman@meluksoft.co.uk, gcc-bugs@gcc.gnu.org
Subject: Re: REF: c & C++
Date: Mon, 24 Jul 2000 12:15:00 -0000
Message-id: <200007241915.MAA02131@kankakee.wrs.com>
X-SW-Source: 2000-07/msg00613.html
Content-length: 1368

> From: Derek Coleman <Derek.Coleman@meluksoft.co.uk>
> To: "'gcc-bugs@gcc.gnu.org'" <gcc-bugs@gcc.gnu.org>
> Date: Mon, 24 Jul 2000 10:04:17 +0100

> From: Derek E Coleman M.Eng (Elec & Comp Sci), I.Eng MIIE(elec).

This is redundant with the line above, you can remove it.

> Email  < mailto:Derek.Coleman@meluksoft.co.uk >

This is redundant with the line above, you can remove it.

> Date: Monday 24th July 2000

This is redundant with the line above, you can remove it.

> I wonder if someone can help me.

I can only try.

> My source code project is large.  It consists of old C source files,
> written by others and new C++ source I wish to link with old C in
> other files.

> My problem follows:
> 	I have to compile C with -x c and C++ with -x c++.

Or you can use file suffixes like .cpp or .C for C++ code and .c for C
code.  Or you can use gcc to compile C files, and g++ to compile C++
files...  Lots of possibilities.  I'd not recommend what your doing.

> Otherwise the old code throws up errors. If I try and compile the
> old code via c++ the, strict type checking stops the compilation.
> Using -x c allows me to compile sucessfully.

> If it is calling static member functions I cant re-write all the old
> source code, theres loads of it.

> Any ideas?

You can have a forwarding extern "C" function that forwards to the
static member functions.
>From gdr@codesourcery.com Mon Jul 24 13:14:00 2000
From: Gabriel Dos Reis <gdr@codesourcery.com>
To: gcc-bugs@gcc.gnu.org
Subject: Current CVS bootstrap failure on x86
Date: Mon, 24 Jul 2000 13:14:00 -0000
Message-id: <m3em4j2sok.fsf@merlin.codesourcery.com>
X-SW-Source: 2000-07/msg00614.html
Content-length: 1147

Current CVS won't bootstrap on an i686-pc-linux.  The failure occurs
at the same point while building libstdc++  with
--enable-checking=tree or not.  It appears to be related to tree-based
inlining.

In file included from /home/gdr/egcs/libstdc++/std/bastring.h:349:
/home/gdr/egcs/libstdc++/std/bastring.h: In instantiation of `basic_string<charT, traits, Allocator>::clear () [with charT = char, traits = string_char_traits<char>, Allocator = __default_alloc_template<true, 0>]':
/home/gdr/egcs/libstdc++/sinst.cc:55:   instantiated from here
/home/gdr/egcs/libstdc++/std/bastring.h:282: Tree check: expected stmt_expr, have scope_stmt
/home/gdr/egcs/libstdc++/std/bastring.h:282: Internal compiler error in expand_call_inline, at 
cp/optimize.c:739
Please submit a full bug report.
See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.


Configure options were

	--enable-languages='c++' --enable-shared --enable-checking=tree


I tend to think that the problem is plateform independent; if so then
I'm wondering how people are managing to bootstrap with current CVS...

-- Gaby
CodeSourcery, LLC		http://www.codesourcery.com
>From geoffk@cygnus.com Mon Jul 24 15:30:00 2000
From: Geoff Keating <geoffk@cygnus.com>
To: "Charles M. Hannum" <root@ihack.net>
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: UltraSPARC 16-bit assignments severely broken [analysis]
Date: Mon, 24 Jul 2000 15:30:00 -0000
Message-id: <jmwvib6u1h.fsf@envy.cygnus.com>
References: <200007230316.e6N3GLn02381@lop-nor.ihack.net>
X-SW-Source: 2000-07/msg00615.html
Content-length: 544

"Charles M. Hannum" <root@ihack.net> writes:

> The problem has to do with loop hoisting and movhi.  When the parser
> generates the 16-bit assignment inside the loop,
> sparc_emit_set_const32() splits it into a two-part load:
> 
> (insn 21 19 22 (set (reg:HI 110)
>         (const_double (const_int 0 [0x0]) -32768 [0xffff8000] 0 [0x0] 0 [0x0] 0 [0x0] 0 [0x0])) -1 (nil)
>     (nil))

This is wrong.  It should be:

(insn 21 19 22 (set (reg:HI 110)
         (const_int -32768)) -1 (nil)
     (nil))

-- 
- Geoffrey Keating <geoffk@cygnus.com>
>From jason@redhat.com Mon Jul 24 16:35:00 2000
From: Jason Merrill <jason@redhat.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: Generating self-referential typedefs in debug info
Date: Mon, 24 Jul 2000 16:35:00 -0000
Message-id: <u9k8ebrtj9.fsf@yorick.soma.redhat.com>
References: <m2puo4nrgo.fsf@localhost.localdomain>
X-SW-Source: 2000-07/msg00616.html
Content-length: 79

I'm unable to reproduce this bug with the current development compiler.

Jason
>From poole@troilus.org Mon Jul 24 17:07:00 2000
From: Michael Poole <poole@troilus.org>
To: gcc-bugs@gcc.gnu.org
Subject: ICE #40 in trivial C++ code
Date: Mon, 24 Jul 2000 17:07:00 -0000
Message-id: <m3aef7cbs1.fsf@troilus.org>
X-SW-Source: 2000-07/msg00617.html
Content-length: 1113

On i686-pc-linux-gnu, using the STL-using program below, gcc (from
current CVS) gets an ICE.  I've tried simplifying the code to isolate
what in the return type causes problems, but have been unable to do so
(std::string does not cause the ICE, and I'm not familiar enough with
C++ or the STL to know why std::list might if std::string doesn't).

This is a much pared-down version of a bug I sent mail about last
week, but I'm unsure if I can pare it down any farther without doing
more digging than I have time for this week.

-- Michael

[poole@troilus ~/src/test]% g++ -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.96/specs
gcc version 2.96 20000724 (experimental)
[poole@troilus ~/src/test]% g++ test.cpp
test.cpp: In function `list<int, allocator<int> > fancy ()':
test.cpp:3: Internal error #40.
test.cpp:3: Internal compiler error in cplus_expand_expr, at 
../gcc/gcc/cp/expr.c:159
Please submit a full bug report.
See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.
[poole@troilus ~/src/test]% cat test.cpp
#include <list>

std::list<int> fancy(void) return ls;
{
}
>From root@ihack.net Mon Jul 24 17:46:00 2000
From: "Charles M. Hannum" <root@ihack.net>
To: Geoff Keating <geoffk@cygnus.com>
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: UltraSPARC 16-bit assignments severely broken [analysis]
Date: Mon, 24 Jul 2000 17:46:00 -0000
Message-id: <200007250037.e6P0bq016407@lop-nor.ihack.net>
X-SW-Source: 2000-07/msg00618.html
Content-length: 746

>> (insn 21 19 22 (set (reg:HI 110)
>>         (const_double (const_int 0 [0x0]) -32768 [0xffff8000] 0 [0x0] 0 [0x0] 0 [0x0] 0 [0x0])) -1 (nil)
>>     (nil))
>
> This is wrong.  It should be:
>
> (insn 21 19 22 (set (reg:HI 110)
>          (const_int -32768)) -1 (nil)
>      (nil))

This is a special case for cross-compiling from a 32-bit platform.
See:


      if (TARGET_ARCH64
          && HOST_BITS_PER_WIDE_INT != 64
          && (INTVAL (op1) & 0x80000000) != 0)
        {

There's a comment elsewhere (that I'm failing to find now) that
suggests this is because somewhere in the bowels of the optimizer it
assumes that the value will be sign-extended.

Of course, given that we're doing a sethi, the upper bits don't
actually matter...