Having heard no objections, I changed pr68068 to { target x86_64-*-linux* } in
revision 240304.
My comment in pr68078.f90:
! This test calls set_vm_limit to set an artificially low address space
! limit. set_vm_limit calls setrlimit, which has some portability
! considerations. setrlimit gets errors on arm*linux and aarch64*linux,
! and when the main program calls malloc(), it in turn fails on Darwin.
! The code being tested is portable, calling ALLOCATED() or ASSOCIATED()
! to verify that allocation was successful, so the operating assumption
! is that as long as this test runs on at least one system, we can call
! it good.
Louis
---- On Mon, 19 Sep 2016 02:35:21 -0700 Christophe Lyon
<christophe.l...@linaro.org> wrote ----
> Hi,
>
>
> On 18 September 2016 at 21:19, Louis Krupp <louis.kr...@zoho.com> wrote:
> > Two possibilities:
> >
> > 1. malloc() doesn't silently return NULL on Darwin when it runs out of
> > memory; it always generates an error message.
> >
> > 2. setrlimit() doesn't work the same on Darwin as it does on Linux, and
> > the test program is hitting a system limit. It so happens that when I
> > first looked at this bug, I ignored the "ulimit -v 1000000" instruction (I
> > have a bad habit of not paying attention), and I let the program do memory
> > allocation forever. It eventually got a segfault deep within malloc(). I
> > was able to reproduce this in C as well as in Fortran. Perhaps something
> > similar happens with Darwin, although at least on Darwin malloc() issues
> > an error, however mysterious, instead of crashing.
> >
> > Two ways to go from here:
> >
> > 1. If anyone can let me ssh into a Darwin system, I can see if I can get
> > this to work.
> >
> > 2. If that's not possible, add a dg-skip-if so that we don't try to run
> > this test on Darwin, since it requires some OS support, and it doesn't
> > just involve Fortran.
> >
> > Louis
>
> On my side, I've noticed that this new test fails on arm*linux and
> aarch64*linux, using QEMU:
> set_vm_limit: Operation not permitted
>
> Christophe
>
> >
> > ---- On Sun, 18 Sep 2016 03:45:38 -0700 Dominique
> > d'Humières<domi...@lps.ens.fr> wrote ----
> > > > Fixed in revision 240219.
> > >
> > > The test fails on x86_64-apple-darwin15 (at least):
> > >
> > > FAIL: gfortran.dg/pr68078.f90 -O0 output pattern test
> > > FAIL: gfortran.dg/pr68078.f90 -O1 output pattern test
> > > FAIL: gfortran.dg/pr68078.f90 -O2 output pattern test
> > > FAIL: gfortran.dg/pr68078.f90 -O3 -fomit-frame-pointer -funroll-loops
> > -fpeel-loops -ftracer -finline-functions output pattern test
> > > FAIL: gfortran.dg/pr68078.f90 -O3 -g output pattern test
> > > FAIL: gfortran.dg/pr68078.f90 -Os output pattern test
> > > FAIL: gfortran.dg/pr68078.f90 -g -flto output pattern test
> > >
> > > The failures are
> > >
> > > Output was:
> > > pr68078.exe(37410,0xa381f000) malloc: *** mach_vm_map(size=8388608)
> > failed (error code=3)
> > > *** error: can't allocate region securely
> > > *** set a breakpoint in malloc_error_break to debug
> > > foo_ptr allocation failed
> > > pr68078.exe(37410,0xa381f000) malloc: *** mach_vm_map(size=8388608)
> > failed (error code=3)
> > > *** error: can't allocate region securely
> > > *** set a breakpoint in malloc_error_break to debug
> > > foo_obj allocation failed
> > >
> > > Should match:
> > > *foo_ptr allocation failed(
> > > |^M
> > > |^M) *foo_obj allocation failed(
> > > |^M
> > > |^M) *foo_array allocation failed(
> > > |^M
> > > |^M)
> > >
> > > with -O0
> > >
> > > and
> > >
> > > Output was:
> > > pr68078.exe(39345,0xa381f000) malloc: *** mach_vm_map(size=8388608)
> > failed (error code=3)
> > > *** error: can't allocate region securely
> > > *** set a breakpoint in malloc_error_break to debug
> > > foo_ptr allocation failed
> > >
> > > Should match:
> > > *foo_ptr allocation failed(
> > > |^M
> > > |^M) *foo_obj allocation failed(
> > > |^M
> > > |^M) *foo_array allocation failed(
> > > |^M
> > > |^M)
> > >
> > > for the other options.
> > >
> > > Dominique
> > >
> > >
> > >
> >
> >
> >
>
