Michal Jires [Thu, 24 Oct 2024 01:02:55 +0000 (03:02 +0200)]
lto: Remap node order for stability.
This patch adds remapping of node order for each lto partition.
Resulting order conserves relative order inside partition, but
is independent of outside symbols. So if lto partition contains
identical set of symbols, their remapped order will be stable
between compilations.
Michal Jires [Thu, 24 Oct 2024 00:21:00 +0000 (02:21 +0200)]
Node clones share order.
Symbol order corresponds to the order in source code.
For clones their order is currently arbitrarily chosen as max order++
But it would be more consistent with original purpose to choose clones
order to be shared with the original node order.
This stabilizes clone order for Incremental LTO.
Order is thus no longer unique, but this property is not used outside
of previous patch, where we can use uid.
If total order would be needed, sorting by order and then uid suffices.
gcc/ChangeLog:
* cgraph.h (symbol_table::register_symbol):
Order can be already set.
* cgraphclones.cc (cgraph_node::create_clone):
Reuse order for clones.
Michal Jires [Thu, 24 Oct 2024 00:04:12 +0000 (02:04 +0200)]
ipa-strub: Replace cgraph_node order with uid.
ipa_strub_set_mode_for_new_functions uses node order as unique ever
increasing identifier. This is better satisfied with uid.
Order loses uniqueness with following patches.
gcc/ChangeLog:
* ipa-strub.cc (ipa_strub_set_mode_for_new_functions): Replace
order with uid.
(pass_ipa_strub_mode::execute): Likewise.
Jakub Jelinek [Wed, 18 Dec 2024 14:53:24 +0000 (15:53 +0100)]
c++: Speed up compilation of large char array initializers when not using #embed
The following patch (again, on top of the #embed patchset
attempts to optimize compilation of large {{{,un}signed ,}char,std::byte}
array initializers when not using #embed in the source.
Unlike the C patch which is done during the parsing of initializers this
is done when lexing tokens into an array, because C++ lexes all tokens
upfront and so by the time we parse the initializers we already have 16
bytes per token allocated (i.e. 32 extra compile time memory bytes per
one byte in the array).
The drawback is again that it can result in worse locations for diagnostics
(-Wnarrowing, -Wconversion) when initializing signed char arrays with values
128..255. Not really sure what to do about this though unlike the C case,
the locations would need to be preserved through reshape_init* and perhaps
till template instantiation.
For #embed, there is just a single location_t (could be range of the
directive), for diagnostics perhaps we could extend it to say byte xyz of
the file embedded here or something like that, but the optimization done by
this patch, either we'd need to bump the minimum limit at which to try it,
or say temporarily allocate a location_t array for each byte and then clear
it when we no longer need it or something.
I've been using the same testcases as for C, with #embed of 100'000'000
bytes:
time ./cc1plus -quiet -O2 -o test4a.s2 test4a.c
real 0m0.972s
user 0m0.578s
sys 0m0.195s
with xxd -i alternative of the same data without this patch it consumed
around 13.2GB of RAM and
time ./cc1plus -quiet -O2 -o test4b.s4 test4b.c
real 3m47.968s
user 3m41.907s
sys 0m5.015s
and the same with this patch it consumed around 3.7GB of RAM and
time ./cc1plus -quiet -O2 -o test4b.s3 test4b.c
real 0m24.772s
user 0m23.118s
sys 0m1.495s
2024-12-18 Jakub Jelinek <jakub@redhat.com>
* parser.cc (cp_lexer_new_main): Attempt to optimize large sequences
of CPP_NUMBER with int type and values 0-255 separated by CPP_COMMA
into CPP_EMBED with RAW_DATA_CST u.value.
Jakub Jelinek [Wed, 18 Dec 2024 14:21:40 +0000 (15:21 +0100)]
gimple-fold: Fix up decode_field_reference xor handling [PR118081]
The function comment says:
*XOR_P is to be FALSE if EXP might be a XOR used in a compare, in which
case, if XOR_CMP_OP is a zero constant, it will be overridden with *PEXP,
*XOR_P will be set to TRUE, and the left-hand operand of the XOR will be
decoded. If *XOR_P is TRUE, XOR_CMP_OP is supposed to be NULL, and then the
right-hand operand of the XOR will be decoded.
and the comment right above the xor_p handling says
/* Turn (a ^ b) [!]= 0 into a [!]= b. */
but I don't see anything that would actually check that the other operand is
0, in the testcase below it happily optimizes (a ^ 1) == 8 into a == 1.
The following patch adds that check.
Note, there are various other parts of the function I'm worried about, but
haven't had time to construct counterexamples yet.
One worrying thing is the
/* Drop casts, only save the outermost type. We need not worry about
narrowing then widening casts, or vice-versa, for those that are not
essential for the compare have already been optimized out at this
point. */
comment, while obviously there are various optimizations which do optimize
nested casts and the like, I'm not really sure it is safe to rely on them
happening always before this optimization, there are various options to
disable certain optimizations and some IL could appear right before
ifcombine without being optimized yet the way this routine expects.
Plus, the 3 casts are looked through in between various optimizations which
might make those narrowing/widening or vice versa cases necessary.
Also, e.g. for the xor optimization, I think there is a difference between
int a and
(a ^ 0x23) == 0
and
((int) (((unsigned char) a) ^ (unsigned char) 0x23)) == 0
etc.
Another thing I'm worrying about are mixing up the different patterns
together, there is the BIT_AND_EXPR handling, BIT_XOR_EXPR handling,
RSHIFT_EXPR handling and then load handling.
What if all 4 appear together, or 3 of them, 2 of them?
Is the xor optimization still valid if there is BIT_AND_EXPR in between?
I.e. instead of
(a ^ 123) == 0
there is
((a ^ 123) & 234) == 0
?
2024-12-18 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/118081
* gimple-fold.cc (decode_field_reference): Only set *xor_p to true
if *xor_cmp_op is integer_zerop.
libatomic/ChangeLog:
PR driver/81358
* Makefile.am: Pass -fno-link-libatomic.
New rule all.
* configure.ac: Assert that CFLAGS is set and pass -fno-link-libatomic.
* Makefile.in: Regenerate.
* configure: Regenerate.
Signed-off-by: Prathamesh Kulkarni <prathameshk@nvidia.com> Co-authored-by: Matthew Malcolmson <mmalcolmson@nvidia.com>
Tobias Burnus [Wed, 18 Dec 2024 08:25:50 +0000 (09:25 +0100)]
OpenMP: Add declare variant's 'append_args' clause in C/C++
Add the append_args clause of 'declare variant' to C and C++,
fix/improve diagnostic for 'interop' clause and 'declare_variant'
clauses on the way.
Cleanup dispatch handling in gimplify_call_expr a bit and
partially handle 'append_args'. (Namely, those parts that
do not require libraries calls, i.e. a dispatch construct
where the 'device' and 'interop' clause has been specified.)
The sorry can be removed once an enum value like
omp_ipr_(ompx_gnu_)omp_device_num (cf. OpenMP Spec Issue 4451)
has to be added to the runtime side such that omp_get_interop_int
returns the device number of an interop object (as passed to
dispatch via the interop clause); and a call to GOMP_interop
has to be added to create interop objects. Once available, only
a very localized change in gimplify_call_expr is required to
claim for full support. - And Fortran parsing support.
* c-parser.cc (c_parser_omp_clause_init_modifiers): New;
split of from ...
(c_parser_omp_clause_init): ... here; call it.
(c_finish_omp_declare_variant): Parse 'append_args' clause.
(c_parser_omp_clause_interop): Set tree used/read.
gcc/cp/ChangeLog:
* decl.cc (omp_declare_variant_finalize_one): Handle
append_args.
* parser.cc (cp_parser_omp_clause_init_modifiers): New;
split of from ...
(cp_parser_omp_clause_init): ... here; call it.
(cp_parser_omp_all_clauses): Replace interop parsing by
a call to ...
(cp_parser_omp_clause_interop): ... this new function;
set tree used/read.
(cp_finish_omp_declare_variant): Parse 'append_args' clause.
(cp_parser_omp_declare): Update comment.
* pt.cc (tsubst_attribute, tsubst_omp_clauses): Handle template
substitution also for declare variant's append_args clause,
using for 'init' the same code as for interop's init clause.
gcc/ChangeLog:
* gimplify.cc (gimplify_call_expr): Update for OpenMP's
append_args; cleanup of OpenMP's dispatch clause handling.
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/declare-variant-2.c: Update dg-error msg.
* c-c++-common/gomp/dispatch-12.c: Likewise.
* c-c++-common/gomp/dispatch-11.c: Likewise and extend a bit.
* c-c++-common/gomp/append-args-1.c: New test.
* c-c++-common/gomp/append-args-2.c: New test.
* c-c++-common/gomp/append-args-3.c: New test.
* g++.dg/gomp/append-args-1.C: New test.
* g++.dg/gomp/append-args-2.C: New test.
* g++.dg/gomp/append-args-3.C: New test.
Jakub Jelinek [Wed, 18 Dec 2024 11:00:13 +0000 (12:00 +0100)]
c++: Fix up pedantic handling of alignas [PR110345]
The following patch on top of the PR110345 P2552R3 series
emits pedantic pedwarns for alignas appertaining to incorrect entities.
As the middle-end and attribute exclusions look for "aligned" attribute,
the patch transforms alignas into "internal "::aligned attribute (didn't
use [[aligned (x)]] so that people can't type it that way).
2024-12-18 Jakub Jelinek <jakub@redhat.com>
PR c++/110345
gcc/c-family/
* c-common.h (attr_aligned_exclusions): Declare.
(handle_aligned_attribute): Likewise.
* c-attribs.cc (handle_aligned_attribute): No longer
static.
(attr_aligned_exclusions): Use extern instead of static.
gcc/cp/
* cp-tree.h (enum cp_tree_index): Add CPTI_INTERNAL_IDENTIFIER.
(internal_identifier): Define.
(internal_attribute_table): Declare.
* parser.cc (cp_parser_exception_declaration): Error on alignas
on exception declaration.
(cp_parser_std_attribute_spec): Turn alignas into internal
ns aligned attribute rather than gnu.
* decl.cc (initialize_predefined_identifiers): Initialize
internal_identifier.
* tree.cc (handle_alignas_attribute): New function.
(internal_attributes): New variable.
(internal_attribute_table): Likewise.
* cp-objcp-common.h (cp_objcp_attribute_table): Add
internal_attribute_table entry.
gcc/testsuite/
* g++.dg/cpp0x/alignas1.C: Add dg-options "".
* g++.dg/cpp0x/alignas2.C: Likewise.
* g++.dg/cpp0x/alignas7.C: Likewise.
* g++.dg/cpp0x/alignas21.C: New test.
* g++.dg/ext/bitfield9.C: Expect a warning.
* g++.dg/cpp2a/is-layout-compatible3.C: Add dg-options -pedantic.
Expect a warning.
Jakub Jelinek [Wed, 18 Dec 2024 10:58:39 +0000 (11:58 +0100)]
c++: Add fallthrough attribute further test coverage [PR110345]
Similarly for fallthrough attribute. Had to add a second testcase because
the diagnostics for fallthrough not used within switch at all is done during
expansion and expansion won't happen if there are other errors in the
testcase.
2024-12-18 Jakub Jelinek <jakub@redhat.com>
PR c++/110345
* g++.dg/cpp0x/attr-fallthrough1.C: New test.
* g++.dg/cpp0x/attr-fallthrough2.C: New test.
Jakub Jelinek [Wed, 18 Dec 2024 10:57:50 +0000 (11:57 +0100)]
c++: Add carries_dependency further test coverage [PR110345]
This patch adds additional test coverage for the carries_dependency
attribute (unlike other attributes, the attribute actually isn't implemented
for real, so we warn even in the cases of valid uses because we ignore those
as well).
2024-12-18 Jakub Jelinek <jakub@redhat.com>
PR c++/110345
* g++.dg/cpp0x/attr-carries_dependency2.C: New test.
Jakub Jelinek [Wed, 18 Dec 2024 10:55:59 +0000 (11:55 +0100)]
c++: Handle attributes on exception declarations [PR110345]
This is a continuation of the series for the ignorability of standard
attributes.
I've added a test for assume attribute diagnostics appertaining to various
entities (mostly invalid) and while doing that, I've discovered that
attributes on exception declarations were mostly ignored, this patch
adds the missing cp_decl_attributes call and also in the
cp_parser_type_specifier_seq case differentiates between attributes and
std_attributes to be able to differentiate between attributes which apply
to the declaration using type-specifier-seq and attributes after the type
specifiers.
2024-12-18 Jakub Jelinek <jakub@redhat.com>
PR c++/110345
* parser.cc (cp_parser_type_specifier_seq): Chain cxx11_attribute_p
attributes after any type specifier in the is_declaration case
to std_attributes rather than attributes. Set also ds_attribute
or ds_std_attribute locations if not yet set.
(cp_parser_exception_declaration): Pass &type_specifiers.attributes
instead of NULL as last argument, call cp_decl_attributes.
Jakub Jelinek [Wed, 18 Dec 2024 10:54:57 +0000 (11:54 +0100)]
c++: Diagnose attributes on class/enum declarations [PR110345]
The following testcase shows another issue where we just ignored
attributes without telling user we did that.
If there are any declarators, the ignoring of the attribute
are diagnosed in grokdeclarator etc., but if there is none
(and we don't error such as on
int;
), the following patch emits diagnostics.
Jakub Jelinek [Wed, 18 Dec 2024 10:52:31 +0000 (11:52 +0100)]
c++: Handle enum attributes like class attributes [PR110345]
As the following testcase shows, cp_parser_decl_specifier_seq
was calling warn_misplaced_attr_for_class_type only for class types
and not for enum types, while check_tag_decl calls them for both
class and enum types.
Enum types are really the same case here, the attribute needs to go
before the type name to apply to all instances of the type.
Additionally, when warn_misplaced_attr_for_class_type is called, it
diagnoses something and so it is fine to drop the attributes then
on the floor, but in case it wasn't a type decision, it silently
discarded the attributes, which is invalid for the ignorability of
standard attributes paper. This patch in that case adds them to
decl_specs->std_attributes and let it be diagnosed later (e.g.
in grokdeclarator).
2024-12-18 Jakub Jelinek <jakub@redhat.com>
PR c++/110345
* parser.cc (cp_parser_decl_specifier_seq): Call
warn_misplaced_attr_for_class_type for all OVERLOAD_TYPE_P
types, not just CLASS_TYPE_P. When not calling
warn_misplaced_attr_for_class_type, don't clear attrs and
add it to decl_specs->std_attributes instead.
Jakub Jelinek [Wed, 18 Dec 2024 10:50:26 +0000 (11:50 +0100)]
inline-asm: Add - constraint modifier support for toplevel extended asm [PR41045]
The following patch adds - constraint modifier support (only in toplevel asms),
which one can use to allow i, s and n constraint to accept SYMBOL_REFs
even with -fpic.
So, the recommended way mark toplevel asm as defining some symbol
would be ":" constraint (usually with cc modifier in the pattern), while
to mark toplevel asm as using some symbol (again, either function or
variable), one would use "-s" constraint again with address of that function
or variable.
2024-12-18 Jakub Jelinek <jakub@redhat.com>
PR c/41045
gcc/
* stmt.cc (parse_output_constraint, parse_input_constraint): Handle
- modifier.
* recog.h (raw_constraint_p): Declare.
* recog.cc (raw_constraint_p): New variable.
(asm_operand_ok, constrain_operands): Handle - modifier.
* common.md (i, s, n): For raw_constraint_p don't require
LEGITIMATE_PIC_OPERAND_P.
* doc/md.texi: Document - constraint modifier.
gcc/c/
* c-typeck.cc (build_asm_expr): Reject - constraint modifier inside
of a function.
gcc/cp/
* semantics.cc (finish_asm_stmt): Reject - constraint modifier inside
of a function.
gcc/testsuite/
* c-c++-common/toplevel-asm-4.c: Add missing %cc2 use in template, add
bar, x, &y operands with "-i" and "-s" constraints.
(x, y): New variables.
(bar): Declare.
* c-c++-common/toplevel-asm-7.c: New test.
* c-c++-common/toplevel-asm-8.c: New test.
Jakub Jelinek [Wed, 18 Dec 2024 10:49:11 +0000 (11:49 +0100)]
inline-asm: Add support for cc operand modifier
As mentioned in the "inline asm: Add new constraint for symbol definitions"
patch description, while the c operand modifier is documented to:
Require a constant operand and print the constant expression with no punctuation.
it actually doesn't do that with -fpic at least on some targets and
has been behaving that way for at least 3 decades.
It prints the operand using output_addr_const if CONSTANT_ADDRESS_P is true,
but CONSTANT_ADDRESS_P can do all sorts of target specific checks.
And if it is false, it falls back to output_operand (operands[opnum], 'c');
which will on various targets just result in an error that it is invalid
modifier letter (weird because it is documented), on others like x86 or
alpha will handle the operand in some weird way if it is a comparison
and otherwise complain the argument isn't a comparison, on others like
arm perhaps do what the user wanted.
As I wrote, we are pretty much out of modifier letters because some targets
use a lot of them, and almost out of % punctuation chars (I think ` is left)
but right now punctuation chars aren't normally followed by operand number
anyway.
So, the following patch takes one of the generic letters (c) and adds an
extra modifier char after it, I chose cc, which behaves like c but just
always uses output_addr_const instead of falling back to the machine
dependent code.
2024-12-18 Jakub Jelinek <jakub@redhat.com>
* final.cc (output_asm_insn): Add support for cc operand modifier.
* doc/extend.texi (Generic Operand Modifiers): Document cc operand
modifier.
* doc/md.texi (@samp{:} in constraint): Mention the cc operand
modifier and add small example.
* c-c++-common/toplevel-asm-4.c: Don't use -fno-pie option.
Use cc modifier instead of c.
(v, w): Add extern keyword.
* c-c++-common/toplevel-asm-6.c: New test.
Jakub Jelinek [Wed, 18 Dec 2024 10:44:36 +0000 (11:44 +0100)]
inline asm: Add new constraint for symbol definitions
The following patch on top of the PR41045 toplevel extended asm patch
allows marking inline asms (both toplevel and function-local, admittedly
it is less useful for the latter, so if you want, I can add restrictions)
as defining symbols, either functions or variables.
As most remaining constraint letters are used at least on some targets,
I'm using : as the new constraint. It is similar to "s" in that it
wants CONSTANT_P && !CONST_SCALAR_INT_P, but
1) it specially requires an address of a function or variable declaration,
so for functions the expected use is
void foo (void);
...
":" (foo)
or
":" (&foo)
and for variables (unless they are arrays)
extern int var;
...
":" (&var)
2) it makes no sense to say that either something is defined or it is
used in a register or something similar, so the patch diagnoses if
one attempts to mix it with other constraints; ":,:,:" is allowed
just because one could be using 3 alternatives in some other operand
3) unlike "s", the constraint doesn't check LEGITIMATE_PIC_OPERAND_P for
-fpic, even in -fpic one should be able to use it the same way
4) the cgraph portion needs to be really added later
5) and last but not least, I'm afraid %c0 print modifier isn't very
good for printing it; it works fine without -fpic/-fpie, but 'c'
modifier is handled as
if (CONSTANT_ADDRESS_P (operands[opnum]))
output_addr_const (asm_out_file, operands[opnum]);
else
output_operand (operands[opnum], 'c');
and because at least on some arches like x86 CONSTANT_ADDRESS_P
is redefined to do backend specific PIC mess, it will just
output_operand and likely just be rejected (on x86 with an error
that the argument is not a comparison)
Guess for x86 one can use %p0 instead.
But I'm afraid we are mostly out of generic modifiers,
and targetm.asm_out.print_operand_punct_valid_p seems to use most
of the punctuation characters as well.
I think ` is unused, but wonder if we want to use up the last
remaining letter that way, perhaps make %`<letter>0?
Or extend the existing generic modifiers, keep %c0 behave as it
does right now and make %cc0 be a 2 letter modifier which is
PIC friendly and prints using output_addr_const anything that can
be printed that way? A follow-up patch implements the %cc0 version.
Tamar Christina [Wed, 18 Dec 2024 09:02:46 +0000 (09:02 +0000)]
libstdc++: Add inline keyword to _M_locate
In GCC 12 there was a ~40% regression in the performance of hashmap->find.
This regression came about accidentally:
Before GCC 12 the find function was small enough that IPA would inline it even
though it wasn't marked inline. In GCC-12 an optimization was added to perform
a linear search when the entries in the hashmap are small.
This increased the size of the function enough that IPA would no longer inline.
Inlining had two benefits:
1. The return value is a reference. so it has to be returned and dereferenced
even though the search loop may have already dereference it.
2. The pattern is a hard pattern to track for branch predictors. This causes
a large number of branch misses if the value is immediately checked and
branched on. i.e. if (a != m.end()) which is a common pattern.
The patch fixes both these issues by adding the inline keyword to _M_locate
to allow the inliner to consider inlining again.
This and the other patches have been ran through serveral benchmarks where
the size, number of elements searched for and type (reference vs value) etc
were tested.
The change shows no statistical regression, but an average find improvement of
~27% and a range between ~10-60% improvements. A selection of the results:
Xi Ruoyao [Mon, 16 Dec 2024 12:43:03 +0000 (20:43 +0800)]
LoongArch: Add CRC expander to generate faster CRC
64-bit LoongArch has native CRC instructions for two specific
polynomials. For other polynomials or 32-bit, use the generic
table-based approach but optimize bit reversing.
gcc/ChangeLog:
* config/loongarch/loongarch.md (crc_rev<mode:SUBDI>si4): New
define_expand.
Xi Ruoyao [Mon, 2 Dec 2024 02:53:27 +0000 (10:53 +0800)]
LoongArch: Add bit reverse operations
LoongArch supports native bit reverse operation for QI, SI, DI, and for
HI we can expand it into a shift and a bit reverse in word_mode.
I was reluctant to add them because until PR50481 is fixed these
operations will be just useless. But now it turns out we can use them
to optimize the bit reversing CRC calculation if recognized by the
generic CRC pass. So add them in prepare for the next patch adding CRC
expanders.
gcc/ChangeLog:
* config/loongarch/loongarch.md (@rbit<mode:GPR>): New
define_insn template.
(rbitsi_extended): New define_insn.
(rbitqi): New define_insn.
(rbithi): New define_expand.
Lewis Hyatt [Wed, 18 Dec 2024 02:26:18 +0000 (21:26 -0500)]
c++: modules: Fix 32-bit overflow with 64-bit location_t [PR117970]
With the move to 64-bit location_t in r15-6016, I missed a spot in module.cc
where a location_t was still being stored in a 32-bit int. Fixed.
The xtreme-header* tests in modules.exp were still passing fine on lots of
architectures that were tested (x86-64, i686, aarch64, sparc, riscv64), but
the PR shows that they were failing in some particular risc-v multilib
configurations. They pass now.
gcc/cp/ChangeLog:
PR c++/117970
* module.cc (module_state::read_ordinary_maps): Change argument to
line_map_uint_t instead of unsigned int.
Inserting an empty range into a std::deque results in undefined calls to
either std::copy, std::copy_backward, std::move, or std::move_backward.
We call those algos with invalid arguments where the output range is the
same as the input range, e.g. std::copy(first, last, first) which
violates the preconditions for the algorithms.
This fix simply returns early if there's nothing to insert. Most callers
already ensure that we don't even call _M_range_insert_aux with an empty
range, but some callers don't. Rather than checking for n == 0 in each
of the callers, this just does the check once and uses __builtin_expect
to treat empty insertions as unlikely.
libstdc++-v3/ChangeLog:
PR libstdc++/118035
* include/bits/deque.tcc (_M_range_insert_aux): Return
immediately if inserting an empty range.
* testsuite/23_containers/deque/modifiers/insert/118035.cc: New
test.
Sandra Loosemore [Tue, 17 Dec 2024 15:19:36 +0000 (15:19 +0000)]
Documentation: Make OpenMP/OpenACC docs easier to find [PR26154]
PR c/26154 is one of our oldest documentation issues. The only
discussion of OpenMP support in the GCC manual is buried in the "C
Dialect Options" section, with nothing at all under "Extensions". The
Fortran manual does have separate sections for OpenMP and OpenACC
extensions so I have copy-edited/adapted that text for similar sections
in the GCC manual, as well as breaking out the OpenMP and OpenACC options
into their own section (they apply to all of C, C++, and Fortran).
I also updated the information about what versions of OpenMP and
OpenACC are supported and removed some redundant text from the Fortran
manual to prevent it from getting out of sync on future updates, and
inserted some cross-references to the new sections elsewhere.
gcc/ChangeLog
PR c/26154
* common.opt.urls: Regenerated.
* doc/extend.texi (C Extensions): Adjust menu for new sections.
(Attribute Syntax): Mention OpenMP directives.
(Pragmas): Mention OpenMP and OpenACC directives.
(OpenMP): New section.
(OpenACC): New section.
* doc/invoke.texi (Invoking GCC): Adjust menu for new section.
(Option Summary): Move OpenMP and OpenACC options to their own
category.
(C Dialect Options): Move documentation for -foffload, -fopenacc,
-fopenacc-dim, -fopenmp, -fopenmd-simd, and
-fopenmp-target-simd-clone to...
(OpenMP and OpenACC Options): ...this new section. Light
copy-editing of the option descriptions.
gcc/fortran/ChangeLog:
PR c/26154
* gfortran.texi (Standards): Remove redundant info about
OpenMP/OpenACC standard support.
(OpenMP): Copy-editing and update version info.
(OpenACC): Likewise.
* lang.opt.urls: Regenerated.
Richard Biener [Tue, 17 Dec 2024 10:23:02 +0000 (11:23 +0100)]
middle-end/118062 - bogus lowering of vector compares
The generic expand_vector_piecewise routine supports lowering of
a vector operation to vector operations of smaller size. When
computing the extract position from the larger vector it uses the
element size in bits of the original result vector to determine
the number of elements in the smaller vector. That is wrong when
lowering a compare as the vector element size of a bool vector
does not have to agree with that of the compare operand. The
following simplifies this, fixing the error.
Marek Polacek [Thu, 12 Dec 2024 19:56:07 +0000 (14:56 -0500)]
c++: ICE initializing array of aggrs [PR117985]
This crash started with my r12-7803 but I believe the problem lies
elsewhere.
build_vec_init has cleanup_flags whose purpose is -- if I grok this
correctly -- to avoid destructing an object multiple times. Let's
say we are initializing an array of A. Then we might end up in
a scenario similar to initlist-eh1.C:
try
{
call A::A in a loop
// #0
try
{
call a fn using the array
}
finally
{
// #1
call A::~A in a loop
}
}
catch
{
// #2
call A::~A in a loop
}
cleanup_flags makes us emit a statement like
D.3048 = 2;
at #0 to disable performing the cleanup at #2, since #1 will take
care of the destruction of the array.
But if we are not emitting the loop because we can use a constant
initializer (and use a single { a, b, ...}), we shouldn't generate
the statement resetting the iterator to its initial value. Otherwise
we crash in gimplify_var_or_parm_decl because it gets the stray decl
D.3048.
PR c++/117985
gcc/cp/ChangeLog:
* init.cc (build_vec_init): Pop CLEANUP_FLAGS if we're not
generating the loop.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-array23.C: New test.
* g++.dg/cpp0x/initlist-array24.C: New test.
Oliver Kozul [Tue, 17 Dec 2024 14:44:33 +0000 (07:44 -0700)]
[PATCH] RISC-V: optimization on checking certain bits set ((x & mask) == val)
The patch optimizes code generation for comparisons of the form
X & C1 == C2 by converting them to (X | ~C1) == (C2 | ~C1).
C1 is a constant that requires li and addi to be loaded,
while ~C1 requires a single lui instruction.
As the values of C1 and C2 are not visible within
the equality expression, a plus pattern is matched instead.
PR target/114087
gcc/ChangeLog:
* config/riscv/riscv.md (*lui_constraint<ANYI:mode>_and_to_or): New pattern
Yangyu Chen [Tue, 17 Dec 2024 14:41:05 +0000 (07:41 -0700)]
RISC-V: Remove svvptc from riscv-ext-bitmask.def
There should be no svvptc in the riscv-ext-bitmask.def file since it has
not yet been added to the RISC-V C API Specification or the Linux
hwprobe. And there is no need for userspace software to know that this
extension exists. So remove it from the riscv-ext-bitmask.def file.
Fixes: e4f4b2dc08 ("RISC-V: Minimal support for svvptc extension.") Signed-off-by: Yangyu Chen <cyy@cyyself.name>
gcc/ChangeLog:
Kito Cheng [Mon, 9 Dec 2024 06:55:20 +0000 (14:55 +0800)]
RISC-V: Add new constraint R for register even-odd pairs
Although this constraint is not currently used for any instructions, it is very
useful for custom instructions. Additionally, some new standard extensions
(not yet upstream), such as `Zilsd` and `Zclsd`, are potential users of this
constraint. Therefore, I believe there is sufficient justification to add it
now.
gcc/ChangeLog:
* config/riscv/constraints.md (R): New constraint.
* doc/md.texi: Document new constraint `R`.
Kito Cheng [Thu, 14 Nov 2024 09:24:45 +0000 (17:24 +0800)]
RISC-V: Implment N modifier for printing the register number rather than the register name
The modifier `N`, to print the raw encoding of a register. This is used
when using `.insn <length>, <encoding>`, where the user wants to pass
a value to the instruction in a known register, but where the
instruction doesn't follow the existing instruction formats, so the
assembly parser is not expecting a register name, just a raw integer.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_print_operand): Add N.
* doc/extend.texi: Document for N,
Martin Jambor [Tue, 17 Dec 2024 10:17:14 +0000 (11:17 +0100)]
ipa: Improve how we derive value ranges from IPA invariants
I believe that the current function ipa_range_set_and_normalize lacks
a check that a base of an ADDR_EXPR lacks a test whether the base
really cannot be NULL, so this patch adds it. Moreover, I never liked
the name as I do not think it makes the value of ranges any more
normal but rather just special-cases non-zero ip_invariant pointers.
Therefore, I have given it a different name and moved it to a .cc
file, our LTO bootstrap should inline (and/or split) it if necessary
anyway.
Because, as Honza correctly pointed out, deriving non-NULLness from a
pointer depends on flag_delete_null_pointer_checks which is an
optimization flag and thus depends on a given function, in this
version of the patch ipa_get_range_from_ip_invariant gets a
context_node parameter for that purpose. This then needs to be used
within symtab_node::nonzero_address which gets a special overload in
which the value of the flag can be provided as a parameter.
gcc/ChangeLog:
2024-12-11 Martin Jambor <mjambor@suse.cz>
* cgraph.h (symtab_node): Add a new overload of nonzero_address.
* symtab.cc (symtab_node::nonzero_address): Add a new overload whith a
parameter for delete_null_pointer_checks. Make the original overload
call the new one which has retains the actual implementation.
* ipa-prop.h (ipa_get_range_from_ip_invariant): Declare.
(ipa_range_set_and_normalize): Remove.
* ipa-prop.cc (ipa_get_range_from_ip_invariant): New function.
(ipa_range_set_and_normalize): Remove.
* ipa-cp.cc (ipa_vr_intersect_with_arith_jfunc): Add a new parameter
context_node. Use ipa_get_range_from_ip_invariant instead of
ipa_range_set_and_normalize and pass to it the new parameter.
(ipa_value_range_from_jfunc): Pass cs->caller as the context_node to
ipa_vr_intersect_with_arith_jfunc.
(propagate_vr_across_jump_function): Likewise.
(ipa_get_range_from_ip_invariant): New function.
* ipa-fnsummary.cc (evaluate_conditions_for_known_args): Use
ipa_get_range_from_ip_invariant instead of ipa_range_set_and_normalize
Martin Jambor [Tue, 17 Dec 2024 10:17:14 +0000 (11:17 +0100)]
ipa: Better value ranges for pointer integer constants
When looking into cases where we know an actual argument of a call is
a constant but we don't generate a singleton value-range for the jump
function, I found out that the special handling of pointer constants
does not work well for constant zero pointer values. In fact the code
only attempts to see if it can figure out that an argument is not zero
and if it can figure out any alignment information.
With this patch, we try to use the value_range that ranger can give us
in the jump function if we can and we query ranger for all kinds of
arguments, not just SSA_NAMES (and so also pointer integer constants).
If we cannot figure out a useful range we fall back again on figuring
out non-NULLness with tree_single_nonzero_warnv_p.
With this patch, we generate
[prange] struct S * [0, 0] MASK 0x0 VALUE 0x0
instead of for example:
[prange] struct S * [0, +INF] MASK 0xfffffffffffffff0 VALUE 0x0
for a zero constant passed in a call.
If you are wondering why we check whether the value range obtained
from range_of_expr can be undefined, even when the function returns
true, that is because that can apparently happen fro default-definition
SSA_NAMEs.
gcc/ChangeLog:
2024-11-15 Martin Jambor <mjambor@suse.cz>
* ipa-prop.cc (ipa_compute_jump_functions_for_edge): Try harder to
use the value range obtained from ranger for pointer values.
Martin Jambor [Tue, 17 Dec 2024 10:17:14 +0000 (11:17 +0100)]
ipa: Skip widening type conversions in jump function constructions
Originally, we did not stream any formal parameter types into WPA and
were generally very conservative when it came to type mismatches in
IPA-CP. Over the time, mismatches that happen in code and blew up in
WPA made us to be much more resilient and also to stream the types of
the parameters which we now use commonly.
With that information, we can safely skip conversions when looking at
the IL from which we build jump functions and then simply fold convert
the constants and ranges to the resulting type, as long as we are
careful that performing the corresponding folding of constants gives
the corresponding results. In order to do that, we must ensure that
the old value can be represented in the new one without any loss.
With this change, we can nicely propagate non-NULLness in IPA-VR as
demonstrated with the new test case.
I have gone through all other uses of (all components of) jump
functions which could be affected by this and verified they do indeed
check types and can handle mismatches.
gcc/ChangeLog:
2024-12-11 Martin Jambor <mjambor@suse.cz>
* ipa-prop.cc: Include vr-values.h.
(skip_a_safe_conversion_op): New function.
(ipa_compute_jump_functions_for_edge): Use it.
Jakub Jelinek [Tue, 17 Dec 2024 09:13:24 +0000 (10:13 +0100)]
c++: Diagnose earlier non-static data members with cv containing class type [PR116108]
In r10-6457 aka PR92593 fix a check has been added to reject
earlier non-static data members with current_class_type in templates,
as the deduction then can result in endless recursion in reshape_init.
It fixed the
template <class T>
struct S { S s = 1; };
S t{2};
crashes, but as the following testcase shows, didn't catch when there
are cv qualifiers on the non-static data member.
Fixed by using TYPE_MAIN_VARIANT.
2024-12-17 Jakub Jelinek <jakub@redhat.com>
PR c++/116108
gcc/cp/
* decl.cc (grokdeclarator): Pass TYYPE_MAIN_VARIANT (type)
rather than type to same_type_p when checking if the non-static
data member doesn't have current class type.
gcc/testsuite/
* g++.dg/cpp1z/class-deduction117.C: New test.
testsuite: Force max-completely-peeled-insns=300 for CRIS, PR118055
This handles fallout from r15-6097-gee2f19b0937b5e. A brief
analysis shows that the metric used in that code is computed
by estimate_move_cost, differentiating on the target macro
MOVE_MAX_PIECES (which defaults to MOVE_MAX) which for most
"32-bit targets" is 4 and for "64-bit targets" is 8. There
are some outliers, like pru, with MOVE_MAX set to 8 but
counting as a 32-bit target.
So, the main difference for this test-case, which is heavy
on 64-bit moves (most targets have "double" mapped to IEEE
64-bit), is between "32-bit" and "64-bit", with the cost up
to twice for the former compared to the latter. I see no
effective_target_move_max_is_4 or equivalent, and this
instance falls below the threshold of adding one, so I'm
sticking to a list of targets. For CRIS, it would suffice
with 210, but there's no need to be this specific, and it
would make the test even more brittle.
David Malcolm [Mon, 16 Dec 2024 16:22:50 +0000 (11:22 -0500)]
sarif-replay: handle embedded links (§3.11.6)
Handle embedded links in plain text messages. For now, merely
use the link text and discard the destination.
gcc/ChangeLog:
* libsarifreplay.cc (struct embedded_link): New.
(maybe_consume_embedded_link): New.
(sarif_replayer::make_plain_text_within_result_message): Handle
embedded links by using the link text, for now.
gcc/testsuite/ChangeLog:
* sarif-replay.dg/2.1.0-valid/3.11.6-embedded-links.sarif: New test.
* sarif-replay.dg/2.1.0-valid/malloc-vs-local-4.c.sarif: Update
expected output for handling the embedded links.
* sarif-replay.dg/2.1.0-valid/spec-example-4.sarif: Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Mon, 16 Dec 2024 16:22:50 +0000 (11:22 -0500)]
libgdiagnostics: consolidate logical locations
This patch updates diagnostic_manager_new_logical_location so
that repeated calls with the same input values yield the same
instance of diagnostic_logical_location.
Doing so allows the path-printing logic to properly consolidate runs of
events, whereas previously it could treat each event as having a
distinct logical location, and thus require them to be printed
separately; this greatly improves the output of sarif-replay when
displaying execution paths.
gcc/ChangeLog:
* doc/libgdiagnostics/topics/logical-locations.rst
(diagnostic_manager_new_logical_location): Add note about repeated
calls.
* libgdiagnostics.cc: Define INCLUDE_MAP.
(class owned_nullable_string): Add copy ctor and move ctor.
(owned_nullable_string::operator<): New.
(diagnostic_logical_location::operator<): New.
(diagnostic_manager::new_logical_location): Use m_logical_locs to
"uniquify" instances, converting it to a std::map.
(diagnostic_manager::logical_locs_map_t): New typedef.
(diagnostic_manager::t m_logical_locs): Convert from a std::vector
to a std::map.
(diagnostic_execution_path::same_function_p): Update comment.
gcc/testsuite/ChangeLog:
* libgdiagnostics.dg/test-logical-location.c: Include <assert.h>.
Verify that creating a diagnostic_logical_location with equal
values yields the same instance.
* sarif-replay.dg/2.1.0-valid/malloc-vs-local-4.c.sarif: New test.
* sarif-replay.dg/2.1.0-valid/signal-1.c.moved.sarif: Update
expected output to show logical location and for consolidation of
events into runs.
* sarif-replay.dg/2.1.0-valid/signal-1.c.sarif: Likewise.
* sarif-replay.dg/2.1.0-valid/spec-example-4.sarif: Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Mon, 16 Dec 2024 16:22:49 +0000 (11:22 -0500)]
sarif-replay: quote source from artifact contents [PR117943]
The diagnostic source-quoting machinery uses class file_cache
implemented in gcc/input.cc for (re)reading the source when
issuing diagnostics.
When sarif-replay issues a saved diagnostic it might be running
in a different path to where the .sarif file was captured, or
on an entirely different machine.
Previously such invocations would lead to the source-quoting
silently failing, even if the content of the file is recorded
in the .sarif file in the artifact "contents" property (which
gcc populates when emitting .sarif output).
This patch:
- adds the ability for slots in file_cache to be populated from memory
rather than from the filesystem
- exposes it in libgdiagnostics via a new entrypoint
- uses this in sarif-replay for any artifacts with a "contents"
property, so that source-quoting uses that rather than trying to read
from the path on the filesystem
gcc/ChangeLog:
PR sarif-replay/117943
* doc/libgdiagnostics/topics/physical-locations.rst
(diagnostic_manager_new_file): Drop "const" from return type.
* doc/libgdiagnostics/tutorial/02-physical-locations.rst: Drop
"const" from "main_file" decl.
* input.cc (file_cache::add_buffered_content): New.
(file_cache_slot::set_content): New.
(file_cache_slot::dump): Use m_file_path being null rather than
m_fp to determine empty slots. Dump m_fp.
(find_end_of_line): Drop "const" from return type and param. Add
forward decl.
(file_cache_slot::get_next_line): Fix "const"-ness.
(selftest::test_reading_source_buffer): New.
(selftest::input_cc_tests): Call it.
* input.h (file_cache::add_buffered_content): New decl.
* libgdiagnostics++.h (class file): Drop const-ness from m_inner.
(file::set_buffered_content): New.
* libgdiagnostics.cc (class content_buffer): New.
(diagnostic_file::diagnostic_file): Add "mgr" param.
(diagnostic_file::get_content): New.
(diagnostic_file::set_buffered_content): New.
(diagnostic_file::m_mgr): New.
(diagnostic_file::m_content): New.
(diagnostic_manager::new_file): Drop const-ness. Pass *this to
ctor.
(diagnostic_file::set_buffered_content): New.
(diagnostic_manager_new_file): Drop "const" from return type.
(diagnostic_file_set_buffered_content): New entrypoint.
(diagnostic_manager_debug_dump_file): Dump the content size,
if any.
* libgdiagnostics.h (diagnostic_manager_new_file): Drop "const"
from return type.
(diagnostic_file_set_buffered_content): New decl.
* libgdiagnostics.map (diagnostic_file_set_buffered_content): New
symbol.
* libsarifreplay.cc (sarif_replayer::m_artifacts_arr): Convert
from json::value to json::array.
(sarif_replayer::handle_run_obj): Call handle_artifact_obj
on all artifacts.
(sarif_replayer::handle_artifact_obj): New.
gcc/testsuite/ChangeLog:
PR sarif-replay/117943
* sarif-replay.dg/2.1.0-valid/error-with-note.sarif: Update
expected output to include quoted source code and underlines.
* sarif-replay.dg/2.1.0-valid/signal-1.c.moved.sarif: New test.
* sarif-replay.dg/2.1.0-valid/signal-1.c.sarif: Update expected
output to include quoted source code and underlines.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Mon, 16 Dec 2024 16:22:49 +0000 (11:22 -0500)]
diagnostics: move libgdiagnostics dc from sinks into diagnostic_manager
libgdiagnostics was written before the fixes for PR other/116613 allowed
a diagnostic_context to have multiple output sinks.
Hence each libgdiagnostics sink had its own diagnostic_context with just
one diagnostic_output_format.
This wart is no longer necessary and makes it harder to move state
into the manager/context; in particular for quoting source code
from the .sarif file (PR sarif-replay/117943).
Simplify, by making libgdiagnostics' implementation more similar to
GCC's implementation, by moving the diagnostic_context from sink into
diagnostic_manager.
Doing so requires generalizing where the
diagnostic_source_printing_options comes from in class
diagnostic_text_output_format: for GCC we use
the instance within the diagnostic_context, whereas for
libgdiagnostics each diagnostic_text_sink has its own instance.
No functional change intended.
gcc/c-family/ChangeLog:
PR sarif-replay/117943
* c-format.cc (selftest::test_type_mismatch_range_labels): Use
dc.m_source_printing.
* c-opts.cc (c_diagnostic_text_finalizer): Use source-printing
options from text_output.
gcc/cp/ChangeLog:
PR sarif-replay/117943
* error.cc (auto_context_line::~auto_context_line): Use
source-printing options from text_output.
gcc/ChangeLog:
PR sarif-replay/117943
* diagnostic-format-text.cc
(diagnostic_text_output_format::append_note): Use source-printing
options from text_output.
(diagnostic_text_output_format::update_printer): Copy
source-printing options from dc.
(default_diagnostic_text_finalizer): Use source-printing
options from text_output.
* diagnostic-format-text.h
(diagnostic_text_output_format::diagnostic_text_output_format):
Add optional diagnostic_source_printing_options param, using
the context's if null.
(diagnostic_text_output_format::get_source_printing_options): New
accessor.
(diagnostic_text_output_format::m_source_printing): New field.
* diagnostic-path.cc (event_range::print): Use source-printing
options from text_output.
(selftest::test_interprocedural_path_1): Use source-printing
options from dc.
* diagnostic-show-locus.cc
(gcc_rich_location::add_location_if_nearby): Likewise.
(diagnostic_context::maybe_show_locus): Add "opts" param
and use in place of m_source_printing. Pass it to source_policy
ctor.
(diagnostic_source_print_policy::diagnostic_source_print_policy):
Add overload taking a const diagnostic_source_printing_options &.
* diagnostic.cc (diagnostic_context::initialize): Pass nullptr
for source options when creating text sink, so that it uses
the dc's options.
(diagnostic_context::dump): Add an "output sinks:" heading and
print "(none)" if there aren't any.
(diagnostic_context::set_output_format): Split out code into...
(diagnostic_context::remove_all_output_sinks): ...this new
function.
* diagnostic.h
(diagnostic_source_print_policy::diagnostic_source_print_policy):
Add overload taking a const diagnostic_source_printing_options &.
(diagnostic_context::maybe_show_locus): Add "opts" param.
(diagnostic_context::remove_all_output_sinks): New decl.
(diagnostic_context::m_source_printing): New field.
(diagnostic_show_locus): Add "opts" param and pass to
maybe_show_locus.
* libgdiagnostics.cc (sink::~sink): Delete.
(sink::begin_group): Delete.
(sink::end_group): Delete.
(sink::emit): Delete.
(sink::m_dc): Drop field.
(diagnostic_text_sink::on_begin_text_diagnostic): Delete.
(diagnostic_text_sink::get_source_printing_options): Use
m_souece_printing.
(diagnostic_text_sink::m_current_logical_loc): Drop field.
(diagnostic_text_sink::m_inner_sink): New field.
(diagnostic_text_sink::m_source_printing): New field.
(diagnostic_manager::diagnostic_manager): Update for changes
to fields. Initialize m_dc.
(diagnostic_manager::~diagnostic_manager): Call diagnostic_finish.
(diagnostic_manager::get_file_cache): Drop.
(diagnostic_manager::get_dc): New accessor.
(diagnostic_manager::begin_group): Reimplement.
(diagnostic_manager::end_group): Reimplement.
(diagnostic_manager::get_prev_diag_logical_loc): New accessor.
(diagnostic_manager::m_dc): New field.
(diagnostic_manager::m_file_cache): Drop field.
(diagnostic_manager::m_edit_context): Convert to a std::unique_ptr
so that object can be constructed after m_dc is initialized.
(diagnostic_manager::m_prev_diag_logical_loc): New field.
(diagnostic_text_sink::diagnostic_text_sink): Reimplement.
(get_color_rule): Delete.
(diagnostic_text_sink::set_colorize): Reimplement.
(diagnostic_text_sink::text_starter): New.
(sarif_sink::sarif_sink): Reimplement.
(diagnostic_manager::write_patch): Update for change to
m_edit_context.
(diagnostic_manager::emit): Update now that each sink has a
corresponding diagnostic_output_format object within m_dc.
gcc/fortran/ChangeLog:
PR sarif-replay/117943
* error.cc (gfc_diagnostic_text_starter): Use source-printing
options from text_output.
gcc/testsuite/ChangeLog:
PR sarif-replay/117943
* gcc.dg/plugin/diagnostic_plugin_test_show_locus.cc
(custom_diagnostic_text_finalizer): Use source-printing options
from text_output.
* gcc.dg/plugin/diagnostic_plugin_xhtml_format.cc
(xhtml_builder::make_element_for_diagnostic): Use source-printing
options from diagnostic_context.
* gcc.dg/plugin/expensive_selftests_plugin.cc (test_richloc):
Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Dimitar Dimitrov [Mon, 16 Dec 2024 15:27:53 +0000 (17:27 +0200)]
testsuite: Require int32plus target for gcc.dg/pr117816.c
Memmove destination overflows if size of int is less than 3, resulting in
spurious test failures. Fix by adding a requirement for effective
target int32plus.
Robin Dapp [Fri, 6 Sep 2024 14:04:03 +0000 (16:04 +0200)]
vect: Do not try to duplicate_and_interleave one-element mode.
PR112694 shows that we try to create sub-vectors of single-element
vectors because can_duplicate_and_interleave_p returns true.
The problem resurfaced in PR116611.
This patch makes can_duplicate_and_interleave_p return false
if count / nvectors > 0 and removes the corresponding check in the riscv
backend.
This partially gets rid of the FAIL in slp-19a.c. At least when built
with cost model we don't have LOAD_LANES anymore. Without cost model,
as in the test suite, we choose a different path and still end up with
LOAD_LANES.
Bootstrapped and regtested on x86 and power10, regtested on
rv64gcv_zvfh_zvbb. Still waiting for the aarch64 results.
Regards
Robin
gcc/ChangeLog:
PR target/112694
PR target/116611.
* config/riscv/riscv-v.cc (expand_vec_perm_const): Remove early
return.
* tree-vect-slp.cc (can_duplicate_and_interleave_p): Return
false when we cannot create sub-elements.
Robin Dapp [Fri, 13 Dec 2024 10:23:03 +0000 (11:23 +0100)]
RISC-V: Increase cost for vec_construct [PR118019].
For a generic vec_construct from scalar elements we need to load each
scalar element and move it over to a vector register.
Right now we only use a cost of 1 per element.
This patch uses register-move cost as well as scalar_to_vec and
multiplies it with the number of elements in the vector instead.
Jonathan Wakely [Thu, 12 Dec 2024 20:42:19 +0000 (20:42 +0000)]
libstdc++: Initialize all members of hashtable local iterators
Currently the _M_bucket members are left uninitialized for
default-initialized local iterators, and then copy construction copies
indeterminate values. We should just ensure they're initialized on
construction.
Setting them to zero makes default-initialization consistent with
value-initialization and avoids indeterminate values.
For the _Local_iterator_base<..., false> specialization we preserve the
existing behaviour of setting _M_bucket_count to -1 in the default
constructor, as a sentinel value to indicate there's no hash object
present.
libstdc++-v3/ChangeLog:
* include/bits/hashtable_policy.h (_Local_iterator_base): Use
default member-initializers.
Jonathan Wakely [Thu, 12 Dec 2024 20:40:15 +0000 (20:40 +0000)]
libstdc++: Use alias-declarations in bits/hashtable_policy,h
This file is only for C++11 and later, so replace typedefs with
alias-declarations for clarity. Also remove redundant std::
qualification on size_t, ptrdiff_t etc.
We can also remove the result_type, first_argument_type and
second_argument_type typedefs from the range hashers. We don't need
those types to follow the C++98 adaptable function object protocol.
libstdc++-v3/ChangeLog:
* include/bits/hashtable_policy.h: Replace typedefs with
alias-declarations. Remove redundant std:: qualification.
(_Mod_range_hashing, _Mask_range_hashing): Remove adaptable
function object typedefs.
Jonathan Wakely [Thu, 5 Dec 2024 15:48:30 +0000 (15:48 +0000)]
libstdc++: Simplify storage of hasher in local iterators
The fix for PR libstdc++/56267 (relating to the lifetime of the hash
object stored in a local iterator) has undefined behaviour, as it relies
on being able to call a member function on an empty object that never
started its lifetime. Although the member function probably doesn't care
about the empty object's state, this is still technically undefined
because there is no object of that type at that address. It's also
possible that the hash object would have a stricter alignment than the
_Hash_code_storage object, so that the reinterpret_cast would produce a
misaligned pointer.
This fix replaces _Local_iterator_base's _Hash_code_storage base-class
with a new class template containing a potentially-overlapping (i.e.
[[no_unique_address]]) union member. This means that we always have
storage of the correct type, and it can be initialized/destroyed when
required. We no longer need a reinterpret_cast that gives us a pointer
that we should not dereference.
It would be nice if we could just use a union containing the _Hash
object as a data member of _Local_iterator_base, but that would be an
ABI change. The _Hash_code_storage that contains the _Hash object is the
first base-class, before the _Node_iterator_base base-class. Making the
union a data member of _Local_iterator_base would make it come after the
_Node_iterator_base base instead of before it, altering the layout.
Since we're changing _Hash_code_storage anyway, we can replace it with a
new class template that stores the _Hash object itself in the union,
rather than a _Hash_code_base that holds the _Hash. This removes an
unnecessary level of indirection in the class hierarchy. This change
requires the effects of _Hash_code_base::_M_bucket_index to be inlined
into the _Local_iterator_base::_M_incr function, but that's easy.
We don't need separate specializations of _Hash_obj_storage for an empty
hash function and a non-empty one. Using [[no_unique_address]] gives us
an empty base-class when possible.
libstdc++-v3/ChangeLog:
* include/bits/hashtable_policy.h (_Hash_code_storage): Remove.
(_Hash_obj_storage): New class template. Store the hash
function as a union member instead of using a byte buffer.
(_Local_iterator_base): Use _Hash_obj_storage instead of
_Hash_code_storage, adjust members that construct and destroy
the hash object.
(_Local_iterator_base::_M_incr): Calculate bucket index.
Jonathan Wakely [Wed, 4 Dec 2024 21:52:40 +0000 (21:52 +0000)]
libstdc++: Further simplify _Hashtable inheritance hierarchy
The main change here is using [[no_unique_address]] instead of the Empty
Base-class Optimization. Using the attribute allows us to use data
members instead of base-classes. That simplifies the inheritance
hierarchy, which means less work for the compiler. It also means that
ADL has fewer associated classes and associated namespaces to consider,
further reducing the work the compiler has to do.
Reducing the differences between the _Hashtable_ebo_helper primary
template and the partial specialization means we no longer need to use
member functions to access the stored object, because it's now always a
data member called _M_obj. This means we can also remove a number of
other helper functions that were using those member functions to access
the object, for example we can swap the _Hash and _Equal objects
directly in _Hashtable::swap instead of calling _Hashtable_base::_M_swap
which then calls _Hash_code_base::_M_swap.
Although [[no_unique_address]] would allow us to reduce the size for
empty types that are also 'final', doing so would be an ABI break
because those types were previously excluded from using the EBO. So we
still need the _Hashtable_ebo_helper class template and a partial
specialization, so that we only use the attribute under exactly the same
conditions as we previously used the EBO. This could be avoided with a
non-standard [[no_unique_address(expr)]] attribute that took a boolean
condition, or with reflection and token sequence injection, but we don't
have either of those things.
Because _Hashtable_ebo_helper is no longer used as a base-class we don't
need to disambiguate possible identical bases, so it doesn't need an
integral non-type template parameter.
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h (_Hashtable::swap): Swap hash
function and equality predicate here. Inline allocator swap
instead of using __alloc_on_swap.
* include/bits/hashtable_policy.h (_Hashtable_ebo_helper):
Replace EBO with no_unique_address attribute. Remove NTTP.
(_Hash_code_base): Replace base class with data member using
no_unique_address attribute.
(_Hash_code_base::_M_swap): Remove.
(_Hash_code_base::_M_hash): Remove.
(_Hashtable_base): Replace base class with data member using
no_unique_address attribute.
(_Hashtable_base::_M_swap): Remove.
(_Hashtable_alloc): Replace base class with data member using
no_unique_address attribute.
Jonathan Wakely [Sun, 8 Dec 2024 14:34:01 +0000 (14:34 +0000)]
libstdc++: Fix fancy pointer support in linked lists [PR57272]
The union members I used in the new _Node types for fancy pointers only
work for value types that are trivially default constructible. This
change replaces the anonymous union with a named union so it can be
given a default constructor and destructor, to leave the variant member
uninitialized.
This also fixes the incorrect macro names in the alloc_ptr_ignored.cc
tests as pointed out by François, and fixes some std::list pointer
confusions that the fixed alloc_ptr_ignored.cc test revealed.
libstdc++-v3/ChangeLog:
PR libstdc++/57272
* include/bits/forward_list.h (__fwd_list::_Node): Add
user-provided special member functions to union.
* include/bits/stl_list.h (__list::_Node): Likewise.
(_Node_base::_M_hook, _Node_base::swap): Use _M_base() instead
of std::pointer_traits::pointer_to.
(_Node_base::_M_transfer): Likewise. Add noexcept.
(_List_base::_M_put_node): Use 'if constexpr' to avoid using
pointer_traits::pointer_to when not necessary.
(_List_base::_M_destroy_node): Fix parameter to be the pointer
type used internally, not the allocator's pointer.
(list::_M_create_node): Likewise.
* testsuite/23_containers/forward_list/requirements/explicit_instantiation/alloc_ptr.cc:
Check explicit instantiation of non-trivial value type.
* testsuite/23_containers/list/requirements/explicit_instantiation/alloc_ptr.cc:
Likewise.
* testsuite/23_containers/forward_list/requirements/explicit_instantiation/alloc_ptr_ignored.cc:
Fix macro name.
* testsuite/23_containers/list/requirements/explicit_instantiation/alloc_ptr_ignored.cc:
Likewise.
Mark Harmstone [Sat, 30 Nov 2024 22:35:24 +0000 (22:35 +0000)]
Fix non-aligned CodeView symbols
CodeView symbols in PDB files are aligned to four-byte boundaries. It's
not really clear what logic MSVC uses to enforce this; sometimes the
symbols are padded in the object file, sometimes the linker seems to do
the work.
It makes more sense to do this in the compiler, so fix the two instances
where we can write symbols with a non-aligned length. S_FRAMEPROC is
unusually not a multiple of 4, so will always have 2 bytes padding.
S_INLINESITE is followed by variable-length "binary annotations", so
will also usually have padding.
If a function receives nonlocal gotos, it needs to save the frame
pointer in the argument save area. This ensures that LRA sets
frame_pointer_needed when it saves arguments in the save area.
2024-12-15 John David Anglin <danglin@gcc.gnu.org>
gcc/ChangeLog:
PR target/118018
* config/pa/pa.cc (pa_frame_pointer_required): Declare and
implement.
(TARGET_FRAME_POINTER_REQUIRED): Define.
Iain Sandoe [Thu, 3 Oct 2024 08:02:59 +0000 (09:02 +0100)]
c++, coroutines: Make the resume index consistent for debug.
At present, we only update the resume index when we actually are
at the stage that the coroutine is considered suspended. This is
on the basis that it is UB to resume or destroy a coroutines that
is not suspended (and therefore we never need to access this value
otherwise). However, it is possible that someone could set a debug
breakpoint on the resume which can be reached without suspending
if await_ready() returns true. In that case, the debugger would
read an incorrect resume index. Fixed by moving the update to
just before the test for ready.
gcc/cp/ChangeLog:
* coroutines.cc (expand_one_await_expression): Update the
resume index before checking if the coroutine is ready.
Iain Sandoe [Fri, 1 Nov 2024 23:30:58 +0000 (23:30 +0000)]
c++, coroutines:Ensure bind exprs are visited once [PR98935].
Recent changes in the C++ FE and the coroutines implementation have
exposed a latent issue in which a bind expression containing a var
that we need to capture in the coroutine state gets visited twice.
This causes an ICE (from a checking assert). Fixed by adding a pset
to the relevant tree walk. Exit the callback early when the tree is
not a BIND_EXPR.
PR c++/98935
gcc/cp/ChangeLog:
* coroutines.cc (register_local_var_uses): Add a pset to the
tree walk to avoid visiting the same BIND_EXPR twice. Make
an early exit for cases that the callback does not apply.
(cp_coroutine_transform::apply_transforms): Add a pset to the
tree walk for register_local_vars.
Tamar Christina [Sun, 15 Dec 2024 13:21:44 +0000 (13:21 +0000)]
arm: fix bootstrap after MVE changes
The recent commits for MVE on Saturday have broken armhf bootstrap due to a
-Werror false positive:
inlined from 'virtual rtx_def* {anonymous}::vstrq_scatter_base_impl::expand(arm_mve::function_expander&) const' at /gcc/config/arm/arm-mve-builtins-base.cc:352:17:
./genrtl.h:38:16: error: 'new_base' may be used uninitialized [-Werror=maybe-uninitialized]
38 | XEXP (rt, 1) = arg1;
/gcc/config/arm/arm-mve-builtins-base.cc: In member function 'virtual rtx_def* {anonymous}::vstrq_scatter_base_impl::expand(arm_mve::function_expander&) const':
/gcc/config/arm/arm-mve-builtins-base.cc:311:26: note: 'new_base' was declared here
311 | rtx insns, base_ptr, new_base;
| ^~~~~~~~
In function 'rtx_def* init_rtx_fmt_ee(rtx, machine_mode, rtx, rtx)',
inlined from 'rtx_def* gen_rtx_fmt_ee_stat(rtx_code, machine_mode, rtx, rtx)' at ./genrtl.h:50:26,
inlined from 'virtual rtx_def* {anonymous}::vldrq_gather_base_impl::expand(arm_mve::function_expander&) const' at /gcc/config/arm/arm-mve-builtins-base.cc:527:17:
./genrtl.h:38:16: error: 'new_base' may be used uninitialized [-Werror=maybe-uninitialized]
38 | XEXP (rt, 1) = arg1;
/gcc/config/arm/arm-mve-builtins-base.cc: In member function 'virtual rtx_def* {anonymous}::vldrq_gather_base_impl::expand(arm_mve::function_expander&) const':
/gcc/config/arm/arm-mve-builtins-base.cc:486:26: note: 'new_base' was declared here
486 | rtx insns, base_ptr, new_base;
Jakub Jelinek [Sun, 15 Dec 2024 12:13:07 +0000 (13:13 +0100)]
Shrink back size of tree_exp from 40 bytes to 32
The following patch implements what I've mentioned in the 64-bit
location_t thread.
struct tree_exp had unsigned condition_uid member added for something
rarely used (-fcondition-coverage) and even there used only on very small
subset of trees only for the duration of the gimplification.
The following patch uses a hash_map instead, which allows shrinking
tree_exp to its previous size (32 bytes + (number of operands - 1) * sizeof
(tree)).
2024-12-15 Jakub Jelinek <jakub@redhat.com>
* tree-core.h (struct tree_exp): Remove condition_uid member.
* tree.h (SET_EXPR_UID, EXPR_COND_UID): Remove.
* gimplify.cc (nextuid): Rename to ...
(nextconduid): ... this.
(cond_uids): New static variable.
(next_cond_uid, reset_cond_uid): Adjust for the renaming,
formatting fix.
(tree_associate_condition_with_expr): New function.
(shortcut_cond_r, tag_shortcut_cond, shortcut_cond_expr): Use it
instead of SET_EXPR_UID.
(gimplify_cond_expr): Look up cond_uid in cond_uids hash map if
non-NULL instead of using EXPR_COND_UID.
(gimplify_function_tree): Delete cond_uids and set it to NULL.
Jovan Vukic [Sat, 14 Dec 2024 21:47:35 +0000 (14:47 -0700)]
[PATCH v3] match.pd: Add pattern to simplify `(a - 1) & -a` to `0`
Thank you for the feedback. I have made the minor changes that were requested.
Additionally, I extracted the repetitive code into a reusable helper function,
match_plus_neg_pattern, making the code much more readable. Furthermore, the
logic, code, and tests remain the same as in version 2 of the patch.
gcc/ChangeLog:
* match.pd: New pattern.
* simplify-rtx.cc (match_plus_neg_pattern): New helper function.
(simplify_context::simplify_binary_operation_1): New
code to handle (a - 1) & -a, (a - 1) | -a and (a - 1) ^ -a.
Jakub Jelinek [Sat, 14 Dec 2024 10:28:25 +0000 (11:28 +0100)]
gimple-fold: Fix the recent ifcombine optimization for _BitInt [PR118023]
The BIT_FIELD_REF verifier has:
if (INTEGRAL_TYPE_P (TREE_TYPE (op))
&& !type_has_mode_precision_p (TREE_TYPE (op)))
{
error ("%qs of non-mode-precision operand", code_name);
return true;
}
check among other things, so one can't extract something out of say
_BitInt(63) or _BitInt(4096).
The new ifcombine optimization happily creates such BIT_FIELD_REFs
and ICEs during their verification.
The following patch fixes that by rejecting those in decode_field_reference.
2024-12-14 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/118023
* gimple-fold.cc (decode_field_reference): Return NULL_TREE if
inner has non-type_has_mode_precision_p integral type.
Jakub Jelinek [Sat, 14 Dec 2024 10:27:20 +0000 (11:27 +0100)]
warn-access: Fix up matching_alloc_calls_p [PR118024]
The following testcase ICEs because of a bug in matching_alloc_calls_p.
The loop was apparently meant to be walking the two attribute chains
in lock-step, but doesn't really do that. If the first lookup_attribute
returns non-NULL, the second one is not done, so rmats in that case can
be some random unrelated attribute rather than "malloc" attribute; the
body assumes even rmats if non-NULL is "malloc" attribute and relies
on its argument to be a "malloc" argument and if it is some other
attribute with incompatible attribute, it just crashes.
Now, fixing that in the obvious way, instead of doing
(amats = lookup_attribute ("malloc", amats))
|| (rmats = lookup_attribute ("malloc", rmats))
in the condition do
((amats = lookup_attribute ("malloc", amats)),
(rmats = lookup_attribute ("malloc", rmats)),
(amats || rmats))
fixes the testcase but regresses Wmismatched-dealloc-{2,3}.c tests.
The problem is that walking the attribute lists in a lock-step is obviously
a very bad idea, there is no requirement that the same deallocators are
present in the same order on both decls, e.g. there could be an extra malloc
attribute without argument in just one of the lists, or the order of say
free/realloc could be swapped, etc. We don't generally document nor enforce
any particular ordering of attributes (even when for some attributes we just
handle the first one rather than all).
So, this patch instead simply splits it into two loops, the first one walks
alloc_decl attributes, the second one walks dealloc_decl attributes.
If the malloc attribute argument is a built-in, that doesn't change
anything, and otherwise we have the chance to populate the whole
common_deallocs hash_set in the first loop and then can check it in the
second one (and don't need to use more expensive add method on it, can just
check contains there). Not to mention that it also fixes the case when
the function would incorrectly return true if there wasn't a common
deallocator between the two, but dealloc_decl had 2 malloc attributes with
the same deallocator.
2024-12-14 Jakub Jelinek <jakub@redhat.com>
PR middle-end/118024
* gimple-ssa-warn-access.cc (matching_alloc_calls_p): Walk malloc
attributes of alloc_decl and dealloc_decl in separate loops rather
than in lock-step. Use common_deallocs.contains rather than
common_deallocs.add in the second loop.
Jakub Jelinek [Sat, 14 Dec 2024 10:25:08 +0000 (11:25 +0100)]
opts: Use OPTION_SET_P instead of magic value 2 for -fshort-enums default [PR118011]
The magic values for default (usually -1 or sometimes 2) for some options
are from times we haven't global_options_set, I think we should eventually
get rid of all of those.
The PR is about gcc -Q --help=optimizers reporting -fshort-enums as
[enabled] when it is disabled.
For this the following patch is just partial fix; with explicit
gcc -Q --help=optimizers -fshort-enums
or
gcc -Q --help=optimizers -fno-short-enums
it already worked correctly before, with this patch it will report
even with just
gcc -Q --help=optimizers
correct value on most targets, except 32-bit arm with some options or
defaults, so I think it is a step in the right direction.
But, as I wrote in the PR, process_options isn't done before --help=
and even shouldn't be in its current form where it warns on some option
combinations or errors or emits sorry on others, so I think ideally
process_options should have some bool argument whether it is done for
--help= purposes or not, if yes, not emit warnings and just adjust the
options, otherwise do what it currently does.
2024-12-14 Jakub Jelinek <jakub@redhat.com>
PR c/118011
gcc/
* opts.cc (init_options_struct): Don't set opts->x_flag_short_enums to
2.
* toplev.cc (process_options): Test !OPTION_SET_P (flag_short_enums)
rather than flag_short_enums == 2.
gcc/ada/
* gcc-interface/misc.cc (gnat_post_options): Test
!OPTION_SET_P (flag_short_enums) rather than flag_short_enums == 2.
Nathaniel Shead [Thu, 7 Nov 2024 10:37:28 +0000 (21:37 +1100)]
c++: Disallow decomposition of lambda bases [PR90321]
Decomposition of lambda closure types is not allowed by
[dcl.struct.bind] p6, since members of a closure have no name.
r244909 made this an error, but missed the case where a lambda is used
as a base. This patch moves the check to find_decomp_class_base to
handle this case.
As a drive-by improvement, we also slightly improve the diagnostics to
indicate why a base class was being inspected. Ideally the diagnostic
would point directly at the relevant base, but there doesn't seem to be
an easy way to get this location just from the binfo so I don't worry
about that here.
PR c++/90321
gcc/cp/ChangeLog:
* decl.cc (find_decomp_class_base): Check for decomposing a
lambda closure type. Report base class chains if needed.
(cp_finish_decomp): Remove no-longer-needed check.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/decomp62.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Marek Polacek <polacek@redhat.com>
Jakub Jelinek [Fri, 13 Dec 2024 23:41:00 +0000 (00:41 +0100)]
cse: Fix up record_jump_equiv checks [PR117095]
The following testcase is miscompiled on s390x-linux with -O2 -march=z15.
The problem happens during cse2, which sees in an extended basic block
(jump_insn 217 78 216 10 (parallel [
(set (pc)
(if_then_else (ne (reg:SI 165)
(const_int 1 [0x1]))
(label_ref 216)
(pc)))
(set (reg:SI 165)
(plus:SI (reg:SI 165)
(const_int -1 [0xffffffffffffffff])))
(clobber (scratch:SI))
(clobber (reg:CC 33 %cc))
]) "t.c":14:17 discrim 1 2192 {doloop_si64}
(int_list:REG_BR_PROB 955630228 (nil))
-> 216)
...
(insn 99 98 100 12 (set (reg:SI 138)
(const_int 1 [0x1])) "t.c":9:31 1507 {*movsi_zarch}
(nil))
(insn 100 99 103 12 (parallel [
(set (reg:SI 137)
(minus:SI (reg:SI 138)
(subreg:SI (reg:HI 135 [ a ]) 0)))
(clobber (reg:CC 33 %cc))
]) "t.c":9:31 1904 {*subsi3}
(expr_list:REG_DEAD (reg:SI 138)
(expr_list:REG_DEAD (reg:HI 135 [ a ])
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil)))))
Note, cse2 has df_note_add_problem () before df_analyze, which add
(expr_list:REG_UNUSED (reg:SI 165)
(expr_list:REG_UNUSED (reg:CC 33 %cc)
notes to the first insn (correctly so, %cc is clobbered there and pseudo
165 isn't used after the insn).
Now, cse_extended_basic_block has an extra optimization on conditional
jumps, where it records equivalence on the edge which continues in the ebb.
Here it sees (ne reg:SI 165) (const_int 1) is false on the edge and
remembers that pseudo 165 is comparison equivalent to (const_int 1),
so on insn 100 it decides to replace (reg:SI 138) with (reg:SI 165).
This optimization isn't correct here though, because the JUMP_INSN has
multiple sets. Before r0-77890 record_jump_equiv has been called from
cse_insn guarded on n_sets == 1 && any_condjump_p (insn), so it wouldn't
be done on the above JUMP_INSN where n_sets == 2. But since that change
it is guarded with single_set (insn) && any_condjump_p (insn) and that
is true because of the REG_UNUSED note. Looking at that note is
inappropriate in CSE though, because the whole intent of the pass is to
extend the lifetimes of the pseudos if equivalence is found, so the fact
that there is REG_UNUSED note for (reg:SI 165) and that the reg isn't used
later doesn't imply that it won't be used after the optimization.
So, unless we manage to process the other sets on the JUMP_INSN (it wouldn't
be terribly hard in this exact case, the doloop insn decreases the register
by 1 and so we could just record equivalence to (const_int 0) instead, but
generally it might be hard), we should IMHO just punt if there are multiple
sets.
The patch below adds !multiple_sets (insn) check instead of replacing with
it the single_set (insn) check, because apparently any_condjump_p uses
pc_set which supports the case where PATTERN is a SET to PC (that is a
single_set (insn) && !multiple_sets (insn), PATTERN is a PARALLEL with a
single SET to PC (likewise) and some CLOBBERs, PARALLEL with two or more
SETs where the first one is SET to PC (that could be single_set (insn)
with REG_UNUSED notes but is not !multiple_sets (insn)) or PATTERN
is UNSPEC/UNSPEC_VOLATILE with SET inside of it. For the last case
!multiple_sets (insn) will be true, but IMHO we shouldn't try to derive
anything from those because we haven't checked the rest of the UNSPEC*
and we don't really know what it does.
Patrick Palka [Fri, 13 Dec 2024 18:17:29 +0000 (13:17 -0500)]
libstdc++: Avoid unnecessary copies in ranges::min/max [PR112349]
Use a local reference for the (now possibly lifetime extended) result of
*__first so that we copy it only when necessary.
PR libstdc++/112349
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__min_fn::operator()): Turn local
object __tmp into a reference.
* include/bits/ranges_util.h (__max_fn::operator()): Likewise.
* testsuite/25_algorithms/max/constrained.cc (test04): New test.
* testsuite/25_algorithms/min/constrained.cc (test04): New test.
projects / thirdparty / gcc.git / log
