This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: `$' in identifiers -vs- PPC Linux
- To: Geoff Keating <geoffk at cygnus dot com>
- Subject: Re: `$' in identifiers -vs- PPC Linux
- From: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Date: Tue, 17 Oct 2000 21:37:53 +0200
- Cc: gcc-patches at gcc dot gnu dot org
- References: <Tom Tromey's message of "30 Aug 2000 15:25:22 -0600"> <00101513565900.01720@enzo.bigblue.local> <jmwvf8e2lf.fsf@envy.cygnus.com>
On Tue, 17 Oct 2000, Geoff Keating wrote:
> Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
> > On Thu, 31 Aug 2000, Franz Sirl wrote:
> > > OK, here is the patch. Bootstrap still running, but I expect no
> > > problems since problems should already show up during compile :-).
> > >
> > > This closes the "move colliding macros from rs6000.h to platform
> > > headers" for me.
> > > The remaining collisions
> > >
> > > STRICT_ALIGNMENT
> > > STACK_BOUNDARY
> > > BIGGEST_ALIGNMENT
> > > ASM_OUTPUT_INT
> > > SIZE_TYPE
>
> Actually, some of these really should be in aix.h. There's no need to
> do them now, though.
Well, tell me what do you want to have out of rs6000.h and I'll do the boring
work :-). I just couldn't draw a sensible line for all the alignment, type
and ASM macros myself.
> > > make no real sense to move into aix.h IMHO.
> > >
> > > The patch also syncs the ASM_APP_* macros for Linux on PPC and fixes
> > > the CONSTRUCTOR handling in rs6000.c. Geoff, related to the CONSTRUCTOR
> > > handling I also want to revive execute/20000516-1.c from CVS, this test
> > > is meant to pass and is _different_ from execute/20000722-1.c. The test
> > > verifies that CONSTRUCTOR data is put into a writeable section. I
> > > didn't notice yet that you did remove it, but the removal was wrong.
>
> The testcase was failing sometimes, and passing sometimes, based I
> believe on segment sizes or something, which was annoying.
>
> The data does not need to be put in a writable section. It has to be
> copied from wherever it is into a local temporary.
>
> For instance,
>
> struct s
> {
> int value;
> char *string;
> };
>
> int i;
> for (i = 0; i < 4; i++)
> {
> struct s *t = & (struct s) { 3, "hey there" };
> if (t->value != 3)
> abort();
> t->value = 4;
> if (t->value != 4)
> abort();
> }
I don't quite understand? This code fails without my patch and passes with
it? Note that my patch (or something similar) fixes Linux kernel compilation,
without it you can't put a kernel image into ROM, cause it tries to write to
it. This is a showstopper for the embedded people. Additionally the same
functionality is available on x86, which passed the testcase too.
On what platforms did the test FAIL? I would rather think these need fixes
too, that's why the testcase was added in the first place, it tests if the
functionality (I think this is a GCC extension) is correctly implemented.
> > > OK to commit?
> > >
> > > BTW, it seems gcc/stmt.c is seriously corrupted in CVS, but I don't
> > > know cvs well enough to tell if this can be fixed from remote.
> > >
> > > Franz.
> > >
> > >
> > > 2000-08-31 Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> > >
> > > * rs6000/rs6000.h (NO_DOLLAR_IN_LABEL, DOLLARS_IN_IDENTIFIERS,
> > > ENCODE_SECTION_INFO, ASM_OUTPUT_SPECIAL_POOL_ENTRY_P): Move
> > > from here...
> > > * rs6000/aix.h: ...to here.
> > > * rs6000/linux.h (ASM_APP_ON, ASM_APP_OFF): Define to
> > > Linux-style. * rs6000/rs6000.c (rs6000_select_section): Handle
> > > CONSTRUCTOR. (rs6000_unique_section): Likewise.
> >
> > Geoff, is this patch OK for commit? OK to revive the testcase?
>
> I don't think so. Can you re-submit without the rs6000_select_section
> changes?
Sure.
Franz.