Like @aprantl suggested ,modify to use the canonicalized DIFile ,if we don't know the loc info and filename for the compiler generated functions for example static initialization functions.
Details
Details
Diff Detail
Diff Detail
- Repository
- rL LLVM
Event Timeline
Comment Actions
This'll need a test case. (& any idea if there are other instances of denormalized DIFiles that could cause duplicates?)
| test/CodeGenCXX/difile_entry.cpp | ||
|---|---|---|
| 2–14 | If the idea is this should produce only one DIFile, whereas it would previously produce 2, perhaps: FileCheck --implicit-check-not=DIFile And then just check the specific DIFile value (& perhaps check that it's referenced from both places we expect it to be referenced from?) Also, could the test code be a bit simpler, like: extern int i; | |
| test/CodeGenCXX/difile_entry.cpp | ||
|---|---|---|
| 2–14 | Would the test be as effective if it were simplified down as I mentioned? extern int i; int i; Rather than a class with member functions, etc? Also you can remove the CHECK-NOT line now that you've got the implicit-check-not that's more general anyway | |
Comment Actions
extern int i;
int i;
We are not getting 2 DIFile entries for the above case,for your reference .
!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
!1 = distinct !DIGlobalVariable(name: "i", scope: !2, file: !3, line: 2, type: !6, isLocal: false, isDefinition: true)
!2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "clang version 10.0.0.1 (http://ukallapa@stash.wrs.com/scm/llvm/clang.git 2660105769d58dbb8b66f56247f208ca2872913a) (llvm/llvm.git bfc5adc611fdc055ece9191c3d8df0750bec8816)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !4, globals: !5, splitDebugInlining: false, nameTableKind: None)
!3 = !DIFile(filename: "test.c", directory: "/folk/ukallapa")
!4 = !{}
!5 = !{!0}
!6 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
!7 = !{i32 7, !"Dwarf Version", i32 4}
!8 = !{i32 2, !"Debug Info Version", i32 3}
!9 = !{i32 1, !"wchar_size", i32 4}
!10 = !{!"clang version 10.0.0.1 (http://
Comment Actions
Hmm, seems to work for me - but in both cases (the class test case and the int test case) it only gets one DIFile if a single filename is given, but if you give an absolute/relative/some other interesting path to the file, other than just "file.cpp", then you get the two file names:
$ clang-tot -cc1 -main-file-name test.cpp -debug-info-kind=limited $HOME/dev/scratch/test.cpp -std=c++11 -emit-llvm -o - | grep DIFile !3 = !DIFile(filename: "/home/blaikie/dev/scratch/test.cpp", directory: "/home/blaikie/dev/scratch") !6 = !DIFile(filename: "test.cpp", directory: "/home/blaikie/dev/scratch") $ clang-tot -cc1 -main-file-name test.cpp -debug-info-kind=limited test.cpp -std=c++11 -emit-llvm -o - | grep DIFile !3 = !DIFile(filename: "test.cpp", directory: "/home/blaikie/dev/scratch") $ cat test.cpp extern int i; int i;
Perhaps try it in the test case and see if it fails under lit? Might make sense to even make the test a bit more explicit/robust - something like:
RUN: rm -rf %t/test_dir RUN: mkdir %t/test_dir RUN: cd %t/test_dir RUN: cp %s . RUN: %clang_cc1 .... -main-file-name difile_entry.cpp -debug-info-kind=limited ../test_dir/difile_entry.cpp
Then it shows how the input file name and the -main-file-name are written differently & that's the key difference/reason for the bug.
This comment was removed by umesh.kalappa0.
| test/CodeGenCXX/difile_entry.cpp | ||
|---|---|---|
| 2 |
This is something david asked for and i agree with him for robustness. | |
Comment Actions
Couple of things to clean up in the test, but otherwise looks good. Appreciate your patience with all the fussy details.
| test/CodeGenCXX/difile_entry.cpp | ||
|---|---|---|
| 6 | -implicit-check-not should be DIFile not DIFiles | |
| 9 | No need to match specific numbers if you aren't going to refer to that match elsewhere - probably replace the [[..:![0-9]+]] matches with {{.*}} or [[[![0-9]+]] as you see fit. | |
Comment Actions
Hi All,
We don't have commit access , please some one can commit on behalf of us.
Please do the needful, thank you
~Umesh
Comment Actions
Hmm, sorry for the churn here - I was going to commit this, but looking at it, it seems this patch pretty much exactly undoes the work from rL349065 - @aprantl can you weigh in on this? This patch doesn't seem to break your test - did your test test the issue correctly? Maybe some other change that's happened since your change has made reverting it viable while preserving the desired behavior?
| test/CodeGenCXX/difile_entry.cpp | ||
|---|---|---|
| 9 | (apologies for the churn here - I was tidying up the test a bit to better understand it and make sure it was testing the change in behavior, I arrived at this: // CHECK: distinct !DIGlobalVariable(name: "i", scope: {{.*}}, file: [[FILE:![a-f0-9]+]],
// CHECK: distinct !DICompileUnit(language: DW_LANG_C_plus_plus{{.*}}, file: [[FILE]]
// CHECK: [[FILE]] = !DIFile(filename: "{{.*}}difile_entry.cpp",I was going to commit that along with the change - but since I want to defer to @aprantl on this change, perhaps you can apply this to the pending patch) | |
Comment Actions
Sorry, to clarify, this patch hasn't been committed yet - hoping @aprantl can chime in with some context for the original change that this patch is reverting.
Comment Actions
I think the comment in https://reviews.llvm.org/rL349065 describes it quite well:
The DIFile used by the CU is special and distinct from the main source
file. Its directory part specifies what becomes the DW_AT_comp_dir
(the compilation directory), even if the source file was specified
with an absolute path.
So while the CU links to a DIFile it's more a storage mechanism for DW_AT_comp_dir and not a "file" in the normal sense and thus should be treated special. (And we might want to just store a string instead to avoid this confusion in the future.
Comment Actions
Fair points.
@umesh.kalappa0 is there specific observable behavior of the resulting DWARF you were trying to address (I seem to recall/think there was)? Or only the quirky/strange IR representation?
Comment Actions
@dblaikie ,like stated in https://bugs.llvm.org/show_bug.cgi?id=47391 ,we are trying to address the specific behavior, where the debug_line referring to two different file index's (1 and 2).
Comment Actions
Right right, smaller repro:
int x(); static int i = x();
So the global ctor uses the DICompileUnit's DIFile, rather than the canonicalized/remapped one that'd be used by other entities that come from specific lines of code.
I guess @aprantl's point would be that nothing should be using the DICompileUnit's DIFile, because it's special and carries the comp_dir. So maybe a separate canonicalized DIFile for use in cases like this. @aprantl ?
Comment Actions
I guess @aprantl's point would be that nothing should be using the DICompileUnit's DIFile, because it's special and carries the comp_dir.
Yes.
So maybe a separate canonicalized DIFile for use in cases like this.
Could we do that?
| clang/lib/CodeGen/CGDebugInfo.cpp | ||
|---|---|---|
| 412–423 ↗ | (On Diff #295583) | Any chance this code can be shared with some other implementation elsewhere/ (I assume this was copied from/inspired by some other code somewhere? It seems non-trivial enough that making avoiding duplication of this code would be good) |
| 425–430 ↗ | (On Diff #295583) | Any path that returns "TheCU->getFile()" is going to create this problem of duplicate/noncanonicalized files, right? |
| clang/lib/CodeGen/CGDebugInfo.cpp | ||
|---|---|---|
| 414–421 ↗ | (On Diff #295789) | This still seems like it might be covered in another function (presumably the computeChecksum/createFile, etc) - and also, this work isn't being cached. So it should probably be moved down below/into the caching code, and preferably share more of its implementation with other code. (also, could you upload the patch with full context (discussed here: https://llvm.org/docs/Phabricator.html ) as it'd make it a bit easier to review) |
| clang/lib/CodeGen/CGDebugInfo.cpp | ||
|---|---|---|
| 430 ↗ | (On Diff #295960) | Could this result in the wrong file being checksum'd since the Loc is invalid/PLoc doesn't have this file name? (& also vaguely worried about the directory name being missing from "FileName" - wondering how those things might interact) |
Comment Actions
| clang/lib/CodeGen/CGDebugInfo.cpp | ||
|---|---|---|
| 430 ↗ | (On Diff #295960) |
Refactor the code and yes if the Loc is invalid ,the checksum is "none" in this case
Previously also ,this code was using the just Filename ,so we used the same |
| 412–423 ↗ | (On Diff #295583) | Not on my top of head :( |
| 425–430 ↗ | (On Diff #295583) | Agree ,refactor the code accordingly. |
Comment Actions
I'm not sure the FID changes have any effect? It looks like this code may be the same as/equivalent to the previous version:
if (Loc.isInvalid() && FileName.empty()){
FileName = TheCU->getFile()->getFilename();
}& maybe that's fine? It does seem a bit strange to me that we wouldn't produce a checksum for this particular file, though.
| clang/lib/CodeGen/CGDebugInfo.cpp | ||
|---|---|---|
| 415 ↗ | (On Diff #296128) | Does this line have any effect? So far as I can tell from reading the code, getFileID on an invalid SourceLocation produces an invalid FileID, which is the same as the default constructed FileID? |
| 418–420 ↗ | (On Diff #296128) | This comment seems to have drifted from where it is meant to be? (oh, actually it appears to be duplicated from the computeChecksum code?) It doesn't seem to make sense here, where there's no checksum computation happening on the line the comment pertains to? |
Comment Actions
Thank you @dblaikie for the suggestions yes "wouldn't produce a checksum for this particular file".
Comment Actions
Few unaddressed comments and could use some formatting (try clang-tidy, you can have it format just the parts of the file you changed by using .../clang/tools/clang-format/git-clang-format origin for instance)
| clang/lib/CodeGen/CGDebugInfo.cpp | ||
|---|---|---|
| 415 ↗ | (On Diff #296128) | Ping on this. |
| 418–420 ↗ | (On Diff #296128) | Ping on this. |
Comment Actions
Updated with "clang-format -lines=406:436"
| clang/lib/CodeGen/CGDebugInfo.cpp | ||
|---|---|---|
| 415 ↗ | (On Diff #296128) | Done. |
Comment Actions
@aprantl could you check this over? It seems plausibly correct to me but I don't know this code too well.
Comment Actions
Does this pass "check-clang" for you? I tried applying the patch and got a lot of failures - crashes like this:
$ ninja check-clang-codegenopencl [0/1] Running lit suite /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL llvm-lit: /usr/local/google/home/blaikie/dev/llvm/src/llvm/utils/lit/lit/llvm/config.py:347: note: using clang: /usr/local/google/home/blaikie/dev/llvm/build/default/bin/clang FAIL: Clang :: CodeGenOpenCL/enqueue-kernel-non-entry-block.cl (105 of 107) ******************** TEST 'Clang :: CodeGenOpenCL/enqueue-kernel-non-entry-block.cl' FAILED ******************** Script: -- : 'RUN: at line 1'; /usr/local/google/home/blaikie/dev/llvm/build/default/bin/clang -cc1 -internal-isystem /usr/local/google/home/blaikie/dev/llvm/build/default/lib/clang/12.0.0/include -nostdsysteminc -cl-std=CL2.0 -O0 -emit-llvm -o - -triple amdgcn < /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl | /usr/local/google/home/blaikie/dev/llvm/build/default/bin/FileCheck /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl --check-prefixes=COMMON,AMDGPU : 'RUN: at line 2'; /usr/local/google/home/blaikie/dev/llvm/build/default/bin/clang -cc1 -internal-isystem /usr/local/google/home/blaikie/dev/llvm/build/default/lib/clang/12.0.0/include -nostdsysteminc -cl-std=CL2.0 -O0 -emit-llvm -o - -triple "spir-unknown-unknown" < /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl | /usr/local/google/home/blaikie/dev/llvm/build/default/bin/FileCheck /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl --check-prefixes=COMMON,SPIR32 : 'RUN: at line 3'; /usr/local/google/home/blaikie/dev/llvm/build/default/bin/clang -cc1 -internal-isystem /usr/local/google/home/blaikie/dev/llvm/build/default/lib/clang/12.0.0/include -nostdsysteminc -cl-std=CL2.0 -O0 -emit-llvm -o - -triple "spir64-unknown-unknown" < /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl | /usr/local/google/home/blaikie/dev/llvm/build/default/bin/FileCheck /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl --check-prefixes=COMMON,SPIR64 : 'RUN: at line 4'; /usr/local/google/home/blaikie/dev/llvm/build/default/bin/clang -cc1 -internal-isystem /usr/local/google/home/blaikie/dev/llvm/build/default/lib/clang/12.0.0/include -nostdsysteminc -cl-std=CL2.0 -O0 -debug-info-kind=limited -gno-column-info -emit-llvm -o - -triple amdgcn < /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl | /usr/local/google/home/blaikie/dev/llvm/build/default/bin/FileCheck /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl --check-prefixes=CHECK-DEBUG -- Exit Code: 2 Command Output (stderr): -- clang: /usr/local/google/home/blaikie/dev/llvm/src/clang/include/clang/Basic/SourceLocation.h:327: const char *clang::PresumedLoc::getFilename() const: Assertion `isValid()' failed. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: /usr/local/google/home/blaikie/dev/llvm/build/default/bin/clang -cc1 -internal-isystem /usr/local/google/home/blaikie/dev/llvm/build/default/lib/clang/12.0.0/include -nostdsysteminc -cl-std=CL2.0 -O0 -debug-info-kind=limited -gno-column-info -emit-llvm -o - -triple amdgcn 1. <eof> parser at end of file 2. <stdin>:11:13: LLVM IR generation of declaration 'test' 3. <stdin>:11:13: Generating code for declaration 'test' #0 0x00000000095c28aa llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/Support/Unix/Signals.inc:563:11 #1 0x00000000095c2a7b PrintStackTraceSignalHandler(void*) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/Support/Unix/Signals.inc:630:1 #2 0x00000000095c109b llvm::sys::RunSignalHandlers() /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/Support/Signals.cpp:70:5 #3 0x00000000095c31ad SignalHandler(int) /usr/local/google/home/blaikie/dev/llvm/src/llvm/lib/Support/Unix/Signals.inc:405:1 #4 0x00007feb7a44b140 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14140) #5 0x00007feb79f1bdb1 raise ./signal/../sysdeps/unix/sysv/linux/raise.c:51:1 #6 0x00007feb79f05537 abort ./stdlib/abort.c:81:7 #7 0x00007feb79f0540f get_sysdep_segment_value ./intl/loadmsgcat.c:509:8 #8 0x00007feb79f0540f _nl_load_domain ./intl/loadmsgcat.c:970:34 #9 0x00007feb79f145b2 (/lib/x86_64-linux-gnu/libc.so.6+0x345b2) #10 0x00000000098b610d clang::PresumedLoc::getFilename() const /usr/local/google/home/blaikie/dev/llvm/src/clang/include/clang/Basic/SourceLocation.h:0:5 #11 0x0000000009a92785 clang::CodeGen::CGDebugInfo::getOrCreateFile(clang::SourceLocation) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:409:24 #12 0x0000000009a98e71 clang::CodeGen::CGDebugInfo::CreateType(clang::TypedefType const*, llvm::DIFile*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:1213:69 #13 0x0000000009aa3c45 clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:3253:5 #14 0x0000000009a93172 clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:3173:17 #15 0x0000000009a971fc clang::CodeGen::CGDebugInfo::CreateQualifiedType(clang::QualType, llvm::DIFile*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:905:5 #16 0x0000000009aa3a8b clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType, llvm::DIFile*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:3220:5 #17 0x0000000009a93172 clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType, llvm::DIFile*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:3173:17 #18 0x0000000009aa8d97 clang::CodeGen::CGDebugInfo::EmitDeclare(clang::VarDecl const*, llvm::Value*, llvm::Optional<unsigned int>, clang::CodeGen::CGBuilderTy&, bool) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:4179:8 #19 0x0000000009aa99fb clang::CodeGen::CGDebugInfo::EmitDeclareOfAutoVariable(clang::VarDecl const*, llvm::Value*, clang::CodeGen::CGBuilderTy&, bool) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:4298:3 #20 0x0000000009d8ffc3 clang::CodeGen::CodeGenFunction::EmitAutoVarAlloca(clang::VarDecl const&) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDecl.cpp:1609:7 #21 0x0000000009d8c8a8 clang::CodeGen::CodeGenFunction::EmitAutoVarDecl(clang::VarDecl const&) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDecl.cpp:0:30 #22 0x0000000009d8c0d5 clang::CodeGen::CodeGenFunction::EmitVarDecl(clang::VarDecl const&) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDecl.cpp:209:1 #23 0x0000000009d8bd87 clang::CodeGen::CodeGenFunction::EmitDecl(clang::Decl const&) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDecl.cpp:154:49 #24 0x0000000009ed97b6 clang::CodeGen::CodeGenFunction::EmitDeclStmt(clang::DeclStmt const&) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGStmt.cpp:1249:22 #25 0x0000000009ed2463 clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*, llvm::ArrayRef<clang::Attr const*>) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGStmt.cpp:387:5 #26 0x0000000009ed170e clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*, llvm::ArrayRef<clang::Attr const*>) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGStmt.cpp:55:7 #27 0x0000000009eda7bd clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGStmt.cpp:441:3 #28 0x0000000009d32c61 clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CodeGenFunction.cpp:1183:5 #29 0x0000000009d33713 clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CodeGenFunction.cpp:1354:3 #30 0x0000000009be99e1 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CodeGenModule.cpp:4715:3 #31 0x0000000009be069d clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CodeGenModule.cpp:3065:12 #32 0x0000000009be544e clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CodeGenModule.cpp:2818:5 #33 0x0000000009bed590 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CodeGenModule.cpp:5533:38 #34 0x000000000a6d0c82 (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/ModuleBuilder.cpp:169:73 #35 0x000000000a6cadc4 clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CodeGenAction.cpp:218:12 #36 0x000000000d10feef clang::ParseAST(clang::Sema&, bool, bool) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/Parse/ParseAST.cpp:162:20 #37 0x000000000a4f417d clang::ASTFrontendAction::ExecuteAction() /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/Frontend/FrontendAction.cpp:1058:1 #38 0x000000000a6c77e5 clang::CodeGenAction::ExecuteAction() /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CodeGenAction.cpp:1153:1 #39 0x000000000a4f3b48 clang::FrontendAction::Execute() /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/Frontend/FrontendAction.cpp:953:7 #40 0x000000000a410dd8 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/Frontend/CompilerInstance.cpp:991:23 #41 0x000000000a6b3f54 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /usr/local/google/home/blaikie/dev/llvm/src/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:278:8 #42 0x00000000061eaa2c cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /usr/local/google/home/blaikie/dev/llvm/src/clang/tools/driver/cc1_main.cpp:240:13 #43 0x00000000061dd2fa ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) /usr/local/google/home/blaikie/dev/llvm/src/clang/tools/driver/driver.cpp:330:5 #44 0x00000000061dc49d main /usr/local/google/home/blaikie/dev/llvm/src/clang/tools/driver/driver.cpp:407:5 #45 0x00007feb79f06cca __libc_start_main ./csu/../csu/libc-start.c:308:16 #46 0x00000000061dbc4a _start (/usr/local/google/home/blaikie/dev/llvm/build/default/bin/clang+0x61dbc4a) FileCheck error: '<stdin>' is empty. FileCheck command line: /usr/local/google/home/blaikie/dev/llvm/build/default/bin/FileCheck /usr/local/google/home/blaikie/dev/llvm/src/clang/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl --check-prefixes=CHECK-DEBUG
Comment Actions
Agree it was failing here too and fixed the same .
@dblaikie ,Please pass through your comments
| clang/test/CodeGenCXX/difile_entry.cpp | ||
|---|---|---|
| 11 ↗ | (On Diff #315570) | The behavior is default triple dependent. *-windows-msvc triples use different static constructor mechanism. I fixed the test by adding -triple %itanium_abi_triple |
| clang/test/CodeGenCXX/difile_entry.cpp | ||
|---|---|---|
| 11 ↗ | (On Diff #315570) | Thanks for the fix! |
| clang/test/CodeGenCXX/difile_entry.cpp | ||
|---|---|---|
| 1 ↗ | (On Diff #315570) | @umesh.kalappa0 Can you clarify how this test demonstrates the behavior difference? Reverting the code part does not make the test fail. |
| clang/test/CodeGenCXX/difile_entry.cpp | ||
|---|---|---|
| 1 ↗ | (On Diff #315570) | Seems that absolute path needs to be used. ../test_dir/difile_entry.cpp cannot demonstrate the difference. I'll improve the test. |
Is all this really needed ?