Hi! No. Please don't commit the fixes. I have implemented C++14 support in ag++ and ac++ for good reasons. If ac++ is configured to internally use the C++98 standard (always), it will not be able to handle programs that make use of C++11/14/17 extensions. For instance, we wouldn't be able to compile Qt 5.x applications anymore!
If a test only works with a specific language standard, we can configure that in its Makefile, e.g.: ACFLAGS ?= -D "__cplusplus=201103L" CXXFLAGS ?= -std=c++11 include ../Makefile.generic However, normally the tests should work with C++98 *and* C++14, i.e. older gccs und gcc >= 6. For the ExecAdviceNewDelete we should implement different handling for the two cases in the weaver. However, first we have to verify that the signature really changed. That would be quite strange. tests/Bug574 should of course be fixed. Cheers, Olaf On 08/31/2017 14:23, "Simon Schröder" wrote: > Hi Reinhard, > > I am able to reproduce the failing tests. The source of the problems is that > starting with gcc-6.0 the default language standard is gnu++14 (instead of > gnu++98) (see [1]). When using an operating system that has gcc >= 6.0 as > system compiler (e.g. debian 9), this leads to two problems: > > 1) Because Ag++ uses the system compiler without specifying a language > standard to generate puma.config, puma.config contains the line > -D "__cplusplus=201402L" (C++14) instead of -D "__cplusplus=199711L" (C++98). > This line causes AspectC++ to set the standard language of the internal Clang > compiler instance to C++14 (-std=c++14). In c++14 mode Clang behaves different > which leads to a different AspectC++ repo and to different woven code. In case > of Bug598 "different" means wrong (see [2]). In case of ExecAdviceNewDelete > "different" means that C++11 code is generated (which cannot be compiled using > g++ in non-C++11 mode). > > 2) When executing the tests, the woven code is compiled using the system > compiler without specifying a language standard. Due to this, g++ with > implicit -std=gnu++14 is used to compile the woven code. This makes > ExecAdviceNewDelete fail, because g++ does not like "void *operator new > (size_t ) throw(std::bad_alloc);" in gnu++14 mode (probably because > "throw(std::bad_alloc)" is deprecated in C++11). On the other hand, clang++ in > gnu++14 mode does not complain, so this might be a g++ issue. > > To fix 1), AspectC++ should use gnu++98 as default (as on operating systems > with gcc < 6.0). To accomplish this, either ag++ has to explicitly set gnu++98 > while generating puma.config or AspectC++ has to ignore -D "__cplusplus=XXXX" > and provide an own mechanism to set the language standard that should be used > for parsing and code generation. I would recommend the latter and would add a > new command line argument "--std" to AspectC++ whose default value is > "gnu++98" and which could look like the following: > ... > -c|--compile <arg> Name of the input file > -o|--output <arg> Name of the output file > --std <arg> Language standard used for parsing and code > generation > -i|--include_files Generate manipulated header files > ... > > To fix 2), the woven test code should be compiled using gnu++98 regardless of > the system compiler's default language standard, because the tests were > written on the supposition that gnu++98 is used. Of course tests can > explicitly change the language standard if they rely on C++11 or C++14 > (e.g. using "--std c++11"). > > Test Bug574 is "just" indeterminate behavior because the value of an > uninitialized member is used in an if-clause. > > I already created commits for my recommended fixed and if no one has > objections, I would push them. What do you think? Olaf, what is your > opinion? > > Best regards, > > Simon > > > [1] https://gcc.gnu.org/gcc-6/changes.html > [2] > template <typename TResult, typename TEntity> > __attribute__((always_inline)) inline TResult __Get__Z4mainv_1_0 (TEntity > &ent, AC::RT<TResult>){ > typedef TJP__Z4mainv_1_0< const TResult, void, void, const char [2], > AC::DILE, AC::TLE > __TJP; > const TResult __result_buffer; > AC::invoke_Bar_Bar__a0_before<__TJP> (); > __result_buffer = ::arr; > return (const TResult &)__result_buffer; > } > int main() { > char x = __Get__Z4mainv_1_0< > (arr[1], __AC_TYPEOF((arr[1])) ); > return 0; > } > > instead of > > template <typename TResult, typename TEntity, unsigned int TDim0, typename > TIdx0> > __attribute__((always_inline)) inline TResult __Get__Z4mainv_1_0 (TEntity > (&base)[TDim0], TIdx0 > idx0, AC::RT<TResult>){ > typedef TJP__Z4mainv_1_0< TResult, void, void, char, AC::DIL< 2, int, > AC::DILE >, AC::TLE > > __TJP; > TResult __result_buffer; > AC::invoke_Bar_Bar__a0_before<__TJP> (); > __result_buffer = ::arr[idx0]; > return (TResult &)__result_buffer; > } > int main() { > char x = __Get__Z4mainv_1_0< > (arr, (1), __AC_TYPEOF((arr[1])) ); > return 0; > } > > >> I've uploaded a new package that simply ignores failures from tests. Not >> exactly an ideal >> situation because it renders the test ineffective. >> >> From what I understand I could instead dialer disable these the tests >> instead. But before doing >> that, I wanted to check with you if these failures also occurred on your >> akut Test infrastructure. >> If yes, how do you deal with them, maybe you could disable the test in svn. >> If they do not appear >> in akut, I wonder why. >> >> I agree that it's not super critical or urgent to me, but I think you are in >> a much per position >> to assess the criticality and urgency. >> >> Thanks >> Reinhard >> >> On August 29, 2017 12:19:21 PM EDT, Olaf Spinczyk >> <olaf.spinc...@tu-dortmund.de> wrote: >>> Hi Reinhard! >>> >>> We should definitely look into these three problems within the next few >>> weeks, but I don't regard them as very critical, because they affect >>> only special use cases: Advice for user-defined "operator new" >>> implementations and the code generation for get/set advice, which is a >>> feature that is only enabled with --data_joinpoints and still a bit >>> experimental. >>> >>> How to proceed? Can we/you live with these problems for now and update >>> later or is there no update option and we have to fix it sooner? >>> >>> Cheers, >>> >>> Olaf >>> >>> On 08/24/2017 00:16, Reinhard Tartler wrote: >>>> >>>> >>>> On 08/23/2017 12:07 PM, Olaf Spinczyk wrote: >>>>> Hi! >>>>> >>>>> You can generate the config file easily with ag++ --gen_config. >>> Sorry >>>>> for the inconvenience. The background is that when I wrote the first >>>>> ac++ tests, I did not want the makefile to depend on ag++. >>>>> >>>>> We should change that sooner or later, because it is obviously >>> confusing. >>>> >>>> Not a problem. >>>> >>>> Progress! With a "correct" PUMA CONFIG, I now get further, but there >>> seem to be >>>> genuine test failures. Are they concerning or shall I ignore them for >>> the debian >>>> package? >>>> >>>> They look like this: >>>> >>>> /usr/bin/make -C tests -s all >>>> make[2]: Entering directory >>>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests' >>>> >>> ...........................................[C:ExecAdviceNewDelete].................................................................................[D:Bug574].......[C:Bug598]........ >>>> >>>> >>>> +---------+ >>>> |ERRORS: | >>>> +---------+ >>>> >>>> >>> ----------------------------------------------------------------------------- >>>> TEST: ExecAdviceNewDelete >>>> >>> ----------------------------------------------------------------------------- >>>> STDOUT: >>>> -------- >>>> make[3]: Entering directory >>>> >>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/ExecAdviceNewDelete' >>>> Weaving main.cc >>>> * Running ac++ 2.2 >>>> * Handling Translation Unit `main.cc'. >>>> - Path "main.cc" >>>> - Parsing ... >>>> - Weaving Aspects Forward Declarations ... >>>> - Inserting namespace AC >>>> - Committing >>>> - Preparing introductions ... >>>> - Parsing again ... >>>> - Weaving access control bypass classes ... >>>> - Weaving Join Points ... >>>> Advicecode manipulation >>>> Collecting Advice >>>> Setting up thisJoinPoint for aspectof >>>> Create pointcut expression tree >>>> Matching joinpoints >>>> Aspect ordering ... >>>> Creating project repository 'repo.acp' >>>> Type Check Functions >>>> Access Join Points >>>> Execution Join Points >>>> void *operator new(unsigned long int) >>>> void *operator new[](unsigned long int) >>>> void operator delete(void *) >>>> void operator delete[](void *) >>>> void A::operator delete(void *) >>>> void *C::operator new(unsigned long int) >>>> void C::operator delete(void *) >>>> Construction Join Points >>>> Destruction Join Points >>>> - Aspect Includes ... >>>> - Final cleanup >>>> - Committing >>>> * Inserting unit pro- and epilogues >>>> - Manipulating translation unit file main.cc >>>> * Updating #line directives of generated code fragments >>>> * Saving >>>> - Expanding project includes >>>> - Fixing #line directives >>>> - Path "main.acc" >>>> * Done >>>> Compiling main.acc >>>> ../Makefile.generic:80: recipe for target 'Junk/main.o' failed >>>> make[3]: Leaving directory >>>> >>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/ExecAdviceNewDelete' >>>> >>>> STDERR: >>>> -------- >>>> main.cc:5:30: warning: dynamic exception specifications are >>> deprecated in C++11 >>>> [-Wdeprecated] >>>> void *operator new (size_t ) throw(std::bad_alloc); >>>> ^~~~~ >>>> main.cc:7:31: warning: dynamic exception specifications are >>> deprecated in C++11 >>>> [-Wdeprecated] >>>> void *operator new (size_t s) throw(std::bad_alloc) { >>>> ^~~~~ >>>> main.cc: In function 'void* operator new(size_t)': >>>> main.cc:7:7: error: declaration of 'void* operator new(size_t) throw >>>> (std::bad_alloc)' has a different exception specifier >>>> void *operator new (size_t s) throw(std::bad_alloc) { >>>> ^~~~~~~~ >>>> main.cc:5:7: note: from previous declaration 'void* operator >>> new(std::size_t)' >>>> void *operator new (size_t ) throw(std::bad_alloc); >>>> ^~~~~~~~ >>>> main.acc: In function 'void* operator new(std::size_t)': >>>> main.acc:147:61: warning: dynamic exception specifications are >>> deprecated in >>>> C++11 [-Wdeprecated] >>>> typedef TJP__Znwm_0< void *, void, void, void *(::size_t) >>>> throw(std::bad_alloc), AC::TL< ::size_t, AC::TLE > > __TJP; >>>> ^~~~~ >>>> main.cc: At global scope: >>>> main.cc:11:33: warning: dynamic exception specifications are >>> deprecated in C++11 >>>> [-Wdeprecated] >>>> void *operator new[] (size_t s) throw(std::bad_alloc) { >>>> ^~~~~ >>>> main.acc: In function 'void* operator new [](std::size_t)': >>>> main.acc:198:61: warning: dynamic exception specifications are >>> deprecated in >>>> C++11 [-Wdeprecated] >>>> typedef TJP__Znam_0< void *, void, void, void *(::size_t) >>>> throw(std::bad_alloc), AC::TL< ::size_t, AC::TLE > > __TJP; >>>> ^~~~~ >>>> make[3]: *** [Junk/main.o] Error 1 >>>> >>>> >>>> >>> ----------------------------------------------------------------------------- >>>> TEST: Bug574 >>>> >>> ----------------------------------------------------------------------------- >>>> STDOUT: >>>> -------- >>>> make[3]: Entering directory >>>> >>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/Bug574' >>>> Weaving main.cc >>>> * Running ac++ 2.2 >>>> * Handling Translation Unit `main.cc'. >>>> - Path "main.cc" >>>> - Parsing ... >>>> - Weaving Aspects Forward Declarations ... >>>> - Inserting namespace AC >>>> - Committing >>>> - Preparing introductions ... >>>> - Parsing again ... >>>> - Weaving access control bypass classes ... >>>> - Weaving Join Points ... >>>> Advicecode manipulation >>>> Collecting Advice >>>> Setting up thisJoinPoint for aspectof >>>> Create pointcut expression tree >>>> Matching joinpoints >>>> Aspect ordering ... >>>> Creating project repository 'repo.acp' >>>> Type Check Functions >>>> Access Join Points >>>> Get: bool Cyg_SchedThread::priority_inherited >>>> Get: int Cyg_SchedThread::original_priority >>>> Execution Join Points >>>> Construction Join Points >>>> Destruction Join Points >>>> - Aspect Includes ... >>>> - Final cleanup >>>> - Committing >>>> * Inserting unit pro- and epilogues >>>> - Manipulating translation unit file main.cc >>>> * Updating #line directives of generated code fragments >>>> * Saving >>>> - Expanding project includes >>>> - Fixing #line directives >>>> - Path "main.acc" >>>> * Done >>>> Compiling main.acc >>>> Linking >>>> make[3]: Leaving directory >>>> >>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/Bug574' >>>> make[3]: Entering directory >>>> >>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/Bug574' >>>> 1a2 >>>>> int Cyg_SchedThread::original_priority >>>> ../Makefile.generic:48: recipe for target 'diff' failed >>>> make[3]: Leaving directory >>>> >>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/Bug574' >>>> >>>> STDERR: >>>> -------- >>>> make[3]: *** [diff] Error 1 >>>> >>>> >>>> >>> ----------------------------------------------------------------------------- >>>> TEST: Bug598 >>>> >>> ----------------------------------------------------------------------------- >>>> STDOUT: >>>> -------- >>>> make[3]: Entering directory >>>> >>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/Bug598' >>>> Weaving main.cc >>>> * Running ac++ 2.2 >>>> * Handling Translation Unit `main.cc'. >>>> - Path "main.cc" >>>> - Parsing ... >>>> - Weaving Aspects Forward Declarations ... >>>> - Inserting namespace AC >>>> - Committing >>>> - Preparing introductions ... >>>> - Parsing again ... >>>> - Weaving access control bypass classes ... >>>> - Weaving Join Points ... >>>> Advicecode manipulation >>>> Collecting Advice >>>> Setting up thisJoinPoint for aspectof >>>> Create pointcut expression tree >>>> Matching joinpoints >>>> Aspect ordering ... >>>> Creating project repository 'repo.acp' >>>> Type Check Functions >>>> Access Join Points >>>> Get: char const arr[2] >>>> Execution Join Points >>>> Construction Join Points >>>> Destruction Join Points >>>> - Aspect Includes ... >>>> - Final cleanup >>>> - Committing >>>> * Inserting unit pro- and epilogues >>>> - Manipulating translation unit file main.cc >>>> * Updating #line directives of generated code fragments >>>> * Saving >>>> - Expanding project includes >>>> - Fixing #line directives >>>> - Path "main.acc" >>>> * Done >>>> Compiling main.acc >>>> ../Makefile.generic:80: recipe for target 'Junk/main.o' failed >>>> make[3]: Leaving directory >>>> >>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/Bug598' >>>> >>>> STDERR: >>>> -------- >>>> main.acc: In instantiation of 'TResult __Get__Z4mainv_1_0(TEntity&, >>> AC::RT<T>) >>>> [with TResult = char; TEntity = const char]': >>>> main.cc:16:66: required from here >>>> main.acc:283:17: error: uninitialized const '__result_buffer' >>> [-fpermissive] >>>> const TResult __result_buffer; >>>> ^~~~~~~~~~~~~~~ >>>> main.acc:285:19: error: assignment of read-only variable >>> '__result_buffer' >>>> __result_buffer = ::arr; >>>> ~~~~~~~~~~~~~~~~^~~~ >>>> main.acc:285:19: error: invalid conversion from 'const char*' to >>> 'char' >>>> [-fpermissive] >>>> make[3]: *** [Junk/main.o] Error 1 >>>> >>>> Makefile:161: recipe for target 'all' failed >>>> make[2]: *** [all] Error 1 >>>> make[2]: Leaving directory >>>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests' >>>> Makefile:259: recipe for target 'testall' failed >>>> make[1]: *** [testall] Error 2 >>>> make[1]: Leaving directory >>>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++' >>>> debian/rules:52: recipe for target 'test-builds' failed >>>> >> >> -- >> Sent from my cell phone. Please excuse my brevity and typos. > > >
