[GSoC] constant-folding pattern not fired
Hi,
Apparently this pattern is not getting fired (even in isolation).
/* x % 1 -> 0 */
(simplify
(trunc_mod @0 integer_onep)
{ build_zero_cst (type); })
I tried with this test-case:
int f(int x)
{
int t1 = 1;
int t2 = x % t1;
return t2;
}
I get the following output in ccp1 dump file:
http://pastebin.com/B6HjptkC
and the following output is generated in gimple-match.c:
http://pastebin.com/tmi0cpxv
I guess the generated code appears to be correct for the above pattern,
so we are not doing anything wrong in genmatch ?
Thanks,
Prathamesh
gcc-5-20140817 is now available
Snapshot gcc-5-20140817 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20140817/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 214076 You'll find: gcc-5-20140817.tar.bz2 Complete GCC MD5=9884e622e5136c06c1e662a6f92f7713 SHA1=9c3b620f43c80ddec064075cb617b6d440a7ada3 Diffs from 5- are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: LTO inhibiting dwarf lexical blocks output
> On Fri, Aug 15, 2014 at 10:08:38PM +0200, Steven Bosscher wrote: > > On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote: > > > So... I've been getting my feet wet with LTO and debugging and I noticed a > > > seemingly unrelated yet annoying problem. On x86-64, > > > gcc.dg/guality/pr48437.c fails when run in LTO mode. > > > > > > Eh, sorry I can't actually answer your question but, eh... > > > > Isn't the only real solution: to generate this kind of DIEs earlier > > (maybe already immediately after parsing) and stream them? > > > > Otherwise, how can this possibly be made to work with multi-language LTO? > > > > It seems to me that only the lowest-level DWARF (things we don't know > > about until RTL, like CFI) should be done at link time. Things like > > scoping and types are language dependent and have to be generated > > before streaming. > > > > Again, sorry for not actually being helpful - just a thought ;-) > > The plan is indeed to generate as much DWARF as possible early. > But, BLOCKs are something which if you throw away during compilation like > LTO does right now will never work properly, because while some minimal > DWARF tree can be created for it early, for the lexical block to be useful > you need > to track on which exact instructions the lexical block is in scope and on > which it is not. We do get blocks at LTO and variables in BLOCK_VARs list, just global decls are skipped (because they are linked by chain pointer and one decl thus can not appear in multiple lists and decl merging will make that happen) I would expect the early DWARF to already contains its representation of BLOCK_VARS at least for the global decls. If that is undobale we can always link BLOCK_VARs by vector instead of tree chain and fix this issue. Honza > > Jakub
Re: ASAN test failures make compare_tests useless
On 08/16/2014 04:37 AM, Manuel López-Ibáñez wrote: On the compile farm, ASAN tests seem to fail a lot like: FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, is ==31166==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12) ==31166==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v , should match READ of size 1 at 0x[0-9a-f]+ thread T0.*( The problem is that those addresses and sizes are very random, so when I compare the test results of a pristine trunk with a patched one, I get: New tests that FAIL: unix//-m64: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, is ==12875==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12) unix//-m64: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, is ==18428==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12) [... hundreds of ASAN tests that failed...] Old tests that failed, that have disappeared: (Eeek!) unix//-m64: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, is ==30142==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12) unix//-m64: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, is ==31166==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12) [... the same hundreds of tests that already failed before...] The above makes very difficult to identify failures caused by my patch. Can we remove the "==" part of the error? This way compare_tests will ignore the failures. Alternatively, I could patch compare_tests to sed out that part before comparing. Would that be acceptable? Cheers, Manuel. Added Sanitizer folks. Frankly it'd be cool if dumping PIDs and addresses could be turned off.
Re: ASAN test failures make compare_tests useless
On 08/18/2014 09:42 AM, Yury Gribov wrote: On 08/16/2014 04:37 AM, Manuel López-Ibáñez wrote: On the compile farm, ASAN tests seem to fail a lot like: FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, is ==31166==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12) ==31166==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v , should match READ of size 1 at 0x[0-9a-f]+ thread T0.*( The problem is that those addresses and sizes are very random, so when I compare the test results of a pristine trunk with a patched one, I get: New tests that FAIL: unix//-m64: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, is ==12875==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12) unix//-m64: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, is ==18428==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12) [... hundreds of ASAN tests that failed...] Old tests that failed, that have disappeared: (Eeek!) unix//-m64: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, is ==30142==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12) unix//-m64: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, is ==31166==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12) [... the same hundreds of tests that already failed before...] The above makes very difficult to identify failures caused by my patch. Can we remove the "==" part of the error? This way compare_tests will ignore the failures. Alternatively, I could patch compare_tests to sed out that part before comparing. Would that be acceptable? Cheers, Manuel. Added Sanitizer folks. Frankly it'd be cool if dumping PIDs and addresses could be turned off. Ok, this time actually added them.
