Hi Olaf, Thank you for your opinion! I think my previous email was not clear enough. My suggestion was/is to have a *default* language standard that is independent of the operating system's default compiler. The language standard can still be changed to C++11, C++14, or C++17. Currently this change is possible by providing -D "__cplusplus=XXXXXXL" as a command line argument or through puma.config. What I do not like about this is that it is not documented (as far as I know) and that it is not as intuitive as a "std=..." command line argument. That is why I suggested adding that command line argument.
Test Bug574 is fixed in current trunk version. Best regards, Simon > 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. >> >> >> >
