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
> <[email protected]> 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.
