egcs 19990629 (arm/aout) static member vars end up in common

egcs 19990629 (arm/aout) static member vars end up in common

[Luke Diamand]

Hi!

I'm using gcc-2.95 19990629 (prerelease) and I find that, compared to
the last version I used (egcs1.1b) it has started to put some symbols
into common (.comm) that it never used to.

The sort of code that provokes this looks like the following:

        class Foo
        {
                static int x;
        };

        int Foo::x;


I get the following:

    .comm   __3Foo.x, 4     @ 4

Sadly, my assembler and linker (non-gnu) do not understand .comm.

I don't think this is really a bug in gcc, and since I intend to try to
switch to gas/ld, it may be that I'm the only person in the world who is
ever going to care.

The problem seems to be in comdat_linkage() in gcc/cp/decl2.c which
makes the symbol common unless it's a function or a vtable, where before
it didn't.

The following patch seems to fix the problem for me (as far as I can
tell) by making the symbol public rather than common. But I suspect that
this patch is actually wrong for targets with working assemblers and
linkers. Can anyone suggest a more sane approach? Does anyone really
care?


Thanks in advance!
Luke Diamand

*** decl2.c.orig        Tue Jul  6 17:19:37 1999
--- decl2.c     Wed Jul  7 14:19:28 1999
***************
*** 2441,2450 ****
--- 2441,2458 ----
  {
    if (flag_weak)
      make_decl_one_only (decl);
+ 
    else if (TREE_CODE (decl) == FUNCTION_DECL || DECL_VIRTUAL_P (decl))
      /* We can just emit functions and vtables statically; it doesn't
really
         matter if we have multiple copies.  */
      TREE_PUBLIC (decl) = 0;
+ 
+   /* we have a losing build system, so just make it a public symbol
and
+    * hope for the best.
+    */
+   else if ( !supports_one_only() )
+     TREE_PUBLIC(decl) = 1;
+ 
    else
      {
        /* Static data member template instantiations, however, cannot


-- 
Virata http://www.virata.com
Cambridge
Tel: +44 1223 566919      Fax: +44 1223 566915
>From p.dalgaard@biostat.ku.dk Wed Jul 07 07:05:00 1999
From: Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk>
To: Vin Everett <vin.everett@mrc-bsu.cam.ac.uk>
Cc: egcs-bugs@egcs.cygnus.com, p.dalgaard@biostat.ku.dk, plummer@iarc.fr
Subject: Re: Problem with egcs and sparc linux
Date: Wed, 07 Jul 1999 07:05:00 -0000
Message-id: <x2r9mkbler.fsf@blueberry.kubism.ku.dk>
References: <199907071032.LAA07160@bernstein.mrc-bsu.cam.ac.uk>
X-SW-Source: 1999-07/msg00250.html
Content-length: 2574

Vin, I think you need to give a little more info:

Vin Everett <vin.everett@mrc-bsu.cam.ac.uk> writes:

> Hello,
> 
> I have a problem with egcs running on redhat6.0 on sparc.
> 
> [vin@beethoven ~]$ egcs -v
> Reading specs from /usr/lib/gcc-lib/sparc-redhat-linux/egcs-2.91.66/specs
> gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
> 
> 
> [vin@beethoven ~]$ g77 -v
> g77 version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) (from FSF-g77 version 0.5.24-19981002)
> 
> 
> Its a sparc ultra1, and I am trying to rebuild the public domain version of R
                                                     ^^^^^^^^^^^^^^^^^^^^^

Ahem. All versions of R are GPL'ed. Raw sources can be had from e.g.
http://sunsite.auc.dk/R/src/base/R-0.64.1.tgz  (there's a 0.64.2 out
now, but I strongly doubt that it changes any of this).

> R-base-0.64.1-6.src.rpm  The compile goes Ok and I get a working binary but 
> the problem comes when it tries to do the tests which are in fortran.

> gdb output :-
> > The line that crashes it:- 
> > eigen(cbind(-1,c(1:2,0),0:2)) # complex values
> > 
> > held by the break and gets changed at:-
> > 1830             DO 40 J = K, N
> > 1: nm = (PTR TO -> ( integer )) 0x1
> >

The actual crash is a bit further down in the function, but relates to
the H array which is declared H(NM,N). We suspect that the NM value
gets overwritten before the routine is through using it. The sudden
change to NM shown in the trace below doesn't happen on Intel
architecture and as far as I know Alphas do not crash either.

> ... 
> > (gdb) 
> > 1823          IERR = 0
> > 1: nm = (PTR TO -> ( integer )) 0x70d99fd0
> > (gdb) 
> > 1828          DO 50 I = 1, N
> > 1: nm = (PTR TO -> ( integer )) 0x70d99fd0
> > (gdb) 
> > 1830             DO 40 J = K, N
> > 1: nm = (PTR TO -> ( integer )) 0x1
> > (gdb) 
> > 1831       40    NORM = NORM + DABS(H(I,J))
> > 1: nm = (PTR TO -> ( integer )) 0x1
> > (gdb) 
> > 1834             IF (I .GE. LOW .AND. I .LE. IGH) GO TO 50
> > 1: nm = (PTR TO -> ( integer )) 0x1

(my earlier comment:)
> 
> > Ouch. This looks very much like a compiler bug. Generally, this sort
> > of thing happens because the compiler *thinks* it is through using a
> > location or register and starts using it for other purposes. Then when
> > it needs it later on, ...


-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907
>From craig@jcb-sc.com Wed Jul 07 07:11:00 1999
From: craig@jcb-sc.com
To: martin.kahlert@provi.de
Cc: craig@jcb-sc.com
Subject: Re: Bug with g77 and -mieee on Alpha Linux
Date: Wed, 07 Jul 1999 07:11:00 -0000
Message-id: <19990707140435.1429.qmail@deer>
References: <199907062042.WAA00509@keksy.linux.provi.de>
X-SW-Source: 1999-07/msg00252.html
Content-length: 2194

>Perhaps i have done something wrong, but i thought, -mieee should 
>prevent these FPE's from occuring?

I don't know, it might/should, though I don't know offhand what the
FP value you're trying to print actually is.  (It seems unlikely to
be a signaling NaN, but, if that *was* what you're trying to print,
I could understand why you got an FPE.)

There are two things that might be working, together or separately, to
give you trouble:

  1.  You're supplying your own main(), but not running the libg2c
      initialization code libg2c's main() normally runs.  See the
      g77 docs for more info.  (Though in your example you wouldn't
      need to call the routine to set up command-line info, you might
      in the product code from which you derived the example.  And,
      in both examples, setting up the signal stuff might be necessary.)

  2.  You're using libg2c to print the FP value, but libg2c *itself*
      has (presumably) not been compiled with -mieee.

      I had assumed (erroneously, as I recently discovered) that gcc
      automatically used multilibs to produce -mieee-compiled libraries
      for Alpha targets, because, without that, libraries can crash (and
      libg2c apparently *will* crash doing, e.g., output of floating-point
      values that require -mieee).

  3.  You're not supplying `-mieee' when linking the object files, so
      even if there *was* a libg2c.a built with -mieee available (and
      properly configured, whatever that means), you'd pick up the default
      one and, if #2 is correct, crash anyway.

My own opinion is that this sort of thing is insanely painful to deal with,
and that the default should have been -mieee all along (both for gcc and
for Digital's compilers, but I assume the latter have all-along offered
easier ways to get the -mieee behavior), with an option (-mno-ieee) being
needed to get -mno-ieee performance.

But the philosophy of most software designers these days seems to be
"make it fast, then offer the user a variety of tweaks to make it work
more slowly".  (The same philosophy is why gcc won't ever default to
80-bit spills of 80-bit FP registers on the x86, I'm afraid.)

        tq vm, (burley)
>From craig@jcb-sc.com Wed Jul 07 07:11:00 1999
From: craig@jcb-sc.com
To: toon@moene.indiv.nluug.nl
Cc: craig@jcb-sc.com
Subject: Re: g77/gdb and complex numbers.
Date: Wed, 07 Jul 1999 07:11:00 -0000
Message-id: <19990707140715.1443.qmail@deer>
References: <19990706133229.A389@shef.ac.uk> <37825FBC.F3DC852D@moene.indiv.nluug.nl>
X-SW-Source: 1999-07/msg00251.html
Content-length: 590

>You named the executable `test'.  Don't do that.  It will run better by
>any other name.

Better still, remove `.' from your PATH environment variable (or equivalent)
and always invoke programs in the current directory explicitly, via
`./test'.

That way, you significantly reduce your exposure to various ills, such
as software viruses, trojan horses, buggy software, and the like.

(For example, this approach makes it much less likely that, after
doing `tar xf some-archive.tar', the next `ls' command will have been
turned into a script that does `rm -fr ~'.)

        tq vm, (burley)
>From pfeifer@dbai.tuwien.ac.at Wed Jul 07 07:18:00 1999
From: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
To: egcs-bugs@egcs.cygnus.com
Cc: Bruce Korb <ddsinc09@ix.netcom.com>, Jeffrey A Law <law@cygnus.com>, obrien@nuxi.com
Subject: Re: fixinc related\(!\) bootstrap failure on freebsd-3.2
Date: Wed, 07 Jul 1999 07:18:00 -0000
Message-id: <Pine.GSO.4.10.9907071555120.15504-100000@markab.dbai.tuwien.ac.at>
References: <Pine.GSO.4.10.9907061806030.11328-100000@markab.dbai.tuwien.ac.at>
X-SW-Source: 1999-07/msg00253.html
Content-length: 3309

On Tue, 6 Jul 1999, Gerald Pfeifer wrote:
>> 1999-07-06  Bruce Korb  <ddsinc09@ix.netcom.com>
>> 
>> 	* fixinc/inclhack.tpl: only install assert.h conditionally
>> 	* fixinc/inclhack.sh: regen
>> 	* fixinc/fixincl.sh: regen

Bruce, even if it didn't completely fix my problem, is it the case to
install the patch above?


As Bruce suggested in private e-mail, please find below the output of
a Makefile where I added a '-v' at the right place to see all the details
of this failure.

  /sw/test/egcs/egcs             is the source tree
  /files/pfeifer/OBJ-0707-15:10  is the build tree
  /sw/test/egcs/FreeBSD          is the --prefix

Finally, I checked, and the stdio.h which is used is the one from
/files/pfeifer/OBJ-0707-15:10/gcc/include/stdio.h

Gerald


_eprintf
Reading specs from /files/pfeifer/OBJ-0707-15:10/gcc/specs
gcc version gcc-2.96 19990707 (experimental)
 /files/pfeifer/OBJ-0707-15:10/gcc/cpp -lang-c -v -I/sw/test/egcs/FreeBSD/i386-unknown-freebsdelf3.1/include -I./include -I. -I/sw/test/egcs/egcs/gcc -I/sw/test/egcs/egcs/gcc/config -I/sw/test/egcs/egcs/gcc/../include -isystem /sw/test/egcs/FreeBSD/i386-unknown-freebsdelf3.1/bin/include -isystem /files/pfeifer/OBJ-0707-15:10/gcc/include -D__GNUC__=2 -D__GNUC_MINOR__=96 -Di386 -Dunix -D__ELF__ -D__FreeBSD__ -D__i386__ -D__unix__ -D__ELF__ -D__FreeBSD__ -D__i386 -D__unix -Asystem(unix) -Asystem(FreeBSD) -Acpu(i386) -Amachine(i386) -D__OPTIMIZE__ -g -g1 -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DL_eprintf /sw/test/egcs/egcs/gcc/libgcc2.c /var/tmp/ccJFzsd1.i
GNU CPP version gcc-2.96 19990707 (experimental) (i386 FreeBSD/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /sw/test/egcs/FreeBSD/i386-unknown-freebsdelf3.1/include
 include
 .
 /sw/test/egcs/egcs/gcc
 /sw/test/egcs/egcs/gcc/config
 /sw/test/egcs/egcs/gcc/../include
 /files/pfeifer/OBJ-0707-15:10/gcc/include
 /usr/local/include
 /sw/test/egcs/FreeBSD/lib/gcc-lib/i386-unknown-freebsdelf3.1/gcc-2.96/../../../../i386-unknown-freebsdelf3.1/include
 /sw/test/egcs/FreeBSD/lib/gcc-lib/i386-unknown-freebsdelf3.1/gcc-2.96/include
 /usr/include
End of search list.
The following default directories have been omitted from the search path:
 /sw/test/egcs/FreeBSD/lib/gcc-lib/i386-unknown-freebsdelf3.1/gcc-2.96/../../../../include/g++-2
End of omitted list.
 /files/pfeifer/OBJ-0707-15:10/gcc/cc1 /var/tmp/ccJFzsd1.i -quiet -dumpbase libgcc2.c -g -g1 -O2 -O2 -version -o /var/tmp/ccLlwWX1.s
GNU C version gcc-2.96 19990707 (experimental) (i386-unknown-freebsdelf3.1) compiled by GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release).
In file included from /sw/test/egcs/egcs/gcc/libgcc2.c:1408:
include/stdio.h:245: parse error before `__gnuc_va_list'
include/stdio.h:246: parse error before `__gnuc_va_list'
include/stdio.h:247: parse error before `__gnuc_va_list'
include/stdio.h:309: parse error before `__gnuc_va_list'
include/stdio.h:311: parse error before `__gnuc_va_list'
include/stdio.h:313: parse error before `__gnuc_va_list'
include/stdio.h:314: parse error before `__gnuc_va_list'
include/stdio.h:344: parse error before `__gnuc_va_list'
gmake[1]: *** [libgcc2.a] Error 1
gmake[1]: Leaving directory `/files/pfeifer/OBJ-0707-15:10/gcc'
gmake: *** [all-gcc] Error 2

Re: egcs 19990629 (arm/aout) static member vars end up in common

[Jeffrey A Law]

  In message < 37835AB0.3DD0C389@virata.com >you write:
  > I'm using gcc-2.95 19990629 (prerelease) and I find that, compared to
  > the last version I used (egcs1.1b) it has started to put some symbols
  > into common (.comm) that it never used to.
  > 
  > The sort of code that provokes this looks like the following:
  > 
  >         class Foo
  >         {
  >                 static int x;
  >         };
  > 
  >         int Foo::x;
  > 
  > 
  > I get the following:
  > 
  >     .comm   __3Foo.x, 4     @ 4
  > 
  > Sadly, my assembler and linker (non-gnu) do not understand .comm.
That sounds like a bug in your gcc configuration files.  The configuration
files should define ASM_OUTPUT_COMMON or ASM_OUTPUT_ALIGNED_COMMON to emit
suitable assembly code for commons.

jeff

Re: egcs 19990629 (arm/aout) static member vars end up in common

[Mike Stump]

Might as well switch now...  The next feature you'll want is link.once...