Created attachment 189436 [details] Fix build with clang 6.0.0 for lang/gcc{48,49,5} While testing the new clang600-import branch (see bug 224669), I noticed that lang/gcc48, lang/gcc49 and lang/gcc5 fail to compile, due clang++ 6.0.0 now defaulting to -std=gnu++14. There are lots of errors similar to: /wrkdirs/share/dim/ports/lang/gcc5/work/gcc-5.5.0/gcc/wide-int-print.cc:130:27: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal] buf += sprintf (buf, "0x"HOST_WIDE_INT_PRINT_HEX_PURE, wi.elt (--i)); ^ Upstream fixed this for gcc 6 and later by adding a space between the double quote and the macro names. I tried getting the first stage compiled with -std=gnu++98 by setting USE_CXXSTD=gnu++98, but that lead to lots of compilation errors while building libstdc++, which apparently needs C++11 or higher to compile. So I have added a post-patch section to the three Makefiles, which searches out all source files using double quotes followed directly by a few specific macro names, and adds a space, e.g.: post-patch: @${FIND} ${WRKSRC} -type f \( -name '*.[ch]' -o -name '*.cc' \) | \ ${XARGS} ${EGREP} -l '"(HOST_WIDE|PLUGIN_COND|PRId64)' | \ ${XARGS} ${REINPLACE_CMD} -E -e 's/"(HOST_WIDE|PLUGIN_COND|PRId64)/" \1/g' Furthermore, lang/gcc5 also needs a separate patch to fix an incorrect call to error(), which should have been error_at(). That was a mismerge by upstream, but reporting it there is probably futile now.
Btw, if there is a good way of passing -std=gnu++98 *only* to the first stage gcc build, but keeping that flag out of the libstdc++ and second/third stages (if bootstrapping is enable), then that could also work, obviously.
(In reply to Dimitry Andric from comment #1) > Btw, if there is a good way of passing -std=gnu++98 *only* to the first stage > gcc build, but keeping that flag out of the libstdc++ and second/third stages > (if bootstrapping is enable), then that could also work, obviously. Hi Dim, thanks for not just reporting this, but even looking at potential fixes and workaround. Might STAGE1_TFLAGS do what you are wondering above? (There's not a lot of documentation available for it, to put it mildly, and it appears to be used by GCC itself for a similar situation around debug infos.) If that does not prove to work out, the patch (for all three ports) is Approved by: gerald (maintainer). Or I can apply it on your behalf and with attribution (of course), if you prefer. Just let me know.
A commit references this bug: Author: dim Date: Tue Jan 9 22:08:46 UTC 2018 New revision: 458581 URL: https://svnweb.freebsd.org/changeset/ports/458581 Log: Fix builds of lang/gcc{48,49,5} with clang 6.0.0 Since clang++ 6.0.0 now defaults to -std=gnu++14 (similar to g++ 6 and higher), building gcc48, gcc49 or gcc5 produce quite a number of "invalid suffix on literal; C++11 requires a space between literal and identifier" errors. This is because in many places, double quotes are directly followed by printf helper macros like HOST_WIDE_INT_PRINT. In gcc 6 and later, spaces were added between the double quotes and the macros, to fix this issue, but for earlier versions, use a combination of find, grep and sed to add them mechanically throughout the respective source trees. In addition, gcc5 needs a regular patch to fix an incorrect call to error(), which should have been error_at(). (This was a mismerge by upstream.) Approved by: gerald (maintainer) PR: 224927 MFH: 2018Q1 Changes: head/lang/gcc48/Makefile head/lang/gcc49/Makefile head/lang/gcc5/Makefile head/lang/gcc5/files/patch-gcc_toplev.c
(In reply to Gerald Pfeifer from comment #2) > Might STAGE1_TFLAGS do what you are wondering above? (There's not a lot > of documentation available for it, to put it mildly, and it appears to be > used by GCC itself for a similar situation around debug infos.) I tried setting STAGE1_TFLAGS in CONFIGURE_ENV, but it didn't seem to work. At least, I still got the same errors about invalid literal suffixes. I have now committed the find/grep/sed fix instead, and will merge it to 2018Q1 when it is approved.
I think we can close this, or is anything left open?
(In reply to Gerald Pfeifer from comment #5) > I think we can close this, or is anything left open? I put a MFH: header in the commit message, but it seems to have been ignored by whoever receives these. But never mind for now.
A commit references this bug: Author: feld Date: Fri Feb 2 10:07:58 UTC 2018 New revision: 460692 URL: https://svnweb.freebsd.org/changeset/ports/460692 Log: MFH: r458581 Fix builds of lang/gcc{48,49,5} with clang 6.0.0 Since clang++ 6.0.0 now defaults to -std=gnu++14 (similar to g++ 6 and higher), building gcc48, gcc49 or gcc5 produce quite a number of "invalid suffix on literal; C++11 requires a space between literal and identifier" errors. This is because in many places, double quotes are directly followed by printf helper macros like HOST_WIDE_INT_PRINT. In gcc 6 and later, spaces were added between the double quotes and the macros, to fix this issue, but for earlier versions, use a combination of find, grep and sed to add them mechanically throughout the respective source trees. In addition, gcc5 needs a regular patch to fix an incorrect call to error(), which should have been error_at(). (This was a mismerge by upstream.) Approved by: gerald (maintainer) PR: 224927 Changes: _U branches/2018Q1/ branches/2018Q1/lang/gcc48/Makefile branches/2018Q1/lang/gcc49/Makefile branches/2018Q1/lang/gcc5/Makefile branches/2018Q1/lang/gcc5/files/patch-gcc_toplev.c
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=16f8f89c5c1f324a15a7e0607f03f041a230a572 commit 16f8f89c5c1f324a15a7e0607f03f041a230a572 Author: Mark Johnston <markj@FreeBSD.org> AuthorDate: 2021-05-26 14:02:19 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2021-05-26 14:45:40 +0000 cxgb: Avoid a read-after-free in get_packet() when cxgb_debug is on PR: 224927 MFC after: 1 week sys/dev/cxgb/cxgb_sge.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)