On Sun, 24 Aug 2014 20:43:30 +0200 Bastian Blank <wa...@debian.org> wrote:
> On Sun, Aug 24, 2014 at 08:34:45PM +0200, Bastian Blank wrote: > > On Sun, Aug 24, 2014 at 08:05:45PM +0200, Bastian Blank wrote: > > > On Fri, Aug 22, 2014 at 07:21:31PM -0400, Stephen Powell wrote: > > > > 32ea: a7 f4 00 01 j 32ec > > > > <sclp_wait_for_int+0x84> > > > > 32ee: 07 07 nopr %r7 > > > gcc 4.9 decides that this must never happen and adds a trap in this > > > location, so this a is deliberate way to stop the process. > > I found the culprit: The tree-isolate-paths pass in gcc 4.9. If I > > disable this pass I get: > > And -fno-delete-null-pointer-checks seems to be the correct option. From the gcc man page: -fdelete-null-pointer-checks Use global dataflow analysis to identify and eliminate useless checks for null pointers. The compiler assumes that dereferencing a null pointer would have halted the program. If a pointer is checked after it has already been dereferenced, it cannot be null. In some environments, this assumption is not true, and programs can safely dereference null pointers. Use -fno-delete-null-pointer-checks to disable this optimization for programs which depend on that behavior. So we should add this Option to CFLAGS in zipl/boot/Makefile? Why we have not seen this problem under RHEL and SLES up to now? Best Regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
