Bug 245006 - toolchain: clang issues bogus "warning: multi-line // comment [-Wcomment]" under -pedantic
Summary: toolchain: clang issues bogus "warning: multi-line // comment [-Wcomment]" un...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: standards (show other bugs)
Version: 12.1-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-standards mailing list
URL: https://github.com/Genivia/RE-flex/is...
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-23 13:29 UTC by Matthias Andree
Modified: 2020-03-23 21:34 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Andree freebsd_committer 2020-03-23 13:29:29 UTC
Greetings,

debugging a ports/textproc/re-flex 1.6.4 issue, I came across a standards violation in clang, observed in base clang 8.0.1 (FreeBSD 12.1 amd64), ports clang 9 and clang-devel as of today (llvm90-9.0.1 llvm-devel-11.0.d20200117), but not gcc-9.2.0 from ports.

Save these two lines as try.c:

// \
x
void f(void) {}

Then observe:
$ gcc -pedantic-errors -std=c11 -c /tmp/try.c 
(no output)

$ /usr/bin/clang -pedantic-errors -std=c11 -c /tmp/try.c 
/tmp/try.c:1:4: error: multi-line // comment [-Werror,-Wcomment]
// \
   ^
1 error generated.

Reading up in C99, C11, C++11, it is clear that line merging happens in compilation phase 2, before phase 3 elides comments and replaces them by one space.
Comment 1 Matthias Andree freebsd_committer 2020-03-23 13:31:17 UTC
sorry, this escaped too soon. My conclusion is that the input is well-formed C99/C11/C++11 code that clang has no right to diagnose or reject.
Comment 2 Matthias Andree freebsd_committer 2020-03-23 13:32:28 UTC
(In reply to Matthias Andree from comment #0)
oh, and that's three lines in your text editor (not two).
Comment 3 Dimitry Andric freebsd_committer 2020-03-23 18:34:40 UTC
Apparently gcc thinks the same, you just have to add -Wcomment:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/lto-wrapper
Target: x86_64-portbld-freebsd13.0
Configured with: /wrkdirs/share/dim/ports/lang/gcc9/work/gcc-9.2.0/configure --enable-multilib --enable-plugin --disable-bootstrap --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc9 --libexecdir=/usr/local/libexec/gcc9 --program-suffix=9 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc9/include/c++/ --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --with-isl=/usr/local --enable-languages=c,c++,objc,fortran --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/share/info/gcc9 --build=x86_64-portbld-freebsd13.0
Thread model: posix
gcc version 9.2.0 (FreeBSD Ports Collection)

$ gcc -Wcomment -c multiline.c
multiline.c:1:1: warning: multi-line comment [-Wcomment]
    1 | // \
      | ^

And similar for gcc 4.8, 7.5 and 8.3.

I am unsure about the interpretation of the various standards though, as they do not say much, if anything, about warnings.  The construct is completely legal, so it causes no errors unless you insist on making all warnings errors.

Maybe you can report this upstream with gcc and clang, to see what their opinion is?  I am hesitant to make changes to our versions unless there is a pressing need to do so.
Comment 4 Matthias Andree freebsd_committer 2020-03-23 21:34:56 UTC
After some digging, I figured that -pedantic -std=c11 makes the difference. 
All GCC version I've tried (9.2.0, 10.0 snapshot) accept the code without diagnostics. 

-pedantic interpretation differs. clang flags extensions, and gcc enables all diagnostics required by the standard.


gcc -O -std=c11 -pedantic-errors  -c /tmp/try.c 
gcc10 -O -std=c11 -pedantic-errors  -c /tmp/try.c 
(no output)

clang -O -std=c11 -pedantic-errors  -c /tmp/try.c 
/tmp/try.c:1:4: error: multi-line // comment [-Werror,-Wcomment]

same for base clang and all clang versions from ports:
llvm-devel-11.0.d20200117      LLVM and Clang
llvm10-10.0.0.r4               LLVM and Clang
llvm80-8.0.1_3                 LLVM and Clang
llvm90-9.0.1                   LLVM and Clang

I've filed this with LLVM, link in See Also. Let's see what we get.