Jonathan Wakely [Tue, 30 Jul 2024 09:55:55 +0000 (10:55 +0100)]
libstdc++: Fix overwriting files with fs::copy_file on Windows
There are no inode numbers on Windows filesystems, so stat_type::st_ino
is always zero and the check for equivalent files in do_copy_file was
incorrectly identifying distinct files as equivalent. This caused
copy_file to incorrectly report errors when trying to overwrite existing
files.
The fs::equivalent function already does the right thing on Windows, so
factor that logic out into a new function that can be reused by
fs::copy_file.
The tests for fs::copy_file were quite inadequate, so this also adds
checks for that function's error conditions.
libstdc++-v3/ChangeLog:
* src/c++17/fs_ops.cc (auto_win_file_handle): Change constructor
parameter from const path& to const wchar_t*.
(fs::equiv_files): New function.
(fs::equivalent): Use equiv_files.
* src/filesystem/ops-common.h (fs::equiv_files): Declare.
(do_copy_file): Use equiv_files.
* src/filesystem/ops.cc (fs::equiv_files): Define.
(fs::copy, fs::equivalent): Use equiv_files.
* testsuite/27_io/filesystem/operations/copy.cc: Test
overwriting directory contents recursively.
* testsuite/27_io/filesystem/operations/copy_file.cc: Test
overwriting existing files.
libstdc++: Fix fs::hard_link_count behaviour on MinGW [PR113663]
std::filesystem::hard_link_count() always returns 1 on
mingw-w64ucrt-11.0.1-r3 on Windows 10 19045
hard_link_count() queries _wstat64() on MinGW-w64
The MSFT documentation claims _wstat64() will always return 1 *non*-NTFS volumes
https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/14h5k7ff(v=vs.120)
My tests suggest that is not always true -
hard_link_count()/_wstat64() still returns 1 on NTFS.
GetFileInformationByHandle does return the correct result of 2.
Please see the PR for a minimal repro.
This patch changes the Windows implementation to always call
GetFileInformationByHandle.
PR libstdc++/113663
libstdc++-v3/ChangeLog:
* src/c++17/fs_ops.cc (fs::equivalent): Moved helper class
auto_handle to anonymous namespace as auto_win_file_handle.
(fs::hard_link_count): Changed Windows implementation to use
information provided by GetFileInformationByHandle which is more
reliable.
* testsuite/27_io/filesystem/operations/hard_link_count.cc: New
test.
Signed-off-by: "Lennox" Shou Hao Ho <lennoxhoe@gmail.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
c++: diagnose usage of co_await and co_yield in default args [PR115906]
This is a partial fix for PR115906. Per [expr.await] 2s3, "An
await-expression shall not appear in a default argument
([dcl.fct.default])". This patch introduces the diagnostic in that
case, and in the case of a co_yield (as co_yield is defined in terms of
co_await, so prerequisites of co_await hold).
PR c++/115906 - [coroutines] missing diagnostic and ICE when co_await used as default argument in function declaration
gcc/cp/ChangeLog:
PR c++/115906
* parser.cc (cp_parser_unary_expression): Reject await
expressions if use of local variables is currently forbidden.
(cp_parser_yield_expression): Reject yield expressions if use of
local variables is currently forbidden.
gcc/testsuite/ChangeLog:
PR c++/115906
* g++.dg/coroutines/pr115906-yield.C: New test.
* g++.dg/coroutines/pr115906.C: New test.
* g++.dg/coroutines/co-await-syntax-02-outside-fn.C: Don't rely
on default arguments.
* g++.dg/coroutines/co-yield-syntax-01-outside-fn.C: Ditto.
c++: fix ICE on FUNCTION_DECLs inside coroutines [PR115906]
When register_local_var_uses iterates a BIND_EXPRs BIND_EXPR_VARS, it
fails to account for the fact that FUNCTION_DECLs might be present, and
later passes it to DECL_HAS_VALUE_EXPR_P. This leads to a tree check
failure in DECL_HAS_VALUE_EXPR_P:
tree check: expected var_decl or parm_decl or result_decl, have
function_decl in register_local_var_uses
We only care about PARM_DECL and VAR_DECL, so select only those.
PR c++/115906 - [coroutines] missing diagnostic and ICE when co_await used as default argument in function declaration
gcc/cp/ChangeLog:
PR c++/115906
* coroutines.cc (register_local_var_uses): Only process
PARM_DECL and VAR_DECLs.
gcc/testsuite/ChangeLog:
PR c++/115906
* g++.dg/coroutines/coro-function-decl.C: New test.
Jennifer Schmitz [Tue, 16 Jul 2024 08:59:50 +0000 (01:59 -0700)]
SVE intrinsics: Add strength reduction for division by constant.
This patch folds SVE division where all divisor elements are the same
power of 2 to svasrd (signed) or svlsr (unsigned).
Tests were added to check
1) whether the transform is applied (existing test harness was amended), and
2) correctness using runtime tests for all input types of svdiv; for signed
and unsigned integers, several corner cases were covered.
The patch was bootstrapped and regtested on aarch64-linux-gnu, no regression.
OK for mainline?
Signed-off-by: Jennifer Schmitz <jschmitz@nvidia.com>
gcc/
This is a fallout of commit r15-2378-g29b1587e7d3466
OpenMP/Fortran: Fix handling of 'declare target' with 'link' clause [PR115559]
where the '!GCC$' attributes were added in reverse order.
Result: The error diagnostic for the stdcall/fastcall was reversed.
Solution: Swap the order in dg-error.
xtensa: Fix suboptimal loading of pooled constant value into hardware single-precision FP register
We would like to implement the following to store a single-precision FP
constant in a hardware FP register:
- Load the bit-exact integer image of the pooled single-precision FP
constant into an address (integer) register
- Then, assign from that address register to a hardware single-precision
FP register
- Load the address of the FP constant entry in litpool into an address
register
- Then, dereference the address via that address register into a hardware
single-precision FP register
It is obviously inefficient to read the pool twice.
gcc/ChangeLog:
* config/xtensa/xtensa.md (movsf_internal):
Reorder alternative that corresponds to L32R machine instruction,
and prefix alternatives that correspond to LSI/SSI instructions
with the constraint character '^' so that they are disparaged by
reload/LRA.
It is not wrong but also not optimal to specify that sibcalls require
register A0 in RTX generation pass, by misleading DFA into thinking it
is being used in function body.
It would be better to specify it in pro_and_epilogue as with 'return'
insn in order to avoid incorrect removing load that restores A0 in
subsequent passes, but since it is not possible to modify each sibcall
there, as a workaround we will preface it with a 'use' as before.
* config/xtensa/xtensa-protos.h (xtensa_expand_call):
Remove the third argument.
* config/xtensa/xtensa.cc (xtensa_expand_call):
Remove the third argument and the code that uses it.
* config/xtensa/xtensa.md (call, call_value, sibcall, sibcall_value):
Remove each Boolean constant specified in the third argument of
xtensa_expand_call.
(sibcall_epilogue): Add emitting '(use A0_REG)' after calling
xtensa_expand_epilogue.
Refine constraint "Bk" to define_special_memory_constraint.
For below pattern, RA may still allocate r162 as v/k register, try to
reload for address with leaq __libc_tsd_CTYPE_B@gottpoff(%rip), %rsi
which result a linker error.
Quote from H.J for why linker issue an error.
>What do these do:
>
> leaq __libc_tsd_CTYPE_B@gottpoff(%rip), %rax
> vmovq (%rax), %xmm0
>
>From x86-64 TLS psABI:
>
>The assembler generates for the x@gottpoff(%rip) expressions a R X86
>64 GOTTPOFF relocation for the symbol x which requests the linker to
>generate a GOT entry with a R X86 64 TPOFF64 relocation. The offset of
>the GOT entry relative to the end of the instruction is then used in
>the instruction. The R X86 64 TPOFF64 relocation is pro- cessed at
>program startup time by the dynamic linker by looking up the symbol x
>in the modules loaded at that point. The offset is written in the GOT
>entry and later loaded by the addq instruction.
>
>The above code sequence looks wrong to me.
gcc/ChangeLog:
PR target/116043
* config/i386/constraints.md (Bk): Refine to
define_special_memory_constraint.
Under -O0, with the "newly" introduced intrins, the variable will be
transformed as mem instead of the origin symbol_ref. The compiler will
then treat the operand as invalid and turn the operation into nop, which
is not expected. Use macro for non-optimize to keep the variable as
symbol_ref just as how prefetch intrin does.
gcc/ChangeLog:
* config/i386/prfchiintrin.h
(_m_prefetchit0): Add macro for non-optimized option.
(_m_prefetchit1): Ditto.
xtensa: Make use of scaled [U]FLOAT/TRUNC.S instructions
[U]FLOAT.S machine instruction in Xtensa ISA, which converts an integer to
a hardware single-precision FP register, has the ability to divide the
result by power of two (0 to 15th).
Similarly, [U]TRUNC.S instruction, which truncates single-precision FP to
integer, can multiply the source value by power of two in advance, but
neither of these currently uses this function (always specified with 0th
power of two, i.e. a scaling factor of 1).
This patch unleashes the scaling ability of the above instructions.
/* example */
float test0(int a) {
return a / 2.f;
}
float test1(unsigned int a) {
return a / 32768.f;
}
int test2(float a) {
return a * 2;
}
unsigned int test3(float a) {
return a * 32768;
}
* config/xtensa/predicates.md
(fix_scaling_operand, float_scaling_operand): New predicates.
* config/xtensa/xtensa.md
(any_fix/m_fix/s_fix, any_float/m_float/s_float):
New code iterators and their attributes.
(fix<s_fix>_truncsfsi2): Change from "fix_truncsfsi2".
(*fix<s_fix>_truncsfsi2_2x, *fix<s_fix>_truncsfsi2_scaled):
New insn definitions.
(float<s_float>sisf2): Change from "floatsisf2".
(*float<s_float>sisf2_scaled): New insn definition.
Jeff Law [Mon, 29 Jul 2024 22:17:25 +0000 (16:17 -0600)]
[target/116104] Fix test guarding UINTVAL to extract shift count
Minor oversight in the ext-dce bits. If the shift count is a constant vector,
then we shouldn't be extracting values with [U]INTVAL. We guarded that test
with CONSTANT_P, when it should have been CONSTANT_INT_P.
Shows up on gcn, but I wouldn't be terribly surprised if it could be triggered
elsewhere.
Verified the testcase compiles on gcn. Haven't done a libgcc build for gcn
though. Also verified x86 bootstraps and regression tests cleanly.
Pushing to the trunk.
PR target/116104
gcc/
* ext-dce.cc (carry_backpropagate): Fix test guarding UINTVAL
extraction of shift count.
Currently, if a 'dg-final' action 'file-io-diff' passes, we print nothing
(should: 'PASS: [...]'), but if it fails, we just print: 'FAIL: files differ',
for example ('*.log' file):
[...]
FAIL: 27_io/basic_ostream/inserters_other/wchar_t/2.cc -std=gnu++17 (test for excess errors)
[...]
UNRESOLVED: 27_io/basic_ostream/inserters_other/wchar_t/2.cc -std=gnu++17 compilation failed to produce executable
diff: wostream_inserter_other_in.txt: No such file or directory
diff: wostream_inserter_other_out.txt: No such file or directory
FAIL: files differ
diff: wostream_inserter_other_in.txt: No such file or directory
diff: wostream_inserter_other_out.txt: No such file or directory
When later the '*.sum' files get sorted, these 'FAIL: files differ' instances
aren't grouped anymore with the other test cases' results, but they appear en
bloc, lexically sorted between ('e[...]' and 's[...]'), for example:
Also, we shouldn't emit the actual 'diff' into the '*.sum' file, but just into
the '*.log* file, and there's no need for 'spawn'/'expect', as we're not
matching any specific messages.
Patrick Palka [Mon, 29 Jul 2024 20:37:19 +0000 (16:37 -0400)]
c++: generic lambda in default template argument [PR88313]
Here we're rejecting the generic lambda inside the default template
argument ultimately because auto_is_implicit_function_template_parm_p
doesn't get set during parsing of the lambda's parameter list, due
to the !processing_template_parmlist restriction. But when parsing a
lambda parameter list we should always set that flag regardless of where
the lambda appears. This patch makes sure of this via a local lambda_p
flag.
PR c++/88313
gcc/cp/ChangeLog:
* parser.cc (cp_parser_lambda_declarator_opt): Pass
lambda_p=true to cp_parser_parameter_declaration_clause.
(cp_parser_direct_declarator): Pass lambda_p=false to
to cp_parser_parameter_declaration_clause.
(cp_parser_parameter_declaration_clause): Add bool lambda_p
parameter. Consider lambda_p instead of current_class_type
when setting parser->auto_is_implicit_function_template_parm_p.
Don't consider processing_template_parmlist.
(cp_parser_requirement_parameter_list): Pass lambda_p=false
to cp_parser_parameter_declaration_clause.
Jonathan Wakely [Fri, 15 Mar 2024 12:58:56 +0000 (12:58 +0000)]
doc: Improve punctuation and grammar in -fdiagnostics-format docs
The hyphen can be misunderstood to mean "emitted to -" i.e. stdout.
Refer to both forms by name, rather than using "the former" for one and
referring to the other by name.
gcc/ChangeLog:
* doc/invoke.texi (Diagnostic Message Formatting Options):
Replace hyphen with a new sentence. Replace "the former" with
the actual value.
libgomp.texi: Update 'Device Information Routines' section
Update 'OpenMP Runtime Library Routines' by adding a note that invoking
inside a target region might invoke unspecified behavior. Additionally,
update omp_{get,set}_default_device for omp_{initial,invalid}_device
named constants.
libgomp/ChangeLog:
* libgomp.texi (OpenMP Runtime Library Routines): Add missing
title to some commented still undocumented items.
(Device Information Routines): Update.
OpenMP/Fortran: Fix handling of 'declare target' with 'link' clause [PR115559]
Contrary to a normal 'declare target', the 'declare target link' attribute
also needs to set node->offloadable and push the offload_vars in the front end.
Linked variables require that the data is mapped. For module variables, this
can happen anywhere. For variables in an external subprograms or the main
programm, this can only happen in the either that program itself or in an
internal subprogram. - Whether a variable is just normally mapped or linked then
becomes relevant if a device routine exists that can access that variable,
i.e. an internal procedure has then to be marked as declare target.
PR fortran/115559
gcc/fortran/ChangeLog:
* trans-common.cc (build_common_decl): Add 'omp declare target' and
'omp declare target link' variables to offload_vars.
* trans-decl.cc (add_attributes_to_decl): Likewise; update args and
call decl_attributes.
(get_proc_pointer_decl, gfc_get_extern_function_decl,
build_function_decl): Update calls.
(gfc_get_symbol_decl): Likewise; move after 'DECL_STATIC (t)=1'
to avoid errors with symtab_node::get_create.
libgomp/ChangeLog:
* testsuite/libgomp.fortran/declare-target-link.f90: New test.
libgomp: Fix declare target link with offset array-section mapping [PR116107]
Assume that 'int var[100]' is 'omp declare target link(var)'. When now
mapping an array section with offset such as 'map(to:var[20:10])',
the device-side link pointer has to store &<device-storage-data>[0] minus
the offset such that var[20] will access <device-storage-data>[0]. But
the offset calculation was missed such that the device-side 'var' pointed
to the first element of the mapped data - and var[20] points beyond at
some invalid memory.
PR middle-end/116107
libgomp/ChangeLog:
* target.c (gomp_map_vars_internal): Honor array mapping offsets
with declare-target 'link' variables.
* testsuite/libgomp.c-c++-common/target-link-2.c: New test.
Jakub Jelinek [Mon, 29 Jul 2024 07:33:09 +0000 (09:33 +0200)]
testsuite: Fix up consteval-prop21.C for 32-bit targets [PR115986]
The test fails on 32-bit targets (which don't support __int128 type).
Using unsigned long long instead still ICEs before the fix and passes
after it on those targets.
2024-07-29 Jakub Jelinek <jakub@redhat.com>
PR c++/115986
* g++.dg/cpp2a/consteval-prop21.C (operator "" _c): Use
unsigned long long rather than __uint128_t for return type if int128
is unsupported.
Feng Xue [Fri, 14 Jun 2024 07:49:23 +0000 (15:49 +0800)]
vect: Fix single_imm_use in tree_vect_patterns
Since pattern statement coexists with normal statements in a way that it is
not linked into function body, we should not invoke utility procedures that
depends on def/use graph on pattern statement, such as counting uses of a
pseudo value defined by a pattern statement. This patch is to fix a bug of
this type in vect pattern formation.
2024-06-14 Feng Xue <fxue@os.amperecomputing.com>
gcc/
* tree-vect-patterns.cc (vect_recog_bitfield_ref_pattern): Only call
single_imm_use if statement is not generated from pattern recognition.
Jason Merrill [Sat, 27 Jul 2024 20:40:02 +0000 (16:40 -0400)]
c++: if consteval and consteval propagation [PR115583]
During speculative constant folding of an if consteval, we take the false
branch, but the true branch is an immediate function context, so we don't
want to to cp_fold_immediate it. So we could check IF_STMT_CONSTEVAL_P
here. But beyond that, we don't want to do this inside a call, only when
first parsing a function.
PR c++/115583
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_conditional_expression): Don't
cp_fold_immediate for if consteval.
Jonathan Wakely [Sun, 28 Jul 2024 10:34:17 +0000 (11:34 +0100)]
gcc: Make exec-tool.in handle missing Binutils more gracefully
When users try to build a cross-compiler without first installing
binutils they get confusing errors like:
/tmp/gcc-obj/./gcc/as: line 114: exec: -m: invalid option
This is an incredibly common source of questions on gcc-help and IRC,
and bogus bug reports e.g. see PR 116119 for the latest example.
This change adds an explicit check for an empty $original variable and
exits with a user-friendly error.
gcc/ChangeLog:
* exec-tool.in: Exit with an error if $original is empty.
AVR target 116056 - Support attribute signal(n), interrupt(n) and noblock.
This patch adds support for arguments to the signal and interrupt
function attributes. It allows to specify the ISR by means of the
associated IRQ number, in extension to the current attributes that
require to specify the ISR name like "__vector_1" as (assembly) name
for the function. The new feature is more convenient, e.g. when the
ISR is implemented by a class method or in a namespace. There is no
requirement that the ISR is externally visible. The syntax is like:
Moreover, this patch adds support for the "noblock" function attribute
to let an ISR start with a SEI instruction. Attribute "signal" together
with "noblock" behaves like "interrupt" but without imposing a specific
function name or visibility like "interrupt" does.
PR target/116056
gcc/
* config/avr/avr.h (machine_function) <is_noblock>: New field.
* config/avr/avr-c.cc (avr_cpu_cpp_builtins) <__HAVE_SIGNAL_N__>: New
built-in macro.
* config/avr/avr.cc (avr_declare_function_name): New function.
(avr_attribute_table) <noblock>: New function attribute>.
<signal, interrupt>: Allow any number of args.
(avr_insert_attributes): Check validity of "signal" and "interrupt"
arguments.
(avr_foreach_function_attribute, avr_interrupt_signal_function)
(avr_isr_number, avr_asm_isr_alias, avr_handle_isr_attribute)
(avr_noblock_function_p): New static functions.
(avr_interrupt_function): New from avr_interrupt_function_p.
Adjust callers.
(avr_signal_function): New from avr_signal_function_p.
Adjust callers.
(avr_set_current_function): Only diagnose non-__vector ISR names
when "signal" or "interrupt" attribute has no args. Set
cfun->machine->is_noblock. Warn about "noblock" in non-ISR functions.
(struct avr_fun_cookie): New.
(avr_expand_prologue, avr_asm_function_end_prologue): Handle "noblock".
* config/avr/elf.h (ASM_DECLARE_FUNCTION_NAME): New define.
* config/avr/avr-protos.h (avr_declare_function_name): New proto.
* doc/extend.texi (AVR Function Attributes): Document
signal(num) and interrupt(num).
* doc/invoke.texi (AVR Built-in Macros) <__HAVE_SIGNAL_N__>: Document.
gcc/testsuite/
* gcc.target/avr/torture/signal_n-1.c: New test.
* gcc.target/avr/torture/signal_n-2.c: New test.
* gcc.target/avr/torture/signal_n-3.c: New test.
* gcc.target/avr/torture/signal_n-4.cpp: New test.
Gaius Mulley [Sun, 28 Jul 2024 18:20:43 +0000 (19:20 +0100)]
PR modula2/115823 Wrong expansion of isnormal optab
This patch corrects the function declaration of a builtin
(using the libname rather than the source name).
gcc/m2/ChangeLog:
PR modula2/115823
* gm2-gcc/m2builtins.cc (define_builtin): Build
the function decl using the libname.
gcc/testsuite/ChangeLog:
PR modula2/115823
* gm2/builtins/run/pass/testisnormal.mod: Change to an
implementation module.
* gm2/builtins/run/pass/testisnormal.def: New test.
* gm2/builtins/run/pass/testsinl.def: New test.
* gm2/builtins/run/pass/testsinl.mod: New test.
Jason Merrill [Fri, 26 Jul 2024 21:20:18 +0000 (17:20 -0400)]
c++: consteval propagation and templates [PR115986]
Here the call to e() makes us decide to check d() for escalation at EOF, but
while checking it we try to fold_immediate 0_c, and get confused by the
template trees. Let's not mess with escalation for function templates.
PR c++/115986
gcc/cp/ChangeLog:
* cp-gimplify.cc (remember_escalating_expr): Skip function
templates.
Jason Merrill [Fri, 26 Jul 2024 20:53:03 +0000 (16:53 -0400)]
c++: ICE with concept, local class, and lambda [PR115561]
Here when we want to synthesize methods for foo()::B maybe_push_to_top_level
calls push_function_context, which sets cfun to a dummy value; later
finish_call_expr tries to set something in
cp_function_chain (i.e. cfun->language), which isn't set. Many places in
the compiler check cfun && cp_function_chain to avoid this problem; here we
also want to check !cp_unevaluated_operand, like set_flags_from_callee does.
Jason Merrill [Fri, 26 Jul 2024 19:10:50 +0000 (15:10 -0400)]
c++: improve C++ testsuite default versions
I wanted to add more cases to the setting of std_list in g++-dg.exp, but
didn't want to do a full scan through the file for each case. So this patch
improves that in two ways: first, by extracting all interesting lines on a
single pass; second, by generating the list more flexibly: now we test every
version mentioned explicitly in the testcase, plus a few more if fewer than
three are mentioned.
This also lowers changes from testing four to three versions for most
testcases: the current default and the earliest and latest versions. This
will reduce testing of C++14 and C++20 modes, and increase testing of C++26
mode. C++ front-end developers are encouraged to set the
GXX_TESTSUITE_STDS environment variable to test more modes.
Roger Sayle [Sat, 27 Jul 2024 14:16:19 +0000 (15:16 +0100)]
Fold ctz(-x) and ctz(abs(x)) as ctz(x) in match.pd.
The subject line pretty much says it all; the count-trailing-zeros function
of -X and abs(X) produce the same result as count-trailing-zeros of X.
This transformation eliminates a negation which may potentially overflow
with an equivalent expression that doesn't [much like the analogous
abs(-X) simplification in match.pd].
I'd noticed this -X equivalence, which isn't mentioned in Hacker's Delight,
investigating whether ranger's non_zero_bits can help determine whether
an integer variable may be converted to a floating point type exactly
(without raising FE_INEXACT), but it turns out this observation isn't
novel, as (disappointingly) LLVM already performs this same folding.
2024-07-27 Roger Sayle <roger@nextmovesoftware.com>
Andrew Pinski <quic_apinski@quicinc.com>
Jonathan Wakely [Fri, 26 Jul 2024 16:23:03 +0000 (17:23 +0100)]
libstdc++: Fix -Wsign-compare warning in <charconv>
Cast ptrdiff_t to size_t to avoid a -Wsign-compare warning. We can check
in __to_chars_i that the ptrdiff_t won't be negative, so that we know
the cast is safe.
libstdc++-v3/ChangeLog:
* include/std/charconv (__to_chars_16, __to_chars_10)
(__to_chars_8, __to_chars_2, __to_chars): Cast ptrdiff_t to
size_t for comparison.
(__to_chars_i): Check for first >= last instead of first == last
for initial sanity check.
Jonathan Wakely [Thu, 4 Jul 2024 11:01:29 +0000 (12:01 +0100)]
libstdc++: Remove __find_if unrolling for random access iterators
As the numbers in PR libstdc++/88545 show, the manual loop unrolling in
std::__find_if doesn't actually help these days, and it prevents the
compiler from auto-vectorizing.
Remove the dispatching on iterator_category and just use the simple loop
for all iterator categories.
libstdc++-v3/ChangeLog:
* include/bits/stl_algobase.h (__find_if): Remove overloads for
dispatching on iterator_category. Do not unroll loop manually.
* include/bits/stl_algo.h (__find_if_not): Remove
iterator_category argument from __find_if call.
David Malcolm [Sat, 27 Jul 2024 00:37:31 +0000 (20:37 -0400)]
diagnostics: SARIF output: capture #include information (PR 107941; §3.34)
This patch extends our SARIF output to capture relationships between
locations within a result (§3.34). In particular, this captures
chains of #includes relating to diagnostics and to events within
diagnostic paths.
For example, consider:
include-chain-1.c:
#include "include-chain-1.h"
include-chain-1.h:
/* First set of decls, which will be referenced in notes. */
#include "include-chain-1-1.h"
/* Second set of decls, which will trigger the errors. */
#include "include-chain-1-2.h"
include-chain-1-1.h:
int p;
int q;
include-chain-1-1.h:
char p;
char q;
GCC's textual output emits:
In file included from PATH/include-chain-1.h:5,
from PATH/include-chain-1.c:30:
PATH/include-chain-1-2.h:1:6: error: conflicting types for 'p'; have 'char'
1 | char p;
| ^
In file included from PATH/include-chain-1.h:2:
PATH/include-chain-1-1.h:1:5: note: previous declaration of 'p' with type 'int'
1 | int p;
| ^
PATH/include-chain-1-2.h:2:6: error: conflicting types for 'q'; have 'char'
2 | char q;
| ^
PATH/include-chain-1-1.h:2:5: note: previous declaration of 'q' with type 'int'
2 | int q;
| ^
With this patch, the SARIF output captures the include information for
the two results, so that e.g. result[0]'s location[0] has:
effectively capturing the inclusion digraph in SARIF form:
+-----------------------------------+ +----------------------------------+
|"id": 0 | |"id": 2 |
| error: "conflicting types for 'p';| | note: previous declaration of 'p'|
| have 'char'"| | | with type 'int'") |
| in include-chain-1-2.h | | in include-chain-1-1.h |
+-----------------------------------+ +----------------------------------+
| |
| included-by | included-by
V V
+--------------------------------+ +--------------------------------+
|"id": 1 | |"id": 3 |
| #include "include-chain-1-2.h" | | #include "include-chain-1-1.h" |
| in include-chain-1.h | | in include-chain-1.h |
+--------------------------------+ +--------------------------------+
| |
| included-by | included-by
V V
+------------------------------------+
|"id": 4 |
| The #include "include-chain-1.h" |
| in include-chain-1.c |
+------------------------------------+
Locations only gain "id" fields if they need one, and the precise
numbering of the IDs within a result is an implementation detail (the
order in which references to the locations are made).
To test all this non-trivial JSON from DejaGnu I needed to adapt the
python testing code used by gcov, adding a new run-sarif-pytest based
on run-gcov-pytest.
gcc/ChangeLog:
PR middle-end/107941
* diagnostic-format-sarif.cc: Define INCLUDE_LIST and INCLUDE_MAP.
(enum class location_relationship_kind): New.
(diagnostic_artifact_role::scanned_file): New value.
(class sarif_location_manager): New.
(class sarif_result): Derive from sarif_location_manager rather
than directly from sarif_object.
(sarif_result::add_related_location): Convert to vfunc
implementation.
(sarif_location::m_relationships_map): New field.
(class sarif_location_relationship): New.
(class sarif_ice_notification): Derive from sarif_location_manager
rather than directly from sarif_object.
(sarif_builder::take_current_result): New.
(sarif_builder::m_line_maps): New field.
(sarif_builder::m_cur_group_result): Convert to std::unique_ptr.
(sarif_artifact::add_role): Skip scanned_file.
(get_artifact_role_string): Handle scanned_file.
(sarif_location_manager::add_relationship_to_worklist): New.
(sarif_location_manager::process_worklist): New.
(sarif_location_manager::process_worklist_item): New.
(sarif_result::on_nested_diagnostic): Pass *this to
make_location_object.
(sarif_location::lazily_add_id): New.
(sarif_location::get_id): New.
(get_string_for_location_relationship_kind): New.
(sarif_location::lazily_add_relationship): New.
(sarif_location::lazily_add_relationship_object): New.
(sarif_location::lazily_add_relationships_array): New.
(sarif_ice_notification::sarif_ice_notification): Fix overlong line.
Pass *this to make_locations_arr.
(sarif_ice_notification::add_related_location): New.
(sarif_location_relationship::sarif_location_relationship): New.
(sarif_location_relationship::get_target_id): New.
(sarif_location_relationship::lazily_add_kind): New.
(sarif_builder::sarif_builder): Add "line_maps" param and use it
to initialize m_line_maps.
(sarif_builder::end_diagnostic): Update for m_cur_group_result
becoming a std::unique_ptr. Don't append to m_results_array yet.
(sarif_builder::end_group): Append m_cur_group_result to
m_results_array here, rather than in end_diagnostic.
(sarif_builder::make_result_object): Pass result_obj to
make_locations_arr and to make_code_flow_object.
(sarif_builder::make_locations_arr): Add "loc_mgr" param and pass
it to make_location_object.
(sarif_builder::make_location_object): For two overloads, add
"loc_mgr" param and call add_any_include_chain on the location.
(sarif_builder::add_any_include_chain): New.
(sarif_builder::make_location_object): New overload.
(sarif_builder::make_code_flow_object): Add "result" param and
pass it to make_thread_flow_location_object.
(sarif_builder::make_thread_flow_location_object): Add "result"
param and pass it to make_location_object.
(sarif_builder::get_or_create_artifact): Handle scanned_file.
(sarif_output_format::~sarif_output_format): Assert that there
isn't a pending result.
(sarif_output_format::sarif_output_format): Add "line_maps" param
and pass it to m_builder's ctor.
(sarif_stream_output_format::sarif_stream_output_format): Add
"line_maps" param and pass it to base class ctor.
(sarif_file_output_format::sarif_file_output_format): Likewise.
(diagnostic_output_format_init_sarif_stderr): Pass "line_table"
global to format.
(diagnostic_output_format_init_sarif_file): Likewise.
(diagnostic_output_format_init_sarif_stream): Likewise.
(test_sarif_diagnostic_context::test_sarif_diagnostic_context):
Likewise.
(buffered_output_format::buffered_output_format): Likewise.
(selftest::test_make_location_object): Likewise.
(selftest::test_make_location_object): Create a sarif_result for
use when calling make_location_object.
* diagnostic.cc (diagnostic_context::finish): End any active
diagnostic groups.
(diagnostic_context::report_diagnostic): Assert that we're within
a diagnostic group.
* diagnostic.h (diagnostic_report_diagnostic): Add
begin_group/end_group pair around call to
diagnostic_context::report_diagnostic.
* selftest-diagnostic.cc (test_diagnostic_context::report): Add
begin_group/end_group pair around diagnostic_impl call.
gcc/testsuite/ChangeLog:
PR middle-end/107941
* gcc.dg/sarif-output/include-chain-1-1.h: New test.
* gcc.dg/sarif-output/include-chain-1-2.h: New test.
* gcc.dg/sarif-output/include-chain-1.c: New test.
* gcc.dg/sarif-output/include-chain-1.h: New test.
* gcc.dg/sarif-output/include-chain-2.c: New test.
* gcc.dg/sarif-output/include-chain-2.h: New test.
* gcc.dg/sarif-output/sarif-output.exp: New file.
* gcc.dg/sarif-output/sarif.py: New test, adapted from
g++.dg/gcov/gcov.py.
* gcc.dg/sarif-output/test-include-chain-1.py: New test.
* gcc.dg/sarif-output/test-include-chain-2.py: New test.
* lib/scansarif.exp (sarif-pytest-format-line): New, taken
from lib/gcov.exp.
(run-sarif-pytest): New, adapted from run-gcov-pytest in
lib/gcov.exp.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Lots going on in here. The key is the nonconstant value is zero extended from
SI to DI in the original RTL and we know the constant value is unchanged if we
were to sign extend it from 32 to 64 bits.
We change the extension of the nonconstant operand from zero to sign extension.
I'm pretty confident the goal there is take advantage of the fact that SI
values are kept sign extended and will often be optimized away.
The problem occurs when the nonconstant operand has the SI sign bit set. As an
example:
smax (0x8000000, 0x7) resulting in 0x80000000
The split RTL will generate
smax (sign_extend (0x80000000), 0x7))
smax (0xffffffff80000000, 0x7) resulting in 0x7
Opps.
We really needed to change the opcode to umax for this transformation to work.
That's easy enough. But there's further improvements we can make.
First the pattern is a define_and_split with a post-reload split condition. It
would be better implemented as a 4->3 define_split so that the costing model
just works. Second, if operands[1] is a suitably promoted subreg, then we can
elide the sign extension when we generate the split code, so often it'll be a
4->2 split, again with the cost model working with no adjustments needed.
Tested on rv32 and rv64 in my tester. I'll wait for the pre-commit tester to
spin it as well.
PR target/116085
gcc/
* config/riscv/bitmanip.md (minmax extension avoidance splitter):
Rewrite as a simpler define_split. Adjust the opcode appropriately.
Avoid emitting sign extension if it's clearly not needed.
* config/riscv/iterators.md (minmax_optab): Rename to uminmax_optab
and map everything to unsigned variants.
gcc/testsuite/
* gcc.target/riscv/pr116085.c: New test.
The code to scale ranges for wide chars in format_string incorrectly
checks range.likely to scale range.unlikely, which is a copy-paste typo
from the immediate previous condition.
gcc/ChangeLog:
* gimple-ssa-sprintf.cc (format_string): Fix type in range check
for UNLIKELY for wide chars.
Andrew Pinski [Mon, 22 Jul 2024 22:39:37 +0000 (15:39 -0700)]
aarch64: sve: Rename aarch64_bic to standard pattern, andn
Now there is an optab for bic, andn since r15-1890-gf379596e0ba99d.
This moves aarch64_bic for sve over to use it instead.
Note unlike the simd bic patterns, the operands were already
in the order that was expected for the optab so no swapping
was needed.
Built and tested on aarch64-linux-gnu with no regressions.
gcc/ChangeLog:
* config/aarch64/aarch64-sve-builtins-base.cc (svbic_impl::expand): Update
to use andn optab instead of using code_for_aarch64_bic.
* config/aarch64/aarch64-sve.md (@aarch64_bic<mode>): Rename to ...
(andn<mode>3): This.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Mon, 22 Jul 2024 23:18:47 +0000 (16:18 -0700)]
aarch64: Use iorn and andn standard pattern names for scalar modes
Since r15-1890-gf379596e0ba99d, these are the new optabs.
So let's use these names for them. These will be used to
generate during expand from gimple in the next few patches.
Built and tested for aarch64-linux-gnu with no regressions.
gcc/ChangeLog:
* config/aarch64/aarch64.md (*<NLOGICAL:optab>_one_cmpl<mode>3): Rename to ...
(<NLOGICAL:optab>n<mode>3): This.
(*<NLOGICAL:optab>_one_cmplsidi3_ze): Rename to ...
(*<NLOGICAL:optab>nsidi3_ze): This.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Mon, 22 Jul 2024 18:19:11 +0000 (11:19 -0700)]
aarch64: Rename bic/orn patterns to iorn/andn for vector modes
This renames the patterns orn<mode>3 to iorn<mode>3 so it
matches the new optab that was added with r15-1890-gf379596e0ba99d.
Likewise for bic<mode>3 to andn<mode>3.
Note the operand 1 and operand 2 are swapped from the original
patterns to match the optab now.
Built and tested for aarch64-linux-gnu with no regression.
gcc/ChangeLog:
* config/aarch64/aarch64-simd.md
(bic<mode>3<vczle><vczbe>): Rename to ...
(andn<mode>3<vczle><vczbe>): This. Also swap operands.
(orn<mode>3<vczle><vczbe>): Rename to ...
(iorn<mode>3<vczle><vczbe>): This. Also swap operands.
(vec_cmp<mode><v_int_equiv>): Update orn call to iorn
and swap the last two arguments.
gcc/testsuite/ChangeLog:
* g++.target/aarch64/vect_cmp-1.C: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Thu, 25 Jul 2024 16:37:49 +0000 (09:37 -0700)]
aarch64: Fix target/optimize option handling with transiting between O1 to O2
The problem here is the aarch64 backend enables -mearly-ra at -O2 and above but
it is not marked as an Optimization in the .opt file so enabling it sometimes
reset the target options when going from -O1 to -O2 for the first time.
Build and tested for aarch64-linux-gnu with no regressions.
PR target/116065
gcc/ChangeLog:
* config/aarch64/aarch64.opt (mearly-ra=): Mark as Optimization rather
than Save.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/target_optimization-1.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Fri, 26 Jul 2024 00:43:07 +0000 (17:43 -0700)]
isel: Don't duplicate comparisons for -O0 nor -fno-tree-ter [PR116101]
While doing cleanups on this code I noticed that we do the duplicate
of comparisons at -O0. For C and C++ code this makes no difference as
the gimplifier never produces COND_EXPR. But it could make a difference
for other front-ends.
Oh and for -fno-tree-ter, duplicating the comparison is just a waste
as it is never used for expand.
I also decided to add a few testcases so this is checked in the future.
Even added one for the duplication itself.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/116101
gcc/ChangeLog:
* gimple-isel.cc (maybe_duplicate_comparison): Don't
do anything for -O0 or -fno-tree-ter.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/dup_compare_cond-1.c: New test.
* gcc.dg/tree-ssa/dup_compare_cond-2.c: New test.
* gcc.dg/tree-ssa/dup_compare_cond-3.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Fri, 26 Jul 2024 00:07:28 +0000 (17:07 -0700)]
isel: Small cleanup of duplicating comparisons
This is a small cleanup of the duplicating comparison code.
There is code generation difference but only for -O0 and -fno-tree-ter
(both of which will be fixed in a later patch).
The difference is instead of skipping the first use if the
comparison uses are only in cond_expr we skip the last use.
Also we go through the uses list in the opposite order now too.
The cleanups are the following:
* Don't call has_single_use as we will do the loop anyways
* Change the order of the checks slightly, it is better
to check for cond_expr earlier
* Use cond_exprs as a stack and pop from it.
Skipping the top if the use is only from cond_expr.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* gimple-isel.cc (duplicate_comparison): Rename to ...
(maybe_duplicate_comparison): This. Add check for use here
rather than in its caller.
(pass_gimple_isel::execute): Don't check how many uses the
comparison had and call maybe_duplicate_comparison instead of
duplicate_comparison.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Thu, 25 Jul 2024 23:17:15 +0000 (16:17 -0700)]
isel: Move duplicate comparisons to its own function
This is just a small cleanup to isel and no functional changes just.
The loop inside pass_gimple_isel::execute looked was getting too
deap so let's fix that by moving it to its own function.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* gimple-isel.cc (pass_gimple_isel::execute): Factor out
duplicate comparisons out to ...
(duplicate_comparison): New function.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
The "tail call must be the same type" message is common on some
targets with C++, or without optimization. It is generated
when gcc believes there is an access of the return value
after the call. However usually it does not actually corespond
to a type mismatch, but can be caused for other reasons.
Make it slightly more vague to be less misleading.
- Run the target_effective tail_call checks without optimization to
match the actual test cases.
- Add an extra check for external tail calls to handle targets like
powerpc that cannot tail call between different object files.
This one will also cover templates.
Robin Dapp [Fri, 26 Jul 2024 10:58:38 +0000 (12:58 +0200)]
RISC-V: Work around bare apostrophe in error string.
An unquoted apostrophe slipped through when testing the recent
V/M extension patch. This, again, re-words the message to
"Currently the 'V' implementation requires the 'M' extension".
Going to commit as obvious after testing.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_override_options_internal):
Reword error string without apostrophe.
Tamar Christina [Fri, 26 Jul 2024 12:02:53 +0000 (13:02 +0100)]
middle-end: check for vector mode before calling get_mask_mode [PR116074]
For historical reasons AArch64 has TI mode vector types but does not consider
TImode a vector mode.
What's happening in the PR is that get_vectype_for_scalar_type is returning
vector(1) TImode for a TImode scalar. This then fails when we call
targetm.vectorize.get_mask_mode (vecmode).exists (&) on the TYPE_MODE.
This checks for vector mode before using the results of
get_vectype_for_scalar_type.
For AMX instructions related with memory, we will treat the memory
size as not specified since there won't be different size causing
confusion for memory.
This will change the output under Intel mode, which is broken for now when
using with assembler and aligns to current binutils behavior.
Bootstrapped and regtested on x86-64-pc-linux-gnu. Ok for trunk?
Thx,
Haochen
gcc/ChangeLog:
* config/i386/i386-expand.cc (ix86_expand_builtin): Change
from XImode to BLKmode.
* config/i386/i386.md (ldtilecfg): Change XI to BLK.
(sttilecfg): Ditto.
Currently we don't stream the contents of 'nowarn_map'; this means that
warning suppressions don't get applied in importers, which is
particularly relevant for templates (as in the linked testcase).
Rather than streaming the whole contents of 'nowarn_map', this patch
instead just streams the exported suppressions for each tree node
individually, to not build up additional locations and suppressions for
tree nodes that do not need to be streamed.
PR c++/115757
gcc/cp/ChangeLog:
* module.cc (trees_out::core_vals): Write warning specs for
DECLs and EXPRs.
(trees_in::core_vals): Read warning specs.
gcc/ChangeLog:
* tree.h (put_warning_spec_at): Declare new function.
(has_warning_spec): Likewise.
(get_warning_spec): Likewise.
(put_warning_spec): Likewise.
* diagnostic-spec.h (nowarn_spec_t::from_bits): New function.
* diagnostic-spec.cc (put_warning_spec_at): New function.
* warning-control.cc (has_warning_spec): New function.
(get_warning_spec): New function.
(put_warning_spec): New function.
gcc/testsuite/ChangeLog:
* g++.dg/modules/warn-spec-1_a.C: New test.
* g++.dg/modules/warn-spec-1_b.C: New test.
Jason Merrill [Thu, 25 Jul 2024 21:36:09 +0000 (17:36 -0400)]
c++: #pragma target and deferred instantiation [PR115403]
My patch for 109753 applies the current #pragma target/optimize to a
function when we compile it, which was a problem for a template
instantiation deferred until EOF, where different #pragmas are active. So
let's only do this for artificial functions.
PR c++/115403
PR c++/109753
gcc/cp/ChangeLog:
* decl.cc (start_preparsed_function): Only call decl_attributes for
artificial functions.
Patrick Palka [Thu, 25 Jul 2024 23:05:19 +0000 (19:05 -0400)]
c++: non-template alias with dependent attributes [PR115897]
This patch generalizes our support for dependent attributes on alias
templates to also support them on non-template aliases. The main
addition is a new predicate dependent_opaque_alias_p controlling whether
we can treat an alias (template or non-template) as type-equivalent to
its expansion.
PR c++/115897
gcc/cp/ChangeLog:
* cp-tree.h (dependent_opaque_alias_p): Declare.
* pt.cc (push_template_decl): Manually mark a dependent opaque
alias or dependent alias template specialization as dependent,
and use structural equality for them.
(dependent_opaque_alias_p): Define.
(alias_template_specialization_p): Don't look through an
opaque alias.
(complex_alias_template_p): Use dependent_opaque_alias_p instead of
any_dependent_template_arguments_p directly.
(dependent_alias_template_spec_p): Don't look through an
opaque alias.
(get_underlying_template): Use dependent_opaque_alias_p instead of
any_dependent_template_arguments_p.
(instantiate_alias_template): Mention same logic in
push_template_decl.
(dependent_type_p_r): Remove dependent_alias_template_spec_p check.
(any_template_arguments_need_structural_equality_p): Return true
for a dependent opaque alias.
(alias_ctad_tweaks): Use template_args_equal instead of same_type_p
followed by dependent_alias_template_spec_p.
* tree.cc (strip_typedefs): Don't strip an opaque alias.
* typeck.cc (structural_comptypes): Compare declaration attributes
for an opaque alias.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/alias-decl-79.C: Remove xfails.
* g++.dg/cpp0x/alias-decl-79a.C: New test.
Patrick Palka [Thu, 25 Jul 2024 23:00:23 +0000 (19:00 -0400)]
c++: alias of alias tmpl with dependent attrs [PR115897]
As a follow-up to r15-2047-g7954bb4fcb6fa8, we also need to consider
dependent attributes when recursing into a non-template alias that names
a dependent alias template specialization (and so STF_STRIP_DEPENDENT
is set), otherwise in the first testcase below we undesirably strip B
all the way to T instead of to A<T>.
We also need to move the typedef recursion case of strip_typedefs up to
get checked before the compound type recursion cases. Otherwise for C
below (which ultimately aliases T*) we end up stripping it to T* instead
of to A<T*> because the POINTER_TYPE recursion dominates the typedef
recursion. It also means we issue an unexpected extra error in the
third testcase below.
Ideally we would also want to consider dependent attributes on
non-template aliases, so that we accept the second testcase below, but
making that work correctly would require broader changes to e.g.
structural_comptypes.
PR c++/115897
gcc/cp/ChangeLog:
* tree.cc (strip_typedefs): Move up the typedef recursion case.
Never strip a dependent alias template-id that has dependent
attributes.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/alias-decl-78.C: New test.
* g++.dg/cpp0x/alias-decl-79.C: New test.
* g++.dg/cpp0x/alias-decl-pr92206-1a.C: New test.
The built-ins set a value in a vector. The same operation can be done
in C-code. The assembly code generated from the C-code is as good or
better than the code generated by the built-ins. With default
optimization the number of assembly generated for the two methods are
similar. With -O3 optimization, the assembly generated for the two
approaches is identical for the 2DF and 2DI types. The assembly for
the C-code version of the 1Ti requires one less assembly instruction.
It also only uses one load versus two loads for the built-in.
With the removal of the built-ins, there are no other uses of the
set built-in attribute. The code associated with the set built-in
attribute is removed.
Finally, the testcase for the __builtin_vsx_set_2df is removed. The
other built-ins do not have testcases.
gcc/ChangeLog:
* config/rs6000/rs6000-builtin.cc (get_element_number,
altivec_expand_vec_set_builtin): Remove functions.
(rs6000_expand_builtin): Remove the if statement to call
altivec_expand_vec_set_builtin.
* config/rs6000/rs6000-builtins.def (__builtin_vsx_set_1ti,
__builtin_vsx_set_2df, __builtin_vsx_set_2di): Remove the
built-in definitions.
* config/rs6000/rs6000-gen-builtins.cc (struct attrinfo):
Remove the isset variable from the structure.
(parse_bif_attrs): Remove the uses of the isset variable.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/vsx-builtin-3.c: Remove test cases for the
__builtin_vsx_set_2df built-in.
This patch removes the __builtin_vec_set_v1ti, __builtin_vec_set_v2df
and __builtin_vec_set_v2di built-ins. The users should just use
normal C-code to update the various vector elements. This change was
originally intended to be part of the earlier series of cleanup
patches. It was initially thought that some additional work would be
needed to do some gimple generation instead of these built-ins.
However, the existing default code generation does produce the needed
code. For the vec_set bif, the equivalent C code is as good or
better than the built-in. For the vec_insert bif whose resolving
previously made use of the vec_set bif, the assembly code generation
is as good as before with the -O3 optimization.
Remove the built-ins, use the default gimple generation instead.
gcc/ChangeLog:
* config/rs6000/rs6000-builtins.def (__builtin_vec_set_v1ti,
__builtin_vec_set_v2df, __builtin_vec_set_v2di): Remove built-in
definitions.
* config/rs6000/rs6000-c.cc (resolve_vec_insert): Remove the
handling for constant vec_insert position with
VECTOR_UNIT_VSX_P V1TImode, V2DFmode and V2DImode modes.
Carl Love [Tue, 9 Jul 2024 18:09:42 +0000 (14:09 -0400)]
rs6000, remove __builtin_vsx_xvcmp* built-ins
This patch removes the built-ins:
__builtin_vsx_xvcmpeqsp, __builtin_vsx_xvcmpgesp,
__builtin_vsx_xvcmpgtsp.
which are similar to the recommended PVIPR documented overloaded
vec_cmpeq, vec_cmpgt and vec_cmpge built-ins.
The difference is that the overloaded built-ins return a vector of
32-bit booleans. The removed built-ins returned a vector of floats.
The __builtin_vsx_xvcmpeqdp, __builtin_vsx_xvcmpgedp and
__builtin_vsx_xvcmpgtdp are not removed as they are used by the
overloaded vec_cmpeq, vec_cmpgt and vec_cmpge built-ins.
The test cases for the __builtin_vsx_xvcmpeqsp, __builtin_vsx_xvcmpgesp,
__builtin_vsx_xvcmpgtsp, __builtin_vsx_xvcmpeqdp,
__builtin_vsx_xvcmpgedp and __builtin_vsx_xvcmpgtdp are changed to use
the overloaded vec_cmpeq, vec_cmpgt, vec_cmpge built-ins. Use of the
overloaded built-ins requires the result to be stored in a vector of
boolean of the appropriate size or the result must be cast to the return
type used by the original __builtin_vsx_xvcmp* built-ins.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/vsx-builtin-3.c (do_cmp): Replace
__builtin_vsx_xvcmp{eq,gt,ge}{sp,dp} by vec_cmp{eq,gt,ge}
respectively and add explicit casts to vector {float,double}.
Add more testing code assigning result to vector boolean types.
Jonathan Wakely [Thu, 25 Jul 2024 12:00:09 +0000 (13:00 +0100)]
libstdc++: Implement P2968R2 "Making std::ignore a first-class object"
This was recently approved for C++26, but we can apply the changes for
all modes back to C++11. There's no reason not to make the assignment
usable in constant expressions for C++11 mode, and noexcept for all
modes.
Move the definitions to <bits/utility.h> so they're available in
<utility> as well as <tuple>.
libstdc++-v3/ChangeLog:
* include/bits/utility.h (_Swallow_assign): Make assignment
constexpr for C++11 as well, and add noexcept.
* include/std/tuple (_Swallow_assign, ignore): Move to
bits/utility.h.
* testsuite/20_util/headers/utility/ignore.cc: New test.
Jakub Jelinek [Thu, 25 Jul 2024 19:36:31 +0000 (21:36 +0200)]
c++: Implement C++26 P2558R2 - Add @, $, and ` to the basic character set [PR110343]
The following patch implements the easy parts of the paper.
When @$` are added to the basic character set, it means that
R"@$`()@$`" should now be valid (here I've noticed most of the
raw string tests were tested solely with -std=c++11 or -std=gnu++11
and I've tried to change that), and on the other side even if
by extension $ is allowed in identifiers, \u0024 or \U00000024
or \u{24} should not be, similarly how \u0041 is not allowed.
The paper in 3.1 claims though that
#include <stdio.h>
#define STR(x) #x
int main()
{
printf("%s", STR(\u0060)); // U+0060 is ` GRAVE ACCENT
}
should have been accepted before this paper (and rejected after it),
but g++ rejects it.
I've tried to understand it, but am confused on what is the right
behavior and why.
Neither clang nor gcc emit any diagnostics on the a, c, i and k
initializers, those are certainly valid (c is invalid in C23 though). g++
emits with -pedantic-errors errors on all the others, while clang++ on the
ones with STR involving \u0041, \u0040 and a\u0066d. The chosen values are
\u0040 '@' as something being changed by this paper, \u0041 'A' as basic
character set char valid in identifiers before/after, \u00b7 as an example
of character which is pedantically valid in identifiers if not at the start
and \u066d s something pedantically not valid in identifiers.
Now, https://eel.is/c++draft/lex.charset#6 says that UCN used outside of a
string/character literal which corresponds to basic character set character
(or control character) is ill-formed, that would make d, f, h cases invalid
for C++ and l, n, p cases invalid for C++26.
https://eel.is/c++draft/lex.name states which characters can appear at the
start of the identifier and which can appear after the start. And
https://eel.is/c++draft/lex.pptoken states that preprocessing-token is
either identifier, or tons of other things, or "each non-whitespace
character that cannot be one of the above"
Then https://eel.is/c++draft/lex.pptoken#1 says that this last category is
invalid if the preprocessing token is being converted into token.
And https://eel.is/c++draft/lex.pptoken#2 includes "If any character not in
the basic character set matches the last category, the program is
ill-formed."
Now, e.g. for the C++23 STR(\u0040) case, \u0040 is there not in the basic
character set, so valid outside of the literals (not the case anymore in
C++26), but it isn't nondigit and doesn't have XID_Start property, so it
isn't IMHO an identifier and so must be the "each non-whitespace character
that cannot be one of the above" case. Why doesn't the above mentioned
https://eel.is/c++draft/lex.pptoken#2 sentence make that invalid? Ignoring
that, I'd say it would be then stringized and that feels like it is what
clang++ is doing. Now, e.g. for the STR(a\u066d) case, I wonder why that
isn't lexed as a identifier followed by \u066d "each non-whitespace
character that cannot be one of the above" token and stringified similarly,
clang++ rejects that.
What GCC libcpp seems to be doing is that if that forms_identifier_p calls
_cpp_valid_utf8 or _cpp_valid_ucn with an argument which tells it is first
or second+ in identifier, and e.g. _cpp_valid_ucn then for UCNs valid in
string literals calls
else if (identifier_pos)
{
int validity = ucn_valid_in_identifier (pfile, result, nst);
if (validity == 0)
cpp_error (pfile, CPP_DL_ERROR,
"universal character %.*s is not valid in an identifier",
(int) (str - base), base);
else if (validity == 2 && identifier_pos == 1)
cpp_error (pfile, CPP_DL_ERROR,
"universal character %.*s is not valid at the start of an identifier",
(int) (str - base), base);
}
so basically all those invalid in identifiers cases emit an error and
pretend to be valid in identifiers, rather than what e.g. _cpp_valid_utf8
does for C but not for C++ and only for the chars completely invalid in
identifiers rather than just valid in identifiers but not at the start:
/* In C++, this is an error for invalid character in an identifier
because logically, the UTF-8 was converted to a UCN during
translation phase 1 (even though we don't physically do it that
way). In C, this byte rather becomes grammatically a separate
token. */
if (CPP_OPTION (pfile, cplusplus))
cpp_error (pfile, CPP_DL_ERROR,
"extended character %.*s is not valid in an identifier",
(int) (*pstr - base), base);
else
{
*pstr = base;
return false;
}
The comment doesn't really match what is done in recent C++ versions because
there UCNs are translated to characters and not the other way around.
2024-07-25 Jakub Jelinek <jakub@redhat.com>
PR c++/110343
libcpp/
* lex.cc: C++26 P2558R2 - Add @, $, and ` to the basic character set.
(lex_raw_string): For C++26 allow $@` characters in prefix.
* charset.cc (_cpp_valid_ucn): For C++26 reject \u0024 in identifiers.
gcc/testsuite/
* c-c++-common/raw-string-1.c: Use { c || c++11 } effective target,
remove c++ specific dg-options.
* c-c++-common/raw-string-2.c: Likewise.
* c-c++-common/raw-string-4.c: Likewise.
* c-c++-common/raw-string-5.c: Likewise. Expect some diagnostics
only for non-c++26, for c++26 expect different.
* c-c++-common/raw-string-6.c: Use { c || c++11 } effective target,
remove c++ specific dg-options.
* c-c++-common/raw-string-11.c: Likewise.
* c-c++-common/raw-string-13.c: Likewise.
* c-c++-common/raw-string-14.c: Likewise.
* c-c++-common/raw-string-15.c: Use { c || c++11 } effective target,
change c++ specific dg-options to just -Wtrigraphs.
* c-c++-common/raw-string-16.c: Likewise.
* c-c++-common/raw-string-17.c: Use { c || c++11 } effective target,
remove c++ specific dg-options.
* c-c++-common/raw-string-18.c: Use { c || c++11 } effective target,
remove -std=c++11 from c++ specific dg-options.
* c-c++-common/raw-string-19.c: Likewise.
* g++.dg/cpp26/raw-string1.C: New test.
* g++.dg/cpp26/raw-string2.C: New test.
Jeff Law [Thu, 25 Jul 2024 18:32:28 +0000 (12:32 -0600)]
[PR rtl-optimization/116039] Fix life computation for promoted subregs
So this turned out to be a neat little test and while the fuzzer found it on
RISC-V, I wouldn't be surprised if the underlying issue is also the root cause
of the loongarch issue with ext-dce.
The key issue is that if we have something like
(set (dest) (any_extend (subreg (source))))
If the subreg object is marked with SUBREG_PROMOTED and the sign/unsigned state
matches the any_extend opcode, then combine (and I guess anything using
simplify-rtx) may simplify that to
(set (dest) (source))
That implies that bits outside the mode of the subreg are actually live and
valid. This needs to be accounted for during liveness computation.
We have to be careful here though. If we're too conservative about setting
additional bits live, then we'll inhibit the desired optimization in the
coremark examples. To do a good job we need to know the extension opcode.
I'm extremely unhappy with how the use handling works in ext-dce. It mixes
different conceptual steps and has horribly complex control flow. It only
handles a subset of the unary/binary opcodes, etc etc. It's just damn mess.
It's going to need some more noodling around.
In the mean time this is a bit hacky in that it depends on non-obvious behavior
to know it can get the extension opcode, but I don't want to leave the trunk in
a broken state while I figure out the refactoring problem.
Bootstrapped and regression tested on x86 and tested on the crosses. Pushing to the trunk.
PR rtl-optimization/116039
gcc/
* ext-dce.cc (ext_dce_process_uses): Add some comments about concerns
with current code. Mark additional bit groups as live when we have
an extension of a suitably promoted subreg.
gcc/testsuite
* gcc.dg/torture/pr116039.c: New test.
The reason why the pass believes that this is legal is,
that the mode test in th_memidx_classify_address_modify()
requires INTEGRAL_MODE_P (mode), which includes vector modes.
Let's restrict the mode test such, that only MODE_INT is allowed.
cp+coroutines: teach convert_to_void to diagnose discarded co_awaits
co_await expressions are nearly calls to Awaitable::await_resume, and,
as such, should inherit its nodiscard. A discarded co_await expression
should, hence, act as if its call to await_resume was discarded.
This patch teaches convert_to_void how to discard 'through' a
CO_AWAIT_EXPR. When we discard a CO_AWAIT_EXPR, we can also just discard
the await_resume() call conveniently embedded within it. This results
in a [[nodiscard]] diagnostic that the PR noted was missing.
gcc/cp/ChangeLog:
PR c++/110171
* coroutines.cc (co_await_get_resume_call): New function.
Returns the await_resume expression of a given co_await.
* cp-tree.h (co_await_get_resume_call): New function.
* cvt.cc (convert_to_void): Handle CO_AWAIT_EXPRs and call
maybe_warn_nodiscard on their resume exprs.
gcc/testsuite/ChangeLog:
PR c++/110171
* g++.dg/coroutines/pr110171-1.C: New test.
* g++.dg/coroutines/pr110171.C: New test.
cp/coroutines: do not rewrite parameters in unevaluated contexts
It is possible to use parameters of a parent function of a lambda in
unevaluated contexts without capturing them. By not capturing them, we
work around the usual mechanism we use to prevent rewriting captured
parameters. Prevent this by simply skipping rewrites in unevaluated
contexts. Those won't mind the value not being present anyway.
This prevents an ICE during parameter substitution. In the testcase
from the PR, the rewriting machinery finds a param in the body of the
coroutine, which it did not previously encounter while processing the
coroutine declaration, and that does not have a DECL_VALUE_EXPR, and
fails.
Jeff Law [Thu, 25 Jul 2024 14:42:04 +0000 (08:42 -0600)]
[committed] Trivial testcase adjustment
I made pr116037.c dependent on int32 just based on the constants used without
noting the int128 vector type. Naturally on targets that don't support int128
the test fails. Fixed by changing the target selector from int32 to int128.
Richard Biener [Thu, 25 Jul 2024 11:39:49 +0000 (13:39 +0200)]
tree-optimization/116083 - improve behavior when SLP discovery limit is reached
The following avoids some useless work when the SLP discovery limit
is reached, for example allocating a node to cache the failure
and starting discovery on split store groups when analyzing BBs.
It does not address the issue in the PR which is a gratious budget
for discovery when the store group size approaches the number of
overall statements.
PR tree-optimization/116083
* tree-vect-slp.cc (vect_build_slp_tree): Do not allocate
a discovery fail node when we reached the discovery limit.
(vect_build_slp_instance): Terminate early when the
discovery limit is reached.
projects / thirdparty / gcc.git / log
