public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Mass rename of C++ .c files to .cc suffix?
@ 2022-01-07 10:25 Martin Jambor
  2022-01-07 10:33 ` Richard Sandiford
                   ` (6 more replies)
  0 siblings, 7 replies; 43+ messages in thread
From: Martin Jambor @ 2022-01-07 10:25 UTC (permalink / raw)
  To: GCC Mailing List

Hi,

Would anyone be terribly against mass renaming all *.c files (that are
actually C++ files) within the gcc subdirectory to ones with .cc suffix?

We already have 47 files with suffix .cc directly in the gcc
subdirectory and 160 if we also count those in (non-testsuite)
subdirectories, while the majority of our non-header C++ files still has
the .c suffix.

I have already missed stuff when grepping because I did not include *.cc
files and the inconsistency is also just ugly and must be very confusing
to anyone who encounters it for the first time.

Since we have switched to git, this should have quite small effect on
anyone who does their development on branches.  With Martin Liška we did
a few experiments and git blame, git rebase and even git gcc-backport
worked seamlessly across a rename.

I would be fine waiting with it until GCC 12 gets released but see
little value in doing so.

What do others think?  (Any important caveats I might have missed?)

Martin

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Mass rename of C++ .c files to .cc suffix?
  2022-01-07 10:25 Mass rename of C++ .c files to .cc suffix? Martin Jambor
@ 2022-01-07 10:33 ` Richard Sandiford
  2022-01-07 10:44   ` Andrew Pinski
  2022-01-07 10:51 ` Jonathan Wakely
                   ` (5 subsequent siblings)
  6 siblings, 1 reply; 43+ messages in thread
From: Richard Sandiford @ 2022-01-07 10:33 UTC (permalink / raw)
  To: Martin Jambor; +Cc: GCC Mailing List

Martin Jambor <mjambor@suse.cz> writes:
> Hi,
>
> Would anyone be terribly against mass renaming all *.c files (that are
> actually C++ files) within the gcc subdirectory to ones with .cc suffix?
>
> We already have 47 files with suffix .cc directly in the gcc
> subdirectory and 160 if we also count those in (non-testsuite)
> subdirectories, while the majority of our non-header C++ files still has
> the .c suffix.
>
> I have already missed stuff when grepping because I did not include *.cc
> files and the inconsistency is also just ugly and must be very confusing
> to anyone who encounters it for the first time.
>
> Since we have switched to git, this should have quite small effect on
> anyone who does their development on branches.  With Martin Liška we did
> a few experiments and git blame, git rebase and even git gcc-backport
> worked seamlessly across a rename.
>
> I would be fine waiting with it until GCC 12 gets released but see
> little value in doing so.
>
> What do others think?  (Any important caveats I might have missed?)

+1 in favour FWIW.  And I agree we might as well do it now.  It seems
likely to be less disruptive than waiting to GCC 12, since at that point
there's going to be more bug fixes that need to be applied to both trunk
and the new branch, as well as the unleashed stage 1 patches.

Thanks,
Richard

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Mass rename of C++ .c files to .cc suffix?
  2022-01-07 10:33 ` Richard Sandiford
@ 2022-01-07 10:44   ` Andrew Pinski
  0 siblings, 0 replies; 43+ messages in thread
From: Andrew Pinski @ 2022-01-07 10:44 UTC (permalink / raw)
  To: Richard Sandiford, Martin Jambor, GCC Mailing List

On Fri, Jan 7, 2022 at 2:35 AM Richard Sandiford via Gcc
<gcc@gcc.gnu.org> wrote:
>
> Martin Jambor <mjambor@suse.cz> writes:
> > Hi,
> >
> > Would anyone be terribly against mass renaming all *.c files (that are
> > actually C++ files) within the gcc subdirectory to ones with .cc suffix?
> >
> > We already have 47 files with suffix .cc directly in the gcc
> > subdirectory and 160 if we also count those in (non-testsuite)
> > subdirectories, while the majority of our non-header C++ files still has
> > the .c suffix.
> >
> > I have already missed stuff when grepping because I did not include *.cc
> > files and the inconsistency is also just ugly and must be very confusing
> > to anyone who encounters it for the first time.
> >
> > Since we have switched to git, this should have quite small effect on
> > anyone who does their development on branches.  With Martin Liška we did
> > a few experiments and git blame, git rebase and even git gcc-backport
> > worked seamlessly across a rename.
> >
> > I would be fine waiting with it until GCC 12 gets released but see
> > little value in doing so.
> >
> > What do others think?  (Any important caveats I might have missed?)
>
> +1 in favour FWIW.  And I agree we might as well do it now.  It seems
> likely to be less disruptive than waiting to GCC 12, since at that point
> there's going to be more bug fixes that need to be applied to both trunk
> and the new branch, as well as the unleashed stage 1 patches.

+1 in favor. (I don't mind it either time really).
I also think the generated files that get built in the build directory
should also be moved but that is more depth patch.

Thanks,
Andrew Pinski


>
> Thanks,
> Richard

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Mass rename of C++ .c files to .cc suffix?
  2022-01-07 10:25 Mass rename of C++ .c files to .cc suffix? Martin Jambor
  2022-01-07 10:33 ` Richard Sandiford
@ 2022-01-07 10:51 ` Jonathan Wakely
  2022-01-07 10:51 ` Jakub Jelinek
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 43+ messages in thread
From: Jonathan Wakely @ 2022-01-07 10:51 UTC (permalink / raw)
  To: Martin Jambor; +Cc: GCC Mailing List

On Fri, 7 Jan 2022 at 10:26, Martin Jambor wrote:
> I have already missed stuff when grepping because I did not include *.cc
> files and the inconsistency is also just ugly and must be very confusing
> to anyone who encounters it for the first time.

Yes, and it affects tooling like syntax highlighting and indenting
rules in editors. I think that's one of the strongest arguments in
favour of renaming them.

Apart from that, I don't have any strong opinion either way (libstdc++
has always used .cc and I rarely touch the rest of the compiler).

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Mass rename of C++ .c files to .cc suffix?
  2022-01-07 10:25 Mass rename of C++ .c files to .cc suffix? Martin Jambor
  2022-01-07 10:33 ` Richard Sandiford
  2022-01-07 10:51 ` Jonathan Wakely
@ 2022-01-07 10:51 ` Jakub Jelinek
  2022-01-07 11:05   ` Jonathan Wakely
  2022-01-07 14:49 ` Jeff Law
                   ` (3 subsequent siblings)
  6 siblings, 1 reply; 43+ messages in thread
From: Jakub Jelinek @ 2022-01-07 10:51 UTC (permalink / raw)
  To: Martin Jambor; +Cc: GCC Mailing List

On Fri, Jan 07, 2022 at 11:25:50AM +0100, Martin Jambor wrote:
> Would anyone be terribly against mass renaming all *.c files (that are
> actually C++ files) within the gcc subdirectory to ones with .cc suffix?
> 
> We already have 47 files with suffix .cc directly in the gcc
> subdirectory and 160 if we also count those in (non-testsuite)
> subdirectories, while the majority of our non-header C++ files still has
> the .c suffix.
> 
> I have already missed stuff when grepping because I did not include *.cc
> files and the inconsistency is also just ugly and must be very confusing
> to anyone who encounters it for the first time.
> 
> Since we have switched to git, this should have quite small effect on
> anyone who does their development on branches.  With Martin Liška we did
> a few experiments and git blame, git rebase and even git gcc-backport
> worked seamlessly across a rename.
> 
> I would be fine waiting with it until GCC 12 gets released but see
> little value in doing so.
> 
> What do others think?  (Any important caveats I might have missed?)

My big worry would be backporting for the next 2 years.
Do we need to adjust commit messages when backporting to replace *.cc with
*.c in there?  Does git cherry-pick handle the changed files or do we
need to resolve conflicts manually?

	Jakub


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Mass rename of C++ .c files to .cc suffix?
  2022-01-07 10:51 ` Jakub Jelinek
@ 2022-01-07 11:05   ` Jonathan Wakely
  2022-01-07 12:55     ` Martin Liška
  0 siblings, 1 reply; 43+ messages in thread
From: Jonathan Wakely @ 2022-01-07 11:05 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Martin Jambor, GCC Mailing List

On Fri, 7 Jan 2022 at 10:54, Jakub Jelinek via Gcc <gcc@gcc.gnu.org> wrote:
> My big worry would be backporting for the next 2 years.
> Do we need to adjust commit messages when backporting to replace *.cc with
> *.c in there?  Does git cherry-pick handle the changed files or do we
> need to resolve conflicts manually?

git cherry-pick (and the gcc-backport alias) should handle it
automatically, unless the diffs between trunk and the branch are a
large percentage of the whole file. IOf a file has been renamed then
Git finds the file to apply the patch to by comparing file contents
fuzzily. For a large repo like GCC you might want to set the
merge.renameLimit config variable so that it doesn't give up trying to
find the file too early. I did 'git config merge.renameLimit 9001' in
my repos. You can also set it to 0 which uses a hardcoded maximum
decided by Git, which gets updated now and then to ensure it works for
the kernel. That maps to a value much larger than 9000, but I've found
that my GCC cherry picks work with 9001.

References to .cc files in the commit message won't get changed to .c
automatically, but maybe the gcc-backport alias could be taught to do
that.

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Mass rename of C++ .c files to .cc suffix?
  2022-01-07 11:05   ` Jonathan Wakely
@ 2022-01-07 12:55     ` Martin Liška
  2022-01-07 14:42       ` Iain Sandoe
  0 siblings, 1 reply; 43+ messages in thread
From: Martin Liška @ 2022-01-07 12:55 UTC (permalink / raw)
  To: Jonathan Wakely, Jakub Jelinek; +Cc: GCC Mailing List

On 1/7/22 12:05, Jonathan Wakely via Gcc wrote:
> References to .cc files in the commit message won't get changed to .c
> automatically, but maybe the gcc-backport alias could be taught to do
> that.

Hi.

+1 for me. I'm willing to extend gcc-backport script to support renaming
files in the commit messages.

Cheers,
Martin

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Mass rename of C++ .c files to .cc suffix?
  2022-01-07 12:55     ` Martin Liška
@ 2022-01-07 14:42       ` Iain Sandoe
  0 siblings, 0 replies; 43+ messages in thread
From: Iain Sandoe @ 2022-01-07 14:42 UTC (permalink / raw)
  To: Martin Liska; +Cc: Jonathan Wakely, Jakub Jelinek, GCC Mailing List



> On 7 Jan 2022, at 12:55, Martin Liška <mliska@suse.cz> wrote:
> 
> On 1/7/22 12:05, Jonathan Wakely via Gcc wrote:
>> References to .cc files in the commit message won't get changed to .c
>> automatically, but maybe the gcc-backport alias could be taught to do
>> that.

> +1 for me. I'm willing to extend gcc-backport script to support renaming
> files in the commit messages

+1 for me if the backport workflow is confirmed to be OK (I mainly cherry-
pick manually, so accept i might need to edit the commit-log, or learn to use
the script ;) ).

Iain



^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Mass rename of C++ .c files to .cc suffix?
  2022-01-07 10:25 Mass rename of C++ .c files to .cc suffix? Martin Jambor
                   ` (2 preceding siblings ...)
  2022-01-07 10:51 ` Jakub Jelinek
@ 2022-01-07 14:49 ` Jeff Law
  2022-01-07 15:45   ` Jeff Law
  2022-01-07 15:59 ` David Malcolm
                   ` (2 subsequent siblings)
  6 siblings, 1 reply; 43+ messages in thread
From: Jeff Law @ 2022-01-07 14:49 UTC (permalink / raw)
  To: Martin Jambor, GCC Mailing List



On 1/7/2022 3:25 AM, Martin Jambor wrote:
> Hi,
>
> Would anyone be terribly against mass renaming all *.c files (that are
> actually C++ files) within the gcc subdirectory to ones with .cc suffix?
>
> We already have 47 files with suffix .cc directly in the gcc
> subdirectory and 160 if we also count those in (non-testsuite)
> subdirectories, while the majority of our non-header C++ files still has
> the .c suffix.
>
> I have already missed stuff when grepping because I did not include *.cc
> files and the inconsistency is also just ugly and must be very confusing
> to anyone who encounters it for the first time.
>
> Since we have switched to git, this should have quite small effect on
> anyone who does their development on branches.  With Martin Liška we did
> a few experiments and git blame, git rebase and even git gcc-backport
> worked seamlessly across a rename.
>
> I would be fine waiting with it until GCC 12 gets released but see
> little value in doing so.
>
> What do others think?  (Any important caveats I might have missed?)
I think it's well past time we do this.   There may be a bit of pain 
with cherry-picking across the rename point, but we should just deal 
with it.

jeff

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Mass rename of C++ .c files to .cc suffix?
  2022-01-07 14:49 ` Jeff Law
@ 2022-01-07 15:45   ` Jeff Law
  0 siblings, 0 replies; 43+ messages in thread
From: Jeff Law @ 2022-01-07 15:45 UTC (permalink / raw)
  To: Martin Jambor, GCC Mailing List



On 1/7/2022 7:49 AM, Jeff Law wrote:
>
>
> On 1/7/2022 3:25 AM, Martin Jambor wrote:
>> Hi,
>>
>> Would anyone be terribly against mass renaming all *.c files (that are
>> actually C++ files) within the gcc subdirectory to ones with .cc suffix?
>>
>> We already have 47 files with suffix .cc directly in the gcc
>> subdirectory and 160 if we also count those in (non-testsuite)
>> subdirectories, while the majority of our non-header C++ files still has
>> the .c suffix.
>>
>> I have already missed stuff when grepping because I did not include *.cc
>> files and the inconsistency is also just ugly and must be very confusing
>> to anyone who encounters it for the first time.
>>
>> Since we have switched to git, this should have quite small effect on
>> anyone who does their development on branches.  With Martin Liška we did
>> a few experiments and git blame, git rebase and even git gcc-backport
>> worked seamlessly across a rename.
>>
>> I would be fine waiting with it until GCC 12 gets released but see
>> little value in doing so.
>>
>> What do others think?  (Any important caveats I might have missed?)
> I think it's well past time we do this.   There may be a bit of pain 
> with cherry-picking across the rename point, but we should just deal 
> with it.
  I realized this might be mis-interpreted.  The "well past time" was 
really meant to signal that I think we probably should have made this 
change long ago and that waiting even longer just doesn't make sense to me.

I'm fully in favor and have no objections to making it now.  I wouldn't 
be terribly surprised if it's less intrusive to make now rather than 
after gcc-12 is released.  Making it now affects trunk->gcc11 and 
earlier backports which should be smaller than trunk->gcc-12 backports 
we'd be making in the summer/fall if we were to defer until after gcc-12.

jeff

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Mass rename of C++ .c files to .cc suffix?
  2022-01-07 10:25 Mass rename of C++ .c files to .cc suffix? Martin Jambor
                   ` (3 preceding siblings ...)
  2022-01-07 14:49 ` Jeff Law
@ 2022-01-07 15:59 ` David Malcolm
  2022-01-07 17:31   ` Jonathan Wakely
  2022-01-10  9:11   ` Martin Liška
  2022-01-07 18:33 ` Alexandre Oliva
  2022-01-11 12:56 ` [PATCH] Mass rename of C++ .c files to .cc suffix Martin Liška
  6 siblings, 2 replies; 43+ messages in thread
From: David Malcolm @ 2022-01-07 15:59 UTC (permalink / raw)
  To: Martin Jambor, GCC Mailing List

On Fri, 2022-01-07 at 11:25 +0100, Martin Jambor wrote:
> Hi,
> 
> Would anyone be terribly against mass renaming all *.c files (that are
> actually C++ files) within the gcc subdirectory to ones with .cc
> suffix?
> 
> We already have 47 files with suffix .cc directly in the gcc
> subdirectory and 160 if we also count those in (non-testsuite)
> subdirectories, while the majority of our non-header C++ files still
> has
> the .c suffix.
> 
> I have already missed stuff when grepping because I did not include
> *.cc
> files and the inconsistency is also just ugly and must be very
> confusing
> to anyone who encounters it for the first time.
> 
> Since we have switched to git, this should have quite small effect on
> anyone who does their development on branches.  With Martin Liška we
> did
> a few experiments and git blame, git rebase and even git gcc-backport
> worked seamlessly across a rename.
> 
> I would be fine waiting with it until GCC 12 gets released but see
> little value in doing so.
> 
> What do others think?  (Any important caveats I might have missed?)

+1 from me.

Various details:

Presumably the generated files should also change from .c to .cc (e.g.
gengtype generates a gtype-desc.c which is actually C++).

grep for "files_rules" in gengtype: it seems to have some hardcoded
regex patterns that end in "\\.c" (not sure what these do, but should
be investigated w.r.t. a renaming to .cc)

A minor detail that would be nice to get right: the selftests manually
code the names of source files in function names; see
selftest::run_tests in selftest-run-tests.c, which has lots of calls to
functions of the form "foo_c_tests ();"  These function names should
probably be renamed to "foo_cc_tests" if "foo.c" is renamed to
"foo.cc".  Though perhaps that can wait to a followup, or be a separate
commit, if that helps with backporting.

Hope this is constructive
Dave



^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Mass rename of C++ .c files to .cc suffix?
  2022-01-07 15:59 ` David Malcolm
@ 2022-01-07 17:31   ` Jonathan Wakely
  2022-01-10  9:11   ` Martin Liška
  1 sibling, 0 replies; 43+ messages in thread
From: Jonathan Wakely @ 2022-01-07 17:31 UTC (permalink / raw)
  To: David Malcolm; +Cc: Martin Jambor, GCC Mailing List

On Fri, 7 Jan 2022 at 16:00, David Malcolm wrote:
> Presumably the generated files should also change from .c to .cc (e.g.
> gengtype generates a gtype-desc.c which is actually C++).

We could do that separately (and right away), couldn't we? That could
even have been done back in the subversion days, no?

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Mass rename of C++ .c files to .cc suffix?
  2022-01-07 10:25 Mass rename of C++ .c files to .cc suffix? Martin Jambor
                   ` (4 preceding siblings ...)
  2022-01-07 15:59 ` David Malcolm
@ 2022-01-07 18:33 ` Alexandre Oliva
  2022-01-07 19:01   ` Jakub Jelinek
  2022-01-11 12:56 ` [PATCH] Mass rename of C++ .c files to .cc suffix Martin Liška
  6 siblings, 1 reply; 43+ messages in thread
From: Alexandre Oliva @ 2022-01-07 18:33 UTC (permalink / raw)
  To: Martin Jambor; +Cc: GCC Mailing List

On Jan  7, 2022, Martin Jambor <mjambor@suse.cz> wrote:

> Would anyone be terribly against mass renaming all *.c files (that are
> actually C++ files) within the gcc subdirectory to ones with .cc suffix?

I wouldn't mind that.

> (Any important caveats I might have missed?)

Having recently renamed a .c source to .cc in a development branch, one
annoying issue that came up was that dependency tracking in build trees
couldn't recover from the renaming on its own: it kept on insisting that
the previously-existing .c file was missing, instead of picking up the
.cc.  This could be a problem for hands-off CI testers, besides the
slight annoyance of having to wipe out the build tree, or at least hunt
down and remove dep-tracking files.

It's no biggie, I'm not sure there's some change to the build machinery
we could make ahead of time to alleviate this, but it should probably be
mentioned in the announcement of the change if/when it goes in.

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Mass rename of C++ .c files to .cc suffix?
  2022-01-07 18:33 ` Alexandre Oliva
@ 2022-01-07 19:01   ` Jakub Jelinek
  0 siblings, 0 replies; 43+ messages in thread
From: Jakub Jelinek @ 2022-01-07 19:01 UTC (permalink / raw)
  To: Alexandre Oliva; +Cc: Martin Jambor, GCC Mailing List

On Fri, Jan 07, 2022 at 03:33:54PM -0300, Alexandre Oliva via Gcc wrote:
> On Jan  7, 2022, Martin Jambor <mjambor@suse.cz> wrote:
> 
> > Would anyone be terribly against mass renaming all *.c files (that are
> > actually C++ files) within the gcc subdirectory to ones with .cc suffix?
> 
> I wouldn't mind that.
> 
> > (Any important caveats I might have missed?)
> 
> Having recently renamed a .c source to .cc in a development branch, one
> annoying issue that came up was that dependency tracking in build trees
> couldn't recover from the renaming on its own: it kept on insisting that
> the previously-existing .c file was missing, instead of picking up the
> .cc.  This could be a problem for hands-off CI testers, besides the
> slight annoyance of having to wipe out the build tree, or at least hunt
> down and remove dep-tracking files.
> 
> It's no biggie, I'm not sure there's some change to the build machinery
> we could make ahead of time to alleviate this, but it should probably be
> mentioned in the announcement of the change if/when it goes in.

So it will be something to work around in bisection scripts (though sure,
over the years we have various quirks in there), e.g. in the svn era I have
if [ $rev -gt 202892 ]; then [ ! -f .deps/toplev.Po ] && rm -f `ls -1 *.o */*.o | grep -v 'crt.*o'`; else [ -d .deps ] && rm -rf .deps */.deps; fi

	Jakub


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: Mass rename of C++ .c files to .cc suffix?
  2022-01-07 15:59 ` David Malcolm
  2022-01-07 17:31   ` Jonathan Wakely
@ 2022-01-10  9:11   ` Martin Liška
  1 sibling, 0 replies; 43+ messages in thread
From: Martin Liška @ 2022-01-10  9:11 UTC (permalink / raw)
  To: David Malcolm, Martin Jambor, GCC Mailing List

[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]

On 1/7/22 16:59, David Malcolm via Gcc wrote:
> On Fri, 2022-01-07 at 11:25 +0100, Martin Jambor wrote:
>> Hi,
>>
>> Would anyone be terribly against mass renaming all *.c files (that are
>> actually C++ files) within the gcc subdirectory to ones with .cc
>> suffix?
>>
>> We already have 47 files with suffix .cc directly in the gcc
>> subdirectory and 160 if we also count those in (non-testsuite)
>> subdirectories, while the majority of our non-header C++ files still
>> has
>> the .c suffix.
>>
>> I have already missed stuff when grepping because I did not include
>> *.cc
>> files and the inconsistency is also just ugly and must be very
>> confusing
>> to anyone who encounters it for the first time.
>>
>> Since we have switched to git, this should have quite small effect on
>> anyone who does their development on branches.  With Martin Liška we
>> did
>> a few experiments and git blame, git rebase and even git gcc-backport
>> worked seamlessly across a rename.
>>
>> I would be fine waiting with it until GCC 12 gets released but see
>> little value in doing so.
>>
>> What do others think?  (Any important caveats I might have missed?)
> 
> +1 from me.
> 
> Various details:
> 
> Presumably the generated files should also change from .c to .cc (e.g.
> gengtype generates a gtype-desc.c which is actually C++).

Exactly. I'm willing to work on the transition.

I started with a replacement script that takes all *.c files in gcc/ subfolder
(excluding testsuite) and I made re.sub('\b${filename}\b', '${filename}c')
for all these files. It's quite surprising how many occurrences do we have
in comments (please see preliminary patch).

Martin

> 
> grep for "files_rules" in gengtype: it seems to have some hardcoded
> regex patterns that end in "\\.c" (not sure what these do, but should
> be investigated w.r.t. a renaming to .cc)
> 
> A minor detail that would be nice to get right: the selftests manually
> code the names of source files in function names; see
> selftest::run_tests in selftest-run-tests.c, which has lots of calls to
> functions of the form "foo_c_tests ();"  These function names should
> probably be renamed to "foo_cc_tests" if "foo.c" is renamed to
> "foo.cc".  Though perhaps that can wait to a followup, or be a separate
> commit, if that helps with backporting.
> 
> Hope this is constructive
> Dave
> 
> 

[-- Attachment #2: 0001-Renaming.patch.zst --]
[-- Type: application/zstd, Size: 199546 bytes --]

^ permalink raw reply	[flat|nested] 43+ messages in thread

* [PATCH] Mass rename of C++ .c files to .cc suffix
  2022-01-07 10:25 Mass rename of C++ .c files to .cc suffix? Martin Jambor
                   ` (5 preceding siblings ...)
  2022-01-07 18:33 ` Alexandre Oliva
@ 2022-01-11 12:56 ` Martin Liška
  2022-01-11 15:48   ` Toon Moene
  6 siblings, 1 reply; 43+ messages in thread
From: Martin Liška @ 2022-01-11 12:56 UTC (permalink / raw)
  To: Martin Jambor, GCC Mailing List; +Cc: GCC Patches

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

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

[-- Attachment #2: 0003-Manual-changes-for-.cc-renaming.patch --]
[-- Type: text/x-patch, Size: 20616 bytes --]

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);
 }
 \f
-/* 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


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] Mass rename of C++ .c files to .cc suffix
  2022-01-11 12:56 ` [PATCH] Mass rename of C++ .c files to .cc suffix Martin Liška
@ 2022-01-11 15:48   ` Toon Moene
  2022-01-11 15:50     ` Martin Liška
  2022-01-13 11:01     ` [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ Martin Liška
  0 siblings, 2 replies; 43+ messages in thread
From: Toon Moene @ 2022-01-11 15:48 UTC (permalink / raw)
  To: Martin Liška, Martin Jambor, GCC Mailing List; +Cc: GCC Patches

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,

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] Mass rename of C++ .c files to .cc suffix
  2022-01-11 15:48   ` Toon Moene
@ 2022-01-11 15:50     ` Martin Liška
  2022-01-11 15:56       ` Jakub Jelinek
  2022-01-11 18:00       ` [PATCH] Mass rename of C++ .c files to .cc suffix Harald Anlauf
  2022-01-13 11:01     ` [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ Martin Liška
  1 sibling, 2 replies; 43+ messages in thread
From: Martin Liška @ 2022-01-11 15:50 UTC (permalink / raw)
  To: Toon Moene, Martin Jambor, GCC Mailing List; +Cc: GCC Patches, gfortran

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,
> 


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] Mass rename of C++ .c files to .cc suffix
  2022-01-11 15:50     ` Martin Liška
@ 2022-01-11 15:56       ` Jakub Jelinek
  2022-01-11 16:03         ` Martin Liška
  2022-01-11 18:00       ` [PATCH] Mass rename of C++ .c files to .cc suffix Harald Anlauf
  1 sibling, 1 reply; 43+ messages in thread
From: Jakub Jelinek @ 2022-01-11 15:56 UTC (permalink / raw)
  To: Martin Liška
  Cc: Toon Moene, Martin Jambor, GCC Mailing List, GCC Patches, gfortran

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


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] Mass rename of C++ .c files to .cc suffix
  2022-01-11 15:56       ` Jakub Jelinek
@ 2022-01-11 16:03         ` Martin Liška
  2022-01-11 16:16           ` Jakub Jelinek
  0 siblings, 1 reply; 43+ messages in thread
From: Martin Liška @ 2022-01-11 16:03 UTC (permalink / raw)
  To: Jakub Jelinek
  Cc: Toon Moene, Martin Jambor, GCC Mailing List, GCC Patches, gfortran

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] Mass rename of C++ .c files to .cc suffix
  2022-01-11 16:03         ` Martin Liška
@ 2022-01-11 16:16           ` Jakub Jelinek
  2022-01-12  8:58             ` Martin Liška
  0 siblings, 1 reply; 43+ messages in thread
From: Jakub Jelinek @ 2022-01-11 16:16 UTC (permalink / raw)
  To: Martin Liška
  Cc: Toon Moene, Martin Jambor, GCC Mailing List, GCC Patches, gfortran

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


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] Mass rename of C++ .c files to .cc suffix
  2022-01-11 15:50     ` Martin Liška
  2022-01-11 15:56       ` Jakub Jelinek
@ 2022-01-11 18:00       ` Harald Anlauf
  2022-01-11 18:00         ` Harald Anlauf
  2022-01-11 18:23         ` Jonathan Wakely
  1 sibling, 2 replies; 43+ messages in thread
From: Harald Anlauf @ 2022-01-11 18:00 UTC (permalink / raw)
  To: Martin Liška, Toon Moene, Martin Jambor, GCC Mailing List
  Cc: GCC Patches, gfortran

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,
>>
>
>


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] Mass rename of C++ .c files to .cc suffix
  2022-01-11 18:00       ` [PATCH] Mass rename of C++ .c files to .cc suffix Harald Anlauf
@ 2022-01-11 18:00         ` Harald Anlauf
  2022-01-11 18:23         ` Jonathan Wakely
  1 sibling, 0 replies; 43+ messages in thread
From: Harald Anlauf @ 2022-01-11 18:00 UTC (permalink / raw)
  To: gcc; +Cc: fortran, gcc-patches, gcc, gcc-patches

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,
>>
> 
> 



^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] Mass rename of C++ .c files to .cc suffix
  2022-01-11 18:00       ` [PATCH] Mass rename of C++ .c files to .cc suffix Harald Anlauf
  2022-01-11 18:00         ` Harald Anlauf
@ 2022-01-11 18:23         ` Jonathan Wakely
  2022-01-11 18:36           ` Jakub Jelinek
  1 sibling, 1 reply; 43+ messages in thread
From: Jonathan Wakely @ 2022-01-11 18:23 UTC (permalink / raw)
  To: Harald Anlauf
  Cc: Martin Liška, Toon Moene, Martin Jambor, GCC Mailing List,
	GCC Patches, gfortran

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.

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] Mass rename of C++ .c files to .cc suffix
  2022-01-11 18:23         ` Jonathan Wakely
@ 2022-01-11 18:36           ` Jakub Jelinek
  0 siblings, 0 replies; 43+ messages in thread
From: Jakub Jelinek @ 2022-01-11 18:36 UTC (permalink / raw)
  To: Jonathan Wakely; +Cc: Harald Anlauf, GCC Mailing List, gfortran, GCC Patches

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


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] Mass rename of C++ .c files to .cc suffix
  2022-01-11 16:16           ` Jakub Jelinek
@ 2022-01-12  8:58             ` Martin Liška
  2022-01-12 15:54               ` [PATCH] git-backport: support renamed .cc files in commit message Martin Liška
  0 siblings, 1 reply; 43+ messages in thread
From: Martin Liška @ 2022-01-12  8:58 UTC (permalink / raw)
  To: Jakub Jelinek
  Cc: Toon Moene, Martin Jambor, GCC Mailing List, GCC Patches, gfortran

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
> 


^ permalink raw reply	[flat|nested] 43+ messages in thread

* [PATCH] git-backport: support renamed .cc files in commit message.
  2022-01-12  8:58             ` Martin Liška
@ 2022-01-12 15:54               ` Martin Liška
  2022-01-14  7:44                 ` Bernhard Reutner-Fischer
  2022-01-17 21:26                 ` Martin Liška
  0 siblings, 2 replies; 43+ messages in thread
From: Martin Liška @ 2022-01-12 15:54 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: GCC Mailing List, Martin Jambor, GCC Patches, gfortran

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

Hi.

There's a patch that enhances git-backport so that it updates commit
messages for files which name ends now with .cc and is still .c on a branch.

Example usage:

$ git show test
commit 8ed4b2cb9aa158c0ef418fd1ac66271664904604 (test)
Author: Martin Liska <mliska@suse.cz>
Date:   Wed Jan 12 16:08:13 2022 +0100

     Fix file.
     
     gcc/ChangeLog:
     
             * ipa-icf.cc: Test me.
     
     gcc/ada/ChangeLog:
     
             * cal.c: aaa.
     
     libcpp/ChangeLog:
     
             * expr.cc: aaa.

$ git gcc-backport test
Auto-merging gcc/ada/cal.c
Auto-merging gcc/ipa-icf.c
Auto-merging libcpp/expr.c
[test2 ee40feb077e] Fix file.
  Date: Wed Jan 12 16:08:13 2022 +0100
  3 files changed, 3 insertions(+)
Commit message updated: 2 .cc file(s) changed.

$ git show test2
commit f59a1e736c1b68f07d83388a994df8d043e8aa6e (test2)
Author: Martin Liska <mliska@suse.cz>
Date:   Wed Jan 12 16:08:13 2022 +0100

     Fix file.
     
     gcc/ChangeLog:
     
             * ipa-icf.c: Test me.
     
     gcc/ada/ChangeLog:
     
             * cal.c: aaa.
     
     libcpp/ChangeLog:
     
             * expr.c: aaa.
     
     (cherry picked from commit 8ed4b2cb9aa158c0ef418fd1ac66271664904604)

Martin

[-- Attachment #2: 0001-git-backport-support-renamed-.cc-files-in-commit-mes.patch --]
[-- Type: text/x-patch, Size: 2987 bytes --]

From 647a6dbaf8cde4ee07b95c4530a03f7774500914 Mon Sep 17 00:00:00 2001
From: Martin Liska <mliska@suse.cz>
Date: Wed, 12 Jan 2022 16:35:41 +0100
Subject: [PATCH] git-backport: support renamed .cc files in commit message.

The change can automatically update names for *.cc files that
are part of a backport.

contrib/ChangeLog:

	* git-backport.py: Support renaming of .cc files.
---
 contrib/git-backport.py | 50 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/contrib/git-backport.py b/contrib/git-backport.py
index 2b8e4686719..627bbd9ee66 100755
--- a/contrib/git-backport.py
+++ b/contrib/git-backport.py
@@ -20,7 +20,32 @@
 # Boston, MA 02110-1301, USA.
 
 import argparse
+import os
 import subprocess
+import sys
+import tempfile
+
+script_folder = os.path.dirname(os.path.abspath(__file__))
+verify_script = os.path.join(script_folder,
+                             'gcc-changelog/git_check_commit.py')
+
+
+def replace_file_in_changelog(lines, filename):
+    if not filename.endswith('.cc'):
+        return
+
+    # consider all componenets of a path: gcc/ipa-icf.cc
+    while filename:
+        for i, line in enumerate(lines):
+            if filename in line:
+                line = line.replace(filename, filename[:-1])
+                lines[i] = line
+                return
+        parts = filename.split('/')
+        if len(parts) == 1:
+            return
+        filename = '/'.join(parts[1:])
+
 
 if __name__ == '__main__':
     parser = argparse.ArgumentParser(description='Backport a git revision and '
@@ -63,3 +88,28 @@ if __name__ == '__main__':
             subprocess.check_output(cmd, shell=True)
         else:
             print('Please resolve all remaining file conflicts.')
+            sys.exit(1)
+
+    # Update commit message if change for a .cc file was taken
+    r = subprocess.run(f'{verify_script} HEAD', shell=True, encoding='utf8',
+                       stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+    if r.returncode != 0:
+        lines = r.stdout.splitlines()
+        cmd = 'git show -s --format=%B'
+        commit_message = subprocess.check_output(cmd, shell=True,
+                                                 encoding='utf8').strip()
+        commit_message = commit_message.splitlines()
+
+        todo = [line for line in lines if 'unchanged file mentioned' in line]
+        for item in todo:
+            filename = item.split()[-1].strip('"')
+            replace_file_in_changelog(commit_message, filename)
+
+        with tempfile.NamedTemporaryFile('w', encoding='utf8',
+                                         delete=False) as w:
+            w.write('\n'.join(commit_message))
+            w.close()
+            subprocess.check_output(f'git commit --amend -F {w.name}',
+                                    shell=True, encoding='utf8')
+            os.unlink(w.name)
+            print(f'Commit message updated: {len(todo)} .cc file(s) changed.')
-- 
2.34.1


^ permalink raw reply	[flat|nested] 43+ messages in thread

* [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ
  2022-01-11 15:48   ` Toon Moene
  2022-01-11 15:50     ` Martin Liška
@ 2022-01-13 11:01     ` Martin Liška
  2022-01-17 21:41       ` Martin Liška
  1 sibling, 1 reply; 43+ messages in thread
From: Martin Liška @ 2022-01-13 11:01 UTC (permalink / raw)
  To: Toon Moene, Martin Jambor, GCC Mailing List; +Cc: GCC Patches, GCC Development

Hello.

Based on the discussion with release managers, the change is going to happen
after stage4 begins.

Martin

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] git-backport: support renamed .cc files in commit message.
  2022-01-12 15:54               ` [PATCH] git-backport: support renamed .cc files in commit message Martin Liška
@ 2022-01-14  7:44                 ` Bernhard Reutner-Fischer
  2022-01-14 15:26                   ` Martin Liška
  2022-01-17 21:26                 ` Martin Liška
  1 sibling, 1 reply; 43+ messages in thread
From: Bernhard Reutner-Fischer @ 2022-01-14  7:44 UTC (permalink / raw)
  To: Martin Liška
  Cc: rep.dot.nop, Jakub Jelinek, GCC Mailing List, Martin Jambor,
	GCC Patches, gfortran

On Wed, 12 Jan 2022 16:54:46 +0100
Martin Liška <mliska@suse.cz> wrote:

> +def replace_file_in_changelog(lines, filename):
> +    if not filename.endswith('.cc'):
> +        return
> +
> +    # consider all componenets of a path: gcc/ipa-icf.cc
> +    while filename:
> +        for i, line in enumerate(lines):
> +            if filename in line:
> +                line = line.replace(filename, filename[:-1])
> +                lines[i] = line
> +                return
> +        parts = filename.split('/')
> +        if len(parts) == 1:
> +            return
> +        filename = '/'.join(parts[1:])
> +

I think you mean os.sep instead of the hardcoded slash.
But i'd use os.path.split and os.path.join

thanks,

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] git-backport: support renamed .cc files in commit message.
  2022-01-14  7:44                 ` Bernhard Reutner-Fischer
@ 2022-01-14 15:26                   ` Martin Liška
  0 siblings, 0 replies; 43+ messages in thread
From: Martin Liška @ 2022-01-14 15:26 UTC (permalink / raw)
  To: Bernhard Reutner-Fischer
  Cc: Jakub Jelinek, GCC Mailing List, Martin Jambor, GCC Patches, gfortran

On 1/14/22 08:44, Bernhard Reutner-Fischer wrote:
> On Wed, 12 Jan 2022 16:54:46 +0100
> Martin Liška <mliska@suse.cz> wrote:
> 
>> +def replace_file_in_changelog(lines, filename):
>> +    if not filename.endswith('.cc'):
>> +        return
>> +
>> +    # consider all componenets of a path: gcc/ipa-icf.cc
>> +    while filename:
>> +        for i, line in enumerate(lines):
>> +            if filename in line:
>> +                line = line.replace(filename, filename[:-1])
>> +                lines[i] = line
>> +                return
>> +        parts = filename.split('/')
>> +        if len(parts) == 1:
>> +            return
>> +        filename = '/'.join(parts[1:])
>> +
> 
> I think you mean os.sep instead of the hardcoded slash.
> But i'd use os.path.split and os.path.join

Hello.

Well, these are all paths from a git commit message. And we require unix-style
of paths for all ChangeLog entries. So it should be correct.

Martin

> 
> thanks,


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] git-backport: support renamed .cc files in commit message.
  2022-01-12 15:54               ` [PATCH] git-backport: support renamed .cc files in commit message Martin Liška
  2022-01-14  7:44                 ` Bernhard Reutner-Fischer
@ 2022-01-17 21:26                 ` Martin Liška
  2022-01-18 19:10                   ` Harald Anlauf
  1 sibling, 1 reply; 43+ messages in thread
From: Martin Liška @ 2022-01-17 21:26 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: GCC Mailing List, GCC Patches, gfortran

On 1/12/22 16:54, Martin Liška wrote:
> 
> There's a patch that enhances git-backport so that it updates commit
> messages for files which name ends now with .cc and is still .c on a branch.

The patch has been installed as I've made the renaming now.

Cheers,
Martin

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ
  2022-01-13 11:01     ` [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ Martin Liška
@ 2022-01-17 21:41       ` Martin Liška
  2022-01-18  8:36         ` Eric Botcazou
  2022-01-18 13:10         ` Richard Earnshaw
  0 siblings, 2 replies; 43+ messages in thread
From: Martin Liška @ 2022-01-17 21:41 UTC (permalink / raw)
  To: Toon Moene, Martin Jambor, GCC Mailing List; +Cc: GCC Patches

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ
  2022-01-17 21:41       ` Martin Liška
@ 2022-01-18  8:36         ` Eric Botcazou
  2022-01-18  8:39           ` Martin Liška
  2022-01-18 13:10         ` Richard Earnshaw
  1 sibling, 1 reply; 43+ messages in thread
From: Eric Botcazou @ 2022-01-18  8:36 UTC (permalink / raw)
  To: Martin Liška
  Cc: Toon Moene, Martin Jambor, GCC Mailing List, gcc-patches, GCC Patches

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.

-- 
Eric Botcazou



^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ
  2022-01-18  8:36         ` Eric Botcazou
@ 2022-01-18  8:39           ` Martin Liška
  2022-01-18  8:46             ` Eric Botcazou
  0 siblings, 1 reply; 43+ messages in thread
From: Martin Liška @ 2022-01-18  8:39 UTC (permalink / raw)
  To: Eric Botcazou; +Cc: Toon Moene, Martin Jambor, GCC Mailing List, gcc-patches

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


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ
  2022-01-18  8:39           ` Martin Liška
@ 2022-01-18  8:46             ` Eric Botcazou
  2022-01-18  8:53               ` Richard Biener
  0 siblings, 1 reply; 43+ messages in thread
From: Eric Botcazou @ 2022-01-18  8:46 UTC (permalink / raw)
  To: Martin Liška
  Cc: Toon Moene, Martin Jambor, GCC Mailing List, gcc-patches

> Release managers.

They certainly have authority on the timing, but not on the contents.

> Working on that right now, sorry..

OK, thanks in advance.

-- 
Eric Botcazou



^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ
  2022-01-18  8:46             ` Eric Botcazou
@ 2022-01-18  8:53               ` Richard Biener
  2022-01-18  9:08                 ` Martin Liška
  0 siblings, 1 reply; 43+ messages in thread
From: Richard Biener @ 2022-01-18  8:53 UTC (permalink / raw)
  To: Eric Botcazou; +Cc: Martin Liška, GCC Mailing List, GCC Patches

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
>
>

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ
  2022-01-18  8:53               ` Richard Biener
@ 2022-01-18  9:08                 ` Martin Liška
  2022-01-18  9:13                   ` Jakub Jelinek
  0 siblings, 1 reply; 43+ messages in thread
From: Martin Liška @ 2022-01-18  9:08 UTC (permalink / raw)
  To: Richard Biener, Eric Botcazou; +Cc: GCC Mailing List, GCC Patches

[-- Attachment #1: Type: text/plain, Size: 742 bytes --]

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

[-- Attachment #2: 0002-Ada-Revert-filename-changes-in-comments.patch --]
[-- Type: text/x-patch, Size: 7946 bytes --]

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/adaint.c                       | 2 +-
 gcc/ada/ctrl_c.c                       | 2 +-
 gcc/ada/gsocket.h                      | 2 +-
 gcc/ada/init.c                         | 2 +-
 gcc/ada/libgnarl/s-intman.ads          | 2 +-
 gcc/ada/libgnarl/s-osinte__android.ads | 2 +-
 gcc/ada/libgnarl/s-osinte__darwin.ads  | 2 +-
 gcc/ada/libgnarl/s-osinte__hpux.ads    | 2 +-
 gcc/ada/libgnarl/s-osinte__linux.ads   | 2 +-
 gcc/ada/libgnarl/s-osinte__qnx.ads     | 2 +-
 gcc/ada/libgnarl/s-taskin.ads          | 2 +-
 gcc/ada/rtfinal.c                      | 2 +-
 12 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
index b7b7d7483dd..591d033fbca 100644
--- a/gcc/ada/adaint.c
+++ b/gcc/ada/adaint.c
@@ -172,7 +172,7 @@ extern "C" {
 
 #include "mingw32.h"
 
-/* Current code page and CCS encoding to use, set in initialize.cc.  */
+/* Current code page and CCS encoding to use, set in initialize.c.  */
 UINT __gnat_current_codepage;
 UINT __gnat_current_ccs_encoding;
 
diff --git a/gcc/ada/ctrl_c.c b/gcc/ada/ctrl_c.c
index b32baa01b3b..eeec3e64f70 100644
--- a/gcc/ada/ctrl_c.c
+++ b/gcc/ada/ctrl_c.c
@@ -61,7 +61,7 @@ void __gnat_uninstall_int_handler (void);
 void
 dummy_handler () {}
 
-/* Lives in init.cc.  */
+/* Lives in init.c.  */
 extern void (*__gnat_ctrl_c_handler) (void);
 #endif
 
diff --git a/gcc/ada/gsocket.h b/gcc/ada/gsocket.h
index aaeca95ba87..e7284a1ef4e 100644
--- a/gcc/ada/gsocket.h
+++ b/gcc/ada/gsocket.h
@@ -246,7 +246,7 @@
  *                     mutual exclusion
  *
  * See "Handling of gethostbyname, gethostbyaddr, getservbyname and
- * getservbyport" in socket.cc for details.
+ * getservbyport" in socket.c for details.
  */
 
 #if defined (HAVE_GETxxxBYyyy_R)
diff --git a/gcc/ada/init.c b/gcc/ada/init.c
index 7ee1977279b..6b6ed5fb058 100644
--- a/gcc/ada/init.c
+++ b/gcc/ada/init.c
@@ -542,7 +542,7 @@ __gnat_error_handler (int sig, siginfo_t *si ATTRIBUTE_UNUSED, void *ucontext)
 	 before the faulting address is accessible.  Unfortunately, Linux
 	 seems to have no way of giving us the faulting address.
 
-	 In old versions of init.cc, we had a test of the page before the
+	 In old versions of init.c, we had a test of the page before the
 	 stack pointer:
 
 	   ((volatile char *)
diff --git a/gcc/ada/libgnarl/s-intman.ads b/gcc/ada/libgnarl/s-intman.ads
index 4d5ab60f68f..aef5a779f75 100644
--- a/gcc/ada/libgnarl/s-intman.ads
+++ b/gcc/ada/libgnarl/s-intman.ads
@@ -105,7 +105,7 @@ private
      (C, Adjust_Context_For_Raise, "__gnat_adjust_context_for_raise");
    --  Target specific hook performing adjustments to the signal's machine
    --  context, to be called before an exception may be raised from a signal
-   --  handler. This service is provided by init.cc, together with the
+   --  handler. This service is provided by init.c, together with the
    --  non-tasking signal handler.
 
 end System.Interrupt_Management;
diff --git a/gcc/ada/libgnarl/s-osinte__android.ads b/gcc/ada/libgnarl/s-osinte__android.ads
index 9ef3e30a2bd..f4434f68b22 100644
--- a/gcc/ada/libgnarl/s-osinte__android.ads
+++ b/gcc/ada/libgnarl/s-osinte__android.ads
@@ -309,7 +309,7 @@ package System.OS_Interface is
    --  The alternate signal stack for stack overflows
 
    Alternate_Stack_Size : constant := 16 * 1024;
-   --  This must be in keeping with init.cc:__gnat_alternate_stack
+   --  This must be in keeping with init.c:__gnat_alternate_stack
 
    Stack_Base_Available : constant Boolean := False;
    --  Indicates whether the stack base is available on this target
diff --git a/gcc/ada/libgnarl/s-osinte__darwin.ads b/gcc/ada/libgnarl/s-osinte__darwin.ads
index 12bb1aad648..1856ce9ee58 100644
--- a/gcc/ada/libgnarl/s-osinte__darwin.ads
+++ b/gcc/ada/libgnarl/s-osinte__darwin.ads
@@ -288,7 +288,7 @@ package System.OS_Interface is
    --  The alternate signal stack for stack overflows
 
    Alternate_Stack_Size : constant := 32 * 1024;
-   --  This must be in keeping with init.cc:__gnat_alternate_stack
+   --  This must be in keeping with init.c:__gnat_alternate_stack
 
    Stack_Base_Available : constant Boolean := False;
    --  Indicates whether the stack base is available on this target. This
diff --git a/gcc/ada/libgnarl/s-osinte__hpux.ads b/gcc/ada/libgnarl/s-osinte__hpux.ads
index a1cf316657d..feaedcc0654 100644
--- a/gcc/ada/libgnarl/s-osinte__hpux.ads
+++ b/gcc/ada/libgnarl/s-osinte__hpux.ads
@@ -293,7 +293,7 @@ package System.OS_Interface is
    --  The alternate signal stack for stack overflows
 
    Alternate_Stack_Size : constant := 128 * 1024;
-   --  This must be in keeping with init.cc:__gnat_alternate_stack
+   --  This must be in keeping with init.c:__gnat_alternate_stack
 
    Stack_Base_Available : constant Boolean := False;
    --  Indicates whether the stack base is available on this target
diff --git a/gcc/ada/libgnarl/s-osinte__linux.ads b/gcc/ada/libgnarl/s-osinte__linux.ads
index 3230f28c38b..7c9e7ca4518 100644
--- a/gcc/ada/libgnarl/s-osinte__linux.ads
+++ b/gcc/ada/libgnarl/s-osinte__linux.ads
@@ -331,7 +331,7 @@ package System.OS_Interface is
    pragma Import (C, sigaltstack, "sigaltstack");
 
    Alternate_Stack_Size : constant := 32 * 1024;
-   --  This must be in keeping with init.cc:__gnat_alternate_stack
+   --  This must be in keeping with init.c:__gnat_alternate_stack
 
    Alternate_Stack : aliased char_array (1 .. Alternate_Stack_Size);
    pragma Import (C, Alternate_Stack, "__gnat_alternate_stack");
diff --git a/gcc/ada/libgnarl/s-osinte__qnx.ads b/gcc/ada/libgnarl/s-osinte__qnx.ads
index af877006d99..c7a887abee2 100644
--- a/gcc/ada/libgnarl/s-osinte__qnx.ads
+++ b/gcc/ada/libgnarl/s-osinte__qnx.ads
@@ -310,7 +310,7 @@ package System.OS_Interface is
    --  sigaltstack in QNX
 
    Alternate_Stack_Size : constant := 0;
-   --  This must be kept in sync with init.cc:__gnat_alternate_stack
+   --  This must be kept in sync with init.c:__gnat_alternate_stack
 
    Stack_Base_Available : constant Boolean := False;
    --  Indicates whether the stack base is available on this target
diff --git a/gcc/ada/libgnarl/s-taskin.ads b/gcc/ada/libgnarl/s-taskin.ads
index c4f42fe1f7e..2e6a0bb3bcf 100644
--- a/gcc/ada/libgnarl/s-taskin.ads
+++ b/gcc/ada/libgnarl/s-taskin.ads
@@ -776,7 +776,7 @@ package System.Tasking is
    Unspecified_Priority : constant Integer := -1;
    --  Indicates that a task has an unspecified priority. This is hardcoded as
    --  -1 rather than System.Priority'First - 1 as the value needs to be used
-   --  in init.cc to specify that the main task has no specified priority.
+   --  in init.c to specify that the main task has no specified priority.
 
    Priority_Not_Boosted : constant Integer := System.Priority'First - 1;
    --  Definition of Priority actually has to come from the RTS configuration
diff --git a/gcc/ada/rtfinal.c b/gcc/ada/rtfinal.c
index ba7c61e7b07..543e3a29f07 100644
--- a/gcc/ada/rtfinal.c
+++ b/gcc/ada/rtfinal.c
@@ -43,7 +43,7 @@ extern void __gnat_runtime_finalize (void);
    Note that __gnat_runtime_finalize() is called in adafinal()   */
 
 extern int __gnat_rt_init_count;
-/*  see initialize.cc  */
+/*  see initialize.c  */
 
 #if defined (__MINGW32__)
 #include "mingw32.h"
-- 
2.34.1


[-- Attachment #3: 0001-Revert-Ada-.cc-renaming-renaming.patch --]
[-- Type: text/x-patch, Size: 17758 bytes --]

From 59ec94ab9246b439ece3cbc3b6504681a702e990 Mon Sep 17 00:00:00 2001
From: Martin Liska <mliska@suse.cz>
Date: Tue, 18 Jan 2022 09:54:35 +0100
Subject: [PATCH 1/2] Revert Ada .cc renaming renaming.

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.
---
 gcc/ada/Make-generated.in                     |  2 +-
 gcc/ada/Makefile.rtl                          |  8 +--
 gcc/ada/{adadecode.cc => adadecode.c}         |  0
 gcc/ada/{affinity.cc => affinity.c}           |  0
 ...en-cert.cc => argv-lynxos178-raven-cert.c} |  0
 gcc/ada/{argv.cc => argv.c}                   |  0
 gcc/ada/{aux-io.cc => aux-io.c}               |  0
 gcc/ada/{cio.cc => cio.c}                     |  0
 gcc/ada/{cstreams.cc => cstreams.c}           |  0
 gcc/ada/{env.cc => env.c}                     |  0
 gcc/ada/{exit.cc => exit.c}                   |  0
 gcc/ada/{expect.cc => expect.c}               |  0
 gcc/ada/{final.cc => final.c}                 |  0
 gcc/ada/gcc-interface/Makefile.in             | 58 +++++++++----------
 gcc/ada/{init.cc => init.c}                   |  0
 gcc/ada/{initialize.cc => initialize.c}       |  0
 gcc/ada/libgnarl/{thread.cc => thread.c}      |  0
 gcc/ada/{link.cc => link.c}                   |  0
 gcc/ada/{locales.cc => locales.c}             |  0
 gcc/ada/{mkdir.cc => mkdir.c}                 |  0
 gcc/ada/{raise.cc => raise.c}                 |  0
 gcc/ada/{rtfinal.cc => rtfinal.c}             |  0
 gcc/ada/{rtinit.cc => rtinit.c}               |  0
 gcc/ada/s-oscons-tmplt.c                      |  2 +-
 gcc/ada/{seh_init.cc => seh_init.c}           |  0
 ...gtramp-armdroid.cc => sigtramp-armdroid.c} |  0
 gcc/ada/{sigtramp-ios.cc => sigtramp-ios.c}   |  0
 gcc/ada/{sigtramp-qnx.cc => sigtramp-qnx.c}   |  0
 ...sigtramp-vxworks.cc => sigtramp-vxworks.c} |  0
 gcc/ada/{socket.cc => socket.c}               |  0
 gcc/ada/{tracebak.cc => tracebak.c}           |  0
 gcc/ada/{version.cc => version.c}             |  0
 gcc/ada/{vx_stack_info.cc => vx_stack_info.c} |  0
 33 files changed, 32 insertions(+), 38 deletions(-)
 rename gcc/ada/{adadecode.cc => adadecode.c} (100%)
 rename gcc/ada/{affinity.cc => affinity.c} (100%)
 rename gcc/ada/{argv-lynxos178-raven-cert.cc => argv-lynxos178-raven-cert.c} (100%)
 rename gcc/ada/{argv.cc => argv.c} (100%)
 rename gcc/ada/{aux-io.cc => aux-io.c} (100%)
 rename gcc/ada/{cio.cc => cio.c} (100%)
 rename gcc/ada/{cstreams.cc => cstreams.c} (100%)
 rename gcc/ada/{env.cc => env.c} (100%)
 rename gcc/ada/{exit.cc => exit.c} (100%)
 rename gcc/ada/{expect.cc => expect.c} (100%)
 rename gcc/ada/{final.cc => final.c} (100%)
 rename gcc/ada/{init.cc => init.c} (100%)
 rename gcc/ada/{initialize.cc => initialize.c} (100%)
 rename gcc/ada/libgnarl/{thread.cc => thread.c} (100%)
 rename gcc/ada/{link.cc => link.c} (100%)
 rename gcc/ada/{locales.cc => locales.c} (100%)
 rename gcc/ada/{mkdir.cc => mkdir.c} (100%)
 rename gcc/ada/{raise.cc => raise.c} (100%)
 rename gcc/ada/{rtfinal.cc => rtfinal.c} (100%)
 rename gcc/ada/{rtinit.cc => rtinit.c} (100%)
 rename gcc/ada/{seh_init.cc => seh_init.c} (100%)
 rename gcc/ada/{sigtramp-armdroid.cc => sigtramp-armdroid.c} (100%)
 rename gcc/ada/{sigtramp-ios.cc => sigtramp-ios.c} (100%)
 rename gcc/ada/{sigtramp-qnx.cc => sigtramp-qnx.c} (100%)
 rename gcc/ada/{sigtramp-vxworks.cc => sigtramp-vxworks.c} (100%)
 rename gcc/ada/{socket.cc => socket.c} (100%)
 rename gcc/ada/{tracebak.cc => tracebak.c} (100%)
 rename gcc/ada/{version.cc => version.c} (100%)
 rename gcc/ada/{vx_stack_info.cc => vx_stack_info.c} (100%)

diff --git a/gcc/ada/Make-generated.in b/gcc/ada/Make-generated.in
index 6cdc6b4605e..948fc508a56 100644
--- a/gcc/ada/Make-generated.in
+++ b/gcc/ada/Make-generated.in
@@ -53,7 +53,7 @@ ada/stamp-snames : ada/snames.ads-tmpl ada/snames.adb-tmpl ada/snames.h-tmpl ada
 	touch ada/stamp-snames
 
 ada/sdefault.adb: ada/stamp-sdefault ; @true
-ada/stamp-sdefault : $(srcdir)/ada/version.cc Makefile
+ada/stamp-sdefault : $(srcdir)/ada/version.c Makefile
 	$(ECHO) "pragma Style_Checks (Off);" >tmp-sdefault.adb
 	$(ECHO) "with Osint; use Osint;" >>tmp-sdefault.adb
 	$(ECHO) "package body Sdefault is" >>tmp-sdefault.adb
diff --git a/gcc/ada/Makefile.rtl b/gcc/ada/Makefile.rtl
index 59db72834dc..1b066ad6b14 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.cc is special as put into GNATRTL_TASKING_OBJS
+# thread.c 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,%.cc,$(LIBGNAT_OBJS))			\
+LIBGNAT_SRCS = $(patsubst %.o,%.c,$(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.cc, \
+	$(foreach f,$(ADA_INCLUDE_SRCS) $(LIBGNAT_SRCS) libgnarl/thread.c, \
 	  $(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.cc >> $(RTSDIR)/libgnarl.lst
+	@echo thread.c >> $(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/adadecode.cc b/gcc/ada/adadecode.c
similarity index 100%
rename from gcc/ada/adadecode.cc
rename to gcc/ada/adadecode.c
diff --git a/gcc/ada/affinity.cc b/gcc/ada/affinity.c
similarity index 100%
rename from gcc/ada/affinity.cc
rename to gcc/ada/affinity.c
diff --git a/gcc/ada/argv-lynxos178-raven-cert.cc b/gcc/ada/argv-lynxos178-raven-cert.c
similarity index 100%
rename from gcc/ada/argv-lynxos178-raven-cert.cc
rename to gcc/ada/argv-lynxos178-raven-cert.c
diff --git a/gcc/ada/argv.cc b/gcc/ada/argv.c
similarity index 100%
rename from gcc/ada/argv.cc
rename to gcc/ada/argv.c
diff --git a/gcc/ada/aux-io.cc b/gcc/ada/aux-io.c
similarity index 100%
rename from gcc/ada/aux-io.cc
rename to gcc/ada/aux-io.c
diff --git a/gcc/ada/cio.cc b/gcc/ada/cio.c
similarity index 100%
rename from gcc/ada/cio.cc
rename to gcc/ada/cio.c
diff --git a/gcc/ada/cstreams.cc b/gcc/ada/cstreams.c
similarity index 100%
rename from gcc/ada/cstreams.cc
rename to gcc/ada/cstreams.c
diff --git a/gcc/ada/env.cc b/gcc/ada/env.c
similarity index 100%
rename from gcc/ada/env.cc
rename to gcc/ada/env.c
diff --git a/gcc/ada/exit.cc b/gcc/ada/exit.c
similarity index 100%
rename from gcc/ada/exit.cc
rename to gcc/ada/exit.c
diff --git a/gcc/ada/expect.cc b/gcc/ada/expect.c
similarity index 100%
rename from gcc/ada/expect.cc
rename to gcc/ada/expect.c
diff --git a/gcc/ada/final.cc b/gcc/ada/final.c
similarity index 100%
rename from gcc/ada/final.cc
rename to gcc/ada/final.c
diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in
index 54cf182a8c3..53d0739470a 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -147,8 +147,8 @@ host_os=@host_os@
 target_cpu_default = @target_cpu_default@
 xmake_file = @xmake_file@
 tmake_file = @tmake_file@
-#version=`sed -e 's/.*\"\([^ \"]*\)[ \"].*/\1/' < $(srcdir)/version.cc`
-#mainversion=`sed -e 's/.*\"\([0-9]*\.[0-9]*\).*/\1/' < $(srcdir)/version.cc`
+#version=`sed -e 's/.*\"\([^ \"]*\)[ \"].*/\1/' < $(srcdir)/version.c`
+#mainversion=`sed -e 's/.*\"\([0-9]*\.[0-9]*\).*/\1/' < $(srcdir)/version.c`
 
 # Directory where sources are, from where we are.
 VPATH = $(srcdir)/ada
@@ -222,7 +222,7 @@ endif
 all.indirect: Makefile ../gnat1$(exeext)
 
 # IN_GCC is meant to distinguish between code compiled into GCC itself, i.e.
-# for the host, and the rest.  But we also use it for the tools (link.cc) and
+# for the host, and the rest.  But we also use it for the tools (link.c) and
 # even break the host/target wall by using it for the library (targext.c).
 # autoconf inserts -DCROSS_DIRECTORY_STRUCTURE if we are building a cross
 # compiler which does not use the native libraries and headers.
@@ -240,7 +240,7 @@ ALL_COMPILERFLAGS = $(ALL_CFLAGS)
 # This is where we get libiberty.a from.
 LIBIBERTY = ../../libiberty/libiberty.a
 
-# We need to link against libbacktrace because diagnostic.cc in
+# We need to link against libbacktrace because diagnostic.c in
 # libcommon.a uses it.
 LIBBACKTRACE = ../../libbacktrace/.libs/libbacktrace.a
 
@@ -296,10 +296,6 @@ 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)
 
@@ -307,7 +303,7 @@ ADA_INCLUDES_FOR_SUBDIR = -I. -I$(fsrcdir)/ada
 	$(CC) -c $(ALL_ADAFLAGS) $(ADA_INCLUDES) $< $(OUTPUT_OPTION)
 
 # how to regenerate this file
-Makefile: ../config.status $(srcdir)/ada/gcc-interface/Makefile.in $(srcdir)/ada/Makefile.in $(srcdir)/ada/version.cc
+Makefile: ../config.status $(srcdir)/ada/gcc-interface/Makefile.in $(srcdir)/ada/Makefile.in $(srcdir)/ada/version.c
 	cd ..; \
 	LANGUAGES="$(CONFIG_LANGUAGES)" \
 	CONFIG_HEADERS= \
@@ -415,7 +411,6 @@ ifeq ($(TOOLSCASE),native)
   vpath %.ads ../$(RTSDIR) ../
   vpath %.adb ../$(RTSDIR) ../
   vpath %.c   ../$(RTSDIR) ../
-  vpath %.cc  ../$(RTSDIR) ../
   vpath %.h   ../$(RTSDIR) ../
 endif
 
@@ -425,7 +420,6 @@ ifeq ($(TOOLSCASE),cross)
   vpath %.ads ../
   vpath %.adb ../
   vpath %.c   ../
-  vpath %.cc  ../
   vpath %.h   ../
 endif
 
@@ -909,44 +903,44 @@ ADA_RTL_DSO_DIR = $(toolexeclibdir)
 # need to keep the frame pointer in tracebak.o to pop the stack properly on
 # some targets.
 
-tracebak.o  : tracebak.cc
+tracebak.o  : tracebak.c
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ADA_CFLAGS) $(ALL_CPPFLAGS) \
 	      $(INCLUDES) $(NO_OMIT_ADAFLAGS) $< $(OUTPUT_OPTION)
 
-adadecode.o : adadecode.cc adadecode.h
-aux-io.o  : aux-io.cc
-argv.o    : argv.cc
+adadecode.o : adadecode.c adadecode.h
+aux-io.o  : aux-io.c
+argv.o    : argv.c
 cal.o     : cal.c
 deftarg.o : deftarg.c
 errno.o   : errno.c
-exit.o    : adaint.h exit.cc
-expect.o  : expect.cc
-final.o   : final.cc
-rtfinal.o : rtfinal.cc
-rtinit.o  : rtinit.cc
-locales.o : locales.cc
-mkdir.o   : mkdir.cc
-socket.o  : socket.cc gsocket.h
+exit.o    : adaint.h exit.c
+expect.o  : expect.c
+final.o   : final.c
+rtfinal.o : rtfinal.c
+rtinit.o  : rtinit.c
+locales.o : locales.c
+mkdir.o   : mkdir.c
+socket.o  : socket.c gsocket.h
 sysdep.o  : sysdep.c
-raise.o   : raise.cc raise.h
-sigtramp-armdroid.o      : sigtramp-armdroid.cc sigtramp.h
+raise.o   : raise.c raise.h
+sigtramp-armdroid.o      : sigtramp-armdroid.c sigtramp.h
 sigtramp-armvxworks.o    : sigtramp-armvxworks.c sigtramp.h
-sigtramp-ios.o           : sigtramp-ios.cc sigtramp.h
-sigtramp-vxworks.o       : sigtramp-vxworks.cc $(VX_SIGTRAMP_EXTRA_SRCS)
+sigtramp-ios.o           : sigtramp-ios.c sigtramp.h
+sigtramp-vxworks.o       : sigtramp-vxworks.c $(VX_SIGTRAMP_EXTRA_SRCS)
 sigtramp-vxworks-vxsim.o : sigtramp-vxworks-vxsim.c $(VX_SIGTRAMP_EXTRA_SRCS)
 terminals.o : terminals.c
-vx_stack_info.o : vx_stack_info.cc
+vx_stack_info.o : vx_stack_info.c
 
 raise-gcc.o : raise-gcc.c raise.h
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ADA_CFLAGS) \
 		-iquote $(srcdir) -iquote $(ftop_srcdir)/libgcc \
 		$(ALL_CPPFLAGS) $(INCLUDES) $< $(OUTPUT_OPTION)
 
-cio.o     : cio.cc
+cio.o     : cio.c
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ADA_CFLAGS) \
 	         $(ALL_CPPFLAGS) $(INCLUDES) $< $(OUTPUT_OPTION)
 
-init.o    : init.cc adaint.h raise.h
+init.o    : init.c adaint.h raise.h
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ADA_CFLAGS) \
 	         $(ALL_CPPFLAGS) $(INCLUDES) $< $(OUTPUT_OPTION)
 
@@ -954,11 +948,11 @@ init-vxsim.o : init-vxsim.c
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ADA_CFLAGS) \
 	         $(ALL_CPPFLAGS) $(INCLUDES) $< $(OUTPUT_OPTION)
 
-initialize.o : initialize.cc raise.h
+initialize.o : initialize.c raise.h
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ADA_CFLAGS) \
 	         $(ALL_CPPFLAGS) $(INCLUDES) $< $(OUTPUT_OPTION)
 
-link.o : link.cc
+link.o : link.c
 	$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ADA_CFLAGS) \
 		$(ALL_CPPFLAGS) $(INCLUDES_FOR_SUBDIR) \
 		$< $(OUTPUT_OPTION)
diff --git a/gcc/ada/init.cc b/gcc/ada/init.c
similarity index 100%
rename from gcc/ada/init.cc
rename to gcc/ada/init.c
diff --git a/gcc/ada/initialize.cc b/gcc/ada/initialize.c
similarity index 100%
rename from gcc/ada/initialize.cc
rename to gcc/ada/initialize.c
diff --git a/gcc/ada/libgnarl/thread.cc b/gcc/ada/libgnarl/thread.c
similarity index 100%
rename from gcc/ada/libgnarl/thread.cc
rename to gcc/ada/libgnarl/thread.c
diff --git a/gcc/ada/link.cc b/gcc/ada/link.c
similarity index 100%
rename from gcc/ada/link.cc
rename to gcc/ada/link.c
diff --git a/gcc/ada/locales.cc b/gcc/ada/locales.c
similarity index 100%
rename from gcc/ada/locales.cc
rename to gcc/ada/locales.c
diff --git a/gcc/ada/mkdir.cc b/gcc/ada/mkdir.c
similarity index 100%
rename from gcc/ada/mkdir.cc
rename to gcc/ada/mkdir.c
diff --git a/gcc/ada/raise.cc b/gcc/ada/raise.c
similarity index 100%
rename from gcc/ada/raise.cc
rename to gcc/ada/raise.c
diff --git a/gcc/ada/rtfinal.cc b/gcc/ada/rtfinal.c
similarity index 100%
rename from gcc/ada/rtfinal.cc
rename to gcc/ada/rtfinal.c
diff --git a/gcc/ada/rtinit.cc b/gcc/ada/rtinit.c
similarity index 100%
rename from gcc/ada/rtinit.cc
rename to gcc/ada/rtinit.c
diff --git a/gcc/ada/s-oscons-tmplt.c b/gcc/ada/s-oscons-tmplt.c
index ea7d256ed43..af6919092d5 100644
--- a/gcc/ada/s-oscons-tmplt.c
+++ b/gcc/ada/s-oscons-tmplt.c
@@ -1976,7 +1976,7 @@ CND(CLOCK_THREAD_CPUTIME_ID, "Thread CPU clock")
  || defined(__DragonFly__) || defined(__QNX__)
 /** On these platforms use system provided monotonic clock instead of
  ** the default CLOCK_REALTIME. We then need to set up cond var attributes
- ** appropriately (see thread.cc).
+ ** appropriately (see thread.c).
  **
  ** Note that AIX 5.2 does not support CLOCK_MONOTONIC timestamps for
  ** pthread_cond_timedwait (and does not have pthread_condattr_setclock),
diff --git a/gcc/ada/seh_init.cc b/gcc/ada/seh_init.c
similarity index 100%
rename from gcc/ada/seh_init.cc
rename to gcc/ada/seh_init.c
diff --git a/gcc/ada/sigtramp-armdroid.cc b/gcc/ada/sigtramp-armdroid.c
similarity index 100%
rename from gcc/ada/sigtramp-armdroid.cc
rename to gcc/ada/sigtramp-armdroid.c
diff --git a/gcc/ada/sigtramp-ios.cc b/gcc/ada/sigtramp-ios.c
similarity index 100%
rename from gcc/ada/sigtramp-ios.cc
rename to gcc/ada/sigtramp-ios.c
diff --git a/gcc/ada/sigtramp-qnx.cc b/gcc/ada/sigtramp-qnx.c
similarity index 100%
rename from gcc/ada/sigtramp-qnx.cc
rename to gcc/ada/sigtramp-qnx.c
diff --git a/gcc/ada/sigtramp-vxworks.cc b/gcc/ada/sigtramp-vxworks.c
similarity index 100%
rename from gcc/ada/sigtramp-vxworks.cc
rename to gcc/ada/sigtramp-vxworks.c
diff --git a/gcc/ada/socket.cc b/gcc/ada/socket.c
similarity index 100%
rename from gcc/ada/socket.cc
rename to gcc/ada/socket.c
diff --git a/gcc/ada/tracebak.cc b/gcc/ada/tracebak.c
similarity index 100%
rename from gcc/ada/tracebak.cc
rename to gcc/ada/tracebak.c
diff --git a/gcc/ada/version.cc b/gcc/ada/version.c
similarity index 100%
rename from gcc/ada/version.cc
rename to gcc/ada/version.c
diff --git a/gcc/ada/vx_stack_info.cc b/gcc/ada/vx_stack_info.c
similarity index 100%
rename from gcc/ada/vx_stack_info.cc
rename to gcc/ada/vx_stack_info.c
-- 
2.34.1


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ
  2022-01-18  9:08                 ` Martin Liška
@ 2022-01-18  9:13                   ` Jakub Jelinek
  2022-01-18  9:43                     ` Martin Liška
  0 siblings, 1 reply; 43+ messages in thread
From: Jakub Jelinek @ 2022-01-18  9:13 UTC (permalink / raw)
  To: Martin Liška
  Cc: Richard Biener, Eric Botcazou, GCC Mailing List, GCC Patches

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


^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ
  2022-01-18  9:13                   ` Jakub Jelinek
@ 2022-01-18  9:43                     ` Martin Liška
  0 siblings, 0 replies; 43+ messages in thread
From: Martin Liška @ 2022-01-18  9:43 UTC (permalink / raw)
  To: Jakub Jelinek
  Cc: Richard Biener, Eric Botcazou, GCC Mailing List, GCC Patches

> 
> LGTM.
> 
I've just installed that, the Ada testsuite should work now.

Martin

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ
  2022-01-17 21:41       ` Martin Liška
  2022-01-18  8:36         ` Eric Botcazou
@ 2022-01-18 13:10         ` Richard Earnshaw
  2022-01-18 13:16           ` Martin Liška
  1 sibling, 1 reply; 43+ messages in thread
From: Richard Earnshaw @ 2022-01-18 13:10 UTC (permalink / raw)
  To: Martin Liška, Toon Moene, Martin Jambor, GCC Mailing List
  Cc: GCC Patches



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.

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ
  2022-01-18 13:10         ` Richard Earnshaw
@ 2022-01-18 13:16           ` Martin Liška
  0 siblings, 0 replies; 43+ messages in thread
From: Martin Liška @ 2022-01-18 13:16 UTC (permalink / raw)
  To: Richard Earnshaw, Toon Moene, Martin Jambor, GCC Mailing List; +Cc: GCC Patches

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

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] git-backport: support renamed .cc files in commit message.
  2022-01-17 21:26                 ` Martin Liška
@ 2022-01-18 19:10                   ` Harald Anlauf
  2022-01-19  8:07                     ` Martin Liška
  0 siblings, 1 reply; 43+ messages in thread
From: Harald Anlauf @ 2022-01-18 19:10 UTC (permalink / raw)
  To: Martin Liška, Jakub Jelinek; +Cc: GCC Mailing List, GCC Patches, gfortran

Am 17.01.22 um 22:26 schrieb Martin Liška:
> On 1/12/22 16:54, Martin Liška wrote:
>>
>> There's a patch that enhances git-backport so that it updates commit
>> messages for files which name ends now with .cc and is still .c on a branch.
>>
>
> The patch has been installed as I've made the renaming now.
>
> Cheers,
> Martin
>

I just made a "git rebase" and had to manually fix the filenames
in the commit message.  Otherwise gcc-verify would complain.

Would it make sense to have something that is clever enough for
rebase to do similar things as git-backport?

Thanks,
Harald

^ permalink raw reply	[flat|nested] 43+ messages in thread

* Re: [PATCH] git-backport: support renamed .cc files in commit message.
  2022-01-18 19:10                   ` Harald Anlauf
@ 2022-01-19  8:07                     ` Martin Liška
  0 siblings, 0 replies; 43+ messages in thread
From: Martin Liška @ 2022-01-19  8:07 UTC (permalink / raw)
  To: Harald Anlauf, fortran; +Cc: gcc, gcc-patches

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

On 1/18/22 20:10, Harald Anlauf via Fortran wrote:
> Am 17.01.22 um 22:26 schrieb Martin Liška:
>> On 1/12/22 16:54, Martin Liška wrote:
>>>
>>> There's a patch that enhances git-backport so that it updates commit
>>> messages for files which name ends now with .cc and is still .c on a branch.
>>
>> The patch has been installed as I've made the renaming now.
>>
>> Cheers,
>> Martin
>>
> 
> I just made a "git rebase" and had to manually fix the filenames
> in the commit message.  Otherwise gcc-verify would complain.

Sure and I'm adding a new script that basically follows all the 'did you mean'
in gcc-verify and fixes that:

ERR: unchanged file mentioned in a ChangeLog (did you mean "contrib/gcc-git-customization.sh"?): "contrib/gcc2-git-customization.sh"
...

> 
> Would it make sense to have something that is clever enough for
> rebase to do similar things as git-backport?

Yes, a new git alias 'gcc-fix-changelog' is going to be available with the patch.

Martin

> 
> Thanks,
> Harald
> 

[-- Attachment #2: 0001-Come-up-with-git-fix-changelog.py-script.patch --]
[-- Type: text/x-patch, Size: 7804 bytes --]

From 4f502745c8e2562ae192181bf2585bad42414d45 Mon Sep 17 00:00:00 2001
From: Martin Liska <mliska@suse.cz>
Date: Wed, 19 Jan 2022 07:57:05 +0100
Subject: [PATCH] Come up with git-fix-changelog.py script.

contrib/ChangeLog:

	* git-backport.py: Use it.
	* git-fix-changelog.py: New file.
	* gcc-git-customization.sh: Add new alias git gcc-fix-changelog.
---
 contrib/gcc-git-customization.sh |  1 +
 contrib/git-backport.py          | 47 +---------------
 contrib/git-fix-changelog.py     | 92 ++++++++++++++++++++++++++++++++
 3 files changed, 95 insertions(+), 45 deletions(-)
 create mode 100755 contrib/git-fix-changelog.py

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index aca61b781ff..2eec17937af 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -27,6 +27,7 @@ git config alias.gcc-undescr \!"f() { o=\$(git config --get gcc-config.upstream)
 
 git config alias.gcc-verify '!f() { "`git rev-parse --show-toplevel`/contrib/gcc-changelog/git_check_commit.py" $@; } ; f'
 git config alias.gcc-backport '!f() { "`git rev-parse --show-toplevel`/contrib/git-backport.py" $@; } ; f'
+git config alias.gcc-fix-changelog '!f() { "`git rev-parse --show-toplevel`/contrib/git-fix-changelog.py" $@; } ; f'
 git config alias.gcc-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/mklog.py" $@; } ; f'
 git config alias.gcc-commit-mklog '!f() { "`git rev-parse --show-toplevel`/contrib/git-commit-mklog.py" "$@"; }; f'
 
diff --git a/contrib/git-backport.py b/contrib/git-backport.py
index 83189a2b5c7..fc369d97754 100755
--- a/contrib/git-backport.py
+++ b/contrib/git-backport.py
@@ -22,29 +22,9 @@
 import argparse
 import os
 import subprocess
-import tempfile
 
 script_folder = os.path.dirname(os.path.abspath(__file__))
-verify_script = os.path.join(script_folder,
-                             'gcc-changelog/git_check_commit.py')
-
-
-def replace_file_in_changelog(lines, filename):
-    if not filename.endswith('.cc'):
-        return
-
-    # consider all componenets of a path: gcc/ipa-icf.cc
-    while filename:
-        for i, line in enumerate(lines):
-            if filename in line:
-                line = line.replace(filename, filename[:-1])
-                lines[i] = line
-                return
-        parts = filename.split('/')
-        if len(parts) == 1:
-            return
-        filename = '/'.join(parts[1:])
-
+fixup_script = os.path.join(script_folder, 'git-fix-changelog.py')
 
 if __name__ == '__main__':
     parser = argparse.ArgumentParser(description='Backport a git revision.')
@@ -52,27 +32,4 @@ if __name__ == '__main__':
     args = parser.parse_args()
 
     subprocess.run('git cherry-pick -x %s' % args.revision, shell=True)
-
-    # Update commit message if change for a .cc file was taken
-    r = subprocess.run(f'{verify_script} HEAD', shell=True, encoding='utf8',
-                       stdout=subprocess.PIPE, stderr=subprocess.PIPE)
-    if r.returncode != 0:
-        lines = r.stdout.splitlines()
-        cmd = 'git show -s --format=%B'
-        commit_message = subprocess.check_output(cmd, shell=True,
-                                                 encoding='utf8').strip()
-        commit_message = commit_message.splitlines()
-
-        todo = [line for line in lines if 'unchanged file mentioned' in line]
-        for item in todo:
-            filename = item.split()[-1].strip('"')
-            replace_file_in_changelog(commit_message, filename)
-
-        with tempfile.NamedTemporaryFile('w', encoding='utf8',
-                                         delete=False) as w:
-            w.write('\n'.join(commit_message))
-            w.close()
-            subprocess.check_output(f'git commit --amend -F {w.name}',
-                                    shell=True, encoding='utf8')
-            os.unlink(w.name)
-            print(f'Commit message updated: {len(todo)} .cc file(s) changed.')
+    subprocess.run(fixup_script, shell=True)
diff --git a/contrib/git-fix-changelog.py b/contrib/git-fix-changelog.py
new file mode 100755
index 00000000000..c15e45c11fa
--- /dev/null
+++ b/contrib/git-fix-changelog.py
@@ -0,0 +1,92 @@
+#!/usr/bin/env python3
+
+# Copyright (C) 2020 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING.  If not, write to
+# the Free Software Foundation, 51 Franklin Street, Fifth Floor,
+# Boston, MA 02110-1301, USA.
+#
+# The script tries to fix commit message where ChangeLog entries
+# can point to .cc renamed files.
+
+import argparse
+import os
+import subprocess
+import tempfile
+
+DESCRIPTION = 'Fix up ChangeLog of the current commit.'
+
+script_folder = os.path.dirname(os.path.abspath(__file__))
+verify_script = os.path.join(script_folder,
+                             'gcc-changelog/git_check_commit.py')
+
+
+def replace_file_in_changelog(lines, filename, fixed):
+    # consider all componenets of a path: gcc/ipa-icf.cc
+    while filename:
+        for i, line in enumerate(lines):
+            if filename in line:
+                lines[i] = line.replace(filename, fixed)
+                return
+
+        parts = filename.split('/')
+        if len(parts) == 1:
+            return
+        filename = '/'.join(parts[1:])
+        fixed = '/'.join(fixed.split('/')[1:])
+
+
+if __name__ == '__main__':
+    parser = argparse.ArgumentParser(description=DESCRIPTION)
+    args = parser.parse_args()
+
+    # Update commit message if change for a .cc file was taken
+    r = subprocess.run(f'{verify_script} HEAD', shell=True, encoding='utf8',
+                       stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+    if r.returncode != 0:
+        lines = r.stdout.splitlines()
+        cmd = 'git show -s --format=%B'
+        commit_message = subprocess.check_output(cmd, shell=True,
+                                                 encoding='utf8').strip()
+        commit_message = commit_message.splitlines()
+
+        # Parse the following lines:
+        # ERR: unchanged file mentioned in a ChangeLog \
+        # (did you mean "gcc/ipa-icf.cc"?): "gcc/ipa-icf.c"
+        replaced = 0
+        for line in lines:
+            if ('unchanged file mentioned' in line and
+                    'did you mean' in line):
+                filename = line.split()[-1].strip('"')
+                fixed = line[line.index('did you mean'):]
+                fixed = fixed[fixed.index('"') + 1:]
+                fixed = fixed[:fixed.index('"')]
+
+                if filename.count('/') == fixed.count('/'):
+                    replace_file_in_changelog(commit_message, filename, fixed)
+                    replaced += 1
+
+        if replaced:
+            with tempfile.NamedTemporaryFile('w', encoding='utf8',
+                                             delete=False) as w:
+                w.write('\n'.join(commit_message))
+                w.close()
+                subprocess.check_output(f'git commit --amend -F {w.name}',
+                                        shell=True, encoding='utf8')
+                os.unlink(w.name)
+                print(f'Commit message updated: {replaced} file(s) renamed.')
+        else:
+            print('Commit message has not been updated.')
-- 
2.34.1


^ permalink raw reply	[flat|nested] 43+ messages in thread

end of thread, other threads:[~2022-01-19  8:07 UTC | newest]

Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-07 10:25 Mass rename of C++ .c files to .cc suffix? Martin Jambor
2022-01-07 10:33 ` Richard Sandiford
2022-01-07 10:44   ` Andrew Pinski
2022-01-07 10:51 ` Jonathan Wakely
2022-01-07 10:51 ` Jakub Jelinek
2022-01-07 11:05   ` Jonathan Wakely
2022-01-07 12:55     ` Martin Liška
2022-01-07 14:42       ` Iain Sandoe
2022-01-07 14:49 ` Jeff Law
2022-01-07 15:45   ` Jeff Law
2022-01-07 15:59 ` David Malcolm
2022-01-07 17:31   ` Jonathan Wakely
2022-01-10  9:11   ` Martin Liška
2022-01-07 18:33 ` Alexandre Oliva
2022-01-07 19:01   ` Jakub Jelinek
2022-01-11 12:56 ` [PATCH] Mass rename of C++ .c files to .cc suffix Martin Liška
2022-01-11 15:48   ` Toon Moene
2022-01-11 15:50     ` Martin Liška
2022-01-11 15:56       ` Jakub Jelinek
2022-01-11 16:03         ` Martin Liška
2022-01-11 16:16           ` Jakub Jelinek
2022-01-12  8:58             ` Martin Liška
2022-01-12 15:54               ` [PATCH] git-backport: support renamed .cc files in commit message Martin Liška
2022-01-14  7:44                 ` Bernhard Reutner-Fischer
2022-01-14 15:26                   ` Martin Liška
2022-01-17 21:26                 ` Martin Liška
2022-01-18 19:10                   ` Harald Anlauf
2022-01-19  8:07                     ` Martin Liška
2022-01-11 18:00       ` [PATCH] Mass rename of C++ .c files to .cc suffix Harald Anlauf
2022-01-11 18:00         ` Harald Anlauf
2022-01-11 18:23         ` Jonathan Wakely
2022-01-11 18:36           ` Jakub Jelinek
2022-01-13 11:01     ` [ANNOUNCEMENT] Mass rename of C++ .c files to .cc suffix is going to happen on Jan 17 evening UTC TZ Martin Liška
2022-01-17 21:41       ` Martin Liška
2022-01-18  8:36         ` Eric Botcazou
2022-01-18  8:39           ` Martin Liška
2022-01-18  8:46             ` Eric Botcazou
2022-01-18  8:53               ` Richard Biener
2022-01-18  9:08                 ` Martin Liška
2022-01-18  9:13                   ` Jakub Jelinek
2022-01-18  9:43                     ` Martin Liška
2022-01-18 13:10         ` Richard Earnshaw
2022-01-18 13:16           ` Martin Liška

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).