On 08/29/2017 09:42 AM, Christophe Lyon wrote: > On 29 August 2017 at 17:28, Jeff Law <l...@redhat.com> wrote: >> On 08/29/2017 03:13 AM, Christophe Lyon wrote: >>> Hi Jeff, >> [ ... ] >>>> >>>> commit a370df2c52074abbb044d1921a0c7df235758050 >>>> Author: law <law@138bc75d-0d04-0410-961f-82ee72b054a4> >>>> Date: Tue Aug 29 05:03:36 2017 +0000 >>>> >>>> * tree-ssa-dom.c (edge_info::record_simple_equiv): Call >>>> derive_equivalences. >>>> (derive_equivalences_from_bit_ior, >>>> record_temporary_equivalences): >>>> Code moved into.... >>>> (edge_info::derive_equivalences): New private member function >>>> >>>> * gcc.dg/torture/pr57214.c: Fix type of loop counter. >>>> * gcc.dg/tree-ssa/ssa-sink-16.c: Disable DOM. >>>> * gcc.dg/tree-ssa/ssa-dom-thread-11.c: New test. >>>> * gcc.dg/tree-ssa/ssa-dom-thread-12.c: New test. >>>> * gcc.dg/tree-ssa/ssa-dom-thread-13.c: New test. >>>> * gcc.dg/tree-ssa/ssa-dom-thread-14.c: New test. >>>> * gcc.dg/tree-ssa/ssa-dom-thread-15.c: New test. >>>> * gcc.dg/tree-ssa/ssa-dom-thread-16.c: New test. >>>> * gcc.dg/tree-ssa/ssa-dom-thread-17.c: New test. >>>> >>>> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@251397 >>>> 138bc75d-0d04-0410-961f-82ee72b054a4 >>>> >>> >>> 3 of the new tests fail on arm-none-linux-gnueabihf >>> --with-cpu=cortex-a15 --with-fpu=vfpv3-d16-fp16 >>> >>> FAIL: gcc.dg/tree-ssa/ssa-dom-thread-11.c scan-tree-dump-times dom2 >>> "Threaded" 1 >>> FAIL: gcc.dg/tree-ssa/ssa-dom-thread-14.c scan-tree-dump-times dom2 >>> "Threaded" 1 >>> FAIL: gcc.dg/tree-ssa/ssa-dom-thread-16.c scan-tree-dump-times dom2 >>> "Threaded" 1 >>> >>> they do pass when configuring for cpu cortex-a9/a15 and fpu >>> neon-fp16/neon-vfpv4 >>> >>> I do not have the dumps since it's automated testing; let me know if >>> you need me to >>> reproduce it manually and extract the dumps. >> Strange. I can't reproduce this. >> >> /home/law/gcc-testing/gcc2/configure --target=arm-none-linux-gnueabihf >> --with-cpu=cortex-a15 --with-fpu=vfpv3-d16-fp16 >> > > Sorry, it was a typo: I meant cortex-a5. Ah. I see it now.
Isn't this really an indicator that the ARM test in check_effective_target_logical_op_short_circuit is wrong? AFAICT that test just looks to see if a particular preprocessor symbol is defined. WOuldn't it be better to check the output of -mprint-tune-info which should make the test DTRT in all situations? jeff
