<div>Under MSYS/MinGW, I looked at a few of the failing tests:</div>
<div> </div>
<div>Analysis/cast.c: Apparently MinGW doesn't have sys/socket.h, which is referenced in a #include. I searched for a package containing socket.h, but didn't find one. A MinGW mailing list search yielded a hint that socket.h is present in Cygwin, but not MinGW. Any MinGW users out there see this in running the tests?</div>
<div> </div>
<div>CodeGenCXX/class-layout.cpp: The test does "grep '%.truct.A = type { i8 }' %t" in the class-layout.cpp.tmp file, but this file has "%struct.A = type { i8 }".</div>
<div> </div>
<div>CodeGenCXX/copy-constructor-elim.cpp: Greps for a mangled symbol not in the output file. Also has this message in stderr: "'count' is not recognized as an internal or external command". I found a count script in llvm/test/Scripts and added it to the path, but still get the same error. I see that a lot of the failures are similar to this one, and for others of those scripts.</div>
<div> </div>
<div>CodeGenCXX\reference-field.cpp: Here's the output from the log:</div>
<div> </div>
<div>********************<br>FAIL: c:/Tools/llvm/tools/clang/test\CodeGenCXX\reference-field.cpp ( 166 of 1428)<br>******************** TEST 'c:/Tools/llvm/tools/clang/test\CodeGenCXX\reference-field.cpp' FAILED ********************<br>
Script:<br>--<br>c:/Tools/llvm/Debug/bin/clang-cc -emit-llvm -o - c:\Tools\llvm\tools\clang\test\CodeGenCXX\reference-field.cpp -O2 | grep "@_Z1bv"<br>--<br>Exit Code: 255<br>Command Output (stdout):<br>--</div>
<div><br>c:\Tools\llvm\tools\clang\test\CodeGenCXX>c:/Tools/llvm/Debug/bin/clang-cc -emit-llvm -o - c:\Tools\llvm\tools\clang\test\CodeGenCXX\reference-field.cpp -O2 | grep "@_Z1bv" </div>
<div>--<br>Command Output (stderr):<br>--<br>'c:' is not recognized as an internal or external command,</div>
<div>operable program or batch file.</div>
<div>--</div>
<div>********************<br></div>
<div>I'm guessing that perhaps the Windows Python installer I used installed a version of Python with Window'isms, kind of like the first Perl I used. I didn't see a MinGW Python package on the MinGW or <a href="http://python.org">python.org</a> sites, so I was going to try downloading the source package for Unix-like systems and build it, but the <a href="http://python.org">python.org</a> site has been down for nearly 24 hours. Unless I find another solution, or someone points me to the right package or solution, I'll try this when <a href="http://python.org">python.org</a> is back.</div>
<div> </div>
<div>On Ubuntu32 with gcc version 4.2.4 I ran the Analysis/casts.c test, which had a segmentation fault. Running in GDB:<br></div>
<div>$ gdb /home/john/llvm/Debug/bin/clang-cc<br>GNU gdb 6.8-debian<br>Copyright (C) 2008 Free Software Foundation, Inc.<br>License GPLv3+: GNU GPL version 3 or later <<a href="http://gnu.org/licenses/gpl.html" target="_blank">http://gnu.org/licenses/gpl.html</a>><br>
This is free software: you are free to change and redistribute it.<br>There is NO WARRANTY, to the extent permitted by law. Type "show copying"<br>and "show warranty" for details.<br>This GDB was configured as "i486-linux-gnu"...<br>
(gdb) run -analyze -checker-cfref -analyzer-store=region /home/john/llvm/tools/clang/test/Analysis/casts.c<br>Starting program: /home/john/llvm/Debug/bin/clang-cc -analyze -checker-cfref -analyzer-store=region /home/john/llvm/tools/clang/test/Analysis/casts.c<br>
[Thread debugging using libthread_db enabled]<br>[New Thread 0xb7c9e6c0 (LWP 2747)]</div>
<div>Program received signal SIGSEGV, Segmentation fault.<br>[Switching to Thread 0xb7c9e6c0 (LWP 2747)]<br>0x08316a9c in clang::CXXScopeSpec::isSet (this=0x0)<br> at /home/john/llvm/tools/clang/lib/Parse/../../include/clang/Parse/DeclSpec.h:454<br>
454 bool isSet() const { return ScopeRep != 0; }<br>(gdb) where<br>#0 0x08316a9c in clang::CXXScopeSpec::isSet (this=0x0)<br> at /home/john/llvm/tools/clang/lib/Parse/../../include/clang/Parse/DeclSpec.h:454<br>#1 0x08316209 in clang::Sema::computeDeclContext (this=0xbf9a6940, <a href="mailto:SS=@0x0" target="_blank">SS=@0x0</a>, <br>
EnteringContext=false) at SemaCXXScopeSpec.cpp:39<br>#2 0x083a57a8 in clang::Sema::LookupParsedName (this=0xbf9a6940, S=0x959e9b0, <br> SS=0x0, Name={Ptr = 157096152}, NameKind=clang::Sema::LookupOrdinaryName, <br>
RedeclarationOnly=false, AllowBuiltinCreation=false, Loc={ID = 0})<br> at SemaLookup.cpp:1165<br>#3 0x0832d978 in clang::Sema::getTypeName (this=0xbf9a6940, <a href="mailto:II=@0x95d18d8" target="_blank">II=@0x95d18d8</a>, <br>
NameLoc={ID = 2147532587}, S=0x959e9b0, SS=0x0) at SemaDecl.cpp:77<br>#4 0x084c277f in clang::Parser::ParseDeclarationSpecifiers (this=0xbf9a6848, <br> <a href="mailto:DS=@0xbf9a62a0" target="_blank">DS=@0xbf9a62a0</a>, <a href="mailto:TemplateInfo=@0xbf9a6300" target="_blank">TemplateInfo=@0xbf9a6300</a>, AS=clang::AS_none, <br>
DSContext=clang::Parser::DSC_normal) at ParseDecl.cpp:834<br>#5 0x084c72b7 in clang::Parser::ParseSimpleDeclaration (this=0xbf9a6848, <br> Context=0, <a href="mailto:DeclEnd=@0xbf9a66bc" target="_blank">DeclEnd=@0xbf9a66bc</a>, RequireSemi=true) at ParseDecl.cpp:343<br>
#6 0x084c7670 in clang::Parser::ParseDeclaration (this=0xbf9a6848, Context=0, <br> <a href="mailto:DeclEnd=@0xbf9a66bc" target="_blank">DeclEnd=@0xbf9a66bc</a>) at ParseDecl.cpp:323<br>#7 0x084b9f60 in clang::Parser::ParseExternalDeclaration (this=0xbf9a6848)<br>
at Parser.cpp:448<br>#8 0x084b9cec in clang::Parser::ParseExternalDeclaration (this=0xbf9a6848)<br> at Parser.cpp:411<br>#9 0x084ba032 in clang::Parser::ParseTopLevelDecl (this=0xbf9a6848, <br>---Type <return> to continue, or q <return> to quit---<br>
<a href="mailto:Result=@0xbf9a6930" target="_blank">Result=@0xbf9a6930</a>) at Parser.cpp:354<br>#10 0x0830818f in clang::ParseAST (<a href="mailto:PP=@0x959e700" target="_blank">PP=@0x959e700</a>, Consumer=0x959ebf0, <br>
<a href="mailto:Ctx=@0x95b89a0" target="_blank">Ctx=@0x95b89a0</a>, PrintStats=false, CompleteTranslationUnit=true)<br> at ParseAST.cpp:63<br>#11 0x08072598 in ProcessInputFile (<a href="mailto:PP=@0x959e700" target="_blank">PP=@0x959e700</a>, <a href="mailto:PPF=@0xbf9a70d8" target="_blank">PPF=@0xbf9a70d8</a>, <br>
<a href="mailto:InFile=@0x959ed80" target="_blank">InFile=@0x959ed80</a>, PA=RunAnalysis, <a href="mailto:Features=@0xbf9a70f0" target="_blank">Features=@0xbf9a70f0</a>, <br> <a href="mailto:Context=@0x95850d0" target="_blank">Context=@0x95850d0</a>) at clang-cc.cpp:2058<br>
#12 0x080743b0 in main (argc=5, argv=0xbf9a7364) at clang-cc.cpp:2314<br>(gdb) list<br>449 <br>450 /// isInvalid - An error occured during parsing of the scope specifier.<br>451 bool isInvalid() const { return isNotEmpty() && ScopeRep == 0; }<br>
452 <br>453 /// isSet - A scope specifier was resolved to a valid C++ scope.<br>454 bool isSet() const { return ScopeRep != 0; }<br>455 <br>456 void clear() {<br>457 Range = SourceRange();<br>458 ScopeRep = 0;<br>
(gdb) p this<br>$1 = (const clang::CXXScopeSpec * const) 0x0<br>(gdb) up<br>#1 0x08316209 in clang::Sema::computeDeclContext (this=0xbf9a6940, <a href="mailto:SS=@0x0" target="_blank">SS=@0x0</a>, <br> EnteringContext=false) at SemaCXXScopeSpec.cpp:39<br>
39 if (!SS.isSet() || SS.isInvalid())<br>(gdb) list<br>34 /// \returns the declaration context represented by the scope specifier @p SS,<br>35 /// or NULL if the declaration context cannot be computed (e.g., because it is<br>
36 /// dependent and not the current instantiation).<br>37 DeclContext *Sema::computeDeclContext(const CXXScopeSpec &SS,<br>38 bool EnteringContext) {<br>39 if (!SS.isSet() || SS.isInvalid())<br>
40 return 0;<br>41 <br>42 NestedNameSpecifier *NNS <br>43 = static_cast<NestedNameSpecifier *>(SS.getScopeRep());<br>(gdb) <br></div>
<div>I see that this is the problem with most if not all the the failing tests on Ubuntu. Before trying to figure out the reason for the crash in gdb, I thought I'd ask if this has been seen. Also, I see there are over 300 mb of updates for Ubuntu, so I'll install them (my internet connection is pretty slow) and try again.<br>
</div>
<div>-John<br></div>
<div class="gmail_quote">On Thu, Aug 6, 2009 at 7:24 PM, Daniel Dunbar <span dir="ltr"><<a href="mailto:daniel@zuster.org" target="_blank">daniel@zuster.org</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">On Thu, Aug 6, 2009 at 5:52 PM, John<br>
<div>Thompson<<a href="mailto:john.thompson.jtsoftware@gmail.com" target="_blank">john.thompson.jtsoftware@gmail.com</a>> wrote:<br></div>
<div>> On a VM running Ubuntu 32-bit I'm seeing 1032 failures, after a fresh<br>> update, configure, make. My Python version is 2.5.2. A week and a half<br>> ago, there were no failures.<br>><br>> Having gotten a build on MSYS/MinGW to suceed, in running the tests I'm<br>
> seeing 336 failures. Python is 2.6.1.<br>><br>> Any suggestions on debugging this? I have VERBOSE logs, but they're<br>> probably too big to post here.<br><br></div>In general, my advice is (a) look at the buildbots to see whether<br>
failures are expected or not. If not, pick any failure which isn't<br>failing on a build bot and trace it down (you can run individual tests<br>using TestRunner.sh). In this case, currently all tests are passing on<br>
many platforms, so its likely a local configuration issue. If you<br>can't figure it out, just file a bug with that one particular test<br>case, and the details on why it fails.<br><br>MSYS/MinGW is of course a separate issue from Ubuntu, but the same<br>
strategy applies.<br><br> - Daniel<br>
<div><br>> -John<br>> On Fri, Jul 31, 2009 at 7:20 PM, Eli Friedman <<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>><br>> wrote:<br>>><br>>> On Fri, Jul 31, 2009 at 5:53 PM, John<br>
>> Thompson<<a href="mailto:john.thompson.jtsoftware@gmail.com" target="_blank">john.thompson.jtsoftware@gmail.com</a>> wrote:<br>>> > After an update of both llvm and clang, configure, and rebuild on a<br>
>> > Linux<br>>> > system in a virtual machine, hundreds of tests are now failing.<br>>> ><br>>> > Just in case you didn't already know...<br>>> ><br>>> > Or is my system messed up?<br>
>><br>>> Hundreds sounds a little high, but there are currently failing tests<br>>> in trunk clang; see <a href="http://google1.osuosl.org:8011/waterfall" target="_blank">http://google1.osuosl.org:8011/waterfall</a> . If<br>
>> you're still seeing failures after that gets cleared up, please send<br>>> another email.<br>>><br>>> -Eli<br>><br>> --<br>> John Thompson<br>> <a href="mailto:John.Thompson.JTSoftware@gmail.com" target="_blank">John.Thompson.JTSoftware@gmail.com</a><br>
><br>><br></div>> _______________________________________________<br>> cfe-dev mailing list<br>> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br>><br></blockquote></div><br><br clear="all">
<div></div><br>-- <br>John Thompson<br><a href="mailto:John.Thompson.JTSoftware@gmail.com" target="_blank">John.Thompson.JTSoftware@gmail.com</a><br><br>