Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7
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++ related build failures see the porting guide at > http://gcc.gnu.org/gcc-7/porting_to.html > > [...] > weave.mk:72: recipe for target > '/build/aspectc++-4
Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7
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 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 experiment
Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7
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 buster >> User: debian-...@lists.debian.org >> Usertags: ftbfs-gcc-7 >> >> Please keep this issue open in the bug tracker for the package it >> was file
Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7
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
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&arch=amd64&ver=1%3A2.2-1&stamp=1490665251&raw=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
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&arch=amd64&ver=1%3A2.2-1&stamp=1490665251&raw=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
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 Poi
Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7
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
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 (size_t ) throw(std::bad_alloc);
Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7
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 &ent, 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 (&base)[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 problems for now and u
Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7
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 > &ent, 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 > (&base)[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
Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7
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 >> &ent, >> 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
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
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
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 g++
Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7
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 >