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.
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.
(In reply to Matthias Andree from comment #0) oh, and that's three lines in your text editor (not two).
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.
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.
MARKED AS SPAM