hm, now I'm puzzled. If I compile with both -std=c++11 and -stdlib=libc++, then the current code works fine. It only breaks if I remover -stdlib=libc++, but then removing the construct overloads also fails.

For me, commenting out construct() is only needed with libc++, which makes sense, since Clang's default STL implementation is not C++-11 compliant. Maybe specialzing allocatior_traits is the way to go? According to http://home.roadrunner.com/~hinnant/stack_alloc.html C++-03 allocators should work in C++11...

One cannot remove both overloads of construct. The allocator requirements were weakened in C++11: construct is now *optional*, even though there is a new overload that is *allowed*.
Still, the C++11 overload is supposed to accept *any* pointer type, not just the allocator's `pointer` type. The code should still work fine like this, as allocator_traits is supposed to default to placement-new if a given call to construct is not well-formed. Why it doesn't work with certain compiler/library combinations, I can't tell for sure, but it sounds like a compiler/library bug.
Since the construct overloads are optional, and the current implementations merely perform the default behaviour anyway, they can both be removed for C++11.
Remember however, that I mentioned the requirements were *weakened*. In C++03, the single argument overload is still *required*.
In light of that I removed only the C++11 overload and the sample code compiles and runs fine with all of the following setups:
- gcc + libstdc++ @ C++03
- gcc + libstdc++ @ C++11
- clang + libstdc++ @ C++03
- clang + libstdc++ @ C++11
- clang + libc++ @ C++03
- clang + libc++ @ C++11
(commit here https://bitbucket.org/martinhofernandes/eigen/commits/450a9024838125a0569879450ffd3d512934e914)
I issued pull request #33 (https://bitbucket.org/eigen/eigen/pull-request/33/fix-for-bug-503/diff) for this.

Hmm, sadly, that pull request was kinda sorta not so good.
Thing is, removing the overload throws us into the adorable hell that is the spawn of the illicit relationship between implicit conversions and overload resolution.
Yes, `std::allocator_traits` will fill in whatever `construct` overloads are necessary, but in some cases it will think that the existing C++03 overload is good enough.
Consider:
struct foo {
foo(int);
foo(foo const&) = delete;
};
This type has an implicit conversion from int and cannot be copy-constructed.
Now suppose we call `v.emplace_back(42)` on some vector of `foo` with our allocator. `allocator_traits` check if `a.construct(42)` is well-formed for our allocator `a`, and if not, will provide its default implementation that does placement-new. But `a.construct(42)` is perfectly well-formed! `42` implicitly converts to a `foo` temporary, and a `foo` temporary matches the existing C++03 overload `construct(foo const&)`. allocator_traits will be extremely happy that for once one of those lazy allocator bastards has taken upon itself to do some work and just forward to that overload.
It's a story that ends in tears: that overload performs a copy and our type is not copyable.
So the C++11 overload *must exist* so that allocator_traits does the right thing and picks it over the C++03 overload. The correct implementation is:
template <typename U, typename... Args>
void construct( U* u, Args&&... args)
{
::new( static_cast<void*>(u) ) U( std::forward<Args>( args )... );
}
See PR#40 https://bitbucket.org/eigen/eigen/pull-request/40

What about making aligned_allocator inherit std::allocator so we do not have to bother about all these details and be more future proof?
We probably also have to add 'using base::construct' to be sure overloads are reachable.

(In reply to comment #11)
Martinho, do you have a self-contained example of your use case with class foo, because the following piece of code does not compile with gcc or clang, even without our aligned_allocator.
#include <vector>
struct Foo {
Foo(int);
Foo(Foo const&) = delete;
};
int main()
{
std::vector<Foo> vec;
vec.emplace_back(42);
return 0;
}

(In reply to comment #14)
My proposal in comment #13 fixes your issue, though it's weird that construct is called with a const pointer.
I'm trying to gather all the tricky cases we found so far before applying that change.

Apologies for my overly simplistic explanation above.
The issue with the bad `construct` being called shows up with types that are not copyable, as described. The type `foo` in the example is neither movable nor copyable, since providing a deleted definition of the copy constructor inhibits the automatic generation of the move constructor, which means it won't work in most containers, but that is unrelated to the issue with the allocator.
It should look as follows to be usable in vector, and still trigger the bad overload resolution.
struct foo {
foo(int) {}
foo(foo &&) = default;
foo(foo const&) = delete;
};