Message ID | 57564370-7184-ef62-039e-60b150058fd8@suse.cz |
---|---|
State | New |
Headers | show |
Series | Mass rename of C++ .c files to .cc suffix | expand |
On 1/11/22 13:56, Martin Liška wrote: > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > Plus it survives build of all FEs (--enable-languages=all) on > x86_64-linux-gnu > and I've built all cross compilers. Does this also rename .c files in the fortran and libgfortran directories ? I would recommend to send this message to the fortran@gcc.gnu.org list too, then. Not everyone reads the gcc and gcc-patches lists ... Kind regards,
On 1/11/22 16:48, Toon Moene wrote: > On 1/11/22 13:56, Martin Liška wrote: > >> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. >> Plus it survives build of all FEs (--enable-languages=all) on x86_64-linux-gnu >> and I've built all cross compilers. > > Does this also rename .c files in the fortran and libgfortran directories ? Hello. Yes, it does the first one. > > I would recommend to send this message to the fortran@gcc.gnu.org list too, then. > > Not everyone reads the gcc and gcc-patches lists ... CCing the list now. Thanks, Martin > > Kind regards, >
On Tue, Jan 11, 2022 at 04:50:02PM +0100, Martin Liška wrote: > On 1/11/22 16:48, Toon Moene wrote: > > On 1/11/22 13:56, Martin Liška wrote: > > > > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > > Plus it survives build of all FEs (--enable-languages=all) on x86_64-linux-gnu > > > and I've built all cross compilers. > > > > Does this also rename .c files in the fortran and libgfortran directories ? > > Hello. > > Yes, it does the first one. And it shouldn't in libgfortran - libgfortran, libgcc, libgomp, libquadmath are all written in C, not C++. While e.g. libcpp or gcc are in C++. Jakub
On 1/11/22 16:56, Jakub Jelinek wrote:
> While e.g. libcpp or gcc are in C++.
Which means I should rename .c files under libcpp, right?
Is there any other folder from gcc/ and libcpp/ that would need that as well?
Martin
On Tue, Jan 11, 2022 at 05:03:34PM +0100, Martin Liška wrote: > On 1/11/22 16:56, Jakub Jelinek wrote: > > While e.g. libcpp or gcc are in C++. > > Which means I should rename .c files under libcpp, right? > Is there any other folder from gcc/ and libcpp/ that would need that as well? From the directories that use .c files for C++, I think that is all. c++tools/, libcody/, libitm/, libsanitizer/, libstdc++-v3/ already use .cc or .cpp. Jakub
Am 11.01.22 um 16:50 schrieb Martin Liška: > On 1/11/22 16:48, Toon Moene wrote: >> On 1/11/22 13:56, Martin Liška wrote: >> >>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. >>> Plus it survives build of all FEs (--enable-languages=all) on >>> x86_64-linux-gnu >>> and I've built all cross compilers. >> >> Does this also rename .c files in the fortran and libgfortran >> directories ? > > Hello. > > Yes, it does the first one. Regarding fortran: can we have a vote on this one? Some developers (including myself) are not really familiar with C++, and in the past preference has been expressed on the fortran ML in favor of not using too much C++. I would also not really be in a position to review real C++ code. Thanks, Harald >> >> I would recommend to send this message to the fortran@gcc.gnu.org list >> too, then. >> >> Not everyone reads the gcc and gcc-patches lists ... > > CCing the list now. > > Thanks, > Martin > >> >> Kind regards, >> > >
On Tue, 11 Jan 2022 at 18:02, Harald Anlauf via Gcc <gcc@gcc.gnu.org> wrote: > > Am 11.01.22 um 16:50 schrieb Martin Liška: > > On 1/11/22 16:48, Toon Moene wrote: > >> On 1/11/22 13:56, Martin Liška wrote: > >> > >>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > >>> Plus it survives build of all FEs (--enable-languages=all) on > >>> x86_64-linux-gnu > >>> and I've built all cross compilers. > >> > >> Does this also rename .c files in the fortran and libgfortran > >> directories ? > > > > Hello. > > > > Yes, it does the first one. > > Regarding fortran: can we have a vote on this one? > > Some developers (including myself) are not really familiar with C++, > and in the past preference has been expressed on the fortran ML in > favor of not using too much C++. > > I would also not really be in a position to review real C++ code. The discussion is purely about renaming files that are *already* C++ source files but have the misleading .c file extension. Nobody is suggesting using C++ where it isn't already being used.
On Tue, Jan 11, 2022 at 06:23:51PM +0000, Jonathan Wakely via Gcc-patches wrote: > > Regarding fortran: can we have a vote on this one? > > > > Some developers (including myself) are not really familiar with C++, > > and in the past preference has been expressed on the fortran ML in > > favor of not using too much C++. > > > > I would also not really be in a position to review real C++ code. > > The discussion is purely about renaming files that are *already* C++ > source files but have the misleading .c file extension. > > Nobody is suggesting using C++ where it isn't already being used. And even gcc/fortran/ is written in C++, the gcc/ headers it uses are C++ only, they use templates etc., so gcc/fortran/ that uses those headers has to be C++ too. That doesn't mean you need to use C++ idioms everywhere in your code, those files can stay to be mostly C-like with C++ headers and use C++-only constructs only where it brings sufficient advantages. Many of the gcc/*.c sources that Martin wants to rename are also written like that. The renaming will just match the reality, clang++ will stop warning that support for .c extension for C++ is deprecated when building gcc, sites like openhub.net (if they twice a year manage to build stats for gcc, dunno what they are doing wrong or if it is because of the limiting of anonymous git on sourceware) will not claim most of GCC is written in C etc. Jakub
On 1/11/22 17:16, Jakub Jelinek wrote: > On Tue, Jan 11, 2022 at 05:03:34PM +0100, Martin Liška wrote: >> On 1/11/22 16:56, Jakub Jelinek wrote: >>> While e.g. libcpp or gcc are in C++. >> >> Which means I should rename .c files under libcpp, right? >> Is there any other folder from gcc/ and libcpp/ that would need that as well? > > From the directories that use .c files for C++, I think that is all. > c++tools/, libcody/, libitm/, libsanitizer/, libstdc++-v3/ already > use .cc or .cpp. All right, I've included libcpp folder in the renaming effort. Please take a look at V2 of the series here: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/cc-renaming Now I filled up complete ChangeLog entries and I'm asking for a patchset approval. Cheers, Martin > > Jakub >
Hi, On Tue, Jan 11 2022, Martin Liška wrote: > Hello. > > I've got a patch series that does the renaming. It contains of 2 automatic > scripts ([1] and [2]) that were run as: > > $ gcc-renaming-candidates.py gcc --rename && git commit -a -m 'Rename files.' && rename-gcc.py . -vv && git commit -a -m 'Automatic renaming' > > The first scripts does the renaming (with a couple of exceptions that are really C files) and saves > the renamed files to a file. Then the file is then loaded and replacement of all the renamed files does happen > for most of the GCC files ([2]). It basically replaces at \b${old_filename}\b with ${old_filename}c > (with some exceptions). That corresponds to patch #1 and #2 and the patches are quite huge. > > The last piece are manual changes needed for Makefile.in, configure.ac and so on. > > The git branch can be seen here: > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/cc-renaming > > and pulled with: > $ git fetch refs/users/marxin/heads/cc-renaming > $ git co FETCH_HEAD > Thanks for the effort! I looked at the branch and liked what I saw. Perhaps only a small nit about the commit message of the 2nd commit ("Automatic renaming of .c files to .cc.") which confused me. It does not actually rename any files so I would change it to "change references to .c files to .cc files" or something like that. But I assume the branch will need to be committed squashed anyway, so commit message worries might be a bit premature. I am looking forward to seeing it in trunk. Martin
On 1/13/22 11:47, Martin Jambor wrote: > Hi, > > On Tue, Jan 11 2022, Martin Liška wrote: >> Hello. >> >> I've got a patch series that does the renaming. It contains of 2 automatic >> scripts ([1] and [2]) that were run as: >> >> $ gcc-renaming-candidates.py gcc --rename && git commit -a -m 'Rename files.' && rename-gcc.py . -vv && git commit -a -m 'Automatic renaming' >> >> The first scripts does the renaming (with a couple of exceptions that are really C files) and saves >> the renamed files to a file. Then the file is then loaded and replacement of all the renamed files does happen >> for most of the GCC files ([2]). It basically replaces at \b${old_filename}\b with ${old_filename}c >> (with some exceptions). That corresponds to patch #1 and #2 and the patches are quite huge. >> >> The last piece are manual changes needed for Makefile.in, configure.ac and so on. >> >> The git branch can be seen here: >> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/cc-renaming >> >> and pulled with: >> $ git fetch refs/users/marxin/heads/cc-renaming >> $ git co FETCH_HEAD >> > > Thanks for the effort! I looked at the branch and liked what I saw. Thanks. > Perhaps only a small nit about the commit message of the 2nd commit > ("Automatic renaming of .c files to .cc.") which confused me. It does > not actually rename any files so I would change it to "change references > to .c files to .cc files" or something like that. Sure, I'm going to update the commit message. > > But I assume the branch will need to be committed squashed anyway, so > commit message worries might be a bit premature. No, I would like to commit it as 3 separate commits for this reasons: - git renaming with 100% match should guarantee git would fully work with merging and stuff like that - I would like to distinguish manual changes from these that are only a mechanical replacement. Cheers, Martin > > I am looking forward to seeing it in trunk. > > Martin
Hello. Based on the discussion with release managers, the change is going to happen after stage4 begins. Martin
On Thu, Jan 13, 2022 at 11:59 AM Martin Liška <mliska@suse.cz> wrote: > > On 1/13/22 11:47, Martin Jambor wrote: > > Hi, > > > > On Tue, Jan 11 2022, Martin Liška wrote: > >> Hello. > >> > >> I've got a patch series that does the renaming. It contains of 2 automatic > >> scripts ([1] and [2]) that were run as: > >> > >> $ gcc-renaming-candidates.py gcc --rename && git commit -a -m 'Rename files.' && rename-gcc.py . -vv && git commit -a -m 'Automatic renaming' > >> > >> The first scripts does the renaming (with a couple of exceptions that are really C files) and saves > >> the renamed files to a file. Then the file is then loaded and replacement of all the renamed files does happen > >> for most of the GCC files ([2]). It basically replaces at \b${old_filename}\b with ${old_filename}c > >> (with some exceptions). That corresponds to patch #1 and #2 and the patches are quite huge. > >> > >> The last piece are manual changes needed for Makefile.in, configure.ac and so on. > >> > >> The git branch can be seen here: > >> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=log;h=refs/users/marxin/heads/cc-renaming > >> > >> and pulled with: > >> $ git fetch refs/users/marxin/heads/cc-renaming > >> $ git co FETCH_HEAD > >> > > > > Thanks for the effort! I looked at the branch and liked what I saw. > > Thanks. > > > Perhaps only a small nit about the commit message of the 2nd commit > > ("Automatic renaming of .c files to .cc.") which confused me. It does > > not actually rename any files so I would change it to "change references > > to .c files to .cc files" or something like that. > > Sure, I'm going to update the commit message. > > > > > But I assume the branch will need to be committed squashed anyway, so > > commit message worries might be a bit premature. > > No, I would like to commit it as 3 separate commits for this reasons: > - git renaming with 100% match should guarantee git would fully work with merging and stuff like that > - I would like to distinguish manual changes from these that are only a mechanical replacement. But please make sure all intermediate revs will still build. Richard. > Cheers, > Martin > > > > > I am looking forward to seeing it in trunk. > > > > Martin >
On 1/13/22 12:14, Richard Biener wrote:
> But please make sure all intermediate revs will still build.
That's not possible :) I don't it's a good idea mixing .cc renaming
and changes in that files.
Martin
On Thu, Jan 13, 2022 at 12:20:57PM +0100, Martin Liška wrote: > On 1/13/22 12:14, Richard Biener wrote: > > But please make sure all intermediate revs will still build. > > That's not possible :) I don't it's a good idea mixing .cc renaming > and changes in that files. I think it is possible, but would require more work. Comments in the files don't matter for sure, and in the Makefiles we could do (just one random file can be checked): ifeq (,$(wildcard $(srcdir)/expr.cc)) what we used to do else what we want to do newly endif A commit that changes the Makefiles that way comes first, then the renaming commit, then a commit that removes those ifeq ... else and endif lines. Jakub
On Thu, Jan 13 2022, Jakub Jelinek via Gcc-patches wrote: > On Thu, Jan 13, 2022 at 12:20:57PM +0100, Martin Liška wrote: >> On 1/13/22 12:14, Richard Biener wrote: >> > But please make sure all intermediate revs will still build. >> >> That's not possible :) I don't it's a good idea mixing .cc renaming >> and changes in that files. > > I think it is possible, but would require more work. > Comments in the files don't matter for sure, and in the Makefiles we > could do (just one random file can be checked): > ifeq (,$(wildcard $(srcdir)/expr.cc)) > what we used to do > else > what we want to do newly > endif > A commit that changes the Makefiles that way comes first, then > the renaming commit, then a commit that removes those ifeq ... else > and endif lines. > I would expect that the problematic case is only when you modify a file that you also rename. Is there any such file where we do more than adjust comments, where the contents modifications are essential for bootstrap too? I would expect that modifications in Makefiles, configure-scripts etc could go in the same commit as the renames and these could be then followed up with comments adjustments and similar. But it would be more work, so I guess just using git bisect skip if bisection ever lands in the middle of this is acceptable in this special case too. Martin
On 1/13/22 12:01, Martin Liška wrote: > Hello. > > Based on the discussion with release managers, the change is going to happen > after stage4 begins. > > Martin Hi. The renaming patches have been just installed and I've built a few target compilers so far. I'll be online in ~10 hours from now so I can address potential issues caused by the patch. One note: I would recommend using: git config log.follow true That causes git log following changes of a file before it was renamed so that one can get a complete history. Cheers, Martin
Martin, > The renaming patches have been just installed and I've built a few target > compilers so far. I'll be online in ~10 hours from now so I can address > potential issues caused by the patch. Who approved it though? The renaming of the C files in the ada/ directory is wrong and should be reverted ASAP.
On 1/18/22 09:36, Eric Botcazou wrote: > Martin, > >> The renaming patches have been just installed and I've built a few target >> compilers so far. I'll be online in ~10 hours from now so I can address >> potential issues caused by the patch. > > Who approved it though? Release managers. > The renaming of the C files in the ada/ directory is > wrong and should be reverted ASAP. Working on that right now, sorry.. Martin
> Release managers. They certainly have authority on the timing, but not on the contents. > Working on that right now, sorry.. OK, thanks in advance.
On Tue, Jan 18, 2022 at 9:46 AM Eric Botcazou via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > > Release managers. > > They certainly have authority on the timing, but not on the contents. Technically all release managers are also global reviewers, but I agree the speciality of the Ada setup (esp. the runtime being in gcc/) could have been anticipated. Richard. > > Working on that right now, sorry.. > > OK, thanks in advance. > > -- > Eric Botcazou > >
On 1/18/22 09:53, Richard Biener wrote: > Technically all release managers are also global reviewers, but I > agree the speciality > of the Ada setup (esp. the runtime being in gcc/) could have been anticipated. Yeah, I thought that building Ada FE is enough for testing effort, sorry. I would like to install the following 2 patches that revert the changes. After the change we're going to have: marxin@marxinbox:~/Programming/gcc/gcc/ada> find . -name '*.cc' ./gcc-interface/targtyps.cc ./gcc-interface/decl.cc ./gcc-interface/cuintp.cc ./gcc-interface/trans.cc ./gcc-interface/misc.cc ./gcc-interface/utils2.cc ./gcc-interface/utils.cc So far I've just make check-ada and there are no failures. May I install the patch? Thanks, Martin
On Tue, Jan 18, 2022 at 10:08:20AM +0100, Martin Liška wrote: > On 1/18/22 09:53, Richard Biener wrote: > > Technically all release managers are also global reviewers, but I > > agree the speciality > > of the Ada setup (esp. the runtime being in gcc/) could have been anticipated. > > Yeah, I thought that building Ada FE is enough for testing effort, sorry. > > I would like to install the following 2 patches that revert the changes. > After the change we're going to have: > > marxin@marxinbox:~/Programming/gcc/gcc/ada> find . -name '*.cc' > ./gcc-interface/targtyps.cc > ./gcc-interface/decl.cc > ./gcc-interface/cuintp.cc > ./gcc-interface/trans.cc > ./gcc-interface/misc.cc > ./gcc-interface/utils2.cc > ./gcc-interface/utils.cc > > So far I've just make check-ada and there are no failures. > > May I install the patch? LGTM. > From ddbf347224c27b7ecf41c546081db13cde136cf3 Mon Sep 17 00:00:00 2001 > From: Martin Liska <mliska@suse.cz> > Date: Tue, 18 Jan 2022 10:02:47 +0100 > Subject: [PATCH 2/2] Ada: Revert filename changes in comments. > > gcc/ada/ChangeLog: > > * adaint.c: Revert filename changes in comments. > * ctrl_c.c (dummy_handler): Likewise. > * gsocket.h: Likewise. > * init.c (__gnat_error_handler): Likewise. > * libgnarl/s-intman.ads: Likewise. > * libgnarl/s-osinte__android.ads: Likewise. > * libgnarl/s-osinte__darwin.ads: Likewise. > * libgnarl/s-osinte__hpux.ads: Likewise. > * libgnarl/s-osinte__linux.ads: Likewise. > * libgnarl/s-osinte__qnx.ads: Likewise. > * libgnarl/s-taskin.ads: Likewise. > * rtfinal.c: Likewise. > gcc/ada/ChangeLog: > > * Make-generated.in: Revert renaming changes. > * Makefile.rtl: Likewise. > * adadecode.cc: Moved to... > * adadecode.c: ...here. > * affinity.cc: Moved to... > * affinity.c: ...here. > * argv-lynxos178-raven-cert.cc: Moved to... > * argv-lynxos178-raven-cert.c: ...here. > * argv.cc: Moved to... > * argv.c: ...here. > * aux-io.cc: Moved to... > * aux-io.c: ...here. > * cio.cc: Moved to... > * cio.c: ...here. > * cstreams.cc: Moved to... > * cstreams.c: ...here. > * env.cc: Moved to... > * env.c: ...here. > * exit.cc: Moved to... > * exit.c: ...here. > * expect.cc: Moved to... > * expect.c: ...here. > * final.cc: Moved to... > * final.c: ...here. > * gcc-interface/Makefile.in: > * init.cc: Moved to... > * init.c: ...here. > * initialize.cc: Moved to... > * initialize.c: ...here. > * libgnarl/thread.cc: Moved to... > * libgnarl/thread.c: ...here. > * link.cc: Moved to... > * link.c: ...here. > * locales.cc: Moved to... > * locales.c: ...here. > * mkdir.cc: Moved to... > * mkdir.c: ...here. > * raise.cc: Moved to... > * raise.c: ...here. > * rtfinal.cc: Moved to... > * rtfinal.c: ...here. > * rtinit.cc: Moved to... > * rtinit.c: ...here. > * s-oscons-tmplt.c (CND): > * seh_init.cc: Moved to... > * seh_init.c: ...here. > * sigtramp-armdroid.cc: Moved to... > * sigtramp-armdroid.c: ...here. > * sigtramp-ios.cc: Moved to... > * sigtramp-ios.c: ...here. > * sigtramp-qnx.cc: Moved to... > * sigtramp-qnx.c: ...here. > * sigtramp-vxworks.cc: Moved to... > * sigtramp-vxworks.c: ...here. > * socket.cc: Moved to... > * socket.c: ...here. > * tracebak.cc: Moved to... > * tracebak.c: ...here. > * version.cc: Moved to... > * version.c: ...here. > * vx_stack_info.cc: Moved to... > * vx_stack_info.c: ...here. Jakub
> > LGTM. > I've just installed that, the Ada testsuite should work now. Martin
On 17/01/2022 21:41, Martin Liška wrote: > On 1/13/22 12:01, Martin Liška wrote: >> Hello. >> >> Based on the discussion with release managers, the change is going to >> happen >> after stage4 begins. >> >> Martin > > Hi. > > The renaming patches have been just installed and I've built a few > target compilers so far. > I'll be online in ~10 hours from now so I can address potential issues > caused by the patch. > > One note: I would recommend using: > git config log.follow true > Is that worth adding to contrib/gcc-git-customization.sh ? > That causes git log following changes of a file before it was renamed so > that > one can get a complete history. > > Cheers, > Martin R.
On 1/18/22 14:10, Richard Earnshaw wrote:
> Is that worth adding to contrib/gcc-git-customization.sh ?
Yes, can you please do that?
Thanks,
Martin
From 65bb0c6b03ed394669471befe54482858d982ee2 Mon Sep 17 00:00:00 2001 From: Martin Liska <mliska@suse.cz> Date: Mon, 10 Jan 2022 11:46:58 +0100 Subject: [PATCH 3/3] Manual changes for .cc renaming. gcc/ChangeLog: * Makefile.in: Rename .c names to .cc. * config.gcc: Likewise. * configure: Regenerate. Likewise. * configure.ac: Likewise. * gengtype.cc (set_gc_used): Likewise. (source_dot_c_frul): Likewise. (source_dot_cc_frul): Likewise. (struct file_rule_st): Likewise. (close_output_files): Likewise. gcc/ada/ChangeLog: * Makefile.rtl: Rename .c names to .cc. * gcc-interface/Make-lang.in: Likewise. * gcc-interface/Makefile.in: Likewise. libgcc/ChangeLog: * libgcov-driver.c: Rename .c names to .cc. --- gcc/Makefile.in | 46 +++++++++++++++--------------- gcc/ada/Makefile.rtl | 8 +++--- gcc/ada/gcc-interface/Make-lang.in | 6 ++-- gcc/ada/gcc-interface/Makefile.in | 6 ++++ gcc/config.gcc | 2 +- gcc/configure | 37 ++++++++++++++++++------ gcc/configure.ac | 6 ++-- gcc/gengtype.cc | 30 ++++++++----------- libgcc/libgcov-driver.c | 2 +- 9 files changed, 81 insertions(+), 62 deletions(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index e13bf66b040..31ff95500c9 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -1784,7 +1784,7 @@ MOSTLYCLEANFILES = insn-flags.h insn-config.h insn-codes.h \ gcc-ranlib$(exeext) \ genversion$(build_exeext) gcov$(exeext) gcov-dump$(exeext) \ gcov-tool$(exeect) \ - gengtype$(exeext) *.[0-9][0-9].* *.[si] *-checksum.c libbackend.a \ + gengtype$(exeext) *.[0-9][0-9].* *.[si] *-checksum.cc libbackend.a \ libcommon-target.a libcommon.a libgcc.mk perf.data # This symlink makes the full installation name of the driver be available @@ -2421,10 +2421,10 @@ simple_generated_h = $(simple_rtl_generated_h) insn-constants.h simple_generated_c = $(simple_rtl_generated_c) insn-enums.cc $(simple_generated_h:insn-%.h=s-%) \ -$(simple_generated_c:insn-%.c=s-%): s-%: $(MD_DEPS) +$(simple_generated_c:insn-%.cc=s-%): s-%: $(MD_DEPS) $(simple_rtl_generated_h:insn-%.h=s-%) \ -$(simple_rtl_generated_c:insn-%.c=s-%): s-%: insn-conditions.md +$(simple_rtl_generated_c:insn-%.cc=s-%): s-%: insn-conditions.md $(simple_generated_h): insn-%.h: s-%; @true @@ -2434,11 +2434,11 @@ $(simple_generated_h:insn-%.h=s-%): s-%: build/gen%$(build_exeext) $(SHELL) $(srcdir)/../move-if-change tmp-$*.h insn-$*.h $(STAMP) s-$* -$(simple_generated_c): insn-%.c: s-%; @true -$(simple_generated_c:insn-%.c=s-%): s-%: build/gen%$(build_exeext) +$(simple_generated_c): insn-%.cc: s-%; @true +$(simple_generated_c:insn-%.cc=s-%): s-%: build/gen%$(build_exeext) $(RUN_GEN) build/gen$*$(build_exeext) $(md_file) \ - $(filter insn-conditions.md,$^) > tmp-$*.c - $(SHELL) $(srcdir)/../move-if-change tmp-$*.c insn-$*.c + $(filter insn-conditions.md,$^) > tmp-$*.cc + $(SHELL) $(srcdir)/../move-if-change tmp-$*.cc insn-$*.cc $(STAMP) s-$* # gencheck doesn't read the machine description, and the file produced @@ -2449,12 +2449,12 @@ s-check : build/gencheck$(build_exeext) $(SHELL) $(srcdir)/../move-if-change tmp-check.h tree-check.h $(STAMP) s-check -# genattrtab produces three files: tmp-{attrtab.c,dfatab.c,latencytab.c} +# genattrtab produces three files: tmp-{attrtab.cc,dfatab.cc,latencytab.cc} insn-attrtab.cc insn-dfatab.cc insn-latencytab.cc: s-attrtab ; @true s-attrtab : $(MD_DEPS) build/genattrtab$(build_exeext) \ insn-conditions.md $(RUN_GEN) build/genattrtab$(build_exeext) $(md_file) insn-conditions.md \ - -Atmp-attrtab.c -Dtmp-dfatab.c -Ltmp-latencytab.c + -Atmp-attrtab.cc -Dtmp-dfatab.cc -Ltmp-latencytab.cc $(SHELL) $(srcdir)/../move-if-change tmp-attrtab.cc insn-attrtab.cc $(SHELL) $(srcdir)/../move-if-change tmp-dfatab.cc insn-dfatab.cc $(SHELL) $(srcdir)/../move-if-change tmp-latencytab.cc insn-latencytab.cc @@ -2464,7 +2464,7 @@ s-attrtab : $(MD_DEPS) build/genattrtab$(build_exeext) \ insn-opinit.cc insn-opinit.h: s-opinit ; @true s-opinit: $(MD_DEPS) build/genopinit$(build_exeext) insn-conditions.md $(RUN_GEN) build/genopinit$(build_exeext) $(md_file) \ - insn-conditions.md -htmp-opinit.h -ctmp-opinit.c + insn-conditions.md -htmp-opinit.h -ctmp-opinit.cc $(SHELL) $(srcdir)/../move-if-change tmp-opinit.h insn-opinit.h $(SHELL) $(srcdir)/../move-if-change tmp-opinit.cc insn-opinit.cc $(STAMP) s-opinit @@ -2472,8 +2472,8 @@ s-opinit: $(MD_DEPS) build/genopinit$(build_exeext) insn-conditions.md # gencondmd doesn't use the standard naming convention. build/gencondmd.cc: s-conditions; @true s-conditions: $(MD_DEPS) build/genconditions$(build_exeext) - $(RUN_GEN) build/genconditions$(build_exeext) $(md_file) > tmp-condmd.c - $(SHELL) $(srcdir)/../move-if-change tmp-condmd.c build/gencondmd.cc + $(RUN_GEN) build/genconditions$(build_exeext) $(md_file) > tmp-condmd.cc + $(SHELL) $(srcdir)/../move-if-change tmp-condmd.cc build/gencondmd.cc $(STAMP) s-conditions insn-conditions.md: s-condmd; @true @@ -2499,8 +2499,8 @@ insn-modes-inline.h: s-modes-inline-h; @true min-insn-modes.cc: s-modes-m; @true s-modes: build/genmodes$(build_exeext) - $(RUN_GEN) build/genmodes$(build_exeext) > tmp-modes.c - $(SHELL) $(srcdir)/../move-if-change tmp-modes.c insn-modes.cc + $(RUN_GEN) build/genmodes$(build_exeext) > tmp-modes.cc + $(SHELL) $(srcdir)/../move-if-change tmp-modes.cc insn-modes.cc $(STAMP) s-modes s-modes-h: build/genmodes$(build_exeext) @@ -2515,8 +2515,8 @@ s-modes-inline-h: build/genmodes$(build_exeext) $(STAMP) s-modes-inline-h s-modes-m: build/genmodes$(build_exeext) - $(RUN_GEN) build/genmodes$(build_exeext) -m > tmp-min-modes.c - $(SHELL) $(srcdir)/../move-if-change tmp-min-modes.c min-insn-modes.cc + $(RUN_GEN) build/genmodes$(build_exeext) -m > tmp-min-modes.cc + $(SHELL) $(srcdir)/../move-if-change tmp-min-modes.cc min-insn-modes.cc $(STAMP) s-modes-m insn-preds.cc: s-preds; @true @@ -2528,8 +2528,8 @@ mddump: $(BUILD_RTL) $(MD_DEPS) build/genmddump$(build_exeext) $(RUN_GEN) build/genmddump$(build_exeext) $(md_file) > tmp-mddump.md s-preds: $(MD_DEPS) build/genpreds$(build_exeext) - $(RUN_GEN) build/genpreds$(build_exeext) $(md_file) > tmp-preds.c - $(SHELL) $(srcdir)/../move-if-change tmp-preds.c insn-preds.cc + $(RUN_GEN) build/genpreds$(build_exeext) $(md_file) > tmp-preds.cc + $(SHELL) $(srcdir)/../move-if-change tmp-preds.cc insn-preds.cc $(STAMP) s-preds s-preds-h: $(MD_DEPS) build/genpreds$(build_exeext) @@ -2734,8 +2734,8 @@ GTFILES = $(CPPLIB_H) $(srcdir)/input.h $(srcdir)/coretypes.h \ GTFILES_H = $(subst /,-, \ $(shell echo $(patsubst $(srcdir)/%,gt-%, \ - $(patsubst %.c,%.h, \ - $(filter %.c, $(GTFILES)))) \ + $(patsubst %.cc,%.h, \ + $(filter %.cc, $(GTFILES)))) \ | sed -e "s|/[^ ]*/|/|g" -e "s|gt-config/|gt-|g")) GTFILES_LANG_H = $(patsubst [%], gtype-%.h, $(filter [%], $(GTFILES))) @@ -3536,7 +3536,7 @@ mostlyclean: lang.mostlyclean -rm -f gt-* -rm -f gtype.state # Delete genchecksum outputs - -rm -f *-checksum.c + -rm -f *-checksum.cc # Delete lock-and-run bits -rm -rf linkfe.lck lock-stamp.* @@ -3574,7 +3574,7 @@ distclean: clean lang.distclean -rm -f *.asm -rm -f site.exp site.bak testsuite/site.exp testsuite/site.bak -rm -f testsuite/*.log testsuite/*.sum - -cd testsuite && rm -f x *.x *.x? *.exe *.rpo *.o *.s *.S *.c + -cd testsuite && rm -f x *.x *.x? *.exe *.rpo *.o *.s *.S *.cc -cd testsuite && rm -f *.out *.gcov *$(coverageexts) -rm -rf ${QMTEST_DIR} stamp-qmtest -rm -f .gdbinit configargs.h @@ -4336,7 +4336,7 @@ TAGS: lang.tags incs="$$incs --include $$dir/TAGS.sub"; \ fi; \ done; \ - $(ETAGS) -o TAGS.sub c-family/*.h c-family/*.c c-family/*.cc \ + $(ETAGS) -o TAGS.sub c-family/*.h c-family/*.cc c-family/*.cc \ *.h *.c *.cc \ ../include/*.h ../libiberty/*.c \ ../libcpp/*.c ../libcpp/include/*.h \ diff --git a/gcc/ada/Makefile.rtl b/gcc/ada/Makefile.rtl index 7d319eaedf2..ee0b0d3f31a 100644 --- a/gcc/ada/Makefile.rtl +++ b/gcc/ada/Makefile.rtl @@ -2856,7 +2856,7 @@ LIBGNAT_TARGET_PAIRS += \ # LIBGNAT_SRCS is the list of all C files (including headers) of the runtime # library. LIBGNAT_OBJS is the list of object files for libgnat. -# thread.c is special as put into GNATRTL_TASKING_OBJS +# thread.cc is special as put into GNATRTL_TASKING_OBJS LIBGNAT_OBJS = adadecode.o adaint.o argv.o aux-io.o \ cal.o cio.o cstreams.o ctrl_c.o \ env.o errno.o exit.o expect.o final.o rtfinal.o rtinit.o \ @@ -2870,7 +2870,7 @@ LIBGNAT_OBJS = adadecode.o adaint.o argv.o aux-io.o \ # GNAT_RTL_SRCS. Right now we count on being able to build GNATRTL_OBJS # from ADA_INCLUDE_SRCS. -LIBGNAT_SRCS = $(patsubst %.o,%.c,$(LIBGNAT_OBJS)) \ +LIBGNAT_SRCS = $(patsubst %.o,%.cc,$(LIBGNAT_OBJS)) \ adadecode.h adaint.h env.h gsocket.h raise.h standard.ads.h \ runtime.h $(EXTRA_LIBGNAT_SRCS) @@ -2920,7 +2920,7 @@ setup-rts: force $(MKDIR) $(RTSDIR) $(CHMOD) u+w $(RTSDIR) # Copy target independent sources - $(foreach f,$(ADA_INCLUDE_SRCS) $(LIBGNAT_SRCS) libgnarl/thread.c, \ + $(foreach f,$(ADA_INCLUDE_SRCS) $(LIBGNAT_SRCS) libgnarl/thread.cc, \ $(LN_S) $(GNAT_SRC)/$(f) $(RTSDIR) ;) true # Remove files not used $(RM) $(patsubst %,$(RTSDIR)/%,$(ADA_EXCLUDE_FILES)) @@ -2941,7 +2941,7 @@ setup-rts: force do \ if [ -f $(RTSDIR)/$$f ]; then echo $$f >> $(RTSDIR)/libgnarl.lst; fi \ done - @echo thread.c >> $(RTSDIR)/libgnarl.lst + @echo thread.cc >> $(RTSDIR)/libgnarl.lst @for f in \ $(foreach F,$(GNATRTL_NONTASKING_OBJS),$(subst $(objext),.ads,$(F))) \ $(foreach F,$(GNATRTL_NONTASKING_OBJS),$(subst $(objext),.adb,$(F))); \ diff --git a/gcc/ada/gcc-interface/Make-lang.in b/gcc/ada/gcc-interface/Make-lang.in index 40e7a9f670c..a8d8899d3c9 100644 --- a/gcc/ada/gcc-interface/Make-lang.in +++ b/gcc/ada/gcc-interface/Make-lang.in @@ -121,13 +121,13 @@ ADA_TOOLS=gnatbind gnatchop gnat gnatkr gnatlink gnatls gnatmake \ # Say how to compile Ada programs. .SUFFIXES: .ada .adb .ads -# FIXME: need to add $(ADA_CFLAGS) to .c.o suffix rule +# FIXME: need to add $(ADA_CFLAGS) to .cc.o suffix rule # Use mildly strict warnings for this front end and add special flags. ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN)) # Unresolved warnings in specific files. ada/adaint.o-warn = -Wno-error -ada/%.o: ada/gcc-interface/%.c +ada/%.o: ada/gcc-interface/%.cc $(COMPILE) $< $(POSTCOMPILE) @@ -796,7 +796,7 @@ ada.srcextra: ada.srcman: ada.tags: force - cd $(srcdir)/ada && $(ETAGS) -o TAGS.sub *.c *.h *.ads *.adb && \ + cd $(srcdir)/ada && $(ETAGS) -o TAGS.sub *.cc *.h *.ads *.adb && \ $(ETAGS) --include TAGS.sub --include ../TAGS.sub diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in index cf645df12f1..54cf182a8c3 100644 --- a/gcc/ada/gcc-interface/Makefile.in +++ b/gcc/ada/gcc-interface/Makefile.in @@ -296,6 +296,10 @@ ADA_INCLUDES_FOR_SUBDIR = -I. -I$(fsrcdir)/ada $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ADA_CFLAGS) $(ALL_CPPFLAGS) \ $(INCLUDES) $< $(OUTPUT_OPTION) +.cc.o: + $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ADA_CFLAGS) $(ALL_CPPFLAGS) \ + $(INCLUDES) $< $(OUTPUT_OPTION) + .adb.o: $(CC) -c $(ALL_ADAFLAGS) $(ADA_INCLUDES) $< $(OUTPUT_OPTION) @@ -411,6 +415,7 @@ ifeq ($(TOOLSCASE),native) vpath %.ads ../$(RTSDIR) ../ vpath %.adb ../$(RTSDIR) ../ vpath %.c ../$(RTSDIR) ../ + vpath %.cc ../$(RTSDIR) ../ vpath %.h ../$(RTSDIR) ../ endif @@ -420,6 +425,7 @@ ifeq ($(TOOLSCASE),cross) vpath %.ads ../ vpath %.adb ../ vpath %.c ../ + vpath %.cc ../ vpath %.h ../ endif diff --git a/gcc/config.gcc b/gcc/config.gcc index 73ad94ec75f..ff1b4c369ba 100644 --- a/gcc/config.gcc +++ b/gcc/config.gcc @@ -5374,7 +5374,7 @@ case ${target} in then target_cpu_default2="\\\"$with_cpu\\\"" fi - out_file="${cpu_type}/${cpu_type}.c" + out_file="${cpu_type}/${cpu_type}.cc" c_target_objs="${c_target_objs} ${cpu_type}-c.o" cxx_target_objs="${cxx_target_objs} ${cpu_type}-c.o" d_target_objs="${d_target_objs} ${cpu_type}-d.o" diff --git a/gcc/configure b/gcc/configure index 992a9d70092..e787646c1d3 100755 --- a/gcc/configure +++ b/gcc/configure @@ -592,7 +592,7 @@ PACKAGE_STRING= PACKAGE_BUGREPORT= PACKAGE_URL= -ac_unique_file="tree.c" +ac_unique_file="tree.cc" # Factoring default headers for most tests. ac_includes_default="\ #include <stdio.h> @@ -5352,7 +5352,26 @@ else GDC="$ac_cv_prog_GDC" fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking whether the D compiler works" >&5 +$as_echo_n "checking whether the D compiler works... " >&6; } +if ${acx_cv_d_compiler_works+:} false; then : + $as_echo_n "(cached) " >&6 +else + cat >conftest.d <<EOF +module conftest; int main() { return 0; } +EOF +acx_cv_d_compiler_works=no if test "x$GDC" != xno; then + errors=`(${GDC} -I"$srcdir"/d -c conftest.d) 2>&1 || echo failure` + if test x"$errors" = x && test -f conftest.$ac_objext; then + acx_cv_d_compiler_works=yes + fi + rm -f conftest.* +fi +fi +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $acx_cv_d_compiler_works" >&5 +$as_echo "$acx_cv_d_compiler_works" >&6; } +if test "x$GDC" != xno && test x$acx_cv_d_compiler_works != xno; then have_gdc=yes else have_gdc=no @@ -8297,7 +8316,7 @@ fi test -n "$AWK" && break done -# We need awk to create options.c and options.h. +# We need awk to create options.cc and options.h. # Bail out if it's missing. case ${AWK} in "") as_fn_error $? "can't build without awk, bailing out" "$LINENO" 5 ;; @@ -12025,7 +12044,7 @@ rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext # On AIX 5.2, <ldfcn.h> conflicts with <fcntl.h>, as both define incompatible # FREAD and FWRITE macros. Fortunately, for GCC's single usage of ldgetname -# in collect2.c, <fcntl.h> isn't visible, but the configure test below needs +# in collect2.cc, <fcntl.h> isn't visible, but the configure test below needs # to undef these macros to get the correct value for HAVE_DECL_LDGETNAME. for ac_func in ldgetname do @@ -12601,7 +12620,7 @@ if test x$md_file = x then md_file=$cpu_type/$cpu_type.md; fi if test x$out_file = x -then out_file=$cpu_type/$cpu_type.c; fi +then out_file=$cpu_type/$cpu_type.cc; fi if test x"$tmake_file" = x then tmake_file=$cpu_type/t-$cpu_type @@ -13253,8 +13272,8 @@ do done tmake_file="${tmake_file_}${omp_device_property_tmake_file}" -out_object_file=`basename $out_file .c`.o -common_out_object_file=`basename $common_out_file .c`.o +out_object_file=`basename $out_file .cc`.o +common_out_object_file=`basename $common_out_file .cc`.o tm_file_list="options.h" tm_include_list="options.h insn-constants.h" @@ -19561,7 +19580,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 19564 "configure" +#line 19583 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -19667,7 +19686,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 19670 "configure" +#line 19689 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -32221,7 +32240,7 @@ _ACEOF # Generate gcc-driver-name.h containing GCC_DRIVER_NAME for the benefit -# of jit/jit-playback.c. +# of jit/jit-playback.cc. gcc_driver_version=`eval "${get_gcc_base_ver} $srcdir/BASE-VER"` echo "gcc_driver_version: ${gcc_driver_version}" cat > gcc-driver-name.h <<EOF diff --git a/gcc/configure.ac b/gcc/configure.ac index 3dd210a8f8c..e8d2f6bbb62 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -1824,7 +1824,7 @@ if test x$md_file = x then md_file=$cpu_type/$cpu_type.md; fi if test x$out_file = x -then out_file=$cpu_type/$cpu_type.c; fi +then out_file=$cpu_type/$cpu_type.cc; fi if test x"$tmake_file" = x then tmake_file=$cpu_type/t-$cpu_type @@ -2294,8 +2294,8 @@ do done tmake_file="${tmake_file_}${omp_device_property_tmake_file}" -out_object_file=`basename $out_file .c`.o -common_out_object_file=`basename $common_out_file .c`.o +out_object_file=`basename $out_file .cc`.o +common_out_object_file=`basename $common_out_file .cc`.o tm_file_list="options.h" tm_include_list="options.h insn-constants.h" diff --git a/gcc/gengtype.cc b/gcc/gengtype.cc index e737c939457..386ae1b0506 100644 --- a/gcc/gengtype.cc +++ b/gcc/gengtype.cc @@ -1618,7 +1618,7 @@ set_gc_used (pair_p variables) printf ("%s used %d GTY-ed variables\n", progname, nbvars); } -/* File mapping routines. For each input file, there is one output .c file +/* File mapping routines. For each input file, there is one output .cc file (but some output files have many input files), and there is one .h file for the whole build. */ @@ -1949,8 +1949,8 @@ struct file_rule_st { /* File rule action handling *.h files. */ static outf_p header_dot_h_frul (input_file*, char**, char**); -/* File rule action handling *.c files. */ -static outf_p source_dot_c_frul (input_file*, char**, char**); +/* File rule action handling *.cc files. */ +static outf_p source_dot_cc_frul (input_file*, char**, char**); #define NULL_REGEX (regex_t*)0 @@ -1970,9 +1970,9 @@ struct file_rule_st files_rules[] = { but are not shared. */ /* the c-family/ source directory is special. */ - { DIR_PREFIX_REGEX "c-family/([[:alnum:]_-]*)\\.c$", + { DIR_PREFIX_REGEX "c-family/([[:alnum:]_-]*)\\.cc$", REG_EXTENDED, NULL_REGEX, - "gt-c-family-$3.h", "c-family/$3.c", NULL_FRULACT}, + "gt-c-family-$3.h", "c-family/$3.cc", NULL_FRULACT}, { DIR_PREFIX_REGEX "c-family/([[:alnum:]_-]*)\\.h$", REG_EXTENDED, NULL_REGEX, @@ -2015,20 +2015,14 @@ struct file_rule_st files_rules[] = { REG_EXTENDED, NULL_REGEX, "gt-objc-objc-map.h", "objc/objc-map.cc", NULL_FRULACT }, - /* General cases. For header *.h and source *.c or *.cc files, we + /* General cases. For header *.h and *.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. */ + through the source_dot_cc_frul action. */ { DIR_PREFIX_REGEX "([[:alnum:]_-]*)\\.cc$", - REG_EXTENDED, NULL_REGEX, "gt-$3.h", "$3.cc", source_dot_c_frul}, + REG_EXTENDED, NULL_REGEX, "gt-$3.h", "$3.cc", source_dot_cc_frul}, /* Common header files get "gtype-desc.cc" as their output_name, * while language specific header files are handled specially. So @@ -2083,13 +2077,13 @@ header_dot_h_frul (input_file* inpf, char**poutname, } -/* Special file rules action for handling *.c source files using +/* Special file rules action for handling *.cc source files using * get_file_gtfilename to compute their output_name and * get_file_basename to compute their for_name. The output_name is * gt-<LANG>-<BASE>.h for language specific source files, and * gt-<BASE>.h for common source files. */ static outf_p -source_dot_c_frul (input_file* inpf, char**poutname, char**pforname) +source_dot_cc_frul (input_file* inpf, char**poutname, char**pforname) { char *newbasename = CONST_CAST (char*, get_file_basename (inpf)); char *newoutname = CONST_CAST (char*, get_file_gtfilename (inpf)); @@ -2371,8 +2365,8 @@ close_output_files (void) { FILE *newfile = NULL; char *backupname = NULL; - /* Back up the old version of the output file gt-FOO.c as - BACKUPDIR/gt-FOO.c~ if we have a backup directory. */ + /* Back up the old version of the output file gt-FOO.cc as + BACKUPDIR/gt-FOO.cc~ if we have a backup directory. */ if (backup_dir) { backupname = concat (backup_dir, "/", diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c index dcd77f7aae5..7e52c5676e5 100644 --- a/libgcc/libgcov-driver.c +++ b/libgcc/libgcov-driver.c @@ -79,7 +79,7 @@ static int gcov_error (const char *, ...); static void gcov_error_exit (void); #endif -#include "gcov-io.c" +#include "gcov-io.cc" #define GCOV_PROF_PREFIX "libgcov profiling error:%s:" -- 2.34.1