PR-47391 : Two DIFile entries are describing the same file two different ways

[umesh.kalappa0]

Summary

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.

[dblaikie]

This'll need a test case. (& any idea if there are other instances of denormalized DIFiles that could cause duplicates?)

[umesh.kalappa0]

Testcase added.

[umesh.kalappa0]

In D87147#2257226, @dblaikie wrote:

This'll need a test case. (& any idea if there are other instances of denormalized DIFiles that could cause duplicates?)

Added the case and not sure on top my head for other instances.

[dblaikie]

test/CodeGenCXX/difile_entry.cpp

1–13 ↗

(On Diff #290912)

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;
int i;

[dblaikie]

test/CodeGenCXX/difile_entry.cpp

1–13 ↗

(On Diff #290912)

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

[umesh.kalappa0]

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://[e-mail]/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://

[dblaikie]

In D87147#2269369, @umesh.kalappa0 wrote:

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://[e-mail]/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://

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.

[dblaikie]

Can the test be reduced down to "extern int i; int i;" now?

[SouraVX]

test/CodeGenCXX/difile_entry.cpp

1 ↗

(On Diff #291486)

Is all this really needed ?

8 ↗

(On Diff #291486)

Please avoid these hard-coding !1 and at other places using these makes tests fairly easy to break in general. Try pattern capturing and matching instead.

[umesh.kalappa0]

This comment was removed by umesh.kalappa0.

test/CodeGenCXX/difile_entry.cpp

1 ↗

(On Diff #291486)

Is all this really needed ?

This is something david asked for and i agree with him for robustness.

[dblaikie]

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

5 ↗

(On Diff #291547)

-implicit-check-not should be DIFile not DIFiles

8 ↗

(On Diff #291547)

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.

[umesh.kalappa0]

Hi All,

We don't have commit access , please some one can commit on behalf of us.

Please do the needful, thank you
~Umesh

[dblaikie]

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

8 ↗

(On Diff #291547)

(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)

[umesh.kalappa0]

In D87147#2275685, @dblaikie wrote:

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?

thank you @dblaikie for commiting this.

[dblaikie]

In D87147#2276547, @umesh.kalappa0 wrote:

In D87147#2275685, @dblaikie wrote:

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?

thank you @dblaikie for commiting this.

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.

[umesh.kalappa0]

In D87147#2277138, @dblaikie wrote:

In D87147#2276547, @umesh.kalappa0 wrote:

In D87147#2275685, @dblaikie wrote:

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?

thank you @dblaikie for commiting this.

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.

@aprantl and @dblaikie ,sure we will wait for your confirmation

[aprantl]

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.

[dblaikie]

In D87147#2288024, @aprantl wrote:

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.

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?

[umesh.kalappa0]

In D87147#2288103, @dblaikie wrote:

In D87147#2288024, @aprantl wrote:

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.

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?

@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).

[dblaikie]

In D87147#2294989, @umesh.kalappa0 wrote:

In D87147#2288103, @dblaikie wrote:

In D87147#2288024, @aprantl wrote:

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.

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?

@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).

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 ?

[aprantl]

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?

[dblaikie]

clang/lib/CodeGen/CGDebugInfo.cpp

412–423

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

Any path that returns "TheCU->getFile()" is going to create this problem of duplicate/noncanonicalized files, right?

[dblaikie]

clang/lib/CodeGen/CGDebugInfo.cpp

414–421

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)

[dblaikie]

clang/lib/CodeGen/CGDebugInfo.cpp

435

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)

[umesh.kalappa0]

@dblaikie and @aprantl ,please let us know your suggestions on the latest change .

clang/lib/CodeGen/CGDebugInfo.cpp

412–423

Not on my top of head :(

425–430

Agree ,refactor the code accordingly.

435

Could this result in the wrong file being checksum'd since the Loc is invalid/PLoc doesn't have this file name?

Refactor the code and yes if the Loc is invalid ,the checksum is "none" in this case

(& also vaguely worried about the directory name being missing from "FileName" - wondering how those things might interact)

Previously also ,this code was using the just Filename ,so we used the same

[dblaikie]

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

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

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?

[umesh.kalappa0]

In D87147#2319776, @dblaikie wrote:

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.

Thank you @dblaikie for the suggestions yes "wouldn't produce a checksum for this particular file".

[dblaikie]

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

Ping on this.

418–420

Ping on this.

[umesh.kalappa0]

In D87147#2355466, @dblaikie wrote:

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)

Updated with "clang-format -lines=406:436"

clang/lib/CodeGen/CGDebugInfo.cpp

415

Done.

[dblaikie]

@aprantl could you check this over? It seems plausibly correct to me but I don't know this code too well.

[umesh.kalappa0]

@aprantl ,Please do let us know your comments on the change ????

[umesh.kalappa0]

In D87147#2367384, @dblaikie wrote:

@aprantl could you check this over? It seems plausibly correct to me but I don't know this code too well.

@dblaikie ,can you commit for us please ,since we don't have the commit access .

[dblaikie]

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

[umesh.kalappa0]

In D87147#2440814, @dblaikie wrote:

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

Agree it was failing here too and fixed the same .

@dblaikie ,Please pass through your comments

[MaskRay]

clang/test/CodeGenCXX/difile_entry.cpp

11

The behavior is default triple dependent. *-windows-msvc triples use different static constructor mechanism. I fixed the test by adding -triple %itanium_abi_triple

[dblaikie]

clang/test/CodeGenCXX/difile_entry.cpp

11

Thanks for the fix!

[MaskRay]

clang/test/CodeGenCXX/difile_entry.cpp

1

@umesh.kalappa0 Can you clarify how this test demonstrates the behavior difference?

Reverting the code part does not make the test fail.

[MaskRay]

clang/test/CodeGenCXX/difile_entry.cpp

1

Seems that absolute path needs to be used. ../test_dir/difile_entry.cpp cannot demonstrate the difference. I'll improve the test.

clang/lib/CodeGen/CGDebugInfo.cpp

Optional<StringRef> CGDebugInfo::getSource(const SourceManager &SM,
 
   if (SourceInvalid)
     return None;
 
   return Source;
 }
 
 llvm::DIFile *CGDebugInfo::getOrCreateFile(SourceLocation Loc) {
-  if (!Loc.isValid())
-    // If Location is not valid then use main input file.
-    return TheCU->getFile();
-
   SourceManager &SM = CGM.getContext().getSourceManager();
+  StringRef FileName;
+  FileID FID;
+
+  if (Loc.isInvalid()) {
+    FileName = TheCU->getFile()->getFilename();
+  } else {
     PresumedLoc PLoc = SM.getPresumedLoc(Loc);
+    FileName = PLoc.getFilename();
     
-  StringRef FileName = PLoc.getFilename();
-  if (PLoc.isInvalid() || FileName.empty())
-    // If the location is not valid then use main input file.
-    return TheCU->getFile();
+    if (FileName.empty()) {
+      FileName = TheCU->getFile()->getFilename();
+    } else {
+      FileName = PLoc.getFilename();
+    }
+    FID = PLoc.getFileID();
+  }
 
   // Cache the results.
   auto It = DIFileCache.find(FileName.data());
   if (It != DIFileCache.end()) {
     // Verify that the information still exists.
     if (llvm::Metadata *V = It->second)
       return cast<llvm::DIFile>(V);
   }
 
   SmallString<32> Checksum;
 
-  // Compute the checksum if possible. If the location is affected by a #line
-  // directive that refers to a file, PLoc will have an invalid FileID, and we
-  // will correctly get no checksum.
-  Optional<llvm::DIFile::ChecksumKind> CSKind =
-      computeChecksum(PLoc.getFileID(), Checksum);
+  Optional<llvm::DIFile::ChecksumKind> CSKind = computeChecksum(FID, Checksum);
   Optional<llvm::DIFile::ChecksumInfo<StringRef>> CSInfo;
   if (CSKind)
     CSInfo.emplace(*CSKind, Checksum);
   return createFile(FileName, CSInfo, getSource(SM, SM.getFileID(Loc)));
 }
 
 llvm::DIFile *
 CGDebugInfo::createFile(StringRef FileName,

clang/test/CodeGen/debug-info-oslog.c

 // RUN: %clang_cc1 -triple x86_64-darwin-apple -debug-info-kind=limited \
 // RUN:   %s -emit-llvm -o -  | FileCheck %s
 void test_builtin_os_log(void *buf, int i, const char *data) {
   __builtin_os_log_format(buf, "%d", i);
 }
 
 // CHECK: define linkonce_odr {{.*}}@__os_log_helper_1_0_1_4_0(
 // CHECK-SAME:   !dbg ![[OS_LOG_HELPER:[0-9]+]]
 
 // This helper is going to be uniqued, so it should not have a line
 // number between file and type.
 
 // CHECK: distinct !DISubprogram(name: "__os_log_helper_1_0_1_4_0",
-// CHECK-SAME:                   file: !{{[0-9+]}}, type
+// CHECK-SAME:                   file: !{{.*}}, type
 // CHECK-SAME:                   flags: DIFlagArtificial

clang/test/CodeGenCXX/difile_entry.cpp

+// RUN: rm -rf %t/test_dir
+// RUN: mkdir -p %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 -std=c++11 -emit-llvm -o - | FileCheck  ../test_dir/difile_entry.cpp
+int x();
+static int i = x();
+
+// CHECK: [[FILE: *]] = !DIFile(filename: "{{.*}}difile_entry.cpp",
+// CHECK: {{.*}} = distinct !DISubprogram(name: "__cxx_global_var_init", scope: {{.*}}, file: [[FILE]]
+// CHECK: {{.*}} = distinct !DISubprogram(linkageName: "_GLOBAL__sub_I_difile_entry.cpp", scope: {{.*}}, file: [[FILE]]
+