On Tue, Sep 12, 2017 at 7:17 AM, Christophe Lyon
<christophe.l...@linaro.org> wrote:
> 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
This makes little sense. Are you compiling the cross compiler with
the new native compiler? Since this patch only touches the C++
front-end and only C++11 even that makes less sense. Are you sure
this was not a bug in qemu which is just happening showing up now?
Even then this makes little sense as the code generation between the
two revisions should not touch anything related to fortran.
Thanks,
Andrew Pinski
>
> Christophe
