[Patch, gfortran] PR22304, 17917, 16511, 18870 and 23270 - modules, equivalences and commons

Paul THOMAS paulthomas2@wanadoo.fr
Thu Sep 1 16:19:00 GMT 2005


Tobi,


> 
> Thanks for the work you put into this. I have a few remarks below; except for
> those, and the issues you pointed out in the followup, this is ok.

When I got back in this morning, the p/s on my workstation caught fire.  I will be out of action for a few days more.
 
> You should merge these ChangeLog entries, there's also nothing left of Mike's
> patch, so I don't think you would taking away the credit he deserves by not
> mentioning him in the ChangeLog. If you think different, keep the last entry
> separate.

OK.  It certainly makes life easier.
> 
> Is there any reason to make this a void *?

This came about for two reasons; (i) the order of definition of the structures and (ii) the idea that common_head would only ever be used as an identifier for the common block. 

> 
> Why don't you use unique serial numbers as the old code did? This would save
> you from doing this (I take it this is meant to ensure uniqueness of the
> mangled symbol name).
>
The serial numbers are now unique in each namespace and this is all that is reauired to make the code work.  Perhaps I should just check to see if your proposal now works or not; it did not at an intermediate stage, giving segmentation faults.  Notice that the demangling in write_module is necessary to prevent multiple mangling of names.  Remember, the most important thing is the use of the unmangled name, which is used to build the reference to the common segment.

> If the common head member were not a void* you could print the name of the
> common block in the error message. You could do away with the equiv_flag
> variable if you put the thirde for loop inside if (e2->expr->symtree->n.sym ==
> sym), but it may be that I only find this easier because I was mildly confused
> because the indentation levels got confused in my mailer :-)

I'll have a look at this.
> 
> > + const char * name = {BLANK_COMMON_NAME};
> 
> Um, why the braces?
> 
Are the braces not recommended now, even for string constants?

I will also check out ensuring that equivalences remain within scope, as discussed last week.

Best regards

Paul



More information about the Gcc-patches mailing list