Hi Olaf,
Thanks! I did not really think about ag++ because the tests do not use it.
However, ag++ -std=XXX should be sufficient for users (User-friendliness was
the main reason why I found the ac++ "std" argument useful).
Furthermore, thank you for fixing the ExecAdviceNewDelete test.
This makes Bug598 the last failing test on Debian 9 and I am not sure whether
the test will be fixed quickly. As a workaround puma.config can be generated
using "ag++ -std=gnu++98 --gen_config".
Reinhard, all in all, it should be sufficient for you to use the current trunk
version and to add "-std=gnu++98" as ag++ command line argument when
generating puma.config ("ag++ -std=gnu++98 --gen_config").
Best regards,
Simon
> 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.
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
