Re: objc (current snapshot) doesn't compile

Re: objc (current snapshot) doesn't compile

[Jeffrey A Law]

  In message <19990422002250.A22743@liafa1.liafa.jussieu.fr>you write:
  > > Downgrading bison to version 1.25 has allowed me build egcs (latest cvs)
  > > without further complaint.
  > Looking at bison log, the only significant change between 1.25 and 1.27
  > is a re-numbering of tokens, so that they now start at 257 as advertized.
  > 
  > So there are two basic possibilities: either objc-parse was the only parser
  > that was rebuilt, in which case it's quite normal it broke (since C/objc
  > parsing are VERY tightly linked), or egcs somehow came out to rely on that
  > bison bug...
  > 
  > I don't have any machine in a decent state to check either conjecture 
  > right away... Jeff, which version of bison is used these days ?
My machine seems to have bison-1.25.  I suspect that's probably what most
of the Cygnus folks have.

Hopefully we're just out of sync in the repo and not depending on any
bug/feature of bison-1.25 that is not in bison-1.27.

Jeff
>From tot@trema.com Fri Apr 23 00:44:00 1999
From: Teemu Torma <tot@trema.com>
To: egcs-bugs@egcs.cygnus.com
Subject: egcs-1.1.2 cross compiler problems
Date: Fri, 23 Apr 1999 00:44:00 -0000
Message-id: <199904230744.JAA26163@lev.labs.trema.com>
X-SW-Source: 1999-04/msg00641.html
Content-length: 977

I have tried for the first time to set egcs to work as a cross
compiler to be able to compile sparc-sun-solaris2.5.1 binaries under
sparc-sun-solaris2.7.  This same setup worked out-of-the-box with gcc
2.7.2.3.

The configuration was done as:

../egcs-1.1/configure --target=sparc-sun-solaris2.5.1 --srcdir=../egcs-1.1 --prefix=/usr/gnu --with-cpu=supersparc --enable-version-specific-runtime-libs --enable-shared --with-gnu-as --with-gnu-ld

I encountered two fatal problems with this setup:

1. The generated include/limits.h does include code to #include_next
   the system limits.h (limitx.h and limity.h).  This causes that
   config/sparc/gmon-sol2.c does not even compile because it does not
   get PATH_MAX from limits.h.  

2. When building a cross compiler, libgcc2.c does automatically
   #define inhibit_libc.  At least __eprintf will be missing and
   causing link failures.

After fixing those two things manually, everything seems to be in
working order.

Teemu
>From tot@trema.com Fri Apr 23 01:18:00 1999
From: Teemu Torma <tot@trema.com>
To: egcs-bugs@egcs.cygnus.com
Subject: Re: egcs-1.1.2 cross compiler problems
Date: Fri, 23 Apr 1999 01:18:00 -0000
Message-id: <x7hfq74uns.fsf@baht.labs.trema.com>
References: <199904230744.JAA26163@lev.labs.trema.com>
X-SW-Source: 1999-04/msg00642.html
Content-length: 290

I wrote:

> 1. The generated include/limits.h does include code to #include_next
>    the system limits.h (limitx.h and limity.h).  This causes that
>    config/sparc/gmon-sol2.c does not even compile because it does not
>    get PATH_MAX from limits.h.  

Forget that, my mistake. 

Teemu
>From rch@larissa.sd.bi.ruhr-uni-bochum.de Fri Apr 23 02:49:00 1999
From: <rch@larissa.sd.bi.ruhr-uni-bochum.de>
To: egcs-bugs@egcs.cygnus.com
Subject: C++ internal compiler error (Virtual & Embedded & Template)
Date: Fri, 23 Apr 1999 02:49:00 -0000
Message-id: <199904230755.JAA22159@lindell.baustatik.rwth-aachen.de>
X-SW-Source: 1999-04/msg00643.html
Content-length: 641

Hi there,

an internal compiler error is reported by the latest egcs snapshot

---------
c++ -v
Reading specs from /opt/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.93.19/specs
gcc version egcs-2.93.19 19990418 (gcc2 ss-980929 experimental)
--------------

for the following code

--------------
#include <stdlib.h>
// <summary> Primitives to build up metaobjects </summary>
// 
template< class X >
struct VB: public virtual X
{};

template< class MOPTerm1, class MOPTerm2 >
struct MOPTermUnify
{
  struct MO:
    public VB<MOPTerm1>,
    public VB<MOPTerm2>
  {
    void   fix()
      { 
      }
  };
};
--------------
Many thanks for egcs!

Rosta
>From jle@star.be Fri Apr 23 04:20:00 1999
From: jle@star.be
To: egcs-bugs@egcs.cygnus.com
Subject: --enable-cpplib, --enable-c-cpplib
Date: Fri, 23 Apr 1999 04:20:00 -0000
Message-id: <C125675C.003D0252.00@lotusout.star.be>
X-SW-Source: 1999-04/msg00644.html
Content-length: 666

trying to compile egcs-1.1.2 on i686-pc-linux-gnu
after a configure --disable-debug --enable-shared --enable-cpplib
--enable-c-cpplib

compilation stops within objective-c part

env LANGUAGES="c c++ f77" make works fine !

the generated C/C++ compilers are unable to handle the -MD option

(I discovered this in trying to compile the new Nurbs++ library (rev 3.0.0)
 see http://yukon.genie.uottawa.ca/~lavoie/software/nurbs/ for download)

Beside that, egcs-1.1.2 appears to be a reliable and efficient tool,
as an example, on an HP C360, an egcs-compiled povray-3.1e runs faster
than an HP C-compiled one ! (400 sec against 440 sec)

egcs-ly yours,
Jacques Leroy

Re: objc (current snapshot) doesn't compile

[Rod m. Stewart]

On Fri, 23 Apr 1999, Jeffrey A Law wrote:
>   In message <19990422002250.A22743@liafa1.liafa.jussieu.fr>you write:
>   > Looking at bison log, the only significant change between 1.25 and 1.27
>   > is a re-numbering of tokens, so that they now start at 257 as advertized.
>   > 
>   > So there are two basic possibilities: either objc-parse was the only parser
>   > that was rebuilt, in which case it's quite normal it broke (since C/objc
>   > parsing are VERY tightly linked), or egcs somehow came out to rely on that
>   > bison bug...
>   > 
>   > I don't have any machine in a decent state to check either conjecture 
>   > right away... Jeff, which version of bison is used these days ?
> My machine seems to have bison-1.25.  I suspect that's probably what most
> of the Cygnus folks have.
> 
> Hopefully we're just out of sync in the repo and not depending on any
> bug/feature of bison-1.25 that is not in bison-1.27.

Incidently, this now appears to fixed (Tue Apr 20 23:38:58 1999
gcc/Changelog entry).  Well I can now build the latest egcs using
bison-1.27, no more crashes in objc.

I have other problems, but I'm willing to blame most of the them on my
build environment.  And hopefully I can convince dejagnu to build on one
of my arm boxes this afternoon.

Thanks,
-Rms

Re: objc (current snapshot) doesn't compile

[Jeffrey A Law]

  In message <Pine.LNX.4.10.9904071931250.15857-100000@k6.microsoft.sucks.eu.or
g>you write:
  > objc doesn't compile in the current egcs snapshot on Linux 2.2/glibc
  > 2.0.7:
  > 
  > /usr/src/egcs/gcc/xgcc -B/usr/src/egcs/gcc/ -B/usr/i586-pc-linux-gnu/bin/
  > -fgnu-runtime -c -o linking.o -I. -I.   -O2 -DIN_GCC -I./objc
  > -I./../../gcc -I./../../gcc/config -I../../gcc -I./../../include linking.m
  > In file included from objc/Object.h:30,
  >                  from linking.m:28:
  > objc/objc.h:51: parse error before `const'
  > xgcc: Internal compiler error: program cc1obj got fatal signal 11
  > make[1]: *** [linking.o] Error 1
  > make[1]: Leaving directory `/usr/src/egcs/i586-pc-linux-gnu/libobjc'
  > make: *** [all-target-libobjc] Error 2
  > 
  > The offending line is "typedef const struct objc_selector"
Odd.  I bootstrapped on both an i686 and i586 tonight in a similar
configuration.


jeff

Re: objc (current snapshot) doesn't compile

[Rod m. Stewart]

On Sat, 10 Apr 1999, Marc Espie wrote:

> >  > 
> >  > The offending line is "typedef const struct objc_selector"
> >Odd.  I bootstrapped on both an i686 and i586 tonight in a similar
> >configuration.
> 
> I got some very similar error in the past (probably the same one, but I can't
> be 100% sure as this is from memory), when I tried getting the parser source 
> thru yacc instead of bison... I haven't got around to investigate this one
> yet, but this looks familiar to me.
> 
> I'd suggest checking the generated parser files against the actual snapshot,
> they *might* have been re-generated (occurs when upgrading thru diffs), and
> the problem might be there.
> 
> If that's the case, I'd definitely be interested in understanding what's
> going on !

I was this having problem on the NetWinder (armv4l arch) for the longest
time with objc.

I noticed the following files were regenerated during my build:
	egcs/gcc/objc/objc-parse.c
	egcs/gcc/objc/objc-parse.y

diffing these against those in my clean cvs tree I found that objc-parse.c
was generate with bison version 1.27, whereas the clean one was generated
with version 1.25.

Downgrading bison to version 1.25 has allowed me build egcs (latest cvs)
without further complaint.

This may be relevant to others problems, or it may be a problem on my end
with bison on the NetWinder.  Just thought I'd mention it.

-Rms

Re: objc (current snapshot) doesn't compile

[Bernhard Rosenkraenzer]

On Sat, 10 Apr 1999, Marc Espie wrote:

> I got some very similar error in the past (probably the same one, but I can't
> be 100% sure as this is from memory), when I tried getting the parser source 
> thru yacc instead of bison...

I'm using bison - actually my yacc is a shell script saying
#!/bin/sh
bison -y $*

Still getting
/usr/src/egcs/gcc/xgcc -B/usr/src/egcs/gcc/ -B/usr/i586-pc-linux-gnu/bin/
-fgnu-runtime -c -o linking.o -I. -I.   -O2 -DIN_GCC -I./objc
-I./../../gcc -I./../../gcc/config -I../../gcc -I./../../include linking.m
In file included from objc/Object.h:30,
                 from linking.m:28:
objc/objc.h:51: parse error before `const'
xgcc: Internal compiler error: program cc1obj got fatal signal 11
make[1]: *** [linking.o] Error 1
make[1]: Leaving directory `/usr/src/egcs/i586-pc-linux-gnu/libobjc'
make: *** [all-target-libobjc] Error 2

after checking out the most current version from the anoncvs tree.

LLaP
bero

-- 
Windows 98 supports real multitasking - it can boot and crash simultaneously.
***
Anyone sending unwanted advertising e-mail to this address will be charged
$25 for network traffic and computing time. By extracting my address from
this message or its header, you agree to these terms.

Re: objc (current snapshot) doesn't compile

[Marc Espie]

In article < 18315.923637319@upchuck > you write:
>  > 
>  > The offending line is "typedef const struct objc_selector"
>Odd.  I bootstrapped on both an i686 and i586 tonight in a similar
>configuration.

I got some very similar error in the past (probably the same one, but I can't
be 100% sure as this is from memory), when I tried getting the parser source 
thru yacc instead of bison... I haven't got around to investigate this one
yet, but this looks familiar to me.

I'd suggest checking the generated parser files against the actual snapshot,
they *might* have been re-generated (occurs when upgrading thru diffs), and
the problem might be there.

If that's the case, I'd definitely be interested in understanding what's
going on !
>From zack@rabi.columbia.edu Fri Apr 09 19:50:00 1999
From: Zack Weinberg <zack@rabi.columbia.edu>
To: egcs-bugs@egcs.cygnus.com, rth@cygnus.com
Subject: 970825-2.f: bug in flow analysis
Date: Fri, 09 Apr 1999 19:50:00 -0000
Message-id: <199904100250.WAA24036@blastula.phys.columbia.edu>
X-SW-Source: 1999-04/msg00287.html
Content-length: 1789

For some time we've had this failure:

FAIL: g77.f-torture/execute/970625-2.f compilation,  -O1 

This case doesn't fail at any other optimization level.  It's
intentionally obfuscated Fortran, but I've managed to reproduce it in
straightforward C (appended). It's blowing up in the second flow pass:

test.c: In function `subr':
test.c:19: Internal compiler error in `make_edges', at flow.c:973

The bug has to do with label addresses (== computed GOTO).
Specifically, we abort on this insn:

(jump_insn 46 66 41 (set (pc)
        (label_ref:SI 57)) 319 {jump} (nil)
    (nil))

Before register allocation, this was

(jump_insn 46 66 41 (set (pc)
        (reg/v:SI 28)) 320 {indirect_jump} (nil)
    (expr_list:REG_DEAD (reg/v:SI 28)
        (nil)))

Local register allocation turned it into a direct jump, but it
neglected to set JUMP_LABEL() on the insn, so we hit the abort in
here:

(gdb) l
969      /* Otherwise, we have a plain conditional or unconditional jump.  */
970               else
971                 {
972                   if (! JUMP_LABEL (insn))
973                     abort ();
974                   make_label_edge (bb, JUMP_LABEL (insn), 0);
975                 }

It doesn't blow up with optimization off because stupid register
allocation won't turn the indirect jump into a direct jump.  It
doesn't blow up at -Os/-O2 because CSE deletes most of the function,
including all the indirect jumps.

Oddly, I can't find anything that would perform the indirect->direct
transformation in local-alloc.c.

zw

void subr (flag, in, re)
     int flag;
     int *in, *re;
{
    int a = 5, b = 5;
    void *skip = &&SKIP, *out = &&OUT;

    if (!flag) goto *skip;

    if (*re > *in)
        *in = *re + 5;
    else
        if (a > b) goto *out;

SKIP:
    *re += 8;
OUT:
}
>From law@upchuck.cygnus.com Fri Apr 09 20:34:00 1999
From: Jeffrey A Law <law@upchuck.cygnus.com>
To: mark@codesourcery.com
Cc: mrs@wrs.com, jakob@ostenfeld.dk, egcs-bugs@egcs.cygnus.com
Subject: Re: Memory usage 
Date: Fri, 09 Apr 1999 20:34:00 -0000
Message-id: <3290.923714866@upchuck>
References: <199904092312.QAA28081@adsl-206-170-148-33.dsl.pacbell.net>
X-SW-Source: 1999-04/msg00288.html
Content-length: 822

  In message < 199904092312.QAA28081@adsl-206-170-148-33.dsl.pacbell.net >you wri
te:
  > >>>>> "Jeffrey" == Jeffrey A Law <law@upchuck.cygnus.com> writes:
  > 
  >     Jeffrey> Well, it's not radically different than what I'm doing
  >     Jeffrey> with CALL_PLACEHOLDER to defer selection of a sequence of
  >     Jeffrey> insns to implement different kinds of calls
  >     Jeffrey> (sibling/tail, recursive & normal).  In fact, I ought to
  >     Jeffrey> go ahead and contribute more of this stuff.
  > 
  > When do you expect to do so?  This does sound like the foundations for
  > what we'd need.
It hasn't been a priority relative to the other stuff going on.  Particularly
getting egcs-1.2 stuff wrapped up.

Actually, the basic code was posted back in Jan.  The basic structure hasn't
changed a whole lot.

jeff
>From law@upchuck.cygnus.com Fri Apr 09 21:00:00 1999
From: Jeffrey A Law <law@upchuck.cygnus.com>
To: richard.earnshaw@arm.com
Cc: Nick Clifton <nickc@cygnus.com>, pb@nexus.co.uk, amylaar@cygnus.com, egcs-bugs@egcs.cygnus.com
Subject: Re: egcs-990330 (arm-elf) unrecognisable insn 
Date: Fri, 09 Apr 1999 21:00:00 -0000
Message-id: <11365.923716498@upchuck>
References: <199904091318.OAA16006@sun52.NIS.cambridge>
X-SW-Source: 1999-04/msg00289.html
Content-length: 2571

  In message < 199904091318.OAA16006@sun52.NIS.cambridge >you write:
  > > The problem starts in arm.c:arm_reload_in_hi() where it is being
  > > called with:
  > > 
  > > 	operands[0] = (reg:HI 1)
  > > 	operands[1] = (subreg:HI (reg:DI: 53))
  > > 	operands[2] = (reg:SI 1)
  > 
  > Actually, I think the problem lies somewhere in emit_reload_insns, since I 
  > think operands[1] shouldn't be a subreg of a pseudo by this stage (at 
  > least, not in this case).  I seem to remember that in cases like this in 
  > 1.1.x operands[1] was a MEM by this point.
Hmmm, actually I think a subreg of a pseudo can still be hanging around at
this point.  Kenner claimed it could happen, though I don't remember all the
details.  The result was a hunk of code like this in the PA backend's reload_XX
expanders (pa.c::emit_move_sequence):

  if (scratch_reg
      && reload_in_progress && GET_CODE (operand0) == REG
      && REGNO (operand0) >= FIRST_PSEUDO_REGISTER)
    operand0 = reg_equiv_mem[REGNO (operand0)];
  else if (scratch_reg
           && reload_in_progress && GET_CODE (operand0) == SUBREG
           && GET_CODE (SUBREG_REG (operand0)) == REG
           && REGNO (SUBREG_REG (operand0)) >= FIRST_PSEUDO_REGISTER)
    {
      SUBREG_REG (operand0) = reg_equiv_mem[REGNO (SUBREG_REG (operand0))];
      operand0 = alter_subreg (operand0);
    }

  if (scratch_reg
      && reload_in_progress && GET_CODE (operand1) == REG
      && REGNO (operand1) >= FIRST_PSEUDO_REGISTER)
    operand1 = reg_equiv_mem[REGNO (operand1)];
  else if (scratch_reg
           && reload_in_progress && GET_CODE (operand1) == SUBREG
           && GET_CODE (SUBREG_REG (operand1)) == REG
           && REGNO (SUBREG_REG (operand1)) >= FIRST_PSEUDO_REGISTER)
    {
      SUBREG_REG (operand1) = reg_equiv_mem[REGNO (SUBREG_REG (operand1))];
      operand1 = alter_subreg (operand1);
    }


Then we have a hunk of code to look up any replacements for a MEM:

  if (scratch_reg && reload_in_progress && GET_CODE (operand0) == MEM
      && ((tem = find_replacement (&XEXP (operand0, 0)))
          != XEXP (operand0, 0)))
    operand0 = gen_rtx_MEM (GET_MODE (operand0), tem);
  if (scratch_reg && reload_in_progress && GET_CODE (operand1) == MEM
      && ((tem = find_replacement (&XEXP (operand1, 0)))
          != XEXP (operand1, 0)))
    operand1 = gen_rtx_MEM (GET_MODE (operand1), tem);


It sounds like your problem is slightly different (since reg_equiv_mem is
NULL), but there may be tidbits you can use.  In a pinch I might be able to
dig out some mail on these two changes.

jeff
>From kthomas@gwdg.de Fri Apr 09 21:29:00 1999
From: kthomas@gwdg.de (Philipp Thomas)
To: egcs-bugs@egcs.cygnus.com
Subject: Signal 11 when compiling at -O2
Date: Fri, 09 Apr 1999 21:29:00 -0000
Message-id: <3711c1ca.1633071@mailer.gwdg.de>
X-SW-Source: 1999-04/msg00290.html
Content-length: 1351

The attached code results in a Signal 11 when compiled at -O2,
it passes at -O1.
It faults in verify_dominator() in loop.c at line 2559 because
JUMP_LABEL returns 0.

Could somebody please verify that this isn't just my egcs version
failing ?

This is the CVS version from 3rd April, compiled with
-O2 --mcpu=k6 --march=k6 -fschedule-insns2

here's the output from --verbose:
Reading specs from /usr/lib/gcc-lib/k6-pc-linux-gnu/egcs-2.93.14/specs
gcc version egcs-2.93.14 19990403 (gcc2 ss-980929 experimental)
 /usr/lib/gcc-lib/k6-pc-linux-gnu/egcs-2.93.14/cpp -lang-c -v
-I/usr/src/linux/include -undef -D__GNUC__=2 -D__GNUC_MINOR__=93
-D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__
-D__linux__ -D__unix -D__linux -Asystem(posix) -D__OPTIMIZE__ -Wall
-Wstrict-prototypes -Wno-trigraphs -Acpu(i386) -Amachine(i386) -Di386
-D__i386 -D__i386__ -Di586 -Dk6 -D__i586 -D__i586__ -D__k6 -D__k6__
-D__KERNEL__ -D__SMP__ -DCPU=586 -DMODULE isdnl2.c -o isdnl2.i
cpp: GNU CPP version egcs-2.93.14 19990403 (gcc2 ss-980929
experimental) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /usr/src/linux/include
 /usr/local/include
 /usr/k6-pc-linux-gnu/include
 /usr/lib/gcc-lib/k6-pc-linux-gnu/egcs-2.93.14/include
 /usr/include
End of search list.


Philipp Thomas

-- 
caffeine low .... brain halted
>From ildar@faki-campus.mipt.ru Fri Apr 09 22:55:00 1999
From: Ildar Mulyukov <ildar@faki-campus.mipt.ru>
To: egcs-bugs@egcs.cygnus.com
Subject: Re: TODO: egcs-g++ (fwd)
Date: Fri, 09 Apr 1999 22:55:00 -0000
Message-id: <Pine.LNX.4.04.9904100953020.22772-100000@natalie.faki-campus.mipt.ru>
X-SW-Source: 1999-04/msg00291.html
Content-length: 1475

Ildar Mulyukov, student of DACR, MIPT (Moscow, Russia)
e-mail: ildar@faki-campus.mipt.ru, ICQ# 4334029

---------- Forwarded message ----------
Date: 10 Apr 1999 02:40:32 -0300
From: Alexandre Oliva <oliva@dcc.unicamp.br>
To: Ildar Mulyukov <ildar@faki-campus.mipt.ru>
Cc: egcs@egcs.cygnus.com
Subject: Re: TODO: egcs-g++

On Apr 10, 1999, Ildar Mulyukov <ildar@faki-campus.mipt.ru> wrote:

> But when I just started using egcs c++ I encountered 2 problems.

Nope, egcs did encounter 2 problems :-D

> struct _stru {
>     int i;
>     union {
>         struct { int j0, j1; };
                                ^ some variable name is missing here
>         int j[2];
>     }
       ^ struct and union declarations must be terminated with `;'
> };

> The worst thing is that TinySoft's VisualC++ eats it ok :-)

Send them a bug report then :-)

> 2. Compiling dos-formatted files (CR-LF instead of LF) invokes no problem
> except when one ends line with '\'. While CR comes straight after \
> compiler thinks it is special symbol and emits an error.

AFAIK, this is not supposed to work, but, if it works at all, it would
probably only work in MS-DOS like platforms.  But I'm not sure about
that.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Brasil
{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

objc (current snapshot) doesn't compile

[Bernhard Rosenkraenzer]

objc doesn't compile in the current egcs snapshot on Linux 2.2/glibc
2.0.7:

/usr/src/egcs/gcc/xgcc -B/usr/src/egcs/gcc/ -B/usr/i586-pc-linux-gnu/bin/
-fgnu-runtime -c -o linking.o -I. -I.   -O2 -DIN_GCC -I./objc
-I./../../gcc -I./../../gcc/config -I../../gcc -I./../../include linking.m
In file included from objc/Object.h:30,
                 from linking.m:28:
objc/objc.h:51: parse error before `const'
xgcc: Internal compiler error: program cc1obj got fatal signal 11
make[1]: *** [linking.o] Error 1
make[1]: Leaving directory `/usr/src/egcs/i586-pc-linux-gnu/libobjc'
make: *** [all-target-libobjc] Error 2

The offending line is "typedef const struct objc_selector"

-- 
Windows 98 supports real multitasking - it can boot and crash simultaneously.
***
Anyone sending unwanted advertising e-mail to this address will be charged
$25 for network traffic and computing time. By extracting my address from
this message or its header, you agree to these terms.