Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7

[Olaf Spinczyk]

Hi!

Do you have any idea why the test "Bug598" fails? You seem to have
looked into it already.

- Olaf

On 08/31/2017 18:28, "Simon Schröder" wrote:
> 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++ 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=XXL" 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

Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7

[Simon Schröder]

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++ 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=XXL" 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 

Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7

[Olaf Spinczyk]

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++ 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=XXL" 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.

 

Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7

[Olaf Spinczyk]

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++ 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=XXL" 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="
>>> 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  Name of the input file
>>>  -o|--output   Name of the output file
>>>  --std Language standard used for parsing and code 
>>> generation
>>>  -i|--include_files Generate manipulated 

Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7

[Simon Schröder]

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=XXL" 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="
>> 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  Name of the input file
>>  -o|--output   Name of the output file
>>  --std 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 
>>   __attribute__((always_inline)) inline TResult __Get__Z4mainv_1_0 (TEntity 
>> ,
>> AC::RT){
>> 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> 

Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7

[Olaf Spinczyk]

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="
> 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  Name of the input file
>  -o|--output   Name of the output file
>  --std 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 
>   __attribute__((always_inline)) inline TResult __Get__Z4mainv_1_0 (TEntity 
> , AC::RT){
> 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  TIdx0>
>   __attribute__((always_inline)) inline TResult __Get__Z4mainv_1_0 (TEntity 
> ()[TDim0], TIdx0
> idx0, AC::RT){
> 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 

Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7

[Simon Schröder]

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="
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  Name of the input file
 -o|--output   Name of the output file
 --std 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 
  __attribute__((always_inline)) inline TResult __Get__Z4mainv_1_0 (TEntity 
, AC::RT){
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 
  __attribute__((always_inline)) inline TResult __Get__Z4mainv_1_0 (TEntity 
()[TDim0], TIdx0
idx0, AC::RT){
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 
>  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 

Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7

[Reinhard Tartler]

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

Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7

[Olaf Spinczyk]

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< 

Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7

[Reinhard Tartler]

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 

Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7

[Olaf Spinczyk]

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.

Cheers,

Olaf


On 08/23/2017 17:57, Reinhard Tartler wrote:
> 
> 
> On 08/23/2017 04:29 AM, Olaf Spinczyk wrote:
>> Hi Reinhard,
>>
>> when trying to compile the tests, ac++ seems to have no (or an invalid)
>> puma.config file. It doesn't find the system header files, e.g. stdio.h
>> and iostream. For 'make test' to succeed PUMA_CONFIG must point to a
>> valid config file. Are you sure that there is one? Where do you set the
>> environment variable? I haven't seen it in the log.
> 
> 
> I think what confused me is that the build did succeed for release 2.2.
> Here is the old buildlog:
> https://buildd.debian.org/status/fetch.php?pkg=aspectc%2B%2B=amd64=1%3A2.2-1=1490665251=0
> 
> The difference is that in release 2.2, failures in the test suite were
> ignored. Now they are causing the build to fail.
> 
> I'm a bit surprised that invoking the testsuite doesn't handle
> puma.config generation by itself and requires the caller to take care of
> that. But I can certainly look into that.
> 
> I'll try that out and report back.
> 
> Thanks guys!
> -rt
> 

Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7

[Reinhard Tartler]

On 08/23/2017 04:29 AM, Olaf Spinczyk wrote:
> Hi Reinhard,
> 
> when trying to compile the tests, ac++ seems to have no (or an invalid)
> puma.config file. It doesn't find the system header files, e.g. stdio.h
> and iostream. For 'make test' to succeed PUMA_CONFIG must point to a
> valid config file. Are you sure that there is one? Where do you set the
> environment variable? I haven't seen it in the log.


I think what confused me is that the build did succeed for release 2.2.
Here is the old buildlog:
https://buildd.debian.org/status/fetch.php?pkg=aspectc%2B%2B=amd64=1%3A2.2-1=1490665251=0

The difference is that in release 2.2, failures in the test suite were
ignored. Now they are causing the build to fail.

I'm a bit surprised that invoking the testsuite doesn't handle
puma.config generation by itself and requires the caller to take care of
that. But I can certainly look into that.

I'll try that out and report back.

Thanks guys!
-rt

Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7

[Olaf Spinczyk]

Hi Reinhard,

when trying to compile the tests, ac++ seems to have no (or an invalid)
puma.config file. It doesn't find the system header files, e.g. stdio.h
and iostream. For 'make test' to succeed PUMA_CONFIG must point to a
valid config file. Are you sure that there is one? Where do you set the
environment variable? I haven't seen it in the log.

Cheers,

Olaf

On 08/23/2017 04:32, Reinhard Tartler wrote:
> Hi Simon,
> 
> no worries, and thank you so much for your prompt response. I did try to
> update the package, and with your changes, and I got even past the part
> that weaves Puma, which is great!
> 
> Unfortunately, the test suite fails to run. Did you try this as well?
> For your convenience, I've attached the buildlog of my testbuild.
> 
> Can you confirm the test case failures?
> 
> Again, thanks for your swift response!
> 
> Reinhard
> 
> On 08/22/2017 02:43 PM, "Simon Schröder" wrote:
>> Hi Reinhard,
>>
>> Building AspectC++ using the Debian clang-4.0 package should work now.
>> Please
>> use the current AspectC++ trunk version. Sorry for the inconveniences!
>>
>> The problem was that the linker arguments that point to the system
>> libraries
>> ("-ldl", ...) were missing. These arguments were missing because
>> starting with
>> version 4.0 the behavior of "llvm-config --system-libs" changed (see
>> [1]) to
>> only return the system libs if static linking ("--link-static") is
>> selected.
>> When using the binaries from the Clang download page ([2])
>> "--link-static"
>> seems to default to "true" whereas "--link-static" defaults to "false"
>> when
>> using the Debian clang-4.0 package. I am not sure whether this is the
>> desired
>> behavior, but changing the AspectC++ makefile to use the command
>> "llvm-config --system-libs --link-static" forces llvm-config to output
>> the
>> system libs in hopefully all cases.
>>
>> Please let me know if it still does not work.
>>
>> Thank you very much and best regards,
>>
>> Simon
>>
>> [1] https://reviews.llvm.org/D27805
>> [2] http://releases.llvm.org/download.html
>>

Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7

[Simon Schröder]

Hi Reinhard,

Building AspectC++ using the Debian clang-4.0 package should work now. Please
use the current AspectC++ trunk version. Sorry for the inconveniences!

The problem was that the linker arguments that point to the system libraries
("-ldl", ...) were missing. These arguments were missing because starting with
version 4.0 the behavior of "llvm-config --system-libs" changed (see [1]) to
only return the system libs if static linking ("--link-static") is selected.
When using the binaries from the Clang download page ([2]) "--link-static"
seems to default to "true" whereas "--link-static" defaults to "false" when
using the Debian clang-4.0 package. I am not sure whether this is the desired
behavior, but changing the AspectC++ makefile to use the command
"llvm-config --system-libs --link-static" forces llvm-config to output the
system libs in hopefully all cases.

Please let me know if it still does not work.

Thank you very much and best regards,

Simon

[1] https://reviews.llvm.org/D27805
[2] http://releases.llvm.org/download.html


> tags 853319 help
> stop
>
> Hi AspectC++ Developers,
>
> gcc-7 is now used by default in debian/unstable, which makes this bug 
> critical.
> Since the verison of AspectC++ that is currently in the package (2.2, the 
> latest
> release) doesn't work with gcc-7, aspectc++ has been removed from testing!
>
> This makes it impossible for me upload backports and worse, it will not be 
> part
> of the next debian release.
>
> I've just checked out the lastest SVN from today (2017-08-21), and found that
> GCC can now indeed be built with GCC-7 and clange 3.8, but I can't use the
> resulting ac++ to weave puma.
>
> I've then tried the clang-4.0 package, but I get this error message:
>
> config/clang.mk:12: *** UNSUPPORTED Clang version '4.0.1' used -- try 'make -C
> config clang LLVMCONF='.  Stop.
>
> I tried to fix this by doing a "cp config/clang-4.0.0.mk 
> config/clang-4.0.1.mk",
> but this lead to this error:
>
> Linking bin/linux-release/ac++.
> /usr/bin/ld: /usr/lib/llvm-4.0/lib/libLLVMSupport.a(Signals.cpp.o): undefined
> reference to symbol 'dladdr@@GLIBC_2.2.5'
> //lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from
> command line
> collect2: error: ld returned 1 exit status
>
>
> Please advise how to proceed here!
>
> Reinhard
>
>
>
>
> On 03/27/2017 08:56 PM, Reinhard Tartler wrote:
>> tags 853319 confirmed upstream
>> forwarded 853319 aspectc-develop...@aspectc.org
>> stop
>>
>> Hi AspectC++ Developers,
>>
>> Matthias Klose, the Debian and Ubuntu GCC Maintainer points out that
>> AspectC++ currentl fails to build against the current GCC trunk (which
>> will be eventually released as GCC-7). I could confirm the build failure
>> myself on my workstation, please find the full buildlog attached to this
>> email. This is done with upstream release 2.2, which I'm about to upload
>> to debian (it builds just fine with GCC 6.3).
>>
>> At this point, I wouldn't consider this issue of any urgency. However, I
>> expect that at some point in the future, Matthias will likely want to
>> upgrade the system compiler to GCC-7 which would make this issue
>> critical. Also, the new compiler finds a couple of new warnings that
>> might be worth having a look at:
>>
>> Elements.cc:485:3: warning: this ?for? clause does not guard...
>> [-Wmisleading-indentation]
>> Elements.cc:489:3: warning: this ?for? clause does not guard...
>> [-Wmisleading-indentation]
>> ClangFlowAnalysis.cc:81:6: warning: ?void
>> {anonymous}::DataflowWorklist::enqueuePredecessors(const
>> clang::CFGBlock*)? defined but not used [-Wunused-function]
>> ClangBinding.cc:10:2: warning: #warning "Invalid clang version used!
>> Only 3.4, 3.4.2, 3.6.2, 3.7.1, 3.8.0, and 3.9.1 are supported by this
>> code." [-Wcpp]
>> Transformer.cc:472:3: warning: this ?for? clause does not guard...
>> [-Wmisleading-indentation]
>> /usr/lib/llvm-3.8/include/llvm/ADT/DenseMap.h:958:18: warning:
>> ?*((void*)(& paths)+40).llvm::SmallDenseMap> std::pair, 8>::LargeRep::Buckets? may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>> /usr/lib/llvm-3.8/include/llvm/ADT/DenseMap.h:965:18: warning:
>> ?*((void*)(& paths)+40).llvm::SmallDenseMap> std::pair, 8>::LargeRep::NumBuckets? may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>>
>>
>> Thanks for your great work on aspectc++!
>>
>> Reinhard
>>
>>
>>  Forwarded Message 
>> Subject: Bug#853319: aspectc++: ftbfs with GCC-7
>> Resent-Date: Tue, 31 Jan 2017 09:34:08 +
>> Resent-From: Matthias Klose 
>> Resent-To: Reinhard Tartler 
>> Date: Tue, 31 Jan 2017 09:29:48 +
>> From: Matthias Klose 
>> Reply-To: Matthias Klose , 853319-mainto...@bugs.debian.org
>> To: mainto...@bugs.debian.org
>>
>> Package: src:aspectc++
>> Version: 1:2.1-2
>> Severity: normal
>> Tags: sid 

Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7

[Olaf Spinczyk]

Hi Reinhard!

Simon was here today and promised to look into it as soon as possible. I
don't expect support for clang 4.0.1 to be difficult to integrate.

Olaf

On 08/22/2017 03:15, Reinhard Tartler wrote:
> tags 853319 help
> stop
> 
> Hi AspectC++ Developers,
> 
> gcc-7 is now used by default in debian/unstable, which makes this bug 
> critical.
> Since the verison of AspectC++ that is currently in the package (2.2, the 
> latest
> release) doesn't work with gcc-7, aspectc++ has been removed from testing!
> 
> This makes it impossible for me upload backports and worse, it will not be 
> part
> of the next debian release.
> 
> I've just checked out the lastest SVN from today (2017-08-21), and found that
> GCC can now indeed be built with GCC-7 and clange 3.8, but I can't use the
> resulting ac++ to weave puma.
> 
> I've then tried the clang-4.0 package, but I get this error message:
> 
> config/clang.mk:12: *** UNSUPPORTED Clang version '4.0.1' used -- try 'make -C
> config clang LLVMCONF='.  Stop.
> 
> I tried to fix this by doing a "cp config/clang-4.0.0.mk 
> config/clang-4.0.1.mk",
> but this lead to this error:
> 
> Linking bin/linux-release/ac++.
> /usr/bin/ld: /usr/lib/llvm-4.0/lib/libLLVMSupport.a(Signals.cpp.o): undefined
> reference to symbol 'dladdr@@GLIBC_2.2.5'
> //lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from
> command line
> collect2: error: ld returned 1 exit status
> 
> 
> Please advise how to proceed here!
> 
> Reinhard
> 
> 
> 
> 
> On 03/27/2017 08:56 PM, Reinhard Tartler wrote:
>> tags 853319 confirmed upstream
>> forwarded 853319 aspectc-develop...@aspectc.org
>> stop
>>
>> Hi AspectC++ Developers,
>>
>> Matthias Klose, the Debian and Ubuntu GCC Maintainer points out that
>> AspectC++ currentl fails to build against the current GCC trunk (which
>> will be eventually released as GCC-7). I could confirm the build failure
>> myself on my workstation, please find the full buildlog attached to this
>> email. This is done with upstream release 2.2, which I'm about to upload
>> to debian (it builds just fine with GCC 6.3).
>>
>> At this point, I wouldn't consider this issue of any urgency. However, I
>> expect that at some point in the future, Matthias will likely want to
>> upgrade the system compiler to GCC-7 which would make this issue
>> critical. Also, the new compiler finds a couple of new warnings that
>> might be worth having a look at:
>>
>> Elements.cc:485:3: warning: this ‘for’ clause does not guard...
>> [-Wmisleading-indentation]
>> Elements.cc:489:3: warning: this ‘for’ clause does not guard...
>> [-Wmisleading-indentation]
>> ClangFlowAnalysis.cc:81:6: warning: ‘void
>> {anonymous}::DataflowWorklist::enqueuePredecessors(const
>> clang::CFGBlock*)’ defined but not used [-Wunused-function]
>> ClangBinding.cc:10:2: warning: #warning "Invalid clang version used!
>> Only 3.4, 3.4.2, 3.6.2, 3.7.1, 3.8.0, and 3.9.1 are supported by this
>> code." [-Wcpp]
>> Transformer.cc:472:3: warning: this ‘for’ clause does not guard...
>> [-Wmisleading-indentation]
>> /usr/lib/llvm-3.8/include/llvm/ADT/DenseMap.h:958:18: warning:
>> ‘*((void*)(& paths)+40).llvm::SmallDenseMap> std::pair, 8>::LargeRep::Buckets’ may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>> /usr/lib/llvm-3.8/include/llvm/ADT/DenseMap.h:965:18: warning:
>> ‘*((void*)(& paths)+40).llvm::SmallDenseMap> std::pair, 8>::LargeRep::NumBuckets’ may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>>
>>
>> Thanks for your great work on aspectc++!
>>
>> Reinhard
>>
>>
>>  Forwarded Message 
>> Subject: Bug#853319: aspectc++: ftbfs with GCC-7
>> Resent-Date: Tue, 31 Jan 2017 09:34:08 +
>> Resent-From: Matthias Klose 
>> Resent-To: Reinhard Tartler 
>> Date: Tue, 31 Jan 2017 09:29:48 +
>> From: Matthias Klose 
>> Reply-To: Matthias Klose , 853319-mainto...@bugs.debian.org
>> To: mainto...@bugs.debian.org
>>
>> Package: src:aspectc++
>> Version: 1:2.1-2
>> Severity: normal
>> Tags: sid buster
>> User: debian-...@lists.debian.org
>> Usertags: ftbfs-gcc-7
>>
>> Please keep this issue open in the bug tracker for the package it
>> was filed for.  If a fix in another package is required, please
>> file a bug for the other package (or clone), and add a block in this
>> package. Please keep the issue open until the package can be built in
>> a follow-up test rebuild.
>>
>> The package fails to build in a test rebuild on at least amd64 with
>> gcc-7/g++-7, but succeeds to build with gcc-6/g++-6. The
>> severity of this report may be raised before the buster release.
>> There is no need to fix this issue in time for the stretch release.
>>
>> The full build log can be found at:
>> http://people.debian.org/~doko/logs/gcc7-20170126/aspectc++_2.1-2_unstable_gcc7.log
>> The last lines of the build log are at the end 

Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7

[Reinhard Tartler]

tags 853319 help
stop

Hi AspectC++ Developers,

gcc-7 is now used by default in debian/unstable, which makes this bug critical.
Since the verison of AspectC++ that is currently in the package (2.2, the latest
release) doesn't work with gcc-7, aspectc++ has been removed from testing!

This makes it impossible for me upload backports and worse, it will not be part
of the next debian release.

I've just checked out the lastest SVN from today (2017-08-21), and found that
GCC can now indeed be built with GCC-7 and clange 3.8, but I can't use the
resulting ac++ to weave puma.

I've then tried the clang-4.0 package, but I get this error message:

config/clang.mk:12: *** UNSUPPORTED Clang version '4.0.1' used -- try 'make -C
config clang LLVMCONF='.  Stop.

I tried to fix this by doing a "cp config/clang-4.0.0.mk config/clang-4.0.1.mk",
but this lead to this error:

Linking bin/linux-release/ac++.
/usr/bin/ld: /usr/lib/llvm-4.0/lib/libLLVMSupport.a(Signals.cpp.o): undefined
reference to symbol 'dladdr@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from
command line
collect2: error: ld returned 1 exit status


Please advise how to proceed here!

Reinhard




On 03/27/2017 08:56 PM, Reinhard Tartler wrote:
> tags 853319 confirmed upstream
> forwarded 853319 aspectc-develop...@aspectc.org
> stop
> 
> Hi AspectC++ Developers,
> 
> Matthias Klose, the Debian and Ubuntu GCC Maintainer points out that
> AspectC++ currentl fails to build against the current GCC trunk (which
> will be eventually released as GCC-7). I could confirm the build failure
> myself on my workstation, please find the full buildlog attached to this
> email. This is done with upstream release 2.2, which I'm about to upload
> to debian (it builds just fine with GCC 6.3).
> 
> At this point, I wouldn't consider this issue of any urgency. However, I
> expect that at some point in the future, Matthias will likely want to
> upgrade the system compiler to GCC-7 which would make this issue
> critical. Also, the new compiler finds a couple of new warnings that
> might be worth having a look at:
> 
> Elements.cc:485:3: warning: this ‘for’ clause does not guard...
> [-Wmisleading-indentation]
> Elements.cc:489:3: warning: this ‘for’ clause does not guard...
> [-Wmisleading-indentation]
> ClangFlowAnalysis.cc:81:6: warning: ‘void
> {anonymous}::DataflowWorklist::enqueuePredecessors(const
> clang::CFGBlock*)’ defined but not used [-Wunused-function]
> ClangBinding.cc:10:2: warning: #warning "Invalid clang version used!
> Only 3.4, 3.4.2, 3.6.2, 3.7.1, 3.8.0, and 3.9.1 are supported by this
> code." [-Wcpp]
> Transformer.cc:472:3: warning: this ‘for’ clause does not guard...
> [-Wmisleading-indentation]
> /usr/lib/llvm-3.8/include/llvm/ADT/DenseMap.h:958:18: warning:
> ‘*((void*)(& paths)+40).llvm::SmallDenseMap std::pair, 8>::LargeRep::Buckets’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
> /usr/lib/llvm-3.8/include/llvm/ADT/DenseMap.h:965:18: warning:
> ‘*((void*)(& paths)+40).llvm::SmallDenseMap std::pair, 8>::LargeRep::NumBuckets’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
> 
> 
> Thanks for your great work on aspectc++!
> 
> Reinhard
> 
> 
>  Forwarded Message 
> Subject: Bug#853319: aspectc++: ftbfs with GCC-7
> Resent-Date: Tue, 31 Jan 2017 09:34:08 +
> Resent-From: Matthias Klose 
> Resent-To: Reinhard Tartler 
> Date: Tue, 31 Jan 2017 09:29:48 +
> From: Matthias Klose 
> Reply-To: Matthias Klose , 853319-mainto...@bugs.debian.org
> To: mainto...@bugs.debian.org
> 
> Package: src:aspectc++
> Version: 1:2.1-2
> Severity: normal
> Tags: sid buster
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-7
> 
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
> 
> The package fails to build in a test rebuild on at least amd64 with
> gcc-7/g++-7, but succeeds to build with gcc-6/g++-6. The
> severity of this report may be raised before the buster release.
> There is no need to fix this issue in time for the stretch release.
> 
> The full build log can be found at:
> http://people.debian.org/~doko/logs/gcc7-20170126/aspectc++_2.1-2_unstable_gcc7.log
> The last lines of the build log are at the end of this report.
> 
> To build with GCC 7, either set CC=gcc-7 CXX=g++-7 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
> 
>   apt-get -t=experimental install g++
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped symbols in Debian symbols files.
> For other C/C++