Translate ^^ operator to druntime hook by dkorpel · Pull Request #22831 · dlang/dmd

dkorpel · 2026-03-28T10:42:55Z

First step to fixing #22670

It doesn't move the implementation like #14297 does, but it moves the hard-coded std import to one that can be overridden in custom druntime.

dlang-bot · 2026-03-28T10:42:59Z

Thanks for your pull request and interest in making D better, @dkorpel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
I have provided a detailed rationale explaining my changes
New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#22831"

rikkimax · 2026-03-28T11:28:35Z

I had to double check what ldc with optimizations would do with ^^ 0.5:

float abc(float a) {
 	return a ^^ 0.5;   
}

float onlineapp.abc(float):
	.cfi_startproc
	sqrtss	%xmm0, %xmm0
	retq

It will optimize it, doing it in the frontend is far too early.

dkorpel · 2026-03-28T12:26:21Z

@rikkimax You got that backwards

rikkimax · 2026-03-28T12:28:57Z

@rikkimax You got that backwards

Which part?

dkorpel · 2026-03-28T12:37:48Z

ldc shares dmd's frontend, which does the transformation. LDC's backend is not allowed to rewrite pow(x, 0.5) to sqrt(x) because that's not strictly equivalent.

rikkimax · 2026-03-28T12:41:46Z

Okay, yes llvm isn't doing the rewrite, IR with optimizations turned off is already sqrt.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

ibuclaw · 2026-03-28T15:11:14Z

@dkorpel are you offering to write an ibm-real implementation of ^^ then? Thanks! :-)

dkorpel · 2026-03-28T15:15:27Z

What is that and why would it be needed?

ibuclaw · 2026-03-28T15:30:44Z

What is that and why would it be needed?

alias real = double[2];

https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Double-double_arithmetic

Without support, building druntime would regress on POWER targets.

dkorpel · 2026-03-28T15:38:35Z

The goal here is to move code from one package to another. Why would that break existing support or require new support? Looks like a separate thing to me.

ibuclaw · 2026-03-28T16:25:38Z

These power targets can't build std.math, moving that out of phobos means they won't be able to build druntime - ergo can't bootstrap the compiler.

ibuclaw · 2026-03-28T16:28:52Z

druntime/src/object.d

+// TODO: move implementation to druntime instead of Phobos.
+auto _d_sqrt(T)(T x)
+{
+    import std.math : sqrt;


This is an intrinsic, use core.math.sqrt instead.

The goal of this PR is to keep behavior equivalent to what it was before, just moving the logic to druntime so at least users of custom druntime can already swap in their own implementation. I plan on breaking the Phobos connection in subsequent PRs.

ibuclaw · 2026-03-28T16:36:21Z

druntime/src/object.d

+// TODO: move implementation to druntime instead of Phobos.
+auto _d_pow(Base, Exp)(Base base, Exp exp)
+{
+    import std.math : pow;


Could test the import in case this is a port that doesn't have phobos included?

static if (__traits(compiles, { import std.math : pow; }))

No need, because the import is inside a template

Then why go to all the trouble of putting in a friendly error in the compiler then.

The current runtime does not support the ^^ operator, or the runtime is corrupt.

That's the standard verifyHookExist procedure.

Which succeeds because _d_pow exists, then it later fails as std.math doesn't.

Test.

[Environment64] #DFLAGS=-I%@P%/../../../../druntime/import -I%@P%/../../../../../phobos -L-L%@P%/../../../../../phobos/generated/linux/release/64 -L--export-dynamic -fPIC DFLAGS=-I%@P%/../../../../druntime/import -L-L%@P%/../../../../../phobos/generated/linux/release/64 -L--export-dynamic -fPIC

Before:

pow.d(3): Error: `a ^^ b` requires `std.math` for `^^` operators auto c = a ^^ b; ^

After:

./generated/linux/release/64/../../../../druntime/import/object.d(4761): Error: unable to read module `math` import std.math : pow; ^ ./generated/linux/release/64/../../../../druntime/import/object.d(4761): Expected 'std/math.d' or 'std/math/package.d' in one of the following import paths: import std.math : pow; ^ import path[0] = ./generated/linux/release/64/../../../../druntime/import

Yes, that's to be expected

Then why shy away from friendly error messages then? :-)

static assert(__traits(compiles, { import std.math : pow; }), "The current runtime does not support the ^^ operator"); return imported!"std.math".pow(base, exp);

->

./generated/linux/release/64/../../../../druntime/import/object.d(4761): Error: static assert: "The current runtime does not support the ^^ operator" static assert(__traits(compiles, { import std.math : pow; }), ^ pow.d(3): instantiated from here: `_d_pow!(double, double)` auto c = a ^^ b; ^

Multiple reasons

__traits(compiles) is a hack

It's better to improve compiler error messages in general than trying to 'catch' them and replacing them manually

The error message is not part of normal usage, but advanced usage in unsupported environments

The static assert removes information from the compiler's error message (import paths)

The whole std import is to be removed any way

The unnormalized path is pretty long and pushes the message to the right, I think that would make a good improvement to start with in general.

dkorpel · 2026-03-28T16:52:58Z

These power targets can't build std.math, moving that out of phobos means they won't be able to build druntime - ergo can't bootstrap the compiler.

If they couldn't build std.math, then they couldn't use ^^ either, so if the implementation in druntime gets versioned out for those targets it will work like before

ibuclaw · 2026-03-28T18:07:38Z

These power targets can't build std.math, moving that out of phobos means they won't be able to build druntime - ergo can't bootstrap the compiler.

If they couldn't build std.math, then they couldn't use ^^ either, so if the implementation in druntime gets versioned out for those targets it will work like before

Except it won't as someone's going to add static assert(0) and I'll get all the bug reports from my downstreams that D broke.

dkorpel · 2026-03-28T18:26:38Z

Do downstreams just pull changes from upstream without testing?

xoxorwr · 2026-03-28T21:23:07Z

This needs change log entry, this will affect custom runtimes.

dkorpel force-pushed the pow-hook branch from 4be6a65 to 1ea1c5b Compare March 28, 2026 10:44

thewilsonator approved these changes Mar 28, 2026

View reviewed changes

rikkimax approved these changes Mar 28, 2026

View reviewed changes

Translate ^^ operator to druntime hook

0d9f388

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

dkorpel force-pushed the pow-hook branch from 1ea1c5b to 0d9f388 Compare March 28, 2026 14:03

dkorpel requested a review from ibuclaw as a code owner March 28, 2026 14:03

ibuclaw reviewed Mar 28, 2026

View reviewed changes

dkorpel merged commit 18013b9 into dlang:master Mar 28, 2026
42 checks passed

dkorpel deleted the pow-hook branch March 28, 2026 17:01

dkorpel mentioned this pull request Mar 28, 2026

^^ depends on phobos #22670

Open

xoxorwr mentioned this pull request Mar 30, 2026

Add change log entry for ^^ operator handling changes #22838

Merged

Uh oh!

Conversation

dkorpel commented Mar 28, 2026

Uh oh!

dlang-bot commented Mar 28, 2026

Bugzilla references

Testing this PR locally

Uh oh!

rikkimax commented Mar 28, 2026

Uh oh!

dkorpel commented Mar 28, 2026

Uh oh!

rikkimax commented Mar 28, 2026

Uh oh!

dkorpel commented Mar 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rikkimax commented Mar 28, 2026

Uh oh!

ibuclaw commented Mar 28, 2026

Uh oh!

dkorpel commented Mar 28, 2026

Uh oh!

ibuclaw commented Mar 28, 2026

Uh oh!

dkorpel commented Mar 28, 2026

Uh oh!

ibuclaw commented Mar 28, 2026

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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ibuclaw Mar 28, 2026 • 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!

dkorpel commented Mar 28, 2026

Uh oh!

Uh oh!

ibuclaw commented Mar 28, 2026

Uh oh!

dkorpel commented Mar 28, 2026

Uh oh!

xoxorwr commented Mar 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

dkorpel commented Mar 28, 2026 •

edited

Loading

ibuclaw Mar 28, 2026 •

edited

Loading