Bug#1041040: [Aspectc-developers] Fwd: Bug#1041040: aspectc++ autopkg tests fail with GCC 13
Hi! Okay, another try: olaf@x1:/store/olaf/workspace2/AspectC++$ svn commit -m "A third try to fix the problems on systems with g++ 13. Now the types _Float are defined as destinct type s so that template specialization should work without conflicts. Furthermore, all types are now defined on all platforms, regardless of the availability of __float12 8." Sende NamespaceAC.cc Übertrage Daten .erledigt Übertrage Transaktion... Revision 1667 übertragen. I hope that this works now. The "fix" is actually just a workaround, because the types that I have created to satisfy the clang parser are not 100% compatible with the real _Float types. So, it is possible that further improvements are needed. Cheers, Olaf On 25.07.23 16:58, Olaf Spinczyk wrote: Right. /usr/include/math.h does not include a template specialization of struct __iseqsig_type for _Float on my Ubuntu 22.04/AMD64 machine. Therefore, my local test had passed. However, my workaround, which tries to satisfy the internal clang parser with typedefs, doesn't work in combination with this template specialization. On Arm it is a different problem. I'll try some other approach and keep you informed. Cheers, Olaf On 25.07.23 12:49, Reinhard Tartler wrote: Unfortunately, it made it worse :-( Here is abuildlog for amd64: https://salsa.debian.org/debian/aspectc/-/jobs/4471659/raw I've also attached my buildlog from an ARM64 machine to this email. thanks for looking into this! On 7/24/23 10:39 AM, Olaf Spinczyk wrote: Hi! It seems that my previous commit was too simple. I hope that today's modification helps: olaf@x1:~/workspace2/AspectC++$ svn commit -m "Improved previous bugfix: Now the typedefs for _Float128 and _Float64x, which should make the clang parser happy, are only generated on platforms where clang support __float128." Sende NamespaceAC.cc Übertrage Daten .erledigt Übertrage Transaktion... Revision 1666 übertragen. Cheers, Olaf On 24.07.23 13:26, Reinhard Tartler wrote: On 7/23/23 9:13 AM, Reinhard Tartler wrote: Turns out, the fix only works on amd64/i386, but not for instance on Arm, Matthias, our GCC maintainer has filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041040 for this. I looked over the patch and couldn't find anything architecture specific. Can you make any rhyme or reason for why it might fail on arm64? Here are some more test logs: https://ci.debian.net/packages/a/aspectc++/unstable/arm64/ This issue also occurs during a regular package build, not only during autopkgtest. I could reproduce it on the amdhal.debian.org in a sid chroot and got this: Weaving aspects into PreFileIncluder.cc... Weaving aspects into PreprocessorParser.cc... Weaving aspects into UnitManager.cc... In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PreFileIncluder.cc:19: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/TokenStream.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Array.h:27: /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Array.h_0_virt:66:9: error: __float128 is not supported on this target typedef __float128 _Float128; ^ In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PrePrintVisitor.cc:19: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreSemIterator.h:24: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreTreeIterator.h:24: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreTree.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreVisitor.h:24: /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreVisitor.h_0_virt:66:9: error: __float128 is not supported on this target typedef __float128 _Float128; ^ In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PreprocessorParser.cc:19: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Token.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/LanguageID.h:25: /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/LanguageID.h_0_virt:66:9: error: __float128 is not supported on this target typedef __float128 _Float128; ^ In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/UnitManager.cc:19: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Unit.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/List.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/i
Bug#1041040: [Aspectc-developers] Fwd: Bug#1041040: aspectc++ autopkg tests fail with GCC 13
Right. /usr/include/math.h does not include a template specialization of struct __iseqsig_type for _Float on my Ubuntu 22.04/AMD64 machine. Therefore, my local test had passed. However, my workaround, which tries to satisfy the internal clang parser with typedefs, doesn't work in combination with this template specialization. On Arm it is a different problem. I'll try some other approach and keep you informed. Cheers, Olaf On 25.07.23 12:49, Reinhard Tartler wrote: Unfortunately, it made it worse :-( Here is abuildlog for amd64: https://salsa.debian.org/debian/aspectc/-/jobs/4471659/raw I've also attached my buildlog from an ARM64 machine to this email. thanks for looking into this! On 7/24/23 10:39 AM, Olaf Spinczyk wrote: Hi! It seems that my previous commit was too simple. I hope that today's modification helps: olaf@x1:~/workspace2/AspectC++$ svn commit -m "Improved previous bugfix: Now the typedefs for _Float128 and _Float64x, which should make the clang parser happy, are only generated on platforms where clang support __float128." Sende NamespaceAC.cc Übertrage Daten .erledigt Übertrage Transaktion... Revision 1666 übertragen. Cheers, Olaf On 24.07.23 13:26, Reinhard Tartler wrote: On 7/23/23 9:13 AM, Reinhard Tartler wrote: Turns out, the fix only works on amd64/i386, but not for instance on Arm, Matthias, our GCC maintainer has filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041040 for this. I looked over the patch and couldn't find anything architecture specific. Can you make any rhyme or reason for why it might fail on arm64? Here are some more test logs: https://ci.debian.net/packages/a/aspectc++/unstable/arm64/ This issue also occurs during a regular package build, not only during autopkgtest. I could reproduce it on the amdhal.debian.org in a sid chroot and got this: Weaving aspects into PreFileIncluder.cc... Weaving aspects into PreprocessorParser.cc... Weaving aspects into UnitManager.cc... In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PreFileIncluder.cc:19: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/TokenStream.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Array.h:27: /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Array.h_0_virt:66:9: error: __float128 is not supported on this target typedef __float128 _Float128; ^ In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PrePrintVisitor.cc:19: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreSemIterator.h:24: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreTreeIterator.h:24: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreTree.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreVisitor.h:24: /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreVisitor.h_0_virt:66:9: error: __float128 is not supported on this target typedef __float128 _Float128; ^ In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PreprocessorParser.cc:19: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Token.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/LanguageID.h:25: /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/LanguageID.h_0_virt:66:9: error: __float128 is not supported on this target typedef __float128 _Float128; ^ In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/UnitManager.cc:19: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Unit.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/List.h:25: In file included from /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/ListElement.h:27: /tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/ListElement.h_0_virt:66:9: error: __float128 is not supported on this target typedef __float128 _Float128; ^ ___ aspectc-developers mailing list aspectc-develop...@mail.aspectc.org https://www.aspectc.org/cgi-bin/mailman/listinfo/aspectc-developers ___ aspectc-developers mailing list aspectc-develop...@mail.aspectc.org https://www.aspectc.org/cgi-bin/mailman/listinfo/aspectc-developers
Bug#953540: [Aspectc-developers] Fwd: Bug#953540: aspectc++: FTBFS on armel
Hi Reinhard, I have added "-Wl,--as-needed -latomic -Wl,--no-as-needed" to the Makefile. It is not exactly your patch, but should do it. Let me know if it doesn't. - Olaf Am 17.03.20 um 22:35 schrieb Reinhard Tartler: > Control: forwarded -1 aspectc-develop...@aspectc.org > > Hi Adrian, > > Olaf, the upstream developer, has a question regarding your patch to > aspectc++. > Would you mind having a look and ideally sharing your reply to everyone? > > Thank you! > -rt > > On 3/17/20 11:05 AM, Olaf Spinczyk wrote: >> Hi Reinhard! >> >> Do you understand the reasons behind the patch? >> >> The difference is the following addition for linking: >> >> -Wl,--as-needed -latomic -Wl,--no-as-needed >> >> (1) I wonder why the atomics (e.g. __atomic_fetch_add_4) are not >> available by default in armel. They seem to be on most other platforms. >> >> (2) Why is "--as-needed ... --no-as-needed" necessary? >> >> (3) Could -latomic also be placed at the end of the list of libraries >> (behind the additional libraries needed for Clang 9.0.x)? >> >> Cheers, >> >> Olaf >> >> Am 17.03.20 um 14:10 schrieb Reinhard Tartler: >>> Hi aspect c++ developers, >>> >>> Would the attached patch be acceptable for svn trunk? >>> >>> Please have a look at the Debian bug for context. I'm happy to clarify any >>> questions. >>> >>> Best >>> Rt >>> >>> >>> Original Message >>> From: Adrian Bunk >>> Sent: March 17, 2020 7:04:58 AM EDT >>> To: Ivo De Decker , 953...@bugs.debian.org >>> Subject: Bug#953540: aspectc++: FTBFS on armel >>> >>> Control: tags -1 patch >>> >>> On Tue, Mar 10, 2020 at 11:12:16AM +, Ivo De Decker wrote: >>>> package: src:aspectc++ >>>> version: 1:2.2+git20200229-1 >>>> severity: serious >>>> tags: ftbfs >>>> >>>> Hi, >>>> >>>> The latest upload of aspectc++ to unstable fails on armel: >>>> >>>> https://buildd.debian.org/status/package.php?p=aspectc%2B%2B >>> Fix attached. >>> >>>> Cheers, >>>> >>>> Ivo >>> cu >>> Adrian >>> >>> >>> ___ >>> aspectc-developers mailing list >>> aspectc-develop...@aspectc.org >>> http://aspectc.org/listinfo/aspectc-developers >>> >> ___ >> aspectc-developers mailing list >> aspectc-develop...@aspectc.org >> http://aspectc.org/listinfo/aspectc-developers >> > ___ > aspectc-developers mailing list > aspectc-develop...@aspectc.org > http://aspectc.org/listinfo/aspectc-developers
Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7
>>
>>>>> 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 >&
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 >>>>
Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7
gt; 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 >> typename 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 tests. Not
>>>> exactly an ideal
>>>> situation because it renders the test ineffective.
>>>>
>>>> From what I understand I could instead dialer disable these the tests
>>>> instead. But before doing
>>>> that, I wanted to check with you if these failures also occurred on your
>>>> akut Test
>>>> infrastructure.
>>>> If yes, how do you deal with them, maybe you could disable the test in
>>>> svn. If they do not
>>>> appear
>>>> in akut, I wonder why.
>>>>
>>>> I agree that it's not super critical or urgent to me, but I think you are
>>>> in a much per
>>>> position
>>>> to assess the criticality and urgency.
>>>>
>>>> Thanks
>>>> Reinhard
>>>>
>>>> On August 29, 2017 12:19:21 PM EDT, Olaf Spinczyk
>>>> <olaf.spinc...@tu-dortmund.de> wrote:
>>>>> Hi Reinhard!
>>>>>
>>>>> We should definitely look into these three problems within the next few
>>>>> weeks, but I don't regard them as very critical, because they affect
>>>>> only special use cases: Advice for user-defined "operator new"
>>>>> implementations and the code generation for get/set advice, which is a
>>>>> feature that is only enabled with --data_joinpoints and still a bit
>>>>> experimental.
>
Bug#853319: [Aspectc-developers] Fwd: Bug#853319: aspectc++: ftbfs with GCC-7
id, void, char, AC::DIL< 2, int,
> AC::DILE >, AC::TLE >
> __TJP;
> TResult __result_buffer;
> AC::invoke_Bar_Bar__a0_before<__TJP> ();
> __result_buffer = ::arr[idx0];
> return (TResult &)__result_buffer;
> }
> int main() {
> char x = __Get__Z4mainv_1_0< > (arr, (1), __AC_TYPEOF((arr[1])) );
> return 0;
> }
>
>
>> I've uploaded a new package that simply ignores failures from tests. Not
>> exactly an ideal
>> situation because it renders the test ineffective.
>>
>> From what I understand I could instead dialer disable these the tests
>> instead. But before doing
>> that, I wanted to check with you if these failures also occurred on your
>> akut Test infrastructure.
>> If yes, how do you deal with them, maybe you could disable the test in svn.
>> If they do not appear
>> in akut, I wonder why.
>>
>> I agree that it's not super critical or urgent to me, but I think you are in
>> a much per position
>> to assess the criticality and urgency.
>>
>> Thanks
>> Reinhard
>>
>> On August 29, 2017 12:19:21 PM EDT, Olaf Spinczyk
>> <olaf.spinc...@tu-dortmund.de> wrote:
>>> Hi Reinhard!
>>>
>>> We should definitely look into these three problems within the next few
>>> weeks, but I don't regard them as very critical, because they affect
>>> only special use cases: Advice for user-defined "operator new"
>>> implementations and the code generation for get/set advice, which is a
>>> feature that is only enabled with --data_joinpoints and still a bit
>>> experimental.
>>>
>>> How to proceed? Can we/you live with these problems for now and update
>>> later or is there no update option and we have to fix it sooner?
>>>
>>> Cheers,
>>>
>>> Olaf
>>>
>>> On 08/24/2017 00:16, Reinhard Tartler wrote:
>>>>
>>>>
>>>> On 08/23/2017 12:07 PM, Olaf Spinczyk wrote:
>>>>> Hi!
>>>>>
>>>>> You can generate the config file easily with ag++ --gen_config.
>>> Sorry
>>>>> for the inconvenience. The background is that when I wrote the first
>>>>> ac++ tests, I did not want the makefile to depend on ag++.
>>>>>
>>>>> We should change that sooner or later, because it is obviously
>>> confusing.
>>>>
>>>> Not a problem.
>>>>
>>>> Progress! With a "correct" PUMA CONFIG, I now get further, but there
>>> seem to be
>>>> genuine test failures. Are they concerning or shall I ignore them for
>>> the debian
>>>> package?
>>>>
>>>> They look like this:
>>>>
>>>> /usr/bin/make -C tests -s all
>>>> make[2]: Entering directory
>>>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests'
>>>>
>>> ...[C:ExecAdviceNewDelete].[D:Bug574]...[C:Bug598]
>>>>
>>>>
>>>> +-+
>>>> |ERRORS: |
>>>> +-+
>>>>
>>>>
>>> -
>>>> TEST: ExecAdviceNewDelete
>>>>
>>> -
>>>> STDOUT:
>>>>
>>>> make[3]: Entering directory
>>>>
>>> '/build/aspectc++-rCVJRW/aspectc++-2.2+git20170823/AspectC++/tests/ExecAdviceNewDelete'
>>>> Weaving main.cc
>>>> * Running ac++ 2.2
>>>> * Handling Translation Unit `main.cc'.
>>>> - Path "main.cc"
>>>> - Parsing ...
>>>> - Weaving Aspects Forward Declarations ...
>>>> - Inserting namespace AC
>>>> - Committing
>>>> - Preparing introductions ...
>>>> - Parsing again ...
>>>> - Weaving access control bypass classes ...
>>>> - Weaving Join Points ...
>>>> Advicecode manipulation
>>>> Collecting Advice
>>>> Setting up thisJoinPoint for aspectof
>>>> Create pointcut expression tree
>>>> Matching joinpoints
>>>> Aspect ordering ...
>>>> Creating project repository 'repo.acp'
>>>> Type Check Functions
>>>> Access J
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:
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=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
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
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
