Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

This issue has stayed with us for gcc releases 6.1.1, 6.2.0, 6.3.0, and 7.1.0 .. so I built with BUILD_TYPE=RELWITHDEBINFO and saw that self was NULL in stack frame #0 (MemorySegmentPool::newSegment), because in stack frame 1, currentPool was NULL. I then single-stepped through stack frame #3 (Rexx

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

I'm not sure I ran the test suite with ooRexx compiled by 6.1.8. It's going to take me a couple of days before I can try this again. It surely did build. Moritz On Wed, Jul 20, 2016 at 10:31 AM, René Jansen wrote: > Hi Moritz, > > can you confirm or deny that this works with GCC 6.1.8? Normal bu

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

Hi Moritz, can you confirm or deny that this works with GCC 6.1.8? Normal builds don’t have a problem, we are seeing this with release builds, and the optimizer is suspected. Depending on this, we can focus on other things and install 6.1.8 on the build machines. best regards, René. > On 12

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

Moritz, can you successfully run regression tests with the GCC 6.1.1-8 BUILD_TYPE=Release build? -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

Interesting, I cannot reproduce this on Debian testing with gcc 6.1.1-8. Maybe it has been fixed upstream? Moritz On Mon, Jul 11, 2016 at 1:10 PM Erich Steinböck wrote: > To check whether a failure so early within the function might be related > to some illegal args coming down from MemoryObject

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

To check whether a failure so early within the function might be related to some illegal args coming down from MemoryObject::newSegment, I compiled with CXXFLAGS="-DMEMPROFILE" cmake -DBUILD_DEB=1 -DCMAKE_BUILD_TYPE=RELEASE ~/oorexxsvn/main/trunk to enable the #ifdef MEMPROFILE sections we have Wi

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

On Monday, July 11, 2016, René Jansen wrote: > > On 11 jul. 2016, at 14:15, Rick McGuire > wrote: > > I'm starting to wonder if the problem is not in this code, but rather in > one of the called routines. Perhaps the rbp register is getting clobbered > on one of the calls resulting in the trap i

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

> On 11 jul. 2016, at 14:15, Rick McGuire wrote: > > I'm starting to wonder if the problem is not in this code, but rather in one > of the called routines. Perhaps the rbp register is getting clobbered on one > of the calls resulting in the trap immediately after the return. yes, it seems th

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

I'm starting to wonder if the problem is not in this code, but rather in one of the called routines. Perhaps the rbp register is getting clobbered on one of the calls resulting in the trap immediately after the return. Rici On Mon, Jul 11, 2016 at 8:13 AM, René Jansen wrote: > > On 10 jul. 2016

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile - corr

> On 11 jul. 2016, at 14:13, René Jansen wrote: > > >> On 10 jul. 2016, at 23:45, Rick McGuire > > wrote: >> >> It might be useful to compare the code generated by the non-optimized >> version to the optimized code. It might also be useful to compare the >> opti

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

> On 10 jul. 2016, at 23:45, Rick McGuire wrote: > > It might be useful to compare the code generated by the non-optimized version > to the optimized code. It might also be useful to compare the optimized code > from a earlier compiler version. Eric, thanks for showing me how to set a break

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

this is the GCC 6.1.1 debug version code (which runs without getting an exception) erichst@erich-vm:~/oorexxbuild/611debug/bin$ gdb ./rexximage GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1 .. This GDB was configured as "x86_64-linux-gnu". .. Reading symbols from ./rexximage...(no debugging symbol

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

Hi René, Actually we didn’t need to disable optimizations before. We did see this problem with ooRexx 4.2.0 recently as well, and our colleague Marguerite disable the optimizations. This appears to be a GCC bug. I’ll check tomorrow if there is an open bug and see what we can do about it. -- —

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

It might be useful to compare the code generated by the non-optimized version to the optimized code. It might also be useful to compare the optimized code from a earlier compiler version. Rick On Sun, Jul 10, 2016 at 3:38 PM, Erich Steinböck wrote: > I've wrapped MemorySegmentPool::newSegment w

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

I've wrapped MemorySegmentPool::newSegment with #pragma GCC push_options #pragma GCC optimize ("O0") .. #pragma GCC pop_options .. but still getting the exception. The code now looks like following, with the failing instruction *very *early in the function body - not sure what that could mean. P

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

Indeed. I spent quite a few hours on this yesterday and today but I forgot to report back. @Rick, thanks for the suggestions; I am also of the opinion that it is an optimizer bug. If I move the code around, it always chokes on the mov 0x8(%rbp),%rax instruction. Googling for that, I hit several

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

With this patch applied .. --- interpreter/platform/unix/MemorySupport.cpp (revision 11101) +++ interpreter/platform/unix/MemorySupport.cpp (working copy) @@ -216,16 +216,9 @@ else/* uncommitted not enough need a new pool */ { MemorySegmentPool *n

Re: [Oorexx-devel] OpenSUSE Tumbleweed rexx.img build failure with optimized compile

On Sat, Jul 9, 2016 at 9:42 AM, René Jansen wrote: > > When specifying CMAKE_BUILD_TYPE=Release the rexx image does not build on > Tumbleweed. It receives a segmentation fault in > MemorySegmentPool::newSegment(). > > This was an opportunity to look into how this image is built. This is what > ha