Hi Tom, > Le 9 oct. 2021 à 21:31, Tom Shields <[email protected]> a écrit > : > > Akim, > > I thought you might be interested in the results of portability testing for > the Ox 1.10 release (available yesterday).
Yes, I am. Thanks a lot for this effort! > Ox 1.10 has 6 parsers generated by bison 3.8.2, using the glr2.cc skeleton. > > For portability testing, I run the regression tests on each operating systems > using each C++ compiler listed below. This is great! > The Solaris Studio errors noted below are due to a defect in support for the > C++ 2011: a noexcept operator within a noexcept specifier for an overloaded > version of std::swap in several header files is the source of the error > messages above. The exact same signature is found in the equivalent GNU & > LLVM header files. As an experiment (on Solaris 11.4), I edited the > offending signature in the header files to bypass the problem, which allowed > Ox to compile. Ox then failed to link due to several versions of the C++ > std::ostream '<<' operator missing from the C++ library. Is this a problem? I'd rather avoid having to work around portability issues of C++11 :( I know by experience how much effort portability requires. > - Homebrew GNU C++ 11.2: compile warnings for each parser: > agc-Lfile.cc:2711:16: warning: 'AGC::lexer::glr_stack' has a field > 'AGC::lexer::glr_stack::yyerror_range' whose type uses the anonymous > namespace [-Wsubobject-linkage] > agc-Lfile.cc:2711:16: warning: 'AGC::lexer::glr_stack' has a field > 'AGC::lexer::glr_stack::yystateStack' whose type uses the anonymous namespace > [-Wsubobject-linkage] I am unable to reproduce it on the "Several parsers" test in the test suite (after having added -Wsubobject-linkage to the list of warning flags to use). I used g++-mp-11 (MacPorts gcc11 11.2.0_1) 11.2.0. But I can see the configuration. Indeed we define the glr_stack class in a named namespace, but in the *.cc file only, and glr_stack uses glr_stack_item, which is defined in the same *.cc, but within an unnamed namespace. I can see why in general this is dangerous, but in the present case, I don't see how it could go wrong: every bit is in the same *.cc file. We could define glr_stack_item in a named namespace (since it is my understanding Tom that you no longer try to have several parsers in the same namespace), but it still annoys me because I was happy to limit the number of visible symbols exposed by the compilation unit. In order to help speeding up linking. Cheers!
