Fix Linux/sparc build after generic asm output optimizations.

Any ELF target that overrides ASM_GENERATE_INTERNAL_LABEL is at risk
of not building any more due to the recent elfos.h changes.

Those changes require that the label format generated by
ASM_GENERATE_INTERNAL_LABEL and TARGET_ASM_INTERNAL_LABEL are in sync,
but that is only being ensured for targets that use elfos.h as-is.

It turns out that Linux/sparc's override is unnecessary, so just
getting rid of it is the best thing to do.

Eric, it seems that most if not all of the other ELF sparc targets
will need something like this as well but I was only able to validate
Linux at the moment.

Committed to trunk.

gcc/

	* config/sparc/linux.h (ASM_GENERATE_INTERNAL_LABEL): Delete.
	* config/sparc/linux64.h (ASM_GENERATE_INTERNAL_LABEL): Delete.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@181307 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog              |    5 +++++
 gcc/config/sparc/linux.h   |    9 ---------
 gcc/config/sparc/linux64.h |    9 ---------
 3 files changed, 5 insertions(+), 18 deletions(-)

> Any ELF target that overrides ASM_GENERATE_INTERNAL_LABEL is at risk
> of not building any more due to the recent elfos.h changes.
>
> Those changes require that the label format generated by
> ASM_GENERATE_INTERNAL_LABEL and TARGET_ASM_INTERNAL_LABEL are in sync,
> but that is only being ensured for targets that use elfos.h as-is.

And ASM_GENERATE_INTERNAL_LABEL uses stpcpy, which isn't portable.

> Eric, it seems that most if not all of the other ELF sparc targets
> will need something like this as well but I was only able to validate
> Linux at the moment.

Aren't all ELF targets of all architectures potentially affected?

On 11/12/2011 03:57 AM, Eric Botcazou wrote:
> And ASM_GENERATE_INTERNAL_LABEL uses stpcpy, which isn't portable.

We just need to declare it in system.h in order to use the definition in 
libiberty.

Jason

> We just need to declare it in system.h in order to use the definition in
> libiberty.

OK, this should be fine.

Hi,

On Sat, 12 Nov 2011, Eric Botcazou wrote:

>> We just need to declare it in system.h in order to use the definition in
>> libiberty.
>
> OK, this should be fine.
>

do the patches I sent for bug #51094 solve the problems?

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51094


Thanks,
Dimitris

From: Eric Botcazou <ebotcazou@adacore.com>
Date: Sat, 12 Nov 2011 09:57:04 +0100

>> Eric, it seems that most if not all of the other ELF sparc targets
>> will need something like this as well but I was only able to validate
>> Linux at the moment.
> 
> Aren't all ELF targets of all architectures potentially affected?

Again, only those ELF targets which have an override for
ASM_GENERATE_INTERNAL_LABEL, which if you check is almost entirely
Sparc.

The normal thing to do is to use the elfos.h defines as-is.

In the end it was a good thing, as we can now get rid of these spurious
override sparc doesn't even need.

> Again, only those ELF targets which have an override for
> ASM_GENERATE_INTERNAL_LABEL, which if you check is almost entirely
> Sparc.

We probably aren't looking at the same tree then.  Alpha, IA-64, MIPS, HP-PA, 
SPARC and a few others have an override for ASM_GENERATE_INTERNAL_LABEL.

> The normal thing to do is to use the elfos.h defines as-is.

Target macros are meant to be overridden though.  If an implicit dependency has 
been introduced, then it should be documented and the tree should be audited.

From: Eric Botcazou <ebotcazou@adacore.com>
Date: Sun, 13 Nov 2011 00:26:51 +0100

>> Again, only those ELF targets which have an override for
>> ASM_GENERATE_INTERNAL_LABEL, which if you check is almost entirely
>> Sparc.
> 
> We probably aren't looking at the same tree then.  Alpha, IA-64, MIPS, HP-PA, 
> SPARC and a few others have an override for ASM_GENERATE_INTERNAL_LABEL.

I am aware of these cases.

And when I took at look at them it seemed to me that these base target
headers where you see those defines either do not get used alongside
elfos.h or will come before elfos.h in the tmake file listing, thus
the elfos.h definition will take precedence.

On the other hand, on Sparc, the overrides occur in OS specific target
headers which appear after elfos.h in the tmake header file list.

>> The normal thing to do is to use the elfos.h defines as-is.
> 
> Target macros are meant to be overridden though.  If an implicit dependency has 
> been introduced, then it should be documented and the tree should be audited.

Agreed.