Unfortunately this led to numerous g++ testsuite failures on Solaris,
tracked as PR analyzer/111475.
Almost all of the failures are due to standard library differences where
including a C standard library on C++ e.g. <stdlib.h> leads to the plain
symbols referencing the symbols "std::" via a "using" declaration,
whereas I had written the code expecting them to use symbols in the root
namespace.
The analyzer has special-case handling of many functions by name.
This patch generalizes such handling to also match against functions
in "std::" for all of the cases I found in the testsuite (via manual
inspection of the preprocessed test cases against Solaris headers).
This fixes cases where the analyzer was failing to "know about" the
behavior of such functions.
Other such failures are due to "std::" prefixes appearing in names of
functions in the output, leading to mismatches against expected output.
The patch adds regexes to some cases, and moves some other cases back
from c-c++-common to gcc.dg where the dg-multiline syntax isn't
expressive enough.
Various "fd-*.c" failures relate to Solaris's socket-handling functions
not being marked with "noexcept", where due to PR analyzer/97111 we
mishandle the exception-handling edges in the CFG, leading to leak
false positives. The patch works around this by adding -fno-exceptions
to these cases, pending a proper fix for PR analyzer/97111.
gcc/analyzer/ChangeLog:
PR analyzer/111475
* analyzer.cc (is_special_named_call_p): Add "look_in_std" param.
(is_std_function_p): Make non-static.
* analyzer.h (is_special_named_call_p): Add optional "look_in_std"
param.
(is_std_function_p): New decl.
* engine.cc (stmt_requires_new_enode_p): Look for both "signal"
and "std::signal".
* kf.cc (register_known_functions): Add various "std::" copies
of the known functions.
* known-function-manager.cc
(known_function_manager::~known_function_manager): Clean up
m_std_ns_map_id_to_kf.
(known_function_manager::add_std_ns): New.
(known_function_manager::get_match): Also look for known "std::"
functions.
(known_function_manager::get_by_identifier_in_std_ns): New.
* known-function-manager.h
(known_function_manager::add_std_ns): New decl.
(known_function_manager::get_by_identifier_in_std_ns): New decl.
(known_function_manager::m_std_ns_map_id_to_kf): New field.
* sm-file.cc (register_known_file_functions): Add various "std::"
copies of the known functions.
* sm-malloc.cc (malloc_state_machine::on_stmt): Handle
"std::realloc".
* sm-signal.cc (signal_unsafe_p): Consider "std::" copies of the
functions as also being async-signal-unsafe.
(signal_state_machine::on_stmt): Consider "std::signal".
gcc/testsuite/ChangeLog:
PR analyzer/111475
* c-c++-common/analyzer/fd-glibc-byte-stream-socket.c: Add
-fno-exceptions for now.
* c-c++-common/analyzer/fd-manpage-getaddrinfo-client.c: Likewise.
* c-c++-common/analyzer/fd-mappage-getaddrinfo-server.c: Rename to...
* c-c++-common/analyzer/fd-manpage-getaddrinfo-server.c: ...this, and
add -fno-exceptions for now.
* c-c++-common/analyzer/fd-socket-meaning.c: Add -fno-exceptions
for now.
* c-c++-common/analyzer/fd-symbolic-socket.c: Likewise.
* c-c++-common/analyzer/flexible-array-member-1.c: Use regexp to
handle C vs C++ differences in spelling of function name, which
could have a "std::" prefix on some targets.
* c-c++-common/analyzer/pr106539.c: Likewise.
* c-c++-common/analyzer/malloc-ipa-8-unchecked.c: Move back to...
* gcc.dg/analyzer/malloc-ipa-8-unchecked.c: ...here, dropping
attempt to generalize output for C vs C++.
* c-c++-common/analyzer/signal-4a.c: Move back to...
* gcc.dg/analyzer/signal-4a.c: ...here, dropping attempt to
generalize output for C vs C++.
* c-c++-common/analyzer/signal-4b.c: Move back to...
* gcc.dg/analyzer/signal-4b.c: ...here, dropping attempt to
generalize output for C vs C++.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Richard Biener [Fri, 3 May 2024 09:48:07 +0000 (11:48 +0200)]
Avoid changing type in the type_hash_canon hash
When building a type and type_hash_canon returns an existing type
avoid changing it, in particular its TYPE_CANONICAL.
PR middle-end/114931
* tree.cc (build_array_type_1): Return early when type_hash_canon
returned an older existing type.
(build_function_type): Likewise.
(build_method_type_directly): Likewise.
(build_offset_type): Likewise.
Alex Coplan [Fri, 3 May 2024 08:23:59 +0000 (09:23 +0100)]
cfgrtl: Fix MEM_EXPR update in duplicate_insn_chain [PR114924]
The PR shows that when cfgrtl.cc:duplicate_insn_chain attempts to
update the MR_DEPENDENCE_CLIQUE information for a MEM_EXPR we can end up
accidentally dropping (e.g.) an ARRAY_REF from the MEM_EXPR and end up
replacing it with the underlying MEM_REF. This leads to an
inconsistency in the MEM_EXPR information, and could lead to wrong code.
While the walk down to the MEM_REF is necessary to update
MR_DEPENDENCE_CLIQUE, we should use the outer tree expression for the
MEM_EXPR. This patch does that.
gcc/ChangeLog:
PR rtl-optimization/114924
* cfgrtl.cc (duplicate_insn_chain): When updating MEM_EXPRs,
don't strip (e.g.) ARRAY_REFs from the final MEM_EXPR.
Jakub Jelinek [Fri, 3 May 2024 07:44:30 +0000 (09:44 +0200)]
tree-inline: Add __builtin_stack_{save,restore} pair about inline calls with calls to alloca [PR113596]
The following patch adds save_NNN = __builtin_stack_save (); ...
__builtin_stack_restore (save_NNN);
pair around inline calls which call alloca (alloca calls because of
VLA vars are ignored in that decision).
The patch doesn't change anything on whether we try to inline such calls or
not, it just fixes the behavior when we inline them despite those checks.
The stack save/restore restores the behavior that alloca acquired regions
are freed at the end of the containing call.
2024-05-03 Jakub Jelinek <jakub@redhat.com>
PR middle-end/113596
* tree-inline.cc (expand_call_inline): Emit __builtin_stack_save
and __builtin_stack_restore calls around inlined functions which
call alloca.
* gcc.dg/pr113596.c: New test.
* gcc.dg/tree-ssa/pr113596.c: New test.
The vectorizer handles a _Float16 to __bf16 conversion through
vectorizable_assignment, thinking it's a noop. The following
fixes this by requiring the same vector component mode when
checking for CONVERT_EXPR_CODE_P, being stricter than for
VIEW_CONVERT_EXPR.
PR tree-optimization/114921
* tree-vect-stmts.cc (vectorizable_assignment): Require
same vector component modes for input and output for
CONVERT_EXPR_CODE_P.
Patrick Palka [Fri, 3 May 2024 01:14:30 +0000 (21:14 -0400)]
c++: remove lookup_template_class's entering_scope flag
lookup_template_class's entering_scope flag controls whether to prefer
returning the primary template type A<T> instead of the corresponding
implicit instantiation A<T>. When we want to set this flag as part of
substitution, we need to use tsubst_aggr_type which also takes this flag
as a parameter. But having this separate entry point to type substitution
turned out to be subtly problematic because it doesn't reuse typedefs
like tsubst does, which r13-4729-gbe124477b38a71 fixed in a way that
respects the flag after the fact, by adjusting the entering_scope=false
result of lookup_template_class as if entering_scope=true was passed.
But if that's possible then it means lookup_template_class's
entering_scope flag is not necessary after all -- we can just do the
after-the-fact adjustment everywhere that we currently pass
entering_scope=true to it and tsubst_aggr_type.
To that end, this patch replaces this flag with an adjustment function
adjust_type_for_entering_scope, to be used whereever we currently need
the entering_scope=true behavior. In turn we can get rid of
tsubst_aggr_type since the only reason we needed this entry point
was to be able to pass entering_scope=true to lookup_template_class.
gcc/cp/ChangeLog:
* coroutines.cc (instantiate_coro_traits): Adjust call to
lookup_template_class.
(instantiate_coro_handle_for_promise_type): Likewise.
* cp-tree.h (adjust_type_for_entering_scope): Declare.
(lookup_template_class): Adjust declaration.
* decl.cc (make_typename_type): Adjust call to
lookup_template_class. Likewise.
(get_tuple_size): Likewise.
(get_tuple_element_type): Likewise.
* pt.cc (adjust_type_for_entering_scope): Define.
(tsubst_entering_scope): Define.
(lookup_template_class): Remove entering_scope parameter.
Replace tsubst_aggr_type call with tsubst_entering_scope.
(tsubst_aggr_type): Remove.
(tsubst_aggr_type_1): Inline into tsubst.
(tsubst_function_decl): Replace tsubst_aggr_type call
with tsubst_entering_scope.
(tsubst_template_decl): Likewise.
(tsubst_decl): Likewise.
(tsubst) <case RECORD_TYPE, UNION_TYPE, ENUMERAL_TYPE>:
Inlined from tsubst_aggr_type_1.
<case BOUND_TEMPLATE_TEMPLATE_PARM>: Adjust calls to
lookup_template_class.
<case TYPENAME_TYPE>: Replace tsubst_aggr_type call with
tsubst_entering_scope.
<case UNBOUND_CLASS_TEMPLATE>: Likewise.
Increment processing_template_decl when substituting the
context.
(tsubst_expr) <case FIELD_DECL>: Replace tsubst_aggr_type
call with tsubst_entering_scope.
<case TEMPLATE_DECL>: Likewise.
(instantiate_template): Likewise.
(resolve_typename_type): Adjust lookup_template_class call
and call adjust_type_for_entering_scope afterward.
(listify): Adjust lookup_template_class call.
(alias_ctad_tweaks): Likewise.
* semantics.cc (finish_template_type): Adjust lookup_template_class
call and maybe call adjust_type_for_entering_scope afterward.
Gaius Mulley [Fri, 3 May 2024 00:22:10 +0000 (01:22 +0100)]
PR modula2/114929 for loop fails to iterate down to zero when using a cardinal type
There is a bug in the for loop control code which is exposed when an
unsigned type is used in the iterator variable. See
gm2/pim/run/pass/testforloopzero[234].mod. The bug is in the
calculation of the last iterator value. The bug fix is to avoid using
negative expressions when calculating the last iterator value with a
negative step value. This patch detects if e1, e2, step value are all
constant, in which case the ztype is used internally and there is no
overflow. If the last iterator value is held in a variable then it
uses a different method to calculate the last iterator depending upon
the sign of the step value.
gcc/m2/ChangeLog:
PR modula2/114929
* gm2-compiler/M2LangDump.mod (GenQualidentSymString): Add
missing return result into identstr.
* gm2-compiler/M2Quads.mod (ForLoopLastIteratorVariable): New
procedure.
(ForLoopLastIteratorConstant): Ditto.
(ForLoopLastIterator): Ditto.
(BuildForToByDo): Remove LastIterator calculation and call
ForLoopLastIterator instead.
(FinalValue): Replace with ...
(LastIterator): ... this.
gcc/testsuite/ChangeLog:
PR modula2/114929
* gm2/pim/run/pass/testforloopzero.mod: New test.
* gm2/pim/run/pass/testforloopzero2.mod: New test.
* gm2/pim/run/pass/testforloopzero3.mod: New test.
* gm2/pim/run/pass/testforloopzero4.mod: New test.
Jeff Law [Thu, 2 May 2024 23:13:12 +0000 (17:13 -0600)]
[committed][RISC-V] Fix nearbyint failure on rv32 and formatting nits
The CI system tripped an execution failure for rv32 with the ceil/round patch.
The fundamental problem is the FP->INT step in these sequences requires the
input size to match the output size. The output size was based on rv32/rv64.
Meaning that we'd try to do DF->SI->DF.
That doesn't preserve the semantics we want in at least two ways.
The net is we can't use this trick for DF values on rv32. While inside the
code I realized we had a similar problem for HF modes. HF modes we can support
only for Zfa. So I fixed that proactively.
The CI system also pointed out various formatting nits. I think this fixes all
but one overly long line.
Note I could have factored the TARGET_ZFA test. But I think as-written it's
clearer what the desired cases to transform are.
gcc/
* config/riscv/riscv.md (<round_pattern><ANYF:mode>2): Adjust
condition to match what can be properly implemented. Fix various
formatting issues.
(l<round_pattern><ANYF:mode>si2_sext): Fix formatting
Jeff Law [Thu, 2 May 2024 20:06:22 +0000 (14:06 -0600)]
[RFA][RISC-V] Improve constant synthesis for constants with 2 bits set
In doing some preparation work for using zbkb's pack instructions for constant
synthesis I figured it would be wise to get a sense of how well our constant
synthesis is actually working and address any clear issues.
So the first glaring inefficiency is in our handling of constants with a small
number of bits set. Let's start with just two bits set. There are 2016
distinct constants in that space (rv64). With Zbs enabled the absolute worst
we should ever do is two instructions (bseti+bseti). Yet we have 503 cases
where we're generating 3+ instructions when there's just two bits set in the
constant. A constant like 0x8000000000001000 generates 4 instructions!
This patch adds bseti (and indirectly binvi if we needed it) as a first class
citizen for constant synthesis. There's two components to this change.
First, we can't generate an IOR with a constant like (1 << 45) as an operand.
The IOR/XOR define_insn is in riscv.md. The constant argument for those
patterns must match an arith_operand which means its not really usable for
generating bseti directly in the cases we care about (at least one of the bits
will be in the 32..63 range and thus won't match arith_operand).
We have a few things we could do. One would be to extend the existing pattern
to incorporate bseti cases. But I suspect folks like the separation of the
base architecture (riscv.md) from the Zb* extensions (bitmanip.md). We could
also try to generate the RTL for bseti
directly, bypassing gen_fmt_ee (which forces undesirable constants into registers based on the predicate of the appropriate define_insn). Neither of these seemed particularly appealing to me.
So what I've done instead is to make ior/xor a define_expand and have the
expander allow a wider set of constant operands when Zbs is enabled. That
allows us to keep the bulk of Zb* support inside bitmanip.md and continue to
use gen_fmt_ee in the constant synthesis paths.
Note the code generation in this case is designed to first set as many bits as
we can with lui, then with addi since those can both set multiple bits at a
time. If there are any residual bits left to set we can emit bseti
instructions up to the current cost ceiling.
This results in fixing all of the 503 2-bit set cases where we emitted too many
instructions. It also significantly helps other scenarios with more bits set.
The testcase I'm including verifies the number of instructions we generate for
the full set of 2016 possible cases. Obviously this won't be possible as we
increase the number of bits (there are something like 48k cases with just 3
bits set).
gcc/
* config/riscv/predicates.md (arith_or_zbs_operand): New predicate.
* config/riscv/riscv.cc (riscv_build_integer_one): Use bseti to set
single bits when profitable.
* config/riscv/riscv.md (*<optab><mode>3): Renamed with '*' prefix.
(<optab><mode>3): New expander for IOR/XOR.
gcc/testsuite
* gcc.target/riscv/synthesis-1.c: New test.
Jeff Law [Thu, 2 May 2024 14:42:32 +0000 (08:42 -0600)]
[committed] [RISC-V] Don't run new rounding tests on newlib risc-v targets
The new round_32.c and round_64.c tests depend on the optimizers to recognize
the conversions feeding the floor/ceil calls and convert them into ceilf,
floorf and the like.
Those transformations only occur when the target indicates the C library has
the appropriate routines (fnclass == function_c99_misc). While newlib has
these routines, they are not exposed as available to the compiler and thus the
transformation the tests depend on do not happen. Naturally the scan-tests then
fail.
Nathaniel Shead [Thu, 2 May 2024 02:55:24 +0000 (12:55 +1000)]
c++: Clear is_unbraced_* when parsing declaration_seq_opt [PR114917]
Currently we incorrectly retain "in_unbraced_linkage_specification_p"
and "in_unbraced_export_declaration_p" when parsing a (braced)
declaration-seq. This patch ensures that we clear these flags before
parsing the toplevel declarations.
Strictly speaking we don't need to save and restore the flags around the
parsing because there's currently no way to provide new declarations
within the unbraced context after the closing brace, but this patch does
it anyway in case this ever changes and for consistency with other
places that these flags are adjusted.
PR c++/114917
gcc/cp/ChangeLog:
* parser.cc (cp_parser_declaration_seq_opt): Clear
parser->in_unbraced_* flags when parsing toplevel declarations.
gcc/testsuite/ChangeLog:
* g++.dg/modules/export-5_a.C: New test.
* g++.dg/modules/export-5_b.C: New test.
* g++.dg/parse/linkage4.C: New test.
Objective-C, NeXT, v2: Correct a regression in code-gen.
There have been several changes in the ABI of Objective-C which
depend on the OS version targetted. In this case Protocols and
LabelProtocols should be made weak/hidden/extern from macOS 10.7
however there was a mistake in the code causing this to occur
from macOS 10.6. Fixed thus.
gcc/objc/ChangeLog:
* objc-next-runtime-abi-02.cc (WEAK_PROTOCOLS_AFTER): New.
(next_runtime_abi_02_protocol_decl): Use WEAK_PROTOCOLS_AFTER
to determine this ABI change.
(build_v2_protocol_list_address_table): Likewise.
Gaius Mulley [Thu, 2 May 2024 12:16:07 +0000 (13:16 +0100)]
PR modula2/113836 gm2 does not dump gimple or quadruples to a file
This patch completes the implementation of dumping the intermediate forms
to file. It implements the filtering on symbol rules. Filtering can be
performed through the full text name (given to the GCC tree) or qualified
modula-2 symbol or filename:qualident.
Peter Damianov [Sun, 28 Apr 2024 23:16:12 +0000 (16:16 -0700)]
lto-wrapper: Truncate files using -truncate driver option [PR110710]
This commit changes the Makefiles generated by lto-wrapper to no longer use
the "mv" and "touch" shell commands. These don't exist on Windows, so when the
Makefile attempts to call them, it results in errors like:
The system cannot find the file specified.
This problem only manifested when calling gcc from cmd.exe, and having no
sh.exe present on the PATH. The Windows port of GNU Make searches the PATH for
an sh.exe, and uses it if present.
I have tested this in environments with and without sh.exe on the PATH and
confirmed it works as expected.
Signed-off-by: Peter Damianov <peter0x44@disroot.org>
PR lto/110710
* lto-wrapper.cc (run_gcc): Instead of truncating a processed
ltrans input from the Makefile use the new -truncate option
to accomplish the same.
Jakub Jelinek [Thu, 2 May 2024 09:56:16 +0000 (11:56 +0200)]
libgomp: Add gfx90c, 1036 and 1103 declare variant tests
Recently -march=gfx{90c,1036,1103} support has been added, but corresponding
changes weren't done in the testsuite.
The following patch adds that.
Tested on x86_64-linux (with fiji and gfx1103 devices; had to use
OMP_DEFAULT_DEVICE=1 there, fiji doesn't really work due to LLVM dropping
support, but we still list those as offloading devices).
2024-05-02 Jakub Jelinek <jakub@redhat.com>
* testsuite/libgomp.c/declare-variant-4.h (gfx90c, gfx1036, gfx1103):
New functions.
(f): Add #pragma omp declare variant directives for those.
* testsuite/libgomp.c/declare-variant-4-gfx90c.c: New test.
* testsuite/libgomp.c/declare-variant-4-gfx1036.c: New test.
* testsuite/libgomp.c/declare-variant-4-gfx1103.c: New test.
Jakub Jelinek [Thu, 2 May 2024 07:34:31 +0000 (09:34 +0200)]
c++: Implement C++26 P2573R2 - = delete("should have a reason"); [PR114458]
The following patch implements the C++26 P2573R2
= delete("should have a reason"); paper.
I've tried to avoid increasing compile time memory for it when it isn't
used (e.g. by adding a new lang_decl tree member), so the reason is
represented as STRING_CST in DECL_INITIAL (which normally is for
DECL_DELETED_FN error_mark_node) and to differentiate this delete("reason")
initializer from some bogus attempt to initialize a function with "reason"
using the RID_DELETE identifier as TREE_TYPE of the STRING_CST, as nothing
needs to care about the type of the reason. If preferred it could
be say TREE_LIST with the reason STRING_CST and RID_DELETE identifier or
something similar instead, but that would need more compile time memory when
it is used.
2024-05-02 Jakub Jelinek <jakub@redhat.com>
PR c++/114458
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_deleted_function=202403L for C++26.
gcc/cp/ChangeLog
* parser.cc (cp_parser_pure_specifier): Implement C++26 P2573R2
- = delete("should have a reason");. Parse deleted-function-body.
* decl.cc (duplicate_decls): Copy DECL_INITIAL from DECL_DELETED_FN
olddecl to newdecl if it is a STRING_CST.
(cp_finish_decl): Handle deleted init with a reason.
* decl2.cc: Include "escaped_string.h".
(grokfield): Handle deleted init with a reason.
(mark_used): Emit DECL_DELETED_FN reason in the message if any.
* cp-tree.h (DECL_DELETED_FN): Document representation of
= delete("reason") on a DECL.
gcc/testsuite/
* g++.dg/cpp26/feat-cxx26.C (__cpp_deleted_function): Add test.
* g++.dg/cpp26/delete-reason1.C: New test.
* g++.dg/cpp26/delete-reason2.C: New test.
* g++.dg/parse/error65.C (f1): Adjust expected diagnostics.
Richard Biener [Tue, 9 Apr 2024 09:28:47 +0000 (11:28 +0200)]
Remove live-info global bitmap
The following removes the unused tree_live_info_d->global bitmap.
* tree-ssa-live.h (tree_live_info_d::global): Remove.
(partition_is_global): Likewise.
(make_live_on_entry): Do not set bit in global.
* tree-ssa-live.cc (new_tree_live_info): Do not allocate
global bitmap.
(delete_tree_live_info): Do not release it.
(set_var_live_on_entry): Do not set bits in it.
Starting with r14-2047-gd0e891406b16dc we see through subregs which
means for f10 in risbg-ll-2.c we do not end up with rosbg_si_noshift but
rather rosbg_di_noshift which materializes in slightly different start
index. This saves us an extend.
gcc/testsuite/ChangeLog:
* gcc.target/s390/risbg-ll-2.c: Fix start offset for rosbg of
f10.
The change in r14-8408 to also emit partial specializations in the
global module fragment caused the regression in the linked PR; this
patch fixes this by restricting emitted GM partial specializations to
those that are actually used.
PR c++/114630
gcc/cp/ChangeLog:
* module.cc (depset::hash::add_partial_entities): Mark GM
specializations as unreached.
(depset::hash::find_dependencies): Also reach entities in the
DECL_TEMPLATE_SPECIALIZATIONS list.
which leads finally to slightly different assembly code where we
previously ended up for z10 or newer with
lr %r1,%r2
sll %r1,8
rosbg %r1,%r2,32,43,20
llgfr %r2,%r1
br %r14
and now
lr %r1,%r2
sll %r1,12
ar %r2,%r1
risbg %r2,%r2,35,128+55,8
br %r14
The zero-extend materializes via risbg for which the pattern contains an
"and" which is why the test fails. Thus, instead of scanning for RTL
expressions rather scan for assembler instructions for s390.
Richard Biener [Thu, 4 Apr 2024 12:00:10 +0000 (14:00 +0200)]
middle-end/114579 - speed up add_scope_conflicts
The following speeds up stack variable conflict detection by recognizing
that the all-to-all conflict recording is only necessary for CFG merges
as it's the unioning of the live variable sets that doesn't come with
explicit mentions we record conflicts for.
If we employ this optimization we have to make sure to perform the
all-to-all conflict recording for all CFG merges even those into
empty blocks where we might previously have skipped this.
I have reworded the comment before the all-to-all conflict recording
since it seemed to be confusing and missing the point - but maybe I
am also missing something here.
Nevertheless for the testcase in the PR the compile-time spend in
add_scope_conflicts at -O1 drops from previously 67s (39%) to 10s (9%).
PR middle-end/114579
* cfgexpand.cc (add_scope_conflicts_1): Record all-to-all
conflicts only when there's a CFG merge but for all CFG merges.
This patch implements the changes described in
https://github.com/itanium-cxx-abi/cxx-abi/pull/171.
One restriction that is lifted in the ABI that hasn't been updated here
is that the ABI no longer requires unique vtables to be emitted with
vague linkage. I haven't changed this behaviour for this patch, but in
the future we could look into changing the relevant target hook
('class_data_always_comdat') to default to 'false'. But the current
behaviour is more forgiving to changes in key function identification.
Since the ABI for vtables attached to named modules no longer depends on
key methods, this also resolves the issue described in PR c++/105224.
PR c++/105224
gcc/cp/ChangeLog:
* class.cc (finish_struct_1): Also push classes attached to a
module into the 'keyed_classes' list.
* decl.cc (record_key_method_defined): Don't push classes
attached to a named module into the 'keyed_classes' list.
* module.cc (trees_in::read_class_def): Likewise.
* decl2.cc (import_export_class): Uniquely emit vtables for
non-template classes attached to a named module.
(vtables_uniquely_emitted): New function.
(import_export_decl): Update comments. Update with knowledge
about new kinds of uniquely emitted vtables.
gcc/testsuite/ChangeLog:
* g++.dg/modules/virt-2_a.C: Update linkage requirements.
* g++.dg/modules/virt-2_b.C: Likewise.
* g++.dg/modules/virt-2_c.C: Likewise.
* g++.dg/modules/virt-4_a.C: New test.
* g++.dg/modules/virt-4_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Gerald Pfeifer [Wed, 1 May 2024 22:45:52 +0000 (00:45 +0200)]
doc: Describe limitations re Ada, D, and Go on FreeBSD
gcc:
PR target/69374
PR target/112959
* doc/install.texi (Specific) <*-*-freebsd*>: The Ada and D
run-time libraries are broken on i386 which also can affect
64-bit builds. Go is broken.
Jason Merrill [Tue, 12 Dec 2023 23:07:28 +0000 (18:07 -0500)]
c++: drop in-charge for dtors without vbases
Constructors and destructors use the in-charge parameter to decide whether
they're responsible for recursing into virtual bases. Historically all
destructors had this parameter in order to also distinguish the deleting
destructor. But r151673 in GCC 4.5 changed the deleting destructor to just
call the complete destructor and then operator delete, making the in-charge
parameter no longer relevant for destructors in classes without virtual
bases. Having it causes confusion in constexpr evaluation, which assumes
that clones will have the same parameters as the cloned 'tor.
gcc/cp/ChangeLog:
* cp-tree.h (base_ctor_identifier): Adjust comment.
* call.cc (in_charge_arg_for_name): Abort on deleting dtor.
* decl2.cc (maybe_retrofit_in_chrg): Don't add it for
destructors without vbases, either.
* constexpr.cc (cxx_eval_call_expression): Remove workaround.
gcc/testsuite/ChangeLog:
* g++.dg/debug/dwarf2/array-3.C: No more 'int' for in-chrg parm.
* g++.dg/debug/dwarf2/array-4.C: Likewise.
Note the explicit subreg. We can instead use a match_operand with QImode.
This ever-so-slightly simplifies the machine description.
It also means that if we have a QImode object lying around (say we loaded it
from memory in QImode), we can use it directly rather than first extending it
to X, then truncing to QI. So we end up with simpler RTL and in rare cases
improve the code we generate.
When used in a define_split or define_insn_and_split we need to make suitable
adjustments to the split RTL.
Bootstrapped a while back. Just re-tested with a cross.
gcc/
* config/riscv/bitmanip.md (splitter to use w-form division): Remove
explicit subregs.
(zero extended bitfield extraction): Similarly.
* config/riscv/thead.md (*th_memidx_operand): Similarly.
Jeff Law [Wed, 1 May 2024 17:28:41 +0000 (11:28 -0600)]
[committed] [RISC-V] Fix detection of store pair fusion cases
We've got the ability to count the number of store pair fusions happening in
the front-end of the pipeline. When comparing some code from last year vs the
current trunk we saw a fairly dramatic drop.
The problem is the store pair fusion detection code was actively harmful due to
a minor bug in checking offsets. So instead of pairing up 8 byte stores such
as sp+0 with sp+8, it tried to pair up sp+8 and sp+16.
Given uarch sensitivity I didn't try to pull together a testcase. But we could
certainly see the undesirable behavior in benchmarks as simplistic as dhrystone
up through spec2017.
Anyway, bootstrapped a while back. Also verified through our performance
counters that store pair fusion rates are back up. Regression tested with
crosses a few minutes ago.
gcc/
* config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Break out
tests for easier debugging in store pair fusion case. Fix offset
check in same.
Jason Merrill [Mon, 12 Feb 2024 23:24:00 +0000 (18:24 -0500)]
c++: const void* memchr [PR113706]
The C++ standard specifies that the <string.h> functions have const and
non-const overloads, unlike C's single function with const argument and
non-const return. Many systems don't actually implement this, but only add
an overload with non-const argument, so both end up having non-const return.
Solaris <string.h> does what the standard says, but we were penalizing it by
not recognizing the const overload as the built-in memchr.
PR c++/113706
gcc/cp/ChangeLog:
* decl.cc (decls_match): Handle memchr return type being
const-qualified.
gcc/testsuite/ChangeLog:
* g++.dg/opt/const-builtin1.C: New test.
* c-c++-common/pr103798-2.c: Remove xfail.
Gerald Pfeifer [Wed, 1 May 2024 14:23:08 +0000 (16:23 +0200)]
doc: FreeBSD no longer has a GNU toolchain in base
gcc:
PR target/69374
PR target/112959
* doc/install.texi (Specific) <*-*-freebsd*>: No longer refer
to GCC or binutils in base. Recommend bootstrap using binutils.
Value_Range is our polymorphic temporary that can hold any range. It
is used for type agnostic code where it isn't known ahead of time,
what the type of the range will be (irange, france, etc). Currently,
there is a temporary of each type in the object, which means we need
to construct each range for every temporary. This isn't scaling
well now that prange is about to add yet another range type.
This patch removes each range, opting to use in-place new for a byte
buffer sufficiently large to hold ranges of any type. It reduces the
memory footprint by 14% for every Value_Range temporary (from 792 to
680 bytes), and we are guaranteed it will never again grow as we add
more range types (strings, complex numbers, etc).
Surprisingly, it improves VRP performance by 6.61% and overall
compilation by 0.44%, which is a lot more than we bargained for
when we started working on prange performance.
There is a slight change in semantics for Value_Range. The default
constructor does not initialize the object at all. It must be
manually initialized with either Value_Range::set_type(), or by
assigning a range to it. This means that IPA's m_known_value_ranges
must be initialized at allocation, instead of depending on the empty
constructor to initialize it to VR_UNDEFINED for unsupported_range.
I have taken the time to properly document both the class, and each
method. If anything isn't clear, please let me know so I can adjust it
accordingly.
gcc/ChangeLog:
* ipa-fnsummary.cc (evaluate_properties_for_edge): Initialize Value_Range's.
* value-range.h (class Value_Range): Add a buffer and remove
m_irange and m_frange.
(Value_Range::Value_Range): Call init.
(Value_Range::set_type): Same.
(Value_Range::init): Use in place new to initialize buffer.
(Value_Range::operator=): Tidy.
Here are some cleanups to unsupported_range so the assignment operator
takes an unsupported_range and behaves like the other ranges. This
makes subsequent cleanups easier.
gcc/ChangeLog:
* value-range.cc (unsupported_range::union_): Cast vrange to
unsupported_range.
(unsupported_range::intersect): Same.
(unsupported_range::operator=): Make argument an unsupported_range.
* value-range.h: New constructor.
c++: Propagate hidden flag on decls from partitions
While working on some other fixes I noticed that the partition handling
code used the wrong flag to propagate OVL_HIDDEN_P on exported bindings
from partitions. This patch fixes that, and renames the flag to be
clearer.
gcc/cp/ChangeLog:
* name-lookup.cc (walk_module_binding): Use the
partition-specific hidden flag instead of the top-level
decl_hidden.
gcc/testsuite/ChangeLog:
* g++.dg/modules/using-16_a.C: New test.
* g++.dg/modules/using-16_b.C: New test.
* g++.dg/modules/using-16_c.C: New test.
c++: Propagate using decls from partitions [PR114868]
The modules code currently neglects to set OVL_USING_P on the dependency
created for a using-decl, which causes it not to remember that the
OVL_EXPORT_P flag had been set on it when emitted from the primary
interface unit. This patch ensures that it occurs.
PR c++/114868
gcc/cp/ChangeLog:
* module.cc (depset::hash::add_binding_entity): Propagate
OVL_USING_P for using-declarations.
gcc/testsuite/ChangeLog:
* g++.dg/modules/using-15_a.C: New test.
* g++.dg/modules/using-15_b.C: New test.
* g++.dg/modules/using-15_c.C: New test.
This clarifies which kinds of declarations may and may not be exported
in various contexts. The patch additionally fixes up some small issues
that were clarified by the paper.
Most of the changes are with regards to export-declarations, which are
applied for all standards modes that we support '-fmodules-ts' for.
However there are also a couple of changes made to linkage specifiers
('extern "C"'); I've applied these as since C++20, to line up with when
modules were actually introduced.
PR c++/107688
gcc/cp/ChangeLog:
* name-lookup.cc (push_namespace): Error when exporting
namespace with internal linkage.
* parser.h (struct cp_parser): Add new flag
'in_unbraced_export_declaration_p'.
* parser.cc (cp_debug_parser): Print the new flag.
(cp_parser_new): Initialise the new flag.
(cp_parser_module_export): Set the new flag.
(cp_parser_class_specifier): Clear and restore the new flag.
(cp_parser_import_declaration): Imports can now appear directly
in a linkage specification.
(cp_parser_declaration): Categorise declarations as "name" or
"special"; error on the later in contexts where the former is
required.
(cp_parser_class_head): Error when exporting a partial
specialisation.
Andrew MacLeod [Tue, 13 Feb 2024 15:07:11 +0000 (10:07 -0500)]
Remove incorrect asserts.
Gimple_range_op handles builtin functions, and a couple of asserts that
are in place are incorrect in this context, so just remove them.
* gimple-range-op.cc (gimple_range_op_handler::calc_op1): Don't
assert that here are less than 3 operands.
(gimple_range_op_handler::maybe_builtin_call): Simply return if
there is no type for the function call.
Andrew MacLeod [Wed, 13 Mar 2024 18:10:41 +0000 (14:10 -0400)]
Fix ranger when called from SCEV.
Do not pre-evaluate PHIs in the cache, and allow fill_block_cache to
be re-entrant. This allows SCEV to call into ranger with a context
and not produce cycles or loops.
* gimple-range-cache.cc (ranger_cache::get_global_range): Do not
pre-evaluate PHI nodes from the cache.
(ranger_cache::fill_block_cache): Make re-entrant.
Andrew MacLeod [Tue, 20 Feb 2024 17:27:51 +0000 (12:27 -0500)]
Remove wrapper around gimple_range_global.
Now that legacy EVRP has been removed, we can remove the wrapper which
prevented us from using global names before inlining except under
some specific conditions. See discussion:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html
Andrew Pinski [Tue, 30 Apr 2024 16:44:52 +0000 (09:44 -0700)]
Fix the build: error message `quote`
The problem here is the quote mark is for English's
possessiveness rather than a quote but the error message
format detection is too simple so it warns which causes
-Werror to fail.
Committed as obvious after a quick build.
gcc/ChangeLog:
* tree-cfg.cc (verify_gimple_assign): Remove quote
mark to shut up the warning.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Mon, 29 Apr 2024 03:21:02 +0000 (20:21 -0700)]
PHIOPT: Value-replacement check undef
While moving value replacement part of PHIOPT over
to use match-and-simplify, I ran into the case where
we would have an undef use that was conditional become
unconditional. This prevents that. I can't remember at this
point what the testcase was though.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (value_replacement): Reject undef variables
so they don't become unconditional used.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Sun, 28 Apr 2024 01:54:45 +0000 (18:54 -0700)]
PHI-OPT: speed up value_replacement slightly
This adds a few early outs to value_replacement that I noticed
while rewriting this to use match-and-simplify but could be committed
seperately.
* virtual operands won't change so return early for them
* special case `A ? B : B` as that is already just `B`
Also moves the check for NE/EQ earlier as calculating empty_or_with_defined_p
is an IR walk for a BB and that might be big.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (value_replacement): Move check for
NE/EQ earlier.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Sun, 28 Apr 2024 01:54:44 +0000 (18:54 -0700)]
MATCH: change single_non_singleton_phi_for_edges for singleton phis
I noticed that single_non_singleton_phi_for_edges could
return a phi whos entry are all the same for the edge.
This happens only if there was a single phis in the first place.
Also gimple_seq_singleton_p walks the sequence to see if it the one
element in the sequence so there is removing that check actually
reduces the number of pointer walks needed.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (single_non_singleton_phi_for_edges):
Remove the special case of gimple_seq_singleton_p.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Wed, 17 Apr 2024 21:30:06 +0000 (14:30 -0700)]
Remove support for nontemporal stores with ssa_names on lhs [PR112976]
When cfgexpand was changed to support expanding from tuple gimple
(r0-95521-g28ed065ef9f345), the code was added to support
doing nontemporal stores with LHS of a SSA_NAME but that will
never be a nontemporal store.
This patch removes that and asserts that expanding with a LHS
of a SSA_NAME is not a nontemporal store.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
PR middle-end/112976
* cfgexpand.cc (expand_gimple_stmt_1): Remove
support for expanding nontemporal "moves" with
ssa names on the LHS.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Wed, 17 Apr 2024 21:12:17 +0000 (14:12 -0700)]
Add verification of gimple_assign_nontemporal_move_p [PR112976]
Currently the middle-end only knows how to support temporal stores
(the undocumented storent optab) so let's verify that the only time
we set nontemporal_move on an assign is if the the lhs is not a
gimple reg.
Bootstrapped and tested on x86_64-linux-gnu no regressions.
gcc/ChangeLog:
PR middle-end/112976
* tree-cfg.cc (verify_gimple_assign): Verify that
nontmporal moves are stores.
* gimple.h (struct gimple): Note that only
nontemporal stores are supported.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
This patch is primarily meant to improve the code we generate for FP rounding
such as ceil/floor. It also addresses some unnecessary sign extensions in the
same areas.
RISC-V's FP conversions have a bit of undesirable behavior that make them
non-suitable as-is for ceil/floor and other related functions. These
deficiencies are addressed in the Zfa extension, but there's no reason not to
pick up a nice improvement when we can.
Basically we can still use the basic FP conversions for floor/ceil and friends
when we don't care about inexact exceptions by checking for the special cases
first, then emitting the conversion when the special cases don't apply. That's
still much faster than calling into glibc.
The redundant sign extensions are eliminated using the same trick Jivan added
last year, just in a few more places ;-)
This eliminates roughly 10% of the dynamic instruction count for imagick. But
more importantly it's about a 17% performance improvement for that workload
within spec.
This has been bootstrapped as well as regression tested in a cross environment.
It's also successfully built & run specint/specfp correctly.
Pushing to the trunk and the coordination branch momentarily.
gcc/
* config/riscv/iterators.md (fix_ops, fix_uns): New iterators.
(RINT, rint_pattern, rint_rm): Remove unused iterators.
* config/riscv/riscv-protos.h (get_fp_rounding_coefficient): Prototype.
* config/riscv/riscv-v.cc (get_fp_rounding_coefficient): Externalize.
external linkage.
* config/riscv/riscv.md (UNSPEC_LROUND): Remove.
(fix_trunc<ANYF:mode><GPR:mode>2): Replace with ...
(<fix_uns>_trunc<ANYF:mode>si2): New expander & associated insn.
(<fix_uns>_trunc<ANYF:mode>si2_ext): New insn.
(<fix_uns>_trunc<ANYF:mode>di2): Likewise.
(l<rint_pattern><ANYF:mode><GPR:mode>2): Replace with ...
(lrint<ANYF:mode>si2): New expander and associated insn.
(lrint<ANYF:mode>si2_ext, lrint<ANYF:mode>di2): New insns.
(<round_pattern><ANYF:mode>2): Replace with....
(l<round_pattern><ANYF:mode>si2): New expander and associated insn.
(l<round_pattern><ANYF:mode>si2_sext): New insn.
(l<round_pattern><ANYF:mode>di2): Likewise.
(<round_pattern><ANYF:mode>2): New expander.
gcc/testsuite/
* gcc.target/riscv/fix.c: New test.
* gcc.target/riscv/round.c: New test.
* gcc.target/riscv/round_32.c: New test.
* gcc.target/riscv/round_64.c: New test.
In my previous change I mistakenly changed Value_Range to
int_range<2>. The former has "infinite" precision for integer ranges,
whereas int_range<2> has two sub-ranges. This should have been
int_range_max.
A large number of gm2 tests are timing out even on current Solaris/SPARC
systems. As detailed in the PR, the problem is that the gm2 testsuite
artificially lowers many timeouts way below the DejaGnu default of 300
seconds, often as short as 10 seconds. The problem lies both in the
values (they may be appropriate for some targets, but too low for
others, especially under high load) and the fact that it uses absolute
values, overriding e.g. settings from a build-wide site.exp.
Therefore this patch removes all those overrides, restoring the
defaults.
Tested on sparc-sun-solaris2.11 (where all the previous timeouts are
gone) and i386-pc-solaris2.11.
Richard Biener [Wed, 17 Apr 2024 09:22:00 +0000 (11:22 +0200)]
Support {CEIL,FLOOR,ROUND}_{DIV,MOD}_EXPR and EXACT_DIV_EXPR in GIMPLE FE
The following adds support for the various division and modulo operators
to the GIMPLE frontend via __{CEIL,FLOOR,ROUND}_{DIV,MOD} and
__EXACT_DIV operators.
gcc/c/
* gimple-parser.cc (c_parser_gimple_binary_expression):
Parse __{CEIL,FLOOR,ROUND}_{DIV,MOD} and __EXACT_DIV.
gcc/testsuite/
* gcc.dg/gimplefe-53.c: New testcase.
Richard Biener [Tue, 16 Apr 2024 12:05:35 +0000 (14:05 +0200)]
middle-end/13421 - -ftrapv vs. POINTER_DIFF_EXPR
Currently we expand POINTER_DIFF_EXPR using subv_optab when -ftrapv
(but -fsanitize=undefined does nothing). That's not consistent
with the behavior of POINTER_PLUS_EXPR which never uses addv_optab
with -ftrapv. Both are because of the way we select whether to use
the trapping or the non-trapping optab - we look at the result type
of the expression and check
the bugreport correctly complains that -ftrapv affects pointer
subtraction (there's no -ftrapv-pointer). Now that we have
POINTER_DIFF_EXPR we can honor that appropriately.
The patch moves both POINTER_DIFF_EXPR and POINTER_PLUS_EXPR
handling so they will never consider trapping (or saturating)
optabs.
PR middle-end/13421
* optabs-tree.cc (optab_for_tree_code): Do not consider
{add,sub}v or {us,ss}{add,sub} optabs for POINTER_DIFF_EXPR
or POINTER_PLUS_EXPR.
Jakub Jelinek [Tue, 30 Apr 2024 09:22:32 +0000 (11:22 +0200)]
gimple-ssa-sprintf: Use [0, 1] range for %lc with (wint_t) 0 argument [PR114876]
Seems when Martin S. implemented this, he coded there strict reading
of the standard, which said that %lc with (wint_t) 0 argument is handled
as wchar_t[2] temp = { arg, 0 }; %ls with temp arg and so shouldn't print
any values. But, most of the libc implementations actually handled that
case like %c with '\0' argument, adding a single NUL character, the only
known exception is musl.
Recently, C23 changed this in response to GB-141 and POSIX in
https://austingroupbugs.net/view.php?id=1647
so that it should have the same behavior as %c with '\0'.
Because there is implementation divergence, the following patch uses
a range rather than hardcoding it to all 1s (i.e. the %c behavior),
though the likely case is still 1 (forward looking plus most of
implementations).
The res.knownrange = true; assignment removed is redundant due to
the same assignment done unconditionally before the if statement,
rest is formatting fixes.
I don't think the min >= 0 && min < 128 case is right either, I'd think
it should be min >= 0 && max < 128, otherwise it is just some possible
inputs are (maybe) ASCII and there can be others, but this code is a total
mess anyway, with the min, max, likely (somewhere in [min, max]?) and then
unlikely possibly larger than max, dunno, perhaps for at least some chars
in the ASCII range the likely case could be for the ascii case; so perhaps
just the one_2_one_ascii shouldn't set max to 1 and mayfail should be true
for max >= 128. Anyway, didn't feel I should touch that right now.
2024-04-30 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/114876
* gimple-ssa-sprintf.cc (format_character): For min == 0 && max == 0,
set max, likely and unlikely members to 1 rather than 0. Remove
useless res.knownrange = true;. Formatting fixes.
* gcc.dg/pr114876.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust expected
diagnostics.
Christophe Lyon [Thu, 25 Jan 2024 15:43:56 +0000 (15:43 +0000)]
Fix pretty printers regexp for GDB output
GDB emits end of lines as \r\n, we currently match any >0 number of
either \n or \r, possibly leading to mismatches under racy conditions.
I noticed this while running the GCC testsuite using the equivalent of
GDB's READ1 feature [1] which helps detecting bufferization issues.
We try to match
\n$1 = empty std::tuple\r
against {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} which fails because
of the leading \n (which was left in the buffer after the previous
"skipping" pattern matched the preceding \r).
This patch accepts any number of leading \n and/or \r in the "got" clause.
Also take this opportunity to quote \r and \r in the logs, to make
debugging such issues easier.
The assertion doesn't allow IFN_COND_MIN/IFN_COND_MAX, which are
commutative conditional binary operations like ADD/MUL/AND/IOR/XOR,
and can be handled just fine.
In particular, we emit
vminpd %zmm3, %zmm5, %zmm0{%k2}
vminpd %zmm0, %zmm3, %zmm5{%k1}
and
vmaxpd %zmm3, %zmm5, %zmm0{%k2}
vmaxpd %zmm0, %zmm3, %zmm5{%k1}
in the vectorized loops of the first and second subroutine.
2024-04-30 Jakub Jelinek <jakub@redhat.com>
Hongtao Liu <hongtao.liu@intel.com>
PR tree-optimization/114883
* tree-vect-loop.cc (vect_transform_reduction): Allow IFN_COND_MIN and
IFN_COND_MAX in the assert.
Jakub Jelinek [Tue, 30 Apr 2024 07:00:07 +0000 (09:00 +0200)]
libgcc: Do use weakrefs for glibc 2.34 on GNU Hurd
On Mon, Apr 29, 2024 at 01:44:24PM +0000, Joseph Myers wrote:
> > glibc 2.34 and later doesn't have separate libpthread (libpthread.so.0 is a
> > dummy shared library with just some symbol versions for compatibility, but
> > all the pthread_* APIs are in libc.so.6).
>
> I suspect this has caused link failures in the glibc testsuite for Hurd,
> which still has separate libpthread.
>
> https://sourceware.org/pipermail/libc-testresults/2024q2/012556.html
So like this then?
2024-04-30 Jakub Jelinek <jakub@redhat.com>
* gthr.h (GTHREAD_USE_WEAK): Don't redefine to 0 for glibc 2.34+
on GNU Hurd.
Jakub Jelinek [Tue, 30 Apr 2024 06:58:39 +0000 (08:58 +0200)]
libcpp: Adjust __STDC_VERSION__ for C23
While the C23 standard isn't officially release yet,
in 2011 we've changed __STDC_VERSION__ value for C11 already
in the month in which the new __STDC_VERSION__ value has been
finalized, so we want to change this now or wait
until we implement all the C23 features?
Note, seems Clang up to 17 also used 202000L for -std=c2x but
Clang 18+ uses 202311L as specified in the latest C23 drafts.
2024-04-30 Jakub Jelinek <jakub@redhat.com>
* init.cc (cpp_init_builtins): Change __STDC_VERSION__
for C23 from 202000L to 202311L.
* doc/cpp.texi (__STDC_VERSION__): Document 202311L value
for -std=c23/-std=gnu23.
Jakub Jelinek [Tue, 30 Apr 2024 06:57:15 +0000 (08:57 +0200)]
c++: Implement C++26 P0609R3 - Attributes for Structured Bindings [PR114456]
The following patch implements the P0609R3 paper; we build the
VAR_DECLs for the structured binding identifiers early, so all we need
IMHO is just to parse the attributed identifier list and pass the attributes
to the VAR_DECL creation.
The paper mentions maybe_unused and gnu::nonstring attributes as examples
where they can be useful. Not sure about either of them.
For maybe_unused, the thing is that both GCC and clang already don't
diagnose maybe unused for the structured binding identifiers, because it
would be a false positive too often; and there is no easy way to find out
if a structured binding has been written with the P0609R3 paper in mind or
not (maybe we could turn it on if in the structured binding is any
attribute, even if just [[]] and record that as a flag on the whole
underlying decl, so that we'd diagnose
auto [a, b, c[[]]] = d;
// use a, c but not b
but not
auto [e, f, g] = d;
// use a, c but not b
). For gnu::nonstring, the issue is that we currently don't allow the
attribute on references to char * or references to char[], just on
char */char[]. I've filed a PR for that.
The first testcase in the patch tests it on [[]] and [[maybe_unused]],
just whether it is parsed properly, second on gnu::deprecated, which
works. Haven't used deprecated attribute because the paper said that
attribute is for further investigation.
2024-04-30 Jakub Jelinek <jakub@redhat.com>
PR c++/114456
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_structured_bindings for C++26 to 202403L rather than
201606L.
gcc/cp/
* parser.cc (cp_parser_decomposition_declaration): Implement C++26
P0609R3 - Attributes for Structured Bindings. Parse attributed
identifier lists for structured binding declarations, pass the
attributes to start_decl.
gcc/testsuite/
* g++.dg/cpp26/decomp1.C: New test.
* g++.dg/cpp26/decomp2.C: New test.
* g++.dg/cpp26/feat-cxx26.C (__cpp_structured_bindings): Expect
202403 rather than 201606.
Richard Biener [Fri, 26 Apr 2024 13:47:13 +0000 (15:47 +0200)]
middle-end/114734 - wrong code with expand_call_mem_ref
When expand_call_mem_ref looks at the definition of the address
argument to eventually expand a &TARGET_MEM_REF argument together
with a masked load it fails to honor constraints imposed by SSA
coalescing decisions. The following fixes this.
PR middle-end/114734
* internal-fn.cc (expand_call_mem_ref): Use
get_gimple_for_ssa_name to get at the def stmt of the address
argument to honor SSA coalescing constraints.
c++: Fix instantiation of imported temploid friends [PR114275]
This patch fixes a number of issues with the handling of temploid friend
declarations.
The primary issue is that instantiations of friend declarations should
attach the declaration to the same module as the befriending class, by
[module.unit] p7.1 and [temp.friend] p2; this could be a different
module from the current TU, and so needs special handling.
The other main issue here is that we can't assume that just because name
lookup didn't find a definition for a hidden class template, that it
doesn't exist at all: it could be a non-exported entity that we've
nevertheless streamed in from an imported module. We need to ensure
that when instantiating template friend classes that we return the same
TEMPLATE_DECL that we got from our imports, otherwise we will get later
issues with 'duplicate_decls' (rightfully) complaining that they're
different when trying to merge.
This doesn't appear necessary for function templates due to the existing
name lookup handling already finding these hidden declarations.
PR c++/105320
PR c++/114275
gcc/cp/ChangeLog:
* cp-tree.h (propagate_defining_module): Declare.
(lookup_imported_hidden_friend): Declare.
* decl.cc (duplicate_decls): Also check if hidden decls can be
redeclared in this module.
* module.cc (imported_temploid_friends): New.
(init_modules): Initialize it.
(trees_out::decl_value): Write it; don't consider imported
temploid friends as attached to a module.
(trees_in::decl_value): Read it.
(get_originating_module_decl): Follow the owning decl for an
imported temploid friend.
(propagate_defining_module): New.
* name-lookup.cc (get_mergeable_namespace_binding): New.
(lookup_imported_hidden_friend): New.
* pt.cc (tsubst_friend_function): Propagate defining module for
new friend functions.
(tsubst_friend_class): Lookup imported hidden friends. Check
for valid module attachment of existing names. Propagate
defining module for new classes.
gcc/testsuite/ChangeLog:
* g++.dg/modules/tpl-friend-10_a.C: New test.
* g++.dg/modules/tpl-friend-10_b.C: New test.
* g++.dg/modules/tpl-friend-10_c.C: New test.
* g++.dg/modules/tpl-friend-10_d.C: New test.
* g++.dg/modules/tpl-friend-11_a.C: New test.
* g++.dg/modules/tpl-friend-11_b.C: New test.
* g++.dg/modules/tpl-friend-12_a.C: New test.
* g++.dg/modules/tpl-friend-12_b.C: New test.
* g++.dg/modules/tpl-friend-12_c.C: New test.
* g++.dg/modules/tpl-friend-12_d.C: New test.
* g++.dg/modules/tpl-friend-12_e.C: New test.
* g++.dg/modules/tpl-friend-12_f.C: New test.
* g++.dg/modules/tpl-friend-13_a.C: New test.
* g++.dg/modules/tpl-friend-13_b.C: New test.
* g++.dg/modules/tpl-friend-13_c.C: New test.
* g++.dg/modules/tpl-friend-13_d.C: New test.
* g++.dg/modules/tpl-friend-13_e.C: New test.
* g++.dg/modules/tpl-friend-13_f.C: New test.
* g++.dg/modules/tpl-friend-13_g.C: New test.
* g++.dg/modules/tpl-friend-14_a.C: New test.
* g++.dg/modules/tpl-friend-14_b.C: New test.
* g++.dg/modules/tpl-friend-14_c.C: New test.
* g++.dg/modules/tpl-friend-14_d.C: New test.
* g++.dg/modules/tpl-friend-9.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Currently different places calling 'module_may_redeclare' all emit very
similar but slightly different error messages, and handle different
kinds of declarations differently. This patch makes the function
perform its own error messages so that they're all in one place, and
prepares it for use with temploid friends.
Patrick Palka [Tue, 30 Apr 2024 01:27:59 +0000 (21:27 -0400)]
c++/modules: imported spec befriending class tmpl [PR114889]
When adding to CLASSTYPE_BEFRIENDING_CLASSES as part of installing an
imported class definition, we need to look through TEMPLATE_DECL like
make_friend_class does.
Otherwise in the below testcase we won't add _Hashtable<int, int> to
CLASSTYPE_BEFRIENDING_CLASSES of _Map_base, which leads to a bogus
access check failure for _M_hash_code.
PR c++/114889
gcc/cp/ChangeLog:
* module.cc (trees_in::read_class_def): Look through
TEMPLATE_DECL when adding to CLASSTYPE_BEFRIENDING_CLASSES.
gcc/testsuite/ChangeLog:
* g++.dg/modules/friend-8_a.H: New test.
* g++.dg/modules/friend-8_b.C: New test.
gcc/fortran/ChangeLog:
* expr.cc (check_transformational): Add SELECTED_LOGICAL_KIND
to allowed functions for Fortran 2023.
* gfortran.h (GFC_ISYM_SL_KIND): New.
* gfortran.texi: Mention SELECTED_LOGICAL_KIND.
* intrinsic.cc (add_functions): Add SELECTED_LOGICAL_KIND.
(gfc_intrinsic_func_interface): Allow it in initialization
expressions.
* intrinsic.h (gfc_simplify_selected_logical_kind): New proto.
* intrinsic.texi: Add SELECTED_LOGICAL_KIND.
* simplify.cc (gfc_simplify_selected_logical_kind): New
function.
* trans-decl.cc (gfc_build_intrinsic_function_decls): Initialize
gfor_fndecl_sl_kind.
* trans-intrinsic.cc (gfc_conv_intrinsic_sl_kind): New function.
(gfc_conv_intrinsic_function): Call it for GFC_ISYM_SL_KIND.
* trans.h (gfor_fndecl_sl_kind): New symbol.
gcc/testsuite/ChangeLog:
* gfortran.dg/selected_logical_kind_1.f90: New test.
* gfortran.dg/selected_logical_kind_2.f90: New test.
* gfortran.dg/selected_logical_kind_3.f90: New test.
* gfortran.dg/selected_logical_kind_4.f90: New test.
This patch updates the Solaris baselines for the GLIBCXX_3.4.33 version
added in GCC 14.0.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
each), together with the GLIBCXX_3.4.32 update, on both gcc-14 branch
and trunk.
This patch updates the Solaris baselines for the GLIBCXX_3.4.32 version
added in GCC 13.2.
Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (32 and 64-bit
each) on the gcc-13 branch and (together with the GLIBCXX_3.4.33 update)
on both gcc-14 branch and trunk.
Paul Thomas [Mon, 29 Apr 2024 10:52:11 +0000 (11:52 +0100)]
Fortran: Fix regression caused by r14-9752 [PR114959]
2024-04-29 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/114959
* trans-expr.cc (gfc_trans_class_init_assign): Return NULL_TREE
if the default initializer has all NULL fields. Guard this
by a requirement that the code not be EXEC_INIT_ASSIGN and that
the object be an INTENT_OUT dummy.
* trans-stmt.cc (gfc_trans_allocate): Change the initializer
code for allocate with mold to EXEC_ALLOCATE to allow an
initializer with all NULL fields.
gcc/testsuite/
PR fortran/114959
* gfortran.dg/pr114959.f90: New test.
internal compiler error: in extract_insn, at recog.cc:2812.
This patch would like to take care of the above rtl. Given the value of
const_poly_int can hardly excceed the max of int64, we can simply
consider the highest 8 bytes of TImode is zero and then set the dest
to (const_int 0).
The below test cases are fixed by this PATCH.
C:
FAIL: gcc.dg/graphite/pr111878.c (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: gcc.dg/graphite/pr111878.c (test for excess errors)
Fortran:
FAIL: gfortran.dg/graphite/vect-pr40979.f90 -O (internal compiler
error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (internal
compiler error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29581.f90 -O3 -g (test for excess
errors)
FAIL: gfortran.dg/graphite/pr14741.f90 -O (test for excess errors)
FAIL: gfortran.dg/graphite/pr29581.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for
excess errors)
FAIL: gfortran.dg/graphite/vect-pr40979.f90 -O (test for excess
errors)
FAIL: gfortran.dg/graphite/id-27.f90 -O (internal compiler error: in
extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -g (internal compiler
error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -g (test for excess
errors)
FAIL: gfortran.dg/graphite/id-27.f90 -O (test for excess errors)
FAIL: gfortran.dg/graphite/pr29832.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (test for
excess errors)
FAIL: gfortran.dg/graphite/pr29581.f90 -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions (internal
compiler error: in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr14741.f90 -O (internal compiler error:
in extract_insn, at recog.cc:2812)
FAIL: gfortran.dg/graphite/pr29581.f90 -O3 -g (internal compiler
error: in extract_insn, at recog.cc:2812)
The below test suites are passed for this patch:
* The rv64gcv fully regression test.
* The rv64gc fully regression test.
Try to write some RTL code for test but not works well according to
existing test cases. Thus, take above as test cases. Please note
graphite require the gcc build with isl.
PR target/114885
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_legitimize_subreg_const_poly_move): New
func impl to take care of (const_int_poly:TI 8).
(riscv_legitimize_move): Handle subreg is const_int_poly,
The extension parsing table entries for a range of Zic* extensions
does not match the mask definition in riscv.opt.
This results in broken TARGET_ZIC* macros, because the values of
riscv_zi_subext and riscv_zicmo_subext are set wrong.
This patch fixes this by moving Zic64b into riscv_zicmo_subext
and all other affected Zic* extensions to riscv_zi_subext.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Move ziccamoa, ziccif,
zicclsm, and ziccrse into riscv_zi_subext.
* config/riscv/riscv.opt: Define MASK_ZIC64B for
riscv_ziccmo_subext.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Jie Mei [Sun, 28 Apr 2024 08:57:31 +0000 (16:57 +0800)]
MIPS: Add MIN/MAX.fmt instructions support for MIPS R6
This patch adds the smin/smax RTL mode for the
min/max.fmt instructions.
Also, since the min/max.fmt instrucions applies to the
IEEE 754-2008 "minNum" and "maxNum" operations, this
patch also provides the new "fmin<mode>3" and
"fmax<mode>3" modes.
gcc/ChangeLog:
* config/mips/i6400.md (i6400_fpu_minmax): New
define_insn_reservation.
* config/mips/mips.h (ISA_HAS_FMIN_FMAX): Define new macro.
* config/mips/mips.md (UNSPEC_FMIN): New unspec.
(UNSPEC_FMAX): Same as above.
(type): Add fminmax.
(smin<mode>3): Generates MIN.fmt instructions.
(smax<mode>3): Generates MAX.fmt instructions.
(fmin<mode>3): Generates MIN.fmt instructions.
(fmax<mode>3): Generates MAX.fmt instructions.
* config/mips/p6600.md (p6600_fpu_fabs): Include fminmax
type.
gcc/testsuite/ChangeLog:
* gcc.target/mips/mips-minmax1.c: New test for MIPS R6.
* gcc.target/mips/mips-minmax2.c: Same as above.
Callers of irange_bitmask must normalize value/mask pairs.
As per the documentation, irange_bitmask must have the unknown bits in
the mask set to 0 in the value field. Even though we say we must have
normalized value/mask bits, we don't enforce it, opting to normalize
on the fly in union and intersect. Avoiding this lazy enforcing as
well as the extra saving/restoring involved in returning the changed
status, gives us a performance increase of 1.25% for VRP and 1.51% for
ipa-CP.
gcc/ChangeLog:
* tree-ssa-ccp.cc (ccp_finalize): Normalize before calling
set_bitmask.
* value-range.cc (irange::intersect_bitmask): Calculate changed
irange_bitmask bits on our own.
(irange::union_bitmask): Same.
(irange_bitmask::verify_mask): Verify that bits are normalized.
* value-range.h (irange_bitmask::union_): Do not normalize.
Remove return value.
(irange_bitmask::intersect): Same.
Aldy Hernandez [Wed, 20 Mar 2024 04:51:55 +0000 (05:51 +0100)]
Remove range_zero and range_nonzero.
Remove legacy range_zero and range_nonzero as they return by value,
which make it not work in a separate irange and prange world. Also,
we already have set_zero and set_nonzero methods in vrange.
gcc/ChangeLog:
* range-op-ptr.cc (pointer_plus_operator::wi_fold): Use method
range setters instead of out of line functions.
(pointer_min_max_operator::wi_fold): Same.
(pointer_and_operator::wi_fold): Same.
(pointer_or_operator::wi_fold): Same.
* range-op.cc (operator_negate::fold_range): Same.
(operator_addr_expr::fold_range): Same.
(range_op_cast_tests): Same.
* range.cc (range_zero): Remove.
(range_nonzero): Remove.
* range.h (range_zero): Remove.
(range_nonzero): Remove.
* value-range.cc (range_tests_misc): Use method instead of out of
line function.
Aldy Hernandez [Tue, 19 Mar 2024 17:22:08 +0000 (18:22 +0100)]
Make some integer specific ranges generic Value_Range's.
There are some irange uses that should be Value_Range, because they
can be either integers or pointers. This will become a problem when
prange comes live.
gcc/ChangeLog:
* tree-ssa-loop-split.cc (split_at_bb_p): Make int_range a Value_Range.
* tree-ssa-strlen.cc (get_range): Same.
* value-query.cc (range_query::get_tree_range): Handle both
integers and pointers.
* vr-values.cc (simplify_using_ranges::fold_cond_with_ops): Make
r0 and r1 Value_Range's.
Aldy Hernandez [Tue, 19 Mar 2024 16:17:53 +0000 (17:17 +0100)]
Accept a vrange in get_legacy_range.
In preparation for prange, make get_legacy_range take a generic
vrange, not just an irange.
gcc/ChangeLog:
* value-range.cc (get_legacy_range): Make static and add another
version of get_legacy_range that takes a vrange.
* value-range.h (class irange): Remove unnecessary friendship with
get_legacy_range.
(get_legacy_range): Accept a vrange.
Aldy Hernandez [Tue, 19 Mar 2024 15:35:41 +0000 (16:35 +0100)]
Verify that reading back from vrange_storage doesn't drop bits.
We have a sanity check in the irange storage code to make sure that
reading back a cache entry we have just written to yields exactly the
same range. There's no need to do this only for integers. This patch
moves the code to a more generic place.
However, doing so tickles a latent bug in the frange code where a
range is being pessimized from [0.0, 1.0] to [-0.0, 1.0]. Exclude
checking frange's until this bug is fixed.
Aldy Hernandez [Wed, 7 Feb 2024 10:27:29 +0000 (11:27 +0100)]
Make fold_cond_with_ops use a boolean type for range_true/range_false.
Conditional operators are always boolean, regardless of their
operands. Getting the type wrong is not currently a problem, but will
be when prange's can no longer store an integer.
gcc/ChangeLog:
* vr-values.cc (simplify_using_ranges::fold_cond_with_ops): Remove
type from range_true and range_false.
git://gcc.gnu.org / gcc.git / log