Bug 4541 – Intrinsic functions do not have pointers

This code fails to link: import std.math; void main() { real function(real) c = &sin; } With the error message: D:\Source>dmd-1 test.d test.exe OPTLINK (R) for Win32 Release 8.00.2 Copyright (C) Digital Mars 1989-2009 All rights reserved. http://www.digitalmars.com/ctg/optlink.html test.obj(test) Error 42: Symbol Undefined _D3std4math3sinFeZe --- errorlevel 1 Because std.math.sin is intrinsic. This should either be detected at compile time or (better yet) a function should be added to Phobos that gives this function a body. This affects treating large sets of functions homogenously, such as exporting to a scripting language.

*** Issue 4696 has been marked as a duplicate of this issue. ***

*** Issue 6692 has been marked as a duplicate of this issue. ***

Also a D2 bug.

Still in DMD master. See http://forum.dlang.org/post/[email protected]

Perhaps a possible workaround is to have the compiler emit a wrapper function when the address of an intrinsic is asked for, and return the pointer to the wrapper?

intrinsic have been moved to `core.math` and `std.math` nowadays (since 2.069 / https://github.com/dlang/phobos/pull/3599 ) provide wrappers around it to mitigate the issue. In order to reproduce this, one can use: import core.math; void main() { real function(real) c = &sin; } instead of the op's code.

*** Issue 5305 has been marked as a duplicate of this issue. ***

I think that this issue is no longer valid since using the std.math wrappers results in successful compilation. Even though using core.math results in link failure, I do not think this is a problem since that is the runtime library and who uses it should know that the functions declared there are intrinsics. Anyway, this is not a phobos bug anymore and I don't think it is a druntime one either. Closing as fixed.

I strongly disagree with closing this bug. > Even though using core.math results in link failure, I do not think this is a problem since that is the runtime library and who uses it should know that the functions declared there are intrinsics. Relying on user knowing of internal details is not a solution. Moreover, this doesn't take into account generic code. If one write a template that accept a static function via a template this argument, do you really expect this person to handle the case of someone passing an intrinsic explicitly ? Intrinsics shouldn't differ from regular functions. > Anyway, this is not a phobos bug anymore and I don't think it is a druntime one either. Closing as fixed. The correct course of action would be to properly tag the bug as being within DMD.

It works fine when I try it with the latest.

@Walter: Did you read the comments ? The test case nowadays is: ``` import core.math; void main() { real function(real) c = &sin; } ``` And it still fails: ``` test.o: In function `_Dmain': test.d:(.text._Dmain[_Dmain]+0x7): undefined reference to `_D4core4math3sinFNaNbNiNfeZe' collect2: error: ld returned 1 exit status Error: linker exited with status 1 ``` Tested with both 2.076.1 and HEAD (51bc2fb42)

@SixthDot created dlang/dmd pull request #15699 "fix issue 4541 - linker failure due to AddrExp on intrinsic function" fixing this issue: - fix issue 4541 - linker failure due to AddrExp on intrinsic function The expression results now in a semantic-time error, which is the only simple solution. DMD Intrinsics map to libc functions, which can give the impression that taking the address is possible, but more generally an intrinsic can also have for effect to insert platform-specific instructions, as seen in LLVM. https://github.com/dlang/dmd/pull/15699

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18286 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB