Created attachment 7662 [details] preprocessed input from sample program, file mini.ii When running gdb on a program using an instance of the unique_ptr class template, the identifier 'tuple' can no longer be accessed in any way, as otherwise valid expressions now give a syntax error. A minimal example: mini.cpp: #include <memory> int main() { std::unique_ptr<int> p; } compile this with gcc (version 4.8.1) using the command g++ -std=c++11 -ggdb -o mini mini.cpp now run gdb and ask to print the (nonexistent) variable 'tuple' $ gdb mini GNU gdb (GDB) 7.6.1-ubuntu Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/license/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/marc/atlas/sources/stand-alone/mini...done. (gdb) p tuple A syntax error in expression, near `'. (gdb) Whereas in a program not using any unique_ptr (for instance the above program after removing the unique statement in 'main') one would correctly get (gdb) p tuple No symbol "tuple" in current context. It seems that 'tuple' has changed its syntax category for gdb, making any access to variables/fields called 'tuple' impossible. I stumbled on this when debugging a program that actually used a field of that name, but the bug does not appear to depend on that circumstance. Looking and the (attached) preprocessed input, it seems that the problem might be that 'tuple' is defined as a variadic template class: template<typename...> class tuple; and later template<typename... _Elements> class tuple : public _Tuple_impl<0, _Elements...> { ... };
Still occurs for me with gdb-7.10
*** Bug 22231 has been marked as a duplicate of this bug. ***
Maybe the canonical bug for this is bug#17272? There are also several bugs open about exposing this to the Python API. The fix seems to be stalled.
(In reply to Tom Tromey from comment #3) > Maybe the canonical bug for this is bug#17272? > There are also several bugs open about exposing this to the Python API. > The fix seems to be stalled. As I understand it, the problem here is about tuple being also the name of the include file, and that's why you get a syntax error. And according to c-exp.y, this behavior is intentional: ``` /* If we found a field on the "this" object, or we are looking up a field on a struct, then we want to prefer it over a filename. However, if the name was quoted, then it is better to check for a filename or a block, since this is the only way the user has of requiring the extension to be used. */ ``` So if no variable is found by the name, but one of the files has that name, it assumes the file is meant.