* 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 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
* 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
* [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 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
* 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: [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
* 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
* [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: [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
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).