llvm-project.git/clang/test/CodeGenCXX/template-param-objects.cpp, branch main

[clang] Do not emit template parameter objects as COMDATs when they have internal linkage. (#125448)

2025-02-03T10:26:22+00:00

Per the ELF spec, section groups may only contain local symbols if those
symbols are only
referenced from within the section group. [1] In the case of template
parameter objects,
they can be referenced from outside the group when the type of the
object was declared
in an anonymous namespace. In that case, we can't place the object in a
COMDAT. This matches
GCC's linkage behavior on the test input.

[1]:
https://www.sco.com/developers/gabi/latest/ch4.sheader.html#section_groups

[Clang][CodeGen] Fix linkage and visibility of template parameter objects

2023-03-14T18:23:06+00:00

This diff fixes linkage and visibility of template parameter objects.
The associated GitHub issue: https://github.com/llvm/llvm-project/issues/51571#

Test plan:
1/ ninja check-all
2/ bootstrapped Clang passes tests

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

[CodeGenCXX] Convert more tests to opaque pointers (NFC)

2022-10-07T08:01:17+00:00

Conversion was performed using
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34
plus manual (but uninteresting) fixups.

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)

2022-04-07T10:09:47+00:00

This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be part of the migration approach described in
https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9.

The patch has been produced by replacing %clang_cc1 with
%clang_cc1 -no-opaque-pointers for tests that fail with opaque
pointers enabled. Worth noting that this doesn't cover all tests,
there's a remaining ~40 tests not using %clang_cc1 that will need
a followup change.

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

[ConstantFold] Remove unnecessary bounded index restriction

2022-01-04T14:23:09+00:00

The fold for merging a GEP of GEP into a single GEP currently bails
if doing so would result in notional overindexing. The justification
given in the comment above this check is dangerously incorrect: GEPs
with notional overindexing are perfectly fine, and if some code
treats them incorrectly, then that code is broken, not the GEP.
Such a GEP might legally appear in source IR, so only preventing
its creation cannot be sufficient. (The constant folder also ends
up canonicalizing the GEP to remove the notional overindexing, but
that's neither here nor there.)

This check dates back to
https://github.com/llvm/llvm-project/commit/bd4fef4a8939db18f39b108e19097b25e2c7c47a,
and as far as I can tell the original issue this was trying to
patch around has since been resolved.

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

[c++20] For P0732R2 / P1907R1: Basic code generation and name

2020-11-10T06:10:27+00:00

mangling support for non-type template parameters of class type and
template parameter objects.

The Itanium side of this follows the approach I proposed in
https://github.com/itanium-cxx-abi/cxx-abi/issues/47 on 2020-09-06.

The MSVC side of this was determined empirically by observing MSVC's
output.

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