summaryrefslogtreecommitdiffstats
path: root/llvm/lib/System/Program.cpp
diff options
context:
space:
mode:
authorDouglas Gregor <dgregor@apple.com>2010-11-09 20:03:54 +0000
committerDouglas Gregor <dgregor@apple.com>2010-11-09 20:03:54 +0000
commit928479e727a0cdf5c245b30d708fe2de3b67bb08 (patch)
tree225ba60a751258a05d319c3b02d78c5fc4a0f5ec /llvm/lib/System/Program.cpp
parentf2e5a91ffbe37ebfd1b72555b4d4f773470be1fe (diff)
downloadbcm5719-llvm-928479e727a0cdf5c245b30d708fe2de3b67bb08.tar.gz
bcm5719-llvm-928479e727a0cdf5c245b30d708fe2de3b67bb08.zip
Revert the fix for PR8013.
That bug concerned the well-formedness of code such as (&ovl)(a, b, c). GCC rejects the code, while EDG accepts it. On further study of the standard, I see no support for EDG's position: in particular, C++ [over.over] does not list this as a context where we can take the address of an overloaded function, C++ [over.call.func] does not reference the address-of operator at any point, and C++ [expr.call] claims that the function argument in a call is either a function lvalue or a pointer-to-function; (&ovl) is neither. llvm-svn: 118620
Diffstat (limited to 'llvm/lib/System/Program.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud