[LLVMbugs] [Bug 17414] New: Trivial program takes severely excessive time to compile. Minute(s) where it should be a second.

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=17414

            Bug ID: 17414
           Summary: Trivial program takes severely excessive time to
                    compile. Minute(s) where it should be a second.
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: gmisocpp at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Take the following program:

#include <istream>

using namespace std;

typedef int MY_OBJECT;

template <typename T> class static_storage_provider {
private:
    union {
        T object;
    };
public:
    static_storage_provider() { }
    ~static_storage_provider() { }

    inline T& storage_get()
    {
        return object;
    }

public:
    T* storage_allocate() { return &storage_get(); }
    void storage_deallocate() {}
};

template <typename T, typename S> class manually_constructed_object : public S
{
private:
    bool valid;
public:
    manually_constructed_object() : valid(false)
    {
    }
    ~manually_constructed_object()
    {
    }

   inline T* create()
   {
        storage_allocate();
    }
};

int main()
{
    manually_constructed_object<MY_OBJECT,static_storage_provider<MY_OBJECT> >
mobj;
}

Compile above program as shown below. Use of Windows may or may not be
important here. libcxx may or be not required here.

Note the time it takes to compile.

clang++ -std=c++11 -fno-exceptions -static mo.cpp -I/libcxx/include
-L/libcxx_build/lib -oz.exe

The output shown below. It is correct but takes minutes not seconds to be
deduced:

c:\test>clang++ -std=c++11 -fno-exceptions -static mo.cpp -I/libcxx/include
-L/libcxx_build/lib -oz.exe
mo.cpp:39:16: error: use of undeclared identifier 'storage_allocate'
        storage_allocate();
               ^
1 error generated.


Observations:

* Remove istream and the "using" statement and compilation time is instant and
correct.

* Compile time is related to the include AND the function being looked up. The
function in this case is storage_allocate which part of the template. I think
it's correct that it not be found, but incorrect that it takes so long to work
it out that it can't be found.

* Increases with each lookup of a function, even the same function, add an
additional call to storage_allocate, and compilation time will double etc.

* The particular include file used seems to be relevant. Replace the include of
<istream> above that causes a slow compile with ONE from below that is marked
fast and compile time will speed up:
#include <istream> // slow
#include "__config" // fast
#include <cstdio> // fast
#include <iostream> // slow
#include <cwchar> // slow
#include "c:\libcxx\include\support\win32\support.h" // slow
#include <cassert> // fast
#include <type_traits> // fast

* g++ is not effected this way. Compile time is near instant in all situations.

* I use Windows 7 64 and libcxx to see these results. It may or may not be
reproducible on non Windows platforms.

* It may (or may not) be that there is some kind of recursive include problem
here with libcxx (though I've yet to see that). If that is the problem, clang++
does not warn of this but is effected. g++ does not warn either, but is not
effected, g++'s time is fast and consistent. If it turns out that a nesting
issue in libcxx is the problem, clang++ should spot this if possible(?) and
warn. If it's not a nesting problem, whatever the problem is it seems wrong and
should be fixed as g++ doesn't take this long to compile the example.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130930/ced9f966/attachment.html>