search

abduld / include-what-you-use

Automatically exported from code.google.com/p/include-what-you-use
Other
0 stars 0 forks source link

iwyu for clang 3.3 always fails with error "fatal error: no input files" #114

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?  Give the *exact* arguments passed
to include-what-you-use, and attach the input source file that gives the
problem (minimal test-cases are much appreciated!)
1.
2.
3.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?

Please provide any additional information below.

Original issue reported on code.google.com by argus....@gmail.com on 15 Dec 2013 at 2:53

GoogleCodeExporter commented 9 years ago 
(Sorry accidentally hit enter too soon)

I am building iwyu out of tree against the headers / libraries installed on my 
system

I stated with the iwyu version for clang 3.3 provided on the website 
(include-what-you-use-3.3.tar.gz)

then I modified the CMakeLists.txt file to refer to the system locations:
>>>cmake .. -DLLVM_PATH=/usr/lib/llvm/ DLLVM_INC_PATH=/usr/include/clang/

there are of the llvm/clang version(
>>>clang++ --version
clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-pc-linux-gnu
Thread model: posix

I then tried to test if clang++ compiles a test file.
>>>clang++ -I . ./tests/casts.cc

Which it did, then I tried to run iwyu:
>>>./build/include-what-you-use -Xiwyu --verbose=3 -I . ./tests/casts.cc
where I got the error:
fatal error: no input files
include-what-you-use: /usr/include/clang/Basic/Diagnostic.h:1059: 
clang::DiagnosticBuilder 
clang::DiagnosticsEngine::Report(clang::SourceLocation, unsigned int): 
Assertion `CurDiagID == ~0U && "Multiple diagnostics in flight at once!"' 
failed.

I get this for all test files.

I've included the modified CMakeLists.txt  I use.

Original comment by argus....@gmail.com on 15 Dec 2013 at 3:09

Attachments:

GoogleCodeExporter commented 9 years ago 
I think you may be seeing this:
http://clang-developers.42468.n3.nabble.com/Diagnostics-in-plugins-fail-with-ass
ert-td4026712.html

I guess clang defaults to std=c++11 on your platform.

Can you force -std=c++03 using CMAKE_CXX_FLAGS in your modified CMakeLists.txt?

Original comment by kim.gras...@gmail.com on 15 Dec 2013 at 9:34

GoogleCodeExporter commented 9 years ago 
I've done this, and checked the compile commands(attached). I still get the 
same problem.

I've included the gdb backtrace.
The argc=0 in line #6 seems wrong...

#6 include_what_you_use::CreateCompilerInstance ( argc=0, argv=0x1a9a500)

gdb --args ./build/include-what-you-use -Xiwyu --verbose=3 -I . 
./tests/casts.cc
GNU gdb (Gentoo 7.5.1 p2) 7.5.1
Copyright (C) 2012 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 "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from 
/home/****/lang/include-what-you-use/build/include-what-you-use...done.
(gdb) r
Starting program: 
/home/****/lang/include-what-you-use/build/include-what-you-use 
-Xiwyu --verbose=3 -I . ./tests/casts.cc
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
fatal error: no input files
include-what-you-use: /usr/include/clang/Basic/Diagnostic.h:1059: 
clang::DiagnosticBuilder 
clang::DiagnosticsEngine::Report(clang::SourceLocation, unsigned int): 
Assertion `CurDiagID == ~0U && "Multiple diagnostics in flight at 
once!"' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff6e342d5 in raise () from /lib64/libc.so.6
(gdb) back
#0  0x00007ffff6e342d5 in raise () from /lib64/libc.so.6
#1  0x00007ffff6e35758 in abort () from /lib64/libc.so.6
#2  0x00007ffff6e2d392 in ?? () from /lib64/libc.so.6
#3  0x00007ffff6e2d442 in __assert_fail () from /lib64/libc.so.6
#4  0x00000000008f359c in clang::DiagnosticsEngine::Report (
    this=0x7fffffffd908, Loc=..., DiagID=409)
    at /usr/include/clang/Basic/Diagnostic.h:1059
#5  0x00000000008ec5f1 in clang::DiagnosticsEngine::Report (
    this=0x7fffffffd908, DiagID=409)
    at /usr/include/clang/Basic/Diagnostic.h:1065
#6  0x00000000008eb213 in include_what_you_use::CreateCompilerInstance (
    argc=0, argv=0x1a9a500)
    at /home/****/lang/include-what-you-use/iwyu_driver.cc:190
#7  0x000000000079c201 in main (argc=7979521, argv=0x7fffffffdd00)
    at /home/****/lang/include-what-you-use/iwyu.cc:3701

Original comment by argus....@gmail.com on 15 Dec 2013 at 2:52

Attachments:

GoogleCodeExporter commented 9 years ago 
actually i'm not sure how applicable gdb is to clang code.

Original comment by argus....@gmail.com on 15 Dec 2013 at 4:30

GoogleCodeExporter commented 9 years ago 
A few thoughts:

1) Your CMakeLists.txt no longer matches what's in the 3.3 release tgz. I think 
I based it on the libclang-3.3-dev package, is that available on your platform? 
Then again, if you can make it build with headers and libs in different roots, 
that should be fine.

2) Could the dev packages be release built? If so, could you explicitly feed 
CMAKE_BUILD_TYPE=Release to align them? I wonder if there's some 
configuration-dependent stuff in LLVM headers that generates problems (e.g. 
IWYU sees a type with a different size than what Clang saw when it was built). 
I've seen some commits to LLVM and Clang to make headers 
configuration-independent lately (post-3.4), so there might be something in 3.3.

Other than that, I'm out of ideas, maybe try and debug all the way from 
beginning of main() and see if you can figure out why argc/argv are messed up.

Original comment by kim.gras...@gmail.com on 15 Dec 2013 at 4:31

GoogleCodeExporter commented 9 years ago 
I choose option 3) debugging. Something is happening here that shouldn't be. 
See attached file, line 175. I guess the best option from here is just 
upgrading to the clang repo version?

>>>./build/include-what-you-use ./tests/anonymous_struct.cc 
iwyu.cc main argc 2
iwyu.cc main clang_argc2
DJS: ./build/include-what-you-use
DJS: ./tests/anonymous_struct.cc
CC2: 2 2
CC3: 0 0
EAV: 0
fatal error: no input files
include-what-you-use: /usr/include/clang/Basic/Diagnostic.h:1059: 
clang::DiagnosticBuilder 
clang::DiagnosticsEngine::Report(clang::SourceLocation, unsigned int): 
Assertion `CurDiagID == ~0U && "Multiple diagnostics in flight at once!"' 
failed.

Original comment by argus....@gmail.com on 16 Dec 2013 at 1:48

Attachments:

GoogleCodeExporter commented 9 years ago 
Ok, this isolates it a little. It gives me:

CC2: 1 1
CC3: 23373528 0
EAV: 23373528

Either:
1) I'm doing something wrong building
2) the Gentoo people are doing something wrong
3) the llvm people are doing something wrong.

Original comment by argus....@gmail.com on 16 Dec 2013 at 3:42

GoogleCodeExporter commented 9 years ago 
(forgot files)

Original comment by argus....@gmail.com on 16 Dec 2013 at 3:43

Attachments:

GoogleCodeExporter commented 9 years ago 
I'm glad you're not suspecting IWYU :-)

I don't know how to figure out the build configuration for the Gentoo 
LLVM/Clang packages, but if you could do so, try and use the same settings for 
IWYU. I'm still worried that there's some incosistency (NDEBUG/_DEBUG, -O 
settings, etc).

It could be a Clang miscompile on your platform (when using Clang to build 
IWYU), but I guess that's hard to prove.

If you're comfortable with debugging disassembly, you could try and step 
through the relevant portions and see if there are signs of a stack smash 
(which would indicate a bug or a configuration mismatch) or if the generated 
code is plainly wrong (which would indicate Clang 3.3 is broken on your 
platform.)

Original comment by kim.gras...@gmail.com on 16 Dec 2013 at 8:46

GoogleCodeExporter commented 9 years ago 
I updated to llvm/clang 3.5 (repo) and iwyu (repo).

So -O0(iwyu) vs -02(llvm) does make a difference. (WTF. why should it? )

I didn't check all other compile flags though, but I did a gdb and valgrind 
check.

What is this strange(by which I mean crazy-void-pointer-to-itself-using) 
GetExecutablePath function? Is it essential or can I cut it out?

Original comment by argus....@gmail.com on 17 Dec 2013 at 12:18

Attachments:

GoogleCodeExporter commented 9 years ago 
(I did change both to -02 though.)

Original comment by argus....@gmail.com on 17 Dec 2013 at 12:19

GoogleCodeExporter commented 9 years ago 
I'm not sure if the result of GetExecutablePath is used in any substantial way 
in Driver.

But it looks like that is only just the first use of std::string in the 
program, so I'm guessing you'll see the same problem when it's used next. Since 
std::string seems to be part of the problem, could it be that you're using 
different standard libraries for LLVM/Clang and IWYU?

I'm not sure how to intepret your comment "So -O0(iwyu) vs -02(llvm) does make 
a difference." -- do you mean you got it working? Or did it just start behaving 
differently?

So have you now checked out both Clang/LLVM and IWYU per:
https://code.google.com/p/include-what-you-use/wiki/InstructionsForUsers#Buildin
g_in-tree

? And building them together won't work either?

Original comment by kim.gras...@gmail.com on 21 Dec 2013 at 2:41

GoogleCodeExporter commented 9 years ago 
This cmake file works for me. It is written to try to pull configuration 
options from the llvm-config executable.

All test pass except 3 that rely on clang's stddef.h, but this is a minor issue.

BR, MA

Original comment by argus....@gmail.com on 29 Dec 2013 at 5:09

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks Max for figuring out build settings. I'd like to simplify CMakeLists.txt 
before committing it. For example, try to use llvm-config on Mac OS X too. I 
think I'll get to it in a week or two.

Original comment by vsap...@gmail.com on 30 Dec 2013 at 3:39