Getting rid of -g

Getting rid of -g

[Roman Lechtchinsky]

Hi,

the current release of the C compiler for the Cray T3E has a bug which
causes it to miscompile gcc if -g is specified. I'd like to turn this flag
off for building gcc on this platform but I'm somewhat confused about how
to do this. It doesn't really matter whether this flag is used when
building stage2 etc. but it shouldn't be passed to cc when building
stage1.

Bye

Roman

Re: Getting rid of -g

[Franz Sirl]

At 13:23 12.09.2001, Roman Lechtchinsky wrote:
>Hi,
>
>the current release of the C compiler for the Cray T3E has a bug which
>causes it to miscompile gcc if -g is specified. I'd like to turn this flag
>off for building gcc on this platform but I'm somewhat confused about how
>to do this. It doesn't really matter whether this flag is used when
>building stage2 etc. but it shouldn't be passed to cc when building
>stage1.

make bootstrap STAGE1_CFLAGS="-O0 -Wall -W"

Franz.

Re: Getting rid of -g

[Roman Lechtchinsky]

On Wed, 12 Sep 2001, Franz Sirl wrote:

> >the current release of the C compiler for the Cray T3E has a bug which
> >causes it to miscompile gcc if -g is specified. I'd like to turn this flag
> >off for building gcc on this platform but I'm somewhat confused about how
> >to do this. It doesn't really matter whether this flag is used when
> >building stage2 etc. but it shouldn't be passed to cc when building
> >stage1.
> 
> make bootstrap STAGE1_CFLAGS="-O0 -Wall -W"

Yes, but I want to fix configure/makefiles so that the user won't have to
worry about this.

Bye

Roman

Re: Getting rid of -g

[Franz Sirl]

At 13:53 12.09.2001, Roman Lechtchinsky wrote:
>On Wed, 12 Sep 2001, Franz Sirl wrote:
>
> > >the current release of the C compiler for the Cray T3E has a bug which
> > >causes it to miscompile gcc if -g is specified. I'd like to turn this flag
> > >off for building gcc on this platform but I'm somewhat confused about how
> > >to do this. It doesn't really matter whether this flag is used when
> > >building stage2 etc. but it shouldn't be passed to cc when building
> > >stage1.
> >
> > make bootstrap STAGE1_CFLAGS="-O0 -Wall -W"
>
>Yes, but I want to fix configure/makefiles so that the user won't have to
>worry about this.

Set stage1_cflags in gcc/configure.in for your platform and regenerate 
gcc/configure. Currently only vax-*-* uses this feature.

Franz.

Re: Getting rid of -g

[Roman Lechtchinsky]

On Wed, 12 Sep 2001, Franz Sirl wrote:

> >Yes, but I want to fix configure/makefiles so that the user won't have to
> >worry about this.
> 
> Set stage1_cflags in gcc/configure.in for your platform and regenerate 
> gcc/configure. Currently only vax-*-* uses this feature.

This doesn't work because Makefile.in defines STAGE1_CFLAGS as

STAGE1_CFLAGS = -g @stage1_cflags@

i.e. -g is always there. The right thing to do is probably to override
STAGE1_CFLAGS somewhere but I don't quite see where this can be done.

Bye

Roman

Re: Getting rid of -g

[Manfred Hollstein]

Roman Lechtchinsky wrote:
> 
> On Wed, 12 Sep 2001, Franz Sirl wrote:
> 
> > >Yes, but I want to fix configure/makefiles so that the user won't have to
> > >worry about this.
> >
> > Set stage1_cflags in gcc/configure.in for your platform and regenerate
> > gcc/configure. Currently only vax-*-* uses this feature.
> 
> This doesn't work because Makefile.in defines STAGE1_CFLAGS as
> 
> STAGE1_CFLAGS = -g @stage1_cflags@
> 
> i.e. -g is always there. The right thing to do is probably to override
> STAGE1_CFLAGS somewhere but I don't quite see where this can be done.

You should set stage1_cflags to -g0 in your case then.

> 
> Bye
> 
> Roman

Cheers.

l8er
manfred

Re: Getting rid of -g

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

Roman Lechtchinsky <rl@cs.tu-berlin.de> writes:

|> On Wed, 12 Sep 2001, Franz Sirl wrote:
|> 
|> > >Yes, but I want to fix configure/makefiles so that the user won't have to
|> > >worry about this.
|> > 
|> > Set stage1_cflags in gcc/configure.in for your platform and regenerate 
|> > gcc/configure. Currently only vax-*-* uses this feature.
|> 
|> This doesn't work because Makefile.in defines STAGE1_CFLAGS as
|> 
|> STAGE1_CFLAGS = -g @stage1_cflags@
|> 
|> i.e. -g is always there.

Set stage1_cflags to -g0.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: Getting rid of -g

[Roman Lechtchinsky]

On Wed, 12 Sep 2001, Manfred Hollstein wrote:

> You should set stage1_cflags to -g0 in your case then.

Unfortunately, Cray cc doesn't understand -g0. Besides, I'd rather avoid
-g altogether (i.e. for libiberty etc. as well). Do I really have to do
this individually for each package?

Bye

Roman

Re: Getting rid of -g

[Manfred Hollstein]

Roman Lechtchinsky wrote:
> 
> On Wed, 12 Sep 2001, Manfred Hollstein wrote:
> 
> > You should set stage1_cflags to -g0 in your case then.
> 
> Unfortunately, Cray cc doesn't understand -g0. Besides, I'd rather avoid
> -g altogether (i.e. for libiberty etc. as well). Do I really have to do
> this individually for each package?

Put an override of STAGE1_CFLAGS into a host specific file in
config/<your-target-name>/x-<your-target-name> and then add the
name of this file to ${tmake_file} in gcc/config.gcc.

The only package which is compiled using plain cc is libiberty,
all other packages will be built using gcc, so there should be no
need to avoid using '-g' for those packages. Regarding libiberty,
you should create a similar config file in the libiberty/config
directory and put suitable code into libiberty/config.table.
But, I'd recommend to *not* ignore the value of ${CFLAGS} when
${CC} is set to something else than "cc".

> 
> Bye
> 
> Roman

HTH, cheers.

l8er
manfred

Re: Getting rid of -g

[Roman Lechtchinsky]

On Wed, 12 Sep 2001, Manfred Hollstein wrote:

> > Unfortunately, Cray cc doesn't understand -g0. Besides, I'd rather avoid
> > -g altogether (i.e. for libiberty etc. as well). Do I really have to do
> > this individually for each package?
> 
> Put an override of STAGE1_CFLAGS into a host specific file in
> config/<your-target-name>/x-<your-target-name> and then add the
> name of this file to ${tmake_file} in gcc/config.gcc.

Doesn't tmake_file refer to bits specific to the target machine (as
opposed to the build machine)? In other words, doesn't this break
cross-compilation?

> The only package which is compiled using plain cc is libiberty,

Ah, that shouldn't be too difficult then. Thanks.

Bye

Roman

Re: Getting rid of -g

[Richard Henderson]

On Wed, Sep 12, 2001 at 06:08:03PM +0200, Roman Lechtchinsky wrote:
> Doesn't tmake_file refer to bits specific to the target machine (as
> opposed to the build machine)?

Yes.  Manfred actually meant xmake_file.


r~

Re: Getting rid of -g

[Roman Lechtchinsky]

On Wed, 12 Sep 2001, Richard Henderson wrote:
> > Doesn't tmake_file refer to bits specific to the target machine (as
> > opposed to the build machine)?
> 
> Yes.  Manfred actually meant xmake_file.

Doesn't this refer to the host specifica, i.e. is this correct for a
Canadian cross? In fact, I might want to pass different flags depending on
whether stage1 is compiled with Cray cc or gcc so I think I'll just
implement Franz's suggestion to make -g part of stage1_cflags in
configure.in. Would that be ok?

Bye

Roman

Re: Getting rid of -g

[Richard Henderson]

On Wed, Sep 12, 2001 at 07:19:51PM +0200, Roman Lechtchinsky wrote:
> Doesn't this refer to the host specifica, i.e. is this correct for a
> Canadian cross?

Yes.

> implement Franz's suggestion to make -g part of stage1_cflags in
> configure.in. Would that be ok?

That would also be ok.


r~

Re: Getting rid of -g

[Roman Lechtchinsky]

On Wed, 12 Sep 2001, Manfred Hollstein wrote:
> The only package which is compiled using plain cc is libiberty,
> all other packages will be built using gcc, so there should be no
> need to avoid using '-g' for those packages. Regarding libiberty,
> you should create a similar config file in the libiberty/config
> directory and put suitable code into libiberty/config.table.

Nope, this doesn't work because both CFLAGS and LIBCFLAGS (it's the latter
which is actually used for compiling libiberty) are overridden by the
top-level makefile. I've added a Unicos-specific config file to the
top-level config directory and set host_makefile_frag in configure.in
appropriately. This seems to work but is this really the right way to do
it? Should I additionally do what you suggest to ensure that the correct
flags are passed if libiberty is built separately?

Bye

Roman

Re: Getting rid of -g

[Manfred Hollstein]

Roman Lechtchinsky wrote:
> 
> On Wed, 12 Sep 2001, Manfred Hollstein wrote:
> > The only package which is compiled using plain cc is libiberty,
> > all other packages will be built using gcc, so there should be no
> > need to avoid using '-g' for those packages. Regarding libiberty,
> > you should create a similar config file in the libiberty/config
> > directory and put suitable code into libiberty/config.table.
> 
> Nope, this doesn't work because both CFLAGS and LIBCFLAGS (it's the latter
> which is actually used for compiling libiberty) are overridden by the
> top-level makefile. I've added a Unicos-specific config file to the
> top-level config directory and set host_makefile_frag in configure.in
> appropriately. This seems to work but is this really the right way to do
> it? Should I additionally do what you suggest to ensure that the correct
> flags are passed if libiberty is built separately?

Fixing this in the top-level configury is definitely the wrong way,
simply because one has to remember to put the same fix into the
local files as well, as you described.

Hmm... I'd suggest you add code to libiberty's aclocal.m4, which
initializes a new autoconf variable ac_libiberty_debuginfo_cflags
depending on whether the compiler is capable of generating proper
code and debugging info or not; this doesn't necessarily mean that
you have to actually compile code at configure time, but you can
define its value based on some host specific libiberty/config/*
file with a default of '-g' instead. This code should be added to the
definition of the LIB_AC_PROG_CC function in a similar fashion as
we are already doing for ac_libiberty_warn_cflags. libiberty's
Makefile.in can then use this in the definition of COMPILE.c

How about that?

> 
> Bye
> 
> Roman

Cheers.

l8er
manfred

Re: Getting rid of -g

[Roman Lechtchinsky]

On Thu, 13 Sep 2001, Manfred Hollstein wrote:
> Hmm... I'd suggest you add code to libiberty's aclocal.m4, which
> initializes a new autoconf variable ac_libiberty_debuginfo_cflags
> depending on whether the compiler is capable of generating proper
> code and debugging info or not; this doesn't necessarily mean that
> you have to actually compile code at configure time, but you can
> define its value based on some host specific libiberty/config/*
> file with a default of '-g' instead. This code should be added to the
> definition of the LIB_AC_PROG_CC function in a similar fashion as
> we are already doing for ac_libiberty_warn_cflags. libiberty's
> Makefile.in can then use this in the definition of COMPILE.c

Hmm, that will only work if libiberty's makefile doesn't use LIBCFLAGS
passed from the top level at all. I'm not sure if that's a good idea.
Maybe I should simply define a new variable, e.g. LIBIBERTYCFLAGS, in
libiberty's makefile, set it to LIBCFLAGS and use it in COMPILE.c instead
of LIBCFLAGS? This way, top-level LIBCFLAGS will still be used by default
but it will be possible to override it locally.

Bye

Roman