POD struct

The following simple program creates a variable length array of structures:

//template<typename T>
class Test {
  struct toto {
    int* x;

  void method(int nb) {
    toto ary[nb];
    for(int i = 0; i < nb; ++i)
      ary[i].x = 0;

int main(int argc, char* argv) {
  //Test<char> t;
  Test t;

  return 0;

In compiles properly as written with clang++ (version 3.0). When
uncommeting the templated version, then the compiler complains:

POD.cc:9:13: error: variable length array of non-POD element type
    toto ary[nb];

It does not seem right. 'struct toto' still looks like a POD. Why
isn't it one anymore?

As a side note, g++ compiles this code without complaining.

Thank you for your time,

Looks like a bug; please file at llvm.org/bugs/ .



I am interested in clang development and this seemed like an easy enough bug to start with so I thought I would try it out. I have managed to get llvm checked out and building without problems. I found the tests and have turned the above example into a test in a new file test/SemaCXX/inner-pod-struct.cpp.

Unfortunately, I cannot figure out how to use lit.py properly. I have looked at


but am a bit confused as it refers to non-existant files in several places. In particular,

python (path to llvm)\llvm\utils\lit\lit.py -sv

–param=build_mode=Win32 --param=build_config=Debug

–param=clang_site_config=(build dir)\tools\clang\test\lit.site.cfg

(path to llvm)\llvm\tools\clang\test(dir)(test)

is giving me trouble. On my machine, ~/dev/llvm is the llvm checkout and ~/dev/llvm-build is the build dir.

boots@eiji:~/dev/llvm-build$ find . -name lit.site.cfg


Kind of a bust there, what about the llvm dir?

boots@eiji:~/dev/llvm$ find . -name lit.site.cfg




Something at least.

boots@eiji:~/dev/llvm-build$ python ~/dev/llvm/utils/lit/lit.py --param=clang_site_config=…/llvm/./utils/lit/lit/ExampleTests/LLVM.OutOfTree/obj/test/lit.site.cfg /Users/boots/dev/llvm/tools/clang/test/

– Testing: 1 tests, 4 threads –

PASS: LLVM :: Foo/pct-S.ll (1 of 1)

Testing Time: 0.28s

Expected Passes : 1

But wait, that ran entirely the wrong tests?

boots@eiji:~/dev/llvm$ find . -name pct-S.ll


… Time passes while I hack and compose this email …

I discover that:

boots@eiji:~/dev/llvm-build$ cd tools/clang/

boots@eiji:~/dev/llvm-build/tools/clang$ make test

Making Clang ‘lit.site.cfg’ file…

Making Clang ‘Unit/lit.site.cfg’ file…

oots@eiji:~/dev/llvm-build/tools/clang/test$ python ~/dev/llvm/utils/lit/lit.py --param=clang_site_config=lit.site.cfg ~/dev/llvm/tools/clang/test/SemaCXX/inner-pod-struct.cpp

lit.py: lit.cfg:175: note: using clang: ‘/Users/boots/dev/llvm-build/Release+Asserts/bin/clang’

– Testing: 1 tests, 4 threads –

FAIL: Clang :: SemaCXX/inner-pod-struct.cpp (1 of 1)

Testing Time: 0.28s

Failing Tests (1):

Clang :: SemaCXX/inner-pod-struct.cpp

Unexpected Failures: 1

Is the incantation I need.

Can we expand the testing page slightly to include mention that you have to run make test in the build/tools/clang directory to generate the cfg files?


Patch welcome. (The relevant webpage is www/hacking.html in a clang checkout.)



Thanks for the pointer to the right place. A patch is attached.


hacking.patch (1.08 KB)

It's probably worth pointing out that 'make test' will run all the tests by default. You only need to do this if you're trying to run a single test.


Sure, the revised patch includes a note that it is ok to control+c the process once the tests have started running.


hacking.patch (1.26 KB)

In general, if you're just fixing a bug, it's better to look for an existing test file that tests the greater functionality, and then add a test case for the bug there. In this case, there should be a file with test cases for VLAs in C++ somewhere; the test cases for this bug should be added there.


Thanks Matt for working on this bug. As suggested, I submitted a bug
report on bugzilla. It has ID 12524.