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.

Reply via email to