Test suite additions request

Hi there.

I'm writing this in the hope that my projects could find their way into some clang test suite.

I've got several packages in SourceForge: v3c, treedb, meta-treedb are the ones relevant here.
Each builds on the one before, a kind of software stack.

Because I'm (or rather gcc/g++ 4.6) is having problems,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630441
"g++-4.6 miscompilation", I've started to explore other compilers to find out more.

The first thing I noticed was that clang(++) isn't flag-for-flag compatible with gcc/g++ -
there's no -dD to list the preprocessor symbols hard-wired into the compiler.
I figured out from web pages that I could check for __clang__.

Next I noticed that clang(++) doesn't support __attribute__((ms_abi)), gcc's way of saying Pascal calling
convention, in which the callee pops the stack - I think my code is smaller and faster with it.

Next I noticed that clang doesn't understand "extern inline int fn() __attribute((always_inline));",
, followed by "extern inline int fn() { return 1; }" which means
"never put this function in an object file, always expand".

I think I've peeled the onion as far as I can when I encountered
"/usr/include/c++/4.5/exception_ptr.h:132:13: error: unknown type name 'type_info'" after
"#include <typeinfo>".

I've found a few places where I need to make corrections already because of clang, and I'd be happy
to to-fro with someone to get (mainly meta-treedb) to build (it does, with corrections) and pass
"make check" (it doesn't, because of that typeinfo problem).

If this can help track down the gcc/g++ 4.6 problem, so much the better.

All my projects build/check fine with Debian gcc/g++ 4.4.6-8.

Regards,
Philip Ashmore

Hi there.

I'm writing this in the hope that my projects could find their way into
some clang test suite.

I've got several packages in SourceForge: v3c, treedb, meta-treedb are
the ones relevant here.
Each builds on the one before, a kind of software stack.

Because I'm (or rather gcc/g++ 4.6) is having problems,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630441
"g++-4.6 miscompilation", I've started to explore other compilers to
find out more.

The first thing I noticed was that clang(++) isn't flag-for-flag
compatible with gcc/g++ -
there's no -dD to list the preprocessor symbols hard-wired into the
compiler.
I figured out from web pages that I could check for __clang__.

clang supports -dM. Haven't seen anyone use -dD.

Next I noticed that clang(++) doesn't support __attribute__((ms_abi)),
gcc's way of saying Pascal calling
convention, in which the callee pops the stack - I think my code is
smaller and faster with it.

Hmm... could be useful, I guess (although I can't imagine it's
substantially faster); feel free to file at llvm.org/bugs/

Next I noticed that clang doesn't understand "extern inline int fn()
__attribute((always_inline));",
, followed by "extern inline int fn() { return 1; }" which means
"never put this function in an object file, always expand".

http://clang.llvm.org/compatibility.html#inline

I think I've peeled the onion as far as I can when I encountered
"/usr/include/c++/4.5/exception_ptr.h:132:13: error: unknown type name
'type_info'" after
"#include <typeinfo>".

Known bug in the header; I think there's a clang bug somewhere to add
a compatibility hack.

-Eli

Next I noticed that clang(++) doesn't support __attribute__((ms_abi)),
gcc's way of saying Pascal calling
convention, in which the callee pops the stack - I think my code is
smaller and faster with it.

In general, the impact is relatively small. clang will accumulate stack
space used for arguments to a degree. You can use the fastcall attribute
for a very similar effect, if you really care.

Next I noticed that clang doesn't understand "extern inline int fn()
__attribute((always_inline));",
, followed by "extern inline int fn() { return 1; }" which means
"never put this function in an object file, always expand".

extern inline is an old GCCism. Look up the C99 inline syntax for
getting the same effect.

Joerg

Hi there.

I'm writing this in the hope that my projects could find their way into
some clang test suite.

I've got several packages in SourceForge: v3c, treedb, meta-treedb are
the ones relevant here.
Each builds on the one before, a kind of software stack.

Because I'm (or rather gcc/g++ 4.6) is having problems,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630441
"g++-4.6 miscompilation", I've started to explore other compilers to
find out more.

The first thing I noticed was that clang(++) isn't flag-for-flag
compatible with gcc/g++ -
there's no -dD to list the preprocessor symbols hard-wired into the
compiler.
I figured out from web pages that I could check for __clang__.

clang supports -dM. Haven't seen anyone use -dD.

-dD works. You just have to pass the right command line arguments. Something like this:

  clang -dD -E -xc /dev/null

Next I noticed that clang(++) doesn't support __attribute__((ms_abi)),
gcc's way of saying Pascal calling
convention, in which the callee pops the stack - I think my code is
smaller and faster with it.

Hmm... could be useful, I guess (although I can't imagine it's
substantially faster); feel free to file at llvm.org/bugs/

I already filed PR9148 (http://llvm.org/PR9148). With some projects, it's not only useful; it's required. Wine on 64-bit needs this to work at all, for example.

Chip