[PATCH] D141375: [SYCL][OpenMP] Fix compilation errors for unsupported __bf16 intrinsics

eandrews added inline comments. Comment at: clang/lib/Sema/Sema.cpp:1978-1979 !Context.getTargetInfo().hasInt128Type()) || +(Ty->isBFloat16Type() && !Context.getTargetInfo().hasBFloat16Type() && + !LangOpts.CUDAIsDevice) || LongDoubleMismatched)

[PATCH] D157118: [NFC][Clang] Fix static analyzer concerns

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG39191c457715: [NFC][Clang] Fix static analyzer concerns (authored by eandrews). Herald added a project: clang. Repository: rG LLVM Github Monorepo

[PATCH] D157118: [NFC][Clang] Fix static analyzer concerns

eandrews updated this revision to Diff 554063. eandrews added a comment. Changed a dyn_cast to cast and handled ObjCAtFinallyStmt similar to how ObjCAtTryStmt is handled, i.e. just check that it exists before calling PrintRawCompoundStmt CHANGES SINCE LAST ACTION https://reviews.llvm.org/D15

[PATCH] D158671: [NFC][Clang] Fix static analyzer concerns

This revision was automatically updated to reflect the committed changes. Closed by commit rG847186eb94bd: [NFC][Clang] Fix static analyzer concern (authored by eandrews). Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D1

[PATCH] D158671: [NFC][Clang] Fix static analyzer concerns

eandrews updated this revision to Diff 553534. eandrews added a comment. Thanks for the reviews! Requested changes have been made in latest patch CHANGES SINCE LAST ACTION https://reviews.llvm.org/D158671/new/ https://reviews.llvm.org/D158671 Files: clang/include/clang/ExtractAPI/ExtractAP

[PATCH] D158666: [Clang] Fix linker error for function multiversioning

eandrews added a comment. aarch64 has different mangling for default functions when using target_clones. Sigh `int __attribute__((target_clones("ls64_v+fp16", "default"))) foo_ovl(int) { return 1; }` results in `@_Z7foo_ovli._Mfp16Mls64_v` and `@_Z7foo_ovlv`. Note there is no ".default" as in

[PATCH] D158671: [NFC][Clang] Fix static analyzer concerns

eandrews created this revision. eandrews added reviewers: aaron.ballman, tahonermann. Herald added subscribers: manas, ASDenysPetrov, dkrupp, donat.nagy, Szelethus, a.sidorin, baloghadamsoftware. Herald added a reviewer: ributzka. Herald added a project: All. eandrews requested review of this revi

[PATCH] D158666: [Clang] Fix linker error for function multiversioning

eandrews added a comment. In D158666#4611497 , @erichkeane wrote: > In D158666#4611494 , @eandrews > wrote: > >> In D158666#4611481 , @erichkeane >> wrote: >> >>> I thi

[PATCH] D158666: [Clang] Fix linker error for function multiversioning

eandrews added a comment. In D158666#4611481 , @erichkeane wrote: > I think the .ifunc spelling was an oversight on my part when I implemented > this, I didn't spend enough time investigating GCC's behavior when > implementing this feature. I think th

[PATCH] D158666: [Clang] Fix linker error for function multiversioning

eandrews created this revision. eandrews added reviewers: erichkeane, tahonermann, aaron.ballman, zsrkmyn. Herald added a project: All. eandrews requested review of this revision. Currently target_clones attribute results in a linker error when there are no multi-versioned function declarations i

[PATCH] D157888: [NFC][Clang] Fix static analyzer concern about null value dereference

eandrews added inline comments. Comment at: clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp:657 + const Stmt *S = AcquireNode->getStmtForDiagnostics(); + assert(S && "Statmement cannot be null."); PathDiagnosticLocation LocUsedForUniqueing = --

[PATCH] D157888: [NFC][Clang] Fix static analyzer concern about null value dereference

This revision was automatically updated to reflect the committed changes. Closed by commit rGe62b2fc40d11: [NFC][Clang] Fix static analyzer concern (authored by eandrews). Herald added a project: clang. Changed prior to commit: https://reviews.llvm.org/D157888?vs=549962&id=550886#toc Repositor

[PATCH] D157885: [NFC][Clang] Fix static analyzer concern about null value derefence

This revision was automatically updated to reflect the committed changes. Closed by commit rGc70dab026d37: [NFC][Clang] Fix static analyzer concern about null value dereference (authored by eandrews). Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D157888: [NFC][Clang] Fix static analyzer concern about null value dereference

eandrews added a comment. In D157888#4586126 , @steakhal wrote: > Hmm. I guess the assertion is to silence some tool. And I think actually that > function might very well also return null in some cases. > Why do you think it cannot or at least should not

[PATCH] D157554: [NFC][Clang] Fix static analyzer concern about null pointer dereference

eandrews added a comment. Thanks for the reviews! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D157554/new/ https://reviews.llvm.org/D157554 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https:

[PATCH] D157554: [NFC][Clang] Fix static analyzer concern about null pointer dereference

This revision was automatically updated to reflect the committed changes. Closed by commit rGc4ada13e4b3e: [NFC][Clang] Fix static analyzer concern about null value dereference (authored by eandrews). Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D157888: [NFC][Clang] Fix static analyzer concern about null value dereference

eandrews created this revision. eandrews added reviewers: aaron.ballman, tahonermann. Herald added subscribers: steakhal, abrachet, manas, ASDenysPetrov, martong, dkrupp, donat.nagy, Szelethus, a.sidorin, baloghadamsoftware. Herald added a reviewer: NoQ. Herald added a project: All. eandrews reque

[PATCH] D157554: [NFC][Clang] Fix static analyzer concern about null pointer dereference

eandrews updated this revision to Diff 549960. eandrews added a comment. Applied review comments CHANGES SINCE LAST ACTION https://reviews.llvm.org/D157554/new/ https://reviews.llvm.org/D157554 Files: clang/lib/Sema/SemaExprCXX.cpp Index: clang/lib/Sema/SemaExprCXX.cpp ==

[PATCH] D157885: [NFC][Clang] Fix static analyzer concern about null value derefence

eandrews created this revision. eandrews added reviewers: aaron.ballman, tahonermann. Herald added subscribers: manas, ASDenysPetrov, dkrupp, donat.nagy, Szelethus, a.sidorin, baloghadamsoftware. Herald added a project: All. eandrews requested review of this revision. https://reviews.llvm.org/D15

[PATCH] D157454: [NFC][Clang] Fix static analyzer concern about null value dereference

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG421c9bbf65b7: [NFC][Clang] Fix static analyzer concern (authored by eandrews). Herald added a project: clang. Repository: rG LLVM Github Monorepo

[PATCH] D157454: [NFC][Clang] Fix static analyzer concern about null value dereference

eandrews added a comment. Pre-merge check fails are unrelated - fatal error C1060: compiler is out of heap space CHANGES SINCE LAST ACTION https://reviews.llvm.org/D157454/new/ https://reviews.llvm.org/D157454 ___ cfe-commits mailing list cfe-comm

[PATCH] D157554: [NFC][Clang] Fix static analyzer concern about null pointer dereference

eandrews added a comment. In D157554#4577504 , @aaron.ballman wrote: > In D157554#4576720 , @eandrews > wrote: > >> In D157554#4576478 , >> @aaron.ballman wrote: >> >>>

[PATCH] D157554: [NFC][Clang] Fix static analyzer concern about null pointer dereference

eandrews added a comment. In D157554#4576478 , @aaron.ballman wrote: > This feels a bit more like a functional change than a non-functional change > because it seems like we should be able to test this case (whereas, if we > think `TC` can never be nul

[PATCH] D157554: [NFC][Clang] Fix static analyzer concern about null pointer dereference

eandrews created this revision. eandrews added reviewers: tahonermann, aaron.ballman. Herald added subscribers: manas, ASDenysPetrov, dkrupp, donat.nagy, Szelethus, a.sidorin, baloghadamsoftware. Herald added a project: All. eandrews requested review of this revision. Herald added a subscriber: wa

[PATCH] D157454: [NFC][Clang] Fix static analyzer concern about null value dereference

eandrews updated this revision to Diff 548789. eandrews added a comment. Applied review comments to use an assert instead CHANGES SINCE LAST ACTION https://reviews.llvm.org/D157454/new/ https://reviews.llvm.org/D157454 Files: clang/lib/CodeGen/CGObjC.cpp Index: clang/lib/CodeGen/CGObjC.c

[PATCH] D157454: [NFC][Clang] Fix static analyzer concern about null value dereference

eandrews added inline comments. Comment at: clang/lib/CodeGen/CGObjC.cpp:222-223 Selector Sel = MethodWithObjects->getSelector(); - QualType ResultType = E->getType(); - const ObjCObjectPointerType *InterfacePointerType -= ResultType->getAsObjCInterfacePointerType(); +

[PATCH] D157454: [NFC][Clang] Fix static analyzer concern about null value dereference

eandrews created this revision. eandrews added reviewers: aaron.ballman, tahonermann. Herald added subscribers: manas, ASDenysPetrov, dkrupp, donat.nagy, Szelethus, a.sidorin, baloghadamsoftware. Herald added a project: All. eandrews requested review of this revision. InterfacePointerType is dere

[PATCH] D157429: [NFC] [Clang] Fix static analyzer concern

eandrews added a comment. In D157429#4570540 , @aaron.ballman wrote: > LGTM with a small formatting nit. Thanks for the review! I committed the patch after fixing the formatting Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https:

[PATCH] D157429: [NFC] [Clang] Fix static analyzer concern

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG6a4779cc235c: [NFC] Fix static analyzer concern (authored by eandrews). Herald added a project: clang. Changed prior to commit: https://reviews.ll

[PATCH] D157429: [NFC] [Clang] Fix static analyzer concern

eandrews created this revision. eandrews added reviewers: aaron.ballman, tahonermann. Herald added subscribers: manas, ASDenysPetrov, dkrupp, donat.nagy, Szelethus, a.sidorin, baloghadamsoftware. Herald added a reviewer: NoQ. Herald added a project: All. eandrews requested review of this revision.

[PATCH] D157118: [NFC][Clang] Fix static analyzer concerns

eandrews created this revision. eandrews added reviewers: aaron.ballman, tahonermann. Herald added subscribers: manas, ASDenysPetrov, dkrupp, donat.nagy, Szelethus, a.sidorin, baloghadamsoftware. Herald added a reviewer: NoQ. Herald added a project: All. eandrews requested review of this revision.

[PATCH] D152195: [Clang] Fix access of friend function in local class

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGc1401e9f3e7c: [Clang][Sema] Fix access of friend class in local class (authored by eandrews). Herald added a project: clang. Changed prior to commit

[PATCH] D152195: [Clang] Fix access of friend function in local class

eandrews updated this revision to Diff 528883. eandrews added a comment. Thanks for the review! I added a release note CHANGES SINCE LAST ACTION https://reviews.llvm.org/D152195/new/ https://reviews.llvm.org/D152195 Files: clang/docs/ReleaseNotes.rst clang/lib/Sema/SemaDecl.cpp clang/t

[PATCH] D152195: [Clang] Fix access of friend function in local class

eandrews added a comment. In D152195#4399251 , @erichkeane wrote: > I think the patch looks fine, but this needs a release note. Just so I know - Does every bug fix need a release note now? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D152195/

[PATCH] D152195: [Clang] Fix access of friend function in local class

eandrews created this revision. eandrews added reviewers: erichkeane, aaron.ballman. Herald added a project: All. eandrews requested review of this revision. Clang currently emits an error when a friend of a local class tries to access it's private data members. This patch fixes the bug. https:

[PATCH] D151837: [Clang][Parser] Accept GNU attributes preceding C++ style attributes on templates

This revision was automatically updated to reflect the committed changes. Closed by commit rGcecd8471e499: [Clang][Parser] Accept GNU attributes preceding C++ attributes on templates (authored by eandrews). Herald added a project: clang. Changed prior to commit: https://reviews.llvm.org/D151837

[PATCH] D151837: [Clang][Parser] Accept GNU attributes preceding C++ style attributes on templates

eandrews added inline comments. Comment at: clang/docs/ReleaseNotes.rst:416 + handled, resulting in compilation error. This has been corrected to match the + behaviour exhibited by GCC. erichkeane wrote: > I'll make this change when I commit the patch. Thank

[PATCH] D151837: [Clang][Parser] Accept GNU attributes preceding C++ style attributes on templates

eandrews updated this revision to Diff 527406. eandrews added a comment. Thanks for the review! I've added a release note. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D151837/new/ https://reviews.llvm.org/D151837 Files: clang/docs/ReleaseNotes.rst clang/lib/Parse/ParseTemplate.cpp

[PATCH] D151837: [Clang][Parser] Accept GNU attributes preceding C++ style attributes on templates

eandrews updated this revision to Diff 527382. eandrews added a comment. Thanks for the review! I added a couple more tests. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D151837/new/ https://reviews.llvm.org/D151837 Files: clang/lib/Parse/ParseTemplate.cpp clang/test/Parser/attr-or

[PATCH] D151837: [Clang][Parser] Accept GNU attributes preceding C++ style attributes on templates

eandrews created this revision. eandrews added reviewers: aaron.ballman, erichkeane, compnerd. Herald added a project: All. eandrews requested review of this revision. Clang was rejecting valid code where GNU style attributes preceded C++ style attributes in template declarations as follows: tem

[PATCH] D146535: [Clang] Fix evaluation of parameters of lambda call operator attributes

eandrews added a comment. Can we merge this patch? It will fix regressions introduced by D124351 I see downstream Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D146535/new/ https://reviews.llvm.org/D146535 __

[PATCH] D146535: [Clang] Fix evaluation of parameters of lambda call operator attributes

eandrews accepted this revision. eandrews added a comment. This revision is now accepted and ready to land. In D146535#4210268 , @cor3ntin wrote: > In D146535#4210198 , @eandrews > wrote: > >>> Attributes of lamb

[PATCH] D146535: [Clang] Fix evaluation of parameters of lambda call operator attributes

eandrews added a comment. > Attributes of lambda call operator were evaluated in the context of the > closure object type rather than its operator, Just for my understanding, what did this affect with regards to the if guard for assert? CurContext or something else? I suspected it had something

[PATCH] D124351: [Clang] Implement Change scope of lambda trailing-return-type

eandrews added a comment. In D124351#4208842 , @cor3ntin wrote: > In D124351#4207501 , @eandrews > wrote: > >> This patch causes an assertion when the attribute argument is an integer >> constant expression - ht

[PATCH] D124351: [Clang] Implement Change scope of lambda trailing-return-type

eandrews added a comment. Herald added a subscriber: jplehr. This patch causes an assertion when the attribute argument is an integer constant expression - https://godbolt.org/z/osKx5ejMb and has resulted in test fails downstream since any attribute which uses `VerifyIntegerConstantExpression`

[PATCH] D141375: [SYCL][OpenMP] Fix compilation errors for unsupported __bf16 intrinsics

eandrews added a comment. Thanks for the reviews! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D141375/new/ https://reviews.llvm.org/D141375 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https:

[PATCH] D141375: [SYCL][OpenMP] Fix compilation errors for unsupported __bf16 intrinsics

This revision was automatically updated to reflect the committed changes. Closed by commit rGf81d529f8955: [Clang] Fix compilation errors for unsupported __bf16 intrinsics (authored by eandrews). Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION htt

[PATCH] D141375: [SYCL][OpenMP] Fix compilation errors for unsupported __bf16 intrinsics

eandrews added a comment. In D141375#4041360 , @bader wrote: > LGTM. > I expect this to be a common issue for all single-source offloading > programming models (i.e. CUDA and HIP in addition to SYCL and OpenMP > offload). Probably we can generalize the

[PATCH] D141375: [SYCL][OpenMP] Fix compilation errors for unsupported __bf16 intrinsics

eandrews created this revision. eandrews added reviewers: mikerice, jyu2, bader, jdoerfert, aaron.ballman. Herald added subscribers: Naghasan, Anastasia, ebevhan, guansong, yaxunl. Herald added a project: All. eandrews requested review of this revision. Herald added a subscriber: sstefan1. This pa

[PATCH] D124351: [Clang][WIP] Implement Change scope of lambda trailing-return-type - Take 2

eandrews added a comment. I came across a strange error when capturing arguments in a lambda inside another lambda. I filed an issue here - https://github.com/llvm/llvm-project/issues/59549 Short reproducer: void foo () { constexpr int i = 2; [&]() { [=]() [[clang::annotate_

[PATCH] D138296: [clang] Avoid duplicating ProgramAddressSpace in TargetInfo. NFCI

eandrews added subscribers: erichkeane, aaron.ballman. eandrews added a comment. Functionally this looks ok to me. However I am not sure if CodeGenTypes is the 'right' place for this function to live, considering that other functions with similar functionality are in ASTContext - including overl

[PATCH] D119045: Fix address space for function types with AS qualifier

eandrews added a comment. In D119045#3302129 , @aaron.ballman wrote: > LGTM aside from some nits Thanks! Fixed the nits in commit. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D119045/new/ https://review

[PATCH] D119045: Fix address space for function types with AS qualifier

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGed5b42b74188: Fix address space for function pointers with qualifier (authored by eandrews). Herald added a project: clang. Changed prior to commit:

[PATCH] D119045: Fix address space for function types with AS qualifier

eandrews created this revision. eandrews added reviewers: rjmccall, dylanmckay, bader. eandrews requested review of this revision. This patch fixes a bug introduced in commit 4eaf5846d0e7 - https://reviews.llvm.org/D111566 Co

[PATCH] D111566: [SYCL] Fix function pointer address space

This revision was automatically updated to reflect the committed changes. Closed by commit rG4eaf5846d0e7: [clang] Fix function pointer address space (authored by eandrews). Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews added inline comments. Comment at: clang/test/CodeGen/avr/functionptr-addrspace.c:3 + +int main() { + int (*p)(); When writing the test I noticed an existing crash in the compiler. I am not sure if I am doing something wrong but if you try to assign to

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews updated this revision to Diff 399484. eandrews added a comment. Herald added a subscriber: Jim. Implemented review comments - Remove unnecessary set method and set default value during construction instead - Changed default address space for function pointer for avr target to 1. CHANG

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews marked 3 inline comments as done. eandrews added inline comments. Comment at: clang/include/clang/Basic/TargetInfo.h:763 + /// Set the address space for functions for the given target. + virtual void setProgramAddressSpace() { ProgramAddrSpace = 0; } +

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews updated this revision to Diff 399080. eandrews added a comment. Add program address space to TargetInfo. Targets with non-default address space for functions should explicitly set value. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D111566/new/ https://reviews.llvm.org/D111566

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews marked 2 inline comments as done. eandrews added inline comments. Comment at: clang/lib/AST/ASTContext.cpp:11496 + .getProgramAddressSpace() + : getTargetAddressSpace(T.getQualifiers()); +} rjmccall wrote: > Oh, I'm sorry I

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews updated this revision to Diff 398784. eandrews added a comment. Implement review comments - add a comment + remove unnecessary code CHANGES SINCE LAST ACTION https://reviews.llvm.org/D111566/new/ https://reviews.llvm.org/D111566 Files: clang/include/clang/AST/ASTContext.h clang/

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews added inline comments. Comment at: clang/lib/AST/ASTContext.cpp:11494 + const Type *TypePtr = T.getTypePtr(); + return TypePtr->isFunctionType() + ? llvm::DataLayout(getTargetInfo().getDataLayoutString()) rjmccall wrote: > You can just do `

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews added a comment. In D111566#3228949 , @rjmccall wrote: > Block pointers are actually data pointers and should stay in the generic > address space if they don't have an address space qualifier. That might > require new logic. Thanks! I kept th

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews updated this revision to Diff 398723. eandrews added a comment. Implemented review comment to move logic into function (`getTargetAddressSpace`) as opposed to call site. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D111566/new/ https://reviews.llvm.org/D111566 Files: clang/

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews added inline comments. Comment at: clang/lib/CodeGen/CodeGenTypes.cpp:636-638 +unsigned AS = PointeeType->isFunctionTy() + ? getDataLayout().getProgramAddressSpace() + : Context.getTargetAddressSpace(ETy); rj

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews added a comment. Thanks for the reviews @dylanmckay and @rjmccall ! I agree that moving the logic for functions pointers to `getTargetAddressSpace` makes sense. However, I'm not sure what the consequences are, since that increases the impact of this change quite a bit. I'm not sure if

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews added a comment. ping * 3 Since this patch has been accepted by one code owner, and has been under review for over a month, I plan to submit it by the end of the week. If anyone has feedback/concerns, please comment on the review. CHANGES SINCE LAST ACTION https://reviews.llvm.org/

[PATCH] D112663: [clang-repl] Allow Interpreter::getSymbolAddress to take a mangled name.

eandrews added inline comments. Comment at: clang/unittests/Interpreter/InterpreterTest.cpp:237-240 + std::string MangledName = MangleName(TmpltSpec); + typedef int (*TemplateSpecFn)(void *); + auto fn = (TemplateSpecFn)cantFail(Interp->getSymbolAddress(MangledName)); + EXPEC

[PATCH] D98895: [X86][clang] Disable long double type for -mno-x87 option

eandrews added a comment. In D98895#3119027 , @asavonic wrote: > In D98895#3118821 , @eandrews wrote: > >> This patch causes a regression. >> >> To reproduce - `clang -cc1 -fsycl-is-device -triple spir64 test.cpp` >

[PATCH] D98895: [X86][clang] Disable long double type for -mno-x87 option

eandrews added a comment. This patch causes a regression. To reproduce - `clang -cc1 -fsycl-is-device -triple spir64 test.cpp` // expected-note@+2 {{'bar<__float128>' defined here}} template T bar() { return T(); }; void usage() { // expected-error@+2 {{'bar<__float128>' requires

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews added a comment. ping CHANGES SINCE LAST ACTION https://reviews.llvm.org/D111566/new/ https://reviews.llvm.org/D111566 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D112975: Fix complex types declared using mode TC

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG5c8d3053fa0c: Fix complex types declared using mode TC (authored by eandrews). Herald added a project: clang. Repository: rG LLVM Github Monorepo

[PATCH] D112975: Fix complex types declared using mode TC

eandrews added a comment. In D112975#3101720 , @rjmccall wrote: > For posterity in case someone tracks down this review: `TC` corresponds to an > unspecified 128-bit format, which on some targets is a double-double format > (like `__ibm128_t`) and on ot

[PATCH] D109950: [Clang] Enable IC/IF mode for __ibm128

eandrews added a comment. In D109950#3097652 , @rjmccall wrote: > In D109950#3097544 , @eandrews > wrote: > >> In D109950#3097161 , @rjmccall >> wrote: >> >>> Oh, yes, I

[PATCH] D112975: Fix complex types declared using mode TC

eandrews created this revision. eandrews added reviewers: qiucf, rjmccall. eandrews requested review of this revision. This patch reverts incorrect IR - introduced in commit d11ec6f67e45 (https://reviews.llvm.org/rGd11ec6f67e4

[PATCH] D109950: [Clang] Enable IC/IF mode for __ibm128

eandrews added a comment. In D109950#3097161 , @rjmccall wrote: > Oh, yes, I think this should be preserving the old logic there and just > adding a new clause for explicit requests for ibm128, right? I think the old logic should be preserved yes. Howev

[PATCH] D109950: [Clang] Enable IC/IF mode for __ibm128

eandrews added a comment. This has changed the behavior for - // Define __complex128 type corresponding to __float128 (as in GCC headers). typedef _Complex float __attribute__((mode(TC))) __complex128; void check() { // CHECK: alloca { fp128, fp128 } <- Fails because alloca { x86

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews added inline comments. Comment at: clang/lib/CodeGen/CodeGenTypes.cpp:636-638 +unsigned AS = PointeeType->isFunctionTy() + ? getDataLayout().getProgramAddressSpace() + : Context.getTargetAddressSpace(ETy); aa

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews added a comment. ping CHANGES SINCE LAST ACTION https://reviews.llvm.org/D111566/new/ https://reviews.llvm.org/D111566 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews updated this revision to Diff 379562. eandrews added a comment. Added a test CHANGES SINCE LAST ACTION https://reviews.llvm.org/D111566/new/ https://reviews.llvm.org/D111566 Files: clang/lib/CodeGen/CodeGenTypes.cpp clang/test/CodeGenSYCL/functionptr-addressspace.cpp Index: cl

[PATCH] D111566: [SYCL] Fix function pointer address space

eandrews created this revision. eandrews added reviewers: vlastik, dylanmckay, bader. Herald added subscribers: Naghasan, Anastasia, ebevhan, yaxunl. eandrews requested review of this revision. Functions pointers should be created with program address space. This patch fixes a crash on lvalue ref

[PATCH] D97941: [Reland] "Do not apply calling conventions to MSVC entry points"

This revision was automatically updated to reflect the committed changes. eandrews marked an inline comment as done. Closed by commit rGd8b8f544d9de: [Reland] "Do not apply calling conventions to MSVC entry points" (authored by eandrews). Herald added a project: clang. Repository: rG LLVM Githu

[PATCH] D97941: [Reland] "Do not apply calling conventions to MSVC entry points"

eandrews added inline comments. Comment at: clang/lib/Sema/SemaDecl.cpp:11206-11207 +} else if (FT->getCallConv() != CC_X86StdCall) { + // Default calling convention for WinMain, wWinMain and DllMain is + // __stdcall + FT = Context.adjustFunctionType(

[PATCH] D97941: [Reland] "Do not apply calling conventions to MSVC entry points"

eandrews updated this revision to Diff 329099. eandrews edited the summary of this revision. eandrews added a comment. Implemented review comment to restrict __stdcall default calling convention (for WinMain, wWinMain, and DllMain) to 32 bit Windows. CHANGES SINCE LAST ACTION https://reviews

[PATCH] D97941: [Reland] "Do not apply calling conventions to MSVC entry points"

eandrews created this revision. eandrews added reviewers: rnk, akhuang, dmajor. Herald added a subscriber: mstorsjo. eandrews requested review of this revision. This patch is a second attempt at fixing a link error for MSVC entry points when calling conventions are specified using a flag. Callin

[PATCH] D96538: [SYCL] Ignore file-scope asm during device-side SYCL compilation.

eandrews accepted this revision. eandrews added a comment. LGTM Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D96538/new/ https://reviews.llvm.org/D96538 ___ cfe-commits mailing list cfe-commits@l

[PATCH] D87701: Do not apply calling conventions to MSVC entry points

eandrews added a comment. In D87701#2280246 , @dmajor wrote: > This broke Firefox builds too, in one of our helper binaries that uses a > `wWinMain`, although I'm having trouble writing a minimal reproducer for it. > Simply making a barebones `wWinMain`

[PATCH] D87701: Do not apply calling conventions to MSVC entry points

eandrews added a comment. In D87701#2274860 , @rnk wrote: > lgtm, thanks. Thanks for taking a look! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D87701/new/ https://reviews.llvm.org/D87701 ___

[PATCH] D87701: Do not apply calling conventions to MSVC entry points

This revision was automatically updated to reflect the committed changes. Closed by commit rG4cff1b40dacf: Do not apply calling conventions to MSVC entry points (authored by eandrews). Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://review

[PATCH] D87701: Do not apply calling conventions to MSVC entry points

eandrews created this revision. eandrews added reviewers: rnk, erichkeane. eandrews requested review of this revision. Fix link error for MSVC entry points when calling conventions are specified. MSVC entry points should have default calling convention. https://reviews.llvm.org/D87701 Files:

[PATCH] D72242: Fix crash on value dependent bitfields in if conditions in templates

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit rGa58017e5cae5: Fix type-dependency of bitfields in templates (authored by eandrews). Herald added a project: clang. Reposi

[PATCH] D72242: Fix crash on value dependent bitfields in if conditions in templates

eandrews added a comment. In D72242#1873017 , @smeenai wrote: > I'm not sure why Phabricator is still showing Needs Review, but @rnk's > approval should make this count as accepted. Ok. Thank you. I've pushed the patch. CHANGES SINCE LAST ACTION htt

[PATCH] D72242: Fix crash on value dependent bitfields in if conditions in templates

eandrews added a comment. Actually I just noticed it still says 'Needs review' above. I'm not sure what the protocol is. Can I push the patch? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72242/new/ https://reviews.llvm.org/D72242 ___ cfe

[PATCH] D72242: Fix crash on value dependent bitfields in if conditions in templates

eandrews added a comment. Thanks! I'll push it shortly. Just running a final ninja check-all after updating workspace. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72242/new/ https://reviews.llvm.org/D72242 ___ cfe-commits mailing list cf

[PATCH] D72242: Fix crash on value dependent bitfields in if conditions in templates

eandrews updated this revision to Diff 243049. eandrews edited the summary of this revision. eandrews added a comment. Thanks for taking a look Richard. This patch adds the required value-dependency check and sets type-dependency accordingly. CHANGES SINCE LAST ACTION https://reviews.llvm.org

[PATCH] D72242: Fix crash on value dependent bitfields in if conditions in templates

eandrews added a comment. In D72242#1820908 , @rnk wrote: > I think I liked the first version of this patch better. I would say, if the > AST after instantiation remains the same as it was before D69950 > , then the first

[PATCH] D72242: Fix crash on value dependent bitfields in if conditions in templates

eandrews updated this revision to Diff 237132. eandrews edited the summary of this revision. eandrews added a comment. Semantic analysis for value dependent conditions is now skipped as per Erich's comment. Patch adds an argument to CheckBooleanCondition to still do the required analysis for no

[PATCH] D72242: Fix crash on value dependent bitfields in if conditions in templates

eandrews added a comment. Thanks for taking a look Erich! > I'm concerned about just making this fallthrough to 'false'. These ARE > integral promotions, we just don't know the type size. In this case, when integral promotion is skipped, boolean conversion (C++ 4.12) is done instead when parsi

[PATCH] D72242: Fix crash on value dependent bitfields in if conditions in templates

eandrews created this revision. eandrews added reviewers: rnk, erichkeane, alexfh, alexfh_. This patch is a follow up to D69950 , to fix a new crash on CXX condition expressions in templates, for value dependent bitfields. Clang currently crashes when integral p

[PATCH] D69950: Reapply "Fix crash on switch conditions of non-integer types in templates"

eandrews added a comment. In D69950#1771340 , @mstorsjo wrote: > In D69950#1771133 , @eandrews wrote: > > > In D69950#1770138 , @mstorsjo > > wrote: > > > > > This (when rea

  1   2   >