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