Author: Eli Friedman
Date: 2022-11-16T15:13:33-08:00
New Revision: 0fcb26c5b6487bf9b31670122f8c931ac020bb34
URL:
https://github.com/llvm/llvm-project/commit/0fcb26c5b6487bf9b31670122f8c931ac020bb34
DIFF:
https://github.com/llvm/llvm-project/commit/0fcb26c5b6487bf9b31670122f8c931ac020bb34.diff
Author: Eli Friedman
Date: 2022-06-24T09:58:31-07:00
New Revision: e11bf8de729a4d6eb0d3b5cf154f900cddc522d3
URL:
https://github.com/llvm/llvm-project/commit/e11bf8de729a4d6eb0d3b5cf154f900cddc522d3
DIFF:
https://github.com/llvm/llvm-project/commit/e11bf8de729a4d6eb0d3b5cf154f900cddc522d3.diff
@@ -10752,6 +10752,68 @@ Value
*CodeGenFunction::EmitAArch64BuiltinExpr(unsigned BuiltinID,
return Load;
}
+ if (BuiltinID == AArch64::BI_CopyDoubleFromInt64 ||
+ BuiltinID == AArch64::BI_CopyFloatFromInt32 ||
+ BuiltinID == AArch64::BI_CopyInt32FromFloat ||
@@ -10779,6 +10779,70 @@ Value
*CodeGenFunction::EmitAArch64BuiltinExpr(unsigned BuiltinID,
return Load;
}
+ if (BuiltinID == AArch64::BI_CopyDoubleFromInt64 ||
+ BuiltinID == AArch64::BI_CopyFloatFromInt32 ||
+ BuiltinID == AArch64::BI_CopyInt32FromFloat ||
@@ -270,6 +269,20 @@ TARGET_HEADER_BUILTIN(__readx18word, "UsUNi", "nh",
INTRIN_H, ALL_MS_LANGUAGES,
TARGET_HEADER_BUILTIN(__readx18dword, "UNiUNi", "nh", INTRIN_H,
ALL_MS_LANGUAGES, "")
TARGET_HEADER_BUILTIN(__readx18qword, "ULLiUNi", "nh", INTRIN_H,
ALL_MS_LANGUAGES, "")
efriedma-quic wrote:
It looks like the Itanium mangleTypeName() canonicalizes the type itself;
should the MSVC mangleTypeName do the same thing?
https://github.com/llvm/llvm-project/pull/66816
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ht
@@ -10779,6 +10779,70 @@ Value
*CodeGenFunction::EmitAArch64BuiltinExpr(unsigned BuiltinID,
return Load;
}
+ if (BuiltinID == AArch64::BI_CopyDoubleFromInt64 ||
+ BuiltinID == AArch64::BI_CopyFloatFromInt32 ||
+ BuiltinID == AArch64::BI_CopyInt32FromFloat ||
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/66554
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
I guess this ends up producing a CK_NoOp CastExpr? That's probably okay, but
can we amend the documentation for CK_NoOp to give this as an example?
https://github.com/llvm/llvm-project/pull/65918
___
cfe-commits mailing list
cfe-
efriedma-quic wrote:
I guess this ends up producing a CK_NoOp CastExpr? That's probably okay, but
can we amend the documentation for CK_NoOp to give this as an example?
https://github.com/llvm/llvm-project/pull/65918
___
cfe-commits mailing list
cfe-
efriedma-quic wrote:
LGTM
https://github.com/llvm/llvm-project/pull/65918
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
I didn't get an an email notification for that.
https://github.com/llvm/llvm-project/pull/67066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Maybe start a discourse thread to get more eyes on this discussion? We might
be able to use a hook to make llvmbot do something automatically.
https://github.com/llvm/llvm-project/pull/67066
___
cfe-commits mailing list
cfe-commi
efriedma-quic wrote:
This patch seems sort of contradictory to me. You're encouraging users to pass
a non-constant slice_offset, presumably because we expect the backend to
optimize it... but at the same time, you're special-casing constant
slice_offsets because you don't expect the backend t
efriedma-quic wrote:
We could go with a clang fix, but also make the backend report_fatal_error if
you try to use llvm.ctors with UseInitArray on mingw. That keeps everything
consistent while also making sure non-clang frontends don't miscompile.
https://github.com/llvm/llvm-project/pull/6857
efriedma-quic wrote:
Hmm...
Maybe the backend should have some notion of a default ctors section. So if
the frontend doesn't explicitly specify anything, the backend tries to pick the
right default.
https://github.com/llvm/llvm-project/pull/68571
_
efriedma-quic wrote:
Doesn't UseInitArray default to false in LLVM?
Anyway, we already have ways to make booleans optional; it's just a matter of
implementing a "default" state, which we already do for certain options like
code models. I don't think there's any fundamental architectural work i
efriedma-quic wrote:
It's only breaking for downstreams that were messing with the option in the
first place. Searching GitHub, the only downstream I can find that actually
touches it is rustc.
I understand it's simpler to just override the behavior for MinGW, but I think
it's really confusi
https://github.com/efriedma-quic approved this pull request.
Whatever we decide to do on the LLVM side, this seems fine for the clang side.
It looks like clang uses the value of UseInitArray for some ObjC stuff, in
addition to passing it to the backend, so we need the right value in clang in
efriedma-quic wrote:
On targets that don't use the Unix .ctors/.init_array convention, the option
doesn't make any sense, so we should just ignore it. For example, the AIX
target overrides emitXXStructorList.
https://github.com/llvm/llvm-project/pull/68571
efriedma-quic wrote:
For reference, can you give a couple examples of code where this is triggering?
If this is triggering in practice, do we want a real driver option to control
the sanitizer? The alignment attributes themselves?
https://github.com/llvm/llvm-project/pull/69240
__
@@ -14,8 +14,8 @@ class B : A {
// NO-AS: @_ZTISt9type_info = external constant ptr
// AS: @_ZTIi = external addrspace(1) constant ptr addrspace(1)
// NO-AS: @_ZTIi = external constant ptr
-// AS: @_ZTVN10__cxxabiv117__class_type_infoE = external addrspace(1) global
ptr addrsp
efriedma-quic wrote:
I don't think we need an end-to-end testcase; it should be sufficient to have
testcases for clang->llvm IR and llvm IR->asm. So should be fine as-is.
https://github.com/llvm/llvm-project/pull/65278
___
cfe-commits mailing list
cf
efriedma-quic wrote:
I don't think we need an end-to-end testcase; it should be sufficient to have
testcases for clang->llvm IR and llvm IR->asm. So should be fine as-is.
https://github.com/llvm/llvm-project/pull/65278
___
cfe-commits mailing list
cf
efriedma-quic wrote:
The primary issue with over-wide bitfield accesses is ensuring we don't cause
data races. C++ [intro.memory]p3: "A memory location is either an object of
scalar type that is not a bit-field or a maximal sequence of adjacent
bit-fields all having nonzero width. Two or mor
efriedma-quic wrote:
> > Note that changing the memory accesses performed by clang (load or store)
> > _is_ an ABI change at IR level because of UB.
>
> Could you clarify why UB is a consideration here?
There's some weirdness with poison values; see https://reviews.llvm.org/D129541
etc. This
efriedma-quic wrote:
> Hm, I've been thinking of it the opposite way round -- merging bitfields is
> throwing away information (about where cuts might be).
In essence, late optimizations can make accesses narrower, but it can't make
them wider. The information about cuts is generally recovera
efriedma-quic wrote:
When you say you want a second opinion on CodeGen changes, do you mean
RecordLayoutBuilder.cpp? I don't see any non-whitespace changes to
clang/lib/CodeGen/ .
https://github.com/llvm/llvm-project/pull/65675
___
cfe-commits maili
@@ -2937,14 +2964,97 @@ void MicrosoftRecordLayoutBuilder::layoutNonVirtualBase(
BaseOffset = CharUnits::Zero();
} else {
// Otherwise, lay the base out at the end of the MDC.
- BaseOffset = Size = Size.alignTo(Info.Alignment);
+ BaseOffset = DataSize
efriedma-quic wrote:
byval changes the calling convention: instead of passing a pointer, it copies
the pointed-to value into the argument list.
It's not clear to me why msan cares about whether a pointer is an implicit or
explicit value... but if it does, we'd want to use an attribute that doe
efriedma-quic wrote:
> I just checked with a few small examples, and while the ABI does not seem to
> change, the code generation looks broken for tail recursion:
I'd guess the SystemZ backend doesn't implement byval properly (since it's not
required for the C calling convention, probably nobo
efriedma-quic wrote:
There's a special case in the msan handling precisely because byval makes the
ABI different. (If you look at the x86 code, you'll see that the generated
code with byval is significantly different.)
I don't think I know enough about dfsan to follow that argument.
https://
efriedma-quic wrote:
In any case:
- We absolutely can't use byval here.
- If you think we need a new attribute for this, please start a Discourse
thread to get some feedback. (I'm still not understanding what you're trying
to fix here, but maybe additional perspectives would help bridge the g
efriedma-quic wrote:
> Both s390x and x86_64 ABIs require passing large structs via a pointer
Wrong. x86_64 passes structs by value (copying the data into the argument
list). It just looks like a pointer in the IR because LLVM can't really handle
large values in registers.
---
The semantic
efriedma-quic wrote:
byval generally results in worse code. It has two problems:
- The copy is invisible. Having the copy explicitly visible means we can
optimize the code involved in the copy (sometimes we can eliminate it, or parts
of it).
- Gluing the allocation to the call means stack lay
@@ -10752,6 +10752,68 @@ Value
*CodeGenFunction::EmitAArch64BuiltinExpr(unsigned BuiltinID,
return Load;
}
+ if (BuiltinID == AArch64::BI_CopyDoubleFromInt64 ||
+ BuiltinID == AArch64::BI_CopyFloatFromInt32 ||
+ BuiltinID == AArch64::BI_CopyInt32FromFloat ||
Author: Eli Friedman
Date: 2023-07-02T14:25:25-07:00
New Revision: b4bae3fd8ede10026a6f6e1caaec476125f5ac67
URL:
https://github.com/llvm/llvm-project/commit/b4bae3fd8ede10026a6f6e1caaec476125f5ac67
DIFF:
https://github.com/llvm/llvm-project/commit/b4bae3fd8ede10026a6f6e1caaec476125f5ac67.diff
efriedma-quic wrote:
LGTM
https://github.com/llvm/llvm-project/pull/65420
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Eli Friedman
Date: 2020-03-23T12:17:09-07:00
New Revision: 896335bfb8ea2c09c361c4f1e5a9aa6fb78caf88
URL:
https://github.com/llvm/llvm-project/commit/896335bfb8ea2c09c361c4f1e5a9aa6fb78caf88
DIFF:
https://github.com/llvm/llvm-project/commit/896335bfb8ea2c09c361c4f1e5a9aa6fb78caf88.diff
Author: Eli Friedman
Date: 2020-03-24T14:34:40-07:00
New Revision: 3f1defa6e2dfdea2a5980083de2b04068f640023
URL:
https://github.com/llvm/llvm-project/commit/3f1defa6e2dfdea2a5980083de2b04068f640023
DIFF:
https://github.com/llvm/llvm-project/commit/3f1defa6e2dfdea2a5980083de2b04068f640023.diff
Author: Eli Friedman
Date: 2020-03-25T10:58:03-07:00
New Revision: c46a0c07a634d85d3fed2ef94747ea19fb4d2d69
URL:
https://github.com/llvm/llvm-project/commit/c46a0c07a634d85d3fed2ef94747ea19fb4d2d69
DIFF:
https://github.com/llvm/llvm-project/commit/c46a0c07a634d85d3fed2ef94747ea19fb4d2d69.diff
Author: Eli Friedman
Date: 2020-03-30T11:46:02-07:00
New Revision: 24485aec4750255574a9a8211b3aef1ce00e83b6
URL:
https://github.com/llvm/llvm-project/commit/24485aec4750255574a9a8211b3aef1ce00e83b6
DIFF:
https://github.com/llvm/llvm-project/commit/24485aec4750255574a9a8211b3aef1ce00e83b6.diff
Author: Eli Friedman
Date: 2019-10-29T14:52:56-07:00
New Revision: 98286b569d01a461d75c9fd133cbf52c0c92e32a
URL:
https://github.com/llvm/llvm-project/commit/98286b569d01a461d75c9fd133cbf52c0c92e32a
DIFF:
https://github.com/llvm/llvm-project/commit/98286b569d01a461d75c9fd133cbf52c0c92e32a.diff
Author: Eli Friedman
Date: 2020-03-18T13:53:17-07:00
New Revision: e24e95fe900ab9d84017e4210b305d6c3a44abb0
URL:
https://github.com/llvm/llvm-project/commit/e24e95fe900ab9d84017e4210b305d6c3a44abb0
DIFF:
https://github.com/llvm/llvm-project/commit/e24e95fe900ab9d84017e4210b305d6c3a44abb0.diff
Author: efriedma
Date: Fri Mar 30 11:39:28 2018
New Revision: 328891
URL: http://llvm.org/viewvc/llvm-project?rev=328891&view=rev
Log:
Remove unused CHECK lines leftover from r306928.
The RUN lines were removed, but the corresponding CHECK lines never
went away.
Modified:
cfe/trunk/test/Dri
Author: Jacob Young
Date: 2023-02-28T16:43:03-08:00
New Revision: 67409911353323ca5edf2049ef0df54132fa1ca7
URL:
https://github.com/llvm/llvm-project/commit/67409911353323ca5edf2049ef0df54132fa1ca7
DIFF:
https://github.com/llvm/llvm-project/commit/67409911353323ca5edf2049ef0df54132fa1ca7.diff
L
Author: Eli Friedman
Date: 2023-06-26T10:45:41-07:00
New Revision: a1540e4852a90e7f72c996a3832edfd20968bd9e
URL:
https://github.com/llvm/llvm-project/commit/a1540e4852a90e7f72c996a3832edfd20968bd9e
DIFF:
https://github.com/llvm/llvm-project/commit/a1540e4852a90e7f72c996a3832edfd20968bd9e.diff
Author: Bolshakov
Date: 2023-05-03T18:20:16-07:00
New Revision: cd93532dfc455255cb2fa553090d14aaa52b106b
URL:
https://github.com/llvm/llvm-project/commit/cd93532dfc455255cb2fa553090d14aaa52b106b
DIFF:
https://github.com/llvm/llvm-project/commit/cd93532dfc455255cb2fa553090d14aaa52b106b.diff
LOG
Author: Eli Friedman
Date: 2023-06-14T11:44:02-07:00
New Revision: f51924d124bdd0e089cd28756578cec13ede1a8c
URL:
https://github.com/llvm/llvm-project/commit/f51924d124bdd0e089cd28756578cec13ede1a8c
DIFF:
https://github.com/llvm/llvm-project/commit/f51924d124bdd0e089cd28756578cec13ede1a8c.diff
efriedma added a comment.
This is probably going to lead to someone complaining about clang realigning
the stack on 32-bit Windows; are your sure we're choosing the right alignment
there?
https://reviews.llvm.org/D24378
___
cfe-commits mailing lis
efriedma added a comment.
Huh... then I guess this is fine.
https://reviews.llvm.org/D24378
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: efriedma
Date: Thu Jan 12 13:51:44 2017
New Revision: 291805
URL: http://llvm.org/viewvc/llvm-project?rev=291805&view=rev
Log:
Add additional testcases for nsw markings on ++ and --.
clang has generated correct IR for char/short decrement since r126816,
but we didn't have any test coverag
Author: efriedma
Date: Mon Jul 3 17:52:24 2017
New Revision: 307051
URL: http://llvm.org/viewvc/llvm-project?rev=307051&view=rev
Log:
[Sema] Make BreakContinueFinder handle nested loops.
We don't care about break or continue statements that aren't
associated with the current loop, so make sure t
Author: efriedma
Date: Mon Mar 13 19:18:29 2017
New Revision: 297694
URL: http://llvm.org/viewvc/llvm-project?rev=297694&view=rev
Log:
Fix crash with interrupt attribute on ARM.
An indirect call has no associated function declaration.
Modified:
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/
efriedma created this revision.
efriedma added a reviewer: dblaikie.
efriedma added a subscriber: cfe-commits.
efriedma set the repository for this revision to rL LLVM.
Fixes regression from r279445.
Repository:
rL LLVM
https://reviews.llvm.org/D25793
Files:
lib/CodeGen/CGDebugInfo.cpp
t
Author: efriedma
Date: Wed Oct 19 17:16:32 2016
New Revision: 284652
URL: http://llvm.org/viewvc/llvm-project?rev=284652&view=rev
Log:
Don't crash generating debug info for VLA in function prototype.
Fixes regression from r279445.
Differential Revision: https://reviews.llvm.org/D25793
Modified
This revision was automatically updated to reflect the committed changes.
Closed by commit rL284652: Don't crash generating debug info for VLA in
function prototype. (authored by efriedma).
Changed prior to commit:
https://reviews.llvm.org/D25793?vs=75219&id=75243#toc
Repository:
rL LLVM
ht
efriedma added a comment.
Ping
https://reviews.llvm.org/D24378
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma added inline comments.
Comment at: lib/CodeGen/CGExprConstant.cpp:1340
+ return C;
+return getNullPtr(PT, DestType);
}
Consider code like the following:
int x = 0;
auto y1 = (__specialaddrspace int*)0;
auto y2 = (__sp
efriedma added inline comments.
Comment at: lib/CodeGen/CGExprConstant.cpp:1340
+ return C;
+return getNullPtr(PT, DestType);
}
yaxunl wrote:
> yaxunl wrote:
> > rjmccall wrote:
> > > efriedma wrote:
> > > > Consider code like the followin
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
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
@@ -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:
I'm concerned that we're calling EvaluateKnownConstInt on an lvalue; that might
indicate there's something wrong with the AST. Usually there should be an
lvalue-to-rvalue cast somewhere.
https://github.com/llvm/llvm-project/pull/97146
_
@@ -2220,6 +2220,11 @@ llvm::Constant
*ConstantLValueEmitter::emitPointerAuthPointer(const Expr *E) {
// The assertions here are all checked by Sema.
assert(Result.Val.isLValue());
+ auto *Base = Result.Val.getLValueBase().get();
+ if (auto *Decl = dyn_cast_or_null(Base
efriedma-quic wrote:
To the extent that EvaluateAsRValue handles LValues, FastEvaluateAsRValue
should also handle them, sure. I'm suspicious of the fact that
EvaluateAsRValue is doing this conversion in the first place, but I guess this
pull request isn't the place to address that.
Given tha
efriedma-quic wrote:
Please add a test for `struct X { int x[0]; };`.
https://github.com/llvm/llvm-project/pull/97315
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2220,6 +2220,11 @@ llvm::Constant
*ConstantLValueEmitter::emitPointerAuthPointer(const Expr *E) {
// The assertions here are all checked by Sema.
assert(Result.Val.isLValue());
+ auto *Base = Result.Val.getLValueBase().get();
+ if (auto *Decl = dyn_cast_or_null(Base
efriedma-quic wrote:
Probably you want a dedicated codepath for computing the right kcfi type for
resolvers.
https://github.com/llvm/llvm-project/pull/96400
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/96659
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Please make sure you have a testcase for computing the difference between two
blockaddresses (`void g(int*); int f() { static int x = &&A-&&B;
A:g(&x);B:return x; }`). Not sure how you should handle that case.
https://github.com/llvm/llvm-project/pull/97647
__
efriedma-quic wrote:
Oh, hmm, I see.
Maybe the right strategy here is to delay attaching the resolver to the ifunc
until the end of the translation unit, when we know the definition is already
emitted. That way, it should already have the right attributes. (We already
do some delayed checki
efriedma-quic wrote:
The current spec language is:
> Empty structs or union arguments or return values are ignored by C compilers
> which support them as a non-standard extension. This is not the case for C++,
> which requires them to be sized types.
So empty structs in C are ignored, empty s
https://github.com/efriedma-quic commented:
It looks like MSVC also applies this rule to fastcall.
Maybe put a boolean in the "state" to try to group together the code for
specific conventions, instead of directly checking the CC.
https://github.com/llvm/llvm-project/pull/97939
___
efriedma-quic wrote:
> gcc does ignore the empty array case for assigning argument registers in C++.
> Compare the two cases here https://godbolt.org/z/j4WP89rE8
Oh, you're right, I didn't actually do any testing myself, I was just assuming
@svs-quic did the right test.
So I guess the previou
@@ -0,0 +1,43 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 5
+// The test may fail as time out on windows
+// REQUIRES: system-linux
+
+// RUN: %clang -S -O3 -emit-llvm -o - -x c++ %s | FileCheck %s
-check-prefixes=CHECK,
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/93267
___
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:
If I'm understanding correctly, the way this currently works is that you do
normal field layout, then if you discover that the actual offset of a field is
less than the offset normal field layout would produce, you assume the struct
is packed. This
https://github.com/efriedma-quic approved this pull request.
LGTM
I meant, at the beginning of X86_32ABIInfo::computeInfo there's a chain of if
statements that set up the properties of different calling conventions, and
maybe some bits could be set there. If you don't think that makes sense,
efriedma-quic wrote:
> What about the case I have mentioned in https://godbolt.org/z/vdhGbvj6W ?
That test doesn't really prove anything useful. The zeroing of a0 doesn't have
any ABI significance: "struct s12" doesn't have any data in it, so the caller
can't use the value in a0 for anything.
efriedma-quic wrote:
I'm not against having a security hardening feature to avoid using LR as a GPR.
But we'd want to name it something different, to make it clear that it's a
security-hardening feature, not a guarantee that the compiler won't clobber LR.
https://github.com/llvm/llvm-project/
efriedma-quic wrote:
We have a mechanism which specifically encodes the distinction we want here:
ReserveXRegisterForRA. This was implemented for debugging/regression tests
(see https://reviews.llvm.org/D132717), but we can expose it more generally.
Naming is hard, but maybe `-mavoid-non-call
https://github.com/efriedma-quic approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/97315
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
efriedma-quic wrote:
Why do we want a module flag, and not a function attribute? Module flags are
generally problematic during LTO, so we try to avoid them if they aren't truly
necessary.
https://github.com/llvm/llvm-project/pull/97524
___
cfe-commi
efriedma-quic wrote:
> > For CGClass, it's not directly tied to the LLVM structure layout, but I'm
> > not sure the generated code would be semantically correct if an "empty"
> > field that isn't isEmpty() overlaps with actual data.
>
> I haven't addressed this yet. To clarify, are you referri
efriedma-quic wrote:
It looks like in the latest patch, there's still a couple uses of isZeroSize()
in CGExprConstant?
https://github.com/llvm/llvm-project/pull/96422
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
efriedma-quic wrote:
What's the interaction here with the standard's ordering guarantees? The
comment in the code indicates that we can't make a separate comdat for ordered
initialization... but inline variables do require partial ordering. Please
update the comment as appropriate.
https://
@@ -19553,17 +19555,18 @@ EnumConstantDecl *Sema::CheckEnumConstant(EnumDecl
*Enum,
// If we're not in C++, diagnose the overflow of enumerator values,
// which in C99 means that the enumerator value is not representable in
-// an int (C99 6.7.2.2p2).
401 - 500 of 1669 matches
Mail list logo
