================
@@ -6555,8 +6555,119 @@ When `#pragma comment(copyright, ...)` appears in a
C++20 module interface
unit, the copyright string is embedded only in the object file compiled from
that interface unit. Importing TUs do not re-emit the string.
-(langext-evaluating-object-size)=
+## Preserving Identifying Variables with -mloadtime-comment-vars
+
+The `-mloadtime-comment-vars=` flag accepts a comma-separated list of
+mangled variable names that should be preserved in the final object file as
+loadtime identifying strings. This is an AIX-specific feature; on other
+targets the compiler emits a warning. Names are matched against each
+variable's mangled name, and unrecognised names are silently ignored.
+
+This flag complements `#pragma comment(copyright, ...)` for codebases that
+already use the traditional UNIX convention of embedding identifying strings
+directly in source variables rather than via a pragma.
+
+Syntax:
+
+```console
+-mloadtime-comment-vars=<var1>[,<var2>,...]
+```
+
+In C, variable names are not mangled, so the mangled name is identical to the
source
+identifier (for example, `sccsid`). In C++, the mangled name follows the
+Itanium C++ ABI, so a namespace-scoped or internal-linkage variable (for
+example, a file-scope `static`) must be named using its mangled form:
+
+```c++
+namespace N { char sccsid[] = "@(#) MyApp Version 1.0"; } // N::sccsid ->
_ZN1N6sccsidE
+static char build[] = "@(#) Level 42"; // build ->
_ZL5build
+```
+
+```console
+-mloadtime-comment-vars=_ZN1N6sccsidE,_ZL5build
+```
+
+Valid variable types:
+
+A variable named in the list must meet all of these conditions to be
+preserved:
+
+- It must be defined at file or namespace scope. A name-matched function-local
+ `static` variable, static data member, or variable template specialization
+ is not supported and is diagnosed.
+- Its type must be a character pointer (`char *`, `const char *`) or a
+ character array (`char[]`, `const char[]`). The character type must be plain
+ `char`: variables of `signed char`, `unsigned char`, and the wide and
+ Unicode character types (`wchar_t`, `char8_t`, `char16_t`, `char32_t`) are
+ not matched.
+- It must have static storage duration and must not be `volatile`-qualified.
+- It must be constant-initialized, so that the string is present in the object
+ at load time. A dynamically initialized variable (whose value is computed by
+ a start-up constructor) is not preserved.
+- A character *pointer* must be initialized directly with a string literal (for
+ example, `char *p = "@(#) ...";`). A pointer bound to some other object
+ -- even a constant one, such as another character array or the result of a
+ `constexpr` function returning the address of an external array -- does not
+ itself carry the identifying string and is not preserved. The expected
+ behavior is that the identifying string is present in the object file
+ compiled from the defining translation unit itself, not merely in the final
+ linked output.
+
+A variable that is named in the list but is `volatile`-qualified, does not
+have static storage duration (for example, a `thread_local` variable), is
+dynamically initialized, or is a pointer not bound to a string literal, is
+diagnosed with a warning and is not preserved. The same applies to name-matched
+variables of unsupported kinds: function-local `static` variables, static data
+members, and variable template specializations (implicit specializations are
+diagnosed in each translation unit that instantiates them). A name-matched
+variable of any other type -- for example, an `int` or a `struct` -- is
+likewise diagnosed. A definition without an initializer is silently skipped.
+Names that match no variable defined in the translation unit are also
+silently ignored.
+
+For C++20 modules, a named variable defined in a module unit is processed when
+the module unit itself is compiled, and the option must be present on that
+compilation -- in a two-phase build, the step that builds the module
+interface. Importing translation units do not re-emit the variable. A variable
----------------
hubert-reinterpretcast wrote:
What happens with C++ inline variables (either defined directly in the current
translation unit or retrieved from an imported module)?
https://github.com/llvm/llvm-project/pull/187986
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
