Make everything more gdb-friendly by using an enum for symbol constants
rather than #defines.
gcc/
* dwarf2codeview.cc (S_LDATA32, S_GDATA32, S_COMPILE3): Undefine.
(enum cv_sym_type): Define.
(struct codeview_symbol): Use enum cv_sym_type.
(write_codeview_symbols): Add default to switch.
Add the preliminary code that the generated expression for MASK may depend
on when generating the inline code to evaluate MINLOC or MAXLOC with a
scalar MASK.
The generated code was only keeping the generated expression but not the
preliminary code, which was sufficient for simple cases such as data
references or simple (scalar) function calls, but was bogus with more
complicated ones.
gcc/fortran/ChangeLog:
* trans-intrinsic.cc (gfc_conv_intrinsic_minmaxloc): Add the
preliminary code generated for MASK to the preliminary code of
MINLOC/MAXLOC.
gcc/testsuite/ChangeLog:
* gfortran.dg/minmaxloc_17.f90: New test.
As discussed in the thread starting at:
https://gcc.gnu.org/pipermail/gcc/2024-June/244199.html
it would be useful to have the @gcc.gnu.org bugzilla account names
in MAINTAINERS. This is because:
(a) Not every non-@gcc.gnu.org email listed in MAINTAINERS is registered
as a bugzilla user.
(b) Only @gcc.gnu.org accounts tend to have full rights to modify tickets.
(c) A maintainer's name and email address aren't always enough to guess
the bugzilla account name.
(d) The users list on bugzilla has many blank entries for "real name".
However, including @gcc.gnu.org to the account name might encourage
people to use it for ordinary email, rather than just for bugzilla.
This patch goes for the compromise of using the unqualified account
name, with some text near the top of the file to explain its usage.
There isn't room in the area maintainer sections for a new column,
so it seemed better to have the account name only in the Write
After Approval section. It's then necessary to list all maintainers
there, even if they have more specific roles as well.
Also, there were some entries that didn't line up with the
prevailing columns (they had one tab too many or one tab too few).
It seemed easier to check for and report this, and other things,
if the file used spaces rather than tabs.
There was one instance of an email address without the trailing ">".
The updates to check-MAINTAINERS.py includes a test for that.
The account names in the file were taken from a trawl of the
gcc-cvs archives, with a very small number of manual edits for
ambiguities. There are a handful of names that I couldn't find;
the new column has "-" for those. The names were then filtered
against the bugzilla @gcc.gnu.org user list, with those not
present again being blanked out with "-".
ChangeLog:
* MAINTAINERS: Replace tabs with spaces. Add a bugzilla account
name column to the Write After Approval section. Line up the
email column and fix an entry that was missing the trailing ">".
contrib/ChangeLog:
* check-MAINTAINERS.py (sort_by_surname): Replace with...
(get_surname): ...this.
(has_tab, is_empty): Delete.
(check_group): Take a list of column positions as argument.
Check that lines conform to these column numbers. Check that the
final column is an email in angle brackets. Record surnames on
the fly.
(top level): Reject tabs. Use paragraph counts to identify which
groups of lines should be checked. Report missing sections.
Since r6-4582-g8a64515099e645 (which added class rich_location), ranges
of quoted source code have been colorized using the following rules:
- the primary range used the same color of the kind of the diagnostic
i.e. "error" vs "warning" etc (defaulting to bold red and bold magenta
respectively)
- secondary ranges alternate between "range1" and "range2" (defaulting
to green and blue respectively)
This works for cases with large numbers of highlighted ranges, but is
suboptimal for common cases.
The following patch adds a pair of color names: "highlight-a" and
"highlight-b", and uses them whenever it makes sense to highlight and
contrast two different things in the source code (e.g. a type mismatch).
These are used by diagnostic-show-locus.cc for highlighting quoted
source. In addition the patch adds colorization to fragments within the
corresponding diagnostic messages themselves, using consistent
colorization between the message and the quoted source code for the two
different things being contrasted.
For example, consider:
demo.c: In function ‘test_bad_format_string_args’:
../../src/demo.c:25:18: warning: format ‘%i’ expects argument of
type ‘int’, but argument 2 has type ‘const char *’ [-Wformat=]
25 | printf("hello %i", msg);
| ~^ ~~~
| | |
| int const char *
| %s
Previously, the types within the message in quotes would be in bold but
not colorized, and the labelled ranges of quoted source code would use
bold magenta for the "int" and non-bold green for the "const char *".
With this patch:
- the "%i" and "int" in the message and the "int" in the quoted source
are all colored bold green
- the "const char *" in the message and in the quoted source are both
colored bold blue
so that the consistent use of contrasting color draws the reader's eyes
to the relationships between the diagnostic message and the source.
I've tried this with gnome-terminal with many themes, including a
variety of light versus dark backgrounds, solarized versus non-solarized
themes, etc, and it was readable in all.
My initial version of the patch used the existing %r and %R facilities
within pretty-print.cc for the messages, but this turned out to be very
uncomfortable, leading to error-prone format strings such as:
error_at (richloc,
"invalid operands to binary %s (have %<%r%T%R%> and %<%r%T%R%>)",
opname,
"highlight-a", type0,
"highlight-b", type1);
To avoid requiring monstrosities such as the above, the patch adds a new
"%e" format code to pretty-print.cc, which expects a pp_element *, where
pp_element is a new abstract base class (actually a pp_markup::element),
along with various useful subclasses. This lets the above be written
as:
pp_markup::element_quoted_type element_0 (type0, highlight_colors::lhs);
pp_markup::element_quoted_type element_1 (type1, highlight_colors::rhs);
error_at (richloc,
"invalid operands to binary %s (have %e and %e)",
opname, &element_0, &element_1);
which I feel is maintainable and clear to translators; the use of %e and
pp_element * captures the type-unsafe part of the variadic call, and the
subclasses allow for type-safety (so e.g. an element_quoted_type expects
a type and a highlighting color). This approach allows for some nice
simplifications within c-format.cc.
The patch also extends -Wformat to "teach" it about the new %e and
pp_element *. Doing so requires c-format.cc to be able to determine
if a T * is a pp_element * (i.e. if T is a subclass). To do so I added
a new comp_types callback for comparing types, where the C++ frontend
supplies a suitable implementation (and %e will always be wrong for C).
I've manually tested this on many diagnostics with both C and C++ and it
seems a subtle but significant improvement in readability.
I've added a new option -fno-diagnostics-show-highlight-colors in case
people prefer the old behavior.
gcc/c-family/ChangeLog:
* c-common.cc: Include "tree-pretty-print-markup.h".
(binary_op_error): Use pp_markup::element_quoted_type and %e.
(check_function_arguments): Add "comp_types" param and pass it to
check_function_format.
* c-common.h (check_function_arguments): Add "comp_types" param.
(check_function_format): Likewise.
* c-format.cc: Include "tree-pretty-print-markup.h".
(local_pp_element_ptr_node): New.
(PP_FORMAT_CHAR_TABLE): Add entry for %e.
(struct format_check_context): Add "m_comp_types" field.
(check_function_format): Add "comp_types" param and pass it to
check_format_info.
(check_format_info): Likewise, passing it to format_ctx's ctor.
(check_format_arg): Extract m_comp_types from format_ctx and
pass it to check_format_info_main.
(check_format_info_main): Add "comp_types" param and pass it to
arg_parser's ctor.
(class argument_parser): Add "m_comp_types" field.
(argument_parser::check_argument_type): Pass m_comp_types to
check_format_types.
(handle_subclass_of_pp_element_p): New.
(check_format_types): Add "comp_types" param, and use it to
call handle_subclass_of_pp_element_p.
(class element_format_substring): New.
(class element_expected_type_with_indirection): New.
(format_type_warning): Use element_expected_type_with_indirection
to unify the if (wanted_type_name) branches, reducing from four
emit_warning calls to two. Simplify these further using %e.
Doing so also gives suitable colorization of the text within the
diagnostics.
(init_dynamic_diag_info): Initialize local_pp_element_ptr_node.
(selftest::test_type_mismatch_range_labels): Add nullptr for new
param of gcc_rich_location label overload.
* c-format.h (T_PP_ELEMENT_PTR): New.
* c-type-mismatch.cc: Include "diagnostic-highlight-colors.h".
(binary_op_rich_location::binary_op_rich_location): Use
highlight_colors::lhs and highlight_colors::rhs for the ranges.
* c-type-mismatch.h (class binary_op_rich_location): Add comment
about highlight_colors.
gcc/c/ChangeLog:
* c-objc-common.cc: Include "tree-pretty-print-markup.h".
(print_type): Add optional "highlight_color" param and use it
to show highlight colors in "aka" text.
(pp_markup::element_quoted_type::print_type): New.
* c-typeck.cc: Include "tree-pretty-print-markup.h".
(comp_parm_types): New.
(build_function_call_vec): Pass it to check_function_arguments.
(inform_for_arg): Use %e and highlight colors to contrast actual
versus expected.
(convert_for_assignment): Use highlight_colors::actual for the
rhs_label.
(build_binary_op): Use highlight_colors::lhs and highlight_colors::rhs
for the ranges.
gcc/ChangeLog:
* common.opt (fdiagnostics-show-highlight-colors): New option.
* common.opt.urls: Regenerate.
* coretypes.h (pp_markup::element): New forward decl.
(pp_element): New typedef.
* diagnostic-color.cc (gcc_color_defaults): Add "highlight-a"
and "highlight-b".
* diagnostic-format-json.cc (diagnostic_output_format_init_json):
Disable highlight colors.
* diagnostic-format-sarif.cc (diagnostic_output_format_init_sarif):
Likewise.
* diagnostic-highlight-colors.h: New file.
* diagnostic-path.cc (struct event_range): Pass nullptr for
highlight color of m_rich_loc.
* diagnostic-show-locus.cc (colorizer::set_range): Handle ranges
with m_highlight_color.
(colorizer::STATE_NAMED_COLOR): New.
(colorizer::m_richloc): New field.
(colorizer::colorizer): Add richloc param for initializing
m_richloc.
(colorizer::set_named_color): New.
(colorizer::begin_state): Add case STATE_NAMED_COLOR.
(layout::layout): Pass richloc to m_colorizer's ctor.
(selftest::test_one_liner_labels): Pass nullptr for new param of
gcc_rich_location ctor for labels.
(selftest::test_one_liner_labels_utf8): Likewise.
* diagnostic.h (diagnostic_context::set_show_highlight_colors):
New.
* doc/invoke.texi: Add option -fdiagnostics-show-highlight-colors
and highlight-a and highlight-b color caps.
* doc/ux.texi
(Use color consistently when highlighting mismatches): New
subsection.
* gcc-rich-location.cc (gcc_rich_location::add_expr): Add
"highlight_color" param.
(gcc_rich_location::maybe_add_expr): Likewise.
* gcc-rich-location.h (gcc_rich_location::gcc_rich_location):
Split out into a pair of ctors, where if a range_label is supplied
the caller must also supply a highlight color.
(gcc_rich_location::add_expr): Add "highlight_color" param.
(gcc_rich_location::maybe_add_expr): Likewise.
* gcc.cc (driver_handle_option): Handle
OPT_fdiagnostics_show_highlight_colors.
* lto-wrapper.cc (merge_and_complain): Likewise.
(append_compiler_options): Likewise.
(append_diag_options): Likewise.
(run_gcc): Likewise.
* opts-common.cc (decode_cmdline_options_to_array): Add comment
about -fno-diagnostics-show-highlight-colors.
* opts-global.cc (init_options_once): Preserve
pp_show_highlight_colors in case the global_dc's printer is
recreated.
* opts.cc (common_handle_option): Handle
OPT_fdiagnostics_show_highlight_colors.
(gen_command_line_string): Likewise.
* pretty-print-markup.h: New file.
* pretty-print.cc: Include "pretty-print-markup.h" and
"diagnostic-highlight-colors.h".
(pretty_printer::format): Handle %e.
(pretty_printer::pretty_printer): Handle new field
m_show_highlight_colors.
(pp_string_n): New.
(pp_markup::context::begin_quote): New.
(pp_markup::context::end_quote): New.
(pp_markup::context::begin_color): New.
(pp_markup::context::end_color): New.
(highlight_colors::expected): New.
(highlight_colors::actual): New.
(highlight_colors::lhs): New.
(highlight_colors::rhs): New.
(class selftest::test_element): New.
(selftest::test_pp_format): Add tests of %e.
(selftest::test_urlification): Likewise.
* pretty-print.h (pp_markup::context): New forward decl.
(class chunk_info): Add friend class pp_markup::context.
(class pretty_printer): Add friend pp_show_highlight_colors.
(pretty_printer::m_show_highlight_colors): New field.
(pp_show_highlight_colors): New inline function.
(pp_string_n): New decl.
* substring-locations.cc: Include "diagnostic-highlight-colors.h".
(format_string_diagnostic_t::highlight_color_format_string): New.
(format_string_diagnostic_t::highlight_color_param): New.
(format_string_diagnostic_t::emit_warning_n_va): Use highlight
colors.
* substring-locations.h
(format_string_diagnostic_t::highlight_color_format_string): New.
(format_string_diagnostic_t::highlight_color_param): New.
* toplev.cc (general_init): Initialize global_dc's
show_highlight_colors.
* tree-pretty-print-markup.h: New file.
gcc/cp/ChangeLog:
* call.cc: Include "tree-pretty-print-markup.h".
(implicit_conversion_error): Use highlight_colors::percent_h for
the labelled range.
(op_error_string): Split out into...
(concat_op_error_string): ...this.
(binop_error_string): New.
(op_error): Use %e, binop_error_string, highlight_colors::lhs,
and highlight_colors::rhs.
(maybe_inform_about_fndecl_for_bogus_argument_init): Add
"highlight_color" param; use it for the richloc.
(convert_like_internal): Use highlight_colors::percent_h for the
labelled_range, and highlight_colors::percent_i for the call to
maybe_inform_about_fndecl_for_bogus_argument_init.
(build_over_call): Pass cp_comp_parm_types for new "comp_types"
param of check_function_arguments.
(complain_about_bad_argument): Use highlight_colors::percent_h for
the labelled_range, and highlight_colors::percent_i for the call
to maybe_inform_about_fndecl_for_bogus_argument_init.
* cp-tree.h (maybe_inform_about_fndecl_for_bogus_argument_init):
Add optional highlight_color param.
(cp_comp_parm_types): New decl.
(highlight_colors::const percent_h): New decl.
(highlight_colors::const percent_i): New decl.
* error.cc: Include "tree-pretty-print-markup.h".
(highlight_colors::const percent_h): New defn.
(highlight_colors::const percent_i): New defn.
(type_to_string): Add param "highlight_color" and use it.
(print_nonequal_arg): Likewise.
(print_template_differences): Add params "highlight_color_a" and
"highlight_color_b".
(type_to_string_with_compare): Add params "this_highlight_color"
and "peer_highlight_color".
(print_template_tree_comparison): Add params "highlight_color_a"
and "highlight_color_b".
(cxx_format_postprocessor::handle):
Use highlight_colors::percent_h and highlight_colors::percent_i.
(pp_markup::element_quoted_type::print_type): New.
(range_label_for_type_mismatch::get_text): Pass nullptr for new
params of type_to_string_with_compare.
* typeck.cc (cp_comp_parm_types): New.
(cp_build_function_call_vec): Pass it to check_function_arguments.
(convert_for_assignment): Use highlight_colors::percent_h for the
labelled_range.
gcc/testsuite/ChangeLog:
* g++.dg/diagnostic/bad-binary-ops-highlight-colors.C: New test.
* g++.dg/diagnostic/bad-binary-ops-no-highlight-colors.C: New test.
* g++.dg/plugin/plugin.exp (plugin_test_list): Add
show-template-tree-color-no-highlight-colors.C to
show_template_tree_color_plugin.c.
* g++.dg/plugin/show-template-tree-color-labels.C: Update expected
output to reflect use of highlight-a and highlight-b to contrast
mismatches.
* g++.dg/plugin/show-template-tree-color-no-elide-type.C:
Likewise.
* g++.dg/plugin/show-template-tree-color-no-highlight-colors.C:
New test.
* g++.dg/plugin/show-template-tree-color.C: Update expected output
to reflect use of highlight-a and highlight-b to contrast
mismatches.
* g++.dg/warn/Wformat-gcc_diag-1.C: New test.
* g++.dg/warn/Wformat-gcc_diag-2.C: New test.
* g++.dg/warn/Wformat-gcc_diag-3.C: New test.
* gcc.dg/bad-binary-ops-highlight-colors.c: New test.
* gcc.dg/format/colors.c: New test.
* gcc.dg/plugin/diagnostic_plugin_show_trees.c (show_tree): Pass
nullptr for new param of gcc_rich_location::add_expr.
libcpp/ChangeLog:
* include/rich-location.h (location_range::m_highlight_color): New
field.
(rich_location::rich_location): Add optional label_highlight_color
param.
(rich_location::set_highlight_color): New decl.
(rich_location::add_range): Add optional label_highlight_color
param.
(rich_location::set_range): Likewise.
* line-map.cc (rich_location::rich_location): Add
"label_highlight_color" param and pass it to add_range.
(rich_location::set_highlight_color): New.
(rich_location::add_range): Add "label_highlight_color" param.
(rich_location::set_range): Add "highlight_color" param.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
The following adjusts mask recording which didn't take into account
that we can merge call arguments from two vectors like
_50 = {vect_d_1.253_41, vect_d_1.254_43};
_51 = VIEW_CONVERT_EXPR<unsigned char>(mask__19.257_49);
_52 = (unsigned int) _51;
_53 = _Z3bazd.simdclone.7 (_50, _52);
_54 = BIT_FIELD_REF <_53, 256, 0>;
_55 = BIT_FIELD_REF <_53, 256, 256>;
The testcase g++.dg/vect/pr68762-2.cc exercises this on x86_64 with
partial vector usage enabled and AVX512 support.
PR tree-optimization/115868
* tree-vect-stmts.cc (vectorizable_simd_clone_call): Correctly
compute the number of mask copies required for vect_record_loop_mask.
David Binderman did a bootstrap build with ubsan enabled which triggered a few
errors in the new ext-dce.cc code. This fixes the trivial case of shifting
negative values.
Bootstrapped and regression tested on x86.
Pushing to the trunk.
gcc/
PR rtl-optimization/115876
* ext-dce.cc (carry_backpropagate): Make mask and mmask unsigned.
We're getting complaints from the CI system about this removed option.
I suspect I should have removed the @opindex and @itemx for it. This
patch does that.
gcc/ChangeLog:
* doc/invoke.texi: Remove @opindex and @itemx for -fconcepts-ts.
As of Xcode 16 beta 2 with the macOS 15 SDK, each re-inclusion of the
stddef.h header causes the NULL macro in C++ to be re-defined to an
integral constant (__null). This makes the workaround in d59a576b8
("Redefine NULL to nullptr") ineffective, as other headers that are
typically included after system.h (such as obstack.h) do include
stddef.h too.
This can be seen by running the sample below through `clang++ -E`
#include <stddef.h>
#define NULL nullptr
#include <stddef.h>
NULL
The relevant libc++ change is here:
2950283ddd
Filed as FB14261859 to Apple and added a comment about it on LLVM PR
86843.
This fixes the cases in --enable-languages=c,c++,objc,obj-c++,rust build
where NULL being an integral constant instead of a null pointer literal
(therefore no longer implicitly converting to a pointer when used as a
template function's argument) caused issues.
gcc/value-pointer-equiv.cc:65:43: error: no viable conversion from `pair<typename __unwrap_ref_decay<long>::type, typename __unwrap_ref_decay<long>::type>' to 'const pair<tree, tree>'
65 | const std::pair <tree, tree> m_marker = std::make_pair (NULL, NULL);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
As noted in the previous commit though, the proper solution would be to
phase out the usages of NULL in GCC's C++ source code.
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (saved_diagnostic::saved_diagnostic):
Change NULL to nullptr.
(struct null_assignment_sm_context): Likewise.
* infinite-loop.cc: Likewise.
* infinite-recursion.cc: Likewise.
* varargs.cc (va_list_state_machine::on_leak): Likewise.
gcc/rust/ChangeLog:
* metadata/rust-imports.cc (Import::try_package_in_directory):
Change NULL to nullptr.
gcc/ChangeLog:
* value-pointer-equiv.cc: Change NULL to nullptr.
Signed-off-by: Daniel Bertalan <dani@danielbertalan.dev>
Bit of a brown paper bag issue, but: due to the representation
of the insn chain, insn_info::prev_any_insn would sometimes skip
over instructions. This led to an invalid update in the PR when
adding and removing instructions.
I think one of the reasons I failed to spot this when checking
the code is that m_prev_insn_or_last_debug_insn is misnamed:
it's the previous instruction *of the same type* or the last
debug instruction in a group. The patch therefore renames it to
m_prev_sametype_or_last_debug_insn (with the term prev_sametype
already being used in some accessors).
The reason this didn't show up earlier is that (a) prev_any_insn
is rarely used directly, (b) no instructions were lost from the
def-use chains, and (c) only consecutive debug instructions were
skipped when walking the insn chain.
The chaining scheme makes prev_any_insn more complicated than
next_any_insn, prev_nondebug_insn and next_nondebug_insn, but the
object code produced is still relatively simple.
gcc/
PR rtl-optimization/115785
* rtl-ssa/insns.h (insn_info::prev_insn_or_last_debug_insn)
(insn_info::next_nondebug_or_debug_insn): Remove typedefs.
(insn_info::m_prev_insn_or_last_debug_insn): Rename to...
(insn_info::m_prev_sametype_or_last_debug_insn): ...this.
* rtl-ssa/internals.inl (insn_info::insn_info): Update after
above renaming.
(insn_info::copy_prev_from): Likewise.
(insn_info::set_prev_sametype_insn): Likewise.
(insn_info::set_last_debug_insn): Likewise.
(insn_info::clear_insn_links): Likewise.
(insn_info::has_insn_links): Likewise.
* rtl-ssa/member-fns.inl (insn_info::prev_nondebug_insn): Likewise.
(insn_info::prev_any_insn): Fix moves from non-debug to debug insns.
gcc/testsuite/
PR rtl-optimization/115785
* g++.dg/torture/pr115785.C: New test.
This patch fixes the include of headers (<string> and <vector>) which
are included after GCC's system.h has been included. It defines
INCLUDE_STRING before including "system.h". This allows gcc to
bootstrap with Apple clang 15.
gcc/m2/ChangeLog:
* gm2-gcc/m2linemap.cc (INCLUDE_STRING): Define before
include of gcc-consolidation.h.
* gm2spec.cc (INCLUDE_STRING): Define before include of
system.h.
(INCLUDE_VECTOR): Ditto.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
Similar to the str[n]cmp work, this adjusts the block compare expansion to do
its work in X mode with an appropriate lowpart extraction of the results at the
end of the sequence.
This has gone through my tester on rv32 and rv64, but that's it. Waiting on
pre-commit testing before moving forward.
gcc/
* config/riscv/riscv-string.cc (emit_memcmp_scalar_load_and_compare):
Set RESULT directly rather than using a temporary.
(emit_memcmp_scalar_result_calculation): Similarly.
(riscv_expand_block_compare_scalar): Use CONST0_RTX rather than
generating new RTL.
* config/riscv/riscv.md (cmpmemsi): Pass an X mode temporary to the
expansion routines. If necessary extract low part of the word to store
in final result location.
This issue was fixed by r15-2003-gd6bf4b1c932211, but seems worth adding
to the testsuite.
PR c++/115798
gcc/testsuite/ChangeLog:
* g++.dg/modules/using-26_a.C: New test.
* g++.dg/modules/using-26_b.C: New test.
* g++.dg/modules/using-26_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
This fixes an ICE exposed by supporting exported non-function
using-decls. Sometimes when preparing to define a class, xref_tag will
find a using-decl belonging to a different namespace, which triggers the
checking_assert in modules handling.
Ideally I feel that 'lookup_and_check_tag' should be told whether we're
about to define the type and handle erroring on redefinitions itself to
avoid this issue (and provide better diagnostics by acknowledging the
using-declaration), but this is complicated with the current
fragmentation of definition checking. So for this patch we just fixup
the assertion and ensure that pushdecl properly errors on the
conflicting declaration later.
gcc/cp/ChangeLog:
* decl.cc (xref_tag): Move assertion into condition.
* name-lookup.cc (check_module_override): Check for conflicting
types and using-decls.
gcc/testsuite/ChangeLog:
* g++.dg/modules/using-19_a.C: New test.
* g++.dg/modules/using-19_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
With modules, a non-function using-declaration is not completely
interchangable with the declaration that it refers to; in particular,
such a using-declaration may be exported without revealing the name of
the entity it refers to.
This patch fixes this by building USING_DECLs for all using-declarations
that bind a non-function from a different scope. These new decls can
than have purviewness and exportingness attached to them without
affecting the decl that they refer to.
We do this for all such usings, not just usings that may be revealed in
a module; this way we can verify the change in representation against
the (more comprehensive) non-modules testsuites, and in a future patch
we can use the locations of these using-decls to enhance relevant
diagnostics.
Another possible approach would be to reuse OVERLOADs for this, as is
already done within add_binding_entity for modules. I didn't do this
because lots of code (as well as the names of the accessors) makes
assumptions that OVERLOADs refer to function overload sets, and so
splitting this up reduced semantic burden and made it easier to avoid
unintentional changes. This did mean that we need to move out the
definitions of ovl_iterator::{purview,exporting}_p, because the
structures for module decls are declared later on in cp-tree.h.
Building USING_DECLs changed a couple of code paths when adjusting
bindings; in particular, pushdecl recognises global using-declarations
as usings now, and so checks fall through to update_binding. To not
regress g++.dg/lookup/linkage2.C the checks for 'extern' declarations no
longer were sufficient (they don't handle 'extern "C"'); but
duplicate_decls performed all the relevant checks anyway.
Otherwise in general we strip using-decls from all lookup_* functions
where necessary. Over time for diagnostics purposes it would probably
be good to slowly revert this (especially e.g. lookup_elaborated_type
causes some diagnostic quality regressions here) but this patch doesn't
do so to minimise churn.
This patch also tries not to build USING_DECLs when just redeclaring an
existing declaration, and instead reveals that declaration in-place.
This requires reworking some logic handling CONST_DECLs in module
streaming, since a non-using CONST_DECL may now be exported indepenently
of its containing enum.
'add_binding_entity' needs to explicitly write the names of unscoped
enumerators so that lazy loading will trigger when the name is found by
name lookup; it does this by pretending that the enum declarations are
always usings so that it doesn't double-write definitions. By also
checking if the enumerator was marked purview/exported we can use that
to override a non-purview/non-exported TYPE_DECL and ensure it's made
visible regardless.
When reading we should get the exported flag on the enumeration
constant, and so should properly create a binding for it. We don't need
to do anything to handle importedness as that checking is skipped for
EK_USINGs.
Some other places assume that module information for a CONST_DECL
inherits module information from its containing type. This includes:
- get_originating_module_decl, for determining if the name was imported
or has module attachment; I don't /think/ this change should affect
that, so I'm leaving this untouched.
- binding_cmp, for sorting by exportedness; since now an enumerator
could be exported without the containing decl being exported, we need
to handle this here too.
PR c++/114683
gcc/cp/ChangeLog:
* cp-tree.h (class ovl_iterator): Move definitions of purview_p
and exporting_p to name-lookup.cc.
* module.cc (depset:#️⃣:add_binding_entity): Strip
using-decls. Remove workarounds. Handle CONST_DECLs with
different purview/exported from their enum.
(enum ct_bind_flags): Remove unnecessary cbf_wrapped flag.
(module_state::write_cluster): Likewise.
(module_state::read_cluster): Build USING_DECL for non-function
usings.
(binding_cmp): Handle CONST_DECLs with different purview and/or
exported from their enum.
(set_instantiating_module): Support CONST_DECLs.
* name-lookup.cc (get_fixed_binding_slot): Strip USING_DECLs.
(name_lookup::process_binding): Strip USING_DECLs.
(name_lookup::process_module_binding): Remove workaround.
(update_binding): Strip USING_DECLs, remove incorrect check for
non-extern variables.
(ovl_iterator::purview_p): Support USING_DECLs.
(ovl_iterator::exporting_p): Support USING_DECLs.
(walk_module_binding): Handle stat hack type.
(do_nonmember_using_decl): Strip USING_DECLs when comparing;
build USING_DECLs for non-function usings in different scope
rather than binding directly.
(get_namespace_binding): Strip USING_DECLs.
(lookup_name): Strip USING_DECLs.
(lookup_elaborated_type): Strip USING_DECLs.
* decl.cc (poplevel): Still support -Wunused for using-decls.
(lookup_and_check_tag): Remove unnecessary strip_using_decl.
* parser.cc (cp_parser_template_name): Likewise.
(cp_parser_nonclass_name): Likewise.
(cp_parser_class_name): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/lookup/using29.C: Update errors.
* g++.dg/lookup/using53.C: Update errors, add XFAILs.
* g++.dg/modules/using-22_b.C: Remove xfails.
* g++.dg/warn/Wunused-var-18.C: Update error, add check.
* g++.dg/lookup/using68.C: New test.
* g++.dg/modules/using-24_a.C: New test.
* g++.dg/modules/using-24_b.C: New test.
* g++.dg/modules/using-25_a.C: New test.
* g++.dg/modules/using-25_b.C: New test.
* g++.dg/modules/using-enum-4_a.C: New test.
* g++.dg/modules/using-enum-4_b.C: New test.
* g++.dg/modules/using-enum-4_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jason Merrill <jason@redhat.com>
Currently instructions vgm and vrepi are utilized only for constant
vectors where the element mode equals the element mode of the
corresponding instruction. This patch lifts this restriction by making
use of those instructions for constant vectors even if element modes
do not coincide. For example, the constant vector
(v2di){0x7ffffffe7ffffffe, 0x7ffffffe7ffffffe}
can be loaded via vgmf %v0,1,30. Similar, the constant vector
(v4si){0xaaaaaaaa, 0xaaaaaaaa, 0xaaaaaaaa, 0xaaaaaaaa}
can be loaded via vrepiq %v0,-86.
Analog, if the element mode of a constant vector is smaller than the
element mode of a corresponding instruction, we still may make use of
those instructions. For example, the constant vector
(v4si){0x7fff, 0xfffe0000, 0x7fff, 0xfffe0000}
can be loaded via vgmg %v0,17,46. Similar, the constant vector
(v4si){-1, -16643, -1, -16643}
can be loaded via vrepig %v0,-16643.
Additionally this patch enables vgm, vgbm, vrepi for partial vectors,
i.e., vectors of size less than 16 bytes. Basically this is done by
treating a vector as a full vector resulting in replicating constants
into the ignored bits whereas vgbm sets those to zero.
Furthermore, there is no restriction to integer vectors anymore, i.e.,
supporting scalars of mode up to and including TI and TF and also
floating-point vectors.
Here are some numbers how often instructions are emitted for SPEC 2017:
w/o patch w/ patch
vgbm 140 365
vgm 17508 24452
vrepi 1360 2775
I expect most (maybe even all) to save us a load from the literal pool.
gcc/ChangeLog:
* config/s390/2964.md: Remove extended mnemonics for vgm.
* config/s390/3906.md: Remove extended mnemonics for vgm.
* config/s390/3931.md: Remove extended mnemonics for vgm.
* config/s390/8561.md: Remove extended mnemonics for vgm.
* config/s390/constraints.md (jKK): Remove constraint.
(jzz): Add constraint.
* config/s390/s390-protos.h (s390_contiguous_bitmask_vector_p):
Add prototype.
(s390_constant_via_vgm_p): Add prototype.
(s390_constant_via_vrepi_p): Add prototype.
* config/s390/s390.cc (s390_contiguous_bitmask_vector_p): New
function.
(s390_constant_via_vgm_vrepi_helper): New function.
(s390_constant_via_vgm_p): New function.
(s390_constant_via_vgbm_p): For the sake of symmetry rename
s390_bytemask_vector_p into s390_constant_via_vgbm_p.
(s390_bytemask_vector_p): Deal with non-integer and partial
vectors.
(s390_constant_via_vrepi_p): New function.
(s390_legitimate_constant_p): Allow partial vectors.
(legitimate_reload_constant_p): Fix indentation.
(legitimate_reload_vector_constant_p): Restrict to constraints
j00, jm1, jxx, jyy, jzz only, i.e., allow partial vectors.
(s390_expand_vec_init): Also make use of vrepi if possible.
(print_operand): Add q,p,r for vgm,vrepi,vgbm, respectively.
Remove e,s,t for constant vectors.
* config/s390/s390.md (movti): Add variants utilizing
vgbm,vgm,vrepi.
* config/s390/vector.md (mov<mode><tf_vr>): Adapt variants
for vgbm,vgm,vrepi for the new scheme.
(mov<mode>): Adapt variants for vgbm,vgm for the new
scheme and add vrepi variant for modes V_8,V_16,V_32,V_64.
gcc/testsuite/ChangeLog:
* gcc.target/s390/vector/vec-copysign.c: Change to non-extended
mnemonic.
* gcc.target/s390/vector/vec-genmask-1.c: Change to non-extended
mnemonic.
* gcc.target/s390/vector/vec-init-1.c: Change to non-extended
mnemonic.
* gcc.target/s390/vector/vec-vrepi-1.c: Change to non-extended
mnemonic.
* gcc.target/s390/zvector/autovec-double-quiet-uneq.c: Change to
non-extended mnemonic.
* gcc.target/s390/zvector/autovec-float-quiet-uneq.c: Change to
non-extended mnemonic.
* gcc.target/s390/zvector/vec-genmask-1.c: Change to
non-extended mnemonic.
* gcc.target/s390/zvector/vec-splat-1.c: Change to non-extended
mnemonic.
* gcc.target/s390/zvector/vec-splat-2.c: Change to non-extended
mnemonic.
* gcc.target/s390/vector/vgbm-double-1.c: New test.
* gcc.target/s390/vector/vgbm-float-1.c: New test.
* gcc.target/s390/vector/vgbm-int128-1.c: New test.
* gcc.target/s390/vector/vgbm-integer-1.c: New test.
* gcc.target/s390/vector/vgbm-longdouble-1.c: New test.
* gcc.target/s390/vector/vgm-df-1.c: New test.
* gcc.target/s390/vector/vgm-di-1.c: New test.
* gcc.target/s390/vector/vgm-hi-1.c: New test.
* gcc.target/s390/vector/vgm-int128-1.c: New test.
* gcc.target/s390/vector/vgm-longdouble-1.c: New test.
* gcc.target/s390/vector/vgm-qi-1.c: New test.
* gcc.target/s390/vector/vgm-sf-1.c: New test.
* gcc.target/s390/vector/vgm-si-1.c: New test.
* gcc.target/s390/vector/vgm-tf-1.c: New test.
* gcc.target/s390/vector/vgm-ti-1.c: New test.
* gcc.target/s390/vector/vrepi-df-1.c: New test.
* gcc.target/s390/vector/vrepi-di-1.c: New test.
* gcc.target/s390/vector/vrepi-hi-1.c: New test.
* gcc.target/s390/vector/vrepi-int128-1.c: New test.
* gcc.target/s390/vector/vrepi-qi-1.c: New test.
* gcc.target/s390/vector/vrepi-sf-1.c: New test.
* gcc.target/s390/vector/vrepi-si-1.c: New test.
* gcc.target/s390/vector/vrepi-tf-1.c: New test.
* gcc.target/s390/vector/vrepi-ti-1.c: New test.
Although for instructions MVI and MVIY it does not make a difference
whether the immediate is interpreted as signed or unsigned, GAS expects
unsigned immediates for instruction format SI_URD.
gcc/ChangeLog:
* config/s390/vector.md (mov<mode>): Fix output template for
movv1qi.
This patch replaces the calls to force_reg in ix86_expand_ternlog_binop
and ix86_expand_ternlog with gen_reg_rtx and emit_move_insn.
This patch also cleans up whitespace, consistently uses CONST_VECTOR_P
instead of GET_CODE and tweaks checks for ix86_ternlog_leaf_p (for
example where vpandn may take a memory operand).
2024-07-12 Roger Sayle <roger@nextmovesoftware.com>
Hongtao Liu <hongtao.liu@intel.com>
gcc/ChangeLog
* config/i386/i386-expand.cc (ix86_broadcast_from_constant):
Use CONST_VECTOR_P instead of comparison against GET_CODE.
(ix86_gen_bcst_mem): Likewise.
(ix86_ternlog_leaf_p): Likewise.
(ix86_ternlog_operand_p): ix86_ternlog_leaf_p is always true for
vector_all_ones_operand.
(ix86_expand_ternlog_bin_op): Use CONST_VECTOR_P instead of
equality comparison against GET_CODE. Replace call to force_reg
with gen_reg_rtx and emit_move_insn (for VEC_DUPLICATE broadcast).
Check for !register_operand instead of memory_operand.
Support CONST_VECTORs by calling force_const_mem.
(ix86_expand_ternlog): Fix indentation whitespace.
Allow ix86_ternlog_leaf_p as ix86_expand_ternlog_andnot's second
operand. Use CONST_VECTOR_P instead of equality against GET_CODE.
Use gen_reg_rtx and emit_move_insn for ~a, ~b and ~c cases.
The handling of the target attribute used alloca to allocate
a copy of unverified user input, which could exhaust the stack
if the input is too long. This patch converts it to auto_vecs
instead.
I wondered about converting it to use std::string, which we
already use elsewhere, but that would be more invasive and
controversial.
gcc/
* config/aarch64/aarch64.cc (aarch64_process_one_target_attr)
(aarch64_process_target_attr): Avoid alloca.
On a target that doesn't enable decimal float components in libgcc
(because the libc doens't define all required FE_* macros), but whose
compiler supports _Decimal* types, the effective target requirement
dfp passes, but several tests won't link because the runtime support
they depend on is missing. State their dfprt requirement.
for libstdc++-v3/ChangeLog
* testsuite/decimal/binary-arith.cc: Require dfprt.
* testsuite/decimal/comparison.cc: Likewise.
* testsuite/decimal/compound-assignment.cc: Likewise.
* testsuite/decimal/compound-assignment-memfunc.cc: Likewise.
* testsuite/decimal/make-decimal.cc: Likewise.
* testsuite/decimal/pr54036-1.cc: Likewise.
* testsuite/decimal/pr54036-2.cc: Likewise.
* testsuite/decimal/pr54036-3.cc: Likewise.
* testsuite/decimal/unary-arith.cc: Likewise.
Before issuing loads or stores for a block move, adjust the MEM
alignments if analysis of the addresses enabled the inference of
stricter alignment. This ensures that the MEMs are sufficiently
aligned for the corresponding insns, which avoids trouble in case of
e.g. substitutions into SUBREGs.
for gcc/ChangeLog
PR target/115459
* config/alpha/alpha.cc (alpha_expand_block_move): Adjust
MEMs to match inferred alignment.
PR target/115840.
In riscv_preferred_else_value, we create an uninitialized tmp var
for else value, instead of the 0 (as default_preferred_else_value)
or the pre-exists VAR (as aarch64 does), so that we can use agnostic
policy.
The problem is that `warn_uninit` will emit a warning:
'({anonymous})' may be used uninitialized
Let's mark this tmp var as NO_WARNING.
This problem is found when I try to build glibc with V extension.
gcc
PR target/115840
* config/riscv/riscv.cc(riscv_preferred_else_value): Mark
tmp_var as NO_WARNING.
gcc/testsuite
* gcc.dg/vect/pr115840.c: New testcase.
Move the evaluation of the BACK argument out of the loop in the inline code
generated for MINLOC or MAXLOC. For that, add a new (scalar) element
associated with BACK to the scalarization loop chain, evaluate the argument
with the context of that element, and let the scalarizer do its job.
The problem was not only a missed optimisation, but also a wrong code
one in the cases where the expression associated with BACK is not free of
side-effects, making multiple evaluations observable.
The new tests check the evaluation count of the BACK argument, and try to
cover all the variations (integral or floating-point type, constant or
unknown shape, absent or scalar or array MASK) supported by the inline
implementation of the functions. Care has been taken to not check the case
of a constant .FALSE. MASK, for which the evaluation of BACK can be elided.
gcc/fortran/ChangeLog:
* trans-intrinsic.cc (gfc_conv_intrinsic_minmaxloc): Create a new
scalar scalarization chain element if BACK is present. Add it to
the loop. Set the scalarization chain before evaluating the
argument.
gcc/testsuite/ChangeLog:
* gfortran.dg/maxloc_5.f90: New test.
* gfortran.dg/minloc_5.f90: New test.
The reason is that in the following code, icode = movmisalignv8si has
already been rejected by TARGET_VECTOR_MISALIGN_SUPPORTED, but it is
allowed by targetm.slow_unaligned_access,which is contradictory.
(((icode = optab_handler (movmisalign_optab, mode))
!= CODE_FOR_nothing)
|| targetm.slow_unaligned_access (mode, align))
misaligned vector access should be enabled by -mno-vector-strict-align option.
PR target/115862
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_slow_unaligned_access): Disable vector misalign.
Signed-off-by: Li Xu <xuli1@eswincomputing.com>
We have already upstreamed these extensions into binutils, and now we need GCC
to recognize these extensions and pass them to binutils as well. We also plan
to upstream intrinsics in the near future. :)
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_implied_info): Add xsfvcp.
(riscv_ext_version_table): Add xsfvcp, xsfcease.
(riscv_ext_flag_table): Ditto.
* config/riscv/riscv.opt (riscv_sifive_subext): New.
(XSFVCP): New.
(XSFCEASE): New.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/predef-sf-1.c: New.
* gcc.target/riscv/predef-sf-2.c: New.
As PR114189 shows, middle-end will obsolete vcond, vcondu
and vcondeq optabs soon. This patch is to remove all
vcond{,u} expanders in rs6000 port and adjust the function
rs6000_emit_vector_cond_expr which is called by those
expanders as static.
PR target/115659
gcc/ChangeLog:
* config/rs6000/rs6000-protos.h (rs6000_emit_vector_cond_expr): Remove.
* config/rs6000/rs6000.cc (rs6000_emit_vector_cond_expr): Add static
qualifier as it is only called by rs6000_emit_swsqrt now.
* config/rs6000/vector.md (vcond<VEC_F:mode><VEC_F:mode>): Remove.
(vcond<VEC_I:mode><VEC_I:mode>): Remove.
(vcondv4sfv4si): Likewise.
(vcondv4siv4sf): Likewise.
(vcondv2dfv2di): Likewise.
(vcondv2div2df): Likewise.
(vcondu<VEC_I:mode><VEC_I:mode>): Likewise.
(vconduv4sfv4si): Likewise.
(vconduv2dfv2di): Likewise.
When only a loop mask is to be supplied for the inbranch arg to a
simd function we fail to handle integer mode masks correctly. We
need to guess the number of elements represented by it. This assumes
that excess arguments are all for masks, I wasn't able to create
a simdclone with more than one integer mode mask argument.
The gcc.dg/vect/vect-simd-clone-20.c exercises this with -mavx512vl
PR tree-optimization/115867
* tree-vect-stmts.cc (vectorizable_simd_clone_call): Properly
guess the number of mask elements for integer mode masks.
So the m68k port has failed to bootstrap since the introduction of
late-combine. My suspicion has been this is a backend problem. Sure enough
after bisecting things down (thank goodness for the debug counter!) I'm happy
to report m68k (after this patch) has moved into its stage3 build for the first
time in a month.
Basically late-combine propagated an address calculation to its use points,
generating this insn (dwarf2out.c, I forget what function):
> (insn 653 652 655 (parallel [
> (set (mem/j:DI (plus:SI (plus:SI (reg/f:SI 9 %a1 [orig:64 _67 ] [64])
> (reg:SI 0 %d0 [321]))
> (const_int 20 [0x14])) [0 slot_204->dw_attr_val.v.val_unsigned+0 S8 A16])
> (sign_extend:DI (mem/c:SI (plus:SI (reg/f:SI 14 %a6)
> (const_int -28 [0xffffffffffffffe4])) [870 %sfp+-28 S4 A16])))
> (clobber (reg:SI 0 %d0))
> ]) "../../../gcc/gcc/dwarf2out.cc":24961:23 93 {extendsidi2}
> (expr_list:REG_DEAD (reg/f:SI 9 %a1 [orig:64 _67 ] [64])
> (expr_list:REG_DEAD (reg:SI 0 %d0 [321])
> (expr_list:REG_UNUSED (reg:SI 0 %d0)
> (nil)))))
Note how the output uses d0 in the address calculation and the clobber uses d0.
It matches this insn in the md file:
> (define_insn "extendsidi2"
> [(set (match_operand:DI 0 "nonimmediate_operand" "=d,o,o,<")
> (sign_extend:DI
> (match_operand:SI 1 "nonimmediate_src_operand" "rm,rm,r<Q>,rm")))
> (clobber (match_scratch:SI 2 "=X,&d,&d,&d"))]
> ""
> {
> if (which_alternative == 0)
> /* Handle alternative 0. */
> {
> if (TARGET_68020 || TARGET_COLDFIRE)
> return "move%.l %1,%R0\;smi %0\;extb%.l %0";
> else
> return "move%.l %1,%R0\;smi %0\;ext%.w %0\;ext%.l %0";
> }
>
> /* Handle alternatives 1, 2 and 3. We don't need to adjust address by 4
> in alternative 3 because autodecrement will do that for us. */
> operands[3] = adjust_address (operands[0], SImode,
> which_alternative == 3 ? 0 : 4);
> operands[0] = adjust_address (operands[0], SImode, 0);
>
> if (TARGET_68020 || TARGET_COLDFIRE)
> return "move%.l %1,%3\;smi %2\;extb%.l %2\;move%.l %2,%0";
> else
> return "move%.l %1,%3\;smi %2\;ext%.w %2\;ext%.l %2\;move%.l %2,%0";
> }
> [(set_attr "ok_for_coldfire" "yes,no,yes,yes")])
Note the smi/ext instruction pair in the case for alternatives 1..3. Those
clobber the scratch register before we're done consuming inputs. The scratch
register really needs to be marked as an earlyclobber.
That fixes the bootstrap problem, but a cursory review of m68k.md is not
encouraging. I will not be surprised at all if there's more of this kind of
problem lurking.
But happy to at least have m68k bootstrapping again. It's failing the
comparison test, but definitely progress.
* config/m68k/m68k.md (extendsidi2): Add missing early clobbers.
We could get an infinite recursion in an odd case in which a
.gnu_debugdata section was added to a debug file, and mini_debuginfo
was put into the debug file, and the debug file was put into a
/usr/lib/debug directory to be found by build ID. This combination
doesn't really make sense but we shouldn't get an infinite recursion.
* elf.c (elf_add): Don't use .gnu_debugdata if we are already
reading a debuginfo file.
* Makefile.am (m2test_*): New test targets.
(CHECK_PROGRAMS): Add m2test.
(MAKETESTS): Add m2test_minidebug2.
(%_minidebug2): New pattern.
(CLEANFILES): Remove minidebug2 files.
* Makefile.in: Regenerate.
The previous commit changed atomic_ref<bool> to not use the integral
specialization. This adds a test to verify that change. We can't
directly test that the primary template is used, but we can check that
the member functions of the integral specializations are not present.
libstdc++-v3/ChangeLog:
* testsuite/29_atomics/atomic_ref/bool.cc: New test.
Per [atomics.ref.int] `bool` is excluded from the list of integral types
for which there is a specialization of the `atomic_ref` class template
and [Note 1] clearly states that `atomic_ref<bool>` "uses the primary
template" instead.
libstdc++-v3/ChangeLog:
* include/bits/atomic_base.h (__atomic_ref): Do not use integral
specialization for bool.
Signed-off-by: Damien Lebrun-Grandie <dalg24@gmail.com>
This patch eliminates an unnecessary sign extension for scalar inlined
string comparisons on rv64.
Conceptually this is pretty simple. Prove all the paths which "return"
a value from the inlined string comparison already have sign extended
values.
FINAL_LABEL is the point after the calculation of the return value. So
if we have a jump to FINAL_LABEL, we must have a properly extended
result value at that point.
Second we're going to arrange in the .md part of the expander to use an
X mode temporary for the result. After computing the result we will (if
necessary) extract the low part of the result using a SUBREG tagged with
the appropriate SUBREG_PROMOTED_* bits.
So with that background.
We find a jump to FINAL_LABEL in emit_strcmp_scalar_compare_byte. Since
we know the result is X mode, we can just emit the subtraction of the
two chars in X mode and we'll have a properly sign extended result.
There's 4 jumps to final_label in emit_strcmp_scalar.
The first is just returning zero and needs trivial simplification to not
force the result into SImode.
The second is after calling strcmp in the library. The ABI mandates
that value is sign extended, so there's nothing to do for that case.
The 3rd occurs after a call to
emit_strcmp_scalar_result_calculation_nonul. If we dive into that
routine it needs simplificationq similar to what we did in
emit_strcmp_scalar_compare_byte
The 4th occurs after a call to emit_strcmp_scalar_result_calculation
which again needs trivial adjustment like we've done in the other routines.
Finally, at the end of expand_strcmp, just store the X mode result
sitting in SUB to RESULT.
The net of all that is we know every path has its result properly
extended to X mode. Standard redundant extension removal will take care
of the rest.
We've been running this within Ventana for about 6 months, so naturally
it's been through various QA cycles, dhrystone, spec2017, etc. It's
also been through a build/test cycle in my tester. Waiting on results
from the pre-commit testing before moving forward.
gcc/
* config/riscv/riscv-string.cc
(emit_strcmp_scalar_compare_byte): Set RESULT directly rather
than using a new temporary.
(emit_strcmp_scalar_result_calculation_nonul): Likewise.
(emit_strcmp_scalar_result_calculation): Likewise.
(riscv_expand_strcmp_scalar): Use CONST0_RTX rather than
generating a new node.
(expand_strcmp): Copy directly from SUB to RESULT.
* config/riscv/riscv.md (cmpstrnsi, cmpstrsi): Pass an X
mode temporary to the expansion routines. If necessary
extract low part of the word to store in final result location.
I noticed there was a warning from clang about int_range's
dtor being marked as final saying the class cannot be inherited from.
So let's mark the few ranger classes as final for those which we know
will be final.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* value-range.h (class int_range): Mark as final.
(class prange): Likewise.
(class frange): Likewise.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
This test uses -fkeep-inline-functions and with debug mode enabled that
compiles much slower and times out if the system is under heavy load.
The original problem being tested is independent of debug mode, so just
require normal mode for the test.
libstdc++-v3/ChangeLog:
PR libstdc++/108636
* testsuite/27_io/filesystem/path/108636.cc: Require normal
mode.
This patch fixes the backend pattern that was printing the wrong input
scalar register pair when inserting into lane 1.
Added a new test to force float-abi=hard so we can use scan-assembler to check
correct codegen.
gcc/ChangeLog:
PR target/115611
* config/arm/mve.md (mve_vec_setv2di_internal): Fix printing of input
scalar register pair when lane = 1.
gcc/testsuite/ChangeLog:
* gcc.target/arm/mve/intrinsics/vsetq_lane_su64.c: New test.
In this PR, due to the -f flags, we ended up with:
bb1: r10=r10
...
bb2: r10=r10
...
bb3: ...=r10
with bb1->bb2 and bb1->bb3.
late-combine successfully combined the bb1->bb2 def-use and set
the insn code to NOOP_MOVE_INSN_CODE. The bb1->bb3 combination
then failed for... reasons. At this point, everything should have
been rewound to its original state.
However, substituting r10=r10 into r10=r10 gives r10=r10, and
validate_change had an early-out for no-op rtl changes. This meant
that validate_change did not register a change for the bb2 insn and
so did not save its old insn code. The NOOP_MOVE_INSN_CODE therefore
persisted even after the attempt had been rewound.
IMO it'd be too cumbersome and error-prone to expect all users of
validate_change to be aware of this possibility. If code is using
validate_change with in_group=1, I think it has a reasonable expectation
that a change will be registered and that the insn code will be saved
(and restored on cancel). This patch therefore limits the shortcut
to the !in_group case.
gcc/
PR rtl-optimization/115782
* recog.cc (validate_change_1): Suppress early exit for no-op
changes that are part of a group.
gcc/testsuite/
PR rtl-optimization/115782
* gcc.dg/pr115782.c: New test.
The Ada compiler now defers to the gimplifier for ordering comparisons of
arrays of bytes (Ada parlance for <, >, <= and >=) because the gimplifier
in turn defers to memcmp for them, which implements the required semantics.
However, the gimplifier has a special processing for aggregate types whose
mode is not BLKmode and this processing deviates from the memcmp semantics
when the target is little-endian.
gcc/
* gimplify.cc (gimplify_scalar_mode_aggregate_compare): Add support
for ordering comparisons.
(gimplify_expr) <default>: Call gimplify_scalar_mode_aggregate_compare
only for integral scalar modes.
gcc/testsuite/
* gnat.dg/array42.adb, gnat.dg/array42_pkg.ads: New test.
