Mass rename of C++ .c files to .cc suffix
Commit Message
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
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.
Thoughts?
Martin
[1] https://github.com/marxin/script-misc/blob/master/gcc-renaming-candidates.py
[2] https://github.com/marxin/script-misc/blob/master/rename-gcc.py
Comments
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(-)
@@ -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 \
@@ -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))); \
@@ -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
@@ -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
@@ -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"
@@ -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
@@ -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"
@@ -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, "/",
@@ -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