After commit r294897, LibreOffice cannot be built with the NewGVN. Steps to reproduce: 1. $ git clone git://anongit.freedesktop.org/libreoffice/core 2. $ apt-get build-dep libreoffice ( also lo_usefull Shell Script if missing dep) 3. Remove ccache if it's installed ( ccache generates warning w/ clang) 4. create file autogen.input with CC=clang and CXX=clang++ 5 ./autogen.sh && make ENVCFLAGS="-mllvm -enable-newgvn" ENVCFLAGSCXX="-mllvm -enable-newgvn" after r294897 build fails with hwpfilter_test_hwpfilter.test' unit test failed after r296000 LibreOffice will fail with the following error [CUT] sdext_pdfimport Test name: (anonymous namespace)::PDFITest::testTdf98421 assertion failed - Expression: aOutput.indexOf("svg:height=\"-262.82mm\"") != -1 Failures !!! Run: 6 Failure total: 1 Failures: 1 Errors: 0 Error: a unit test failed, please do one of: make CppunitTest_sdext_pdfimport CPPUNITTRACE="gdb --args" # for interactive debugging on Linux /core/solenv/gbuild/CppunitTest.mk:107: recipe for target '/core/workdir/CppunitTest/sdext_pdfimport.test' failed make[1]: *** [/core/workdir/CppunitTest/sdext_pdfimport.test] Error 1 make[1]: *** Waiting for unfinished jobs.... Makefile:264: recipe for target 'build' failed make: *** [build] Error 2
NewGVN doesn't use value tracking, so not sure what is up.
also, need a minimized testcase to debug, i'm not going to download all of libreoffice :)
I'll be happy to reduce if you provide a single file that fails (libreoffice is really too big).
(In reply to Daniel Berlin from comment #1) > NewGVN doesn't use value tracking, so not sure what is up.
(In reply to Daniel Berlin from comment #1) > NewGVN doesn't use value tracking, so not sure what is up. There must be some kind of interaction here as a regular make completes all of the unit tests. Also, I bisected the change in failing CppUnit test down to http://llvm.org/viewvc/llvm-project?view=revision&revision=295583 NewGVN: Start making use of predicateinfo pass. > a single file that fails I'm not sure where to begin here. Before r294897, hwpfilter.test failed with a segfault. After r295583, Cppunit Test sdext_pdfimport generates an assertion failed. I can give you the core dump of the pre-r294897 error or any debug output that you require. However paring this down an application unit test is beyond my ability.
As of r301609, NewGVN builds of LibreOffice are still failing on the mandatory CppUnit Test_sdext_pdfimport. Normal builds are working.
I appreciate the update. There's still really not a lot i can do without a reduced testcase. It's likely a latent bug somewhere, but it may also be in other code. At this point i've now built thousands and thousands of software packages with newgvn on, and not hit any issue like this. If you could at least produce a single .bc file of the unit test that lli could run or something, i could try to track it down.
I'm willing to do some of the reduction work but I have to say the libreoffice suite is a little huge and scary. Accidentally, I just stumbled upon this http://llvm.org/devmtg/2017-03//assets/slides/libreoffice_loves_llvm.pdf so I cc:ed the speaker in case he has suggestions on how we can reduce this bug effectively (as I asssume they hit similar issues in the past)
(In reply to Davide Italiano from comment #8) > so I cc:ed the speaker in case he has suggestions on how we can reduce this > bug effectively (as I asssume they hit similar issues in the past) I haven't come across NewGVN yet; is this problem specific to 32-bit x86, or does it also happen on 64-bit x86_64? I routinely do x86_64 builds of LibreOffice with Clang trunk, and don't remember any specific issue with those hwpfilter or pdfimport tests (but never manually enabled that -enable-newgvn).
I don't think it's 32-bit specific. It only happens with -mllvm -enable-newgvn as far as I can tell.
With recent LLVM/Clang trunk (r301906), a Linux x86_64 build of recent LibreOffice master (de9106a511ed9c202423e3c3a9754feb4f969364), with CC/CXX containing '-mllvm -enable-newgvn', succeeds 'make check' for me without failing any tests.
Luke, can we close this one? Stephan, thanks! Is there any chance you can run builds with `newgvn` periodically? We plan to enable it by default and catching regressions early would be great.
(In reply to Davide Italiano from comment #12) > Stephan, thanks! Is there any chance you can run builds with `newgvn` > periodically? We plan to enable it by default and catching regressions early > would be great. Yes, will do.
Verified fixed with clang version 5.0.0 (trunk 301984). Thanks for your help Stephan and Davide.