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. >>> >>> >>> >> > > >
