www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9623] New: Illegal Win64 linker optimization?

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9623

           Summary: Illegal Win64 linker optimization?
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: code dawg.eu


--- Comment #0 from Martin Nowak <code dawg.eu> 2013-03-01 11:30:18 PST ---
debug=PRINTF;
debug(PRINTF) import core.stdc.stdio;

int foo()()
{
    return 0;
}

int bar()()
{
    return 0;
}

void main()
{
     auto f1 = &foo!();
     auto f2 = &bar!();
     debug(PRINTF) printf("%p %p\n", f1, f2);
     assert(f1 !is f2);
}

----

Because identical COMDAT folding (/OPT:ICF) is enabled by default this will
assert. When compiled with '-g' we pass '/DEBUG' to the linker which also
disables ICF so the assertion passes.
This could lead to difficult to track down bug when function pointer comparison
is used, e.g. as key to an AA.

http://msdn.microsoft.com/en-us//library/bxwfs976(v=vs.110).aspx#alert_note

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 01 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9623


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com


--- Comment #1 from Walter Bright <bugzilla digitalmars.com> 2013-03-01
14:12:22 PST ---
I have mixed feelings about whether this is a bug or not. First off, nothing in
the dmd spec requires that identical function bodies must have distinct
addresses. Second, this is an important optimization to reduce template bloat.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 01 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9623


Martin Nowak <code dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


--- Comment #2 from Martin Nowak <code dawg.eu> 2013-03-04 04:53:03 PST ---
(In reply to comment #1)
 I have mixed feelings about whether this is a bug or not.

Me too and as this optimization becomes probably even more important to fold TypeInfos and precise GC metadata I will close this for now. Related C++ article "Can Two Functions Have the Same Address?" http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=561 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 04 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9623



--- Comment #3 from Walter Bright <bugzilla digitalmars.com> 2013-03-05
21:52:05 PST ---
(In reply to comment #2)
 Related C++ article "Can Two Functions Have the Same Address?"
 http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=561

This quote pretty much sells me: -- Additionally, Google's compiler team have experimented with Identical Code Folding (ICF) and reported that "[d]etailed experiments on the x86 platform show that ICF can reduce the text size [the program section in which functions' code is stored, DK] of some Google binaries, whose average text size is 50 MB, by up to 7%." -- We should settle the issue by updating the D spec to explicitly allow functions to have the same address. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 05 2013