| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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/
* builtin-types.def (BT_FN_UINT8_UINT8_UINT8_CONST_SIZE): Define.
(BT_FN_UINT16_UINT16_UINT8_CONST_SIZE): Likewise.
(BT_FN_UINT16_UINT16_UINT16_CONST_SIZE): Likewise.
(BT_FN_UINT32_UINT32_UINT8_CONST_SIZE): Likewise.
(BT_FN_UINT32_UINT32_UINT16_CONST_SIZE): Likewise.
(BT_FN_UINT32_UINT32_UINT32_CONST_SIZE): Likewise.
(BT_FN_UINT64_UINT64_UINT8_CONST_SIZE): Likewise.
(BT_FN_UINT64_UINT64_UINT16_CONST_SIZE): Likewise.
(BT_FN_UINT64_UINT64_UINT32_CONST_SIZE): Likewise.
(BT_FN_UINT64_UINT64_UINT64_CONST_SIZE): Likewise.
* builtins.cc (associated_internal_fn): Handle CRC related builtins.
(expand_builtin_crc_table_based): New function.
(expand_builtin): Handle CRC related builtins.
* builtins.def (BUILT_IN_CRC8_DATA8): New builtin.
(BUILT_IN_CRC16_DATA8): Likewise.
(BUILT_IN_CRC16_DATA16): Likewise.
(BUILT_IN_CRC32_DATA8): Likewise.
(BUILT_IN_CRC32_DATA16): Likewise.
(BUILT_IN_CRC32_DATA32): Likewise.
(BUILT_IN_CRC64_DATA8): Likewise.
(BUILT_IN_CRC64_DATA16): Likewise.
(BUILT_IN_CRC64_DATA32): Likewise.
(BUILT_IN_CRC64_DATA64): Likewise.
(BUILT_IN_REV_CRC8_DATA8): New builtin.
(BUILT_IN_REV_CRC16_DATA8): Likewise.
(BUILT_IN_REV_CRC16_DATA16): Likewise.
(BUILT_IN_REV_CRC32_DATA8): Likewise.
(BUILT_IN_REV_CRC32_DATA16): Likewise.
(BUILT_IN_REV_CRC32_DATA32): Likewise.
(BUILT_IN_REV_CRC64_DATA8): Likewise.
(BUILT_IN_REV_CRC64_DATA16): Likewise.
(BUILT_IN_REV_CRC64_DATA32): Likewise.
(BUILT_IN_REV_CRC64_DATA64): Likewise.
* builtins.h (expand_builtin_crc_table_based): New function
declaration.
* doc/extend.texi: Add documentation for new CRC builtins.
gcc/testsuite/
* 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>
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
gcc/testsuite/
* gcc.dg/pr117757-1.c: New test.
|
|
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.
PR c/91193
gcc/c/
* c-parser.cc (c_parser_maybe_reclassify_token): Define earlier.
(c_parser_declaration_or_fndef): Call
c_parser_maybe_reclassify_token before parsing old-style parameter
definitions.
gcc/testsuite/
* gcc.dg/pr91193-1.c, gcc.dg/pr91193-2.c: New tests.
|
|
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>
|
|
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.
* gcc.dg/pr117745.c: New test.
|
|
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.
gcc/testsuite/
* gcc.dg/c23-typeof-5.c: New test.
|
|
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.
|
|
This is another recent GCC extension whose use is apparently
difficult to spot in code reviews.
The name of the option is due to Jonathan Wakely. Part of it
could apply to C++ as well (for labels at the end of a compound
statement).
gcc/c-family/
* c-opts.cc (c_common_post_options): Initialize
warn_free_labels.
* c.opt (Wfree-labels): New option.
* c.opt.urls: Regenerate.
gcc/c/
* 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.
|
|
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*.
gcc/testsuite/ChangeLog:
* g++.dg/plugin/plugin.exp (plugin_test_list): Update for renaming
of all plugin implementation files from .c to .cc.
* g++.dg/plugin/attribute_plugin.c: Rename to...
* g++.dg/plugin/attribute_plugin.cc: ...this.
* g++.dg/plugin/comment_plugin.c: Rename to...
* g++.dg/plugin/comment_plugin.cc: ...this.
* g++.dg/plugin/decl_plugin.c: Rename to...
* g++.dg/plugin/decl_plugin.cc: ...this.
* g++.dg/plugin/def_plugin.c: Rename to...
* g++.dg/plugin/def_plugin.cc: ...this.
* g++.dg/plugin/dumb_plugin.c: Rename to...
* g++.dg/plugin/dumb_plugin.cc: ...this.
* g++.dg/plugin/header_plugin.c: Rename to...
* g++.dg/plugin/header_plugin.cc: ...this.
* g++.dg/plugin/pragma_plugin.c: Rename to...
* g++.dg/plugin/pragma_plugin.cc: ...this.
* g++.dg/plugin/selfassign.c: Rename to...
* g++.dg/plugin/selfassign.cc: ...this.
* g++.dg/plugin/show_template_tree_color_plugin.c: Rename to...
* g++.dg/plugin/show_template_tree_color_plugin.cc: ...this.
* gcc.dg/plugin/plugin.exp (plugin_test_list): Update for renaming
of all plugin implementation files from .c to .cc.
* gcc.dg/plugin/analyzer_cpython_plugin.c: Rename to...
* gcc.dg/plugin/analyzer_cpython_plugin.cc: ...this.
* gcc.dg/plugin/analyzer_gil_plugin.c: Rename to...
* gcc.dg/plugin/analyzer_gil_plugin.cc: ...this.
* gcc.dg/plugin/analyzer_kernel_plugin.c: Rename to...
* gcc.dg/plugin/analyzer_kernel_plugin.cc: ...this.
* gcc.dg/plugin/analyzer_known_fns_plugin.c: Rename to...
* gcc.dg/plugin/analyzer_known_fns_plugin.cc: ...this.
* gcc.dg/plugin/crash_test_plugin.c: Rename to...
* gcc.dg/plugin/crash_test_plugin.cc: ...this.
* gcc.dg/plugin/diagnostic_group_plugin.c: Rename to...
* gcc.dg/plugin/diagnostic_group_plugin.cc: ...this.
* gcc.dg/plugin/diagnostic_plugin_show_trees.c: Rename to...
* gcc.dg/plugin/diagnostic_plugin_show_trees.cc: ...this.
* gcc.dg/plugin/diagnostic_plugin_test_inlining.c: Rename to...
* gcc.dg/plugin/diagnostic_plugin_test_inlining.cc: ...this.
* gcc.dg/plugin/diagnostic_plugin_test_metadata.c: Rename to...
* gcc.dg/plugin/diagnostic_plugin_test_metadata.cc: ...this.
* gcc.dg/plugin/diagnostic_plugin_test_nesting.c: Rename to...
* gcc.dg/plugin/diagnostic_plugin_test_nesting.cc: ...this.
* gcc.dg/plugin/diagnostic_plugin_test_paths.c: Rename to...
* gcc.dg/plugin/diagnostic_plugin_test_paths.cc: ...this.
* gcc.dg/plugin/diagnostic_plugin_test_show_locus.c: Rename to...
* gcc.dg/plugin/diagnostic_plugin_test_show_locus.cc: ...this.
* gcc.dg/plugin/diagnostic_plugin_test_string_literals.c: Rename
* gcc.dg/plugin/diagnostic_plugin_test_string_literals.cc: ..to
this.
* gcc.dg/plugin/diagnostic_plugin_test_text_art.c: Rename to...
* gcc.dg/plugin/diagnostic_plugin_test_text_art.cc: ...this.
* gcc.dg/plugin/diagnostic_plugin_test_tree_expression_range.c:
Rename to...
* gcc.dg/plugin/diagnostic_plugin_test_tree_expression_range.cc:
...this.
* gcc.dg/plugin/diagnostic_plugin_xhtml_format.c: Rename to...
* gcc.dg/plugin/diagnostic_plugin_xhtml_format.cc: ...this.
* gcc.dg/plugin/dump_plugin.c: Rename to...
* gcc.dg/plugin/dump_plugin.cc: ...this.
* gcc.dg/plugin/expensive_selftests_plugin.c: Rename to...
* gcc.dg/plugin/expensive_selftests_plugin.cc: ...this.
* gcc.dg/plugin/finish_unit_plugin.c: Rename to...
* gcc.dg/plugin/finish_unit_plugin.cc: ...this.
* gcc.dg/plugin/ggcplug.c: Rename to...
* gcc.dg/plugin/ggcplug.cc: ...this.
* gcc.dg/plugin/location_overflow_plugin.c: Rename to...
* gcc.dg/plugin/location_overflow_plugin.cc: ...this.
* gcc.dg/plugin/must_tail_call_plugin.c: Rename to...
* gcc.dg/plugin/must_tail_call_plugin.cc: ...this.
* gcc.dg/plugin/one_time_plugin.c: Rename to...
* gcc.dg/plugin/one_time_plugin.cc: ...this.
* gcc.dg/plugin/poly-int-01_plugin.c: Rename to...
* gcc.dg/plugin/poly-int-01_plugin.cc: ...this.
* gcc.dg/plugin/poly-int-02_plugin.c: Rename to...
* gcc.dg/plugin/poly-int-02_plugin.cc: ...this.
* gcc.dg/plugin/poly-int-03_plugin.c: Rename to...
* gcc.dg/plugin/poly-int-03_plugin.cc: ...this.
* gcc.dg/plugin/poly-int-04_plugin.c: Rename to...
* gcc.dg/plugin/poly-int-04_plugin.cc: ...this.
* gcc.dg/plugin/poly-int-05_plugin.c: Rename to...
* gcc.dg/plugin/poly-int-05_plugin.cc: ...this.
* gcc.dg/plugin/poly-int-06_plugin.c: Rename to...
* gcc.dg/plugin/poly-int-06_plugin.cc: ...this.
* gcc.dg/plugin/poly-int-07_plugin.c: Rename to...
* gcc.dg/plugin/poly-int-07_plugin.cc: ...this.
* gcc.dg/plugin/selfassign.c: Rename to...
* gcc.dg/plugin/selfassign.cc: ...this.
* gcc.dg/plugin/start_unit_plugin.c: Rename to...
* gcc.dg/plugin/start_unit_plugin.cc: ...this.
* gcc.dg/plugin/wide-int_plugin.c: Rename to...
* gcc.dg/plugin/wide-int_plugin.cc: ...this.
* obj-c++.dg/plugin/plugin.exp: Update for renaming of plugin
implementation file from .c to .cc.
* objc.dg/plugin/plugin.exp: Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
|
|
gcc/c/ChangeLog:
PR c/94370
* c-typeck.cc (c_build_functype_attribute_variant): Reword
warning message to avoid double-negative.
gcc/testsuite/ChangeLog:
PR c/94370
* gcc.dg/format/proto.c: Update wording of message.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
|
|
gcc/ChangeLog:
PR translation/80760
* tree-ssa-loop-prefetch.cc (pass_loop_prefetch::execute): Add
missing colon to not-a-power-of-two param warning.
gcc/testsuite/ChangeLog:
PR translation/80760
* gcc.dg/tree-ssa/pr79803.c: Add ':' to expected warning.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
|
|
This patch is similar to the one I've just posted, __builtin_fpclassify also
needs to print decimal float minimum differently and use real_from_string3.
Plus I've done some formatting fixes.
2024-11-26 Jakub Jelinek <jakub@redhat.com>
PR middle-end/102674
* builtins.cc (fold_builtin_fpclassify): Use real_from_string3 rather
than real_from_string. Use "1E%d" format string rather than "0x1p%d"
for decimal float minimum. Formatting fixes.
* gcc.dg/dfp/pr102674.c: New test.
|
|
__builtin_is{inf,finite,normal} builtins ICE on _Decimal{32,64,128,64x}
operands unless those operands are constant.
The problem is that we fold the builtins to comparisons with the largest
finite number, but
a) get_max_float was only handling binary floats
b) real_from_string again assumes binary float
and so we were ICEing in the build_real called after the two calls.
This patch adds decimal handling into get_max_float (well, moves it
from c-cppbuiltin.cc which was printing those for __DEC{32,64,128}_MAX__
macros) and uses real_from_string3 (perhaps it is time to rename it
to just real_from_string now that we can use function overloading)
so that it handles both binary and decimal floats.
2024-11-26 Jakub Jelinek <jakub@redhat.com>
PR middle-end/43374
gcc/
* real.cc (get_max_float): Handle decimal float.
* builtins.cc (fold_builtin_interclass_mathfn): Use
real_from_string3 rather than real_from_string. Use
"1E%d" format string rather than "0x1p%d" for decimal
float minimum.
gcc/c-family/
* c-cppbuiltin.cc (builtin_define_decimal_float_constants): Use
get_max_float.
gcc/testsuite/
* gcc.dg/dfp/pr43374.c: New test.
|
|
As reported in bug 98195, there are ICEs from an _Atomic compound
assignment with an incomplete type on the RHS, arising from an invalid
temporary being created with such a type. As reported in bug 117755,
there are also (different) ICEs in cases with complete types where the
binary operation itself is invalid, when inside a nested function,
arising from a temporary being created for the RHS, but then not used
because the binary operation returns error_mark_node, resulting in the
temporary not appearing in a TARGET_EXPR, never getting its
DECL_CONTEXT set by the gimplifier and eventually resulting in an ICE
in nested function processing (trying to find a function context for
the temporary) as a result.
Fix the first ICE with an earlier check for a complete type for the
RHS of an assignment so the problematic temporary is never created for
an incomplete type (which changes the error message three existing
tests get for that case; the new message seems as good as the old
one). Fix the second ICE by ensuring that once a temporary has been
created, it always gets a corresponding TARGET_EXPR even on error.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/98195
PR c/117755
gcc/c/
* c-typeck.cc (build_atomic_assign): Always create a TARGET_EXPR
for newval even in case of error from binary operation.
(build_modify_expr): Check early for incomplete type of rhs.
gcc/testsuite/
* gcc.dg/pr98195-1.c, gcc.dg/pr117755-1.c: New tests.
* gcc.dg/noncompile/20020207-1.c, gcc.dg/pr14765-1.c,
objc.dg/method-11.m: Update expected error messages.
|
|
The outgoing stack slot size may be different from the BLKmode argument
size due to parameter alignment. Check partial != 0 for BLKmode argument
passed on stack.
gcc/
PR middle-end/117098
* calls.cc (store_one_arg): Check partial != 0 for BLKmode argument
passed on stack.
gcc/testsuite/
PR middle-end/117098
* gcc.dg/sibcall-12.c: New test.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
nios2 target support in GCC was deprecated in GCC 14 as the
architecture has been EOL'ed by the vendor. This patch removes the
entire port for GCC 15
There are still references to "nios2" in libffi and libgo. Since those
libraries are imported into the gcc sources from master copies maintained
by other projects, those will need to be addressed elsewhere.
ChangeLog:
* MAINTAINERS: Remove references to nios2.
* configure.ac: Likewise.
* configure: Regenerated.
config/ChangeLog:
* mt-nios2-elf: Deleted.
contrib/ChangeLog:
* config-list.mk: Remove references to Nios II.
gcc/ChangeLog:
* common/config/nios2/*: Delete entire directory.
* config/nios2/*: Delete entire directory.
* config.gcc: Remove references to nios2.
* configure.ac: Likewise.
* doc/extend.texi: Likewise.
* doc/install.texi: Likewise.
* doc/invoke.texi: Likewise.
* doc/md.texi: Likewise.
* regenerate-opt-urls.py: Likewise.
* config.in: Regenerated.
* configure: Regenerated.
gcc/testsuite/ChangeLog:
* g++.target/nios2/*: Delete entire directory.
* gcc.target/nios2/*: Delete entire directory.
* g++.dg/cpp0x/constexpr-rom.C: Remove refences to nios2.
* g++.old-deja/g++.jason/thunk3.C: Likewise.
* gcc.c-torture/execute/20101011-1.c: Likewise.
* gcc.c-torture/execute/pr47237.c: Likewise.
* gcc.dg/20020312-2.c: Likewise.
* gcc.dg/20021029-1.c: Likewise.
* gcc.dg/debug/btf/btf-datasec-1.c: Likewise.
* gcc.dg/ifcvt-4.c: Likewise.
* gcc.dg/stack-usage-1.c: Likewise.
* gcc.dg/struct-by-value-1.c: Likewise.
* gcc.dg/tree-ssa/reassoc-33.c: Likewise.
* gcc.dg/tree-ssa/reassoc-34.c: Likewise.
* gcc.dg/tree-ssa/reassoc-35.c: Likewise.
* gcc.dg/tree-ssa/reassoc-36.c: Likewise.
* lib/target-supports.exp: Likewise.
libgcc/ChangeLog:
* config/nios2/*: Delete entire directory.
* config.host: Remove refences to nios2.
* unwind-dw2-fde-dip.c: Likewise.
|
|
This plugs another hole in alignment checking with VMAT_STRIDED_SLP.
When using an alternate load or store type we have to check whether
that's supported with respect to required vector alignment.
PR tree-optimization/117767
* tree-vect-stmts.cc (vectorizable_store): Check for supported
alignment before using a an alternate store vector type.
(vectorizable_load): Likewise for loads.
* gcc.dg/vect/pr117767.c: New testcase.
|
|
[PR117663]
These tests use the K&R function style definitions or pass arguments
to () functions.
It seemed easiest to just use -std=gnu17 for all of those.
2024-11-25 Jakub Jelinek <jakub@redhat.com>
PR testsuite/117663
* gcc.target/powerpc/pr58673-1.c: Add -std=gnu17 to dg-options.
* gcc.target/powerpc/pr64505.c: Likewise.
* gcc.target/powerpc/pr116170.c: Likewise.
* gcc.target/powerpc/pr58673-2.c: Likewise.
* gcc.target/powerpc/pr64019.c: Likewise.
* gcc.target/powerpc/pr96506-1.c: Likewise.
* gcc.target/powerpc/swaps-stack-protector.c: Likewise.
* gcc.target/powerpc/pr78543.c: Likewise.
* gcc.dg/vect/pr48765.c: Add -std=gnu17 to dg-additional-options.
|
|
The loop unrolling code assumes that one third of all volatile accesses
can be possibly optimized away which is of course not true. This leads
to excessive unrolling in some cases. The following tracks the number
of stmts with side-effects as those are not eliminatable later and
only assumes one third of the other stmts can be further optimized.
This causes some fallout in the testsuite where we rely on unrolling
even when calls are involved. I have XFAILed g++.dg/warn/Warray-bounds-20.C
but adjusted the others with a #pragma GCC unroll to mimic previous
behavior and retain what the testcase was testing. I've also filed
PR117671 for the case where the size estimation fails to honor the
stmts we then remove by inserting __builtin_unreachable ().
For gcc.dg/tree-ssa/cunroll-2.c the estimate that the code doesn't
grow is clearly bogus and we have explicit code to reject unrolling
for bodies containing calls so I've adjusted the testcase accordingly.
PR tree-optimization/115825
* tree-ssa-loop-ivcanon.cc (loop_size::not_eliminatable_after_peeling):
New.
(loop_size::last_iteration_not_eliminatable_after_peeling): Likewise.
(tree_estimate_loop_size): Count stmts with side-effects as
not optimistically eliminatable.
(estimated_unrolled_size): Compute the number of stmts that can
be optimistically eliminated by followup transforms.
(try_unroll_loop_completely): Adjust.
* gcc.dg/tree-ssa/cunroll-17.c: New testcase.
* gcc.dg/tree-ssa/cunroll-2.c: Adjust to not expect unrolling.
* gcc.dg/pr94600-1.c: Force unrolling.
* c-c++-common/ubsan/unreachable-3.c: Likewise.
* g++.dg/warn/Warray-bounds-20.C: XFAIL cases we rely on
unrolling loops created by new expressions and not inlined
CTOR invocations.
|
|
The problem here is c_parser_skip_until_found stops at a closing nesting
delimiter without consuming it. So if we don't consume it in
c_parser_gimple_compound_statement, we would go into an infinite loop. The C
parser similar code in c_parser_statement_after_labels to handle this specific
case too.
PR c/117741
gcc/c/ChangeLog:
* gimple-parser.cc (c_parser_gimple_compound_statement): Handle
CPP_CLOSE_PAREN/CPP_CLOSE_SQUARE with an error and skipping the token.
gcc/testsuite/ChangeLog:
* gcc.dg/gimplefe-54.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
|
|
As reported in bug 112841, typeof_unqual fails to remove qualifiers
from qualified array types. In C23 (unlike in previous standard
versions), array types are considered to have the qualifiers of the
element type, so typeof_unqual should remove such qualifiers (and an
example in the standard shows that is as intended). Fix this by
calling strip_array_types when checking for the presence of
qualifiers. (The reason we check for qualifiers rather than just
using TYPE_MAIN_VARIANT unconditionally is to avoid, as a quality of
implementation matter, unnecessarily losing typedef information in the
case where the type is already unqualified.)
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/112841
gcc/c/
* c-parser.cc (c_parser_typeof_specifier): Call strip_array_types
when checking for type qualifiers for typeof_unqual.
gcc/testsuite/
* gcc.dg/c23-typeof-4.c: New test.
|
|
When the object size estimate is returned for a PHI node, it is the
maximum possible value, which is fine in isolation. When combined with
negative offsets however, it may sometimes end up in zero size because
the resultant size was larger than the wholesize, leading
size_for_offset to conclude that there's a potential underflow. Fix
this by allowing a non-strict mode to size_for_offset, which
conservatively returns the size (or wholesize) in case of a negative
offset.
gcc/ChangeLog:
PR tree-optimization/117355
* tree-object-size.cc (size_for_offset): New argument STRICT,
return SZ if it is set to false.
(plus_stmt_object_size): Adjust call to SIZE_FOR_OFFSET.
gcc/testsuite/ChangeLog:
PR tree-optimization/117355
* g++.dg/ext/builtin-object-size2.C (test9): New test.
(main): Call it.
* gcc.dg/builtin-object-size-3.c (test10): Adjust expected size.
Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
|
|
[PR117420]
The following testcase shows wrong-code caused by incorrect use
of with_possible_nonzero_bits2.
That matcher is defined as
/* Slightly extended version, do not make it recursive to keep it cheap. */
(match (with_possible_nonzero_bits2 @0)
with_possible_nonzero_bits@0)
(match (with_possible_nonzero_bits2 @0)
(bit_and:c with_possible_nonzero_bits@0 @2))
and because with_possible_nonzero_bits includes the SSA_NAME case with
integral/pointer argument, both forms can actually match when a SSA_NAME
with integral/pointer type has a def stmt which is BIT_AND_EXPR
assignment with say SSA_NAME with integral/pointer type as one of its
operands (or INTEGER_CST, another with_possible_nonzero_bits case).
And in match.pd the latter actually wins if both match and so when using
(with_possible_nonzero_bits2 @0) the @0 will actually be one of the
BIT_AND_EXPR operands if that form is matched.
Now, with_possible_nonzero_bits2 and with_certain_nonzero_bits2 were added
for the
/* X == C (or X & Z == Y | C) is impossible if ~nonzero(X) & C != 0. */
(for cmp (eq ne)
(simplify
(cmp:c (with_possible_nonzero_bits2 @0) (with_certain_nonzero_bits2 @1))
(if (wi::bit_and_not (wi::to_wide (@1), get_nonzero_bits (@0)) != 0)
{ constant_boolean_node (cmp == NE_EXPR, type); })))
simplifier, but even for that one I think they do not do a good job, they
might actually pessimize stuff rather than optimize, but at least does not
result in wrong-code, because the operands are solely tested with
wi::to_wide or get_nonzero_bits, but not actually used in the
simplification. The reason why it can pessimize stuff is say if we have
# RANGE [irange] int ... MASK 0xb VALUE 0x0
x_1 = ...;
# RANGE [irange] int ... MASK 0x8 VALUE 0x0
_2 = x_1 & 0xc;
_3 = _2 == 2;
then if it used just with_possible_nonzero_bits@0, @0 would have
get_nonzero_bits (@0) 0x8 and (2 & ~8) != 0, so we can fold it into
_3 = 0;
But as it uses (with_possible_nonzero_bits2 @0), @0 is x_1 rather
than _2 and get_nonzero_bits (@0) is unnecessarily conservative,
0xb rather than 0x8 and (2 & ~0xb) == 0, so we don't optimize.
Now, with_possible_nonzero_bits2 can actually improve stuff as well in that
pattern, if say value ranges aren't fully computed yet or the BIT_AND_EXPR
assignment has been added later and the lhs doesn't have range computed yet,
get_nonzero_range on the BIT_AND_EXPR lhs will be all bits set, while
on the BIT_AND_EXPR operand might actually succeed.
I believe better would be to either modify get_nonzero_bits so that it
special cases the SSA_NAME with BIT_AND_EXPR def_stmt (but one level
deep only like with_possible_nonzero_bits2, no recursion), in that case
return bitwise and of get_nonzero_bits (non-recursive) for the lhs and
both operands, and possibly BIT_AND_EXPR itself e.g. for GENERIC
matching during by returning bitwise and of both operands.
Then with_possible_nonzero_bits2 could be needed for the GENERIC case,
perhaps have the second match #if GENERIC, but changed so that the @N
operand always is the whole thing rather than its operand which is
error-prone. Or add get_nonzero_bits wrapper with a different name
which would do that.
with_certain_nonzero_bits2 could be changed similarly, these days
we can test known non-zero bits rather than possible non-zero bits on
SSA_NAMEs too, we record both mask and value, so possible nonzero bits
(aka. get_nonzero_bits) is mask () | value (), while known nonzero bits
is value () & ~mask (), with a new function (get_known_nonzero_bits
or get_certain_nonzero_bits etc.) which handles that.
Anyway, the following patch doesn't do what I wrote above just yet,
for that single pattern it is just a missed optimization.
But the with_possible_nonzero_bits2 uses in the 3 new simplifiers are
just completely incorrect, because they don't just use the @0 operand
in get_nonzero_bits (pessimizing stuff if value ranges are fully computed),
but also use it in the replacement, then they act as if the BIT_AND_EXPR
wasn't there at all.
While we could use (with_possible_nonzero_bits2@3 @0) and use
get_nonzero_bits (@0) and use @3 in the replacement, that would still
often be a pessimization, so I've just used with_possible_nonzero_bits@0.
2024-11-22 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/117420
* match.pd ((X >> C1) << (C1 + C2) -> X << C2,
(X >> C1) * (C2 << C1) -> X * C2, X / (1 << C) -> X /[ex] (1 << C)):
Use with_possible_nonzero_bits@0 rather than
(with_possible_nonzero_bits2 @0).
* gcc.dg/torture/pr117420.c: New test.
|
|
Sorry, the last patch only partially fixed the __sync_* ICEs with
_BitInt(128) on ia32.
Even for !fetch we need to error out and return 0. I was afraid of
APIs like __atomic_exchange/__atomic_compare_exchange, those obviously
need to be supported even on _BitInt(128) on ia32, but they actually never
sync_resolve_size, they are handled by adding the size argument and using
the library version much earlier.
For fetch && !orig_format (i.e. __atomic_fetch_* etc.) we need to return -1
so that we handle it with a manualy __atomic_load +
__atomic_compare_exchange loop in the caller, all other cases should
be rejected.
2024-11-22 Jakub Jelinek <jakub@redhat.com>
PR c/117641
* c-common.cc (sync_resolve_size): For size 16 with _BitInt
on targets where TImode isn't supported, use goto incompatible if
!fetch.
* gcc.dg/bitint-117.c: New test.
|
|
On Thu, Nov 21, 2024 at 01:30:39PM +0100, Christoph Müllner wrote:
> > > * gcc.dg/tree-ssa/satd-hadamard.c: New test.
> > > * gcc.dg/tree-ssa/vector-10.c: New test.
> > > * gcc.dg/tree-ssa/vector-8.c: New test.
> > > * gcc.dg/tree-ssa/vector-9.c: New test.
I see FAILs on i686-linux or on x86_64-linux (in the latter
with -m32 testing).
One problem is that vector-10.c doesn't use -Wno-psabi option
and uses a function which returns a vector and takes vector
as first parameter, the other problems are that 3 other
tests don't arrange for at least basic vector ISA support,
plus non-standardly test only on x86_64-*-*, while normally
one would allow both i?86-*-* x86_64-*-* and if it is e.g.
specific to 64-bit, also check for lp64 or int128 or whatever
else is needed. E.g. Solaris I think has i?86-*-* triplet even
for 64-bit code, etc.
The following patch fixes these.
2024-11-22 Jakub Jelinek <jakub@redhat.com>
* gcc.dg/tree-ssa/satd-hadamard.c: Add -msse2 as dg-additional-options
on x86. Also scan-tree-dump on i?86-*-*.
* gcc.dg/tree-ssa/vector-8.c: Likewise.
* gcc.dg/tree-ssa/vector-9.c: Likewise.
* gcc.dg/tree-ssa/vector-10.c: Add -Wno-psabi to dg-additional-options.
|
|
Cases of void parameters, other than a parameter list of (void) (or
equivalent with a typedef for void) in its entirety, have been made a
constraint violation in C2Y (N3344 alternative 1 was adopted), as part
of a series of changes to eliminate unnecessary undefined behavior by
turning it into constraint violations, implementation-defined behavior
or something else with stricter bounds on what behavior is allowed.
Previously, these were implicitly undefined behavior (see DR#295),
with only some cases listed in Annex J as undefined (but even those
cases not having wording in the normative text to make them explicitly
undefined).
As discussed in bug 114816, GCC is not entirely consistent about
diagnosing such usages; unnamed void parameters get errors when not
the entire parameter list, while qualified and register void (the
cases listed in Annex J) get errors as a single unnamed parameter, but
named void parameters are accepted with a warning (in a declaration
that's not a definition; it's not possible to define a function with
incomplete parameter types).
Following C2Y, make all these cases into errors. The errors are not
conditional on the standard version, given that this was previously
implicit undefined behavior. Since it wasn't possible anyway to
define such functions, only declare them without defining them (or
otherwise use such parameters in function type names that can't
correspond to any defined function), hopefully the risks of
compatibility issues are small.
Bootstrapped with no regressions for x86-64-pc-linux-gnu.
PR c/114816
gcc/c/
* c-decl.cc (grokparms): Do not warn for void parameter type here.
(get_parm_info): Give errors for void parameters even when named.
gcc/testsuite/
* gcc.dg/c2y-void-parm-1.c: New test.
* gcc.dg/noncompile/920616-2.c, gcc.dg/noncompile/921116-1.c,
gcc.dg/parm-incomplete-1.c: Update expected diagnostics.
|
|
Recently added test cases assume optimized code generation for certain
vectorized code. However, this optimization might not be applied if
the backends don't support the optimized permuation.
The tests are confirmed to work on aarch64 and x86-64, so this
patch restricts the tests accordingly.
Tested on x86-64.
PR117728
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/satd-hadamard.c: Restrict to aarch64 and x86-64.
* gcc.dg/tree-ssa/vector-8.c: Likewise.
* gcc.dg/tree-ssa/vector-9.c: Likewise.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
|
|
This extends forwprop by yet another VEC_PERM optimization:
It attempts to blend two isomorphic vector sequences by using the
redundancy in the lane utilization in these sequences.
This redundancy in lane utilization comes from the way how specific
scalar statements end up vectorized: two VEC_PERMs on top, binary operations
on both of them, and a final VEC_PERM to create the result.
Here is an example of this sequence:
v_in = {e0, e1, e2, e3}
v_1 = VEC_PERM <v_in, v_in, {0, 2, 0, 2}>
// v_1 = {e0, e2, e0, e2}
v_2 = VEC_PERM <v_in, v_in, {1, 3, 1, 3}>
// v_2 = {e1, e3, e1, e3}
v_x = v_1 + v_2
// v_x = {e0+e1, e2+e3, e0+e1, e2+e3}
v_y = v_1 - v_2
// v_y = {e0-e1, e2-e3, e0-e1, e2-e3}
v_out = VEC_PERM <v_x, v_y, {0, 1, 6, 7}>
// v_out = {e0+e1, e2+e3, e0-e1, e2-e3}
To remove the redundancy, lanes 2 and 3 can be freed, which allows to
change the last statement into:
v_out' = VEC_PERM <v_x, v_y, {0, 1, 4, 5}>
// v_out' = {e0+e1, e2+e3, e0-e1, e2-e3}
The cost of eliminating the redundancy in the lane utilization is that
lowering the VEC PERM expression could get more expensive because of
tighter packing of the lanes. Therefore this optimization is not done
alone, but in only in case we identify two such sequences that can be
blended.
Once all candidate sequences have been identified, we try to blend them,
so that we can use the freed lanes for the second sequence.
On success we convert 2x (2x BINOP + 1x VEC_PERM) to
2x VEC_PERM + 2x BINOP + 2x VEC_PERM traded for 4x VEC_PERM + 2x BINOP.
The implemented transformation reuses (rewrites) the statements
of the first sequence and the last VEC_PERM of the second sequence.
The remaining four statements of the second statment are left untouched
and will be eliminated by DCE later.
This targets x264_pixel_satd_8x4, which calculates the sum of absolute
transformed differences (SATD) using Hadamard transformation.
We have seen 8% speedup on SPEC's x264 on a 5950X (x86-64) and 7%
speedup on an AArch64 machine.
Bootstrapped and reg-tested on x86-64 and AArch64 (all languages).
gcc/ChangeLog:
* tree-ssa-forwprop.cc (struct _vec_perm_simplify_seq): New data
structure to store analysis results of a vec perm simplify sequence.
(get_vect_selector_index_map): Helper to get an index map from the
provided vector permute selector.
(recognise_vec_perm_simplify_seq): Helper to recognise a
vec perm simplify sequence.
(narrow_vec_perm_simplify_seq): Helper to pack the lanes more
tight.
(can_blend_vec_perm_simplify_seqs_p): Test if two vec perm
sequences can be blended.
(calc_perm_vec_perm_simplify_seqs): Helper to calculate the new
permutation indices.
(blend_vec_perm_simplify_seqs): Helper to blend two vec perm
simplify sequences.
(process_vec_perm_simplify_seq_list): Helper to process a list
of vec perm simplify sequences.
(append_vec_perm_simplify_seq_list): Helper to add a vec perm
simplify sequence to the list.
(pass_forwprop::execute): Integrate new functionality.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/satd-hadamard.c: New test.
* gcc.dg/tree-ssa/vector-10.c: New test.
* gcc.dg/tree-ssa/vector-8.c: New test.
* gcc.dg/tree-ssa/vector-9.c: New test.
* gcc.target/aarch64/sve/satd-hadamard.c: New test.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
|
|
The following patch optimizes spaceship followed by comparisons of the
spaceship value even for floating point spaceship when NaNs can appear.
operator<=> for this emits roughly
signed char c; if (i == j) c = 0; else if (i < j) c = -1; else if (i > j) c = 1; else c = 2;
and I believe the
/* The optimization may be unsafe due to NaNs. */
comment just isn't true.
Sure, the i == j comparison doesn't raise exceptions on qNaNs, but if
one of the operands is qNaN, then i == j is false and i < j or i > j
is then executed and raises exceptions even on qNaNs.
And we can safely optimize say
c == -1 comparison after the above into i < j, that also raises
exceptions like before and handles NaNs the same way as the original.
The only unsafe transormation would be c == 0 or c != 0, turning it
into i == j or i != j wouldn't raise exception, so I'm not doing that
optimization (but other parts of the compiler optimize the i < j comparison
away anyway).
Anyway, to match the HONOR_NANS case, we need to verify that the
second comparison has true edge to the phi_bb (yielding there -1 or 1),
it can't be the false edge because when NaNs are honored, the false
edge is for both the case where the inverted comparison is true or when
one of the operands is NaN. Similarly we need to ensure that the two
non-equality comparisons are the opposite, while for -ffast-math we can in
some cases get one comparison x >= 5.0 and the other x > 5.0 and it is fine,
because NaN is UB, when NaNs are honored, they must be different to leave
the unordered case with 2 value as the last one remaining.
The patch also punts if HONOR_NANS and the phi has just 3 arguments instead
of 4.
When NaNs are honored, we also in some cases need to perform some comparison
and then invert its result (so that exceptions are properly thrown and we
get the correct result).
2024-11-21 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/94589
PR tree-optimization/117612
* tree-ssa-phiopt.cc (spaceship_replacement): Handle
HONOR_NANS (TREE_TYPE (lhs1)) case when possible.
* gcc.dg/pr94589-5.c: New test.
* gcc.dg/pr94589-6.c: New test.
* g++.dg/opt/pr94589-5.C: New test.
* g++.dg/opt/pr94589-6.C: New test.
|
|
As reported in bug 114266, GCC fails to pedwarn for a compound
literal, whose type is an array of unknown size, initialized with an
empty initializer. This case is disallowed by C23 (which doesn't have
zero-size objects); the case of a named object is diagnosed as
expected, but not that for compound literals. (Before C23, the
pedwarn for empty initializers sufficed.) Add a check for this
specific case with a pedwarn.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/114266
gcc/c/
* c-decl.cc (build_compound_literal): Diagnose array of unknown
size with empty initializer for C23.
gcc/testsuite/
* gcc.dg/c23-empty-init-4.c: New test.
|
|
This patch adds support to the C front-end to parse the `dispatch` construct and
the `adjust_args` clause. It also includes some common C/C++ bits for pragmas
and attributes.
Additional common C/C++ testcases are in a later patch in the series.
gcc/c-family/ChangeLog:
* c-attribs.cc (c_common_gnu_attributes): Add attribute for adjust_args
need_device_ptr.
* c-omp.cc (c_omp_directives): Uncomment dispatch.
* c-pragma.cc (omp_pragmas): Add dispatch.
* c-pragma.h (enum pragma_kind): Add PRAGMA_OMP_DISPATCH.
(enum pragma_omp_clause): Add PRAGMA_OMP_CLAUSE_NOCONTEXT and
PRAGMA_OMP_CLAUSE_NOVARIANTS.
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_dispatch): New function.
(c_parser_omp_clause_name): Handle nocontext and novariants clauses.
(c_parser_omp_clause_novariants): New function.
(c_parser_omp_clause_nocontext): Likewise.
(c_parser_omp_all_clauses): Handle nocontext and novariants clauses.
(c_parser_omp_dispatch_body): New function adapted from
c_parser_expr_no_commas.
(OMP_DISPATCH_CLAUSE_MASK): Define.
(c_parser_omp_dispatch): New function.
(c_finish_omp_declare_variant): Parse adjust_args.
(c_parser_omp_construct): Handle PRAGMA_OMP_DISPATCH.
* c-typeck.cc (c_finish_omp_clauses): Handle OMP_CLAUSE_NOVARIANTS and
OMP_CLAUSE_NOCONTEXT.
gcc/testsuite/ChangeLog:
* gcc.dg/gomp/adjust-args-1.c: New test.
* gcc.dg/gomp/dispatch-1.c: New test.
* gcc.dg/gomp/dispatch-2.c: New test.
* gcc.dg/gomp/dispatch-3.c: New test.
* gcc.dg/gomp/dispatch-4.c: New test.
* gcc.dg/gomp/dispatch-5.c: New test.
|
|
When trying to change a IV from IV0 < IV1 to IV0' != IV1' we apply
fancy adjustments to the may_be_zero condition we compute rather
than using the obvious IV0->base >= IV1->base expression (to be
able to use > instead of >=?). This doesn't seem to go well.
PR tree-optimization/117574
* tree-ssa-loop-niter.cc (number_of_iterations_lt_to_ne):
Use the obvious may_be_zero condition.
* gcc.dg/torture/pr117574-1.c: New testcase.
|
|
Bug 115515 (plus its duplicate 117139) reports an ICE with constexpr
initializer for an integer type variable that is not of integer type.
Fix this by not calling int_fits_type_p unless the previous check for
an integer constant expression passes.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/115515
gcc/c/
* c-typeck.cc (check_constexpr_init): Do not call int_fits_type_p
for arguments that are not integer constant expressions.
gcc/testsuite/
* gcc.dg/c23-constexpr-10.c, gcc.dg/gnu23-constexpr-2.c: New
tests.
|
|
As reported in bug 114869, the C front end wrongly creates nullptr_t
as a built-in typedef; it should only be defined in <stddef.h>. While
the type node needs a name for debug info generation, it doesn't need
to be a valid identifier; use typeof (nullptr) instead, similar to how
the C++ front end uses decltype(nullptr) for this purpose.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/114869
gcc/c/
* c-decl.cc (c_init_decl_processing): Register nullptr_type_node
as typeof (nullptr) not nullptr_t.
gcc/testsuite/
* gcc.dg/c23-nullptr-5.c: Use typeof (nullptr) not nullptr_t.
* gcc.dg/c11-nullptr-2.c, gcc.dg/c11-nullptr-3.c,
gcc.dg/c23-nullptr-7.c: New tests
|
|
Only __atomic_* builtins are meant to work on arbitrary _BitInt types
(if not supported in hw we emit a CAS loop which uses __atomic_load_*
in that case), the compatibility __sync_* builtins work only if there
is a corresponding normal integral type (for _BitInt on 32-bit ARM
we'll need to limit even that to no padding, because the padding bits
are well defined there and the hw or libatomic __sync_* APIs don't
guarantee that), IMHO people shouldn't mix very old APIs with very
new ones and I don't see a replacement for the __atomic_load_*.
For size > 16 that is how it already correctly behaves,
in the hunk shown in the patch it is immediately followed by
if (fetch && !orig_format && TREE_CODE (type) == BITINT_TYPE)
return -1;
which returns -1 for the __atomic_* builtins (i.e. !orig_format),
which causes caller to use atomic_bitint_fetch_using_cas_loop,
and otherwise does diagnostic and return 0 (which causes caller
to punt). But for size == 16 if TImode isn't suipported (i.e.
mostly 32-bit arches), we return (correctly) -1 if !orig_format,
so again force atomic_bitint_fetch_using_cas_loop on those arches
for e.g. _BitInt(115), but for orig_format the function returns
16 as if it could do 16 byte __sync_*_and_* (which it can't
because TImode isn't supported; for 16 byte it can only do
(perhaps using libatomic) normal compare and swap). So we need
to error and return 0, rather than return 16.
The following patch ensures that.
2024-11-19 Jakub Jelinek <jakub@redhat.com>
PR c/117641
* c-common.cc (sync_resolve_size): For size == 16 fetch of
BITINT_TYPE if TImode isn't supported scalar mode diagnose
and return 0 if orig_format instead of returning 16.
* gcc.dg/bitint-115.c: New test.
|
|
Apparently the middle-end/expansion can only handle {L,R}ROTATE_EXPR
on types with mode precision, or large/huge BITINT_TYPE.
So, the following patch uses the rotate exprs only in those cases
where it can be handled, and emits code with shifts/ior otherwise.
As types without mode precision including small/medium BITINT_TYPE
have unlikely power of two precision and TRUNC_MOD_EXPR is on many targets
quite expensive, I chose to expand e.g. __builtin_stdc_rotate_left (arg1,
arg2) as
((tem = arg1, count = arg2 % prec)
? ((tem << count) | (tem >> (prec - count))) : tem)
rather than
(((tem = arg1) << (count = arg2 % prec))
| (tem >> (-count % prec))
(where the assignments are really save_exprs, so no UB), because
I think another TRUNC_MOD_EXPR would be more costly in most cases
when the shift count is non-constant (and when it is constant,
it folds to 2 shifts by constant and ior in either case).
2024-11-19 Jakub Jelinek <jakub@redhat.com>
PR c/117456
gcc/c/
* c-parser.cc (c_parser_postfix_expression): Use LROTATE_EXPR
or RROTATE_EXPR only if type_has_mode_precision_p or if arg1
has BITINT_TYPE with precision larger than MAX_FIXED_MODE_SIZE.
Otherwise build BIT_IOR_EXPR of LSHIFT_EXPR and RSHIFT_EXPR
and wrap it into a COND_EXPR depending on if arg2 is 0 or not.
* c-fold.cc (c_fully_fold_internal): Check for suppression of
-Wshift-count-overflow warning.
gcc/testsuite/
* gcc.dg/builtin-stdc-rotate-4.c: New test.
|
|
gcc/testsuite/
PR testsuite/52641
PR testsuite/116488
PR testsuite/116915
* gcc.dg/torture/pr116488.c: Require int32plus.
* gcc.dg/torture/pr116915.c: Require int32plus.
|
|
Two different declarations of tagged types in the same translation unit
are incompatible in C before C23 and without tag also in C23. Still,
two such types can be compatible to the same tagged type in a different
translation unit, but this means that pointers can alias.
typedef struct { int i; } s1;
typedef struct { int i; } s2;
int f(s1 *p1, s2 *p2)
{
p1->i = 2;
p2->i = 3; // p2->i can alias p1->i
return p1->i;
}
We need to assign the same TYPE_CANONICAL to both types. This patch fixes
this for C23 and types without tag by also forming equivalence classes for
such types based on their structure as already done for types with tag.
Because this change exposes checking errors related to flexible array
members (cf. PR113688), one test is restricted to C17 for now.
PR c/117490
gcc/c/ChangeLog:
* c-typeck.cc (tagged_types_tu_compatible): Form equivalence
classed for tagless types in C23.
gcc/testsuite/ChangeLog:
* gcc.dg/gnu23-tag-alias-4.c: Adapt test.
* gcc.dg/gnu23-tag-alias-7.c: Adapt test.
* gcc.dg/guality/zero-length-array.c: Restrict to c17.
* gcc.dg/pr117490.c: New test.
|
|
The following testcase was failing with the warning: old-style function
definition ever since the c standard version has been updated. Update
the function definition.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul-ice-3.c: Update
function definition.
Signed-off-by: Edwin Lu <ewlu@rivosinc.com>
|
|
extract_bit_field can't handle extraction of non-mode precision
from complex mode operands which don't live in memory, e.g. gen_lowpart
crashes on those.
The following patch in that case defers the extract_bit_field call
until op0 is forced into memory.
2024-11-19 Jakub Jelinek <jakub@redhat.com>
PR middle-end/117458
* expr.cc (expand_expr_real_1) <case VIEW_CONVERT_EXPR>: Don't
call extract_bit_field if op0 has complex mode and isn't a MEM,
instead first force op0 into memory and then call extract_bit_field.
* gcc.dg/bitint-116.c: New test.
|
|
The following patch handles PAREN_EXPR in bitint lowering, and handles it
as an optimization barrier, so that temporary arithmetics from PAREN_EXPR
isn't mixed with temporary arithmetics from outside of the PAREN_EXPR.
2024-11-19 Jakub Jelinek <jakub@redhat.com>
PR middle-end/117459
* gimple-lower-bitint.cc (bitint_large_huge::handle_stmt,
bitint_large_huge::lower_stmt): Handle PAREN_EXPR.
* gcc.dg/torture/bitint-74.c: New test.
|
|
[PR117571]
r15-4601 added match.pd simplification of some TRUNC_DIV_EXPR expressions
into EXACT_DIV_EXPR, so bitintlower can now encounter even those.
From bitint lowering POV the fact that the division will be exact
doesn't matter, we still need to call at runtime the __divmodbitint4
API and it wouldn't simplify there anything to know it is exact if
we duplicated that, so the following patch lowers EXACT_DIV_EXPR exactly
as TRUNC_DIV_EXPR.
I think we don't need to backport this unless something introduces
EXACT_DIV_EXPR on BITINT_TYPEd expressions on the 14 branch as well.
2024-11-19 Jakub Jelinek <jakub@redhat.com>
PR middle-end/117571
* gimple-lower-bitint.cc (bitint_large_huge::lower_muldiv_stmt,
bitint_large_huge::lower_stmt, stmt_needs_operand_addr,
build_bitint_stmt_ssa_conflicts, gimple_lower_bitint): Handle
EXACT_DIV_EXPR like TRUNC_DIV_EXPR.
* gcc.dg/bitint-114.c: New test.
|
|
pow-to-ldexp.c checks for calls to __builtin_ldexpf and __builtin_ldexpl, which
will only be performed when the compiler knows the target has a C99 libm
available.
Modified the test to add a C99 runtime requirement.
This fixes the failure on arm-eabi targets for this test case.
Signed-off-by: Soumya AR <soumyaa@nvidia.com>
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pow-to-ldexp.c: Require c99_runtime.
|
|
As reported in bug 112556, GCC wrongly rejects conversion of null
pointer constants with bool or enum type to pointers in
convert_for_assignment (assignment, initialization, argument passing,
return). Fix the code there to allow BOOLEAN_TYPE and ENUMERAL_TYPE;
it already allowed INTEGER_TYPE and BITINT_TYPE.
This bug (together with -std=gnu23 meaning false has type bool rather
than int) has in turn resulted in people thinking they need to fix
code using false as a null pointer constant for C23 compatibility.
While such a usage is certainly questionable, it has nothing to do
with C23 compatibility and the right place for warnings about such
usage is -Wzero-as-null-pointer-constant. I think it would be
appropriate to extend -Wzero-as-null-pointer-constant to cover
BOOLEAN_TYPE, ENUMERAL_TYPE and BITINT_TYPE (in all the various
contexts in which that option generates warnings), though this patch
doesn't do anything about that option.
Bootstrapped with no regressions for x86-64-pc-linux-gnu.
PR c/112556
gcc/c/
* c-typeck.cc (convert_for_assignment): Allow conversion of
ENUMERAL_TYPE and BOOLEAN_TYPE null pointer constants to pointers.
gcc/testsuite/
* gcc.dg/c11-null-pointer-constant-1.c,
gcc.dg/c23-null-pointer-constant-1.c: New tests.
|
|
The tests added for PR115157 fail on arm-eabi. Add __INT_MAX__
to enum to make sure they have size int.
PR testsuite/117419
gcc/testsuite/ChangeLog:
* gcc.dg/enum-alias-1.c: Add __INT_MAX__.
* gcc.dg/enum-alias-2.c: Likewise.
* gcc.dg/enum-alias-3.c: Likewise.
Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
|
|
Previously the diagnostic subsystem supported a one-deep
hierarchy via auto_diagnostic_group, for associating
notes with the warning/error they annotate; this only
affects SARIF output, not text output.
This patch adds support to the diagnostics subsystem for
capturing arbitrarily deep nesting structure within
diagnostic messages.
This patch:
* adds the ability to express nesting internally when
building diagnostics
* captures the nesting in SARIF output in the form documented
in SG15's P3358R0 ("SARIF for Structured Diagnostics") via
a "nestingLevel" property
* adds a new experimental mode to text output to see the
hierarchy, via:
-fdiagnostics-set-output=text:experimental-nesting=yes
* adds test coverage via a plugin, which with the above
option emits:
• note: child 0
• note: grandchild 0 0
• note: grandchild 0 1
• note: grandchild 0 2
• note: child 1
• note: grandchild 1 0
• note: grandchild 1 1
• note: grandchild 1 2
• note: child 2
• note: grandchild 2 0
• note: grandchild 2 1
• note: grandchild 2 2
using '*' rather than '•' if the text_art::theme is ascii-only.
My hope is to eventually:
(a) use this to improve C++'s template diagnostics
(b) remove the "experimental" caveat from the the text output mode
but this patch doesn't touch the C++ frontend, leaving both of these
to followup work.
gcc/c-family/ChangeLog:
PR other/116253
* c-opts.cc (c_diagnostic_text_finalizer): Use
text_output.build_indent_prefix for prefix to
diagnostic_show_locus.
gcc/ChangeLog:
PR other/116253
* diagnostic-core.h (class auto_diagnostic_nesting_level): New.
* diagnostic-format-sarif.cc (class sarif_builder): Update leading
comment re nesting of diagnostics.
(sarif_result::on_nested_diagnostic): Add nestingLevel property.
* diagnostic-format-text.cc (on_report_diagnostic): If we're
showing nested diagnostics, then print changes of location on a
new line, indented, and update m_last_location.
(diagnostic_text_output_format::build_prefix): If m_show_nesting,
then potentially add indentation and a bullet point.
(get_bullet_point_unichar): New.
(use_unicode_p): New.
(diagnostic_text_output_format::build_indent_prefix): New.
* diagnostic-format-text.h
(diagnostic_text_output_format::diagnostic_text_output_format):
Initialize m_show_nesting and m_show_nesting_levels.
(diagnostic_text_output_format::build_indent_prefix): New decl.
(diagnostic_text_output_format::show_nesting_p): New accessor
(diagnostic_text_output_format::show_locations_in_nesting_p):
Likewise.
(diagnostic_text_output_format::set_show_nesting): New.
(diagnostic_text_output_format::set_show_locations_in_nesting):
New.
(diagnostic_text_output_format::set_show_nesting_levels): New.
(diagnostic_text_output_format::m_show_nesting): New field.
(diagnostic_text_output_format::m_show_locations_in_nesting): New
field.
(diagnostic_text_output_format::m_show_nesting_levels): New field.
* diagnostic-global-context.cc
(auto_diagnostic_nesting_level::auto_diagnostic_nesting_level):
New.
(auto_diagnostic_nesting_level::~auto_diagnostic_nesting_level):
New.
* diagnostic-show-locus.cc (layout_printer::print): Temporarily
set DIAGNOSTICS_SHOW_PREFIX_EVERY_LINE.
* diagnostic.cc (diagnostic_context::initialize): Update for
renaming of m_nesting_depth to m_group_nesting_depth and
initialize m_diagnostic_nesting_level.
(diagnostic_context::finish): Update for renaming of
m_nesting_depth to m_group_nesting_depth.
(diagnostic_context::report_diagnostic): Likewise.
(diagnostic_context::begin_group): Likewise.
(diagnostic_context::end_group): Likewise.
(diagnostic_context::push_nesting_level): New.
(diagnostic_context::pop_nesting_level): New.
(diagnostic_context::set_diagnostic_buffer): Update for renaming
of m_nesting_depth to m_group_nesting_depth. Assert that we don't
have nested diagnostics.
* diagnostic.h (diagnostic_context::push_nesting_level): New decl.
(diagnostic_context::pop_nesting_level): New decl.
(diagnostic_context::get_diagnostic_nesting_level): New accessor.
(diagnostic_context::build_indent_prefix): New decl.
(diagnostic_context::m_diagnostic_groups): Rename m_nesting_depth
to m_group_nesting_depth and add field m_diagnostic_nesting_level.
* doc/invoke.texi (fdiagnostics-add-output): Add note about
"experimental" schemes, keys, and values. Add keys
"experimental-nesting", "experimental-nesting-show-locations",
and "experimental-nesting-show-levels" to text scheme.
* opts-diagnostic.cc (text_scheme_handler::make_sink): Add keys
"experimental-nesting", "experimental-nesting-show-locations",
and "experimental-nesting-show-levels".
gcc/testsuite/ChangeLog:
PR other/116253
* gcc.dg/plugin/diagnostic-test-nesting-sarif.c: New test.
* gcc.dg/plugin/diagnostic-test-nesting-sarif.py: New test.
* gcc.dg/plugin/diagnostic-test-nesting-text-indented-show-levels.c:
New test.
* gcc.dg/plugin/diagnostic-test-nesting-text-indented-unicode.c:
New test.
* gcc.dg/plugin/diagnostic-test-nesting-text-indented.c: New test.
* gcc.dg/plugin/diagnostic-test-nesting-text-plain.c: New test.
* gcc.dg/plugin/diagnostic_plugin_test_nesting.c: New test plugin.
* gcc.dg/plugin/plugin.exp: Add the above.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
|
