CastXML chokes on C++11 constructs in g++-6 headers about castxml

[bradking]

Cc: @thewtex

[bradking]

What is the command line of castxml that is invoked when this error is produced?

[gerddie]

cd /home/scr/Debian/build-area/insighttoolkit4-4.8.2/BUILD/Wrapping/Modules/ITKCommon && /usr/bin/castxml -o /home/scr/Debian/build-area/insighttoolkit4-4.8.2/BUILD/Wrapping/Modules/ITKCommon/vcl_complex.xml --castxml-gccxml --castxml-start _cable_ --castxml-cc-gnu /usr/bin/g++-6 -w -c @/home/scr/Debian/build-area/insighttoolkit4-4.8.2/BUILD/Wrapping/Modules/ITKCommon/castxml.inc /home/scr/Debian/build-area/insighttoolkit4-4.8.2/BUILD/Wrapping/Modules/ITKCommon/vcl_complex.cxx

Exact error is:

In file included from /home/scr/Debian/build-area/insighttoolkit4-4.8.2/BUILD/Wrapping/Modules/ITKCommon/vcl_complex.cxx:1:
In file included from /home/scr/Debian/build-area/insighttoolkit4-4.8.2/Modules/Core/Common/include/itkCommand.h:21:
In file included from /home/scr/Debian/build-area/insighttoolkit4-4.8.2/Modules/Core/Common/include/itkObject.h:31:
In file included from /home/scr/Debian/build-area/insighttoolkit4-4.8.2/Modules/Core/Common/include/itkLightObject.h:21:
In file included from /home/scr/Debian/build-area/insighttoolkit4-4.8.2/Modules/Core/Common/include/itkMacro.h:45:
In file included from /usr/include/c++/6/typeinfo:34:
In file included from /usr/include/c++/6/exception:37:
/usr/include/x86_64-linux-gnu/c++/6/bits/c++config.h:202:11: error: unknown type name 'decltype'
  typedef decltype(nullptr)     nullptr_t;
          ^
/usr/include/x86_64-linux-gnu/c++/6/bits/c++config.h:202:28: error: expected ';' after top level declarator
  typedef decltype(nullptr)     nullptr_t;
                           ^

[thewtex]

I tried reproducing with ITK release branch. The resulting error was:

FAILED: cd /usr/src/ITK-build/Wrapping/Modules/ITKCommon && /usr/src/ITK-build/Wrapping/Generators/CastXML/castxml/bin/castxml -o /usr/src/ITK-build/Wrapping/itkBoundingBox.xml --castxml-gccxml --castxml-start _wrapping_ --castxml-cc-gnu "(" /usr/bin/g++-6 -Wall -Wcast-align -Wdisabled-optimization -Wextra -Wformat=2 -Winvalid-pch -Wno-format-nonliteral -Wpointer-arith -Wshadow -Wunused -Wwrite-strings -funit-at-a-time -Wno-strict-overflow -Wno-deprecated -Wno-invalid-offsetof -Woverloaded-virtual -Wstrict-null-sentinel -msse2 -msse2 ")" -w -c @/usr/src/ITK-build/Wrapping/castxml.inc /usr/src/ITK-build/Wrapping/itkBoundingBox.cxx
<built-in>:293:82: error: typedef redefinition with different types ('struct __castxml_float128' vs '__float128')
typedef struct __castxml_float128 {   char x[16] __attribute__((aligned(16))); } __float128;
                                                                                 ^
1 error generated.

[gerddie]

Well, I was compiling with -j2, so that may be the reason why you hit an error in a different file.

As for __float128, it is available as a GNU extension on some archs. I don't know how castxml works, but if it invokes the g++-6 preprocessor, and since g++-6 defaults to -std=gnu14, this __float128 would already be defined.

[bradking]

The __float128 trouble is because LLVM/Clang, on which CastXML is built, does not implement that particular GNU extension. Since CastXML simulates the preprocessor of the compiler specified with --castxml-cc-gnu then code using __float128 will be seen by the Clang parser within CastXML. In order to avoid an error on the lack of a builtin type, CastXML adds its own preamble that declares __float128 through a typedef to a properly sized and aligned structure. However, it looks like when Clang's GNU extensions are enabled in C++11 mode or higher (e.g. -std=gnu++11 or -std=gnu++14) then Clang does its own workaround to tolerate __float128 during parsing. The two workarounds are conflicting with each other. I still need to dig in further to figure out the proper fix for this.

[bradking]

After some refactoring commits, commit 1414278 fixes the __float128 problem for -std=gnu++{11,14} modes. Then commit fc71eb9 updates the test suite to run all gccxml output tests with GNU extension modes (in addition to the existing standard modes).

[bradking]

Returning to the issue originally reported here, I'm not able to reproduce it. I have package g++-6 version 6-20160117-1 installed on a Debian VM. The castxml runs work, e.g.

cd /.../ITK-build/Wrapping/Modules/ITKCommon && /.../CastXML-build/root/bin/castxml -o /.../ITK-build/Wrapping/Modules/ITKCommon/vcl_complex.xml --castxml-gccxml --castxml-start _cable_ --castxml-cc-gnu /usr/bin/g++-6 -w -c @/.../ITK-build/Wrapping/Modules/ITKCommon/castxml.inc /.../ITK-build/Wrapping/Modules/ITKCommon/vcl_complex.cxx

The only way I've been able to produce the decltype error shown is by running castxml with

--castxml-cc-gnu /usr/bin/g++-6 -std=c++98

This causes the preprocessor to run with __cplusplus=201402L but the parser to be configured in C++98 mode due to the explicit request. That causes code in c++config.h:

#if __cplusplus >= 201103L
  typedef decltype(nullptr)     nullptr_t;
#endif

to break because it requires a C++11 mode parser.

@gerddie, does the file

/home/scr/Debian/build-area/insighttoolkit4-4.8.2/BUILD/Wrapping/Modules/ITKCommon/castxml.inc

have any -std= flag in it? That's the only other place it could appear since it is not shown on the command line.

[gerddie]

I have the same package version installed, but I haven't updated castxml yet, I suppose the your changes don't influence the general C++ standard handling, so the following tests should still be valid.

The file in question doesn't contain any -std flags. Now, I did play with this a little.
When I add -std=c++98 or -std=c++03 I get the same error.
When I add *-std=c++11" the error changes, I get an error

/usr/includde/c++/6/complex:1943:13: error expected identifier 
  operator""if(long double __num)

/usr/includde/c++/6/complex:1947:13: error expected identifier
operator""if(unsigned long long __num)

and later on

/usr/includde/c++/6/bits/std_algo.h:3359:7: error: statement not allowed in constexpr function 
  while (__first != __last) 

This is a C++14 thingy, i.e. there, constexpr can contain fixed length loops, with c++11 this was not allowed.

Now with -std=c++14, castxml simply stops telling my that it doesn't support this.

Castxml is in Debian is currently 0.1-g8a08a44 and is based on llvm-3.6.2 (although llvm-3.7 is packaged).

[bradking]

Thanks. Using --castxml-cc-gnu /usr/bin/g++-6 tells CastXML to preprocess the translation unit with the same predefines as g++-6 uses. By default CastXML will check the target compiler's __cplusplus value to determine the standard level automatically to use for parsing. Using -std=... overrides this default with an explicit choice. If one explicitly specifies an older standard than is preprocessed then these kind of errors are expected.

The question here is: Why does this mismatch in -std selection occur when ITK's build invokes CastXML? Is an explicit -std= flag being passed somewhere? If you run the whole command line by hand, add -### to see CastXML's internal invocation arguments for the Clang parser. That should show the -std= argument that it uses. I get -std=gnu++14.

Now with -std=c++14, castxml simply stops telling my that it doesn't support this.

That's because it does support C++14 parsing if not told to parse as an older standard. Of course since CastXML is built on LLVM/Clang its parsing is limited to the language levels supported by the version of Clang against which it is built.

[bradking]

Castxml is in Debian is currently 0.1-g8a08a44

That explains it. I tested with 0.1+git20150807-1+b1 (Git version 8a08a44) and got the same result as here. This has been fixed in CastXML 'master' with commit c6562e5 (for -std= detection) and commit 7acd634 (for -std=c++14 support).

[gerddie]

Okay, I'll get back to you when I have gotten around to test the current master/HEAD, thanks.

[gerddie]

Okay, with master/head the initially reported error doesn't show up.

[bradking]

with master/head the initially reported error doesn't show up.

Great, thanks. I'll close the issue here. Debian's castxml package should be updated to our current 'master' to get all the changes discussed above.