retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features #135927

azhogin · 2025-01-23T10:46:14Z

-Zretpoline and -Zretpoline-external-thunk flags are target modifiers (tracked to be equal in linked crates).

Enables target features for -Zretpoline-external-thunk:
+retpoline-external-thunk, +retpoline-indirect-branches, +retpoline-indirect-calls.
Enables target features for -Zretpoline:
+retpoline-indirect-branches, +retpoline-indirect-calls.

It corresponds to clang -mretpoline & -mretpoline-external-thunk flags.

Also this PR forbids to specify those target features manually (warning).

rustbot · 2025-01-23T10:46:22Z

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2025-01-23T10:46:25Z

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

compiler-errors · 2025-01-23T18:12:36Z

r? compiler

chenyukang · 2025-02-05T02:30:16Z

r? compiler

fee1-dead · 2025-02-08T01:29:07Z

r? compiler

lcnr · 2025-02-09T18:12:07Z

r? @davidtwco maybe 😅

davidtwco · 2025-06-12T09:47:51Z

@bors r+

bors · 2025-06-12T09:47:54Z

📌 Commit 5601490 has been approved by davidtwco

It is now in the queue for this repository.

Rollup of 9 pull requests Successful merges: - #128425 (Make `missing_fragment_specifier` an unconditional error) - #135927 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features) - #140770 (add `extern "custom"` functions) - #142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches) - #142248 (Add supported asm types for LoongArch32) - #142267 (assert more in release in `rustc_ast_lowering`) - #142274 (Update the stdarch submodule) - #142276 (Update dependencies in `library/Cargo.lock`) - #142308 (Upgrade `object`, `addr2line`, and `unwinding` in the standard library) Failed merges: - #140920 (Extract some shared code from codegen backend target feature handling) r? `@ghost` `@rustbot` modify labels: rollup try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-gnu try-job: dist-i586-gnu-i586-i686-musl try-job: test-various

Rollup merge of #135927 - azhogin:azhogin/retpoline, r=davidtwco retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features `-Zretpoline` and `-Zretpoline-external-thunk` flags are target modifiers (tracked to be equal in linked crates). * Enables target features for `-Zretpoline-external-thunk`: `+retpoline-external-thunk`, `+retpoline-indirect-branches`, `+retpoline-indirect-calls`. * Enables target features for `-Zretpoline`: `+retpoline-indirect-branches`, `+retpoline-indirect-calls`. It corresponds to clang -mretpoline & -mretpoline-external-thunk flags. Also this PR forbids to specify those target features manually (warning). Issue: #116852

RalfJung · 2025-06-13T21:50:53Z

compiler/rustc_session/src/errors.rs

As discussed in #140920, codegen_ssa is probably a much better place for this target feature handling.

RalfJung · 2025-06-13T21:53:25Z

compiler/rustc_target/src/target_features.rs

@@ -34,6 +34,9 @@ pub enum Stability {
    /// particular for features are actually ABI configuration flags (not all targets are as nice as
    /// RISC-V and have an explicit way to set the ABI separate from target features).
    Forbidden { reason: &'static str },
+    /// This feature can not be set via `-Ctarget-feature` or `#[target_feature]`, it can only be set
+    /// by target modifier flag. Target modifier flags are tracked to be consistent in linked modules.
+    TargetModifierOnly { reason: &'static str, flag: &'static str },


Why are such features even listed here? The entire point of this file is to define the Rust feature names used for -Ctarget-feature and #[target_feature] and cfg(target_feature). Mixing in other things here seems like a big mess...

RalfJung · 2025-06-13T21:56:30Z

compiler/rustc_session/src/features.rs

+            Stability::TargetModifierOnly { reason, flag } => {
+                if !sess.opts.target_feature_flag_enabled(*flag) { Err(reason) } else { Ok(()) }
+            }


I don't understand this logic. Somewhere it says these target features are not allowed in -Ctarget-features, but now here it seems to allow them... sometimes?

Oh, you are taking the named -Z options and mixing them with the -Ctarget-features flag. Then of course things become messy and they have to masquerade as actual target features in parts of the compiler even though they aren't, actually, target features for us.

I think it's a bad idea to ever mix these. The code paths should be entirely separate all the way until actually generating backend target features. Please let's not make the target feature code even more spaghetti than it already was.

If I understand this PR correctly, then once I set -Zretpoline-external-thunk this would actually let me set -Ctarget-features=-retpoline-external-thunk without any warning. My refactor in #140920 fixes that.

RalfJung · 2025-06-13T22:11:30Z

compiler/rustc_codegen_llvm/src/llvm_util.rs

@@ -707,6 +707,12 @@ pub(crate) fn target_cpu(sess: &Session) -> &str {
    handle_native(cpu_name)
 }

+fn llvm_features_by_flags(sess: &Session) -> Vec<&str> {


The handling for fixed_x18 should probably be merged with this. (That would also have been an easier model to follow for adding the new flags.)

RalfJung · 2025-06-13T22:18:27Z

#140920 now also changes the logic for these new flags quite a bit, in an attempt to reduce the spaghetti. Might be worth taking a look.

RalfJung · 2025-06-13T22:28:45Z

compiler/rustc_target/src/target_features.rs

@@ -49,6 +52,7 @@ impl<CTX> HashStable<CTX> for Stability {
            Stability::Forbidden { reason } => {
                reason.hash_stable(hcx, hasher);
            }
+            Stability::TargetModifierOnly { .. } => {}


Not hashing the fields here is sus... but I'm anyway going to entirely remove this variant in my PR.

RalfJung · 2025-06-13T22:36:17Z

tests/ui/check-cfg/target_feature.stderr

Is it deliberate that these are added to the list of possible values for cfg(target_feature)? They are not set via -Ctarget-feature, so that seems confusing. Also, I can't find any logic here that would actually ever make cfg!(target_feature="retpoline-external-thunk") be "true", and no test checking that it would ever be "true". This seems like an accidental side-effect of adding a new target_features::Stability variant?

I think this is being set as a target feature "because LLVM treats it as a target feature". There was no discussion of exposing this to the language that I remember.

It is never actually set as a cfg(target_feature), as far as I can tell. It is only added to the list of values that check-cfg will accept for cfg(target_feature).

Because a new variant was added to target_features::Stability and then some of the existing logic, in particular in_cfg, was not updated properly.

The variant was entirely unnecessary so I am getting rid of it again in #140920.

Rollup of 9 pull requests Successful merges: - rust-lang/rust#128425 (Make `missing_fragment_specifier` an unconditional error) - rust-lang/rust#135927 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features) - rust-lang/rust#140770 (add `extern "custom"` functions) - rust-lang/rust#142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches) - rust-lang/rust#142248 (Add supported asm types for LoongArch32) - rust-lang/rust#142267 (assert more in release in `rustc_ast_lowering`) - rust-lang/rust#142274 (Update the stdarch submodule) - rust-lang/rust#142276 (Update dependencies in `library/Cargo.lock`) - rust-lang/rust#142308 (Upgrade `object`, `addr2line`, and `unwinding` in the standard library) Failed merges: - rust-lang/rust#140920 (Extract some shared code from codegen backend target feature handling) r? `@ghost` `@rustbot` modify labels: rollup try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-gnu try-job: dist-i586-gnu-i586-i686-musl try-job: test-various

Kobzol · 2025-06-17T13:22:21Z

@rust-timer build 696f7e3

(For #142443)

rust-timer · 2025-06-17T16:10:17Z

Finished benchmarking commit (696f7e3): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.3%	[0.2%, 0.5%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary 1.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.5%	[2.2%, 2.6%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.7%	[-1.7%, -1.7%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary 2.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.9%	[2.9%, 6.8%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.8%	[-1.8%, -1.8%]	1
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 755.964s -> 690.311s (-8.68%)
Artifact size: 372.26 MiB -> 372.28 MiB (0.01%)

…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#128425 (Make `missing_fragment_specifier` an unconditional error) - rust-lang#135927 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features) - rust-lang#140770 (add `extern "custom"` functions) - rust-lang#142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches) - rust-lang#142248 (Add supported asm types for LoongArch32) - rust-lang#142267 (assert more in release in `rustc_ast_lowering`) - rust-lang#142274 (Update the stdarch submodule) - rust-lang#142276 (Update dependencies in `library/Cargo.lock`) - rust-lang#142308 (Upgrade `object`, `addr2line`, and `unwinding` in the standard library) Failed merges: - rust-lang#140920 (Extract some shared code from codegen backend target feature handling) r? `@ghost` `@rustbot` modify labels: rollup try-job: aarch64-apple try-job: x86_64-msvc-1 try-job: x86_64-gnu try-job: dist-i586-gnu-i586-i686-musl try-job: test-various

…n, r=nnethercote,WaffleLapkin Extract some shared code from codegen backend target feature handling There's a bunch of code duplication between the GCC and LLVM backends in target feature handling. This moves that into new shared helper functions in `rustc_codegen_ssa`. The first two commits should be purely refactoring. I am fairly sure the LLVM-side behavior stays the same; if the GCC side deliberately diverges from this then I may have missed that. I did account for one divergence, which I do not know is deliberate or not: GCC does not seem to use the `-Ctarget-feature` flag to populate `cfg(target_feature)`. That seems odd, since the `-Ctarget-feature` flag is used to populate the return value of `global_gcc_features` which controls the target features actually used by GCC. `@GuillaumeGomez` `@antoyo` is there a reason `target_config` ignores `-Ctarget-feature` but `global_gcc_features` does not? The second commit also cleans up a bunch of unneeded complexity added in rust-lang#135927. The third commit extracts some shared logic out of the functions that populate `cfg(target_feature)` and the backend target feature set, respectively. This one actually has some slight functional changes: - Before, with `-Ctarget-feature=-feat`, if there is some other feature `x` that implies `feat` we would *not* add `-x` to the backend target feature set. Now, we do. This fixes rust-lang#134792. - The logic that removes `x` from `cfg(target_feature)` in this case also changed a bit, avoiding a large number of calls to the (uncached) `sess.target.implied_target_features` (if there were a large number of positive features listed before a negative feature) but instead constructing a full inverse implication map when encountering the first negative feature. Ideally this would be done with queries but the backend target feature logic runs before `tcx` so we can't use that... - Previously, if feature "a" implied "b" and "b" was unstable, then using `-Ctarget-feature=+a` would also emit a warning about `b`. I had to remove this since when accounting for negative implications, this emits a ton of warnings in a bunch of existing tests... I assume this was unintentional anyway. The fourth commit increases consistency of the GCC backend with the LLVM backend. The last commit does some further cleanup: - Get rid of RUSTC_SPECIAL_FEATURES. It was only needed for s390x "backchain", but since LLVM 19 that is always a regular target feature so we don't need this hack any more. The hack also has various unintended side-effects so we don't want to keep it. Fixes rust-lang#142412. - Move RUSTC_SPECIFIC_FEATURES handling into the shared parse_rust_feature_flag helper so all consumers of `-Ctarget-feature` that only care about actual target features (and not "crt-static") have it. Previously, we actually set `cfg(target_feature = "crt-static")` twice: once in the backend target feature logic, and once specifically for that one feature. IIUC, some targets are meant to ignore `-Ctarget-feature=+crt-static`, it seems like before this PR that flag still incorrectly enabled `cfg(target_feature = "crt-static")` (but I didn't test this). - Move fixed_x18 handling together with retpoline handling. - Forbid setting fixed_x18 as a regular target feature, even unstably. It must be set via the `-Z` flag. `@bjorn3` I did not touch the cranelift backend here, since AFAIK it doesn't really support target features. But if you ever do, please use the new helpers. :) Cc `@workingjubilee`

…n, r=nnethercote,WaffleLapkin Extract some shared code from codegen backend target feature handling There's a bunch of code duplication between the GCC and LLVM backends in target feature handling. This moves that into new shared helper functions in `rustc_codegen_ssa`. The first two commits should be purely refactoring. I am fairly sure the LLVM-side behavior stays the same; if the GCC side deliberately diverges from this then I may have missed that. I did account for one divergence, which I do not know is deliberate or not: GCC does not seem to use the `-Ctarget-feature` flag to populate `cfg(target_feature)`. That seems odd, since the `-Ctarget-feature` flag is used to populate the return value of `global_gcc_features` which controls the target features actually used by GCC. ``@GuillaumeGomez`` ``@antoyo`` is there a reason `target_config` ignores `-Ctarget-feature` but `global_gcc_features` does not? The second commit also cleans up a bunch of unneeded complexity added in rust-lang#135927. The third commit extracts some shared logic out of the functions that populate `cfg(target_feature)` and the backend target feature set, respectively. This one actually has some slight functional changes: - Before, with `-Ctarget-feature=-feat`, if there is some other feature `x` that implies `feat` we would *not* add `-x` to the backend target feature set. Now, we do. This fixes rust-lang#134792. - The logic that removes `x` from `cfg(target_feature)` in this case also changed a bit, avoiding a large number of calls to the (uncached) `sess.target.implied_target_features` (if there were a large number of positive features listed before a negative feature) but instead constructing a full inverse implication map when encountering the first negative feature. Ideally this would be done with queries but the backend target feature logic runs before `tcx` so we can't use that... - Previously, if feature "a" implied "b" and "b" was unstable, then using `-Ctarget-feature=+a` would also emit a warning about `b`. I had to remove this since when accounting for negative implications, this emits a ton of warnings in a bunch of existing tests... I assume this was unintentional anyway. The fourth commit increases consistency of the GCC backend with the LLVM backend. The last commit does some further cleanup: - Get rid of RUSTC_SPECIAL_FEATURES. It was only needed for s390x "backchain", but since LLVM 19 that is always a regular target feature so we don't need this hack any more. The hack also has various unintended side-effects so we don't want to keep it. Fixes rust-lang#142412. - Move RUSTC_SPECIFIC_FEATURES handling into the shared parse_rust_feature_flag helper so all consumers of `-Ctarget-feature` that only care about actual target features (and not "crt-static") have it. Previously, we actually set `cfg(target_feature = "crt-static")` twice: once in the backend target feature logic, and once specifically for that one feature. IIUC, some targets are meant to ignore `-Ctarget-feature=+crt-static`, it seems like before this PR that flag still incorrectly enabled `cfg(target_feature = "crt-static")` (but I didn't test this). - Move fixed_x18 handling together with retpoline handling. - Forbid setting fixed_x18 as a regular target feature, even unstably. It must be set via the `-Z` flag. ``@bjorn3`` I did not touch the cranelift backend here, since AFAIK it doesn't really support target features. But if you ever do, please use the new helpers. :) Cc ``@workingjubilee``

Rollup merge of #140920 - RalfJung:target-feature-unification, r=nnethercote,WaffleLapkin Extract some shared code from codegen backend target feature handling There's a bunch of code duplication between the GCC and LLVM backends in target feature handling. This moves that into new shared helper functions in `rustc_codegen_ssa`. The first two commits should be purely refactoring. I am fairly sure the LLVM-side behavior stays the same; if the GCC side deliberately diverges from this then I may have missed that. I did account for one divergence, which I do not know is deliberate or not: GCC does not seem to use the `-Ctarget-feature` flag to populate `cfg(target_feature)`. That seems odd, since the `-Ctarget-feature` flag is used to populate the return value of `global_gcc_features` which controls the target features actually used by GCC. ``@GuillaumeGomez`` ``@antoyo`` is there a reason `target_config` ignores `-Ctarget-feature` but `global_gcc_features` does not? The second commit also cleans up a bunch of unneeded complexity added in #135927. The third commit extracts some shared logic out of the functions that populate `cfg(target_feature)` and the backend target feature set, respectively. This one actually has some slight functional changes: - Before, with `-Ctarget-feature=-feat`, if there is some other feature `x` that implies `feat` we would *not* add `-x` to the backend target feature set. Now, we do. This fixes #134792. - The logic that removes `x` from `cfg(target_feature)` in this case also changed a bit, avoiding a large number of calls to the (uncached) `sess.target.implied_target_features` (if there were a large number of positive features listed before a negative feature) but instead constructing a full inverse implication map when encountering the first negative feature. Ideally this would be done with queries but the backend target feature logic runs before `tcx` so we can't use that... - Previously, if feature "a" implied "b" and "b" was unstable, then using `-Ctarget-feature=+a` would also emit a warning about `b`. I had to remove this since when accounting for negative implications, this emits a ton of warnings in a bunch of existing tests... I assume this was unintentional anyway. The fourth commit increases consistency of the GCC backend with the LLVM backend. The last commit does some further cleanup: - Get rid of RUSTC_SPECIAL_FEATURES. It was only needed for s390x "backchain", but since LLVM 19 that is always a regular target feature so we don't need this hack any more. The hack also has various unintended side-effects so we don't want to keep it. Fixes #142412. - Move RUSTC_SPECIFIC_FEATURES handling into the shared parse_rust_feature_flag helper so all consumers of `-Ctarget-feature` that only care about actual target features (and not "crt-static") have it. Previously, we actually set `cfg(target_feature = "crt-static")` twice: once in the backend target feature logic, and once specifically for that one feature. IIUC, some targets are meant to ignore `-Ctarget-feature=+crt-static`, it seems like before this PR that flag still incorrectly enabled `cfg(target_feature = "crt-static")` (but I didn't test this). - Move fixed_x18 handling together with retpoline handling. - Forbid setting fixed_x18 as a regular target feature, even unstably. It must be set via the `-Z` flag. ``@bjorn3`` I did not touch the cranelift backend here, since AFAIK it doesn't really support target features. But if you ever do, please use the new helpers. :) Cc ``@workingjubilee``

rustbot assigned compiler-errors Jan 23, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Jan 23, 2025

azhogin force-pushed the azhogin/retpoline branch from e808e83 to 12b286f Compare January 23, 2025 10:48

This comment has been minimized.

Sign in to view

rustbot assigned chenyukang and unassigned compiler-errors Jan 23, 2025

This comment was marked as resolved.

Sign in to view

azhogin marked this pull request as draft January 30, 2025 08:48

azhogin force-pushed the azhogin/retpoline branch from 12b286f to f331c60 Compare February 2, 2025 16:27

This comment has been minimized.

Sign in to view

azhogin force-pushed the azhogin/retpoline branch from f331c60 to 434a25f Compare February 2, 2025 17:27

This comment has been minimized.

Sign in to view

azhogin force-pushed the azhogin/retpoline branch from 434a25f to 945d0f1 Compare February 3, 2025 12:41

This comment has been minimized.

Sign in to view

rustbot assigned fee1-dead and unassigned chenyukang Feb 5, 2025

azhogin force-pushed the azhogin/retpoline branch from 945d0f1 to 0ea46d2 Compare February 6, 2025 19:08

This comment has been minimized.

Sign in to view

rustbot assigned lcnr and unassigned fee1-dead Feb 8, 2025

azhogin force-pushed the azhogin/retpoline branch from 0ea46d2 to 386c90e Compare February 8, 2025 11:41

rustbot assigned davidtwco Feb 9, 2025

azhogin force-pushed the azhogin/retpoline branch from 14f651e to 5601490 Compare June 9, 2025 14:42

davidtwco approved these changes Jun 12, 2025

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 12, 2025

matthiaskrgr mentioned this pull request Jun 13, 2025

Rollup of 9 pull requests #142443

Merged

bors merged commit 1a865fb into rust-lang:master Jun 13, 2025
10 checks passed

rustbot added this to the 1.89.0 milestone Jun 13, 2025

RalfJung reviewed Jun 13, 2025

View reviewed changes

RalfJung mentioned this pull request Jun 13, 2025

Extract some shared code from codegen backend target feature handling #140920

Merged

RalfJung reviewed Jun 13, 2025

View reviewed changes

This comment has been minimized.

Sign in to view

retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features #135927

retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features #135927

Uh oh!

Conversation

azhogin commented Jan 23, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jan 23, 2025

Uh oh!

rustbot commented Jan 23, 2025

Uh oh!

This comment has been minimized.

compiler-errors commented Jan 23, 2025

Uh oh!

This comment was marked as resolved.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

chenyukang commented Feb 5, 2025

Uh oh!

This comment has been minimized.

fee1-dead commented Feb 8, 2025

Uh oh!

lcnr commented Feb 9, 2025

Uh oh!

davidtwco commented Jun 12, 2025

Uh oh!

bors commented Jun 12, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Jun 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung commented Jun 13, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Jun 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Jun 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kobzol commented Jun 17, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Jun 17, 2025

Overall result: ❌ regressions - no action needed

Uh oh!

Uh oh!

azhogin commented Jan 23, 2025 •

edited by rustbot

Loading

RalfJung Jun 13, 2025 •

edited

Loading

RalfJung Jun 13, 2025 •

edited

Loading

RalfJung Jun 14, 2025 •

edited

Loading