D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 3418 - link error with cast(ulong)(ulong*real)
Summary: link error with cast(ulong)(ulong*real)
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: x86 Windows
: P2 normal
Assignee: No Owner
URL:
Keywords: link-failure
Depends on:
Blocks:
 
Reported: 2009-10-19 02:13 UTC by ZY Zhou
Modified: 2015-06-09 01:26 UTC (History)
2 users (show)

See Also:

Attachments
test case with template use and comments (523 bytes, application/octet-stream)
2010-03-14 00:49 UTC, Aldo Nunez 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description ZY Zhou 2009-10-19 02:13:05 UTC 
test case:

ulong a = 1; 
a = cast(ulong)(a * 2.0L);

ERROR message: 

OPTLINK (R) for Win32  Release 8.00.1
Copyright (C) Digital Mars 1989-2004  All rights reserved.
C:\d\dmd2\windows\bin\..\lib\SNN.lib(u64_ldbl)  Offset FFE74H Record Type 0091
 Error 1: Previous Definition Different : ___LDBLULLNG
Comment 1 Aldo Nunez 2010-03-14 00:49:02 UTC 
Created attachment 588 [details]
test case with template use and comments
Comment 2 Aldo Nunez 2010-03-14 00:49:48 UTC 
I get the same error, but in a slightly different context. I tried the case from ZY Zhou on DMD 2.041, and it still fails.

The different case that I'm seeing is this.

This links fine.
	real y = 99.5L;
	ulong x = cast(ulong) y;

But if I put it after the following call, I get the link error.
	BinOp!(ulong, real).P( 99L );
	// where P is defined like this
	template BinOp(T, U)
	{
		void Q( U u )	{}
		void P( T t )	{ Q( cast(U) t ); }
	}

Then compiling with -O gets rid of the error. I do have a case where the error doesn't go away with the -O flag. The following is all in main.
	BinOp!(ulong, real).P( 99L );
	real y = 99.5L;
	void Q( ulong l )
	{
	}
	void P( real r )
	{
		Q( cast(ulong) r );
	}
	// B: -O doesn't fix this
	P( y );

Of course, getting rid of the BinOp.P call gets rid of the error as before.

Sorry if this is confusing. I've attached a file that might show this a little more clearly. Picking line A or one line B by itself will not bring out the error. It involves enabling A and one of the line Bs.