c: Fix constructor bounds checking for VLA and construct VLA vector constants
This patch adds support for checking bounds of SVE ACLE vector initialization
constructors. It also adds support to construct vector constant from init
constructors.
gcc/c/ChangeLog:
* c-typeck.cc (process_init_element): Add check to restrict
constructor length to the minimum vector length allowed.
gcc/ChangeLog:
* tree.cc (build_vector_from_ctor): Add support to construct VLA vector
constants from init constructors.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/acle/general-c/sizeless-1.c: Update test to
test initialize error.
* gcc.target/aarch64/sve/acle/general-c/sizeless-2.c: Likewise.
gimple: Handle variable-sized vectors in BIT_FIELD_REF
Handle variable-sized vectors for BIT_FIELD_REF canonicalization.
gcc/ChangeLog:
* gimple-fold.cc (maybe_canonicalize_mem_ref_addr): Handle variable
sized vector types in BIT_FIELD_REF canonicalization.
* tree-cfg.cc (verify_types_in_gimple_reference): Change object-size-
checking for BIT_FIELD_REF to error offsets that are known_gt to be
outside object-size. Out-of-range offsets can happen in the case of
indices that reference VLA SVE vector elements that may be outside the
minimum vector size range and therefore maybe_gt is not appropirate
here.
aarch64: Make C/C++ operations possible on SVE ACLE types.
This patch changes the TYPE_INDIVISBLE flag to 0 to enable SVE ACLE types to be
treated as GNU vectors and have the same semantics with operations that are
defined on GNU vectors.
gcc/ChangeLog:
* config/aarch64/aarch64-sve-builtins.cc (register_builtin_types): Flip
TYPE_INDIVISBLE flag for SVE ACLE vector types.
Jakub Jelinek [Fri, 29 Nov 2024 09:19:08 +0000 (10:19 +0100)]
gimple-fold: Fix up type_has_padding_at_level_p [PR117065]
The following testcase used to ICE on the trunk since the clear small
object if it has padding optimization before my r15-5746 change,
now it doesn't just because type_has_padding_at_level_p isn't called
on the testcase.
Though, as the testcase shows, structures/unions which contain erroneous
types of one or more of its members can have TREE_TYPE of the FIELD_DECL
error_mark_node, on which we can crash.
E.g. the __builtin_clear_padding lowering just ignores those:
if (TREE_TYPE (field) == error_mark_node)
continue;
and
if (ftype == error_mark_node)
continue;
It doesn't matter much what exactly we do for those cases, as we are going
to fail the compilation anyway, but we shouldn't crash.
So, the following patch ignores those in type_has_padding_at_level_p.
For RECORD_TYPE, we already return if !DECL_SIZE (f) which I think should
cover already the erroneous fields (and we don't use TYPE_SIZE on those).
2024-11-29 Jakub Jelinek <jakub@redhat.com>
PR middle-end/117065
* gimple-fold.cc (type_has_padding_at_level_p) <case UNION_TYPE>:
Also continue if f has error_mark_node type.
Jakub Jelinek [Fri, 29 Nov 2024 09:17:07 +0000 (10:17 +0100)]
__builtin_prefetch fixes [PR117608]
The r15-4833-ge9ab41b79933 patch had among tons of config/i386
specific changes also important change to the generic code, allowing
also 2 as valid value of the second argument of __builtin_prefetch:
- /* Argument 1 must be either zero or one. */
- if (INTVAL (op1) != 0 && INTVAL (op1) != 1)
+ /* Argument 1 must be 0, 1 or 2. */
+ if (INTVAL (op1) < 0 || INTVAL (op1) > 2)
But the patch failed to document that change in __builtin_prefetch
documentation, and more importantly didn't adjust any of the other
backends to deal with it (my understanding is the expected behavior
is that 2 will be silently handled as 0 unless backends have some
more specific way). Some of the backends would ICE on it, in some
cases gcc_assert failures/gcc_unreachable, in other cases crash later
(e.g. accessing arrays with that value as index and due to accessing
garbage after the array crashing at final.cc time), others treated 2
silently as 0, others treated 2 silently as 1.
And even in the i386 backend there were bugs which caused ICEs.
The patch added some if (write == 0) and write 2 handling into
a (badly indented, maybe that is the reason, if (write == 1) body),
rather than into the else side, so it would be always false.
The new *prefetch_rst2 define_insn only accepts parameters 2 1
(i.e. read-shared with moderate degree of locality), so in order
not to ICE the patch uses it only for __builtin_prefetch (ptr, 2, 1);
or __builtin_ia32_prefetch (ptr, 2, 1, 0); and not for other values
of the parameter. If that isn't what we want and we want it to be used
also for all or some of __builtin_prefetch (ptr, 2, {0,2,3}); and
corresponding __builtin_ia32_prefetch, maybe the define_insn could match
other values.
And there was another problem that -mno-mmx -mno-sse -mmovrs compilation
would ICE on most of the prefetches, so I had to add the FAIL; cases.
2024-11-29 Jakub Jelinek <jakub@redhat.com>
PR target/117608
* doc/extend.texi (__builtin_prefetch): Document that second
argument may be also 2 and its meaning.
* config/i386/i386.md (prefetch): Remove unreachable code.
Clear write set operands[1] to const0_rtx if !TARGET_MOVRS or
of locality is not 1. Formatting fixes.
* config/i386/i386-expand.cc (ix86_expand_builtin): Use IN_RANGE.
Call gen_prefetch even for TARGET_MOVRS.
* config/alpha/alpha.md (prefetch): Treat read_or_write 2 like 0.
* config/mips/mips.md (prefetch): Likewise.
* config/arc/arc.md (prefetch_1, prefetch_2, prefetch_3): Likewise.
* config/riscv/riscv.md (prefetch): Likewise.
* config/loongarch/loongarch.md (prefetch): Likewise.
* config/sparc/sparc.md (prefetch): Likewise. Use IN_RANGE.
* config/ia64/ia64.md (prefetch): Likewise.
* config/pa/pa.md (prefetch): Likewise.
* config/aarch64/aarch64.md (prefetch): Likewise.
* config/rs6000/rs6000.md (prefetch): Likewise.
* gcc.dg/builtin-prefetch-1.c (good): Add tests with second argument
2.
* gcc.target/i386/pr117608-1.c: New test.
* gcc.target/i386/pr117608-2.c: New test.
Andrew Pinski [Fri, 29 Nov 2024 09:00:11 +0000 (01:00 -0800)]
fortran: Add default to switch in gfc_trans_transfer [PR117843]
This fixes a bootstrap failure due to a warning on enum values not being
handled. In this case, it is just checking two values and the rest should
are not handled so adding a default case fixes the issue.
When ifcombining contiguous blocks, we can follow forwarder blocks and
reverse conditions to enable combinations, but when there are
intervening blocks, we have to constrain ourselves to paths to the
exit that share the PHI args with all intervening blocks.
Avoiding considering forwarders when intervening blocks were present
would match the preexisting test, but we can do better, recording in
case a forwarded path corresponds to the outer block's exit path, and
insisting on not combining through any other path but the one that was
verified as corresponding. The latter is what this patch implements.
While at that, I've fixed some typos, introduced early testing before
computing the exit path to avoid it when computing it would be
wasteful, or when avoiding it can enable other sound combinations.
for gcc/ChangeLog
PR tree-optimization/117723
* tree-ssa-ifcombine.cc (tree_ssa_ifcombine_bb): Record
forwarder blocks in path to exit, and stick to them. Avoid
computing the exit if obviously not needed, and if that
enables additional optimizations.
(tree_ssa_ifcombine_bb_1): Fix typos.
Harald Anlauf [Wed, 27 Nov 2024 20:11:16 +0000 (21:11 +0100)]
Fortran: fix crash with bounds check writing array section [PR117791]
PR fortran/117791
gcc/fortran/ChangeLog:
* trans-io.cc (gfc_trans_transfer): When an array index depends on
a function evaluation or an expression, do not use optimized array
I/O of an array section and fall back to normal scalarization.
gcc/testsuite/ChangeLog:
* gfortran.dg/bounds_check_array_io.f90: New test.
Uros Bizjak [Thu, 28 Nov 2024 16:44:03 +0000 (17:44 +0100)]
i386: Macroize compound shift patterns some more
Merge ashl and <any_shiftrt:code> compound define_insn_and_split
patterns to form <any_shift:code> macroized pattern.
No functional changes.
gcc/ChangeLog:
* config/i386/i386.md (*<any_shift:insn><mode>3_mask): Macroize
pattern from *ashl<mode>3_mask and *<any_shiftrt:insn><mode>3_mask
using any_shift code iterator.
(*<any_shift:insn><mode>3_mask_1): Macroize pattern
from *ashl<mode>3_mask_1 and *<any_shiftrt:insn><mode>3_mask_1
using any_shift code iterator.
(*<any_shift:insn><mode>3_add): Macroize pattern
from *ashl<mode>3_add and *<any_shiftrt:insn><mode>3_add
using any_shift code iterator.
(*<any_shift:insn><mode>3_add_1): Macroize pattern
from *ashl<mode>3_add_1 and *<any_shiftrt:insn><mode>3_add_1
using any_shift code iterator.
(*<insn><mode>3_sub): Macroize pattern
from *ashl<mode>3_sub and *<any_shiftrt:insn><mode>3_sub
using any_shift code iterator.
(*<any_shift:insn><mode>3_sub_1): Macroize pattern
from *ashl<mode>3_sub_1 and *<any_shiftrt:insn><mode>3_sub_1
using any_shift code iterator.
Jonathan Wakely [Mon, 25 Nov 2024 23:01:28 +0000 (23:01 +0000)]
libstdc++: Reduce duplication in Doxygen comments for std::list
We have a number of comments which are duplicated for C++98 and C++11
overloads, where the signatures are slightly different. Instead of
duplicating the comments that are 90% identical, just use a single
comment that can apply to both. In some cases this means saying "an
iterator" instead of "A const iterator" but that's fine, a
std::list::const_iterator is still an iterator (and a non-const iterator
is a valid argument to those functions because they'll implicitly
convert to const_iterator).
In two cases the @return description just needs to say that it returns
void for C++98 and an iterator otherwise.
libstdc++-v3/ChangeLog:
* include/bits/stl_list.h: Reduce duplication in doxygen
comments.
Marek Polacek [Wed, 9 Oct 2024 15:54:37 +0000 (11:54 -0400)]
c++: Implement P2662R3, Pack Indexing [PR113798]
This patch implements C++26 Pack Indexing, as described in
<https://wg21.link/P2662R3>.
The issue discussing how to mangle pack indexes has not been resolved
yet <https://github.com/itanium-cxx-abi/cxx-abi/issues/175> and I've
made no attempt to address it so far.
Unlike v1, which used augmented TYPE/EXPR_PACK_EXPANSION codes, this
version introduces two new codes: PACK_INDEX_EXPR and PACK_INDEX_TYPE.
Both carry two operands: the pack expansion and the index. They are
handled in tsubst_pack_index: substitute the index and the pack and
then extract the element from the vector (if possible).
To handle pack indexing in a decltype or with decltype(auto), there is
also the new PACK_INDEX_PARENTHESIZED_P flag.
With this feature, it's valid to write something like
using U = tmpl<Ts...[Is]...>;
where we first expand the template argument into
Ts...[Is#0], Ts...[Is#1], ...
and then substitute each individual pack index.
PR c++/113798
gcc/cp/ChangeLog:
* constexpr.cc (potential_constant_expression_1) <case PACK_INDEX_EXPR>:
New case.
* cp-objcp-common.cc (cp_common_init_ts): Mark PACK_INDEX_TYPE and
PACK_INDEX_EXPR.
* cp-tree.def (PACK_INDEX_TYPE): New.
(PACK_INDEX_EXPR): New.
* cp-tree.h (WILDCARD_TYPE_P): Also check PACK_INDEX_TYPE.
(PACK_INDEX_CHECK): Define.
(PACK_INDEX_P): Define.
(PACK_INDEX_PACK): Define.
(PACK_INDEX_INDEX): Define.
(PACK_INDEX_PARENTHESIZED_P): Define.
(make_pack_index): Declare.
(pack_index_element): Declare.
* cxx-pretty-print.cc (cxx_pretty_printer::expression) <case
PACK_INDEX_EXPR>: New case.
(cxx_pretty_printer::type_id) <case PACK_INDEX_TYPE>: New case.
* error.cc (dump_type) <case PACK_INDEX_TYPE>: New case.
(dump_type_prefix): Handle PACK_INDEX_TYPE.
(dump_type_suffix): Likewise.
(dump_expr) <case PACK_INDEX_EXPR>: New case.
* mangle.cc (write_type) <case PACK_INDEX_TYPE>: New case.
* module.cc (trees_out::type_node) <case PACK_INDEX_TYPE>: New case.
(trees_in::tree_node) <case PACK_INDEX_TYPE>: New case.
* parser.cc (cp_parser_next_tokens_are_pack_index_p): New.
(cp_parser_pack_index): New.
(cp_parser_primary_expression): Handle a C++26 pack-index-expression.
(cp_parser_unqualified_id): Handle a C++26 pack-index-specifier.
(cp_parser_nested_name_specifier_opt): See if a pack-index-specifier
follows.
(cp_parser_qualifying_entity): Handle a C++26 pack-index-specifier.
(cp_parser_decltype_expr): Set id_expression_or_member_access_p for
pack indexing.
(cp_parser_mem_initializer_id): Handle a C++26 pack-index-specifier.
(cp_parser_simple_type_specifier): Likewise.
(cp_parser_base_specifier): Likewise.
* pt.cc (iterative_hash_template_arg) <case PACK_INDEX_TYPE,
PACK_INDEX_EXPR>: New case.
(find_parameter_packs_r) <case PACK_INDEX_TYPE, PACK_INDEX_EXPR>: New
case.
(make_pack_index): New.
(tsubst_pack_index): New.
(tsubst): Avoid tsubst on PACK_INDEX_TYPE.
<case TYPENAME_TYPE>: Add a call to error.
<case PACK_INDEX_TYPE>: New case.
(tsubst_expr) <case PACK_INDEX_EXPR>: New case.
(dependent_type_p_r): Return true for PACK_INDEX_TYPE.
(type_dependent_expression_p): Recurse on PACK_INDEX_PACK for
PACK_INDEX_EXPR.
* ptree.cc (cxx_print_type) <case PACK_INDEX_TYPE>: New case.
* semantics.cc (finish_parenthesized_expr): Set
PACK_INDEX_PARENTHESIZED_P for PACK_INDEX_EXPR.
(finish_type_pack_element): Adjust error messages.
(pack_index_element): New.
* tree.cc (cp_tree_equal) <case PACK_INDEX_EXPR>: New case.
(cp_walk_subtrees) <case PACK_INDEX_TYPE, PACK_INDEX_EXPR>: New case.
* typeck.cc (structural_comptypes) <case PACK_INDEX_TYPE>: New case.
* g++.dg/cpp26/pack-indexing1.C: New test.
* g++.dg/cpp26/pack-indexing2.C: New test.
* g++.dg/cpp26/pack-indexing3.C: New test.
* g++.dg/cpp26/pack-indexing4.C: New test.
* g++.dg/cpp26/pack-indexing5.C: New test.
* g++.dg/cpp26/pack-indexing6.C: New test.
* g++.dg/cpp26/pack-indexing7.C: New test.
* g++.dg/cpp26/pack-indexing8.C: New test.
* g++.dg/cpp26/pack-indexing9.C: New test.
* g++.dg/cpp26/pack-indexing10.C: New test.
* g++.dg/cpp26/pack-indexing11.C: New test.
* g++.dg/modules/pack-index-1_a.C: New test.
* g++.dg/modules/pack-index-1_b.C: New test.
Mariam Arutunian [Mon, 11 Nov 2024 19:51:18 +0000 (12:51 -0700)]
[PATCH v6 02/12] Add built-ins and tests for bit-forward and bit-reversed CRCs.
This patch introduces new built-in functions to GCC for computing
bit-forward and bit-reversed CRCs.
These builtins aim to provide efficient CRC calculation capabilities.
When the target architecture supports CRC operations (as indicated by the
presence of a CRC optab),
the builtins will utilize the expander to generate CRC code.
In the absence of hardware support, the builtins default to generating code
for a table-based CRC calculation.
The built-ins are defined as follows:
__builtin_rev_crc16_data8,
__builtin_rev_crc32_data8, __builtin_rev_crc32_data16,
__builtin_rev_crc32_data32
__builtin_rev_crc64_data8, __builtin_rev_crc64_data16,
__builtin_rev_crc64_data32, __builtin_rev_crc64_data64,
__builtin_crc8_data8,
__builtin_crc16_data16, __builtin_crc16_data8,
__builtin_crc32_data8, __builtin_crc32_data16, __builtin_crc32_data32,
__builtin_crc64_data8, __builtin_crc64_data16, __builtin_crc64_data32,
__builtin_crc64_data64
Each built-in takes three parameters:
crc: The initial CRC value.
data: The data to be processed.
polynomial: The CRC polynomial without the leading 1.
To validate the correctness of these built-ins, this patch also includes
additions to the GCC testsuite.
This enhancement allows GCC to offer developers high-performance CRC
computation options
that automatically adapt to the capabilities of the target hardware.
* gcc.dg/crc-builtin-rev-target32.c: New test.
* gcc.dg/crc-builtin-rev-target64.c: New test.
* gcc.dg/crc-builtin-target32.c: New test.
* gcc.dg/crc-builtin-target64.c: New test.
Signed-off-by: Mariam Arutunian <mariamarutunian@gmail.com> Co-authored-by: Joern Rennecke <joern.rennecke@embecosm.com> Co-authored-by: Jeff Law <jlaw@ventanamicro.com>
Mariam Arutunian [Mon, 11 Nov 2024 19:48:34 +0000 (12:48 -0700)]
[PATCH v6 01/12] Implement internal functions for efficient CRC computation.
Add two new internal functions (IFN_CRC, IFN_CRC_REV), to provide faster
CRC generation.
One performs bit-forward and the other bit-reversed CRC computation.
If CRC optabs are supported, they are used for the CRC computation.
Otherwise, table-based CRC is generated.
The supported data and CRC sizes are 8, 16, 32, and 64 bits.
The polynomial is without the leading 1.
A table with 256 elements is used to store precomputed CRCs.
For the reflection of inputs and the output, a simple algorithm involving
SHIFT, AND, and OR operations is used.
gcc/
* doc/md.texi (crc@var{m}@var{n}4, crc_rev@var{m}@var{n}4): Document.
* expr.cc (calculate_crc): New function.
(assemble_crc_table): Likewise.
(generate_crc_table): Likewise.
(calculate_table_based_CRC): Likewise.
(expand_crc_table_based): Likewise.
(gen_common_operation_to_reflect): Likewise.
(reflect_64_bit_value): Likewise.
(reflect_32_bit_value): Likewise.
(reflect_16_bit_value): Likewise.
(reflect_8_bit_value): Likewise.
(generate_reflecting_code_standard): Likewise.
(expand_reversed_crc_table_based): Likewise.
* expr.h (generate_reflecting_code_standard): New function declaration.
(expand_crc_table_based): Likewise.
(expand_reversed_crc_table_based): Likewise.
* internal-fn.cc: (crc_direct): Define.
(direct_crc_optab_supported_p): Likewise.
(expand_crc_optab_fn): New function
* internal-fn.def (CRC, CRC_REV): New internal functions.
* optabs.def (crc_optab, crc_rev_optab): New optabs.
Signed-off-by: Mariam Arutunian <mariamarutunian@gmail.com> Co-authored-by: Joern Rennecke <joern.rennecke@embecosm.com> Co-authored-by: Jeff Law <jlaw@ventanamicro.com>
[-PASS:-]{+FAIL:+} libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_get_property-gcn.c -DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa -O0 (test for excess errors)
[-PASS:-]{+UNRESOLVED:+} libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_get_property-gcn.c -DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa -O0 [-execution test-]{+compilation failed to produce executable+}
[Etc.]
..., due to:
[...]/libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_get_property-gcn.c:16:13: error: two or more data types in declaration specifiers
[...]/libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_get_property-gcn.c:16:1: warning: useless type name in empty declaration
libgomp/
* testsuite/libgomp.oacc-c-c++-common/acc_get_property-gcn.c
[!__cplusplus]: Don't 'typedef int bool;'.
Jakub Jelinek [Thu, 28 Nov 2024 13:54:42 +0000 (14:54 +0100)]
testsuite: Fix up pr116675.c test [PR116675]
The test uses dg-do run and scan-assembler* at the same time,
that obviously doesn't work when pr116675.s isn't created at all,
so one gets
PASS: gcc.target/i386/pr116675.c execution test
gcc.target/i386/pr116675.c: output file does not exist
UNRESOLVED: gcc.target/i386/pr116675.c scan-assembler-times pand 4
gcc.target/i386/pr116675.c: output file does not exist
UNRESOLVED: gcc.target/i386/pr116675.c scan-assembler-times pandn 4
gcc.target/i386/pr116675.c: output file does not exist
UNRESOLVED: gcc.target/i386/pr116675.c scan-assembler-times por 4
The usual way to handle that is adding -save-temps option.
The test FAILs after that change though, for simple reason, the pand
regex doesn't match just pand instructions, but also the pandn ones.
I've added \t there to make sure it matches only pand.
Though, wonder if it wouldn't be safer to split the test into two,
one with just the 4 functions (why noinline, noclone rather than
noipa, btw?), that one would be dg-do compile and have the scan-assembler*
directives, and then another one which includes the first one and is
dg-do run and contains the runtime checking of those.
In any case, I've committed this as obvious.
2024-11-28 Jakub Jelinek <jakub@redhat.com>
PR target/116675
* gcc.target/i386/pr116675.c: Add -save-temps to dg-options.
Scan for pand\t rather than pand.
Jakub Jelinek [Thu, 28 Nov 2024 13:31:44 +0000 (14:31 +0100)]
docs: Fix up __sync_* documentation [PR117642]
The PR14311 commit which added support for __sync_* builtins documented that
there is a warning if a particular operation cannot be implemented.
But that commit nor anything later on implemented such warning, it was
always silent generation of the mentioned calls (which can in most cases
result in linker errors of course because those functions aren't implemented
anywhere, in libatomic or elsewhere in code shipped in gcc).
So, the following patch just adjust the documentation to match the
implementation.
2024-11-28 Jakub Jelinek <jakub@redhat.com>
PR target/117642
* doc/extend.texi: Remove documentation of warning for unimplemented
__sync_* operations, such warning has never been implemented.
On top of the
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668554.html
patch which introduces the nonnull_if_nonzero attribute (because
C2Y is allowing NULL arguments on various calls like memcpy, memset,
strncpy etc. as long as the count is 0) the following patch adds just
limited handling of the attribute in the ranger, in particular infers
nonnull for the pointer argument referenced in first argument of the
attribute if the second argument is a non-zero INTEGER_CST
(integer_nonzerop).
Ideally (as the FIXME says) I'd like to query arg2 range and check if
it doesn't contain zero, but am not sure such queries are possible from
gimple_infer_range (and if it is possible whether one can just query
the currently recorded range for it or if one can call something that
will try to compute the range by walking the def stmts etc.).
Could you handle as a follow-up the range querying if it is possible?
As for useful testcase, with the patch I'm going to post next
e.g. gcc.dg/tree-ssa/pr78154.c if the calls use d as destination (not dn)
and count that will have a range which doesn't include 0 and isn't constant.
2024-11-28 Jakub Jelinek <jakub@redhat.com>
PR c/117023
* gimple-range-infer.cc (gimple_infer_range::gimple_infer_range):
Handle also nonnull_if_nonzero attributes.
Jakub Jelinek [Thu, 28 Nov 2024 10:48:33 +0000 (11:48 +0100)]
Add support for nonnull_if_nonzero attribute [PR117023]
As mentioned in an earlier thread, C2Y voted in a change which made
various library APIs callable with NULL arguments in certain cases,
e.g.
memcpy (NULL, NULL, 0);
is now valid, although
memcpy (NULL, NULL, 1);
remains invalid. This affects various APIs, including several of
GCC builtins; plus on the C library side those APIs are often declared
with nonnull attribute(s) as well.
Florian suggested using the access attribute for this, but our docs
explicitly say that access attribute doesn't imply nonnull and it doesn't
cover e.g. the qsort case where the comparison function pointer may be
also NULL if nmemb is 0, but must be non-zero otherwise.
As this case affects 21 APIs in C standard and I think is going to affect
various wrappers around those in various packages as well, I think it
is a common thing that should have its own attribute, because we should
still warn when people use
qsort (NULL, 1, 1, NULL);
etc., and similarly want to have -fsanitize=null instrumentation for those.
So, the following patch introduces nonnull_if_nonzero attribute (or would
you prefer cond_nonnull or some other name?), which has always 2 arguments,
argument index of a pointer argument (like one argument nonnull) and
argument index of an associated integral argument. If that argument is
non-zero, it is UB to pass NULL to the pointer argument, if that argument
is zero, it is valid. And changes various spots which already handled the
nonnull attribute to handle this one as well, with sometimes using the
ranger (or for -fsanitize=nonnull explicitly checking the associated
argument value, so instead of if (!ptr) __ubsan_... (...); it will
now do if (!ptr && sz) __ubsan_... (...);).
I've so far omitted changing gimple_infer_range (am not 100% sure how I can
use the ranger inside of the ranger) and changing the analyzer to handle it.
And I haven't changed builtins.def etc. to make use of that attribute
instead of nonnull where appropriate.
I'd then follow with the builtins.def changes (and eventually glibc
etc. would need to be adjusted too).
2024-11-28 Jakub Jelinek <jakub@redhat.com>
PR c/117023
gcc/
* gimple.h (infer_nonnull_range_by_attribute): Add a tree *
argument defaulted to NULL.
* gimple.cc (infer_nonnull_range_by_attribute): Add op2 argument.
Handle also nonnull_if_nonzero attributes.
* tree.cc (get_nonnull_args): Fix comment typo.
* builtins.cc (validate_arglist): Handle nonnull_if_nonzero attribute.
* tree-ssa-ccp.cc (pass_post_ipa_warn::execute): Handle
nonnull_if_nonzero attributes.
* ubsan.cc (instrument_nonnull_arg): Adjust
infer_nonnull_range_by_attribute caller. If it returned true and
filed in non-NULL arg2, check that arg2 is non-zero as another
condition next to checking that arg is zero.
* doc/extend.texi (nonnull_if_nonzero): Document new attribute.
gcc/c-family/
* c-attribs.cc (handle_nonnull_if_nonzero_attribute): New
function.
(c_common_gnu_attributes): Add nonnull_if_nonzero attribute.
(handle_nonnull_attribute): Fix comment typo.
* c-common.cc (struct nonnull_arg_ctx): Add other member.
(check_function_nonnull): Also check nonnull_if_nonzero attributes.
(check_nonnull_arg): Use different warning wording if pctx->other
is non-zero.
(check_function_arguments): Initialize ctx.other.
gcc/testsuite/
* gcc.dg/nonnull-8.c: New test.
* gcc.dg/nonnull-9.c: New test.
* gcc.dg/nonnull-10.c: New test.
* c-c++-common/ubsan/nonnull-6.c: New test.
* c-c++-common/ubsan/nonnull-7.c: New test.
Jakub Jelinek [Thu, 28 Nov 2024 10:45:00 +0000 (11:45 +0100)]
rs6000: Add PowerPC inline asm redzone clobber support
The following patch on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667949.html
patch adds rs6000 part of the support (the only other target I'm aware of
which clearly has red zone as well).
2024-11-28 Jakub Jelinek <jakub@redhat.com>
* config/rs6000/rs6000.h (struct machine_function): Add
asm_redzone_clobber_seen member.
* config/rs6000/rs6000-logue.cc (rs6000_stack_info): Force
info->push_p if cfun->machine->asm_redzone_clobber_seen.
* config/rs6000/rs6000.cc (TARGET_REDZONE_CLOBBER): Redefine.
(rs6000_redzone_clobber): New function.
Jakub Jelinek [Thu, 28 Nov 2024 10:42:11 +0000 (11:42 +0100)]
inline-asm, i386: Add "redzone" clobber support
The following patch adds a "redzone" clobber (recognized everywhere,
even on on targets which don't do anything with it),
with which one can mark the rare case where inline asm pushes
something on the stack or uses call instruction without taking
red zone into account (i.e. addq $-128, %rsp; and addq $128, %rsp
around that).
2024-11-28 Jakub Jelinek <jakub@redhat.com>
gcc/
* target.def (redzone_clobber): New target hook.
* varasm.cc (decode_reg_name_and_count): Return -5 for
"redzone".
* cfgexpand.cc (expand_asm_stmt): Handle redzone clobber.
* config/i386/i386.h (struct machine_function): Add
asm_redzone_clobber_seen member.
* config/i386/i386.cc (ix86_compute_frame_layout): Don't
use red zone if cfun->machine->asm_redzone_clobber_seen.
(ix86_redzone_clobber): New function.
(TARGET_REDZONE_CLOBBER): Redefine.
* doc/extend.texi (Clobbers and Scratch Registers): Document
the "redzone" clobber.
* doc/tm.texi.in: Add @hook TARGET_REDZONE_CLOBBER.
* doc/tm.texi: Regenerate.
gcc/testsuite/
* gcc.dg/asm-redzone-1.c: New test.
* gcc.target/i386/asm-redzone-1.c: New test.
Jakub Jelinek [Thu, 28 Nov 2024 10:30:32 +0000 (11:30 +0100)]
c++: Small initial fixes for zeroing of padding bits [PR117256]
https://eel.is/c++draft/dcl.init#general-6
says that even padding bits are supposed to be zeroed during
zero-initialization.
The following patch on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665565.html
patch attempts to implement that, though only for the easy
cases so far, in particular marks the CONSTRUCTOR created during
zero-initialization (or zero-initialization done during the
value-initialization) as having padding bits cleared and for
constexpr evaluation attempts to preserve that bit on a new CONSTRUCTOR
created for CONSTRUCTOR_ZERO_PADDING_BITS lhs.
I think we need far more than that, but am not sure where exactly
to implement that.
In particular, I think __builtin_bitcast should take it into account
during constant evaluation, if the padding bits in something are guaranteed
to be zero, then I'd think std::bitcast out of it and testing those
bits in there should be well defined.
But if we do that, the flag needs to be maintained precisely, not just
conservatively, so e.g. any place where some object is copied into another
one (except bitcast?) which would be element-wise copy, the bit should
be cleared (or preserved from the earlier state? I'd hope
element-wise copying invalidates even the padding bits, but then what
about just stores into some members, do those invalidate the padding bits
in the rest of the object?). But if it is an elided copy, it shouldn't.
And am not really sure what happens e.g. with non-automatic constexpr
variables. If it is constructed by something that doesn't guarantee
the zeroing of the padding bits (so similarly constructed constexpr automatic
variable would have undefined state of the padding bits), are those padding
bits well defined because it isn't automatic variable?
Anyway, I hope the following patch is at least a small step in the right
direction.
Jakub Jelinek [Thu, 28 Nov 2024 10:18:07 +0000 (11:18 +0100)]
expr, c: Don't clear whole unions [PR116416]
As discussed earlier, we currently clear padding bits even when we
don't have to and that causes pessimization of emitted code,
e.g. for
union U { int a; long b[64]; };
void bar (union U *);
void
foo (void)
{
union U u = { 0 };
bar (&u);
}
we need to clear just u.a, not the whole union, but on the other side
in cases where the standard requires padding bits to be zeroed, like for
C23 {} initializers of aggregates with padding bits, or for C++11 zero
initialization we don't do that.
This patch
a) moves some of the stuff into complete_ctor_at_level_p (but not
all the *p_complete = 0; case, for that it would need to change
so that it passes around the ctor rather than just its type) and
changes the handling of unions
b) introduces a new option, so that users can either get the new
behavior (only what is guaranteed by the standards, the default),
or previous behavior (union padding zero initialization, no such
guarantees in structures) or also a guarantee in structures
c) introduces a new CONSTRUCTOR flag which says that the padding bits
(if any) should be zero initialized (and sets it for now in the C
FE for C23 {} initializers).
Am not sure the CONSTRUCTOR_ZERO_PADDING_BITS flag is really needed
for C23, if there is just empty initializer, I think we already mark
it as incomplete if there are any missing initializers. Maybe with
some designated initializer games, say
void foo () {
struct S { char a; long long b; };
struct T { struct S c; } t = { .c = {}, .c.a = 1, .c.b = 2 };
...
}
Is this supposed to initialize padding bits in C23 and then the .c.a = 1
and .c.b = 2 stores preserve those padding bits, so is that supposed
to be different from struct T t2 = { .c = { 1, 2 } };
? What about just struct T t3 = { .c.a = 1, .c.b = 2 }; ?
And I haven't touched the C++ FE for the flag, because I'm afraid I'm lost
on where exactly is zero-initialization done (vs. other types of
initialization) and where is e.g. zero-initialization of a temporary then
(member-wise) copied.
Say
struct S { char a; long long b; };
struct T { constexpr T (int a, int b) : c () { c.a = a; c.b = b; } S c; };
void bar (T *);
void
foo ()
{
T t (1, 2);
bar (&t);
}
Is the c () value-initialization of t.c followed by c.a and c.b updates
which preserve the zero initialized padding bits? Or is there some
copy construction involved which does member-wise copying and makes the
padding bits undefined?
Looking at (older) clang++ with -O2, it initializes also the padding bits
when c () is used and doesn't with c {}.
For GCC, note that there is that optimization from Alex to zero padding bits
for optimization purposes for small aggregates, so either one needs to look
at -O0 -fdump-tree-gimple dumps, or use larger structures which aren't
optimized that way.
2024-11-28 Jakub Jelinek <jakub@redhat.com>
PR c++/116416
gcc/
* flag-types.h (enum zero_init_padding_bits_kind): New type.
* tree.h (CONSTRUCTOR_ZERO_PADDING_BITS): Define.
* common.opt (fzero-init-padding-bits=): New option.
* expr.cc (categorize_ctor_elements_1): Handle
CONSTRUCTOR_ZERO_PADDING_BITS or
flag_zero_init_padding_bits == ZERO_INIT_PADDING_BITS_ALL. Fix
up *p_complete = -1; setting for unions.
(complete_ctor_at_level_p): Handle unions differently for
flag_zero_init_padding_bits == ZERO_INIT_PADDING_BITS_STANDARD.
* gimple-fold.cc (type_has_padding_at_level_p): Fix up UNION_TYPE
handling, return also true for UNION_TYPE with no FIELD_DECLs
and non-zero size, handle QUAL_UNION_TYPE like UNION_TYPE.
* doc/invoke.texi (-fzero-init-padding-bits=@var{value}): Document.
gcc/c/
* c-parser.cc (c_parser_braced_init): Set CONSTRUCTOR_ZERO_PADDING_BITS
for flag_isoc23 empty initializers.
* c-typeck.cc (constructor_zero_padding_bits): New variable.
(struct constructor_stack): Add zero_padding_bits member.
(really_start_incremental_init): Save and clear
constructor_zero_padding_bits.
(push_init_level): Save constructor_zero_padding_bits. Or into it
CONSTRUCTOR_ZERO_PADDING_BITS from previous value if implicit.
(pop_init_level): Set CONSTRUCTOR_ZERO_PADDING_BITS if
constructor_zero_padding_bits and restore
constructor_zero_padding_bits.
gcc/testsuite/
* gcc.dg/plugin/infoleak-1.c (test_union_2b, test_union_4b): Expect
diagnostics.
* gcc.dg/c23-empty-init-5.c: New test.
* gcc.dg/gnu11-empty-init-1.c: New test.
* gcc.dg/gnu11-empty-init-2.c: New test.
* gcc.dg/gnu11-empty-init-3.c: New test.
* gcc.dg/gnu11-empty-init-4.c: New test.
Where two things go wrong, the wrong mask is used and the address pointers to
the stores are wrong.
This issue is happening because the codegen loop in vectorizable_store is a
nested loop where in the outer loop we iterate over ncopies and in the inner
loop we loop over vec_num.
For SLP ncopies == 1 and vec_num == SLP_NUM_STMS, but the loop mask is
determined by only the outerloop index and the pointer address is only updated
in the outer loop.
As such for SLP we always use the same predicate and the same memory location.
This patch flattens the two loops and instead iterates over ncopies * vec_num
and simplified the indexing.
This does not fully fix the gcc_r miscompile error in SPECCPU 2017 as the error
moves somewhere else. I will look at that next but fixes some other libraries
that also started failing.
gcc/ChangeLog:
PR tree-optimization/117557
* tree-vect-stmts.cc (vectorizable_store): Flatten the ncopies and
vec_num loops.
gcc/testsuite/ChangeLog:
PR tree-optimization/117557
* gcc.target/aarch64/pr117557.c: New test.
Jakub Jelinek [Thu, 28 Nov 2024 09:51:16 +0000 (10:51 +0100)]
gimple-fold: Avoid ICEs with bogus declarations like const attribute no snprintf [PR117358]
When one puts incorrect const or pure attributes on declarations of various
C APIs which have corresponding builtins (vs. what they actually do), we can
get tons of ICEs in gimple-fold.cc.
The following patch fixes it by giving up gimple_fold_builtin_* folding
if the functions don't have gimple_vdef (or for pure functions like
bcmp/strchr/strstr gimple_vuse) when in SSA form (during gimplification
they will surely have both of those NULL even when declared correctly,
yet it is highly desirable to fold them).
Or shall I replace
!gimple_vdef (stmt) && gimple_in_ssa_p (cfun)
tests with
(gimple_call_flags (stmt) & (ECF_CONST | ECF_PURE | ECF_NOVOPS)) != 0
and
!gimple_vuse (stmt) && gimple_in_ssa_p (cfun)
with
(gimple_call_flags (stmt) & (ECF_CONST | ECF_NOVOPS)) != 0
?
2024-11-28 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/117358
* gimple-fold.cc (gimple_fold_builtin_memory_op): Punt if stmt has no
vdef in ssa form.
(gimple_fold_builtin_bcmp): Punt if stmt has no vuse in ssa form.
(gimple_fold_builtin_bcopy): Punt if stmt has no vdef in ssa form.
(gimple_fold_builtin_bzero): Likewise.
(gimple_fold_builtin_memset): Likewise. Use return false instead of
return NULL_TREE.
(gimple_fold_builtin_strcpy): Punt if stmt has no vdef in ssa form.
(gimple_fold_builtin_strncpy): Likewise.
(gimple_fold_builtin_strchr): Punt if stmt has no vuse in ssa form.
(gimple_fold_builtin_strstr): Likewise.
(gimple_fold_builtin_strcat): Punt if stmt has no vdef in ssa form.
(gimple_fold_builtin_strcat_chk): Likewise.
(gimple_fold_builtin_strncat): Likewise.
(gimple_fold_builtin_strncat_chk): Likewise.
(gimple_fold_builtin_string_compare): Likewise.
(gimple_fold_builtin_fputs): Likewise.
(gimple_fold_builtin_memory_chk): Likewise.
(gimple_fold_builtin_stxcpy_chk): Likewise.
(gimple_fold_builtin_stxncpy_chk): Likewise.
(gimple_fold_builtin_stpcpy): Likewise.
(gimple_fold_builtin_snprintf_chk): Likewise.
(gimple_fold_builtin_sprintf_chk): Likewise.
(gimple_fold_builtin_sprintf): Likewise.
(gimple_fold_builtin_snprintf): Likewise.
(gimple_fold_builtin_fprintf): Likewise.
(gimple_fold_builtin_printf): Likewise.
(gimple_fold_builtin_realloc): Likewise.
Jakub Jelinek [Thu, 28 Nov 2024 09:23:47 +0000 (10:23 +0100)]
builtins: Handle BITINT_TYPE in __builtin_iseqsig folding [PR117802]
In check_builtin_function_arguments in the _BitInt patchset I've changed
INTEGER_TYPE tests to INTEGER_TYPE or BITINT_TYPE, but haven't done the
same in fold_builtin_iseqsig, which now ICEs because of that.
The following patch fixes that.
BTW, that TYPE_PRECISION (type0) >= TYPE_PRECISION (type1) test
for REAL_TYPE vs. REAL_TYPE looks pretty random and dangerous, I think
it would be useful to handle this builtin also in the C and C++ FEs,
if both arguments have REAL_TYPE, use the FE specific routine to decide
which types to use and error if a comparison between types would be
erroneous (e.g. complain about _Decimal* vs. float/double/long
double/_Float*, pick up the preferred type, complain about
__ibm128 vs. _Float128 in C++, etc.).
But the FEs can just promote one argument to the other in that case
and keep fold_builtin_iseqsig as is for say Fortran and other FEs.
2024-11-28 Jakub Jelinek <jakub@redhat.com>
PR c/117802
* builtins.cc (fold_builtin_iseqsig): Handle BITINT_TYPE like
INTEGER_TYPE.
* gcc.dg/builtin-iseqsig-1.c: New test.
* gcc.dg/bitint-118.c: New test.
Joseph Myers [Thu, 28 Nov 2024 02:41:35 +0000 (02:41 +0000)]
c: Fix gimplification ICE for shifts with invalid redeclarations
As reported in bug 117757, there is a C gimplification ICE for shifts
involving a variable that was incompatibly redeclared (and thus had
its type changed to error_mark_node). Fix this with an appropriate
error_operand_p check.
Note that this is not the same issue as any of the other bugs reported
for ICEs later in the gimplifier dealing with such erroneous
redeclarations (it is, however, the same as the *second* ICE reported
in bug 115644 - the test in comment#1 for that bug, not the one in the
original bug report).
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/117757
gcc/c-family/
* c-gimplify.cc (c_gimplify_expr): Check for error_operand_p
before calling TYPE_MAIN_VARIANT for shifts.
David Malcolm [Thu, 28 Nov 2024 00:21:15 +0000 (19:21 -0500)]
c-family: offer suggestions for missing command-line options [PR82892]
Some builtin macros are only defined when certain command-line options
are provided. Update the error messages for them so that we suggest
the pertinent option ('-fopenacc' for '_OPENACC', and '-fopenmp' for
'_OPENMP')
David Malcolm [Thu, 28 Nov 2024 00:21:15 +0000 (19:21 -0500)]
C/C++: add fix-it hints for missing '&' and '*' (v5) [PR87850]
This patch adds a note with a fix-it hint to various
pointer-vs-non-pointer diagnostics, suggesting the addition of
a leading '&' or '*'.
For example, note the ampersand fix-it hint in the following:
demo.c: In function 'int main()':
demo.c:5:22: error: invalid conversion from 'pthread_key_t' {aka 'unsigned int'}
to 'pthread_key_t*' {aka 'unsigned int*'} [-fpermissive]
5 | pthread_key_create(key, NULL);
| ^~~
| |
| pthread_key_t {aka unsigned int}
demo.c:5:22: note: possible fix: take the address with '&'
5 | pthread_key_create(key, NULL);
| ^~~
| &
In file included from demo.c:1:
/usr/include/pthread.h:1122:47: note: initializing argument 1 of
'int pthread_key_create(pthread_key_t*, void (*)(void*))'
1122 | extern int pthread_key_create (pthread_key_t *__key,
| ~~~~~~~~~~~~~~~^~~~~
gcc/c-family/ChangeLog:
PR c++/87850
* c-common.cc: Include "gcc-rich-location.h".
(maybe_emit_indirection_note): New function.
* c-common.h (maybe_emit_indirection_note): New decl.
(compatible_types_for_indirection_note_p): New decl.
gcc/c/ChangeLog:
PR c++/87850
* c-typeck.cc (compatible_types_for_indirection_note_p): New
function.
(convert_for_assignment): Call maybe_emit_indirection_note for
pointer vs non-pointer diagnostics.
gcc/cp/ChangeLog:
PR c++/87850
* call.cc (convert_like_real): Call maybe_emit_indirection_note
for "invalid conversion" diagnostic.
* typeck.cc (compatible_types_for_indirection_note_p): New
function.
gcc/testsuite/ChangeLog:
PR c++/87850
* c-c++-common/indirection-fixits.c: New test.
* g++.dg/template/error60.C: Add fix-it hint to expected output.
* g++.dg/template/error60a.C: Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Jan Hubicka [Wed, 27 Nov 2024 22:52:37 +0000 (23:52 +0100)]
optimize basic_string
Add __builtin_unreachable conditionls to declare value ranges of
basic_string::length(). FIx max_size() to return actual max size
using logic similar to std::vector. Aviod use of size() in empty()
to save some compile time overhead.
As disucced, max_size() change is technically ABI breaking, but
hopefully this does not really matter in practice.
Change of length() breaks empty-loop testcase where we now optimize the
loop only after inlining, so template is updated to check cddce3 instead
of cddce2. This is PR117764.
With these chages we now optimize out unused strings as tested in
string-1.C
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (basic_string::size(),
basic_string::length(), basic_string::capacity()): Add
__builtin_unreachable to declare value ranges.
(basic_string::empty()): Implement directly
(basic_string::max_size()): Account correctly the terminating 0
and limits implied by ptrdiff_t.
gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/empty-loop.C: xfail optimization at cddce2 and check
it happens at cddce3.
* g++.dg/tree-ssa/string-1.C: New test.
Joseph Myers [Wed, 27 Nov 2024 22:27:08 +0000 (22:27 +0000)]
c: Fix ICE using function name in parameter type in old-style function definition [PR91193]
As reported in bug 91193, if an old-style function definition
redeclares a typedef name as a function, then uses that function name
at the start of the first old-style parameter definition, then the
parser interprets that token as a typedef name (because lookahead
occurred before processing of the function declarator completed), but
when it is looked up in processing that parameter definition, what is
found is the redefinition, resulting in an ICE.
The function name's scope starts at the end of its declarator, so this
is similar to other cases where we call
c_parser_maybe_reclassify_token because lookahead might have
classified a token as being a typedef or not based on information from
the wrong scope; do so in this case as well, so resulting in the
expected parse errors from using something that's no longer a typedef
name as if it were a typedef name, and eliminating the ICE.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
Jonathan Wakely [Wed, 27 Nov 2024 11:52:40 +0000 (11:52 +0000)]
libstdc++: Add cold attribute to assertion failure functions [PR117650]
This helps the compiler to split the cold path into a separate clone, so
that the hot path is a smaller function that uses less icache, and the
cold path is only fetched into the icache if actually executed.
Andrew Pinski [Tue, 26 Nov 2024 00:04:21 +0000 (16:04 -0800)]
match: Improve handling of double convert [PR117776]
For a double conversion, we will simplify it into a conversion
with an and if the outer type and inside precision matches and
the intra precision is smaller and unsigned. We should be able
to extend this to where the outer precision is larger too.
This is a good canonicalization too.
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/117776
gcc/ChangeLog:
* match.pd (nested int casts): Allow for the case
where the final prec is greater than the original
prec.
gcc/testsuite/ChangeLog:
* g++.dg/vect/pr117776.cc: New test.
* gcc.dg/tree-ssa/cast-3.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Patrick Palka [Wed, 27 Nov 2024 16:59:38 +0000 (11:59 -0500)]
libstdc++/ranges: make _RangeAdaptorClosure befriend operator|
This declares the range adaptor pipe operators a friend of the
_RangeAdaptorClosure base class so that the std module doesn't need to
export them for ADL to find them.
Note that we deliberately don't define these pipe operators as hidden
friends, see r14-3293-g4a6f3676e7dd9e.
Jakub Jelinek [Wed, 27 Nov 2024 16:29:28 +0000 (17:29 +0100)]
c: Fix sizeof error recovery [PR117745]
Compilation of the following testcase hangs forever after emitting first
error. The problem is that in one place we just return error_mark_node
directly rather than going through c_expr_sizeof_expr or c_expr_sizeof_type.
The parsing of the expression could have called record_maybe_used_decl
though, but nothing calls pop_maybe_used which needs to be called after
parsing of every sizeof/typeof, successful or not.
At the end of the toplevel declaration we free the parser_obstack and in
another function record_maybe_used_decl is called again and due to the
missing pop_maybe_unused we end up with a cycle in the chain.
The following patch fixes it by just setting error and goto to the
sizeof_expr:
c_inhibit_evaluation_warnings--;
in_sizeof--;
mark_exp_read (expr.value);
if (TREE_CODE (expr.value) == COMPONENT_REF
&& DECL_C_BIT_FIELD (TREE_OPERAND (expr.value, 1)))
error_at (expr_loc, "%<sizeof%> applied to a bit-field");
result = c_expr_sizeof_expr (expr_loc, expr);
where c_expr_sizeof_expr will do:
struct c_expr ret;
if (expr.value == error_mark_node)
{
ret.value = error_mark_node;
ret.original_code = ERROR_MARK;
ret.original_type = NULL;
ret.m_decimal = 0;
pop_maybe_used (false);
}
...
return ret;
which is exactly what the old code did manually except for the missing
pop_maybe_used call. mark_exp_read does nothing on error_mark_node and
error_mark_node doesn't have COMPONENT_REF tree_code.
2024-11-27 Jakub Jelinek <jakub@redhat.com>
PR c/117745
* c-parser.cc (c_parser_sizeof_expression): If type_name is NULL,
just expr.set_error () and goto sizeof_expr instead of doing error
recovery manually.
Pan Li [Fri, 22 Nov 2024 03:48:26 +0000 (11:48 +0800)]
I386: Add more testcases for unsigned SAT_ADD vector pattern
Some forms like below failed to be recognized as a SAT_ADD pattern
for target i386. It is related to some match pattern
extraction but get fixed after the refactor of the SAT_ADD
pattern. Thus, add testcases to ensure we won't have similar
issues in the future.
#define DEF_SAT_ADD(T) \
T sat_add_##T (T x, T y) \
{ \
T res; \
res = x + y; \
res |= -(T)(res < x); \
return res; \
}
#define VEC_DEF_SAT_ADD(T) \
void vec_sat_add(T * restrict a, T * restrict b) \
{ \
for (int i = 0; i < 8; i++) \
b[i] = sat_add_##T (a[i], b[i]); \
}
DEF_SAT_ADD (uint32_t)
VEC_DEF_SAT_ADD (uint32_t)
The below test suites are passed for this patch.
make -k check-gcc RUNTESTFLAGS="--target_board=unix\{,-m32\} i386.exp=pr112600-5a-*.c"
PR target/112600
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr112600-5-u16.c: New test.
* gcc.target/i386/pr112600-5-u32.c: New test.
* gcc.target/i386/pr112600-5-u64.c: New test.
* gcc.target/i386/pr112600-5-u8.c: New test.
* gcc.target/i386/pr112600-5.h: New test.
Pan Li [Mon, 25 Nov 2024 01:21:24 +0000 (09:21 +0800)]
Match: Refactor the unsigned SAT_ADD match ADD_OVERFLOW pattern [NFC]
This patch would like to refactor the unsigned SAT_ADD pattern when
leverage the IFN ADD_OVERFLOW, aka:
* Extract type check outside.
* Re-arrange the related match pattern forms together.
* Remove unnecessary helper pattern matches.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
* The x86 bootstrap test.
* The x86 fully regression test.
gcc/ChangeLog:
* match.pd: Refactor sorts of unsigned SAT_ADD match pattern for
IFN ADD_OVERFLOW.
Joseph Myers [Wed, 27 Nov 2024 14:10:37 +0000 (14:10 +0000)]
c: Do not remove _Atomic from array element type for typeof_unqual [PR117781]
As reported in bug 117781, my fix for bug 112841 broke the case of
typeof_unqual applied to an array of _Atomic elements, which should
not have _Atomic removed since only the element type is atomic, not
the array type. Fix with logic to ensure that atomic element types
are preserved as such, while other qualifiers (i.e. those that are
semantically rather than only syntactically such in C) are removed.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/117781
gcc/c/
* c-parser.cc (c_parser_typeof_specifier): Do not remove _Atomic
from array element type for typeof_unqual.
Jakub Jelinek [Wed, 27 Nov 2024 13:33:16 +0000 (14:33 +0100)]
builtins: Emit __sync_lock_release_{8,16} call as last resort instead of doing nothing [PR117642]
As the following testcases show, in case of multi-word
__sync_lock_test_and_set where we don't actually support atomics for that
size (__int128 for x86_64 lp64 with -mno-cx16, long long for ia32 with
-march=i{3,4}86), as the last fallback if we don't know anything else
we just emit calls to __sync_lock_test_and_set_{8,16}. Those aren't defined
in libatomic, but perhaps users could define them themselves.
While __sync_lock_release if it gives up and has no way to emit the atomic
store just does nothing at all, so no clear sign to the users something
went wrong and that the code will not do what they expected.
This regressed when __atomic_* support has been introduced, previously we
would just emit those calls even in this case.
The patch just emits the call as the last fallback.
2024-11-27 Jakub Jelinek <jakub@redhat.com>
PR target/117642
* builtins.cc (expand_builtin_sync_lock_release): Change return type
from void to rtx, return result of expand_atomic_store.
(expand_builtin) <case BUILT_IN_SYNC_LOCK_RELEASE_16>: If
expand_builtin_sync_lock_release returns NULL, do a break rather
than return const0_rtx.
* gcc.target/i386/pr117642-1.c: New test.
* gcc.target/i386/pr117642-2.c: New test.
Jakub Jelinek [Wed, 27 Nov 2024 13:32:07 +0000 (14:32 +0100)]
match.pd: Avoid introducing UB in the ((X /[ex] C1) +- C2) * (C1 * C3) simplification [PR117692]
As the pr117692.c testcase shows, the generalized pattern can introduce
UB when there wasn't any.
The old pattern was I believe correct, it is as if in the new
pattern C3 was always 1 and I don't see how that could have introduced
UB.
But if type is signed and C3 (aka factor) isn't 1 and for + X and C2
could have different sign or for - X and C2 could have the same sign,
when doing the addition/subtraction first the absolute value could
decrease, while if first multiplying by C3 we could invoke UB already
during that multiplication.
The following patch fixes it by going through the casts to utype if
ranger (get_range_pos_neg) detects the sign compared to sign of C2
(INTEGER_CST) could be the same or could be different depending on op
because then the absolute value will not increase.
Other possibility (perhaps as another check if this check doesn't succeed)
would be to test whether X * C3 could actually overflow.
vr-values.cc has check_for_binary_op_overflow (currently not exported)
which I think does what we'd need to check, if it returns true and sets
ovf to false.
2024-11-27 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/117692
* tree.cc (get_range_pos_neg): Adjust function comment, use
non-negative instead of positive.
* match.pd
(((X /[ex] C1) +- C2) * (C1 * C3) -> (X * C3) +- (C1 * C2 * C3)):
Use casts to utype if type is signed, factor isn't 1 and
C1 and C2 could have different sign for + or could have the
same sign for -.
* gcc.dg/tree-ssa/mulexactdiv-5.c: Expect 8 nop_exprs.
* gcc.dg/tree-ssa/pr117692.c: New test.
Jason Merrill [Tue, 19 Nov 2024 23:21:00 +0000 (00:21 +0100)]
libstdc++: module std fixes
Some tests were failing due to the exported using declaration of iter_move
conflicting with friend declarations; the exported using needs to be in the
inline namespace, like the customization point itself, rather than
std::ranges.
Also add a few missing exports.
Some tests failed to find some operators defined in implementation-detail
namespaces; this exports them as well, but as previously discussed it's
probably preferable to make those operators friends so ADL can find them
that way.
libstdc++-v3/ChangeLog:
* src/c++23/std.cc.in: Fix iter_move/swap. Add fold_left_first, to,
concat, and some operators.
Jonathan Wakely [Fri, 15 Nov 2024 22:03:20 +0000 (22:03 +0000)]
libstdc++: Add debug assertions to std::list and std::forward_list
While working on fancy pointer support for the linked lists I noticed
they didn't have any debug assertions. This adds the obvious non-empty
assertions to front() and back().
Jonathan Wakely [Mon, 25 Nov 2024 21:57:57 +0000 (21:57 +0000)]
libstdc++: Simplify std::forward_list assignment using 'if constexpr'
Use diagnostic pragmas to allow using `if constexpr` in C++11 mode, so
that we don't need to use tag dispatching.
The unused member functions are preserved for the purposes of explicit
instantiations. The _M_assign function template can be removed, because
member function templates aren't instantiated by explicit instantiations
anyway.
libstdc++-v3/ChangeLog:
* include/bits/forward_list.h (operator=(forward_list&&)): Use
if constexpr instead of dispatching to _M_move_assign.
(assign(InputIterator, InputIterator)): Use if constexpr instead
of dispatching to _M_assign.
(assign(size_type, const T&)): Use if constexpr instead of
dispatching to _M_assign_n.
(_M_move_assign, _M_assign_n): Do not define for versioned
namespace.
(_M_assign): Remove.
Jonathan Wakely [Mon, 25 Nov 2024 21:57:57 +0000 (21:57 +0000)]
libstdc++: Simplify std::list assignment using 'if constexpr'
Use diagnostic pragmas to allow using `if constexpr` in C++11 mode, so
that we don't need to use tag dispatching.
The _M_move_assign overloads that were previously used for tag
dispatching are no longer used, but are retained here (at least for the
default config) so that an explicit instantiation will still define
those members. This ensures that old code which expects an explicit
instantiation in some other translation unit will still link. I'm not
sure if that's really needed, we should probably have a policy about
whether we support explicit instantiations where the declaration and
definition use different versions of the headers.
libstdc++-v3/ChangeLog:
* include/bits/stl_list.h (operator=(list&&)): Use if constexpr
instead of dispatching to _M_move_assign.
(_M_move_assign): Do not define for versioned namespace.
Jonathan Wakely [Tue, 26 Nov 2024 20:07:33 +0000 (20:07 +0000)]
libstdc++: Fix unsigned wraparound in codecvt::do_length [PR105857]
When the max argument to std::codecvt<wchar_t, char, mbstate_t>::length
is SIZE_MAX/4+1 or greater the multiplication with sizeof(wchar_t) will
wrap to a small value, and the alloca call will have a buffer that's
smaller than requested. The call to mbsnrtowcs then has a buffer that is
smaller than the value passed as the buffer length. When libstdc++.so is
built with -D_FORTIFY_SOURCE=3 the mismatched buffer and length will get
detected and will abort inside Glibc.
When it doesn't abort, there's no buffer overflow because Glibc's
mbsnrtowcs has the same len * sizeof(wchar_t) calculation to determine
the size of the buffer in bytes, and that will wrap to the same small
number as the alloca argument. So luckily Glibc agrees with the caller
about the real size of the buffer, and won't overflow it.
Even when the max argument isn't large enough to wrap, it can still be
much too large to safely pass to alloca, so we should limit that. We
already have a loop that processes chunks so that we can handle null
characters in the middle of the input. If we limit the alloca buffer to
4kB then we'll just loop each time that buffer is filled.
libstdc++-v3/ChangeLog:
PR libstdc++/105857
* config/locale/dragonfly/codecvt_members.cc (do_length): Limit
size of alloca buffer to 4k.
* config/locale/gnu/codecvt_members.cc (do_length): Likewise.
* testsuite/22_locale/codecvt/length/wchar_t/105857.cc: New
test.
Alexandre Oliva [Wed, 27 Nov 2024 09:27:12 +0000 (06:27 -0300)]
ifcombine: skip fallback conjunction on noncontiguous blocks
When everything else fails, if enabled by the target or by a
parameter, and when other requirements are satisfied, ifcombine
generates an AND of both conditions.
That may be good for contiguous conditions, but it's unlikely to be an
optimization when the blocks are separate.
Add contiguity to the set of requirements for this fallback
transformation.
for gcc/ChangeLog
* tree-ssa-ifcombine.cc (ifcombine_ifandif): Avoid fallback
conjunction of noncontiguous conditions.
PR fortran/84674
* class.cc (add_proc_comp): If the component points to a tbp
that is abstract, do not return since the new version is more
likely to be usable.
PR fortran/117768
* resolve.cc (resolve_fl_derived): Remove the condition that
rejected a completely empty derived type extension.
gcc/testsuite/ChangeLog
PR fortran/117768
* gfortran.dg/pr117768.f90: New test.
* c-parser.cc (c_parser_compound_statement_nostart): Use
OPT_Wfree_labels for warning about labels on declarations.
(c_parser_compound_statement_nostart): Use OPT_Wfree_labels
for warning about labels at end of compound statements.
gcc/
* doc/invoke.texi: Document -Wfree-labels.
gcc/testsuite/
* gcc.dg/Wfree-labels-1.c: New test.
* gcc.dg/Wfree-labels-2.c: New test.
* gcc.dg/Wfree-labels-3.c: New test.
Jason Merrill [Tue, 26 Nov 2024 12:50:49 +0000 (07:50 -0500)]
c++: modules and local static
Here we weren't emitting the guard variable for 'a' when we emitted 'afn'
in the importer, because we only treated inline variables as needing that.
Fixed by generalizing to vague_linkage_p.
But we need to specifically exempt vtables, because the rest of the module
code handles them specially and expects them to be DECL_EXTERNAL.
Jason Merrill [Tue, 26 Nov 2024 21:19:05 +0000 (16:19 -0500)]
libcpp: modules and -include again
I enabled include translation to header units in r15-1104-ga29f481bbcaf2b,
but it seems that patch wasn't sufficient, as any diagnostics in the main
source file would show up as coming from the header instead.
Fixed by setting buffer->file for leaving the file transition that my
previous patch made us enter. And don't push a buffer of newlines, in this
case that messes up line numbers instead of aligning them.
libcpp/ChangeLog:
* files.cc (_cpp_stack_file): Handle -include of header unit more
specially.
gcc/testsuite/ChangeLog:
* g++.dg/modules/dashinclude-1_b.C: Add an #error.
* g++.dg/modules/dashinclude-1_a.H: Remove dg-module-do run.
Andi Kleen [Thu, 31 Oct 2024 17:26:16 +0000 (10:26 -0700)]
PR117350: Keep assembler name for abstract decls for autofdo
autofdo looks up inline stacks and tries to match them with the profile
data using their symbol name. Make sure all decls that can be in a inline stack
have a valid assembler name.
This fixes a bootstrap problem with autoprofiledbootstrap and LTO.
2024-10-30 Jason Merrill <jason@redhat.com>
Andrew Pinski <quic_apinski@quicinc.com>
Andi Kleen <ak@gcc.gnu.org>
gcc/ChangeLog:
PR bootstrap/117350
* tree.cc (need_assembler_name_p): Keep assembler name
for abstract declarations when autofdo is used.
Harald Anlauf [Tue, 26 Nov 2024 19:37:35 +0000 (20:37 +0100)]
Fortran: fix minor front-end memleaks
gcc/fortran/ChangeLog:
* expr.cc (find_inquiry_ref): Fix memleak introduced by scanning
the reference chain to find and simplify inquiry references.
* symbol.cc (gfc_copy_formal_args_intr): Free formal namespace
when not needed to avoid a front-end memleak.
Andrew Pinski [Tue, 26 Nov 2024 21:38:15 +0000 (13:38 -0800)]
aarch64: Update error message check for __builtin_launder check of sve-sizeless-2.C
r15-3614-g9fe57e4879de93 changed the error message for __builtin_launder but this testcase
was not updated for the new format of the error message since it is an aarch64 specific
testcase.
This patch updates the expected error message.
Pushed as obvious after testing to see the testcase now works.
gcc/testsuite/ChangeLog:
* g++.dg/ext/sve-sizeless-2.C: Update the expected error message
for __builtin_launder.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Tue, 26 Nov 2024 21:05:00 +0000 (13:05 -0800)]
aarch64: Fix fp8_scalar_1.c's stacktest1
The function body test was expecting:
umov w0, v0.b[0]
strb w0, [sp, 15]
But the code generation was improved after r15-5375-gbeec291225be to just:
str b0, [sp, 15]
which is correct and better because no longer need to move between SIMD registers
and the GPRs.
This changes the function body test to new better code generation.
Pushed as obvious after a test of the testcase to make sure it now passes.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/fp8_scalar_1.c (stacktest1): Fix for new
improved code generation.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
David Malcolm [Tue, 26 Nov 2024 21:09:37 +0000 (16:09 -0500)]
selftest: invoke "diff" when ASSERT_STREQ fails
Currently when ASSERT_STREQ or ASSERT_STREQ_AT fail we print
both strings to stderr. However it can be hard to figure out
the problem (e.g. for 1-character differences in long strings).
Extend the output by writing out the strings to tempfiles and
invoking "diff -up" on them when we have such a selftest failure,
to (I hope) simplify debugging.
gcc/ChangeLog:
* selftest.cc (selftest::print_diff): New function.
(selftest::assert_streq): Call it when we have non-equal
non-null strings.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Tue, 26 Nov 2024 21:01:35 +0000 (16:01 -0500)]
testsuite: rename plugins from .c to .cc
In r12-6650-g5c69acb32329d4 we updated our sources from .c to .cc
since for some time GCC has been implemented in C++, not C.
GCC plugins are also implemented in C++, not C, but the plugins
in our testsuite still have .c extensions.
Rename the plugin implementation files in the testsuite from .c to .cc,
for consistency with GCC's implementation files (as opposed to .C,
which is used in C++ parts of the testsuite).
Don't rename the files that the plugins are tested *on*.
David Malcolm [Tue, 26 Nov 2024 20:58:25 +0000 (15:58 -0500)]
csky: use quotes when referring to cpus and archs [PR90160]
gcc/ChangeLog:
PR translation/90160
* config/csky/csky.cc (csky_configure_build_target): Use %qs when
referring to cpu and arch names.
(csky_option_override): Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Harald Anlauf [Mon, 25 Nov 2024 21:55:10 +0000 (22:55 +0100)]
Fortran: passing inquiry ref of complex array to assumed rank dummy [PR117774]
PR fortran/117774
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_conv_procedure_call): When passing an array
to an assumed-rank dummy, terminate search for array reference of
actual argument before an inquiry reference (e.g. INQUIRY_RE,
INQUIRY_IM) so that bounds update works properly.
Alex Coplan [Tue, 26 Nov 2024 15:10:29 +0000 (15:10 +0000)]
gdbhooks: Handle references to vec* in VecPrinter
vec.h has this method:
template<typename T, typename A>
inline T *
vec_safe_push (vec<T, A, vl_embed> *&v, const T &obj CXX_MEM_STAT_INFO)
where v is a reference to a pointer to vec. This matches the regex for
VecPrinter, so gdbhooks.py attempts to print it but chokes on the reference.
I see the following:
#1 0x0000000002b84b7b in vec_safe_push<edge_def*, va_gc> (v=Traceback (most
recent call last):
File "$SRC/gcc/gcc/gdbhooks.py", line 486, in to_string
return '0x%x' % intptr(self.gdbval)
File "$SRC/gcc/gcc/gdbhooks.py", line 168, in intptr
return long(gdbval) if sys.version_info.major == 2 else int(gdbval)
gdb.error: Cannot convert value to long.
This patch makes VecPrinter handle such references by stripping them
(dereferencing) at the top of the relevant functions.
gcc/ChangeLog:
* gdbhooks.py (strip_ref): New. Use it ...
(VecPrinter.to_string): ... here,
(VecPrinter.children): ... and here.
Pan Li [Mon, 25 Nov 2024 03:45:30 +0000 (11:45 +0800)]
RISC-V: Refactor the testcases for RVV gather/scatter
This patch would like to refactor the testcases of gather/scatter
after sorts of optimization option passing to testcase. Includes:
* Remove unnecessary optimization options.
* Adjust dg-final by any-opts and/or no-opts if the rtl dump changes
on different optimization options (like O2, O3).
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
It is test only patch and obvious up to a point, will commit it
directly if no comments in next 48H.
Pan Li [Mon, 25 Nov 2024 03:45:29 +0000 (11:45 +0800)]
RISC-V: Fix incorrect optimization options passing to gather/scatter
Like the strided load/store, the testcases of vector gather/scatter are
designed to pick up different sorts of optimization options but actually
these option are ignored according to the Execution log of gcc.log. This patch
would like to make it correct almost the same as what we fixed for
strided load/store.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
It is test only patch and obvious up to a point, will commit it
directly if no comments in next 48H.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/rvv.exp: Fix the incorrect optimization
options passing to testcases.
Jan Hubicka [Tue, 26 Nov 2024 12:52:09 +0000 (13:52 +0100)]
improve std::deque::_M_reallocate_map
Looking into reason why we still do throw_bad_alloc in clang binary I noticed
that quite few calls come from deque::_M_reallocate_map. This patch adds
unreachable to limit the size of realloc_map. _M_reallocate_map is called only
if new size is smaller then max_size. map is an array holding pointers to
entries of fixed size.
Since rellocation is done by doubling the map size, I think the maximal size of
map allocated is max_size / deque_buf_size rounded up times two. This should
be also safe for overflows since we have extra bit.
map size is always at least 8. Theoretically this computation may be wrong for
very large T, but in that case callers should never reallocate.
On the testcase I get:
jh@shroud:~> ~/trunk-install-new4/bin/g++ -O2 dq.C -c ; size -A dq.o | grep text
.text 284 0
.text._ZNSt5dequeIiSaIiEE17_M_reallocate_mapEmb 485 0
.text.unlikely 10 0
jh@shroud:~> ~/trunk-install-new5/bin/g++ -O2 dq.C -c ; size -A dq.o | grep text
.text 284 0
.text._ZNSt5dequeIiSaIiEE17_M_reallocate_mapEmb 465 0
.text.unlikely 10 0
so this saves about 20 bytes of rellocate_map, which I think is worthwhile.
Curiously enough gcc14 does:
jh@shroud:~> g++ -O2 dq.C -c ; size -A dq.o | grep text
.text 604 0
.text.unlikely 10 0
which is 145 bytes smaller. Obvoius difference is that _M_reallocate_map gets inlined.
Compiling gcc14 preprocessed file with trunk gives:
jh@shroud:~> g++ -O2 dq.C -S ; size -A dq.o | grep text
.text 762 0
.text.unlikely 10 0
So inlining is due to changes at libstdc++ side, but code size growth is due to
something else.
For clang this reduced number of thris_bad_new_array_length from 121 to 61.
libstdc++-v3/ChangeLog:
* include/bits/deque.tcc (std::deque::_M_reallocate_map): Add
__builtin_unreachable check to declare that maps are not very large.
* include/bits/stl_deque.h (std::deque::size): Add __builtin_unreachable
to check for maximal size of map.
gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/deque-1.C: New test.
* g++.dg/tree-ssa/deque-2.C: New test.
Eric Botcazou [Mon, 11 Nov 2024 10:16:26 +0000 (11:16 +0100)]
ada: Do not use ATTR_ADDR_EXPR for 'Unrestricted_Access
Unlike for 'Access or 'Unchecked_Access, the Attribute_to_gnu routine passes
ATTR_ADDR_EXPR to build_unary_op for 'Unrestricted_Access, which causes the
processing done in build_unary_op to flatten the reference, in particular to
remove all intermediate (view) conversions, which may be problematic for the
SUBSTITUTE_PLACEHOLDER_IN_EXPR machinery.
gcc/ada/ChangeLog:
* gcc-interface/trans.cc (Attribute_to_gnu) <Attr_Access>: Do not
pass ATTR_ADDR_EXPR to build_unary_op for 'Unrestricted_Access.
Eric Botcazou [Tue, 12 Nov 2024 18:46:12 +0000 (19:46 +0100)]
ada: Add minimal support for address clause/aspect on controlled objects
The clause and aspect have been accepted by the compiler for a few years,
but the result is generally an internal compiler error or an incorrect
finalization at run time.
gcc/ada/ChangeLog:
* exp_ch3.adb (Expand_N_Object_Declaration): Do not insert the tag
assignment there if the object has the Address aspect.
* exp_ch7.adb: Add clauses for Aspect package.
(Build_Finalizer.Process_Object_Declaration): Deal with an object
with delayed freezing.
(Insert_Actions_In_Scope_Around): If the target is the declaration
of an object with address clause or aspect, move all the statements
that have been inserted after it into the Initialization_Statements
list of the object.
* freeze.adb (Check_Address_Clause): Do not reassign the tag here,
instead set the appropriate flag on the assignment statement.
Eric Botcazou [Wed, 13 Nov 2024 08:42:01 +0000 (09:42 +0100)]
ada: Minor adjustments to error message for RM B.1(24)
The RM B.1(24) sub-clause says that imported entities cannot be initialized
and it is checked in three contexts, aspect Import, pragma Import and pragma
Import_Object, with slightly different error messages. Moreover, for the
aspect, the error is given twice because that of the pragma is also given.
In addition, if the initialization expression is an aggregate that is not
static, the error is given only for the aspect and not for the two pragmas.
This change aligns the error messages on that of pragma Import and plugs the
aforementioned loophole for the two pragmas.
gcc/ada/ChangeLog:
* sem_ch13.adb (Analyze_Aspect_Export_Import): Add explicit mention
of the declaration in the error message for the Import.
* sem_prag.adb (Process_Extended_Import_Export_Object_Pragma): Also
test Has_Init_Expression on the declaration node for Import_Object
and use the same wording as that of Import.
(Process_Import_Or_Interface): Also test Has_Init_Expression on the
declaration node for Import.
Javier Miranda [Tue, 29 Oct 2024 08:31:28 +0000 (08:31 +0000)]
ada: Refactor code of Check_Ambiguous_Call and Valid_Conversion
Code cleanup; factorizing code.
gcc/ada/ChangeLog:
* sem_ch2.adb (Check_Ambiguous_Call): Replace code factorized
code by call to the new subprogram Is_Ambiguous_Operand.
* sem_res.ads (Is_Ambiguous_Operand): New subprogram that
factorizes previous code in Check_Ambiguous_Call and
Valid_Conversion.
* sem_res.adb (Is_Ambiguous_Operand): New subprogram.
(Valid_Tagged_Conversion): Replace factorized code by call to
the new subprogram Is_Ambiguous_Operand.
(Report_Error_N): New subprogram.
(Report_Error_NE): New subprogram.
(Report_Interpretation): New subprogram.
(Conversion_Error_N): Removed; replaced by Report_Error_N.
(Conversion_Error_NE): Removed; replaced by Report_Error_NE.
(Valid_Conversion): Update Opnd_Type after the call to
Is_Ambiguous_Operand in the overloaded case.
Viljar Indus [Mon, 11 Nov 2024 09:01:12 +0000 (11:01 +0200)]
ada: Remove Warn_Runtime_Raise attribute from Error_Msg_Object
The goal of this attribute is to raise a warning to an error when
the -gnatwE flag is used. This is similar to the existing warnings
as error behavior under the Warn_Err flag so it can be merged.
gcc/ada/ChangeLog:
* errout.adb: Set Warn_Err as true if Is_Runtime_Error was
set in the error message.
* erroutc.adb: Remove instances of Warn_Runtime_Raise.
* erroutc.ads: Likewise.
* errutil.adb: Likewise.
Viljar Indus [Mon, 11 Nov 2024 08:19:21 +0000 (10:19 +0200)]
ada: Refactor checking redundant messages
Move common code between errout and errutil into a single function.
gcc/ada/ChangeLog:
* errout.adb: Use Is_Redundant_Error_Message.
* erroutc.adb: Move the common code for checking if a message
can be removed to Is_Redundant_Error_Message.
* erroutc.ads: Add definition of Is_Redundant_Error_Message.
* errutil.adb: Use Is_Redundant_Error_Message.
Viljar Indus [Tue, 5 Nov 2024 08:42:55 +0000 (10:42 +0200)]
ada: Remove Current_Node from Errout
This variable was used for Opt.Include_Subprogram_In_Messages
activated by -gnatdJ. This switch has been removed so this variable
is no longer used.
gcc/ada/ChangeLog:
* errout.ads: Remove Current_Node.
* errout.adb: Remove uses of Current_Node.
* par-ch6.adb: Same as above.
* par-ch7.adb: Same as above.
* par-ch9.adb: Same as above.
Viljar Indus [Mon, 4 Nov 2024 12:16:02 +0000 (14:16 +0200)]
ada: Remove Raise_Exception_On_Error
Raise_Exception_On_Error is never modified so it can be removed.
gcc/ada/ChangeLog:
* err_vars.ads: Remove Raise_Exception_On_Error and
Error_Msg_Exception.
* errout.ads: Same as above.
* errout.adb: Remove uses of Raise_Exception_On_Error and
Error_Msg_Exception.
* errutil.adb: Same as above.
Viljar Indus [Thu, 31 Oct 2024 13:50:46 +0000 (15:50 +0200)]
ada: Store error message kind as an enum
Simplify the storage for the kind of error message under a single
enumerator. This replaces the existing attributes with the following
enumeration values.
* Is_Warning_Msg => Warning
* Is_Style_Msg => Style
* Is_Info_Msg => Info
* Is_Check_Msg => Low_Check, Medium_Check, High_Check
* Is_Serious_Error => Error, if the attribute was false then
Non_Serious_Error.
gcc/ada/ChangeLog:
* diagnostics-converter.adb: Use new enum values instead
of the old attributes.
* diagnostics-switch_repository.adb: Same as above.
* diagnostics-utils.adb: Same as above.
* diagnostics.adb: Same as above.
* diagnostics.ads: Same as above.
* errout.adb: Same as above.
* erroutc.adb: Same as above.
* erroutc.ads: Remove old attriubtes and replace them
with Error_Msg_Kind.
* errutil.adb: Same as others.
Viljar Indus [Fri, 1 Nov 2024 11:15:21 +0000 (13:15 +0200)]
ada: Refactor code for printing the error location
gcc/ada/ChangeLog:
* errout.adb: Use Output_Msg_Location
* erroutc.adb: add common implementation for printing the
error message line.
* erroutc.ads: Add new method Output_Msg_Location
* errutil.adb: use Output_Msg_Location
projects / thirdparty / gcc.git / log
