| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This adds support to sarif-replay to display fix-it hints
stored in GCC's SARIF output.
gcc/ChangeLog:
* libsarifreplay.cc (sarif_replayer::handle_result_obj): Call
handle_fix_object if we see a single-element "fixes" array.
(sarif_replayer::handle_fix_object): New.
(sarif_replayer::handle_artifact_change_object): New.
gcc/testsuite/ChangeLog:
* sarif-replay.dg/2.1.0-valid/3.27.30-fixes-1.sarif: New test.
* sarif-replay.dg/2.1.0-valid/3.27.30-fixes-2.sarif: New test.
* sarif-replay.dg/2.1.0-valid/3.27.30-fixes-3.sarif: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
|
|
Our SARIF output supplies "error" for the rule ID for DK_ERROR,
since a value is required, but it's not useful to print in sarif-replay.
Filter it out.
gcc/ChangeLog:
* libsarifreplay.cc (should_add_rule_p): New.
(sarif_replayer::handle_result_obj): Use it to filter out rules
that don't make sense.
gcc/testsuite/ChangeLog:
* sarif-replay.dg/2.1.0-valid/3.28.6-annotations-1.sarif: Update
expected output to remove trailing " [error]".
* sarif-replay.dg/2.1.0-valid/unlabelled-secondary-locations.sarif:
Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
|
|
Given the .sarif output from e.g.:
too-many-arguments.c: In function 'test_known_fn':
too-many-arguments.c:14:3: error: too many arguments to function 'fn_a'; expected 0, have 1
14 | fn_a (42);
| ^~~~ ~~
too-many-arguments.c:8:13: note: declared here
8 | extern void fn_a ();
| ^~~~
the underlining of the stray argument (the "42") is captured in
'relatedLocations' (§3.27.22) but previously sarif-replay would not
display this:
In function 'test_known_fn':
too-many-arguments.c:14:3: error: too many arguments to function 'fn_a'; expected 0, have 1 [error]
14 | fn_a (42);
| ^~~~
too-many-arguments.c:8:13: note: declared here
8 | extern void fn_a ();
| ^~~~
With this patch sarif-replay handles the relatedLocations element as
a secondary location in libgdiagnostics, and correctly underlines
the "42":
In function 'test_known_fn':
too-many-arguments.c:14:3: error: too many arguments to function 'fn_a'; expected 0, have 1 [error]
14 | fn_a (42);
| ^~~~ ~~
too-many-arguments.c:8:13: note: declared here
8 | extern void fn_a ();
| ^~~~
gcc/ChangeLog:
* libsarifreplay.cc (sarif_replayer::handle_result_obj): Treat any
relatedLocations without messages as secondary ranges within the
diagnostic. Doing so requires stashing the notes until after
the diagnostic has been finished, so that relatedLocations can be
walked in one pass.
gcc/testsuite/ChangeLog:
* sarif-replay.dg/2.1.0-valid/unlabelled-secondary-locations.sarif:
New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
|
|
In our .sarif output from e.g.:
bad-binary-op.c: In function ‘test_4’:
bad-binary-op.c:19:23: error: invalid operands to binary + (have ‘S’ {aka ‘struct s’} and ‘T’ {aka ‘struct t’})
19 | return callee_4a () + callee_4b ();
| ~~~~~~~~~~~~ ^ ~~~~~~~~~~~~
| | |
| | T {aka struct t}
| S {aka struct s}
the labelled ranges are captured in the 'annotations' property of the
'location' object (§3.28.6).
However sarif-replay emits just:
In function 'test_4':
bad-binary-op.c:19:23: error: invalid operands to binary + (have ‘S’ {aka ‘struct s’} and ‘T’ {aka ‘struct t’}) [error]
19 | return callee_4a () + callee_4b ();
| ^
missing the labelled ranges.
This patch adds support to sarif-replay for the 'annotations' property;
with this patch we emit:
In function 'test_4':
bad-binary-op.c:19:23: error: invalid operands to binary + (have ‘S’ {aka ‘struct s’} and ‘T’ {aka ‘struct t’}) [error]
19 | return callee_4a () + callee_4b ();
| ~~~~~~~~~~~~ ^ ~~~~~~~~~~~~
| | |
| | T {aka struct t}
| S {aka struct s}
thus showing the labelled ranges.
Doing so requires adding a new entrypoint to libgdiagnostics:
diagnostic_physical_location_get_file
Given that we haven't yet released a stable version and that
sarif-replay is built together with libgdiagnostics I didn't
bother updating the ABI version.
gcc/ChangeLog:
PR sarif-replay/118881
* doc/libgdiagnostics/topics/physical-locations.rst: Add
diagnostic_physical_location_get_file.
* libgdiagnostics++.h (physical_location::get_file): New wrapper.
(diagnostic::add_location): Likewise.
* libgdiagnostics.cc (diagnostic_manager::get_file_by_name): New.
(diagnostic_physical_location::get_file): New.
(diagnostic_physical_location_get_file): New.
* libgdiagnostics.h (diagnostic_physical_location_get_file): New.
* libgdiagnostics.map (diagnostic_physical_location_get_file): New.
* libsarifreplay.cc (class annotation): New.
(add_any_annotations): New.
(sarif_replayer::handle_result_obj): Collect vectors of
annotations in the calls to handle_location_object and apply them
to "err" and to "note" as appropriate.
(sarif_replayer::handle_thread_flow_location_object): Pass nullptr
for annotations.
(sarif_replayer::handle_location_object): Handle §3.28.6
"annotations" property, using it to populate a new
"out_annotations" param.
gcc/testsuite/ChangeLog:
PR sarif-replay/118881
* sarif-replay.dg/2.1.0-valid/3.28.6-annotations-1.sarif: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
|
|
There are two separate issues making various template parameters behave
as if they were TU-local.
Firstly, the TU-local detection code uses WILDCARD_TYPE_P to check for
types that are not yet concrete; for some reason UNBOUND_CLASS_TEMPLATE
is not on that list. I don't see any particular reason why it shouldn't
be, so this patch adds it; this may solve other latent issues as well.
Secondly, the TEMPLATE_DECL for a type with expressions involving
TEMPLATE_TEMPLATE_PARM_Ps is currently always constrained to internal
linkage, because the result does not have TREE_PUBLIC set. Rather than
messing with TREE_PUBLIC here, I think rather we just should ensure that
we only attempt to constrain visiblity of templates of type, variable,
or function decls.
PR c++/118846
gcc/cp/ChangeLog:
* cp-tree.h (WILDCARD_TYPE_P): Include UNBOUND_CLASS_TEMPLATE.
* decl2.cc (min_vis_expr_r): Don't assume a TEMPLATE_DECL will
be a function or variable.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr118846_a.C: New test.
* g++.dg/modules/pr118846_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
I forgot to add the -O necessary to reproduce the bug before pushing the
fix.
PR c++/118053
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/constexpr-lambda1.C: Add -O.
|
|
Here during constant evaluation we encounter a VAR_DECL with DECL_VALUE_EXPR
of the RESULT_DECL, where the latter has been adjusted for
pass-by-invisible-reference. We already had the code to deal with this, we
just need to use it in the non-capture case of DECL_VALUE_EXPR as well.
PR c++/118053
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_constant_expression): Generalize
DECL_VALUE_EXPR invisiref handling.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/constexpr-lambda1.C: New test.
|
|
gcc/fortran/ChangeLog:
PR fortran/118159
* invoke.texi: Remove mention of defunct web site for Coco.
|
|
The fix for PR 118845 introduced new checks, which in turn exposed
a case where the typespec information on a symbol generated symbol
was not set. This led to an apparent type of BT_UNKNOWN, and hence
an error. Fixed as obvoius and simple.
gcc/fortran/ChangeLog:
* frontend-passes.cc (check_externals_procedure): Copy
typespec from old to new symbol.
gcc/testsuite/ChangeLog:
* gfortran.dg/interface_54.f90: New test.
|
|
As of Subversion r231013 (Git commit 00e5241831c1227615a45b7bcba29c393671cb3f)
"[PTX] Another libcall patch", only used 'nvptx_record_needed_fndecl' is
locally.
gcc/
* config/nvptx/nvptx.cc (nvptx_record_needed_fndecl): Tag as
'static'.
|
|
When using riscv_v_abi, the return and arguments of the function should
be adequately checked to avoid ICE.
PR target/118872
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_fntype_abi): Strengthen the logic
of the check to avoid missing the error report.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr118872.c: New test.
Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Jin Ma <jinma@linux.alibaba.com>
|
|
|
|
gcc/po/
* gcc.pot: Regenerate.
libcpp/po/
* cpplib.pot: Regenerate.
|
|
Fixed by r12-4425 and it seemed worth adding.
PR c++/83144
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-83144.C: New test.
|
|
gcc/cp/ChangeLog:
* pt.cc (tsubst_expr) <COMPONENT_REF>: Assign the result of
force_paren_expr.
|
|
After register allocation, paradoxical subregs may become something
like r20:SI += r22:SI which doesn't make much sense as assembly code.
Hence avr_out_plus_1() used to ICE on such code. However, paradoxical
subregs appear to be a common optimization device (instead of proper
mode demotion).
PR target/118878
gcc/
* config/avr/avr.cc (avr_out_plus_1): Don't ICE on result of
paradoxical reg's register allocation.
gcc/testsuite/
* gcc.target/avr/torture/pr118878.c: New test.
|
|
In commit 7f1989249e25af6fc0f124452efa24b3796b767a
"[gcn] Set 'UI_NONE' for 'TARGET_EXCEPT_UNWIND_INFO' [PR94282]", we've copied
the 'UI_NONE' idea from nvptx to GCN.
I understand the intention of using 'UI_NONE' like this, and it happens to work
in a lot of cases, but there are ICEs elsewhere: code paths where we run into
'internal compiler error: in get_personality_function, at expr.cc:13512':
13494 /* Extracts the personality function of DECL and returns the corresponding
13495 libfunc. */
13496
13497 rtx
13498 get_personality_function (tree decl)
13499 {
13500 tree personality = DECL_FUNCTION_PERSONALITY (decl);
13501 enum eh_personality_kind pk;
13502
13503 pk = function_needs_eh_personality (DECL_STRUCT_FUNCTION (decl));
13504 if (pk == eh_personality_none)
13505 return NULL;
13506
13507 if (!personality
13508 && pk == eh_personality_any)
13509 personality = lang_hooks.eh_personality ();
13510
13511 if (pk == eh_personality_lang)
13512 gcc_assert (personality != NULL_TREE);
13513
13514 return XEXP (DECL_RTL (personality), 0);
13515 }
..., where 'lang_hooks.eh_personality ()' ends up calling
'gcc/expr.cc:build_personality_function', and we 'return NULL;' for 'UI_NONE':
13448 /* Build a decl for a personality function given a language prefix. */
13449
13450 tree
13451 build_personality_function (const char *lang)
13452 {
13453 const char *unwind_and_version;
13454 tree decl, type;
13455 char *name;
13456
13457 switch (targetm_common.except_unwind_info (&global_options))
13458 {
13459 case UI_NONE:
13460 return NULL;
[...]
(Comparing to nvptx' current use of 'UI_NONE', this problem (ICEs mentioned
above) is way more prevalent for GCN.)
The GCC internals documentation indeed states, 'gcc/doc/tm.texi':
@deftypefn {Common Target Hook} {enum unwind_info_type} TARGET_EXCEPT_UNWIND_INFO (struct gcc_options *@var{opts})
This hook defines the mechanism that will be used for exception handling
by the target. If the target has ABI specified unwind tables, the hook
should return @code{UI_TARGET}. If the target is to use the
@code{setjmp}/@code{longjmp}-based exception handling scheme, the hook
should return @code{UI_SJLJ}. If the target supports DWARF 2 frame unwind
information, the hook should return @code{UI_DWARF2}.
A target may, if exceptions are disabled, choose to return @code{UI_NONE}.
This may end up simplifying other parts of target-specific code. [...]
Here, note: "if exceptions are disabled" (meaning: '-fno-exceptions' etc.) may
"return @code{UI_NONE}". That's what other back ends do with code like:
/* For simplicity elsewhere in this file, indicate that all unwind
info is disabled if we're not emitting unwind tables. */
if (!opts->x_flag_exceptions && !opts->x_flag_unwind_tables)
return UI_NONE;
else
return UI_TARGET;
The corresponding "simplifying other parts of target-specific code"/
"simplicity elsewhere" would then be the early returns from
'TARGET_ASM_UNWIND_EMIT', 'ARM_OUTPUT_FN_UNWIND', etc. for
'TARGET_EXCEPT_UNWIND_INFO != UI_TARGET' (that is, for 'UI_NONE').
From the documentation (and implementation), however, it does *not* follow that
if a target doesn't implement support for exception handling, it may just set
'UI_NONE' for 'TARGET_EXCEPT_UNWIND_INFO'.
Therefore, switch to 'UI_TARGET', allocating a "fake" 'exception_section'.
With that, all these 'internal compiler error: in get_personality_function'
test cases turn into PASS, or UNSUPPORTED ('exception handling not supported'),
or re-classify into a few other, already known issues. And, this change also
happens to resolve the class of errors identified in GCC PR113331
"AMDGCN: Compilation failure due to duplicate .LEHB<n>/.LEHE<n> symbols".
(In case that use of 'UI_NONE' like originally intended really makes sense, and
is preferable over this 'UI_TARGET' solution, then more work will be necessary
for implementing the missing parts, where 'UI_NONE' currently isn't handled.)
PR target/94282
PR target/113331
gcc/
* common/config/gcn/gcn-common.cc (gcn_except_unwind_info): 'return UI_TARGET;'.
* config/gcn/gcn.cc (gcn_asm_init_sections): New function.
(TARGET_ASM_INIT_SECTIONS): '#define'.
|
|
Subversion r263265 (Git commit 77e0a97acf7b00c1e68e4738fdf275a4cffc2e50)
"[nvptx] Ignore c++ exceptions", originally had set 'UI_TARGET', but as part of
Subversion r263287 (Git commit d989dba8ef02c2406b7c9e62b352197dffc6b880)
"[c++] Don't emit exception tables for UI_NONE", then switched to 'UI_NONE'.
I understand the intention of using 'UI_NONE' like this, and it happens to work
in a lot of cases, but there are ICEs elsewhere: code paths where we run into
'internal compiler error: in get_personality_function, at expr.cc:13512':
13494 /* Extracts the personality function of DECL and returns the corresponding
13495 libfunc. */
13496
13497 rtx
13498 get_personality_function (tree decl)
13499 {
13500 tree personality = DECL_FUNCTION_PERSONALITY (decl);
13501 enum eh_personality_kind pk;
13502
13503 pk = function_needs_eh_personality (DECL_STRUCT_FUNCTION (decl));
13504 if (pk == eh_personality_none)
13505 return NULL;
13506
13507 if (!personality
13508 && pk == eh_personality_any)
13509 personality = lang_hooks.eh_personality ();
13510
13511 if (pk == eh_personality_lang)
13512 gcc_assert (personality != NULL_TREE);
13513
13514 return XEXP (DECL_RTL (personality), 0);
13515 }
..., where 'lang_hooks.eh_personality ()' ends up calling
'gcc/expr.cc:build_personality_function', and we 'return NULL;' for 'UI_NONE':
13448 /* Build a decl for a personality function given a language prefix. */
13449
13450 tree
13451 build_personality_function (const char *lang)
13452 {
13453 const char *unwind_and_version;
13454 tree decl, type;
13455 char *name;
13456
13457 switch (targetm_common.except_unwind_info (&global_options))
13458 {
13459 case UI_NONE:
13460 return NULL;
[...]
(Comparing to nvptx' current use of 'UI_NONE', this problem (ICEs mentioned
above) is way more prevalent for GCN.)
The GCC internals documentation indeed states, 'gcc/doc/tm.texi':
@deftypefn {Common Target Hook} {enum unwind_info_type} TARGET_EXCEPT_UNWIND_INFO (struct gcc_options *@var{opts})
This hook defines the mechanism that will be used for exception handling
by the target. If the target has ABI specified unwind tables, the hook
should return @code{UI_TARGET}. If the target is to use the
@code{setjmp}/@code{longjmp}-based exception handling scheme, the hook
should return @code{UI_SJLJ}. If the target supports DWARF 2 frame unwind
information, the hook should return @code{UI_DWARF2}.
A target may, if exceptions are disabled, choose to return @code{UI_NONE}.
This may end up simplifying other parts of target-specific code. [...]
Here, note: "if exceptions are disabled" (meaning: '-fno-exceptions' etc.) may
"return @code{UI_NONE}". That's what other back ends do with code like:
/* For simplicity elsewhere in this file, indicate that all unwind
info is disabled if we're not emitting unwind tables. */
if (!opts->x_flag_exceptions && !opts->x_flag_unwind_tables)
return UI_NONE;
else
return UI_TARGET;
The corresponding "simplifying other parts of target-specific code"/
"simplicity elsewhere" would then be the early returns from
'TARGET_ASM_UNWIND_EMIT', 'ARM_OUTPUT_FN_UNWIND', etc. for
'TARGET_EXCEPT_UNWIND_INFO != UI_TARGET' (that is, for 'UI_NONE').
From the documentation (and implementation), however, it does *not* follow that
if a target doesn't implement support for exception handling, it may just set
'UI_NONE' for 'TARGET_EXCEPT_UNWIND_INFO'.
Therefore, switch (back) to 'UI_TARGET', implementing some basic support for
'exception_section': discard (via a PTX comment block) whatever GCC writes into
it.
With that, all these 'internal compiler error: in get_personality_function'
test cases turn into PASS, or UNSUPPORTED ('exception handling not supported'),
or re-classify into a few other, already known issues.
(In case that use of 'UI_NONE' like originally intended really makes sense, and
is preferable over this 'UI_TARGET' solution, then more work will be necessary
for implementing the missing parts, where 'UI_NONE' currently isn't handled.)
PR target/86660
gcc/
* common/config/nvptx/nvptx-common.cc (nvptx_except_unwind_info):
'return UI_TARGET;'.
* config/nvptx/nvptx.cc (nvptx_assemble_integer): Handle
'exception_section'.
(nvptx_output_section_asm_op, nvptx_asm_init_sections): New
functions.
(TARGET_ASM_INIT_SECTIONS): '#define'.
* config/nvptx/nvptx.h (TEXT_SECTION_ASM_OP, DATA_SECTION_ASM_OP):
Don't '#define'.
(ASM_OUTPUT_DWARF_DELTA): '#define'.
|
|
The 'init_frag' machinery is used by 'nvptx_assemble_integer' (via
'TARGET_ASM_INTEGER'), 'nvptx_output_skip' (via 'ASM_OUTPUT_SKIP'),
'nvptx_output_ascii' (via 'ASM_OUTPUT_ASCII'). But, it's not obvious that
these are called only when that machinery is active (and in a consistent
state), which it only is in 'nvptx_output_aligned_decl' (via
'ASM_OUTPUT_ALIGNED_DECL_COMMON', or 'ASM_OUTPUT_ALIGNED_DECL_LOCAL'), or in
'nvptx_assemble_undefined_decl' (via 'TARGET_ASM_ASSEMBLE_UNDEFINED_DECL'), or
within a region started by 'nvptx_assemble_decl_begin' (via
'nvptx_asm_declare_constant_name' (via 'TARGET_ASM_DECLARE_CONSTANT_NAME'), or
via 'nvptx_declare_object_name' (via 'ASM_DECLARE_OBJECT_NAME')) and ended by
'nvptx_assemble_decl_end' (via 'TARGET_ASM_DECL_END').
And indeed, in a GCC/nvptx offloading configuration, we then find that
'nvptx_output_skip' (via 'ASM_OUTPUT_SKIP') is getting called in inconsistent
'init_frag' state, in 'gcc/varasm.cc', via 'assemble_zeros', from
'output_object_block', to "Move to the object's offset, padding with zeros".
Supposedly, this didn't cause any damage, but we now handle it explicitly.
(..., and the question remains whether such "padding" etc. shouldn't actually
be attempted for targets like nvptx.)
gcc/
* config/nvptx/nvptx.cc (init_frag): New 'bool active' member.
(output_init_frag, nvptx_assemble_value, nvptx_assemble_integer)
(nvptx_output_skip, nvptx_assemble_decl_begin)
(nvptx_assemble_decl_end): Sanity-check its state.
|
|
I was getting confused about 'nvptx_output_skip' in certain cases not doing
anything at all; write down and 'assert' what I found.
gcc/
* config/nvptx/nvptx.cc (nvptx_output_skip): Clarify case of
no or incomplete initializer.
|
|
Fixed by the PR118265 fix r15-7339-g26d3424ca5d9f4.
PR c++/86933
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/variadic-nontype1.C: Mention PR number.
* g++.dg/cpp1z/variadic-nontype2.C: New test.
|
|
Fixed by r8-6829-gaaec81f10fa314; before that:
Segmentation fault (core dumped)
PR c++/82936
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/vt-82936.C: New test.
|
|
Fixed by r10-3735.
PR c++/82794
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-pr82794.C: New test.
|
|
Fixed by r11-735 + r11-2417.
PR c++/70037
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-pr70037.C: New test.
|
|
Fixed by r11-175.
PR c++/66878
gcc/testsuite/ChangeLog:
* g++.dg/lookup/using71.C: New test.
|
|
Fixed by r10-6464.
PR c++/66519
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/variadic-parm2.C: New test.
|
|
502.gcc_r when built with -fprofile-generate exposes a SLP discovery
issue where an IV forced live due to early break is not properly
discovered if its latch def is part of a different IVs SSA cycle.
To mitigate this we have to make sure to create an SLP instance
for the original IV. Ideally we'd handle all vect_induction_def
the same but this is left for next stage1.
PR tree-optimization/118852
* tree-vect-slp.cc (vect_analyze_slp): For early-break
forced-live IVs make sure we create an appropriate
entry into the SLP graph.
* gcc.dg/vect/pr118852.c: New testcase.
|
|
A later testcase in PR118856 highlights a preexisting problem with multiple
reference-extended temporaries in a single declaration; if initializing a
later one throws, the cleanup for the earlier one is not in scope yet.
Let's deal with this by keeping a dummy TARGET_EXPR to hold the EH cleanup
until all other initialization is complete. See the comment for various
other considered approaches.
We now avoid extending TARGET_EXPRs with CLEANUP_EH_ONLY set; all such
TARGET_EXPRs were already only internal iterator/flag variables that don't
want to be extended, as they are dead after initialization is complete even
if other temporaries are extended. But some other internal temporaries did
not have the flag set because they don't have TARGET_EXPR_CLEANUP; I
introduce a get_internal_target_expr function to set the flag rather than
directly set the flag (and add a comment) in such places. The places
changed to call get_internal_target_expr either already set the flag, or
have no cleanup at all.
PR c++/118856
gcc/cp/ChangeLog:
* call.cc (set_up_extended_ref_temp): Retain a TARGET_EXPR for
cleanups if something later in initialization throws.
(extend_temps_r): Don't extend eliding or EH-only TARGET_EXPRs.
* cp-tree.h (get_internal_target_expr): Declare.
* tree.cc (get_internal_target_expr): New.
* decl.cc (cp_finish_decomp, expand_static_init): Use it.
* except.cc (build_throw): Likewise.
* init.cc (build_new_1, build_vec_init, build_delete): Likewise.
(build_vec_delete): Likewise.
* typeck2.cc (maybe_push_temp_cleanup): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/eh/ref-temp3.C: New test.
* g++.dg/eh/ref-temp4.C: New test.
|
|
We had a stray U+2019 right single quotation mark instead of U+0027
apostrophe.
gcc/cp/ChangeLog:
* init.cc (perform_member_init): Remove unicode from comment.
|
|
Here we have:
template<typename T>
struct X{
T val;
decltype(auto) value(){
return (val);
}
};
where the return type of value should be 'int &' since '(val)' is an
expression, not a name, and decltype(auto) performs the type deduction
using the decltype rules.
The problem is that we weren't propagating REF_PARENTHESIZED_P
correctly: the return value of finish_non_static_data_member in this
test was a REFERENCE_REF_P, so we didn't set the flag. We should
use force_paren_expr like below.
PR c++/116379
gcc/cp/ChangeLog:
* pt.cc (tsubst_expr) <COMPONENT_REF>: Use force_paren_expr to set
REF_PARENTHESIZED_P.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/decltype-auto9.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
The ggc_set_mark call in gt_value_expr_mark_2 is actually wrong, that
just marks the VAR_DECL itself, but doesn't mark the subtrees of it (type
etc.). So, I think we need to test gcc_marked_p for whether it is marked
or not, if not marked walk the DECL_VALUE_EXPR and then gt_ggc_mx mark
the VAR_DECL that was determined not marked and needs to be marked now.
One option would be to call gt_ggc_mx (t) right after the DECL_VALUE_EXPR
walking, but I'm a little bit worried that the subtree marking could mark
other VAR_DECLs (e.g. seen from DECL_SIZE or TREE_TYPE and the like) and
if they would be DECL_HAS_VALUE_EXPR_P we might not walk their
DECL_VALUE_EXPR anymore later.
So, the patch defers the gt_ggc_mx calls until we've walked all the
DECL_VALUE_EXPRs directly or indirectly connected to already marked
VAR_DECLs.
2025-02-14 Jakub Jelinek <jakub@redhat.com>
PR debug/118790
* tree.cc (struct gt_value_expr_mark_data): New type.
(gt_value_expr_mark_2): Don't call ggc_set_mark, instead check
ggc_marked_p. Treat data as gt_value_expr_mark_data * with pset
in it rather than address of the pset itself and push to be marked
VAR_DECLs into to_mark vec.
(gt_value_expr_mark_1): Change argument from hash_set<tree> *
to gt_value_expr_mark_data * and find pset in it.
(gt_value_expr_mark): Pass to traverse_noresize address of
gt_value_expr_mark_data object rather than hash_table<tree> and
for all entries in the to_mark vector after the traversal call
gt_ggc_mx.
|
|
After changing this cost from 1 to 3, the performance of spec2006
401 473 416 465 482 can be improved by about 2% on LA664.
Add option '-maddr-reg-reg-cost='.
gcc/ChangeLog:
* config/loongarch/genopts/loongarch.opt.in: Add
option '-maddr-reg-reg-cost='.
* config/loongarch/loongarch-def.cc
(loongarch_rtx_cost_data::loongarch_rtx_cost_data): Initialize
addr_reg_reg_cost to 3.
* config/loongarch/loongarch-opts.cc
(loongarch_target_option_override): If '-maddr-reg-reg-cost='
is not used, set it to the initial value.
* config/loongarch/loongarch-tune.h
(struct loongarch_rtx_cost_data): Add the member
addr_reg_reg_cost and its assignment function to the structure
loongarch_rtx_cost_data.
* config/loongarch/loongarch.cc (loongarch_address_insns):
Use la_addr_reg_reg_cost to set the cost of ADDRESS_REG_REG.
* config/loongarch/loongarch.opt: Regenerate.
* config/loongarch/loongarch.opt.urls: Regenerate.
* doc/invoke.texi: Add description of '-maddr-reg-reg-cost='.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/const-double-zero-stx.c: Add
'-maddr-reg-reg-cost=1'.
* gcc.target/loongarch/stack-check-alloca-1.c: Likewise.
|
|
[PR118843].
PR target/118843
gcc/ChangeLog:
* config/loongarch/loongarch-c.cc
(loongarch_update_cpp_builtins): Fix macro definition issues.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/pr118843.c: New test.
|
|
PR target/118828
gcc/ChangeLog:
* config/loongarch/loongarch-c.cc (loongarch_pragma_target_parse):
Update the predefined macros.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/pr118828.c: New test.
* gcc.target/loongarch/pr118828-2.c: New test.
* gcc.target/loongarch/pr118828-3.c: New test.
* gcc.target/loongarch/pr118828-4.c: New test.
|
|
Split the implementation of the function loongarch_cpu_cpp_builtins into two parts:
1. Macro definitions that do not change (only considering 64-bit architecture)
2. Macro definitions that change with different compilation options.
gcc/ChangeLog:
* config/loongarch/loongarch-c.cc (builtin_undef): New macro.
(loongarch_cpu_cpp_builtins): Split to loongarch_update_cpp_builtins
and loongarch_define_unconditional_macros.
(loongarch_def_or_undef): New functions.
(loongarch_define_unconditional_macros): Likewise.
(loongarch_update_cpp_builtins): Likewise.
|
|
gcc/ChangeLog:
* config/loongarch/loongarch-target-attr.cc
(loongarch_pragma_target_parse): Move to ...
(loongarch_register_pragmas): Move to ...
* config/loongarch/loongarch-c.cc
(loongarch_pragma_target_parse): ... here.
(loongarch_register_pragmas): ... here.
* config/loongarch/loongarch-protos.h
(loongarch_process_target_attr): Function Declaration.
|
|
For the testcase in question which uses a fold-left vectorized
reduction of a reverse iterating loop we'd need two forwprop
invocations to first bypass the permute emitted for the reverse
iterating loop and then to decompose the vector load that only
feeds element extracts. The following moves the first transform
to a match.pd pattern and makes sure we fold the element extracts
when the vectorizer emits them so the single forwprop pass can
then pick up the vector load decomposition, avoiding the forwarding
fail that causes.
Moving simplify_bitfield_ref also makes forwprop remove the dead
VEC_PERM_EXPR via the simple-dce it uses - this was also
previously missing.
PR tree-optimization/90579
* tree-ssa-forwprop.cc (simplify_bitfield_ref): Move to
match.pd.
(pass_forwprop::execute): Adjust.
* match.pd (bit_field_ref (vec_perm ...)): New pattern
modeled after simplify_bitfield_ref.
* tree-vect-loop.cc (vect_expand_fold_left): Fold the
element extract stmt, combining it with the vector def.
* gcc.target/i386/pr90579.c: New testcase.
|
|
In r15-7202 we made lambdas between a template parameter scope and a
class/function/initializer be considered TU-local, in lieu of working
out how to mangle them to the succeeding declaration.
I neglected to clear any existing mangling on the template declaration
however; this means that such lambdas can occasionally get a lambda
scope, and will in general inherit the lambda scope of their
instantiation context (whatever that might be).
This patch ensures that the scope is cleared on the template declaration
as well.
gcc/cp/ChangeLog:
* lambda.cc (record_lambda_scope): Clear mangling scope for
otherwise unattached lambdas in class member templates.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-uneval22.C: Add check that the primary
specialisation of the lambda is TU-local.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
|
|
My fix for this issue in r15-7147 turns out to not be quite sufficient;
static member templates apparently go down a different code path and
need their own handling.
PR c++/107741
gcc/cp/ChangeLog:
* cp-tree.h (is_static_data_member_initialized_in_class):
Declare new predicate.
* decl2.cc (start_initialized_static_member): Push the
TEMPLATE_DECL when appropriate.
(is_static_data_member_initialized_in_class): New predicate.
(finish_initialized_static_member): Use it.
* lambda.cc (record_lambda_scope): Likewise.
* parser.cc (cp_parser_init_declarator): Start the member decl
early for static members so that lambda scope is set.
(cp_parser_template_declaration_after_parameters): Don't
register in-class initialized static members here.
gcc/testsuite/ChangeLog:
* g++.dg/abi/lambda-ctx2-19.C: Add tests for template members.
* g++.dg/abi/lambda-ctx2-19vs20.C: Likewise.
* g++.dg/abi/lambda-ctx2-20.C: Likewise.
* g++.dg/abi/lambda-ctx2.h: Likewise.
* g++.dg/cpp0x/static-member-init-1.C: Likewise.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
|
|
|
|
Hi,
in PR118832 we have another instance of the problem already noticed in
PR117878. We sometimes use e.g. expand_simple_binop for vector
operations like shift or and. While this is usually OK, it causes
problems when doing it late, e.g. during LRA.
In particular, we might rematerialize a const_vector during LRA, which
then leaves an insn laying around that cannot be split any more if it
requires a pseudo. Therefore we should only use the split variants
in expand_const_vector.
This patch fixed the issue in the PR and also pre-emptively rewrites two
other spots that might be prone to the same issue.
Regtested on rv64gcv_zvl512b. As the two other cases don't have a test
(so might not even trigger) I unconditionally enabled them for my testsuite
run.
Regards
Robin
PR target/118832
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_const_vector): Expand as
vlmax insn during lra.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr118832.c: New test.
|
|
I added class jit_diagnostic_listener in r15-4760-g0b73e9382ab51c
but forgot to annotate one of the vfuncs with "override".
Fixed thusly.
gcc/jit/ChangeLog:
PR other/116613
* dummy-frontend.cc
(jit_diagnostic_listener::on_report_diagnostic): Add
"final override".
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
|
|
As the manual states, using "-fhardened -fstack-protector" will produce
a warning because -fhardened wants to enable -fstack-protector-strong,
but it can't since it's been overriden by the weaker -fstack-protector.
-fhardened also attempts to enable -Wl,-z,relro,-z,now. By the same
logic as above, "-fhardened -z norelro" or "-fhardened -z lazy" should
produce the same warning. But we don't detect this combination, so
this patch fixes it. I also renamed a variable to better reflect its
purpose.
Also don't check warn_hardened in process_command, since it's always
true there.
Also tweak wording in the manual as Jon Wakely suggested on IRC.
PR driver/117739
gcc/ChangeLog:
* doc/invoke.texi: Tweak wording for -Whardened.
* gcc.cc (driver_handle_option): If -z lazy or -z norelro was
specified, don't enable linker hardening.
(process_command): Don't check warn_hardened.
gcc/testsuite/ChangeLog:
* c-c++-common/fhardened-16.c: New test.
* c-c++-common/fhardened-17.c: New test.
* c-c++-common/fhardened-18.c: New test.
* c-c++-common/fhardened-19.c: New test.
* c-c++-common/fhardened-20.c: New test.
* c-c++-common/fhardened-21.c: New test.
Reviewed-by: Jakub Jelinek <jakub@redhat.com>
|
|
This test added by r15-7507 doesn't get some expected diagnostics if we
implicitly make I(E) constexpr.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/nontype-class72.C: Disable -fimplicit-constexpr.
|
|
Per https://wiki.dwarfstd.org/C++0x_Variadic_templates.md
DW_TAG_GNU_formal_parameter_pack should have a DW_AT_name:
17$: DW_TAG_formal_parameter_pack
DW_AT_name("args")
18$: DW_TAG_formal_parameter
! no DW_AT_name attribute
DW_AT_type(reference to 13$)
(...)
PR c++/70536
gcc/ChangeLog:
* dwarf2out.cc (gen_formal_parameter_pack_die): Add name attr.
gcc/testsuite/ChangeLog:
* g++.dg/debug/dwarf2/template-func-params-7.C: Check for pack names.
Co-authored-by: Jason Merrill <jason@redhat.com>
|
|
gcc/cp/ChangeLog:
* tree.cc (handle_init_priority_attribute): Use OPT_prio_ctor_dtor.
gcc/testsuite/ChangeLog:
* g++.dg/special/initp1.C: Test disabling -Wprio-ctor-dtor.
|
|
In r15-6707 I changed this function to use build_stub_object to more simply
produce the right type, but it occurs to me that forward_parm would be even
better, specifically for the diagnostic.
This changes nothing with respect to PR118791.
gcc/cp/ChangeLog:
* decl.cc (omp_declare_variant_finalize_one): Use forward_parm.
gcc/testsuite/ChangeLog:
* g++.dg/gomp/declare-variant-3.C: Adjust diagnostic.
* g++.dg/gomp/declare-variant-5.C: Adjust diagnostic.
|
|
This was an interesting regression. It came from my recent
patch, where an assert was triggered because a procedure artificial
dummy argument generated for a global symbol did not have the
information if if was a function or a subroutine. Fixed by
adding the information in gfc_get_formal_from_actual_arglist.
This information then uncovered some new errors, also in the
testsuite, which needed fixing. Finally, the error is made to
look a bit nicer, so the user gets a pointer to where the
original interface comes from.
gcc/fortran/ChangeLog:
PR fortran/118845
* interface.cc (compare_parameter): If the formal attribute has been
generated from an actual argument list, also output an pointer to
there in case of an error.
(gfc_get_formal_from_actual_arglist): Set function and subroutine
attributes and (if it is a function) the typespec from the actual
argument.
gcc/testsuite/ChangeLog:
PR fortran/118845
* gfortran.dg/recursive_check_4.f03: Adjust call so types matche.
* gfortran.dg/recursive_check_6.f03: Likewise.
* gfortran.dg/specifics_2.f90: Adjust calls so types match.
* gfortran.dg/interface_52.f90: New test.
* gfortran.dg/interface_53.f90: New test.
|
|
Some things in the front-end use a TARGET_EXPR to create a temporary, then
refer to its TARGET_EXPR_SLOT separately later; in this testcase,
maybe_init_list_as_range does. So we need to handle that pattern in
extend_all_temps.
PR c++/118856
gcc/cp/ChangeLog:
* call.cc (struct extend_temps_data): Add var_map.
(extend_all_temps): Adjust.
(set_up_extended_ref_temp): Make walk_data void*.
(extend_temps_r): Remap variables. Handle pset here.
Extend all TARGET_EXPRs.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/range-for9.C: New test.
|
|
This proposal was implemented a long time ago by my r9-5271,
but it took me this long to verify that it still works as per P2308.
This patch adds assorted tests, both from clang and from [temp.arg.nontype].
Fortunately I did not discover any issues in the compiler.
PR c++/113800
DR 2450
gcc/testsuite/ChangeLog:
* g++.dg/cpp26/pack-indexing15.C: New test.
* g++.dg/cpp2a/nontype-class68.C: New test.
* g++.dg/cpp2a/nontype-class69.C: New test.
* g++.dg/cpp2a/nontype-class70.C: New test.
* g++.dg/cpp2a/nontype-class71.C: New test.
* g++.dg/cpp2a/nontype-class72.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
|
