Re: C++ bug still in egcs-2.91.54 199808

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

At 02:00 25.08.98 , Alexandre Oliva wrote:
>Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
>
>> At 06:00 24.08.98 , Alexandre Oliva wrote:
>>> Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
>>> 
>>>> this small example will produce a corrupted assembler file if
>>>> compiled with g++ -S:
>>> 
>>>> extern "C" { untyped(int,int); void typed(int, int); }
>>> 
>>> On which platform?  I've got an empty assembly file (save for
>>> comments) on the platforms I've tried it.
>
>> I've tried this on i586-pc-linux-gnulibc1 and powerpc-unknown-linux-gnu,
>> ppc results in totally corrupted labels, i586 produces corrupt labels too,
>> but at least they are readable. Here a sample output on i586:
>
>Did you notice that egcs prints an error (not warning) message when
>presented this code snippet, and that it returns a non-zero exit
>status?  This indicates that the generated assembly code is known to
>be invalid; IMO, it should even be removed!

The problem here is I don't know if the error message is correct or is a
result of the bug. I think it's a result of the bug, but I have not enough
knowledge here to prove it.

>Anyway, generating unreadable labels is not correct, and might
>possibly affect correct programs, so this *is* a bug.
>
>> The problem is that untyped() gets assigned VAR_DECL instead of FUNC_DECL,
>> as reported in http://www.cygnus.com/ml/egcs-bugs/1998-Jun/0275.html.
>
>If you know what is the fix, will you please post a patch that fixes
>the problem to egcs-patches@cygnus.com?

I don't know what's the fix. That is what I saw in gdb and with
--enable-checking. But I got lost during debugging somewhere in parse.y/c
and I know nearly nothing about c++, so I was really happy I could track it
down that far.

Franz.