[PATCH] Boolize darwin's target files, and clean up and fix compat testcases

[Andrew Pinski]

On Apr 12, 2004, at 15:03, Dale Johannesen wrote:

> On Apr 12, 2004, at 6:29 AM, Andrew Pinski wrote:
>> To help out for fixing part of the darwin back-end so that it will 
>> only find out if the
>> function needs a stub only when outputting the symbol, I made two new 
>> functions,
>> machopic_define_data_name and machopic_define_function_name which 
>> right now just do the
>> same as machopic_define_name just to do.
>
> So you expect these to diverge in the future, right?

Yes, I am changing when the back-end figures out if the symbol needs to 
be a stub or not
to fix a regression which I introduced after fixing a build regression 
which was introduced
by one of Roger Sayle's combine patch.  Here is the plan I had in mind.

When a function is declared (meaning a function body is there), the 
function gets added to a
declared list.  When the function is being outputted the branches to a 
symbol is checked to see
if it is in the declared list and if it is, then just output the symbol 
name.  Otherwise, output
the name of the stub for the symbol and then add it to the stub list if 
it is not already there.

Right now eon in SPEC 2K cannot compile because the patch which I added 
to fix the build regression
and I was hoping to get some numbers so that I can compare the tree-ssa 
with the mainline soon
for the FSF's gcc.

> This looks generally OK, but...
>
>>  {
>> -  if (flag_reorder_blocks_and_partition)
>> -    fprintf (asm_out_file, SECTION_FORMAT_STRING, name);
>> -  else
>>      fprintf (asm_out_file, ".section %s\n", name);
>>  }
>
>> -#define SECTION_FORMAT_STRING ".section %s\n\t.align 2\n"
>
> These 2 have something to do with Caroline's patch, not what you said.
> I wasn't following how that came out, but clearly they don't belong in 
> this patch.

Sorry I had this here in mistake, I had forgot no to remove this.

>> +   The machopic_define_datename calls are telling the machopic 
>> subsystem
>
> Fix spelling.

Yes I had thought I had fixed that, woops.

>> +    size1 = size1 == 0 ? 1 : size1;					\
>
> I'd prefer parentheses around size1 == 0 (2 places).

Yes that is better.

> Looks OK to me with the above addressed.  (I'm not objecting to the 
> several Random Whitespace
> Changes, but these are generally considered undesirable.)  Thanks.   
> (I still have no authority,
> but David asked me to review.)

Thanks,
Andrew Pinski