gcc/
PR middle-end/53153
* gimplify.c (preprocess_case_label_vec_for_gimple): New function,
split out from ...
(gimplify_switch_expr): ... here.
* gimple.h (preprocess_case_label_vec_for_gimple): Add prototype.
* tree-ssa-forwprop.c (simplify_gimple_switch_label_vec): New function
to clean up case labels with values outside the index type range.
(simplify_gimple_switch): Call it if something changed.
Remove strange and unnecessary assert.
testsuite/
PR middle-end/53153
* gcc.dg/pr53153.c: New test.
From-SVN: r187048
2012-05-02 Richard Guenther <rguenther@suse.de>
* tree.c (valid_constant_size_p): New function.
* tree.h (valid_constant_size_p): Declare.
* cfgexpand.c (expand_one_var): Adjust check for too large
variables by using valid_constant_size_p.
* varasm.c (assemble_variable): Likewise.
c/
* c-decl.c (grokdeclarator): Properly check for sizes that
cover more than half of the address-space.
cp/
* decl.c (grokdeclarator): Properly check for sizes that
cover more than half of the address-space.
2012-05-02 Richard Guenther <rguenther@suse.de>
* fold-const.c (div_if_zero_remainder): sizetypes no longer
sign-extend.
(int_const_binop_1): New worker for int_const_binop with
overflowable parameter. Pass it through
to force_fit_type_double.
(int_const_binop): Wrap around int_const_binop_1 with overflowable
equal to one.
(size_binop_loc): Call int_const_binop_1 with overflowable equal
to minus one, forcing overflow detection for even unsigned types.
(extract_muldiv_1): Remove bogus TYPE_IS_SIZETYPE special-casing.
(fold_binary_loc): Call try_move_mult_to_index with signed offset.
* stor-layout.c (initialize_sizetypes): sizetypes no longer
sign-extend.
(layout_type): For zero-sized arrays ignore overflow on the
size calculations.
* tree-ssa-ccp.c (bit_value_unop_1): Likewise.
(bit_value_binop_1): Likewise.
* tree.c (double_int_to_tree): Likewise.
(double_int_fits_to_tree_p): Likewise.
(force_fit_type_double): Likewise.
(host_integerp): Likewise.
(int_fits_type_p): Likewise.
* varasm.c (output_constructor_regular_field): Sign-extend the
field-offset to cater for negative offsets produced by the Ada frontend.
* omp-low.c (extract_omp_for_data): Convert the loop step to
signed for pointer adjustments.
* g++.dg/tree-ssa/pr19807.C: Adjust.
From-SVN: r187042
PR rtl-optimization/53160
* ree.c (combine_reaching_defs): Handle the case where cand->insn
has been modified by ree pass already.
* gcc.c-torture/execute/pr53160.c: New test.
From-SVN: r187035
gcc/:
PR c/37303
* c-decl.c (build_compound_literal): Make the decl readonly if it
an array of a readonly type.
* gimplify.c (gimplify_compound_literal_expr): Add fallback
parameter. Change all callers. If the decl is not addressable
and is not an l-value, make it readonly.
gcc/testsuite:
PR c/37303
* gcc.dg/pr37303.c: New test.
From-SVN: r187027
* ira.c (allocated_reg_info_size): New static variable.
(expand_reg_info): Manage it. Call
setup_preferred_alternate_classes_for_new_pseudos.
(ira): Don't do it here. Remove local allocated_reg_info_size,
set the global before calling find_moveable_pseudos.
(find_moveable_pseudos): Call expand_reg_info rather than
resize_reg_info.
From-SVN: r187019
PR target/53038
* config/rs6000/rs6000.c (load_lr_save, restore_saved_lr,
load_cr_save, add_crlr_cfa_restore): New functions.
(rs6000_restore_saved_cr): Rename to..
(restore_saved_cr): ..this. Add cfa_restore notes for cr.
(rs6000_emit_epilogue): Use new functions. Adjust condition
for emitting lr and cr cfa_restore. Emit cfa_restores for fp
regs when using out-of-line restore only when shrink wrapping.
From-SVN: r187010
2012-04-30 Andrew Stubbs <ams@codesourcery.com>
* config/arm/arm.md (negdi2): Use gen_negdi2_neon.
* config/arm/neon.md (negdi2_neon): New insn.
Also add splitters for core and NEON registers.
From-SVN: r186984
Several warnings related to questionable usage cases of variadic
function related macros (like va_start) could not be controlled by any
warning-related macro. Fixed thus, by introducing the -Wvarargs
option.
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/c-family/
* c.opt (Wvarargs): Define new option.
gcc/
* builtins.c (fold_builtin_next_arg): Use OPT_Wvarargs as an
argument for the various warning_at calls.
gcc/doc/
* invoke.texi: Update the documentation.
gcc/testsuite/
* c-c++-common/Wvarargs.c: New test case.
* c-c++-common/Wvarargs-2.c: Likewise.
From-SVN: r186978
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
Even after all the patches I have already submitted, some test cases
where errors happens on tokens that are defined in macros see their
output change in an incompatible way, when you run them with or
without -ftrack-macro-expansion.
I think this is expected, because the (spelling) locus inside the
definition of the macro pointed to with -ftrack-macro-expansion is
different from the locus of the expansion point of the macro pointed
to without -ftrack-macro-expansion.
In those cases this patch either adjusts the test case and forces it
be run either with -ftrack-macro-expansion, or it just forces it to be
run without -ftrack-macro-expansion.
There are so many libstdc++ tests that were failing because of that
benign issue that I preferred to just run them with
-ftrack-macro-expansion diabled, after inspecting each of them to be
sure there was nothing more serious underneath.
Boostrapped on x86_64-unknown-linux-gnu against trunk with and without
-ftrack-macro-expansion turned on.
gcc/testsuite/
* objc.dg/foreach-7.m: Force the test case to run without
-ftrack-macro-expansion.
* c-c++-common/tm/attrib-1.c: Likewise.
* c-c++-common/warn-ommitted-condop.c: Likewise.
* gcc.dg/assign-warn-1.c: Likewise.
* gcc.dg/assign-warn-2.c: Likewise.
* gcc.dg/attr-alloc_size.c: Likewise.
* gcc.dg/builtin-stringop-chk-1.c: Likewise.
* gcc.dg/builtin-stringop-chk-2.c: Likewise.
* gcc.dg/builtin-strncat-chk-1.c: Likewise.
* gcc.dg/c90-const-expr-9.c: Likewise.
* gcc.dg/c99-const-expr-9.c: Likewise.
* gcc.dg/cpp/direct2.c: Likewise. Adjust.
* gcc.dg/cpp/direct2s.c: Likewise.
* gcc/testsuite/gcc.dg/cpp/pr28709.c: Likewise.
* gcc.dg/cpp/pragma-diagnostic-1.c: Likewise.
* gcc.dg/dfp/composite-type.c: Likewise.
* gcc.dg/uninit-6-O0.c: Adjust the test case and force it to run
with -ftrack-macro-expansion
* g++.dg/cpp0x/constexpr-ex3.C: Likewise.
* g++.dg/cpp0x/constexpr-overflow.C: Likewise.
* g++.dg/ext/cleanup-1.C: Likewise.
* g++.dg/ext/gnu-inline-global-reject.C: Likewise.
* g++.dg/template/sfinae10.C: Likewise.
* g++.dg/tm/wrap-2.C: Likewise.
* g++.dg/warn/Wconversion-real-integer.C: Likewise.
* g++.dg/warn/Wsign-conversion.C: Likewise.
* g++.dg/warn/multiple-overflow-warn-1.C: Likewise.
* g++.old-deja/g++.mike/p10769b.C: Likewise.
* g++.dg/warn/Wdouble-promotion.C: Adjust the test case and force
it to run with -ftrack-macro-expansion.
* libstdc++-v3/scripts/testsuite_flags.in: By default, run the
test cases without -ftrack-macro-expansion.
From-SVN: r186976
In gcc/testsuite/gcc.dg/pr30457.c, the first warning was not being
emitted because the relevant location was inside the var_start macro
defined in a system header. It can even point to a token for a
builtin macro there. This patch unwinds to the first token in real
source code in that case.
Tested on x86_64-unknown-linux-gnu against trunk.
* builtins.c (fold_builtin_next_arg): Unwinds to the first
location in real source code.
From-SVN: r186975
Consider the test case g++.dg/other/offsetof5.C:
#include <stddef.h>
struct A
{
char c;
int &i;
};
int j = offsetof (A, i); // { dg-warning "invalid access|offsetof" }
template <typename T>
struct S
{
T h;
T &i;
static const int j = offsetof (S, i); // { dg-warning "invalid access|offsetof" }
};
int k = S<int>::j; // { dg-message "required from here" }
The second warning (that involves the instantiation of the S template)
is not emitted when -ftrack-macro-expansion is on.
This is because during the instantiation of the member j of S
template, the location that is used for the warning is the one for the
DECL j (set by instantiate_decl). And that location is inaccurately
set to the locus of 'offsetof', which is a macro defined in a system
header, so it's discarded by the diagnostics machinery.
Note that when we reach the point where we emit the warning in
build_class_member_access_expr offsetof expression has long been
folded, so we cannot use e.g, the location of the ')' token that would
have been in the source code. So I believe the location of 'j' is the
best we can get at this point.
The patch below sets the location of the DECL for 'j' to what I
believe is its precise location; with that, the test case passes with
and without -ftrack-macro-expansion. But I had to adjust
g++.dg/template/sfinae6_neg.C for that.
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp
* decl.c (grokdeclarator): Use the location carried by the
declarator for the DECL of the static class member.
gcc/testsuite/
* g++.dg/template/sfinae6_neg.C: Adjust.
From-SVN: r186974
Now that diagnostics first point to the spelling location of tokens
coming from macro expansion, the test case
gcc/testsuite/g++.old-deja/g++.other/vaarg3.C shows that when I write
va_args (args, some_type), the location that is recorded for
"some_type" is not correct. We wrongly record a location that is in
the system header where the va_args macro is defined.
This patch changes that to correctly record the location for the type
operand of the va_arg expression.
With this patch applied, the
gcc/testsuite/g++.old-deja/g++.other/vaarg3.C test PASSes with and
without -ftrack-macro-expansion.
Tested 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.
gcc/cp/
* cp-tree.h (build_x_va_arg): Take an additional location
parameter.
* call.c (build_x_va_arg): Take a loc parameter for the location
of the type of the va_arg expression.
* parser.c (cp_parser_primary_expression): Pass the type of the
type in the va_arg expression to build_x_va_arg.
* pt.c (tsubst_copy): Adjust calls to build_x_va_arg.
From-SVN: r186973
There are various conversion related warnings that trigger on
potentially dangerous uses of NULL (or __null). NULL is defined as a
macro in a system header, so calling warning or warning_at on a
virtual location of NULL yields no diagnostic. So the test
accompanying this patch (as well as others), was failling when run
with -ftrack-macro-expansion.
I think it's necessary to use the location of NULL that is in the main
source code (instead of, e.g, the spelling location that is in the
system header where the macro is defined) in those cases. Note that
for __null, we don't have the issue.
I have augmented the test of this patch to check that we don't regress
when handling __null.
Tested 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.
gcc/
* input.h (expansion_point_location_if_in_system_header): Declare
new function.
* input.c (expansion_point_location_if_in_system_header): Define it.
gcc/cp/
* call.c (conversion_null_warnings): Use the new
expansion_point_location_if_in_system_header.
* cvt.c (build_expr_type_conversion): Likewise.
* typeck.c (cp_build_binary_op): Likewise.
gcc/testsuite/
* g++.dg/warn/Wconversion-null-2.C: Add testing for __null,
alongside the previous testing for NULL.
From-SVN: r186972
Besides the warning emitted by warn_uninit, this function wants
to hint the user at where the uninitialized variable was declared, for
cases where the declaration location is outside the current function.
Now that expand_location expands to the location that is in the main
source file (even for -ftrack-macro-expansion) the hinting part was
not working well for cases where the variable is declared in a macro
(outside the function), which is then expanded in the function.
So I had to adjust warn_uninit a little bit to make it consider the
spelling location of the variable declaration.
I have fixed the test gcc.dg/cpp/pragma-diagnostic-2.c on which I
believe gcc shouldn't emit any error.
Here is the new output on that test:
=~=
gcc.dg/cpp/pragma-diagnostic-2.c: In function 'g':
gcc.dg/cpp/pragma-diagnostic-2.c:10:5: warning: 'a' is used uninitialized in this function [-Wuninitialized]
gcc.dg/cpp/pragma-diagnostic-2.c:9:7: note: 'a' was declared here
gcc.dg/cpp/pragma-diagnostic-2.c:9:7: note: in expansion of macro 'CODE_WITH_WARNING'
gcc.dg/cpp/pragma-diagnostic-2.c:17:3: note: expanded from here
gcc.dg/cpp/pragma-diagnostic-2.c: In function 'h':
gcc.dg/cpp/pragma-diagnostic-2.c:10:5: warning: 'a' is used uninitialized in this function [-Wuninitialized]
gcc.dg/cpp/pragma-diagnostic-2.c:9:7: note: 'a' was declared here
gcc.dg/cpp/pragma-diagnostic-2.c:9:7: note: in expansion of macro 'CODE_WITH_WARNING'
gcc.dg/cpp/pragma-diagnostic-2.c:27:3: note: expanded from here
=~=
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.
gcc/
* tree-ssa.c (warn_uninit): Use the spelling location of the
variable declaration. Use linemap_location_before_p for source
locations.
gcc/testsuite/
* gcc.dg/cpp/pragma-diagnostic-2.c: Fix this.
From-SVN: r186971
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
Apparently, quite some places in the compiler (like the C/C++
preprocessor, the debug info machinery) expect expand_location to
resolve to locations that are in the main source file, even if the
token at stake comes from a macro that was defined in a header
somewhere. Turning on -ftrack-macro-expansion by default was
triggering a lot of failures (not necessarily related to diagnostics)
because expand_location resolves to spelling locations instead.
So I have changed expand_location to honour the initial expectation.
In addition, I came up with the new expand_location_to_spelling_point
used in diagnostic_build_prefix because the diagnostic system, on the
other hand, wants to point to the location of the token where it was
spelled, and then display the error context involving all the macro
whose expansion led to that spelling point - if we are in the context
of a macro expansion there.
This seems to me like a reasonable balance.
Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk and
whitnessed that a lot more tests were PASSing.
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.
gcc/
* input.c (expand_location_1): New. Takes a parameter to choose
whether to resolve the location to spelling or expansion point.
Was factorized from ...
(expand_location): ... here.
(expand_location_to_spelling_point): New. Implemented in terms of
expand_location_1.
* diagnostic.c (diagnostic_build_prefix): Use the new
expand_location_to_spelling_point instead of expand_location.
From-SVN: r186969
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
When -ftrack-macro-expansion is activated, the PCH generation
machinery can crash in gt_pch_save when it's about to relocate the
pointer for the
line_maps::info_macro::maps[i]::d.macro.macro_locations member.
The call that crashes (in ggc-common.c) is:
state.ptrs[i]->note_ptr_fn (state.ptrs[i]->obj,
state.ptrs[i]->note_ptr_cookie,
relocate_ptrs, &state);
The ->note_ptr_fn called in this case is the gengtype-generated
gt_pch_p_9line_maps function. It crashes because the second argument
passed to it is a pointer to struct line_map, instead of being a
pointer to struct line_maps (extra 's') like what the function
expects.
You can see the crash for the test case:
runtest --tool g++ --tool_opts="-ftrack-macro-expansion" pch.exp=system-1.C
I believe it's because a part of the code of gt_pch_nx_line_maps
(generated as part of gtype-desc.c by gengtype) is not correct. Note
that this gt_pch_nx_line_maps function is called from gt_pch_save in
the snippet:
for (rt = gt_ggc_rtab; *rt; rt++)
for (rti = *rt; rti->base != NULL; rti++)
for (i = 0; i < rti->nelt; i++)
(*rti->pchw)(*(void **)((char *)rti->base + rti->stride * i));
So, in that gt_pch_nx_line_maps, in the branch that starts with the
code:
if ((*x).info_macro.maps != NULL) {
size_t i3;
for (i3 = 0; i3 != (size_t)(((*x).info_macro).used); i3++) {
switch (((*x).info_macro.maps[i3]).reason == LC_ENTER_MACRO)
we have the code:
gt_pch_note_object ((*x).info_macro.maps[i3].d.macro.macro_locations,
(*x).info_macro.maps,
gt_pch_p_9line_maps,
gt_types_enum_last);
This last snippet registers gt_pch_p_9line_maps to be called on the
object pointed by (*x).info_macro.maps[i3].d.macro.macro_locations (as
a first argument), with (*x).info_macro.maps as its second argument.
Note that (*x).info_macro.maps is of type struct line_map*, while 'x'
is of type struct line_maps* - beware, there is an 's' at the end of
the latter.
The problem is that gt_pch_p_9line_maps requires that its second
argument be an instance of _struct line_maps_, not struct line_map.
So later when gt_pch_p_9line_maps is called, it just crashes.
More generally, these gt_pch_p_xxx functions seem to require that
their second argument be an instance of the xxx in question. And that
invariant is violated by the snippet of code above.
The invariant seems to be violated only for the case where a GTYed
structure (possibly embedded in another GTYed structure) contains a
pointer to a scalar (that is not a string) which memory is ggc/GTY
managed, like the line_map_macro::macro_locations field. And this
only happens for PCH generation.
Looking at gengtype.c, it seems like write_types_process_field can be
fooled in that case. It expects that the expression d->prev_val[3]
contains the name of the second argument of the gt_pch_p_xxx (which is
generically referenced by wtd->subfield_marker_routine there). That
expression can resolve to either "x", as we would like it to be, but
can also resolve to another arbitrary name for e.g, the case of a
pointer-to-struct used as a root).
This patch simply forces the second argument of gt_pch_p_xxx to be 'x'
even in the case of a member that is a pointer to a scalar.
As a result, here is the the diff the new generated gtype-desc.c file:
@@ -5234,7 +5234,7 @@ gt_pch_nx_line_maps (void *x_p)
size_t i2;
for (i2 = 0; i2 != (size_t)(2 * ((*x).info_ordinary.maps[i0].d.macro).n_tokens); i2++) {
}
- gt_pch_note_object ((*x).info_ordinary.maps[i0].d.macro.macro_locations, (*x).info_ordinary.maps, gt_pch_p_9line_maps, gt_types_enum_last);
+ gt_pch_note_object ((*x).info_ordinary.maps[i0].d.macro.macro_locations, x, gt_pch_p_9line_maps, gt_types_enum_last);
}
break;
default:
@@ -5261,7 +5261,7 @@ gt_pch_nx_line_maps (void *x_p)
size_t i5;
for (i5 = 0; i5 != (size_t)(2 * ((*x).info_macro.maps[i3].d.macro).n_tokens); i5++) {
}
- gt_pch_note_object ((*x).info_macro.maps[i3].d.macro.macro_locations, (*x).info_macro.maps, gt_pch_p_9line_maps, gt_types_enum_last);
+ gt_pch_note_object ((*x).info_macro.maps[i3].d.macro.macro_locations, x, gt_pch_p_9line_maps, gt_types_enum_last);
}
break;
default:
@@ -9366,7 +9366,7 @@ gt_pch_na_regno_reg_rtx (ATTRIBUTE_UNUSED void *x_p)
for (i1 = 0; i1 != (size_t)(crtl->emit.x_reg_rtx_no); i1++) {
gt_pch_n_7rtx_def (regno_reg_rtx[i1]);
}
- gt_pch_note_object (regno_reg_rtx, ®no_reg_rtx, gt_pch_pa_regno_reg_rtx, gt_types_enum_last);
+ gt_pch_note_object (regno_reg_rtx, x, gt_pch_pa_regno_reg_rtx, gt_types_enum_last);
}
}
I think it's pretty much what I was willing to have.
Bootstrapped and tested 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.
gcc/
* gengtype.c (write_types_process_field): Force second argument
of the call to the PCH object hierarchy walker to be 'x'.
From-SVN: r186967
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
Steven Bosscher
Arnaud Charlet
Richard Guenther
Jakub Jelinek
GCC Administrator
Ian Lance Taylor
François Dumont
Bernd Schmidt
Richard Henderson
Kenneth Zadeck
Ian Bolton
Greta Yorsh
Richard Earnshaw
Alan Modra
Uros Bizjak
Jan Hubicka
Marc Glisse
Uros Bizjak
Manuel López-Ibáñez
Jason Merrill
Ian Lance Taylor
Andrew Stubbs
Richard Earnshaw
Dodji Seketeli