https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/75226
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> > Making Sema pull the TBAA info out of clang/lib/CodeGen is a layering
> > violation (and probably breaks if we aren't actually generating code). If
> > we need some notion of "aliasing" in Sema, we should pull the relevant code
> > into clang/lib/AST.
>
> That's unfor
efriedma-quic wrote:
It doesn't seem like a good idea to make target-independent logic behave in
target-specific ways; that's going to confusing for both people hacking on
clang, and for users if it's user-visible. Is there some way we can make this
logic consistent across targets?
Maybe we
@@ -418,6 +418,8 @@ void BackendConsumer::anchor() { }
} // namespace clang
bool ClangDiagnosticHandler::handleDiagnostics(const DiagnosticInfo &DI) {
+ if (DI.getSeverity() == DS_Error)
+HasErrors = true;
efriedma-quic wrote:
I'm not sure I like the way
efriedma-quic wrote:
When I said "inconsistencies", I just meant the way the responsibility for
lowering atomics is split between LLVM and clang; I didn't mean anything was
actually broken.
https://github.com/llvm/llvm-project/pull/73176
___
cfe-comm
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/75141
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic closed
https://github.com/llvm/llvm-project/pull/75141
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Please add test coverage for compound assignment and increment/decrement.
This seems like a reasonable extension of the existing integer truncation
checks, but we might want to consider giving it a unique name. Otherwise,
people using integer truncation checks will have t
efriedma-quic wrote:
Pushed revert.
@kartcq please fix the test so it either doesn't depend on DEBUG output, or
uses `REQUIRES: asserts`.
https://github.com/llvm/llvm-project/pull/75141
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://
efriedma-quic wrote:
This is basically the approach I was expecting: we check the type of "long
double" when we build the TargetLowering, and pick appropriate names based on
that.
I expect that for -mlong-double-128, you just want to add a module flag that
overrides the default choice.
I thi
efriedma-quic wrote:
Have you considered the following case?
```
void foo() {
char* arr = new char[]("asdf");
}
```
https://github.com/llvm/llvm-project/pull/76976
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/
Author: efriedma
Date: Tue Jan 15 16:50:44 2019
New Revision: 351284
URL: http://llvm.org/viewvc/llvm-project?rev=351284&view=rev
Log:
[EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp
This is the clang counterpart to D56747.
Patch by Mandeep Singh Grang.
Differential Revision:
Author: efriedma
Date: Mon Jan 21 16:11:17 2019
New Revision: 351766
URL: http://llvm.org/viewvc/llvm-project?rev=351766&view=rev
Log:
[CodeGen] Always use string computed in Sema for PredefinedExpr
We can't use any other string, anyway, because its type wouldn't
match the type of the PredefinedE
(Comments inline.)
> -Original Message-
> From: cfe-commits On Behalf Of
> Doerfert, Johannes Rudolf via cfe-commits
> Sent: Tuesday, January 22, 2019 9:29 AM
> To: Chandler Carruth
> Cc: cfe-commits cfe
> Subject: Re: r351629 - Emit !callback metadata and introduce the callback
> attri
Author: efriedma
Date: Wed Aug 2 16:22:50 2017
New Revision: 309901
URL: http://llvm.org/viewvc/llvm-project?rev=309901&view=rev
Log:
[coverage] Make smaller regions for the first case of a switch.
We never overwrite the end location of a region, so we would end up with
an overly large region wh
Author: efriedma
Date: Thu Aug 3 15:27:36 2017
New Revision: 309995
URL: http://llvm.org/viewvc/llvm-project?rev=309995&view=rev
Log:
[coverage] Special-case calls to noreturn functions.
The code after a noreturn call doesn't execute.
The pattern in the testcase is pretty common in LLVM (a swit
Author: efriedma
Date: Tue Aug 8 13:10:14 2017
New Revision: 310406
URL: http://llvm.org/viewvc/llvm-project?rev=310406&view=rev
Log:
[coverage] Special-case calls to noreturn functions.
The code after a noreturn call doesn't execute.
The pattern in the testcase is pretty common in LLVM (a swit
Author: efriedma
Date: Tue Dec 12 16:14:17 2017
New Revision: 320533
URL: http://llvm.org/viewvc/llvm-project?rev=320533&view=rev
Log:
[Coverage] Always emit unused coverage mappings in the same order.
Non-determinism is confusing at best.
Differential Revision: https://reviews.llvm.org/D41140
Author: efriedma
Date: Fri Aug 24 12:31:52 2018
New Revision: 340640
URL: http://llvm.org/viewvc/llvm-project?rev=340640&view=rev
Log:
[LTO] Fix -save-temps with LTO and unnamed globals.
If all LLVM passes are disabled, we can't emit a summary because there
could be unnamed globals in the IR.
Di
Author: efriedma
Date: Fri Aug 24 13:18:34 2018
New Revision: 340644
URL: http://llvm.org/viewvc/llvm-project?rev=340644&view=rev
Log:
Add REQUIRES: x86-registered-target to test.
(This isn't really x86-specific, but we have to pick some non-Apple
triple to exercise the right codepath.)
Modifie
Author: efriedma
Date: Wed Oct 31 14:31:09 2018
New Revision: 345779
URL: http://llvm.org/viewvc/llvm-project?rev=345779&view=rev
Log:
[ARM64] [Windows] Implement _InterlockedExchangeAdd*_* builtins.
These apparently need to be proper builtins to handle the Windows
SDK.
Differential Revision: ht
Author: efriedma
Date: Wed Oct 31 14:39:41 2018
New Revision: 345781
URL: http://llvm.org/viewvc/llvm-project?rev=345781&view=rev
Log:
[AArch64] [Windows] Emit unwind tables by default.
Unwind tables are necessary even in code that doesn't support
exceptions. The tables are used for setjmp(), an
eli.friedman added a comment.
I don't think we need to use x86-specific operations for sitofp-like
conversions; the C cast is equivalent given that a 32 or 64-bit integer is
always in within the range of a 32-bit float.
Repository:
rL LLVM
https://reviews.llvm.org/D22105
eli.friedman added a comment.
The x86-specific operation is affected by the rounding mode... but so is a C
cast. This is specified by Annex F in the C standard.
Of course, you're going to end up with undefined behavior if you actually
modify the rounding mode because LLVM and clang don't suppo
eli.friedman accepted this revision.
eli.friedman added a comment.
This revision is now accepted and ready to land.
LGTM.
Repository:
rL LLVM
https://reviews.llvm.org/D22105
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llv
What sort of outputs, specifically? Memory outputs are easy; I think the LLVM
IR patch actually supports them already. Register outputs are complicated... I
guess they're also possible, but we would need to come up with some frontend
rule that allows sane code generation. Consider the case wh
Author: efriedma
Date: Thu Feb 7 17:17:49 2019
New Revision: 353493
URL: http://llvm.org/viewvc/llvm-project?rev=353493&view=rev
Log:
[COFF, ARM64] Fix types for _ReadStatusReg, _WriteStatusReg
r344765 added those intrinsics, but used the wrong types.
Patch by Mike Hommey
Differential Revision
Author: efriedma
Date: Fri Feb 8 13:18:46 2019
New Revision: 353569
URL: http://llvm.org/viewvc/llvm-project?rev=353569&view=rev
Log:
[Sema] Make string literal init an rvalue.
This allows substantially simplifying the expression evaluation code,
because we don't have to special-case lvalues whi
Author: efriedma
Date: Fri Feb 8 13:36:04 2019
New Revision: 353571
URL: http://llvm.org/viewvc/llvm-project?rev=353571&view=rev
Log:
[CodeGen][NFC] Update comments in CGExprConstant.cpp.
Modified:
cfe/trunk/lib/CodeGen/CGExprConstant.cpp
Modified: cfe/trunk/lib/CodeGen/CGExprConstant.cpp
t;, line 147, in main
> subprocess.check_output(args, stderr=subprocess.STDOUT).decode()
> File "/usr/lib/python2.7/subprocess.py", line 223, in check_output
> raise CalledProcessError(retcode, cmd, output=output)
> subprocess.CalledProcessError: Command '['
Author: efriedma
Date: Fri Feb 8 18:22:17 2019
New Revision: 353598
URL: http://llvm.org/viewvc/llvm-project?rev=353598&view=rev
Log:
Fix buildbot failure from r353569.
I assumed lvalue-to-rvalue conversions of array type would never
happen, but apparently clang-tidy tries in some cases.
Modif
Fixed in r353598.
-Eli
> -Original Message-
> From: cfe-commits On Behalf Of Eli
> Friedman via cfe-commits
> Sent: Friday, February 8, 2019 6:06 PM
> To: douglas.y...@sony.com
> Cc: cfe-commits@lists.llvm.org
> Subject: [EXT] RE: r353569 - [Sema] Make string l
Author: efriedma
Date: Mon Feb 11 14:54:27 2019
New Revision: 353762
URL: http://llvm.org/viewvc/llvm-project?rev=353762&view=rev
Log:
[Sema] Mark GNU compound literal array init as an rvalue.
Basically the same issue as string init, except it didn't really have
any visible consequences before I
Author: efriedma
Date: Fri Aug 3 15:09:44 2018
New Revision: 338931
URL: http://llvm.org/viewvc/llvm-project?rev=338931&view=rev
Log:
Diagnose invalid cv-qualifiers for friend decls.
Differential Revision: https://reviews.llvm.org/D45712
Modified:
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe
Author: efriedma
Date: Wed Oct 17 14:07:11 2018
New Revision: 344710
URL: http://llvm.org/viewvc/llvm-project?rev=344710&view=rev
Log:
[AArch64] Define __ELF__ for aarch64-none-elf and other similar triples.
"aarch64-none-elf" is commonly used for AArch64 baremetal toolchains.
Differential Revis
Author: efriedma
Date: Thu Oct 25 18:31:57 2018
New Revision: 345354
URL: http://llvm.org/viewvc/llvm-project?rev=345354&view=rev
Log:
[AArch64] Support Windows stack probe command-line arguments.
Adds support for -mno-stack-arg-probe and -mstack-probe-size.
(Not really happy copy-pasting code,
https://github.com/efriedma-quic commented:
I don't really like the whole "sufficiently simple function" thing. It seems
fragile. You should be able to just take a arbitrary internal varargs
function, rewrite its signature to take a va_list argument, rewrite calls to
va_start to make a copy
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/81058
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,701 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache
https://github.com/efriedma-quic updated
https://github.com/llvm/llvm-project/pull/81298
>From d59c262b31937fdd2b907ec11d7f08e4a385007c Mon Sep 17 00:00:00 2001
From: Amirreza Ashouri
Date: Fri, 9 Feb 2024 21:55:03 +0330
Subject: [PATCH 1/4] [clang] Support `__is_trivially_copyable(int()&)==fal
https://github.com/efriedma-quic commented:
Do we need to add handling for `new int[](co_await foo())`
(CodeGenFunction::EmitNewArrayInitializer)?
https://github.com/llvm/llvm-project/pull/80698
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -627,9 +627,11 @@ CodeGenFunction::getJumpDestForLabel(const LabelDecl *D) {
if (Dest.isValid()) return Dest;
// Create, but don't insert, the new block.
+ // FIXME: We do not know `BranchInExprDepth` for the destination and
currently
+ // emit *all* the BranchInExpr
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/80698
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -592,10 +590,14 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr,
llvm::ArrayType *AType,
// observed to be unnecessary.
if (endOfInit.isValid()) Builder.CreateStore(element, endOfInit);
}
-
-LValue elementLV = CGF.MakeAddrLValue(
-Address(e
efriedma-quic wrote:
Looks like a bug in the SPARC backend.
https://github.com/llvm/llvm-project/pull/73176#pullrequestreview-1811677691
indicated that atomic expansion was working correctly for all backends, but I
guess it isn't working correctly on SPARC.
https://github.com/llvm/llvm-proj
@@ -592,10 +590,14 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr,
llvm::ArrayType *AType,
// observed to be unnecessary.
if (endOfInit.isValid()) Builder.CreateStore(element, endOfInit);
}
-
-LValue elementLV = CGF.MakeAddrLValue(
-Address(e
efriedma-quic wrote:
> IIUC you're suggesting movint the TBAA data origination from CodeGen into
> (probably) Sema and/or TargetInfo and then deriving the LLVM info in CodeGen
> from that. I.e. keep once source of truth, but move where it is?
Right; move the core computation to AST, and then t
https://github.com/efriedma-quic commented:
We could consider keeping the warning group, not actually guarding any warning,
so we don't warn on `-Wno-gnu-binary-literal`.
Otherwise looks fine.
https://github.com/llvm/llvm-project/pull/81658
___
cfe-c
efriedma-quic wrote:
I can't tell what you're trying to fix here. Is this fixing a crash? Or is
the check redundant? Or is it necessary for some followup change you want to
make?
https://github.com/llvm/llvm-project/pull/81669
___
cfe-commits mail
https://github.com/efriedma-quic approved this pull request.
LGTM
(It feels a little weird that the types in the clang AST don't actually match
the LLVM builtin, but I guess it's not likely to actually cause any issues.)
https://github.com/llvm/llvm-project/pull/81669
_
efriedma-quic wrote:
> > I don't really like the whole "sufficiently simple function" thing. It
> > seems fragile. You should be able to just take a arbitrary internal varargs
> > function, rewrite its signature to take a va_list argument, rewrite calls
> > to va_start to make a copy of that v
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/81849
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic approved this pull request.
LGTM
Note you can get a similar crash using `enum x { X = (__uint128_t)(1<<64) };`.
I'm a little surprised we haven't run into this before C23.
https://github.com/llvm/llvm-project/pull/81760
efriedma-quic wrote:
> If we ignore that design and run functions through the block splitting
> unnecessarily, we win a combinatorial increase in required testing, a
> decrease in emitted code quality (spurious extra functions), an inability to
> pattern match on fprintf->vfprintf style code t
@@ -592,10 +590,14 @@ void AggExprEmitter::EmitArrayInit(Address DestPtr,
llvm::ArrayType *AType,
// observed to be unnecessary.
if (endOfInit.isValid()) Builder.CreateStore(element, endOfInit);
}
-
-LValue elementLV = CGF.MakeAddrLValue(
-Address(e
efriedma-quic wrote:
Missing semantic analysis. Since the signature is unspecified in Builtin.td,
you have to check that there's one argument, and that argument is an integer.
That code should go in SemaChecking.cpp.
You can leave constant evaluation to a followup, sure.
https://github.com/
efriedma-quic wrote:
Unaligned accesses require that SCTLR.A is 0, SCTLR.U is 1, and that the memory
in question is configured as "normal" memory. Almost all operating systems do
in fact configure their registers/memory this way, but on baremetal it's not
really a safe assumption. Changing th
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/79382
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4655,6 +4655,13 @@ void CodeGenFunction::EmitCallArg(CallArgList &args,
const Expr *E,
return emitWritebackArg(*this, args, CRE);
}
+ // If an argument is an array paramter expression being passed through. Emit
+ // the argument to a temporary and pass the tempora
@@ -1126,6 +1126,7 @@ class ConstExprEmitter :
case CK_NonAtomicToAtomic:
case CK_NoOp:
case CK_ConstructorConversion:
+case CK_HLSLArrayRValue:
efriedma-quic wrote:
We shouldn't accept CK_HLSLArrayRValue casts here (or if we do, we need to do
@@ -10900,6 +10936,10 @@ QualType ASTContext::mergeTypes(QualType LHS, QualType
RHS, bool OfBlockPointer,
assert(LHS != RHS &&
"Equivalent pipe types should have already been handled!");
return {};
+ case Type::ArrayParameter:
+if (RHS != LHS)
-
https://github.com/efriedma-quic commented:
This seems like the right direction.
https://github.com/llvm/llvm-project/pull/79382
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1442,6 +1445,7 @@ static bool castPreservesZero(const CastExpr *CE) {
case CK_BitCast:
case CK_ToUnion:
case CK_ToVoid:
+ case CK_HLSLArrayRValue:
efriedma-quic wrote:
Probably should be false, like other lvalue-to-rvalue casts?
https://github.com/
@@ -500,6 +500,7 @@ ComplexPairTy ComplexExprEmitter::EmitCast(CastKind CK,
Expr *Op,
case CK_NoOp:
case CK_LValueToRValue:
case CK_UserDefinedConversion:
+ case CK_HLSLArrayRValue:
efriedma-quic wrote:
The result of an CK_HLSLArrayRValue can't be a co
@@ -2231,7 +2231,8 @@ Value *ScalarExprEmitter::VisitCastExpr(CastExpr *CE) {
case CK_UserDefinedConversion:
return Visit(const_cast(E));
- case CK_NoOp: {
+ case CK_NoOp:
+ case CK_HLSLArrayRValue: {
efriedma-quic wrote:
It shouldn't be possible to
@@ -3173,41 +3174,46 @@ class ArrayType : public Type, public
llvm::FoldingSetNode {
return T->getTypeClass() == ConstantArray ||
T->getTypeClass() == VariableArray ||
T->getTypeClass() == IncompleteArray ||
- T->getTypeClass() == DependentS
https://github.com/efriedma-quic commented:
Oh, this is making a bit more sense now... I didn't realize this was overriding
method that handles char/short already. And I guess for BPF targets, you can
assume "long" is 64 bits.
That said, this isn't handling "unsigned int" correctly. "unsigne
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/84874
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> My understanding is that you refer to the following part of the
> [specification](https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf):
Yes. For example, on RISC-V, the function `long f(unsigned g) { return (int)g;
}` compiles to just a "ret".
> clang would
@@ -259,6 +259,10 @@ Bug Fixes in This Version
operator.
Fixes (#GH83267).
+- Clang no longer fails to codegen static ``const`` variables whose
initialiser performs
+ a floating-point division by 0 in C23.
+ Fixes (#GH84784).
efriedma-quic wrote:
We us
@@ -20,6 +20,12 @@ class RISCVBuiltin :
TargetBuiltin {
let Attributes = [NoThrow, Const] in {
//===--===//
+// Zicsr extension.
+//===--==
@@ -147,6 +147,7 @@ struct ImplicitConversionData {
const TypeDescriptor &FromType;
const TypeDescriptor &ToType;
/* ImplicitConversionCheckKind */ unsigned char Kind;
+ unsigned int BitfieldBits;
efriedma-quic wrote:
Do we have an ABI stability policy
@@ -0,0 +1,61 @@
+// RUN: %clang -fsanitize=implicit-bitfield-conversion -target x86_64-linux -S
-emit-llvm -o - %s | FileCheck %s
--check-prefixes=CHECK,CHECK-BITFIELD-CONVERSION
efriedma-quic wrote:
I'd like to see some testcases that run in C++ mode.
https:
efriedma-quic wrote:
A report from the field: we had an ignorelist that contained
`[cfi-vcall|cfi-nvcall|cfi-icall]`. This was recommended syntax from the
documentation
(https://releases.llvm.org/17.0.1/tools/clang/docs/SanitizerSpecialCaseList.html)...
but it broke with the transition. Thi
efriedma-quic wrote:
CC @llvm/clang-vendors
> I [announced this change on
> discourse](https://discourse.llvm.org/t/use-glob-instead-of-regex-for-specialcaselists/71666?u=ellishg)
> last year.
"Use glob instead of regex for SpecialCaseLists" doesn't mean anything for
anyone not actively work
efriedma-quic wrote:
See also #80195 (CC @nickdesaulniers).
gcc on aarch64 Linux only supports _Float128, not __float128; this seems like a
bit of a compatibility hazard.
https://github.com/llvm/llvm-project/pull/85070
___
cfe-commits mailing list
cf
efriedma-quic wrote:
The primary problem with allowing flexible arrays alone in structs/unions is
that you end up with a zero-size type. This leads to weird semantic issues
because standard C/C++ doesn't have any provision for zero-size types: pointer
arithmetic, struct layout, and initializa
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
@@ -1,13 +1,158 @@
-// RUN: %clang_cc1 %s -verify=c -fsyntax-only
-// RUN: %clang_cc1 %s -verify -fsyntax-only -x c++
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility
-// RUN: %clang_cc1 %s -verify -fsyntax-only -fms-compatibility -x c++
+// RUN: %clang_cc1 %s -veri
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/77907
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic commented:
Code change looks fine; the regression test needs a few tweaks.
https://github.com/llvm/llvm-project/pull/77907
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -x c -o - %s |
FileCheck %s
+
+typedef struct { struct {} a; } empty;
+
+// CHECK-LABEL: define{{.*}} void @{{.*}}empty_record_t
efriedma-quic wrote:
I think the logic the code is using is that t67 is actually properly aligned:
it's a type with size 8 and alignment 4, so everything is fine. If that's not
right, we should tweak the relevant logic (around line 2104).
Specifically checking whether a type crosses an 8-byte
@@ -3504,6 +3504,47 @@ argument can be of any unsigned integer type.
``__builtin_popcount{,l,ll}`` builtins, with support for other integer types,
such as ``unsigned __int128`` and C23 ``unsigned _BitInt(N)``.
+``__builtin_clzg`` and ``__builtin_ctzg``
+---
https://github.com/efriedma-quic edited
https://github.com/llvm/llvm-project/pull/83431
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic approved this pull request.
LGTM with one minor comment
https://github.com/llvm/llvm-project/pull/83431
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/84230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
The code in question is comparing what Sema thinks the size of a variable
should be, versus the size of the variable we're actually emitting into LLVM
IR. So try dumping the value of "Init". If it looks wrong, we need to fix
constant emission. If it's right, probably so
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/77907
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
> because we don't yet support non-zero initialization (as described in commit
> [5955a0f](https://github.com/llvm/llvm-project/commit/5955a0f9375a8c0b134eeb4a8de5155dcce7c94f))
I'm confused. We support non-zero init, and there are tests for non-zero init
in that commit.
@@ -886,28 +886,16 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver
&D,
} else {
// Assume pre-ARMv6 doesn't support unaligned accesses.
//
-// ARMv6 may or may not support unaligned accesses depending on the
-// SCTLR.U bit, which is architecture
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/82359
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Please fix your GitHub settings so your email address is public. Looks like
the bot didn't trigger for some reason; see
https://github.com/llvm/llvm-project/pull/82429#issuecomment-1955214651 for the
normal message.
https://github.com/llvm/llvm-project/pull/82359
___
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/82400
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
This seems like it messes up the metadata in a different way: we have no
representation of the bitfield at all, so it looks like it's padding.
I think we want to treat multiple adjacent bitfields as a single "field". So
NamedBitfields from the testcase would have three fi
https://github.com/efriedma-quic approved this pull request.
I'm not sure there's really much point to passing around a const reference to a
CGRecordLowering; all the uses are in one file, so const-correctness doesn't
seem to help that much.
But if you want to do it this way, that's fine; LGTM
@@ -294,18 +297,49 @@ CodeGenTBAA::CollectFields(uint64_t BaseOffset,
return false;
const ASTRecordLayout &Layout = Context.getASTRecordLayout(RD);
+const CGRecordLayout &CGRL = CGTypes.getCGRecordLayout(RD);
unsigned idx = 0;
-for (RecordDecl::field
@@ -294,18 +297,49 @@ CodeGenTBAA::CollectFields(uint64_t BaseOffset,
return false;
const ASTRecordLayout &Layout = Context.getASTRecordLayout(RD);
+const CGRecordLayout &CGRL = CGTypes.getCGRecordLayout(RD);
unsigned idx = 0;
-for (RecordDecl::field
201 - 300 of 1001 matches
Mail list logo
