Re: Bug with egcs-19990428 on i586-pc-linux-gnulibc1 ?

Re: Bug with egcs-19990428 on i586-pc-linux-gnulibc1 ?

[Alexandre Oliva]

On Apr 29, 1999, Andrew Pollard <andrew@odie.demon.co.uk> wrote:

> struct A {
>         A(int=0, int=0);
> };
> #define B() static A _A(0)

> #define B() static A _A()

Despite the apparently similar syntax, these are two completely
different C++ declarations.

`A _A(0);' declares and defines an object named _A, and directly
initializes it with 0.

`A _A();', on the other hand, is just the declaration of a function
`_A', without arguments, returning an A.  There's no initialization to 
take place here, so the crash does not occur.  But we do indeed have a 
bug, because the first alternative should work too.

Suggested (untested) workaround: use unnamed namespaces instead of
static.

#define B() namespace { A _A(0); }

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: Bug with egcs-19990428 on i586-pc-linux-gnulibc1 ?

[Andrew Pollard]

Alexandre Oliva replied with:

>On Apr 29, 1999, Andrew Pollard <andrew@odie.demon.co.uk> wrote:
>
>> struct A {
>>         A(int=0, int=0);
>> };
>> #define B() static A _A(0)
>>
>> #define B() static A _A()

>Despite the apparently similar syntax, these are two completely
>different C++ declarations.
>
>`A _A(0);' declares and defines an object named _A, and directly
>initializes it with 0.
>
>`A _A();', on the other hand, is just the declaration of a function
>`_A', without arguments, returning an A.  There's no initialization to 
>take place here, so the crash does not occur.

True... I realised this when I saw your message... I was too much trying
to cut down on the example (it first appeared in a huge program, and I
was trying to get the example as small as possible...)

What I meant to write was :-) the following

main.cxx:
------------------------------------------------------------------------
#include "A.h"
B();
int main() { return(0); }
------------------------------------------------------------------------
A.h:
------------------------------------------------------------------------
struct A {
        A(int, int);
};
#define B() static A _A(0, 0)
------------------------------------------------------------------------
A.cxx:
------------------------------------------------------------------------
#include "A.h"
B();
A::A(int, int) {}
------------------------------------------------------------------------

Fails, with 'g++ -O main.cxx' A.cxx, but

A.h:
------------------------------------------------------------------------
struct A {
        A(int);
};
#define B() static A _A(0)
------------------------------------------------------------------------
A.cxx:
------------------------------------------------------------------------
#include "A.h"
B();
A::A(int) {}
------------------------------------------------------------------------

works.... (ie, with only one parameter to A() is fine, two aren't)

>But we do indeed have a bug, because the first alternative should work too.

Good, I thought so.

>Suggested (untested) workaround: use unnamed namespaces instead of
>static.
>
>#define B() namespace { A _A(0); }

Nope, 'fraid not. Same crash in __do_global_ctors_aux :-(

Andrew.
--
Andrew Pollard, Auto Simulations Ltd. UK. | home: andrew@odie.demon.co.uk
2 Milbanke Court, Milbanke Way, Bracknell | work: Andrew_Pollard@autosim.com
Tel/Fax: (+44(0)1344) 426486x103 / 426615 | http://www.odie.demon.co.uk

Bug with egcs-19990428 on i586-pc-linux-gnulibc1 ?

[Andrew Pollard]

Hi All,

[ System: Linux-2.0.36-SMP, libc-5.4.46, binutils-2.9.1.0.22b

  egcs  : egcs-19990428 snapshot, configured with
  % ./configure --prefix=/usr --with-gnu-as --with-gnu-ld --enable-version-specific-runtime-libs --enable-shared
	and 3 stage compiled with
  % make CFLAGS='-O2' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap
]

With the following pieces of code (which were whittled down from some
source code at work...)

A.h:
------------------------------------------------------------------------
struct A {
        A(int=0, int=0);
};
#define B() static A _A(0)
------------------------------------------------------------------------

A.cxx:
------------------------------------------------------------------------
#include "A.h"
B();
A::A(int, int) {}
------------------------------------------------------------------------

main.cxx:
------------------------------------------------------------------------
#include "A.h"
B();
int main() { return(0); }
------------------------------------------------------------------------

% g++ -v
Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnulibc1/egcs-2.93.20/specs
gcc version egcs-2.93.20 19990427 (gcc2 ss-980929 experimental)
% g++ main.cxx A.cxx
% a.out
% g++ -O main.cxx A.cxx
% a.out
Segmentation fault
% g++ -O -g main.cxx A.cxx
% gdb a.out
GNU gdb 4.17.0.11 with Linux support
Copyright 1998 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 "i586-pc-linux"...
(gdb) run
starting program: /home/andrew/bugs/track/a.out 

Program received signal SIGSEGV, Segmentation fault.
0x80485d4 in __do_global_ctors_aux ()
(gdb) where
#0  0x80485d4 in __do_global_ctors_aux ()
(gdb)

By changing A.h to be (ie removing the '0' from the _A(0))

A.h:
------------------------------------------------------------------------
struct A {
        A(int=0, int=0);
};
#define B() static A _A()
------------------------------------------------------------------------

It works fine.

It also works with gcc2722, egcs103 and egcs112.

It also fails with the CVS tree of late Apr28 (UK time).

Am I doing something silly? Or is this actually a problem with egcs?

I hope there is enough information here, if not, please contact me.

Cheers,
 Andrew.
--
Andrew Pollard, Auto Simulations Ltd. UK. | home: andrew@odie.demon.co.uk
2 Milbanke Court, Milbanke Way, Bracknell | work: Andrew_Pollard@autosim.com
Tel/Fax: (+44(0)1344) 426486x103 / 426615 | http://www.odie.demon.co.uk
>From dglo@SSEC.WISC.EDU Fri Apr 30 23:15:00 1999
From: Dave Glowacki <dglo@SSEC.WISC.EDU>
To: egcs-bugs@egcs.cygnus.com
Subject: 1.1.1 coredump; known bug?
Date: Fri, 30 Apr 1999 23:15:00 -0000
Message-id: <199904271942.OAA06992@tick.ssec.wisc.edu>
X-SW-Source: 1999-04n/msg00776.html
Content-length: 792

Compiling the following routine with EGCS 1.1.1 on an AIX 4.3.1 system
results in an eventual coredump (after 'cc1' consumes all available
memory.)  Is this something that's fixed in 1.1.2?


	/*
	 * compile with 'gcc -O -c source.c'
	 * using egcs 2.91.60 on rs6000-ibm-aix4.3.1.0
	 *
	 * EGCS doesn't break if '-O' is not used
	 */
	void
	foo(int *g)
	{
	  /* EGCS doesn't break if 'd' isn't a pointer */
	  static const int *d;
	  int i;

	  /* EGCS doesn't break if subtracted value is less than this */
	  g -= 16385;

	  /* EGCS doesn't break if the next two lines are changed to
	   * either 'i = 0; g[i] = d;' or 'g[0] = *d;'
	   */
	  for (i = 0; i < 1; i++)
	    g[i] = *d;
	}

(Sorry, I don't read this mailing list.  I'd appreciate it if you would
 forward any replies to me...)