Re: C++ PATCH to reduced_constant_expression for partially-initialized objects

[Christophe Lyon <christophe dot lyon at linaro dot org>]

On 12 September 2017 at 16:21, Andrew Pinski <pinskia@gmail.com> wrote:
> On Tue, Sep 12, 2017 at 7:17 AM, Christophe Lyon
> <christophe.lyon@linaro.org> wrote:
>> Hi Jason
>>
>> On 10 September 2017 at 11:09, Jason Merrill <jason@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.
>

Hmmmm you are probably right. I'm compiling the cross compiler
with the system's native compiler.

Looks like I need to check why my bisect script returns the wrong revision.

Thanks,

Christophe

> Thanks,
> Andrew Pinski
>
>>
>> Christophe