compilation of *.i files does not go to temp files

compilation of *.i files does not go to temp files

[Joern Rennecke]

When I try to compile a *.i file, the cc1 output is not directed to the
temp file, thus resulting in an object file with zero sized text sections.
You can work around this with the --save-temps option, but that should
not be required.
AFAICS your patch to gcc.c on the 13th July caused this.

phal:/x/egcs-regmove2-sh-elf/gcc$ ./xgcc -B./ -c tst.i -v
Reading specs from ./specs
gcc version 2.96 20000725 (experimental)
 ./cc1 tst.i -quiet -dumpbase tst.i -version
GNU C version 2.96 20000725 (experimental) (sh-elf) compiled by GNU C version 2.7.2.3.
 ./as -o tst.o /tmp/ccFzhS6I.s
>From raeburn@raeburn.org Wed Jul 26 12:28:00 2000
From: Ken Raeburn <raeburn@raeburn.org>
To: gcc-bugs@gcc.gnu.org
Subject: Re: assembly name collisions in C++
Date: Wed, 26 Jul 2000 12:28:00 -0000
Message-id: <200007261928.PAA09257@raeburn.org>
References: <200007261750.NAA08513@raeburn.org> <14719.10311.712264.186941@watercress.indetermi.net>
X-SW-Source: 2000-07/msg00691.html
Content-length: 633

Alex Samuel <samuel@codesourcery.com> writes:
> I believe that your code sample is illegal -- you can't declare both a
> class and a namespace foo in the same scope.  The problem isn't in the
> mangling; however, it is a bug that gcc doesn't catch the double
> declaration of foo.

Thanks.  I just bought a copy of the spec from the ANSI web site (much
cheaper than hardcopies I've gotten before!), and after looking at
some bits in section 7, I agree.  I still want to look further at how
far the prohibition against reusing the name of a namespace goes, but
clearly my example is invalid and should be caught by the compiler.

Ken
>From pavenis@latnet.lv Wed Jul 26 12:38:00 2000
From: Andris Pavenis <pavenis@latnet.lv>
To: Jeffrey F Lipton <jlipton@maimonidesmed.org>, gcc-bugs@gcc.gnu.org
Subject: Re: Bug Report
Date: Wed, 26 Jul 2000 12:38:00 -0000
Message-id: <00072621374700.00241@hal>
References: <397EEEFD.5FB2658F@maimonidesmed.org>
X-SW-Source: 2000-07/msg00692.html
Content-length: 437

On Wed, 26 Jul 2000, Jeffrey F Lipton wrote:
> 
> I got the following when running gcc 2.952 on windows 95, under the
> ''bash'' shell.
> 
> Jeff Lipton

With gcc-2.95.2 I'm getting ICE (I tested both Linux-to-DJGPP cross-compiler and
native compiler under Linux, latest gave some warnings warnings due to DJGPP
header files).

With gcc-2.96 20000721 I'm no more getting internal compiler error. Soo
perhaps the error is fixed

Andris

Re: compilation of *.i files does not go to temp files

[Zack Weinberg]

On Wed, Jul 26, 2000 at 08:02:15PM +0100, Joern Rennecke wrote:
> When I try to compile a *.i file, the cc1 output is not directed to the
> temp file, thus resulting in an object file with zero sized text sections.
> You can work around this with the --save-temps option, but that should
> not be required.
> AFAICS your patch to gcc.c on the 13th July caused this.
> 
> phal:/x/egcs-regmove2-sh-elf/gcc$ ./xgcc -B./ -c tst.i -v
> Reading specs from ./specs
> gcc version 2.96 20000725 (experimental)
>  ./cc1 tst.i -quiet -dumpbase tst.i -version
> GNU C version 2.96 20000725 (experimental) (sh-elf) compiled by GNU C version 2.7.2.3.
>  ./as -o tst.o /tmp/ccFzhS6I.s

Should be corrected in the patch I just applied to gcc.c.

zw
>From zack@wolery.cumb.org Mon Jul 31 12:14:00 2000
From: Zack Weinberg <zack@wolery.cumb.org>
To: "H . J . Lu" <hjl@lucon.org>
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: Does cpp still open many files.
Date: Mon, 31 Jul 2000 12:14:00 -0000
Message-id: <20000731121401.J26185@wolery.cumb.org>
References: <20000727183822.A4501@lucon.org>
X-SW-Source: 2000-07/msg00785.html
Content-length: 726

On Thu, Jul 27, 2000 at 06:38:22PM -0700, H . J . Lu wrote:
> Hi, Zack,
> 
> Have you fixed
> 
> http://gcc.gnu.org/ml/gcc/2000-07/msg00037.html
> 
> The gcc from CVS has been killing my machine left and right when
> I do parallel Linux kernel build on my SMP machines.

It does still open many files.  It is supposed to close them all if
open() fails, but you might run out of system file slots first and
have some other program be affected.  Setting rlimits such that
(number of per-process files allowed) * (number of parallel gcc
instances) < (total number of open files supported) should fix that
problem.

I've been meaning to fix this for awhile but other things are higher
priority.  I'll bump it up a few levels.

zw
>From rajeshc@empowertel.com Mon Jul 31 12:21:00 2000
From: Rajesh Cheethirala <rajeshc@empowertel.com>
To: gcc-bugs@gcc.gnu.org
Subject: casting problem in c
Date: Mon, 31 Jul 2000 12:21:00 -0000
Message-id: <3985D297.14891374@empowertel.com>
X-SW-Source: 2000-07/msg00786.html
Content-length: 836

If I have code that looks like this:


/* put component tag */
 *pdup.uc++ = TC_ERROR;

/* leave the length indicator blank */
   pdup.us++;

I get a core dump after I build and execute at the last line.

The union looks like this
typedef union
{
    pduhdr_t            *hdr;
    unsigned char       *ptag;
    void                *vp;    /* internal use only */
    char                *c;
    unsigned char       *uc;
    short               *s;
    unsigned short      *us;
    int                 *i;
    unsigned int        *ui;
    long                *l;
    unsigned long       *ul;
} pduptr_t;



My system configuration is as follows:
System Configuration:  Sun Microsystems  sun4u
Memory size: 2432 Megabytes
System Peripherals (Software Nodes):

SUNW,Ultra-4
SunOS helia 5.6 Generic_105181-17 sun4u sparc


Thanks
Rajesh