This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by umesh.kalappa0 on Sep 4 2020, 8:43 AM.

Details

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.

Diff Detail

Repository
rL LLVM

Event Timeline

umesh.kalappa0 created this revision.Sep 4 2020, 8:43 AM
umesh.kalappa0 requested review of this revision.Sep 4 2020, 8:43 AM

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

SouraVX added a project: debug-info.
SouraVX added a subscriber: probinson.
SouraVX added a subscriber: SouraVX.

Testcase added.

umesh.kalappa0 added a comment.EditedSep 10 2020, 2:34 AM

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 added inline comments.Sep 10 2020, 6:12 PM
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;
int i;

dblaikie added inline comments.Sep 11 2020, 4:25 PM
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

umesh.kalappa0 marked an inline comment as done.Sep 12 2020, 12:43 AM

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://

umesh.kalappa0 marked an inline comment as done.
dblaikie added a comment.EditedSep 12 2020, 4:46 PM

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://

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.

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

SouraVX added inline comments.Sep 13 2020, 9:51 PM
test/CodeGenCXX/difile_entry.cpp
2

Is all this really needed ?

9

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 marked 2 inline comments as done.Sep 14 2020, 5:28 AM
This comment was removed by umesh.kalappa0.
test/CodeGenCXX/difile_entry.cpp
2

Is all this really needed ?

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

umesh.kalappa0 marked an inline comment as done.
dblaikie accepted this revision.Sep 14 2020, 9:23 AM

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.

This revision is now accepted and ready to land.Sep 14 2020, 9:23 AM

Hi All,

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

Please do the needful, thank you
~Umesh

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)

umesh.kalappa0 marked 2 inline comments as done.Sep 16 2020, 5:58 AM

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.

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.

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

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.

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?

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

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 ?

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?

umesh.kalappa0 edited the summary of this revision. (Show Details)
umesh.kalappa0 edited the summary of this revision. (Show Details)
dblaikie added inline comments.Oct 1 2020, 12:11 PM
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?

umesh.kalappa0 marked 2 inline comments as done.
dblaikie added inline comments.Oct 2 2020, 12:28 PM
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)

dblaikie added inline comments.Oct 3 2020, 9:41 AM
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)

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

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?

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

412–423 ↗(On Diff #295583)

Not on my top of head :(

425–430 ↗(On Diff #295583)

Agree ,refactor the code accordingly.

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?

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".

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.

umesh.kalappa0 marked 4 inline comments as done.

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 ↗(On Diff #296128)

Done.

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

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

aprantl accepted this revision.Dec 4 2020, 6:12 PM

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

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 updated this revision to Diff 313287.EditedDec 22 2020, 3:43 AM

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

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJan 8 2021, 10:11 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
MaskRay added inline 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

dblaikie added inline comments.Jan 9 2021, 10:54 AM
clang/test/CodeGenCXX/difile_entry.cpp
11 ↗(On Diff #315570)

Thanks for the fix!

MaskRay added inline comments.Jan 10 2021, 10:35 AM
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.

MaskRay added inline comments.Jan 10 2021, 10:59 AM
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.