Message ID | 20130902075801.GA981@ours.starynkevitch.net |
---|---|
State | New |
Headers | show |
Hello all, I'm pinging the patch (of september 2nd) on http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html #### gcc/ChangeLog entry 2013-09-16 Basile Starynkevitch <basile@starynkevitch.net> * gengtype.c (file_rules): Added rule for *.cc files. (get_output_file_with_visibility): Give fatal message when no rules found. ### Regards
On 2013-09-16 04:19 , Basile Starynkevitch wrote: > Hello all, > > I'm pinging the patch (of september 2nd) on > http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html > > > #### gcc/ChangeLog entry > > 2013-09-16 Basile Starynkevitch <basile@starynkevitch.net> > > * gengtype.c (file_rules): Added rule for *.cc files. > (get_output_file_with_visibility): Give fatal message when no > rules found. OK. Diego.
On Fri, Sep 20, 2013 at 09:53:10AM -0400, Diego Novillo wrote: > On 2013-09-16 04:19 , Basile Starynkevitch wrote: > >Hello all, > > > >I'm pinging the patch (of september 2nd) on > >http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html > > > > > >#### gcc/ChangeLog entry > > > >2013-09-16 Basile Starynkevitch <basile@starynkevitch.net> > > > > * gengtype.c (file_rules): Added rule for *.cc files. > > (get_output_file_with_visibility): Give fatal message when no > > rules found. > > OK. Thanks for the review and the approval. I just commited revision 202782. BTW, I believe this patch should be back ported, at least to next GCC 4.8.2 (and perhaps even to 4.7). What do you think? Cheers
On Fri, Sep 20, 2013 at 05:52:38PM +0200, Basile Starynkevitch wrote: > On Fri, Sep 20, 2013 at 09:53:10AM -0400, Diego Novillo wrote: > > On 2013-09-16 04:19 , Basile Starynkevitch wrote: > > >Hello all, > > > > > >I'm pinging the patch (of september 2nd) on > > >http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html > > > > > > > > >#### gcc/ChangeLog entry > > > > > >2013-09-16 Basile Starynkevitch <basile@starynkevitch.net> > > > > > > * gengtype.c (file_rules): Added rule for *.cc files. > > > (get_output_file_with_visibility): Give fatal message when no > > > rules found. > > > > OK. > > Thanks for the review and the approval. I just commited revision 202782. > > BTW, I believe this patch should be back ported, at least to next GCC 4.8.2 > (and perhaps even to 4.7). What do you think? Why? There are no *.cc files in 4.8.x and I don't see why this patch would be desirable for the release branches. Jakub
On Fri, Sep 20, 2013 at 05:56:22PM +0200, Jakub Jelinek wrote: > On Fri, Sep 20, 2013 at 05:52:38PM +0200, Basile Starynkevitch wrote: > > On Fri, Sep 20, 2013 at 09:53:10AM -0400, Diego Novillo wrote: > > > On 2013-09-16 04:19 , Basile Starynkevitch wrote: > > > >Hello all, > > > > > > > >I'm pinging the patch (of september 2nd) on > > > >http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00036.html > > > > > > > > > > > >#### gcc/ChangeLog entry > > > > > > > >2013-09-16 Basile Starynkevitch <basile@starynkevitch.net> > > > > > > > > * gengtype.c (file_rules): Added rule for *.cc files. > > > > (get_output_file_with_visibility): Give fatal message when no > > > > rules found. > > > > > > OK. > > > > Thanks for the review and the approval. I just commited revision 202782. > > > > BTW, I believe this patch should be back ported, at least to next GCC 4.8.2 > > (and perhaps even to 4.7). What do you think? > > Why? There are no *.cc files in 4.8.x and I don't see why this patch would > be desirable for the release branches. Because 4.8 (and even 4.7) plugins may have .cc files and they are running (when they have GTY-ed data) gengtype to be built. In general, I still do find that naming .c a C++ file is very confusing (especially for newbies). BTW, some other compilers don't like that (in particular Clang issues a warning when compiling a C++ file named .c, so Clang issues a lot of warnings when compiling GCC) Of course, one might say that no recent C++ formal standard states that C++ source files should have a .cc or .cxx or .cpp or .C extension (but I am not sure of this) but this is a common practice since several decades (probably since the origin of C++). INSHO plugins for GCC don't have any reasons to follow the GCC (obscure and undocumented) bad & crazy habit of naming .c a C++ file (that a plain C compiler won't even compile!). So I believe that the plugin infrastructure should accept -and even mandates, or at least strongly advise- that plugin files should be named *.cc (or *.cpp). And since GCC 4.8 (and even 4.7) requires a C++ compiler, their plugins should generally be coded in C++ not in C. And such a plugin C++ source file has absolutely no reason to be named *.c (the reason why GCC still have *.c file is some obscure version controlling reason; one might be tempted to think that if the version control wants *.c files for C++ source, that version control is broken and should be replaced by some more fancy thing...) Not accepting plugin source files named .cc for C++ source code is IMHO a bug. And some plugins (those with GTY-ed data) do use gengtype during their build. Cheers.
Index: gcc/gengtype.c =================================================================== --- gcc/gengtype.c (revision 202160) +++ gcc/gengtype.c (working copy) @@ -2004,14 +2004,21 @@ REG_EXTENDED, NULL_REGEX, "gt-objc-objc-map.h", "objc/objc-map.c", NULL_FRULACT }, - /* General cases. For header *.h and source *.c files, we need - * special actions to handle the language. */ + /* General cases. For header *.h and source *.c or *.cc files, we + * need special actions to handle the language. */ /* Source *.c files are using get_file_gtfilename to compute their output_name and get_file_basename to compute their for_name through the source_dot_c_frul action. */ { DIR_PREFIX_REGEX "([[:alnum:]_-]*)\\.c$", REG_EXTENDED, NULL_REGEX, "gt-$3.h", "$3.c", source_dot_c_frul}, + + /* Source *.cc files are using get_file_gtfilename to compute their + output_name and get_file_basename to compute their for_name + through the source_dot_c_frul action. */ + { DIR_PREFIX_REGEX "([[:alnum:]_-]*)\\.cc$", + REG_EXTENDED, NULL_REGEX, "gt-$3.h", "$3.cc", source_dot_c_frul}, + /* Common header files get "gtype-desc.c" as their output_name, * while language specific header files are handled specially. So * we need the header_dot_h_frul action. */ @@ -2269,9 +2276,9 @@ } if (!output_name || !for_name) { - /* This is impossible, and could only happen if the files_rules is - incomplete or buggy. */ - gcc_unreachable (); + /* This should not be possible, and could only happen if the + files_rules is incomplete or buggy. */ + fatal ("failed to compute output name for %s", inpfname); } /* Look through to see if we've ever seen this output filename