[Bug target/10129] Ada bootstrap fails on PPC-Darwin - invalid assembler emitted - PIC related

[Andrew Pinski]

On Wednesday, Jul 2, 2003, at 16:52 US/Eastern, Geert Bosch wrote:

> On Wednesday, Jul 2, 2003, at 13:17 America/New_York, pinskia at 
> physics dot uc dot edu wrote:
>> Okay I think I figured out how this one is happening, now the problem 
>> is figuring out how to fix it. The problem is the Darwin's backend 
>> depends on current_function_decl which Ada changes the  name inside 
>> it for some reason to be one with a .n (where n is an integer). So 
>> the problem is the
>> hashtable will not caught every thing so on when the setjmp is 
>> generated, current_function_decl is without the .n but when the 
>> function is generated it has a .n, so this is confusing Darwin's 
>> backend.  Now I do not know the currect fix at all and this problem 
>> seems to be needed to be fixed in the Ada frontend.
>
> Hi Andrew,
>
> According to Kenner, the .n's are added by the GCC back end for
> nested functions. This has nothing to do with Ada itself, and I don't
> quite understand your comment that Ada "changes" the name "inside" 
> current_function_decl. What is exactly happening here?
>
> Anyway, I'm quite unhappy that the whole Darwin PIC code and design
> is considered "horribly ugly" and "broken". For that reason I think
> it might be best to consider how we can avoid this PIC code and
> default to statically linked code by default.
>
> Actually, this brings up a question I have. Why don't we just enable
> the "-mdynamic-no-pic" flag by default (at least for the Ada front end)
> and then require an explicit -pic or -PIC for this to be enabled?
> This came up when I tried to figure out how to change the Ada makefiles
> to use the -mdynamic-no-pic flag in the right cases. Not generating
> PIC code by default, but fast statically linked code instead, and only
> requiring explicit flags for shared executables seems the standard
> practice on most systems anyway.
>
> The fact that PIC code is broken on Darwin only makes this more 
> important.

I am fixing it so only after the rtl is ready to be emitted to asm,
to generate the labels, this will simplify the code.
Then we do not have to worry about another frontend causing this 
problem.
The reason why this should be fixed is that it still is a problem with 
user
code so we will get reports about the problem.

Thanks,
Andrew Pinski