While building llvm & clang & libs by giving some optimization options
to the building compiler, the following error happened:
I think it is related to the passed -DCLS=64, because in file
clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:6411 an enum member
has the same name (CLS), so it does a macro-substitution with the passed value of CLS, ie. with 64, but which of course then breakes the syntax...
I think such "reserved" names like CLS that can be passed to the compiler(s), should be avoided as identifiers for naming variables, constants, enum members, macros etc.
[2845/3381] Building CXX object tools/clang/lib/Tooling/CMakeFiles/clangTooling.dir/Execution.cpp.o
FAILED: /usr/local/gcc-latest/bin/g++-latest -DEXPENSIVE_CHECKS -D_DEBUG -D_GLIBCXX_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/clang/lib/Frontend/Rewrite -I/sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite -I/sw/src/clang_llvm_dev/clang/include -Itools/clang/include -Iinclude -I/sw/src/clang_llvm_dev/llvm_trunk/include -fopt-info -pipe -Wall -Wextra -Ofast -DCLS=64 -fPIC -floop-nest-optimize --param simultaneous-prefetches=16 -fprefetch-loop-arrays -msse4.2 -mrecip=all -funroll-loops -fdelete-null-pointer-checks --param prefetch-latency=32 -ffast-math -ftree-vectorize -funsafe-math-optimizations -Wno-error=unused-parameter -Wno-error=type-limits -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++1y -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -pedantic -Wno-long-long -O3 -UNDEBUG -MD -MT tools/clang/lib/Frontend/Rewrite/CMakeFiles/clangRewriteFrontend.dir/RewriteModernObjC.cpp.o -MF tools/clang/lib/Frontend/Rewrite/CMakeFiles/clangRewriteFrontend.dir/RewriteModernObjC.cpp.o.d -o tools/clang/lib/Frontend/Rewrite/CMakeFiles/clangRewriteFrontend.dir/RewriteModernObjC.cpp.o -c /sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp
<command-line>: error: expected identifier before numeric constant
/sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:6411:3: note: in expansion of macro 'CLS'
CLS = 0x0,
^~~
<command-line>: error: expected '}' before numeric constant
/sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:6411:3: note: in expansion of macro 'CLS'
CLS = 0x0,
^~~
/sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:6410:20: note: to match this '{'
enum MetaDataDlags {
^
<command-line>: error: expected unqualified-id before numeric constant
/sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:6411:3: note: in expansion of macro 'CLS'
CLS = 0x0,
^~~
/sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:6421:1: error: expected declaration before '}' token
};
^
In file included from /sw/src/clang_llvm_dev/llvm_trunk/include/llvm/ADT/STLExtras.h:21,
from /sw/src/clang_llvm_dev/llvm_trunk/include/llvm/ADT/StringRef.h:13,
from /sw/src/clang_llvm_dev/llvm_trunk/include/llvm/ADT/StringMap.h:17,
from /sw/src/clang_llvm_dev/llvm_trunk/include/llvm/Support/Host.h:17,
from /sw/src/clang_llvm_dev/llvm_trunk/include/llvm/ADT/Hashing.h:49,
from /sw/src/clang_llvm_dev/llvm_trunk/include/llvm/ADT/ArrayRef.h:13,
from /sw/src/clang_llvm_dev/llvm_trunk/include/llvm/ADT/APFloat.h:21,
from /sw/src/clang_llvm_dev/clang/include/clang/AST/APValue.h:18,
from /sw/src/clang_llvm_dev/clang/include/clang/AST/Decl.h:17,
from /sw/src/clang_llvm_dev/clang/include/clang/AST/ASTTypeTraits.h:20,
from /sw/src/clang_llvm_dev/clang/include/clang/AST/ASTContext.h:18,
from /sw/src/clang_llvm_dev/clang/include/clang/AST/AST.h:18,
from /sw/src/clang_llvm_dev/clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:15:
...
Why are you passing that argument in the first place? The compiler
completely ignores it.
I sort of assume some library makes use of it, but if so that library
is certainly not required while compiling Clang and is actually
obscure enough that it's not even obvious from Googling. So it's a bit
of a stretch to claim the token is reserved.
I think such "reserved" names like CLS that can be passed to the compiler(s),
should be avoided as identifiers for naming variables, constants, enum
members, macros etc.
Why are you passing that argument in the first place? The compiler
completely ignores it.
CLS stands for cacheline size. It is an important parameter
for optimization of the generated code, at least with gcc/g++.
-DCLS=n should have the same importance like for example -DNDEBUG.
I sort of assume some library makes use of it, but if so that library
is certainly not required while compiling Clang and is actually
obscure enough that it's not even obvious from Googling. So it's a bit
of a stretch to claim the token is reserved.
Yes, it might not be required for the Average Joe user, but that's not me
Let me wish you a Good Morning!...
> Why are you passing that argument in the first place? The compiler
> completely ignores it.
CLS stands for cacheline size. It is an important parameter
for optimization of the generated code, at least with gcc/g++.
-DCLS=n should have the same importance like for example -DNDEBUG.
The GCC source doesn't appear to mention it, and neither does any
documentation I can find. NDEBUG on the other hand is in both the C
and C++ standards.
I still think there's some weird library out there that interprets it
the way you're suggesting, and Clang is not that weird library.
Hey, I'm working on optimization, and I know "it works".
Curious, have you ever heard of "false sharing" and "true sharing"
and what lies behind them?
Hint: it has todo with the cacheline and its size, and memory alignment etc...
Furthermore … in the articles you reference, the -DCLS=$(getconf LEVEL1_DCACHE_LINESIZE) is passed when compiling the user’s program – one doing extensive blocked matrix operations – and not when building the compiler.
Furthermore .. in the articles you reference, the -DCLS=$(getconf LEVEL1_DCACHE_LINESIZE) is passed when compiling the user's program -- one doing extensive blocked matrix operations -- and not when building the *compiler*.
It's worse. At least in the first case, the code looks like it
wouldn't even compile without that definition. That's not an
optimization flag, that's a weird build system.
Furthermore .. in the articles you reference, the -DCLS=$(getconf LEVEL1_DCACHE_LINESIZE) is passed when compiling the user's program -- one doing extensive blocked matrix operations -- and not when building the *compiler*.
It's worse. At least in the first case, the code looks like it
wouldn't even compile without that definition. That's not an
optimization flag, that's a weird build system.
We have a famous saying here over in Germany:
"Wenn man keine Ahnung hat, sollte man besser die Schnauze halten."
Right, but there is nothing inherently significant about the symbol
name CLS. They could have called it MY_SILLY_PARAMETER and it would
have worked equally well. gcc attaches no special significance to
that name. Clang attaches no special significance to that name.
Changing the value of CLS works for the software in the article because
that software is written to make use of a symbol named CLS. That's all.
--paulr
