http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52538
Bug #: 52538 Summary: Extend C++11 UDLs to be compatible with inttypes.h macros Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jyass...@gcc.gnu.org C++11 defines user-defined literals in a way that breaks compatibility with some code that uses the formatting macros from <inttypes.h>: $ cat test.cc #define __STDC_FORMAT_MACROS #include <inttypes.h> #include <stdio.h> int main() { int64_t i64 = 123; printf("My int64: %"PRId64"\n", i64); } $ install_gcc46/bin/g++ -Wall test.cc -o test && ./test My int64: 123 $ install_gcc46/bin/g++ -std=c++0x -Wall test.cc -o test && ./test My int64: 123 $ install_gcc47/bin/g++-4.7pre -Wall test.cc -o test && ./test My int64: 123 $ install_gcc47/bin/g++-4.7pre -Wall -Wc++11-compat test.cc -o test && ./test My int64: 123 $ install_gcc47/bin/g++-4.7pre -std=c++0x -Wall test.cc -o test && ./test test.cc: In function ‘int main()’: test.cc:7:29: error: unable to find string literal operator ‘operator"" PRId64’ Clang is working around this by interpreting literal suffixes that don't start with underscores as separate tokens, which allows them to expand as macros: http://llvm.org/viewvc/llvm-project?view=rev&revision=152287 According to [lex.ext]p10 and [usrlit.suffix], these suffixes are ill-formed, no diagnostic required, so allowing them to expand as macros is a conforming extension. It would also be possible to fix the code by inserting a space between the " and the macro name, but in Google's codebase, this cleanup would be 3-4x as large as the narrowing conversion cleanup, which you have already made optional.