PATCH: ObjC++-related common code mods

Zack Weinberg
Tue Aug 17 21:02:00 GMT 2004

Ziemowit Laski <> writes:

> The get_file_basename() routine attempts to find which language
> subdirectory a given file lives in by comparing the identifiers
> immediately preceding the '/' directory separator with the directories
> it knows about.  This works now, with the directory list consisting of
> 'cp' and 'objc', but breaks when you add 'objcp' into the mix.  For
> example, upon being handed in 'gcc/objcp/objcp-decl.h', the routine
> erroneously concluded that the file resides in 'cp', by matching the
> 'cp/objcp-decl.h' suffix of the name.

Aha.  This is the explanation you were missing the first time; now I
understand this part of the patch.

You should be using IS_DIR_SEPARATOR here instead of comparing against
'/'.  Otherwise this part seems correct to me.

> @@ -1134,10 +1138,7 @@ get_base_file_bitmap (const char *input_
>            {
>              /* It's in a language directory, set that language.  */
>              bitmap = 1 << i;
> -            return bitmap;
>            } 
> - 
> -      abort (); /* Should have found the language.  */
>      }
>    /* If it's in any, then set for the languages
> There is a comment (in English) at the top of this hunk, explaining
> what's going on.  The abort() is removed so that the logic falls
> through to the checks to determine which language(s)
> the file belongs to.  The important part here is that a file may
> belong to (i.e., be used by) more than one front-end.

The existence of commentary does not excuse you from explaining it in
the text of your message.  I don't try very hard to understand the
patch if it's inadequately explained in the message, and I certainly
will not go look at the modified files in that case.

> Again, note the English comment.  Also note that I'm extending an
> existing idiom for handling files used by more than one idiom.

Same observation as above.

So, putting it all together, you have headers (possibly just
objcp/objcp-decl.h?) that contain GTY information, are shared between
front ends, but are contained in a language subdirectory.  gengtype
currently doesn't support this, and you need it to.  You accomplish
this by (a) fixing a bug in some code that looks for basenames,
(b) augmenting an existing list of special cases, and (c) adjusting
the way files are determined to belong to languages.

Do I understand correctly?  If so, I'm mostly good with this, but I
would like to hear Geoff's opinion on (c) (i.e. the change to


More information about the Gcc-patches mailing list