* line-map.c (linemap_enter_macro): Don't zero max_column_hint in
every macro. This improves performance by reducing the number of
reallocations when track-macro-expansion is on.
From-SVN: r188242
The location for a built-in macro token is BUILTIN_LOCATION. When we
see that location value, we cannot know if that token was used in a
system header or not. And that can trigger some unwanted warnings on
e.g, the use of __LONG_LONG_MAX__ built-in macro in system headers
when we compile with -pedantic, like in the test case accompanying
this patch.
In that case, I think we ought to step-up to see where the built-in
macro has been expanded, until we see a location that is not for a
built-in macro. Then we can check if the resulting location is in a
system header or not.
Now that we step up to the location of first non-built-in-macro token,
it appeared that for
testsuite/c-c++-common/dfp/convert-int-saturate.c, G++ then fails to
emit the warning in:
volatile unsigned int usi;
int
main ()
{
usi = DEC32_MAX; /* { dg-warning "overflow in implicit constant conversion" } */
...
}
Because DEC32_MAX is defined in the system header float.h as a
built-in macro:
#define DEC32_MAX __DEC32_MAX__
And during the parsing of the assignment expression that should have
led to the warning above, input_location is set to the location for
the DEC32_MAX, which is actually the location for the built-in
__DECL32_MAX_EXP.
A possible fix is to use the location of the "=" operator as the
default location for assignment expressions. This is what the patch
does.
I had to adjust a couple of tests to arrange for this.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
libcpp/
PR preprocessor/53463
* line-map.c (linemap_location_in_system_header_p): For built-in
macro tokens, check the first expansion point location for that is
not for a token coming from a built-in macro.
gcc/cp/
PR preprocessor/53463
* parser.c (cp_parser_assignment_expression): Use the location
for the LHS as the default location for the expression.
gcc/testsuite/
PR preprocessor/53463
* g++.dg/cpp/limits.C: New test.
* g++.dg/parse/error19.C: Adjust.
* g++.dg/warn/Wconversion-real-integer2.C: Likewise.
* g++.dg/warn/pr35635.C: Likewise.
* g++.old-deja/g++.pt/assign1.C: Likewise.
From-SVN: r188203
As stated in the audit trail of this problem report, consider this
test case:
$ cat test.c
1 struct x {
2 int i;
3 };
4 struct x x;
5
6 #define TEST(X) x.##X
7
8 void foo (void)
9 {
10 TEST(i) = 0;
11 }
$
$ cc1 -quiet test.c
test.c: In function 'foo':
test.c:10:1: error: pasting "." and "i" does not give a valid preprocessing token
TEST(i) = 0;
^
$
So, when pasting tokens, the error diagnostic uses the global and
imprecise input_location variable, leading to an imprecise output.
To properly fix this, I think libcpp should keep the token of the
pasting operator '##', instead of representing it with flag on the LHS
operand's token. That way, it could use its location. Doing that
would be quite intrusive though. So this patch just uses the location
of the LHS of the pasting operator, for now. It's IMHO better than
the current situation.
The patch makes paste_tokens take a location parameter that is used in
the diagnostics. This change can still be useful later when we can
use the location of the pasting operator, because paste_tokens will
just be passed the new, more precise location.
Incidentally, it appeared that when getting tokens from within
preprocessor directives (like what is done in gcc.dg/cpp/paste12.c),
with -ftrack-macro-expansion disabled, the location of the expansion
point of macros was being lost because
cpp_reader::set_invocation_location wasn't being properly set. It's
because when cpp_get_token_1 calls enter_macro_context, there is a
little period of time between the beginning of that later function and
when the macro is really pushed (and thus when the macro is really
expanded) where we wrongly consider that we are not expanding the
macro because macro_of_context is still NULL. In that period of time,
in the occurrences of indirect recursive calls to cpp_get_token_1,
this later function wrongly sets cpp_reader::invocation_location
because cpp_reader::set_invocation_location is not being properly set.
To avoid that confusion the patch does away with
cpp_reader::set_invocation_location and introduces a new flag
cpp_reader::about_to_expand_macro_p that is set in the small time
interval exposed earlier. A new in_macro_expansion_p is introduced as
well, so that cpp_get_token_1 can now accurately detect when we are in
the process of expanding a macro, and thus correctly collect the
location of the expansion point.
People seem to like screenshots.
Thus, after the patch, we now have:
$ cc1 -quiet test.c
test.c: In function 'foo':
test.c:6:18: error: pasting "." and "i" does not give a valid preprocessing token
#define TEST(X) x.##X
^
test.c:10:3: note: in expansion of macro 'TEST'
TEST(i) = 0;
^
$
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
libcpp/
PR preprocessor/53229
* internal.h (cpp_reader::set_invocation_location): Remove.
(cpp_reader::about_to_expand_macro_p): New member flag.
* directives.c (do_pragma): Remove Kludge as
pfile->set_invocation_location is no more.
* macro.c (cpp_get_token_1): Do away with the use of
cpp_reader::set_invocation_location. Just collect the macro
expansion point when we are about to expand the top-most macro.
Do not override cpp_reader::about_to_expand_macro_p.
This fixes gcc.dg/cpp/paste12.c by making get_token_no_padding
properly handle locations of expansion points.
(cpp_get_token_with_location): Adjust, as
cpp_reader::set_invocation_location is no more.
(paste_tokens): Take a virtual location parameter for
the LHS of the pasting operator. Use it in diagnostics. Update
comments.
(paste_all_tokens): Tighten the assert. Propagate the location of
the expansion point when no virtual locations are available.
Pass the virtual location to paste_tokens.
(in_macro_expansion_p): New static function.
(enter_macro_context): Set the cpp_reader::about_to_expand_macro_p
flag until we really start expanding the macro.
gcc/testsuite/
PR preprocessor/53229
* gcc.dg/cpp/paste6.c: Force to run without
-ftrack-macro-expansion.
* gcc.dg/cpp/paste8.c: Likewise.
* gcc.dg/cpp/paste8-2.c: New test, like paste8.c but run with
-ftrack-macro-expansion.
* gcc.dg/cpp/paste12.c: Force to run without
-ftrack-macro-expansion.
* gcc.dg/cpp/paste12-2.c: New test, like paste12.c but run with
-ftrack-macro-expansion.
* gcc.dg/cpp/paste13.c: Likewise.
* gcc.dg/cpp/paste14.c: Likewise.
* gcc.dg/cpp/paste14-2.c: New test, like paste14.c but run with
-ftrack-macro-expansion.
* gcc.dg/cpp/paste18.c: New test.
From-SVN: r187945
Now that we track token locations accross macro expansions, it would
be cool to be able to fix PR preprocessor/7263 for real. That is,
consider this example where we have a system header named header.h
like this:
#define _Complex __complex__ #define _Complex_I 1.0iF
and then a normal C file like this:
#include "header.h"
static _Complex float c = _Complex_I;
If we compile the file with -pedantic, the usages of _Complex or
_Complex_I should not trigger any warning, even though __complex__ and
the complex literal are extensions to the standard C.
They shouldn't trigger any warning because _Complex and _Complex_I are
defined in a system header (and expanded in normal user code).
To be able to handle this, we must address two separate concerns.
First, warnings about non-standard usage of numerical literals are emitted
directly from within libcpp. So we must teach libcpp's parser for numerical
literals to use virtual locations, instead of the spelling
location it uses today. Once we have that, as the diagnostics machinery
already knows how to avoid emitting errors happening on tokens that come from
system headers, we win.
Second, there is the issue of tracking locations for declaration
specifiers, like the "_Complex" in the declaration:
static _Complex float c;
For that, we need to arrange for each possible declaration specifier
to have its own location, because otherwise, we'd warn on e.g, on:
_Complex float c;
but not on:
static _Complex float c;
So this patch addresses the two concerns above. It's actually a
follow-up on an earlier patch[1] I wrote as part of my initial work on
virtual locations. We then agreed[2] that the second concern was
important to address before the patch could get a chance to go in.
[1]: http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00957.html
[2]: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00264.html
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
libcpp/
PR preprocessor/7263
* include/cpplib.h (cpp_classify_number): Take a location
parameter.
* expr.c (SYNTAX_ERROR_AT, SYNTAX_ERROR2_AT): New diagnostic
macros that take a location parameter.
(cpp_classify_number): Take a (virtual) location parameter. Use
it for diagnostics. Adjust comments.
(eval_token): Take a location parameter. Pass it to
cpp_classify_number and to diagnostic routines.
(_cpp_parse_expr): Use virtual locations of tokens when parsing
expressions. Pass a virtual location to eval_token and to
diagnostic routines.
gcc/c-family/
PR preprocessor/7263
* c-lex.c (c_lex_with_flags): Pass a virtual location to the call
to cpp_classify_number. For diagnostics, use the precise location
instead of the global input_location.
gcc/
PR preprocessor/7263
* c-tree.h (enum c_declspec_word): Declare new enum.
(struct c_declspecs::locations): New member.
(declspecs_add_qual, declspecs_add_scspec)
(declspecs_add_addrspace, declspecs_add_alignas): Take a new
location parameter.
* c-decl.c (build_null_declspecs): Initialize the new struct
c_declspecs::locations member.
(declspecs_add_addrspace): Take a location parameter for the
address space. Store it onto declaration specifiers.
(declspecs_add_qual): Likewise, take a location parameter for the
qualifier.
(declspecs_add_type): Likewise, take a location parameter for the
type specifier.
(declspecs_add_scspec): Likewise, take a location parameter for
the storage class specifier.
(declspecs_add_attrs): Likewise, take a location parameter for the
first attribute.
(declspecs_add_alignas): Likewise, take a location parameter for
the alignas token.
(finish_declspecs): For diagnostics, use the location of the
relevant declspec, instead of the global input_location.
* c-parser.c (c_parser_parameter_declaration): Pass the precise
virtual location of the declspec to the declspecs-setters.
(c_parser_declspecs): Likewise. Avoid calling c_parser_peek_token
repeatedly.
gcc/cp/
PR preprocessor/7263
* cp-tree.h (enum cp_decl_spec): Add new enumerators to cover all
the possible declarator specifiers so far.
(struct cp_decl_specifier_seq::locations): Declare new member.
(cp_decl_specifier_seq::{specs, type_location}): Remove.
(decl_spec_seq_has_spec_p): Declare new function.
* parser.c (cp_parser_check_decl_spec): Remove.
(set_and_check_decl_spec_loc): Define new static function.
(decl_spec_seq_has_spec_p): Define new public function.
(cp_parser_decl_specifier_seq, cp_parser_function_specifier_opt)
(cp_parser_type_specifier, cp_parser_simple_type_specifier)
(cp_parser_set_storage_class, cp_parser_set_decl_spec_type)
(cp_parser_alias_declaration): Set the locations for each
declspec, using set_and_check_decl_spec_loc.
(cp_parser_explicit_instantiation, cp_parser_init_declarator)
(cp_parser_member_declaration, cp_parser_init_declarator): Use the
new declspec location for specifiers. Use the new
decl_spec_seq_has_spec_p.
(cp_parser_type_specifier_seq): Use the new
set_and_check_decl_spec_loc. Stop using
cp_parser_check_decl_spec. Use the new decl_spec_seq_has_spec_p.
(, cp_parser_init_declarator): Use the new
set_and_check_decl_spec_loc.
(cp_parser_single_declaration, cp_parser_friend_p)
(cp_parser_objc_class_ivars, cp_parser_objc_struct_declaration):
Use the new decl_spec_seq_has_spec_p.
* decl.c (check_tag_decl): Use new decl_spec_seq_has_spec_p. Use
the more precise ds_redefined_builtin_type_spec location for
diagnostics about re-declaring C++ built-in types.
(start_decl, grokvardecl, grokdeclarator): Use the new
decl_spec_seq_has_spec_p.
gcc/testsuite/
PR preprocessor/7263
* gcc.dg/binary-constants-2.c: Run without tracking locations
accross macro expansion.
* gcc.dg/binary-constants-3.c: Likewise.
* gcc.dg/cpp/sysmac2.c: Likewise.
* testsuite/gcc.dg/nofixed-point-2.c: Adjust for more precise
location.
* gcc.dg/cpp/syshdr3.c: New test.
* gcc.dg/cpp/syshdr3.h: New header for the new test above.
* gcc.dg/system-binary-constants-1.c: New test.
* gcc.dg/system-binary-constants-1.h: New header for the new test
above.
* g++.dg/cpp/syshdr3.C: New test.
* g++.dg/cpp/syshdr3.h: New header the new test above.
* g++.dg/system-binary-constants-1.C: New test.
* g++.dg/system-binary-constants-1.h: New header the new test
above.
From-SVN: r187587
destringize_and_run forgets to initialize all the fields of the
cpp_context that it pushes. Later _cpp_pop_context then gets confused
when it accesses context->tokens_kind via the call to macro_of_context
on context->prev.
The first hunk of this patch is the real obvious fix. The second hunk
is just an assert that I am adding to err on the safe side.
Tested by on x86_64-unknown-linux-gnu against trunk by running the
test gcc.dg/gomp/macro-4.c under Valgrind, and bootstrapped.
libcpp/
* directives.c (destringize_and_run): Properly initialize the new
context.
* macro.c (_cpp_pop_context): Assert that we shouldn't try to pop
the initial base context, which has the same life time as the
current instance of cpp_file.
From-SVN: r187054
This switches the compiler to -ftrack-macro-expansion=2 by default.
Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk.
libcpp/
* init.c (cpp_create_reader): Switch -ftrack-macro-expansion=2 on
by default. Add comments.
gcc/docs/
* cppopts.texi: Adjust for enabling -ftrack-macro-expansion=2 by
default.
From-SVN: r186977
Now that diagnostics for tokens coming from macro expansions point to
the spelling location of the relevant token (and then displays the
context of the expansion), some ugly (not so seldom) corner cases can
happen.
When the relevant token is a built-in token (which means the location
of that token is BUILTINS_LOCATION) the location prefix displayed to
the user in the diagnostic line is the "<built-in>:0:0" string. For
instance:
<built-in>:0:0: warning: conversion to 'float' alters 'int' constant value
For the user, I think this is surprising and useless.
A more user-friendly approach would be to refer to the first location
that (in the reported macro expansion context) is for a location in
real source code, like what is shown in the new test case
gcc/testsuite/g++.dg/warn/Wconversion-real-integer2.C accompanying
this patch.
To do this, I am making the line-map module provide a new
linemap_unwind_to_first_non_reserved_loc function that resolves a
virtual location to the first spelling location that is in real source
code.
I am then using that facility in the diagnostics printing module and
in the macro unwinder to avoid printing diagnostics lines that refer
to the locations for built-ins or more generally for reserved
locations. Note that when I start the dance of skipping a built-in
location I also skip locations that are in system headers, because it
turned out that a lot of those built-ins are actually used in system
headers (e.g, "#define INT_MAX __INT_MAX__" where __INT_MAX__ is a
built-in).
Besides the user-friendliness gain, this patch allows a number of
regression tests to PASS unchanged with and without
-ftrack-macro-expansion.
Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk.
Note that the bootstrap with -ftrack-macro-expansion exhibits other
separate issues that are addressed in subsequent patches. This patch
just fixes one class of problems.
The patch does pass bootstrap with -ftrack-macro-expansion turned off,
though.
libcpp/
* include/line-map.h (linemap_unwind_toward_expansion): Fix typo
in comment.
(linemap_unwind_to_first_non_reserved_loc): Declare new function.
* line-map.c (linemap_unwind_to_first_non_reserved_loc): Define
new function.
gcc/
* input.c (expand_location_1): When expanding to spelling location
in a context of a macro expansion, skip reserved system header
locations. Update comments. * tree-diagnostic.c
(maybe_unwind_expanded_macro_loc): Likewise.
gcc/testsuite/
* g++.dg/warn/Wconversion-real-integer2.C: New test.
* g++.dg/warn/Wconversion-real-integer-3.C: Likewise.
* g++.dg/warn/conversion-real-integer-3.h: New header used by the
new test above.
From-SVN: r186970
Consider the test case gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c.
Its interesting part is:
#define A(x) vari x /* line 7. */
#define vari(x)
#define B , varj
int A(B) ; /* line 10. */
In its initial version, this test was being pre-processed as:
# 1 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c"
# 1 "build/gcc//"
# 1 "<command-line>"
# 1 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c"
# 10 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c"
int
# 7 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c"
vari
, varj ;
Note how "int" and "vari" are on separate lines, whereas "int" and
", varj" are on the same line.
This looks like a bug to me, even independantly from the macro
location tracking work.
With macro location tracking turned on, the preprocessed output
becomes:
# 1 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c"
# 1 "<command-line>"
# 1 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c"
# 10 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c"
int vari , varj ;
Which, IMO, is what we'd expect.
This is due to an unexpected side effect of enter_macro_context when
passed a token that might look like a function-like macro at first
sight, but that it eventually considers to not be a macro after all.
This is the case for the "vari" token which looks like a macro when it
is first lexed, but is eventually considered to be a normal token by
enter_macro_context because it's not used as a function-like macro
invocation.
In that case, besides returning NULL, enter_macro_context sets
pfile->context->c.macro to NULL, making cpp_get_token_1 forget to set
the location of the "vari" to the expansion point of A.
enter_macro_context sets pfile->context->c.macro to NULL in that case
because funlike_invocation_p reads one token pass "foo", sees that
there is no '(' token, so we are not invoking the function-like
parameter. It then puts the tokens (which it has read after "foo")
back into the tokens stream by calling _cpp_push_token_context on it,
which sets pfile->context->c.macro to NULL, saying in essence that the
current macro expansion context is "stopped".
The fix here is to teach _cpp_push_token and
push_extended_tokens_context to continue the current macro context
when passed a NULL macro. But then, now that there can be several
continguous contexts associated with the same macro, we need to teach
_cpp_pop_context to re-enable the expansion of the current macro only
when we are really out of expanding the current macro. Otherwise we
can run in cases where we have recursive expansions of the same macro.
Tested on x86_64-unknown-linux-gnu against trunk. Now this test has
the same output with and without tracking locations accross macro
expansions.
Note that the bootstrap with -ftrack-macro-expansion exhibits other
separate issues that are addressed in subsequent patches. This patch
just fixes one class of problems.
The patch does pass bootstrap with -ftrack-macro-expansion turned off,
though.
libcpp/
* macro.c (macro_of_context): New static function.
(_cpp_push_token_context, push_extended_tokens_context): If the
macro argument is NULL, it means we are continuing the expansion
of the current macro, if any. Update comments.
(_cpp_pop_context): Re-enable expansion of the macro only when we
are really out of the context of the current expansion.
gcc/testsuite/
* gcc.dg/debug/dwarf2/pr41445-5.c: Adjust.
* gcc.dg/debug/dwarf2/pr41445-6.c: Likewise.
From-SVN: r186968
This patch makes token pasting work with -ftrack-macro-expansion
turned on. It improves some pasting related tests of the gcc.dg/cpp
subdirectory.
Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk.
Note that the bootstrap with -ftrack-macro-expansion exhibits other
separate issues that are addressed in subsequent patches. This patch
just fixes one class of problems.
The patch does pass bootstrap with -ftrack-macro-expansion turned off,
though.
libcpp/
* macro.c (paste_all_tokens): Put the token resulting from pasting
into an extended token context with -ftrack-macro-location is in
effect.
gcc/testsuite/
* gcc.dg/cpp/paste17.c: New test case for
-ftrack-macro-expansion=2 mode only.
* gcc.dg/cpp/macro-exp-tracking-5.c: Likewise.
From-SVN: r186966
cpp_sys_macro_p crashes when -ftrack-macro-expansion is on. The issue
can be reproduced by running the tests:
runtest --tool gcc --tool_opts="-ftrack-macro-expansion" cpp.exp=sysmac1.c
runtest --tool gcc --tool_opts="-ftrack-macro-expansion" cpp.exp=sysmac2.c
This is because it just doesn't support that mode. Fixed thus.
Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk.
Note that the bootstrap with -ftrack-macro-expansion turned on
exhibits other separate issues that are addressed in subsequent
patches. This patch just fixes one class of problems.
The patch does pass bootstrap with -ftrack-macro-expansion turned off,
though.
libcpp/
* macro.c (cpp_sys_macro_p): Support -ftrack-macro-expansion.
From-SVN: r186965
I noticed that the file lex.c had C++ style comments, which I believe
is against the coding standards of the project.
Fixed, tested and applied to master as per the obvious rule.
libcpp/
* lex.c (lex_raw_string): Change C++ style comments into C
style comments.
(lex_string): Likewise.
From-SVN: r186946
This option, which is enabled by default, causes the preprocessor to warn
when a string or character literal is followed by a ud-suffix which does
not begin with an underscore. According to [lex.ext]p10, this is
ill-formed.
Also modifies the preprocessor to treat such ill-formed suffixes as separate
preprocessing tokens. This is consistent with the Clang front end (see
http://llvm.org/viewvc/llvm-project?view=rev&revision=152287), and enables
backwards compatibility with code that uses formatting macros from
<inttypes.h>, as in the following code block:
int main() {
int64_t i64 = 123;
printf("My int64: %"PRId64"\n", i64);
}
Google ref b/6377711.
2012-04-27 Ollie Wild <aaw@google.com>
PR c++/52538
* gcc/c-family/c-common.c: Add CPP_W_LITERAL_SUFFIX mapping.
* gcc/c-family/c-opts.c (c_common_handle_option): Handle
OPT_Wliteral_suffix.
* gcc/c-family/c.opt: Add Wliteral-suffix.
* gcc/doc/invoke.texi (Wliteral-suffix): Document new option.
* gcc/testsuite/g++.dg/cpp0x/Wliteral-suffix.c: New test.
* libcpp/include/cpplib.h (struct cpp_options): Add new field,
warn_literal_suffix.
(CPP_W_LITERAL_SUFFIX): New enum.
* libcpp/init.c (cpp_create_reader): Default initialization of
warn_literal_suffix.
* libcpp/lex.c (lex_raw_string): Treat user-defined literals which
don't begin with '_' as separate tokens and produce a warning.
(lex_string): Ditto.
From-SVN: r186909
* c-decl.c (diagnose_mismatched_decls, grokdeclarator, grokfield)
(finish_struct): Refer to C11 in comments. Use flag_isoc11.
* c-parser.c (c_parser_static_assert_declaration)
(c_parser_static_assert_declaration_no_semi, c_parser_declspecs)
(c_parser_alignas_specifier, c_parser_alignof_expression): Refer
to C11 in comments. Use flag_isoc11.
* c-typeck.c (comptypes_check_different_types): Refer to C11 in
comment.
* doc/cpp.texi (Overview): Refer to -std=c11 instead of -std=c1x.
* doc/cppopts.texi (-std=c11, -std=gnu11): Document in preference
to -std=c1x and -std=gnu1x.
* doc/extend.texi (Inline, Alternate Keywords, Other Builtins)
(__builtin_complex, Unnamed Fields): Refer to -std=c11 and C11
instead of -std=c1x and C1X.
* doc/invoke.texi (-std=c11, -std=iso9899:2011): Document in
preference to -std=c1x.
(-std=gnu11): Document in preference to -std=gnu1x.
* doc/standards.texi: Document C11 instead of C1X. Document C11
as actual standard. Document headers required from freestanding
C11 implementations.
* ginclude/float.h, ginclude/stddef.h: Test __STDC_VERSION__ >=
201112L for C11. Update comments to refer to C11.
gcc/c-family:
* c-common.c (flag_isoc99): Update comment to refer to C11.
(flag_isoc1x): Change to flag_isoc11.
* c-common.h (flag_isoc99): Update comment to refer to C11.
(flag_isoc1x): Change to flag_isoc11.
* c-cppbuiltin.c (cpp_atomic_builtins): Change comment to refer to
C11.
* c-opts.c (set_std_c1x): Change to set_std_c11.
(c_common_handle_option): Handle OPT_std_c11 and OPT_std_gnu11.
Call set_std_c11.
(set_std_c89, set_std_c99, set_std_c11): Use flag_isoc11.
(set_std_c1): Use CLK_STDC11 and CLK_GNUC11.
* c.opt (std=c1x): Change to std=c11. Document as non-draft
standard.
(std=c1x, std=iso9899:2011): Add as aliases of std=c11.
(std=gnu1x): Change to std=gnu11. Refer to non-draft standard.
(std=gnu1x): Make alias of std=gnu11.
gcc/testsuite:
* gcc.dg/c11-version-1.c, gcc.dg/c11-version-2.c,
gcc.dg/c94-version-1.c, gcc.dg/c99-version-1.c,
gcc.dg/gnu11-version-1.c: New tests.
libcpp:
* include/cpplib.h (CLK_GNUC1X): Change to CLK_GNUC11.
(CLK_STDC1X): Change to CLK_STDC11.
* init.c (lang_defaults): Update comments.
(cpp_init_builtins): Update language tests. Use 201112L for C11
__STDC_VERSION__.
From-SVN: r182551
PR c++/50958
gcc/cp/
* parser.c (lookup_literal_operator): New.
(cp_parser_userdef_char_literal): Use it.
(cp_parser_userdef_numeric_literal): Use it.
(cp_parser_userdef_string_literal): Use lookup_name.
libcpp/
* expr.c (cpp_userdef_char_remove_type): Fix typo.
From-SVN: r181595
Uros Bizjak