On Fri, Sep 26, 2014 at 12:49 AM, Jiong Wang
<wong.kwongyuan.to...@gmail.com> wrote:
> 2014-09-25 14:07 GMT+01:00 Jiong Wang <jiong.w...@arm.com>:
>>
>> On 25/09/14 12:25, Christophe Lyon wrote:
>>>
>>>>
>>> I have observed regressions in the g++ testsuite: pr49847 now FAILs
>>> after this patch.
>>
>> no.
>>
>> even without my patch, the regression still happen.
>>
>> or you could specify -fno-shrink-wrap, gcc still crash.
>>
>> so, this regression should caused by other commits which haven't exposed on
>> x86 regression test.
>
> sorry, confirmed, there is regression.
>
> my code was git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@215590.
> there also be gcc crash on aarch64, with the following info,
> pr49847.C:5:21: internal compiler error: Segmentation fault
> try { return g >= 0; }
> ^
> 0xdc249e crash_signal
> ../../gcc/gcc/toplev.c:340
> 0xdbfeff default_get_reg_raw_mode(int)
>
> so I was thinking it's caused by other commits instead of this, and after I
> sync
> code to git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@215599 I could
> reproduce this bug.
>
> error: missing REG_EH_REGION note at the end of bb 2
>
> the reson is:
> * before this patch, we only sink simple "set reg, reg" instruction which
> the corresponding instruction will not produce exception, thus no
> REG_EH_REGION attached.
> * after this patch, we will sink instruction like the following for
> aarch64 or arm or other RISC.
>
> (insn 7 3 30 2 (set (reg:CCFPE 66 cc)
> (compare:CCFPE (reg:SF 32 v0 [ g ])
> (const_double:SF 0.0 [0x0.0p+0]))) pr49847.C:5 330 {*cmpesf}
> (expr_list:REG_DEAD (reg:SF 32 v0 [ g ])
> (expr_list:REG_EH_REGION (const_int 1 [0x1])
> (nil))))
>
> "compare" is actually a operator which may cause trap and we need to prevent
> any instruction which may causing trap be sink, because that may
> break exception handling logic
>
> so something like the following should be added to the iterator check
>
> if (may_trap_p (x))
> don't sink this instruction.
>
> any comments?
Should be checking if x may throw internally instead.
Richard.
> I will try to send a fix tomorrow.
>
> thanks.
>
> -- Jiong
>
>
>>
>> -- Jiong
>>
>>
>>>
>>> Here is what I have in my logs:
>>>
>>> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabihf/gcc3/gcc/testsuite/g++/../../xg++
>>>
>>> -B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabihf/gcc3/gcc/testsuite/g++/../../
>>> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/g++.dg/pr49847.C
>>> -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
>>>
>>> -I/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabihf/gcc3/arm-none-linux-gnueabihf/libstdc++-v3/include/arm-none-linux-gnueabihf
>>>
>>> -I/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabihf/gcc3/arm-none-linux-gnueabihf/libstdc++-v3/include
>>> -I/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++
>>> -I/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/include/backward
>>> -I/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/util
>>> -fmessage-length=0 -std=gnu++98 -O -fnon-call-exceptions -S -o
>>> pr49847.s (timeout = 800)
>>> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/g++.dg/pr49847.C: In
>>> function 'int f(float)':
>>> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/g++.dg/pr49847.C:7:1:
>>> error: missing REG_EH_REGION note at the end of bb 2
>>> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/g++.dg/pr49847.C:7:1:
>>> internal compiler error: verify_flow_info failed
>>> 0x82f8ba verify_flow_info()
>>> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/cfghooks.c:260
>>>
>>> 0x840cd3 commit_edge_insertions()
>>> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/cfgrtl.c:2068
>>> 0x9bf243 thread_prologue_and_epilogue_insns
>>> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/function.c:5852
>>> 0x9bfa52 rest_of_handle_thread_prologue_and_epilogue
>>> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/function.c:6245
>>> 0x9bfa52 execute
>>> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/function.c:6283
>>>
>>> As per
>>>
>>> http://cbuild.validation.linaro.org/build/cross-validation/gcc/trunk/215563/report-build-info.html
>>> I've noticed this on targets:
>>> arm-none-linux-gnueabihf
>>> armeb-none-linux-gnueabihf
>>> aarch64-none-elf
>>> aarch64_be-none-elf
>>> aarch64-none-linux-gnu
>>> but NOT on
>>> arm-none-eabi
>>> arm-none-linux-gnueabi
>>>
>>> Christophe.
>>>
>>
>>
