Hi Jason
On 10 September 2017 at 11:09, Jason Merrill <ja...@redhat.com> wrote:
> A few months back I queued this patch to bring back for GCC 8.
> Unfortunately I don't remember the context that it came up in, but it
> affects for instance cases of self-assignment, which can't have a
> constant value if there is no previous initialization.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
I've noticed that this patch causes a regression in fortran on
armeb-linux-gnumeabihf
FAIL: gfortran.dg/allocate_zerosize_3.f -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions execution
test
FAIL: gfortran.dg/allocate_zerosize_3.f -O3 -g execution test
FAIL: gfortran.dg/assumed_rank_1.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions execution
test
FAIL: gfortran.dg/assumed_rank_1.f90 -O3 -g execution test
FAIL: gfortran.dg/assumed_rank_2.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions execution
test
FAIL: gfortran.dg/assumed_rank_2.f90 -O3 -g execution test
target armeb-none-linux-gnueabihf
--with-mode arm
--with-cpu cortex-a9
--with-fpu neon-fp16
using --with-fpu vfpv3-d16-fp16 does not introduce the regression.
target arm-none-linux-gnueabihf with the same parameters is OK ('arm'
as opposed to 'armeb')
My gfortran.log only shows:
spawn [open ...]
Program aborted. Backtrace:
qemu: uncaught target signal 6 (Aborted) - core dumped
Christophe
