Hi! It is really the case that with C++11 the exception specifications have been removed. See the following discussion, for instance:
https://stackoverflow.com/questions/39188919/different-exception-specifier-with-g-6-2 This means that gcc 6 is right to complain about the test code. However, it is not the weaver's fault but that of the test code. We could check the language standard within ExecAdviceNewDelete/main.cc by using some #if and compile the exception specifications only for C++98/03. BTW, this is also the reason why ExecAdviceNewDelete fails in Akut on the Windows platform. It is the only one that already uses g++-6. - Olaf On 08/31/2017 15:47, Olaf Spinczyk wrote: > Hi Simon, > > I already suspected that I should think longer about this. ;-) > > I agree that the interface of ac++ for configuring the language standard > is not very convenient. However, it avoids redundancy. The __cplusplus > macro would have to be defined in puma.config anyway. Defining the > remaining parts of puma.config manually is either not convenient. > > If you use ag++, everything should work smoothly at the moment: > Depending on the gcc version and its default language standard, the > __cplusplus macro is defined in puma.config. If the project's source > code is written for some other standard, ag++ would be called with > -std=c++<year> and the __cplusplus macro would be generated accordingly. > > If we had a -std option in ac++, ag++ would have to be changed as well. > > In summary: I might be missing something, but still don't see the point > in that new option. > > - Olaf > > > On 08/31/2017 15:32, "Simon Schröder" wrote: >> 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. >>>> >>>> >>>> >>> >> >> >> > _______________________________________________ > aspectc-developers mailing list > aspectc-develop...@aspectc.org > http://aspectc.org/listinfo/aspectc-developers >
