[dmd-internals] "Previous Definition Different" w/ array ops

David Simcha dsimcha at gmail.com
Tue Feb 15 09:38:48 PST 2011


BTW, to deal with annoying errors like this, how hard would it be to compare
implementations when a symbol is defined multiple times and, if the
implementations are identical, just pick one and use it?  Of course I know
in the short term this is hard b/c OPTLINK isn't translated to C yet, but
let's assume longer term that we will have a sane linker codebase.

On Tue, Feb 15, 2011 at 12:33 PM, David Simcha <dsimcha at gmail.com> wrote:

> Never mind, I got it.  http://d.puremagic.com/issues/show_bug.cgi?id=5592
> The thing that made it hard to reproduce was that I was using the wrong
> array op.  What the heck is the difference between
> __arrayExpSliceMulSliceAddass_d and
> __arraySliceExpMulSliceAddass_d anyhow?  From what I can tell, which one
> gets called depends on the order you write your array op in.  arr1[] += num
> * arr2[] calls __arrayExpSliceMulSliceAddass_d and arr1[] += arr2[] * num
> calls __arraySliceExpMulSliceAddass_d .  Isn't multiplication commutative
> even in inexact floating point arithmetic?  Why two functions?
>
>
> On Tue, Feb 15, 2011 at 12:07 PM, Jason House <jason.james.house at gmail.com
> > wrote:
>
>> The complete linker error with mangled symbol name and the candidate code
>> generating the symbol in the first place is probably enough. At one point, I
>> posted an error message, and Don was able to infer everything else without
>> seeing a line of my code. That might not be the case here, but it's probably
>> the bulk of the needed info.
>>
>> Sent from my iPhone
>>
>> On Feb 15, 2011, at 11:33 AM, David Simcha <dsimcha at gmail.com> wrote:
>>
>> > Whenever I use array ops in multi-module projects, I always seem to run
>> into "Previous definition different" linker errors.  This seems to occur
>> when I call the same array op using library function from multiple modules
>> in the same project.  Moving things around to different modules and
>> recompiling always seems to solve them at the expense of uglifying my code.
>>  Unfortunately, this is one of those frustrating bugs that only seems to
>> occur on real-world code, i.e. code that has multiple modules, lots of
>> indirection, libraries, etc.  I can't for the life of me come up with a
>> reduced test case.
>> >
>> > Has anyone else been experiencing similar issues?  Alternatively, can
>> someone with a better mental model of how things work at the binary level
>> please suggest how this bug might be reproduced in a test case that's less
>> than 20 thousand lines of code?  (I find linker bugs very difficult to
>> isolate and file bug reports on because I have no mental model of how things
>> work at that low a level.  My mental model basically only goes down to
>> assembly language, not the process of turning a pile of assembly language
>> files into a working executable or shared library.)
>> > _______________________________________________
>> > dmd-internals mailing list
>> > dmd-internals at puremagic.com
>> > http://lists.puremagic.com/mailman/listinfo/dmd-internals
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-internals/attachments/20110215/1a3a233d/attachment-0001.html>


More information about the dmd-internals mailing list