[clang] [clang][Parse] Use consistent Scope::ScopeFlags enum values (NFC) (PR #159275)

https://github.com/brunodf-snps edited https://github.com/llvm/llvm-project/pull/159275 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Function type attribute to prevent CFI instrumentation (PR #135836)

https://github.com/brunodf-snps edited https://github.com/llvm/llvm-project/pull/135836 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Function type attribute to prevent CFI instrumentation (PR #135836)

@@ -9283,8 +9283,14 @@ static AssignConvertType checkPointerTypesForAssignment(Sema &S, return AssignConvertType::IncompatibleFunctionPointer; return AssignConvertType::IncompatiblePointer; } - if (!S.getLangOpts().CPlusPlus && S.IsFunctionConversion(ltrans, rtran

[clang] [clang][Sema] Avoid warnings when mixing diagnostic categories (NFC) (PR #159316)

brunodf-snps wrote: Tagging @erichkeane @Sirraide https://github.com/llvm/llvm-project/pull/159316 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang] Avoid warnings about enum mismatch in ternary expressions. NFC. (PR #159338)

brunodf-snps wrote: @mstorsjo It seems you are (by coincidence) looking into warnings of a gcc build at the same time as I was. There was a third PR about a gcc warning: #158635 https://github.com/llvm/llvm-project/pull/159338 ___ cfe-commits mailing

[clang] [clang][Parse] Use consistent Scope::ScopeFlags enum values (NFC) (PR #159275)

brunodf-snps wrote: Tagging @cor3ntin @erichkeane @Sirraide (Feel free to merge this if you approve, I have no commit access.) https://github.com/llvm/llvm-project/pull/159275 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.

[clang] [clang][Sema] Avoid warnings when mixing diagnostic categories (NFC) (PR #159316)

brunodf-snps wrote: Example of compiler warnings: https://godbolt.org/z/4jGb941f4 https://github.com/llvm/llvm-project/pull/159316 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Sema] Avoid warnings when mixing diagnostic categories (NFC) (PR #159316)

https://github.com/brunodf-snps created https://github.com/llvm/llvm-project/pull/159316 These statements conditionally select between diagnostics of different categories (common vs. sema). Although the diagnostic IDs do not overlap between categories, they are organized in different enums, an

[clang] [clang][Parse] use consistent Scope::ScopeFlags enum values [NFC] (PR #159275)

brunodf-snps wrote: This is an example of the warning triggered when using literal 0: https://godbolt.org/z/1zcb488rr This is an example of similar code that uses NoScope instead of literal 0: https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Sema/Scope.h#L313 https://github.c

[clang] [clang][Parse] use consistent Scope::ScopeFlags enum values (NFC) (PR #159275)

https://github.com/brunodf-snps edited https://github.com/llvm/llvm-project/pull/159275 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][Parse] use consistent Scope::ScopeFlags enum values [NFC] (PR #159275)

https://github.com/brunodf-snps created https://github.com/llvm/llvm-project/pull/159275 Commit 438863a changed the underlying type of the Scope::ScopeFlags from int to unsigned. This triggers type mismatch warnings from specific compilers when the enum's values are combined in operations with

[clang] [NFC] Fix Parens on assertion from 147514 (PR #158635)

@@ -2142,9 +2142,9 @@ Value *ScalarExprEmitter::VisitInitListExpr(InitListExpr *E) { bool Ignore = TestAndClearIgnoreResultAssign(); (void)Ignore; unsigned NumInitElements = E->getNumInits(); - assert(Ignore == false || - (NumInitElements == 0 && E->getType()->i

[clang] [NFC] Fix Parens on assertion from 147514 (PR #158635)

brunodf-snps wrote: Thanks for picking this up! https://github.com/llvm/llvm-project/pull/158635 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [NFC] Fix Parens on assertion from 147514 (PR #158635)

@@ -2142,9 +2142,9 @@ Value *ScalarExprEmitter::VisitInitListExpr(InitListExpr *E) { bool Ignore = TestAndClearIgnoreResultAssign(); (void)Ignore; unsigned NumInitElements = E->getNumInits(); - assert(Ignore == false || - (NumInitElements == 0 && E->getType()->i

[clang] [Clang] Fix crash on `void{}` (PR #147514)

@@ -2114,8 +2114,10 @@ static int getAsInt32(llvm::ConstantInt *C, llvm::Type *I32Ty) { Value *ScalarExprEmitter::VisitInitListExpr(InitListExpr *E) { bool Ignore = TestAndClearIgnoreResultAssign(); (void)Ignore; - assert (Ignore == false && "init list ignored"); unsig

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

brunodf-snps wrote: Could someone with commit access please merge this? Thanks! https://github.com/llvm/llvm-project/pull/137719 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

brunodf-snps wrote: (Not sure if this requires re-approval, but I think this is ready to be merged.) https://github.com/llvm/llvm-project/pull/137719 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinf

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

https://github.com/brunodf-snps updated https://github.com/llvm/llvm-project/pull/137719 >From d63c8fe4fcc8e89933bf3c1cc176941b0b9094fa Mon Sep 17 00:00:00 2001 From: Bruno De Fraine Date: Mon, 28 Apr 2025 14:12:00 +0200 Subject: [PATCH 1/6] [clang][CodeGen] Make tbaa-array test more robust Av

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

brunodf-snps wrote: > I was still adding test cases involving may_alias, but I still found problems This has been solved in 1a40063bc73ee468cb6c8634505232b6f2d833ec. This requires to update the member types in the struct type node in case of an array member with may_alias tag. I found it is t

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

https://github.com/brunodf-snps updated https://github.com/llvm/llvm-project/pull/137719 >From d63c8fe4fcc8e89933bf3c1cc176941b0b9094fa Mon Sep 17 00:00:00 2001 From: Bruno De Fraine Date: Mon, 28 Apr 2025 14:12:00 +0200 Subject: [PATCH 1/5] [clang][CodeGen] Make tbaa-array test more robust Av

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

brunodf-snps wrote: Hm, I was still adding test cases involving may_alias, but I still found problems with the following: ``` typedef int __attribute__((may_alias)) aliasing_int; typedef int __attribute__((may_alias)) aliasing_array[10]; struct E { aliasing_int x[4]; aliasing_array y; }; ``` B

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

@@ -28,25 +30,39 @@ int bar(C *c) { int bar2(C *c) { // CHECK-NEW-LABEL: _Z4bar2P1C -// CHECK-NEW: load i32, {{.*}}, !tbaa [[TAG_int:!.*]] +// CHECK-NEW: load i32, {{.*}}, !tbaa [[TAG_C_x:!.*]] return c->x[2]; } int bar3(C *c, int j) { // CHECK-NEW-LABEL: _Z4bar3P1Ci -

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

https://github.com/brunodf-snps updated https://github.com/llvm/llvm-project/pull/137719 >From d63c8fe4fcc8e89933bf3c1cc176941b0b9094fa Mon Sep 17 00:00:00 2001 From: Bruno De Fraine Date: Mon, 28 Apr 2025 14:12:00 +0200 Subject: [PATCH 1/4] [clang][CodeGen] Make tbaa-array test more robust Av

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

@@ -4503,7 +4503,29 @@ LValue CodeGenFunction::EmitArraySubscriptExpr(const ArraySubscriptExpr *E, E->getType(), !getLangOpts().PointerOverflowDefined, SignedIndices, E->getExprLoc(), &arrayType, E->getBase()); EltBaseInfo = ArrayLV.getBaseInfo(); -EltT

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

brunodf-snps wrote: > I'm surprised we need all this. Since we don't distinguish arrays from their > elements in TBAA, is it not sufficient to just make sure that array subscript > expressions produce an l-value with the same TBAA metadata as their base > l-value? The code is written after [t

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

https://github.com/brunodf-snps updated https://github.com/llvm/llvm-project/pull/137719 >From d63c8fe4fcc8e89933bf3c1cc176941b0b9094fa Mon Sep 17 00:00:00 2001 From: Bruno De Fraine Date: Mon, 28 Apr 2025 14:12:00 +0200 Subject: [PATCH 1/3] [clang][CodeGen] Make tbaa-array test more robust Av

[clang] [CodeGen] Add TBAA struct path info for array members (PR #137719)

brunodf-snps wrote: > @kosarev @fhahn @rjmccall @efriedma-quic @hfinkel Ping. @AaronBallman @nikic any idea who else could review TBAA changes? https://github.com/llvm/llvm-project/pull/137719 ___ cfe-commits mailing list cfe-commits@lists.llvm.org h

[clang] [TBAA] Refine pointer-tbaa for void pointers by pointer depth (PR #126047)

brunodf-snps wrote: @Endilll @rjmccall OK to merge. https://github.com/llvm/llvm-project/pull/126047 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [TBAA] Refine pointer-tbaa for void pointers by pointer depth (PR #126047)

brunodf-snps wrote: If no other remarks get raised, I think this can be merged in a day or two? (Will have to be done by someone with commit access.) https://github.com/llvm/llvm-project/pull/126047 ___ cfe-commits mailing list cfe-commits@lists.llvm.

[clang] [TBAA] Refine pointer-tbaa for void pointers by pointer depth (PR #126047)

brunodf-snps wrote: > I'm not qualified to review this, so please make sure you understand changes > to CWG158 test and they are what you expect. Specifically, I'd like to avoid > updating the test just to make FileCheck happy. All the updates to FileCheck patterns match what I expected. The a

[clang] [TBAA] Refine pointer-tbaa for void pointers by pointer depth (PR #126047)

@@ -80,6 +80,28 @@ llvm::MDNode *CodeGenTBAA::getChar() { return Char; } +llvm::MDNode *CodeGenTBAA::getAnyPtr(unsigned PtrDepth) { + assert(PtrDepth >= 1 && "Pointer must have some depth"); + + // Populate at least PtrDepth elements in AnyPtrs. These are the type nodes +

[clang] [TBAA] Refine pointer-tbaa for void pointers by pointer depth (PR #126047)

https://github.com/brunodf-snps updated https://github.com/llvm/llvm-project/pull/126047 >From f516639a2bfe5cad76ac82684877f46ac6260077 Mon Sep 17 00:00:00 2001 From: Bruno De Fraine Date: Thu, 6 Feb 2025 11:50:44 +0100 Subject: [PATCH 1/4] [TBAA] Refine pointer-tbaa for void pointers by pointe

[clang] [TBAA] Refine pointer-tbaa for void pointers by pointer depth (PR #126047)

@@ -256,7 +277,7 @@ llvm::MDNode *CodeGenTBAA::getTypeInfoHelper(const Type *Ty) { // similar-types rule. const auto *RT = Ty->getAs(); if (!RT) -return AnyPtr; +return getAnyPtr(); brunodf-snps wrote: Yes, I agree this shoul

[clang] [TBAA] Refine pointer-tbaa for void pointers by pointer depth (PR #126047)

https://github.com/brunodf-snps updated https://github.com/llvm/llvm-project/pull/126047 >From f516639a2bfe5cad76ac82684877f46ac6260077 Mon Sep 17 00:00:00 2001 From: Bruno De Fraine Date: Thu, 6 Feb 2025 11:50:44 +0100 Subject: [PATCH 1/3] [TBAA] Refine pointer-tbaa for void pointers by pointe

[clang] [TBAA] Don't emit pointer-tbaa for void pointers. (PR #122116)

brunodf-snps wrote: > I think we can continue to refine our implementation, yeah. [...] The > supertype-ish reasoning I laid out above seems like the right idea. Thanks. FWIW, I think this can be implemented as laid out in #126047. https://github.com/llvm/llvm-project/pull/122116 _

[clang] [TBAA] Refine pointer-tbaa for void pointers by pointer depth (PR #126047)

https://github.com/brunodf-snps created https://github.com/llvm/llvm-project/pull/126047 Commit 77d3f8a avoids distinct tags for any pointers where the ultimate pointee type is `void`, to solve breakage in real-world code that uses (indirections to) `void*` for polymorphism over different poin

[clang] [TBAA] Don't emit pointer-tbaa for void pointers. (PR #122116)

brunodf-snps wrote: > We're documenting a weaker guarantee than we implement, yes. OK, thanks. I guess the wording "in Clang 20, [...] Clang now distinguishes different pointers by their pointee type, except as limited by the relaxations around qualifiers and `void*` described above" led me to

[clang] [TBAA] Don't emit pointer-tbaa for void pointers. (PR #122116)

brunodf-snps wrote: I read about this commit in LLVM weekly. Thanks @fhahn and @rjmccall for adding documentation about strict aliasing! This is always a difficult topic for our users. One remark though. The documentation states: > `void*` is permitted to alias any pointer type, `void**` is pe

[clang] [clang][CodeGen] Emit improved memory effects and return status for AsmStmt (PR #110510)

brunodf-snps wrote: > Do we want nocapture markings on memory operands? I had a chance to discuss this with @nikic and he brought up the LEA instruction. The following would capture the address the `b` field: ``` asm("lea %0, %1" : "=r" (r) : "m" (p[i].b)); ``` I could not find back if you ar

[clang] [clang][CodeGen] Emit improved memory effects and return status for AsmStmt (PR #110510)

brunodf-snps wrote: > We need documentation for the exact assumptions we're making here. Sure, we can try to work on this (and your other remarks). But what do you have in mind? Since this form of inline assembly is a gcc extension, I consider the gcc documentation and implementation authorita

[clang] [clang][CodeGen] Emit improved memory effects and return status for AsmStmt (PR #110510)

brunodf-snps wrote: The intention is to enable LLVM to do more of the optimizations that GCC does around inline asm statements. The following example demonstrates this: https://godbolt.org/z/53rzbjW7z All of the test cases marked as "MISSED" are also optimized by LLVM with this patch, except f

[clang] [clang][CodeGen] Emit improved memory effects and return status for AsmStmt (PR #110510)

https://github.com/brunodf-snps created https://github.com/llvm/llvm-project/pull/110510 This patch adds an appropriate LLVM memory effects attribute and `willreturn` attribute to asm call instructions for extended asm statements. The existing code of EmitAsmStmt seems to have been written bef

[clang] [clang][CodeGen] Fix EmitInvariantStart for non-zero addrspace (PR #94346)

brunodf-snps wrote: @efriedma-quic Thanks for the review! Could you merge this request on our behalf? (No commit access) https://github.com/llvm/llvm-project/pull/94346 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi

[clang] [clang][CodeGen] Fix EmitInvariantStart for non-zero addrspace (PR #94346)

brunodf-snps wrote: Another round of tagging to try to get a review: @efriedma-quic @asl @AaronBallman can you help with reviewing or getting a reviewer? This should really be a trivial patch, so not much work at all. https://github.com/llvm/llvm-project/pull/94346

[clang] [clang][CodeGen] Fix EmitInvariantStart for non-zero addrspace (PR #94346)

brunodf-snps wrote: Tagging some possible reviewers: @zygoloid @AnastasiaStulova @rjmccall https://github.com/llvm/llvm-project/pull/94346 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm

[clang] [clang][CodeGen] Fix EmitInvariantStart for non-zero addrspace (PR #94346)

https://github.com/brunodf-snps created https://github.com/llvm/llvm-project/pull/94346 The `llvm.invariant.start` intrinsic is already overloaded to work with memory objects in any address space. We simply instantiate the intrinsic with the appropriate pointer type. Fixes #94345. >From ea1a

[clang] [Driver] Remove dead -freroll-loops flag (PR #82254)

@@ -3871,10 +3871,6 @@ def funroll_loops : Flag<["-"], "funroll-loops">, Group, HelpText<"Turn on loop unroller">, Visibility<[ClangOption, CC1Option]>; def fno_unroll_loops : Flag<["-"], "fno-unroll-loops">, Group, HelpText<"Turn off loop unroller">, Visibility<[ClangOpti

[llvm] [flang] [clang] [InstCombine] Canonicalize constant GEPs to i8 source element type (PR #68882)

@@ -2282,6 +2282,15 @@ Instruction *InstCombinerImpl::visitGetElementPtrInst(GetElementPtrInst &GEP) { if (MadeChange) return &GEP; + // Canonicalize constant GEPs to i8 type. brunodf-snps wrote: Reading about the [planned steps](https://www.npopov.c