History log of /llvm-project-15.0.7/clang/lib/CodeGen/CGExprConstant.cpp (Results 26 – 50 of 479)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 550c4562 15-Jun-2020 Kirill Bobyrev <[email protected]>

Revert "Prevent IR-gen from emitting consteval declarations"

This reverts commit 3bab88b7baa20b276faaee0aa7ca87f636c91877.

This patch causes test failures:
http://lab.llvm.org:8011/builders/clang-c

Revert "Prevent IR-gen from emitting consteval declarations"

This reverts commit 3bab88b7baa20b276faaee0aa7ca87f636c91877.

This patch causes test failures:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/17260

show more ...


# 3bab88b7 14-Jun-2020 Tyker <[email protected]>

Prevent IR-gen from emitting consteval declarations

Summary: with this patch instead of emitting calls to consteval function. the IR-gen will emit a store of the already computed result.

Reviewers:

Prevent IR-gen from emitting consteval declarations

Summary: with this patch instead of emitting calls to consteval function. the IR-gen will emit a store of the already computed result.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D76420

show more ...


Revision tags: llvmorg-10.0.1-rc1
# bab6df86 12-Apr-2020 Richard Smith <[email protected]>

Rework how UuidAttr, CXXUuidofExpr, and GUID template arguments and constants are represented.

Summary:
Previously, we treated CXXUuidofExpr as quite a special case: it was the
only kind of expressi

Rework how UuidAttr, CXXUuidofExpr, and GUID template arguments and constants are represented.

Summary:
Previously, we treated CXXUuidofExpr as quite a special case: it was the
only kind of expression that could be a canonical template argument, it
could be a constant lvalue base object, and so on. In addition, we
represented the UUID value as a string, whose source form we did not
preserve faithfully, and that we partially parsed in multiple different
places.

With this patch, we create an MSGuidDecl object to represent the
implicit object of type 'struct _GUID' created by a UuidAttr. Each
UuidAttr holds a pointer to its 'struct _GUID' and its original
(as-written) UUID string. A non-value-dependent CXXUuidofExpr behaves
like a DeclRefExpr denoting that MSGuidDecl object. We cache an APValue
representation of the GUID on the MSGuidDecl and use it from constant
evaluation where needed.

This allows removing a lot of the special-case logic to handle these
expressions. Unfortunately, many parts of Clang assume there are only
a couple of interesting kinds of ValueDecl, so the total amount of
special-case logic is not really reduced very much.

This fixes a few bugs and issues:
* PR38490: we now support reading from GUID objects returned from
__uuidof during constant evaluation.
* Our Itanium mangling for a non-instantiation-dependent template
argument involving __uuidof no longer depends on which CXXUuidofExpr
template argument we happened to see first.
* We now predeclare ::_GUID, and permit use of __uuidof without
any header inclusion, better matching MSVC's behavior. We do not
predefine ::__s_GUID, though; that seems like a step too far.
* Our IR representation for GUID constants now uses the correct IR type
wherever possible. We will still fall back to using the
{i32, i16, i16, [8 x i8]}
layout if a definition of struct _GUID is not available. This is not
ideal: in principle the two layouts could have different padding.

Reviewers: rnk, jdoerfert

Subscribers: arphaman, cfe-commits, aeubanks

Tags: #clang

Differential Revision: https://reviews.llvm.org/D78171

show more ...


# 68b03aee 07-Apr-2020 Eli Friedman <[email protected]>

Remove SequentialType from the type heirarchy.

Now that we have scalable vectors, there's a distinction that isn't
getting captured in the original SequentialType: some vectors don't have
a known el

Remove SequentialType from the type heirarchy.

Now that we have scalable vectors, there's a distinction that isn't
getting captured in the original SequentialType: some vectors don't have
a known element count, so counting the number of elements doesn't make
sense.

In some cases, there's a better way to express the commonality using
other methods. If we're dealing with GEPs, there's GEP methods; if we're
dealing with a ConstantDataSequential, we can query its element type
directly.

In the relatively few remaining cases, I just decided to write out
the type checks. We're talking about relatively few places, and I think
the abstraction doesn't really carry its weight. (See thread "[RFC]
Refactor class hierarchy of VectorType in the IR" on llvmdev.)

Differential Revision: https://reviews.llvm.org/D75661

show more ...


# e6cb4b65 27-Mar-2020 Lucas Prates <[email protected]>

[Clang][CodeGen] Fixing mismatch between memory layout and const expressions for oversized bitfields

Summary:
The construction of constants for structs/unions was conflicting the
expected memory lay

[Clang][CodeGen] Fixing mismatch between memory layout and const expressions for oversized bitfields

Summary:
The construction of constants for structs/unions was conflicting the
expected memory layout for over-sized bit-fields. When building the
necessary bits for those fields, clang was ignoring the size information
computed for the struct/union memory layout and using the original data
from the AST's FieldDecl information. This caused an issue in big-endian
targets, where the field's contant was incorrectly misplaced due to
endian calculations.

This patch aims to separate the constant value from the necessary
padding bits, using the proper size information for each one of them.
With this, the layout of constants for over-sized bit-fields matches the
ABI requirements.

Reviewers: rsmith, eli.friedman, efriedma

Reviewed By: efriedma

Subscribers: efriedma, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D77048

show more ...


Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1
# d35a4541 21-Nov-2019 Akira Hatanaka <[email protected]>

[CodeGen] Emit destructor calls to destruct non-trivial C struct objects
returned by function calls or loaded from volatile objects

rdar://problem/51867864

Differential Revision: https://reviews.ll

[CodeGen] Emit destructor calls to destruct non-trivial C struct objects
returned by function calls or loaded from volatile objects

rdar://problem/51867864

Differential Revision: https://reviews.llvm.org/D66094

show more ...


# 96c89944 07-Feb-2020 Richard Smith <[email protected]>

C++ DR2026: static storage duration variables are not zeroed before
constant initialization.

Removing this zeroing regressed our code generation in a few cases, also
fixed here. We now compute wheth

C++ DR2026: static storage duration variables are not zeroed before
constant initialization.

Removing this zeroing regressed our code generation in a few cases, also
fixed here. We now compute whether a variable has constant destruction
even if it doesn't have a constant initializer, by trying to destroy a
default-initialized value, and skip emitting a trivial default
constructor for a variable even if it has non-trivial (but perhaps
constant) destruction.

show more ...


# a6d57a8c 18-Dec-2019 Akira Hatanaka <[email protected]>

Use hasOffsetApplied to initialize member HasOffsetApplied

This is NFC since none of the constructor calls in trunk pass
hasOffsetApplied=true.


# 9803178a 10-Dec-2019 Reid Kleckner <[email protected]>

Avoid Attr.h includes, CodeGen edition

This saves around 20 includes of Attr.h. Not much.


# b0561b33 17-Nov-2019 Tyker <[email protected]>

[NFC] Refactor representation of materialized temporaries

Summary:
this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63

[NFC] Refactor representation of materialized temporaries

Summary:
this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718

Reviewers: rsmith, martong, shafik

Reviewed By: rsmith

Subscribers: thakis, sammccall, ilya-biryukov, rnkovacs, arphaman, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D69360

show more ...


# c9276fbf 17-Nov-2019 Nico Weber <[email protected]>

Revert "[NFC] Refactor representation of materialized temporaries"

This reverts commit 08ea1ee2db5f9d6460fef1d79d0d1d1a5eb78982.
It broke ./ClangdTests/FindExplicitReferencesTest.All
on the bots, se

Revert "[NFC] Refactor representation of materialized temporaries"

This reverts commit 08ea1ee2db5f9d6460fef1d79d0d1d1a5eb78982.
It broke ./ClangdTests/FindExplicitReferencesTest.All
on the bots, see comments on https://reviews.llvm.org/D69360

show more ...


# 08ea1ee2 16-Nov-2019 Tyker <[email protected]>

[NFC] Refactor representation of materialized temporaries

Summary:
this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63

[NFC] Refactor representation of materialized temporaries

Summary:
this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718

Reviewers: rsmith, martong, shafik

Reviewed By: rsmith

Subscribers: rnkovacs, arphaman, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D69360

show more ...


# cebfddc0 16-Oct-2019 Simon Pilgrim <[email protected]>

CGExprConstant - silence static analyzer getAs<> null dereference warning. NFCI.

The static analyzer is warning about a potential null dereference, but in these cases we should be able to use castAs

CGExprConstant - silence static analyzer getAs<> null dereference warning. NFCI.

The static analyzer is warning about a potential null dereference, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.

llvm-svn: 374988

show more ...


# c79099e0 03-Oct-2019 Guillaume Chatelet <[email protected]>

[Alignment][Clang][NFC] Add CharUnits::getAsAlign

Summary:
This is a prerequisite to removing `llvm::GlobalObject::setAlignment(unsigned)`.
This is patch is part of a series to introduce an Alignmen

[Alignment][Clang][NFC] Add CharUnits::getAsAlign

Summary:
This is a prerequisite to removing `llvm::GlobalObject::setAlignment(unsigned)`.
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet

Subscribers: jholewinski, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D68274

llvm-svn: 373592

show more ...


# 1cd399c9 03-Oct-2019 Simon Pilgrim <[email protected]>

Silence static analyzer getAs<RecordType> null dereference warnings. NFCI.

The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<Record

Silence static analyzer getAs<RecordType> null dereference warnings. NFCI.

The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<RecordType> directly and if not assert will fire for us.

llvm-svn: 373584

show more ...


Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init
# 49a3ad21 16-Jul-2019 Rui Ueyama <[email protected]>

Fix parameter name comments using clang-tidy. NFC.

This patch applies clang-tidy's bugprone-argument-comment tool
to LLVM, clang and lld source trees. Here is how I created this
patch:

$ git clone

Fix parameter name comments using clang-tidy. NFC.

This patch applies clang-tidy's bugprone-argument-comment tool
to LLVM, clang and lld source trees. Here is how I created this
patch:

$ git clone https://github.com/llvm/llvm-project.git
$ cd llvm-project
$ mkdir build
$ cd build
$ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \
-DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \
-DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \
-DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm
$ ninja
$ parallel clang-tidy -checks='-*,bugprone-argument-comment' \
-config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \
::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h}

llvm-svn: 366177

show more ...


Revision tags: llvmorg-8.0.1, llvmorg-8.0.1-rc4
# 7264a474 03-Jul-2019 Fangrui Song <[email protected]>

Change std::{lower,upper}_bound to llvm::{lower,upper}_bound or llvm::partition_point. NFC

llvm-svn: 365006


# eee944e7 02-Jul-2019 Erik Pilkington <[email protected]>

[C++2a] Add __builtin_bit_cast, used to implement std::bit_cast

This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a
bit_cast from a value v to a type T. This expression can be

[C++2a] Add __builtin_bit_cast, used to implement std::bit_cast

This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a
bit_cast from a value v to a type T. This expression can be evaluated at
compile time under specific circumstances.

The compile time evaluation currently doesn't support bit-fields, but I'm
planning on fixing this in a follow up (some of the logic for figuring this out
is in CodeGen). I'm also planning follow-ups for supporting some more esoteric
types that the constexpr evaluator supports, as well as extending
__builtin_memcpy constexpr evaluation to use the same infrastructure.

rdar://44987528

Differential revision: https://reviews.llvm.org/D62825

llvm-svn: 364954

show more ...


Revision tags: llvmorg-8.0.1-rc3
# 780c374b 22-Jun-2019 Richard Smith <[email protected]>

Remove reliance on toCharUnitsFromBits rounding down.

llvm-svn: 364139


# 78b239ea 20-Jun-2019 Richard Smith <[email protected]>

P0840R2: support for [[no_unique_address]] attribute

Summary:
Add support for the C++2a [[no_unique_address]] attribute for targets using the Itanium C++ ABI.

This depends on D63371.

Reviewers: rj

P0840R2: support for [[no_unique_address]] attribute

Summary:
Add support for the C++2a [[no_unique_address]] attribute for targets using the Itanium C++ ABI.

This depends on D63371.

Reviewers: rjmccall, aaron.ballman

Subscribers: dschuff, aheejin, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D63451

llvm-svn: 363976

show more ...


# 5136ea49 18-Jun-2019 Mikael Holmen <[email protected]>

Fix compiler warning by removing unused variable

llvm-svn: 363651


# 5745febe 17-Jun-2019 Richard Smith <[email protected]>

Rewrite ConstStructBuilder with a mechanism that can cope with splitting and updating constants.

Summary:
This adds a ConstantBuilder class that deals with incrementally building
an aggregate consta

Rewrite ConstStructBuilder with a mechanism that can cope with splitting and updating constants.

Summary:
This adds a ConstantBuilder class that deals with incrementally building
an aggregate constant, including support for overwriting
previously-emitted parts of the aggregate with new values.

This fixes a bunch of cases where we used to be unable to reduce a
DesignatedInitUpdateExpr down to an IR constant, and also lays some
groundwork for emission of class constants with [[no_unique_address]]
members.

Reviewers: rjmccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D63371

llvm-svn: 363620

show more ...


Revision tags: llvmorg-8.0.1-rc2
# 275a55cb 22-May-2019 David Blaikie <[email protected]>

Modules: Code generation of enum constants for merged enum definitions

Found in a bootstrap of LLVM with implicit modules, resulting in a
deadlock of some Orc unit tests with libstdc++ 8.1. An enum

Modules: Code generation of enum constants for merged enum definitions

Found in a bootstrap of LLVM with implicit modules, resulting in a
deadlock of some Orc unit tests with libstdc++ 8.1. An enum was used as
part of the implementation of std::recursive_mutex and this bug resulted
in the constant initialization of zero instead of the desired non-zero
value. => Badness.

Richard Smith tells me neither of these fields are necessarily canonical
& so using declaresSamEntity is the right solution here (rather than
changing both of these Fields to be canonical by construction/from their
source)

llvm-svn: 361428

show more ...


# e637cbe4 21-May-2019 Richard Smith <[email protected]>

Refactor: split Uninitialized state on APValue into an "Absent" state
representing no such object, and an "Indeterminate" state representing
an uninitialized object. The latter is not yet used, but s

Refactor: split Uninitialized state on APValue into an "Absent" state
representing no such object, and an "Indeterminate" state representing
an uninitialized object. The latter is not yet used, but soon will be.

llvm-svn: 361328

show more ...


# ee0ce302 17-May-2019 Richard Smith <[email protected]>

Refactor constant evaluation of typeid(T) to track a symbolic type_info
object rather than tracking the originating expression.

This is groundwork for supporting polymorphic typeid expressions. (Not

Refactor constant evaluation of typeid(T) to track a symbolic type_info
object rather than tracking the originating expression.

This is groundwork for supporting polymorphic typeid expressions. (Note
that this somewhat regresses our support for DR1968, but it turns out
that that never actually worked anyway, at least in non-trivial cases.)

This reinstates r360974, reverted in r360988, with a fix for a
static_assert failure on 32-bit builds: force Type base class to have
8-byte alignment like the rest of Clang's AST nodes.

llvm-svn: 360995

show more ...


12345678910>>...20