GCC Administrator [Mon, 13 Jun 2022 00:16:18 +0000 (00:16 +0000)]
Daily bump.
Simon Wright [Sun, 12 Jun 2022 16:01:22 +0000 (17:01 +0100)]
Darwin: Truncate kernel-provided version to OS major for Darwin >= 20.
In common with system tools, GCC uses a version obtained from the kernel as
the prevailing macOS target, when that is not overridden by command line or
environment versions (i.e. mmacosx-version-min=, MACOSX_DEPLOYMENT_TARGET).
Presently, GCC assumes that if the OS version is >= 20, the value used should
include both major and minium version identifiers. However the system tools
(for those versions) truncate the value to the major version - this leads to
link errors when combining objects built with clang and GCC for example:
ld: warning: object file (null.o) was built for newer macOS version (12.2)
than being linked (12.0)
The change here truncates the values GCC uses to the major version.
gcc/ChangeLog:
PR target/104871
* config/darwin-driver.cc (darwin_find_version_from_kernel): If the OS
version is darwin20 (macOS 11) or greater, truncate the version to the
major number.
Mark Mentovai [Fri, 10 Jun 2022 14:56:42 +0000 (15:56 +0100)]
Darwin: Future-proof -mmacosx-version-min
f18cbc1ee1f4 (2021-12-18) updated various parts of gcc to not impose a
Darwin or macOS version maximum of the current known release. Different
parts of gcc accept, variously, Darwin version numbers matching
darwin2*, and macOS major version numbers up to 99. The current released
version is Darwin 21 and macOS 12, with Darwin 22 and macOS 13 expected
for public release later this year. With one major OS release per year,
this strategy is expected to provide another 8 years of headroom.
However,
f18cbc1ee1f4 missed config/darwin-c.c (now .cc), which
continued to impose a maximum of macOS 12 on the -mmacosx-version-min
compiler driver argument. This was last updated from 11 to 12 in
11b967577483 (2021-10-27), but kicking the can down the road one year at
a time is not a viable strategy, and is not in line with the more recent
technique from
f18cbc1ee1f4.
Prior to
556ab5125912 (2020-11-06), config/darwin-c.c did not impose a
maximum that needed annual maintenance, as at that point, all macOS
releases had used a major version of 10. The stricter approach imposed
since then was valuable for a time until the particulars of the new
versioning scheme were established and understood, but now that they
are, it's prudent to restore a more permissive approach.
gcc/ChangeLog:
* config/darwin-c.cc: Make -mmacosx-version-min more future-proof.
Signed-off-by: Mark Mentovai <mark@mentovai.com>
Max Filippov [Sun, 12 Jun 2022 01:51:44 +0000 (18:51 -0700)]
gcc: xtensa: fix pr95571 test for call0 ABI
gcc/testsuite/
* g++.target/xtensa/pr95571.C (__xtensa_libgcc_window_spill):
New definition.
Prathamesh Kulkarni [Sun, 12 Jun 2022 03:20:16 +0000 (08:50 +0530)]
PR96463: Optimise svld1rq from vectors for little endian AArch64 targets.
The patch folds:
lhs = svld1rq({-1, -1, ...}, rhs)
into:
tmp = mem_ref<vectype> [(elem_type * {ref-all}) rhs]
lhs = vec_perm_expr<tmp, tmp, {0, 1, 2, 3 ...}>.
which is then expanded using aarch64_expand_sve_dupq.
Example:
svint32_t
foo (int32x4_t x)
{
return svld1rq (svptrue_b8 (), &x[0]);
}
code-gen:
foo:
.LFB4350:
dup z0.q, z0.q[0]
ret
The patch relaxes type-checking for VEC_PERM_EXPR by allowing different
vector types for lhs and rhs provided:
(1) rhs3 is constant and has integer type element.
(2) len(lhs) == len(rhs3) and len(rhs1) == len(rhs2)
(3) lhs and rhs have same element type.
gcc/ChangeLog:
PR target/96463
* config/aarch64/aarch64-sve-builtins-base.cc: Include ssa.h.
(svld1rq_impl::fold): Define.
* config/aarch64/aarch64.cc (expand_vec_perm_d): Define new members
op_mode and op_vec_flags.
(aarch64_evpc_reencode): Initialize newd.op_mode and
newd.op_vec_flags.
(aarch64_evpc_sve_dup): New function.
(aarch64_expand_vec_perm_const_1): Gate existing calls to
aarch64_evpc_* functions under d->vmode == d->op_mode,
and call aarch64_evpc_sve_dup.
(aarch64_vectorize_vec_perm_const): Remove assert
d->vmode != d->op_mode, and initialize d.op_mode and d.op_vec_flags.
* tree-cfg.cc (verify_gimple_assign_ternary): Allow different
vector types for lhs and rhs in VEC_PERM_EXPR if rhs3 is
constant.
gcc/testsuite/ChangeLog:
PR target/96463
* gcc.target/aarch64/sve/acle/general/pr96463-1.c: New test.
* gcc.target/aarch64/sve/acle/general/pr96463-2.c: Likewise.
GCC Administrator [Sun, 12 Jun 2022 00:16:26 +0000 (00:16 +0000)]
Daily bump.
Takayuki 'January June' Suwa [Fri, 10 Jun 2022 15:26:17 +0000 (00:26 +0900)]
xtensa: Improve constant synthesis for both integer and floating-point
This patch revises the previous implementation of constant synthesis.
First, changed to use define_split machine description pattern and to run
after reload pass, in order not to interfere some optimizations such as
the loop invariant motion.
Second, not only integer but floating-point is subject to processing.
Third, several new synthesis patterns - when the constant cannot fit into
a "MOVI Ax, simm12" instruction, but:
I. can be represented as a power of two minus one (eg. 32767, 65535 or
0x7fffffffUL)
=> "MOVI(.N) Ax, -1" + "SRLI Ax, Ax, 1 ... 31" (or "EXTUI")
II. is between -34816 and 34559
=> "MOVI(.N) Ax, -2048 ... 2047" + "ADDMI Ax, Ax, -32768 ... 32512"
III. (existing case) can fit into a signed 12-bit if the trailing zero bits
are stripped
=> "MOVI(.N) Ax, -2048 ... 2047" + "SLLI Ax, Ax, 1 ... 31"
The above sequences consist of 5 or 6 bytes and have latency of 2 clock cycles,
in contrast with "L32R Ax, <litpool>" (3 bytes and one clock latency, but may
suffer additional one clock pipeline stall and implementation-specific
InstRAM/ROM access penalty) plus 4 bytes of constant value.
In addition, 3-instructions synthesis patterns (8 or 9 bytes, 3 clock latency)
are also provided when optimizing for speed and L32R instruction has
considerable access penalty:
IV. 2-instructions synthesis (any of I ... III) followed by
"SLLI Ax, Ax, 1 ... 31"
V. 2-instructions synthesis followed by either "ADDX[248] Ax, Ax, Ax"
or "SUBX8 Ax, Ax, Ax" (multiplying by 3, 5, 7 or 9)
gcc/ChangeLog:
* config/xtensa/xtensa-protos.h (xtensa_constantsynth):
New prototype.
* config/xtensa/xtensa.cc (xtensa_emit_constantsynth,
xtensa_constantsynth_2insn, xtensa_constantsynth_rtx_SLLI,
xtensa_constantsynth_rtx_ADDSUBX, xtensa_constantsynth):
New backend functions that process the abovementioned logic.
(xtensa_emit_move_sequence): Revert the previous changes.
* config/xtensa/xtensa.md: New split patterns for integer
and floating-point, as the frontend part.
gcc/testsuite/ChangeLog:
* gcc.target/xtensa/constsynth_2insns.c: New.
* gcc.target/xtensa/constsynth_3insns.c: Ditto.
* gcc.target/xtensa/constsynth_double.c: Ditto.
Takayuki 'January June' Suwa [Fri, 10 Jun 2022 04:19:32 +0000 (13:19 +0900)]
xtensa: Improve instruction cost estimation and suggestion
This patch implements a new target-specific relative RTL insn cost function
because of suboptimal cost estimation by default, and fixes several "length"
insn attributes (related to the cost estimation).
And also introduces a new machine-dependent option "-mextra-l32r-costs="
that tells implementation-specific InstRAM/ROM access penalty for L32R
instruction to the compiler (in clock-cycle units, 0 by default).
gcc/ChangeLog:
* config/xtensa/xtensa.cc (xtensa_rtx_costs): Correct wrong case
for ABS and NEG, add missing case for BSWAP and CLRSB, and
double the costs for integer divisions using libfuncs if
optimizing for speed, in order to take advantage of fast constant
division by multiplication.
(TARGET_INSN_COST): New macro definition.
(xtensa_is_insn_L32R_p, xtensa_insn_cost): New functions for
calculating relative costs of a RTL insns, for both of speed and
size.
* config/xtensa/xtensa.md (return, nop, trap): Correct values of
the attribute "length" that depends on TARGET_DENSITY.
(define_asm_attributes, blockage, frame_blockage): Add missing
attributes.
* config/xtensa/xtensa.opt (-mextra-l32r-costs=): New machine-
dependent option, however, preparatory work for now.
Takayuki 'January June' Suwa [Fri, 10 Jun 2022 04:18:24 +0000 (13:18 +0900)]
xtensa: Consider the Loop Option when setmemsi is expanded to small loop
Now apply to almost any size of aligned block under such circumstances.
gcc/ChangeLog:
* config/xtensa/xtensa.cc (xtensa_expand_block_set_small_loop):
Pass through the block length / loop count conditions if
zero-overhead looping is configured and active,
Takayuki 'January June' Suwa [Fri, 10 Jun 2022 04:17:40 +0000 (13:17 +0900)]
xtensa: Tweak some widen multiplications
umulsidi3 is faster than umuldi3 even if library call, and is also
prerequisite for fast constant division by multiplication.
gcc/ChangeLog:
* config/xtensa/xtensa.md (mulsidi3, umulsidi3):
Split into individual signedness, in order to use libcall
"__umulsidi3" but not the other.
(<u>mulhisi3): Merge into one by using code iterator.
(<u>mulsidi3, mulhisi3, umulhisi3): Remove.
Michael Meissner [Sat, 11 Jun 2022 04:40:16 +0000 (00:40 -0400)]
Disable generating load/store vector pairs for block copies.
Testing has found that using load and store vector pair for block copies
can result in a slow down on power10. This patch disables using the
vector pair instructions for block copies if we are tuning for power10.
2022-06-11 Michael Meissner <meissner@linux.ibm.com>
gcc/
* config/rs6000/rs6000.cc (rs6000_option_override_internal): Do
not generate block copies with vector pair instructions if we are
tuning for power10.
GCC Administrator [Sat, 11 Jun 2022 00:16:21 +0000 (00:16 +0000)]
Daily bump.
Patrick Palka [Fri, 10 Jun 2022 20:10:02 +0000 (16:10 -0400)]
c++: improve TYPENAME_TYPE hashing [PR65328]
For the testcase in this PR, compilation takes very long ultimately due
to our poor hashing of TYPENAME_TYPE causing a huge number of collisions
in the spec_hasher and typename_hasher tables.
In spec_hasher, we don't hash the components of TYPENAME_TYPE, which
means most TYPENAME_TYPE arguments end up contributing the same hash.
This is the safe thing to do uniformly since structural_comptypes may
try resolving a TYPENAME_TYPE via the current instantiation. But this
behavior of structural_comptypes is suppressed from spec_hasher::equal
via the comparing_specializations flag, which means spec_hasher::hash
can assume it's disabled too. To that end, this patch makes
spec_hasher::hash set the flag, and teaches iterative_hash_template_arg
to hash the relevant components of TYPENAME_TYPE when the flag is set.
And in typename_hasher, the hash function considers TYPE_IDENTIFIER
instead of the more informative TYPENAME_TYPE_FULLNAME, which this patch
fixes accordingly.
After this patch, compile time for the testcase in the PR falls to
around 30 seconds on my machine (down from dozens of minutes).
PR c++/65328
gcc/cp/ChangeLog:
* decl.cc (typename_hasher::hash): Add extra overloads.
Use iterative_hash_object instead of htab_hash_pointer.
Hash TYPENAME_TYPE_FULLNAME instead of TYPE_IDENTIFIER.
(build_typename_type): Use typename_hasher::hash.
* pt.cc (spec_hasher::hash): Add two-parameter overload.
Set comparing_specializations around the call to
hash_tmpl_and_args.
(iterative_hash_template_arg) <case TYPENAME_TYPE>:
When comparing_specializations, hash the TYPE_CONTEXT
and TYPENAME_TYPE_FULLNAME.
(tsubst_function_decl): Use spec_hasher::hash instead of
hash_tmpl_and_args.
(tsubst_template_decl): Likewise.
(tsubst_decl): Likewise.
Patrick Palka [Fri, 10 Jun 2022 20:09:58 +0000 (16:09 -0400)]
c++: optimize specialization of templated member functions
This applies one of the lookup_template_class optimizations from the
previous patch to instantiate_template as well.
gcc/cp/ChangeLog:
* pt.cc (instantiate_template): Don't substitute the context
of the most general template if that of the partially
instantiated template is already non-dependent.
Patrick Palka [Fri, 10 Jun 2022 20:09:48 +0000 (16:09 -0400)]
c++: optimize specialization of nested templated classes
When substituting a class template specialization, tsubst_aggr_type
substitutes the TYPE_CONTEXT before passing it to lookup_template_class.
This appears to be unnecessary, however, because the the initial value
of lookup_template_class's context parameter is unused outside of the
IDENTIFIER_NODE case, and l_t_c performs its own substitution of the
context, anyway. So this patch removes the redundant substitution in
tsubst_aggr_type. Doing so causes us to ICE on template/nested5.C
because during lookup_template_class for A<T>::C::D<S> with T=E and S=S,
we substitute and complete the context A<T>::C with T=E, which in turn
registers the desired dependent specialization of D for us which we end
up trying to register twice. This patch fixes this by checking the
specializations table again after completion of the context.
This patch also implements a couple of other optimizations:
* In lookup_template_class, if the context of the partially
instantiated template is already non-dependent, then we could
reuse that instead of substituting the context of the most
general template.
* During tsubst_decl for the TYPE_DECL for an injected-class-name,
we can avoid substituting its TREE_TYPE. We can also avoid
template argument substitution/coercion for this TYPE_DECL, and
for class-scope non-template VAR_/TYPE_DECLs more generally.
Together these optimizations improve memory usage for the range-v3
file test/view/zip.cc by about 5%.
gcc/cp/ChangeLog:
* pt.cc (lookup_template_class): Remove dead stores to
context parameter. Don't substitute the context of the
most general template if that of the partially instantiated
template is already non-dependent. Check the specializations
table again after completing the context of a nested dependent
specialization.
(tsubst_aggr_type) <case RECORD_TYPE>: Don't substitute
TYPE_CONTEXT or pass it to lookup_template_class.
(tsubst_decl) <case TYPE_DECL, case TYPE_DECL>: Avoid substituting
the TREE_TYPE for DECL_SELF_REFERENCE_P. Avoid template argument
substitution or coercion in some cases.
Nathan Sidwell [Thu, 9 Jun 2022 15:14:31 +0000 (08:14 -0700)]
c++: Add a late-writing step for modules
To add a module initializer optimization, we need to defer finishing writing
out the module file until the end of determining the dynamic initializers.
This is achieved by passing some saved-state from the main module writing
to a new function that completes it.
This patch merely adds the skeleton of that state and move things around,
allowing the finalization of the ELF file to be postponed. None of the
contents writing is moved, or the init optimization added.
gcc/cp/
* cp-tree.h (fini_modules): Add some parameters.
(finish_module_processing): Return an opaque pointer.
* decl2.cc (c_parse_final_cleanups): Propagate a cookie from
finish_module_processing to fini_modules.
* module.cc (struct module_processing_cookie): New.
(finish_module_processing): Return a heap-allocated cookie.
(late_finish_module): New. Finish out the module writing.
(fini_modules): Adjust.
Jakub Jelinek [Fri, 10 Jun 2022 19:19:51 +0000 (21:19 +0200)]
openmp: Call dlopen with "libmemkind.so.0" rather than "libmemkind.so"
On Thu, Jun 09, 2022 at 12:11:28PM +0200, Thomas Schwinge wrote:
> > This patch adds support for dlopening libmemkind.so
>
> Instead of 'dlopen'ing literally 'libmemkind.so':
> ..., shouldn't this instead 'dlopen' 'libmemkind.so.0'? At least for
> Debian/Ubuntu, the latter ('libmemkind.so.0') is shipped in the "library"
> package:
I agree and I've actually noticed it too right before committing, but I thought
I'll investigate and tweak incrementally because "libmemkind.so"
is what I've actually tested (it is what llvm libomp uses).
Here is the now tested incremental fix.
2022-06-10 Jakub Jelinek <jakub@redhat.com>
* allocator.c (gomp_init_memkind): Call dlopen with "libmemkind.so.0"
rather than "libmemkind.so".
Nathan Sidwell [Fri, 10 Jun 2022 12:22:21 +0000 (05:22 -0700)]
c++: Adjust module initializer calling emission
We special-case emitting the calls of module initializer functions. It's
simpler to just emit a static fn do do that, and add it onto the front of
the global init fn chain. We can also move the calculation of the set of
initializers to call to the point of use.
gcc/cp/
* cp-tree.h (module_has_import_init): Rename to ...
(module_determined_import_inits): ... here.
* decl2.cc (start_objects): Do not handle module initializers
here.
(c_parse_final_cleanups): Generate a separate module
initializer calling function and add it to the list. Shrink
the c-lang region.
* module.cc (num_init_calls_needed): Delete.
(module_has_import_init): Rename to ...
(module_determined_import_inits): ... here. Do the
calculation here ...
(finish_module_processing): ... rather than here.
(module_add_import_initializers): Reformat.
gcc/testsuite/
* g++.dg/modules/init-3_a.C: New.
* g++.dg/modules/init-3_b.C: New.
* g++.dg/modules/init-3_c.C: New.
Thomas Schwinge [Thu, 12 May 2022 20:46:40 +0000 (22:46 +0200)]
libgomp nvptx plugin: Remove '--with-cuda-driver=[...]' etc. configuration option
That means, exposing to the user only the '--without-cuda-driver' behavior:
including the GCC-shipped 'include/cuda/cuda.h' (not system <cuda.h>), and
'dlopen'ing the CUDA Driver library (not linking it).
For development purposes, the libgomp nvptx plugin developer may still manually
override that, to get the previous '--with-cuda-driver' behavior.
libgomp/
* plugin/Makefrag.am: Evaluate 'if PLUGIN_NVPTX_DYNAMIC' to true.
* plugin/configfrag.ac (--with-cuda-driver)
(--with-cuda-driver-include, --with-cuda-driver-lib)
(CUDA_DRIVER_INCLUDE, CUDA_DRIVER_LIB, PLUGIN_NVPTX_CPPFLAGS)
(PLUGIN_NVPTX_LDFLAGS, PLUGIN_NVPTX_LIBS, PLUGIN_NVPTX_DYNAMIC):
Remove.
* testsuite/libgomp-test-support.exp.in (cuda_driver_include)
(cuda_driver_lib): Remove.
* testsuite/lib/libgomp.exp (libgomp_init): Don't consider these.
* Makefile.in: Regenerate.
* configure: Likewise.
* testsuite/Makefile.in: Likewise.
Jonathan Wakely [Fri, 10 Jun 2022 13:39:13 +0000 (14:39 +0100)]
libstdc++: Make std::lcm and std::gcd detect overflow [PR105844]
When I fixed PR libstdc++/92978 I introduced a regression whereby
std::lcm(INT_MIN, 1) and std::lcm(50000, 49999) would no longer produce
errors during constant evaluation. Those calls are undefined, because
they violate the preconditions that |m| and the result can be
represented in the return type (which is int in both those cases). The
regression occurred because __absu<unsigned>(INT_MIN) is well-formed,
due to the explicit casts to unsigned in that new helper function, and
the out-of-range multiplication is well-formed, because unsigned
arithmetic wraps instead of overflowing.
To fix 92978 I made std::gcm and std::lcm calculate |m| and |n|
immediately, yielding a common unsigned type that was used to calculate
the result. That was partly correct, but there's no need to use an
unsigned type. Doing so only suppresses the overflow errors so the
compiler can't detect them. This change replaces __absu with __abs_r
that returns the common type (not its corresponding unsigned type). This
way we can detect overflow in __abs_r when required, while still
supporting the most-negative value when it can be represented in the
result type. To detect LCM results that are out of range of the result
type we still need explicit checks, because neither constant evaluation
nor UBsan will complain about unsigned wrapping for cases such as
std::lcm(500000u, 499999u). We can detect those overflows efficiently by
using __builtin_mul_overflow and asserting.
libstdc++-v3/ChangeLog:
PR libstdc++/105844
* include/experimental/numeric (experimental::gcd): Simplify
assertions. Use __abs_r instead of __absu.
(experimental::lcm): Likewise. Remove use of __detail::__lcm so
overflow can be detected.
* include/std/numeric (__detail::__absu): Rename to __abs_r and
change to allow signed result type, so overflow can be detected.
(__detail::__lcm): Remove.
(gcd): Simplify assertions. Use __abs_r instead of __absu.
(lcm): Likewise. Remove use of __detail::__lcm so overflow can
be detected.
* testsuite/26_numerics/gcd/gcd_neg.cc: Adjust dg-error lines.
* testsuite/26_numerics/lcm/lcm_neg.cc: Likewise.
* testsuite/26_numerics/gcd/105844.cc: New test.
* testsuite/26_numerics/lcm/105844.cc: New test.
Jonathan Wakely [Wed, 8 Jun 2022 09:43:57 +0000 (10:43 +0100)]
libstdc++: Fix lifetime bugs for non-TLS eh_globals [PR105880]
This ensures that the single-threaded fallback buffer eh_globals is not
destroyed during program termination, using the same immortalization
technique used for error category objects.
Also ensure that init._M_init can still be read after init has been
destroyed, by making it a static data member.
libstdc++-v3/ChangeLog:
PR libstdc++/105880
* libsupc++/eh_globals.cc (eh_globals): Ensure constant init and
prevent destruction during termination.
(__eh_globals_init::_M_init): Replace with static member _S_init.
(__cxxabiv1::__cxa_get_globals_fast): Update.
(__cxxabiv1::__cxa_get_globals): Likewise.
Roger Sayle [Fri, 10 Jun 2022 14:14:23 +0000 (15:14 +0100)]
PR rtl-optimization/7061: Complex number arguments on x86_64-like ABIs.
This patch addresses the issue in comment #6 of PR rtl-optimization/7061
(a four digit PR number) from 2006 where on x86_64 complex number arguments
are unconditionally spilled to the stack.
For the test cases below:
float re(float _Complex a) { return __real__ a; }
float im(float _Complex a) { return __imag__ a; }
GCC with -O2 currently generates:
re: movq %xmm0, -8(%rsp)
movss -8(%rsp), %xmm0
ret
im: movq %xmm0, -8(%rsp)
movss -4(%rsp), %xmm0
ret
with this patch we now generate:
re: ret
im: movq %xmm0, %rax
shrq $32, %rax
movd %eax, %xmm0
ret
[Technically, this shift can be performed on %xmm0 in a single
instruction, but the backend needs to be taught to do that, the
important bit is that the SCmode argument isn't written to the
stack].
The patch itself is to emit_group_store where just before RTL
expansion commits to writing to the stack, we check if the store
group consists of a single scalar integer register that holds
a complex mode value; on x86_64 SCmode arguments are passed in
DImode registers. If this is the case, we can use a SUBREG to
"view_convert" the integer to the equivalent complex mode.
An interesting corner case that showed up during testing is that
x86_64 also passes HCmode arguments in DImode registers(!), i.e.
using modes of different sizes. This is easily handled/supported
by first converting to an integer mode of the correct size, and
then generating a complex mode SUBREG of this. This is similar
in concept to the patch I proposed here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590139.html
2020-06-10 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR rtl-optimization/7061
* expr.cc (emit_group_store): For groups that consist of a single
scalar integer register that hold a complex mode value, use
gen_lowpart to generate a SUBREG to "view_convert" to the complex
mode. For modes of different sizes, first convert to an integer
mode of the appropriate size.
gcc/testsuite/ChangeLog
PR rtl-optimization/7061
* gcc.target/i386/pr7061-1.c: New test case.
* gcc.target/i386/pr7061-2.c: New test case.
Jonathan Wakely [Thu, 9 Jun 2022 11:07:15 +0000 (12:07 +0100)]
libstdc++: Make std::hash<basic_string<>> allocator-agnostic (LWG 3705)
This new library issue was recently moved to Tentatively Ready by an LWG
poll, so I'm making the change on trunk.
As noted in PR libstc++/105907 the std::hash specializations for PMR
strings were not treated as slow hashes by the unordered containers, so
this change preserves that. The new specializations for custom
allocators are also not treated as slow, for the same reason. For the
versioned namespace (i.e. unstable ABI) we don't have to worry about
that, so can enable hash code caching for all basic_string
specializations.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (__hash_str_base): New class
template.
(hash<basic_string<C, char_traits<C>, A>>): Define partial
specialization for each of the standard character types.
(hash<string>, hash<wstring>, hash<u8string>, hash<u16string>)
(hash<u32string>): Remove explicit specializations.
* include/std/string (__hash_string_base): Remove class
template.
(hash<pmr::string>, hash<pmr::wstring>, hash<pmr::u8string>)
(hash<pmr::u16string>, hash<pmr::u32string>): Remove explicit
specializations.
* testsuite/21_strings/basic_string/hash/hash.cc: Test with
custom allocators.
* testsuite/21_strings/basic_string/hash/hash_char8_t.cc:
Likewise.
Antoni Boucher [Fri, 10 Jun 2022 01:37:23 +0000 (21:37 -0400)]
libgccjit: Support getting the size of a float [PR105829]
2022-06-09 Antoni Boucher <bouanto@zoho.com>
gcc/jit/
PR jit/105829
* libgccjit.cc: Add support for floating-point types in
gcc_jit_type_get_size.
gcc/testsuite/
PR jit/105829
* jit.dg/test-types.c: Add tests for gcc_jit_type_get_size.
GCC Administrator [Fri, 10 Jun 2022 00:16:43 +0000 (00:16 +0000)]
Daily bump.
Takayuki 'January June' Suwa [Sun, 29 May 2022 10:57:35 +0000 (19:57 +0900)]
xtensa: Add clrsbsi2 insn pattern
> (clrsb:m x)
> Represents the number of redundant leading sign bits in x, represented
> as an integer of mode m, starting at the most significant bit position.
This explanation is just what the NSA instruction (not ever emitted before)
calculates in Xtensa ISA.
gcc/ChangeLog:
* config/xtensa/xtensa.md (clrsbsi2): New insn pattern.
libgcc/ChangeLog:
* config/xtensa/lib1funcs.S (__clrsbsi2): New function.
* config/xtensa/t-xtensa (LIB1ASMFUNCS): Add _clrsbsi2.
Takayuki 'January June' Suwa [Sun, 29 May 2022 10:55:44 +0000 (19:55 +0900)]
xtensa: Optimize '(~x & y)' to '((x & y) ^ y)'
In Xtensa ISA, there is no single machine instruction that calculates unary
bitwise negation.
gcc/ChangeLog:
* config/xtensa/xtensa.md (*andsi3_bitcmpl):
New insn_and_split pattern.
gcc/testsuite/ChangeLog:
* gcc.target/xtensa/check_zero_byte.c: New.
Takayuki 'January June' Suwa [Sun, 29 May 2022 10:46:16 +0000 (19:46 +0900)]
xtensa: Make one_cmplsi2 optimizer-friendly
In Xtensa ISA, there is no single machine instruction that calculates unary
bitwise negation. But a few optimizers assume that bitwise negation can be
done by a single insn.
As a result, '((x < 0) ? ~x : x)' cannot be optimized to '(x ^ (x >> 31))'
ever before, for example.
This patch relaxes such limitation, by putting the insn expansion off till
the split pass.
gcc/ChangeLog:
* config/xtensa/xtensa.md (one_cmplsi2):
Rearrange as an insn_and_split pattern.
gcc/testsuite/ChangeLog:
* gcc.target/xtensa/one_cmpl_abs.c: New.
Takayuki 'January June' Suwa [Sun, 29 May 2022 10:44:32 +0000 (19:44 +0900)]
xtensa: Implement bswaphi2 insn pattern
This patch adds bswaphi2 insn pattern that is one instruction less than the
default expansion.
gcc/ChangeLog:
* config/xtensa/xtensa.md (bswaphi2): New insn pattern.
Joseph Myers [Thu, 9 Jun 2022 22:04:25 +0000 (22:04 +0000)]
Update gcc sv.po
* sv.po: Update.
Segher Boessenkool [Wed, 11 May 2022 18:43:57 +0000 (18:43 +0000)]
rs6000: Delete FP_ISA3
FP_ISA3 is exactly the same as SFDF, just a less obvious name. So,
let's delete it.
2022-06-09 Segher Boessenkool <segher@kernel.crashing.org>
* config/rs6000/rs6000.md (FP_ISA3): Delete.
(float<QHI:mode><FP_ISA3:mode>2): Rename to...
(float<QHI:mode><SFDF:mode>2): ... this. Adjust.
(*float<QHI:mode><FP_ISA3:mode>2_internal): Rename to...
(*float<QHI:mode><SFDF:mode>2_internal): ... this. Adjust.
(floatuns<QHI:mode><FP_ISA3:mode>2): Rename to...
(floatuns<QHI:mode><SFDF:mode>2): ... this. Adjust.
(*floatuns<QHI:mode><FP_ISA3:mode>2_internal): Rename to...
(*floatuns<QHI:mode><SFDF:mode>2_internal): ... this. Adjust.
Jakub Jelinek [Thu, 9 Jun 2022 17:44:50 +0000 (19:44 +0200)]
openmp: Fix up include of the generic allocator.c
As reported by Richard Sandiford, #include "../../../allocator.c"
has one too many ../s, dunno why it worked for me when using
../configure (VPATH = ../../../libgomp)
2022-06-09 Jakub Jelinek <jakub@redhat.com>
* config/linux/allocator.c: Fix up #include directive.
Jakub Jelinek [Thu, 9 Jun 2022 15:42:31 +0000 (17:42 +0200)]
c++: Fix up ICE on __builtin_shufflevector constexpr evaluation [PR105871]
As the following testcase shows, BIT_FIELD_REF result doesn't have to have
just integral type, it can also have vector type. And in that case
cxx_eval_bit_field_ref just ICEs on it because it is unprepared for that
case, creates the initial value with build_int_cst (sure, that one could be
easily replaced with build_zero_cst) and then expects it can through shifts,
ands and ors come up with the final value, but that doesn't work for
vectors.
We already call fold_ternary if whole is a VECTOR_CST, this patch does the
same if the result doesn't have integral type. And, there is no guarantee
fold_ternary will succeed and the callers certainly don't expect NULL
being returned, so it also diagnoses those as non-constant and returns
original t in that case.
2022-06-09 Jakub Jelinek <jakub@redhat.com>
PR c++/105871
* constexpr.cc (cxx_eval_bit_field_ref): For BIT_FIELD_REF with
non-integral result type use fold_ternary too like for BIT_FIELD_REFs
from VECTOR_CST. If fold_ternary returns NULL, diagnose non-constant
expression, set *non_constant_p and return t, instead of returning
NULL.
* g++.dg/pr105871.C: New test.
Maciej W. Rozycki [Thu, 9 Jun 2022 13:34:34 +0000 (14:34 +0100)]
RISC-V: Use a tab rather than space with FSFLAGS
Consistently use a tab rather than a space as the separator between the
assembly instruction mnemonic and its operand with FSFLAGS instructions
produced with the unordered FP comparison RTL insns.
gcc/
* config/riscv/riscv.md
(*f<quiet_pattern>_quiet<ANYF:mode><X:mode>4_default)
(*f<quiet_pattern>_quiet<ANYF:mode><X:mode>4_snan): Emit a tab
rather than space with FSFLAGS.
Nathan Sidwell [Wed, 8 Jun 2022 18:25:14 +0000 (11:25 -0700)]
c++: Better module initializer code
Every module interface needs to emit a global initializer, but it
might have nothing to init. In those cases, there's no need for any
idempotency boolean to be emitted.
gcc/cp
* cp-tree.h (module_initializer_kind): Replace with ...
(module_global_init_needed, module_has_import_inits): ...
these.
* decl2.cc (start_objects): Add has_body parm. Reorganize
module initializer creation.
(generate_ctor_or_dtor_function): Adjust.
(c_parse_final_cleanups): Adjust.
(vtv_start_verification_constructor_init_function): Adjust.
* module.cc (module_initializer_kind): Replace with ...
(module_global_init_needed, module_has_import_inits): ...
these.
gcc/testsuite/
* g++.dg/modules/init-2_a.C: Check no idempotency.
* g++.dg/modules/init-2_b.C: Check idempotency.
Tobias Burnus [Thu, 9 Jun 2022 12:48:24 +0000 (14:48 +0200)]
OpenMP: Handle ancestor:1 with discover_declare_target
gcc/
* omp-offload.cc (omp_discover_declare_target_tgt_fn_r,
omp_discover_declare_target_fn_r): Don't walk reverse-offload
target regions.
gcc/testsuite/
* c-c++-common/gomp/reverse-offload-1.c: New.
Jakub Jelinek [Thu, 9 Jun 2022 08:19:53 +0000 (10:19 +0200)]
doc: Fix up -Waddress documentation
WHen looking up the -Waddress documentation due to some PR that mentioned it,
I've noticed some typos and thus I'm fixing them.
2022-06-09 Jakub Jelinek <jakub@redhat.com>
* doc/invoke.texi (-Waddress): Fix a typo in small example.
Fix typos inptr_t -> intptr_t and uinptr_t -> uintptr_t.
Jakub Jelinek [Thu, 9 Jun 2022 08:14:42 +0000 (10:14 +0200)]
openmp: Add support for HBW or large capacity or interleaved memory through the libmemkind.so library
This patch adds support for dlopening libmemkind.so on Linux and uses it
for some kinds of allocations (but not yet e.g. pinned memory).
2022-06-09 Jakub Jelinek <jakub@redhat.com>
* allocator.c: Include dlfcn.h if LIBGOMP_USE_MEMKIND is defined.
(enum gomp_memkind_kind): New type.
(struct omp_allocator_data): Add memkind field if LIBGOMP_USE_MEMKIND
is defined.
(struct gomp_memkind_data): New type.
(memkind_data, memkind_data_once): New variables.
(gomp_init_memkind, gomp_get_memkind): New functions.
(omp_init_allocator): Initialize data.memkind, don't fail for
omp_high_bw_mem_space if libmemkind supports it.
(omp_aligned_alloc, omp_free, omp_aligned_calloc, omp_realloc): Add
memkind support of LIBGOMP_USE_MEMKIND is defined.
* config/linux/allocator.c: New file.
Cui,Lili [Wed, 8 Jun 2022 03:25:57 +0000 (11:25 +0800)]
Update {skylake,icelake,alderlake}_cost to add a bit preference to vector store.
Since the interger vector construction cost has changed, we need to adjust the
load and store costs for intel processers.
With the patch applied
538.imagic_r:gets ~6% improvement on ADL for multicopy.
525.x264_r :gets ~2% improvement on ADL and ICX for multicopy.
with no measurable changes for other benchmarks.
gcc/ChangeLog
PR target/105493
* config/i386/x86-tune-costs.h (skylake_cost): Raise the gpr load cost
from 4 to 6 and gpr store cost from 6 to 8. Change SSE loads and
unaligned loads cost from {6, 6, 6, 10, 20} to {8, 8, 8, 8, 16}.
(icelake_cost): Ditto.
(alderlake_cost): Raise the gpr store cost from 6 to 8 and SSE loads,
stores and unaligned stores cost from {6, 6, 6, 10, 15} to
{8, 8, 8, 10, 15}.
gcc/testsuite/
PR target/105493
* gcc.target/i386/pr91446.c: Adjust to expect vectorization
* gcc.target/i386/pr99881.c: XFAIL.
* gcc.target/i386/pr105493.c: New.
* g++.target/i386/pr105638.C: Use other sequence checks
instead of vpxor, because code generation changed.
Haochen Gui [Thu, 9 Jun 2022 05:24:15 +0000 (13:24 +0800)]
This patch replaces shift and ior insns with one rotate and mask insn for the split patterns which are for DI byte swap on Power6.
gcc/
* config/rs6000/rs6000.md (define_split for bswapdi load): Merge shift
and ior insns to one rotate and mask insn.
(define_split for bswapdi register): Likewise.
gcc/testsuite/
* gcc.target/powerpc/pr93453-1.c: New.
GCC Administrator [Thu, 9 Jun 2022 00:16:26 +0000 (00:16 +0000)]
Daily bump.
Jason Merrill [Tue, 7 Jun 2022 19:52:30 +0000 (15:52 -0400)]
c++: non-templated friends [PR105852]
The previous patch for 105852 avoids copying DECL_TEMPLATE_INFO from a
non-templated friend, but it really shouldn't have it in the first place.
PR c++/105852
gcc/cp/ChangeLog:
* decl.cc (duplicate_decls): Change non-templated friend
check to an assert.
* pt.cc (tsubst_function_decl): Don't set DECL_TEMPLATE_INFO
on non-templated friends.
(tsubst_friend_function): Adjust.
Jason Merrill [Tue, 7 Jun 2022 01:49:06 +0000 (21:49 -0400)]
c++: redeclared hidden friend take 2 [PR105852]
My previous patch for 105761 avoided copying DECL_TEMPLATE_INFO from a
friend to a later definition, but in this testcase we have first a
non-friend declaration and then a definition, and we need to avoid copying
in that case as well. But we do still want to set new_template_info to
avoid GC trouble.
With this change, the modules dump correctly identifies ::foo as a
non-template function in tpl-friend-2_a.C.
Along the way I noticed that the duplicate_decls handling of
DECL_UNIQUE_FRIEND_P was backwards for templates, where we don't clobber
DECL_LANG_SPECIFIC (olddecl) with DECL_LANG_SPECIFIC (newdecl) like we do
for non-templates.
PR c++/105852
PR c++/105761
gcc/cp/ChangeLog:
* decl.cc (duplicate_decls): Avoid copying template info
from non-templated friend even if newdecl isn't a definition.
Correct handling of DECL_UNIQUE_FRIEND_P on templates.
* pt.cc (non_templated_friend_p): New.
* cp-tree.h (non_templated_friend_p): Declare it.
gcc/testsuite/ChangeLog:
* g++.dg/modules/tpl-friend-2_a.C: Adjust expected dump.
* g++.dg/template/friend74.C: New test.
Roger Sayle [Wed, 8 Jun 2022 19:43:03 +0000 (20:43 +0100)]
PR middle-end/105874: Use EXPAND_MEMORY to fix ada bootstrap.
Many thanks to Tamar Christina for filing PR middle-end/105874 indicating
that SPECcpu 2017's Leela is failing on x86_64 due to a miscompilation
of FastBoard::is_eye. This function is much smaller and easier to work
with than my previous hunt for the cause of the Ada bootstrap failures
due to miscompilation somewhere in GCC (or one of the 131 places that
the problematic form of optimization triggers during an ada bootstrap).
It turns out the source of the miscompilation introduced by my recent
patch is the distinction (during RTL expansion) of l-values and r-values.
According to the documentation above expand_modifier, EXPAND_MEMORY
should be used for lvalues (when a memory is required), and EXPAND_NORMAL
for rvalues when a constant is permissible. In what I'd like to consider
a latent bug, the recursive call to expand_expr_real on line 11188 of
expr.cc, in the case handling ARRAY_REF, COMPONENT_REF, BIT_FIELD_REF
and ARRARY_RANGE_REF was passing EXPAND_NORMAL when it really required
(the semantics of) EXPAND_MEMORY. All the time that VAR_DECLs were
being returned as memory this was fine, but as soon as we're able to
optimize sort arrays into immediate constants, bad things happen.
In the test case from Leela, we notice that the array s_eyemask
always has DImode constant value { 4, 64 }, which is useful as
an rvalue, but not when we need to index it as an lvalue, as in
s_eyemask[color]. This also explains why everything being accepted
by immediate_const_ctor_p (during an ada bootstrap) looks reasonable,
what's incorrect is that we don't know how these structs/arrays are
to be used.
The fix is to ensure that we call expand_expr with EXPAND_MEMORY
when processing the VAR_DECL's returned by get_inner_reference.
2022-06-08 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR middle-end/105874
* expr.cc (expand_expr_real_1) <normal_inner_ref>: New local
variable tem_modifier for calculating the expand_modifier enum to
use for expanding tem. If tem is a VAR_DECL, use EXPAND_MEMORY.
gcc/testsuite/ChangeLog
PR middle-end/105874
* g++.dg/opt/pr105874.C: New test case.
Max Filippov [Wed, 8 Jun 2022 04:01:01 +0000 (21:01 -0700)]
gcc: xtensa: fix PR target/105879
split_double operates with the 'word that comes first in memory in the
target' terminology, while gen_lowpart operates with the 'value
representing some low-order bits of X' terminology. They are not
equivalent and must be dealt with differently on little- and big-endian
targets.
gcc/
PR target/105879
* config/xtensa/xtensa.md (movdi): Rename 'first' and 'second'
to 'lowpart' and 'highpart' so that they match 'gen_lowpart' and
'gen_highpart' bitwise semantics and fix order of highpart and
lowpart depending on target endianness.
Nathan Sidwell [Tue, 31 May 2022 17:42:35 +0000 (10:42 -0700)]
c++: Reimplement static init/fini generation
Currently we generate static init/fini code by generating a set of
functions taking an 'initp' bool and an unsigned priority. (There can
be more than one, as we repeat the end-of-compile loop.) We then
generate a set of real init or fini functions for each needed
prioroty, calling the previous set of functions. This is of course
very tangled, but excitingly the value-range-propagator is clever
enough to unentangle it. However, the current arrangement makes
generation awkward, particularly as to how to optimize the
module-global-init generation.
This reimplements the generation to generate a set of separate
init/fini functions for each needed priority, and then call them from
the real inits previously mentioned. This replaces a splay tree,
recording which priority/init combos we needed, with a pair of hash
tables, mapping priority to init functions. Much simpler.
While there, rename several of the functions as they are only dealing
with part of the init/fini generation, not the whole set.
gcc/cp/
* decl2.cc (struct priority_info_s, priority_info): Delete.
(priority_map_traits, priority_map_t): New.
(static_init_fini_fns): New.
(INITIALIZE_P_IDENTIFIER, PRIORITY_IDENTIFIER): Delete.
(initialize_p_decl, priority_decl): Delete.
(ssdf_decls, priority_info_map): Delete.
(start_static_storage_duration_function): Rename to ...
(start_partial_init_fini_fn): ... here. Create a void arg fn.
Add it to the slot in the appropriate static_init_fini_fns
hash table.
(finish_static_storage_duration_function): Rename to ...
(finish_partial_init_fini_fn): ... here.
(get_priority_info): Delete.
(one_static_initialization_or_destruction): Assert not
trivial dtor.
(do_static_initialization_or_destruction): Rename to ...
(emit_partial_init_fini_fn) ... here. Start & finish the fn.
Simply init/fini each var.
(partition_vars_for_init_fini): Partition vars according to
priority and add to init and/or fini list.
(generate_ctor_or_dtor_function): Start and finish the function.
Do santitizer calls here.
(generate_ctor_and_dtor_functions_for_priority): Delete.
(c_parse_final_cleanups): Reimplement global init/fini
processing.
gcc/testsuite/
* g++.dg/init/static-cdtor1.C: New.
Roger Sayle [Wed, 8 Jun 2022 09:06:23 +0000 (10:06 +0100)]
[Committed] Add -mno-avx2 to recent gcc.target/i386/xop-vpcmov3.c
Adding -march=cascadelake to the command line options of the recently
added xop-vpcmov3.c test case causes problems as GCC then prefers to
use AVX512's vpternlogd instruction, instead of the XOP vpcmov that
the test is checking for. This is easily solved by adding an explicit
-mno-avx512vl to the command line options.
Committed to mainline as obvious (in hindsight).
2022-06-08 Roger Sayle <roger@nextmovesoftware.com>
gcc/testsuite/ChangeLog
* gcc.target/i386/xop-pcmov3.c: Add -mno-avx512vl to dg-options.
Tobias Burnus [Wed, 8 Jun 2022 08:06:57 +0000 (10:06 +0200)]
OpenMP: Fortran - fix ancestor's requires reverse_offload check
gcc/fortran/
* openmp.cc (gfc_match_omp_clauses): Check also parent namespace
for 'requires reverse_offload'.
gcc/testsuite/
* gfortran.dg/gomp/target-device-ancestor-5.f90: New test.
Chung-Ju Wu [Wed, 8 Jun 2022 07:14:11 +0000 (07:14 +0000)]
arm: Add star-mc1 cpu
The star-mc1 is an embedded processor with armv8m architecture. Majorly
it is designed to meet the requirements of AIoT application performance,
power consumption and security. This patch is to add support of star-mc1
cpu.
Signed-off-by: Chung-Ju Wu <jasonwucj@gmail.com>
gcc/ChangeLog:
* config/arm/arm-cpus.in (star-mc1): New cpu.
* config/arm/arm-tables.opt: Regenerate.
* config/arm/arm-tune.md: Regenerate.
* doc/invoke.texi: Update docs.
Yang Yujie [Thu, 19 May 2022 08:10:15 +0000 (16:10 +0800)]
libgccjit: allow common objects in $(EXTRA_GCC_OBJS) and $(EXTRA_OBJS)
This patch fixes libgccjit build failure on loongarch* targets,
and could probably be useful for future ports.
For now, libgccjit is linked with objects from $(EXTRA_GCC_OBJS) and
libbackend.a, which contains object files from $(EXTRA_OBJS).
This effectively forbids any overlap between those two lists, i.e. all
target-specific shared code between the gcc driver and compiler
executables must go into gcc/common/config/<arch>/<arch>-common.cc,
which feels a bit inconvenient when there are a lot of "common" stuff
that we want to put into separate source files.
By linking libgccjit with $(EXTRA_GCC_OBJS_EXCLUSIVE), which contains
all elements from $(EXTRA_GCC_OBJS) but not $(EXTRA_OBJS), this problem
can be alleviated.
This patch does not affect any other target architecture than loongarch,
and has been bootstrapped and regression-tested on loongarch64-linux-gnuf64
an x86_64-pc-linux-gnu.
* gcc/jit/ChangeLog:
* Make-lang.in: only link objects from $(EXTRA_GCC_OBJS)
that's not in $(EXTRA_OBJS) into libgccjit.
liuhongt [Mon, 30 May 2022 07:30:51 +0000 (15:30 +0800)]
Disparages SSE_REGS alternatives sligntly with ?v instead of *v in *mov{si,di}_internal.
So alternative v won't be igored in record_reg_classess.
Similar for *r alternatives in some vector patterns.
It helps testcase in the PR, also RA now makes better decisions for
gcc.target/i386/extract-insert-combining.c
movd %esi, %xmm0
movd %edi, %xmm1
- movl %esi, -12(%rsp)
paddd %xmm0, %xmm1
pinsrd $0, %esi, %xmm0
paddd %xmm1, %xmm0
The patch has no big impact on SPEC2017 for both O2 and Ofast
march=native run.
And I noticed there's some changes in SPEC2017 from code like
mov mem, %eax
vmovd %eax, %xmm0
..
mov %eax, 64(%rsp)
to
vmovd mem, %xmm0
..
vmovd %xmm0, 64(%rsp)
Which should be exactly what we want?
gcc/ChangeLog:
PR target/105513
PR target/105504
* config/i386/i386.md (*movsi_internal): Change alternative
from *v to ?v.
(*movdi_internal): Ditto.
* config/i386/sse.md (vec_set<mode>_0): Change alternative *r
to ?r.
(*vec_extractv4sf_mem): Ditto.
(*vec_extracthf): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr105513-1.c: New test.
* gcc.target/i386/extract-insert-combining.c: Add new
scan-assembler-not for spill.
liuhongt [Wed, 8 Jun 2022 02:55:32 +0000 (10:55 +0800)]
Adjust testcase to avoid compile failure under -m32.
gcc/testsuite/ChangeLog:
PR target/105854
* gcc.target/i386/pr105854.c: Add target int128 and dfp.
GCC Administrator [Wed, 8 Jun 2022 00:16:28 +0000 (00:16 +0000)]
Daily bump.
Richard Earnshaw [Tue, 7 Jun 2022 11:09:47 +0000 (12:09 +0100)]
arm: Improve code generation for BFI and BFC [PR105090]
This patch, in response to PR105090, makes some general improvements
to the code generation when BFI and BFC instructions are available.
Firstly we handle more cases where the RTL does not generate an INSV
operation due to a lack of a tie between the input and output, but we
nevertheless need to emit BFI later on; we handle this by requiring
the register allocator to tie the operands. Secondly we handle some
cases where we were previously emitting BFC, but AND with an immediate
would be better; we do this by converting all BFC patterns into AND
using a split pattern. And finally, we handle some cases where
previously we would emit multiple BIC operations to clear a value, but
could instead use a single BFC instruction.
BFC and BFI express the mask as a pair of values, one for the number
of bits to clear and another for the location of the least significant
bit. We handle these with a single new output modifier letter that
causes both values to be printed; we use an 'inverted' value so that
it can be used directly with the constant used in an AND rtl
construct. We've run out of 'new' letters, so to do this we re-use
one of the long-obsoleted Maverick output modifiers.
gcc/ChangeLog:
PR target/105090
* config/arm/arm.cc (arm_bfi_1_p): New function.
(arm_bfi_p): New function.
(arm_rtx_costs_internal): Add costs for BFI idioms.
(arm_print_operand [case 'V']): Format output for BFI/BFC masks.
* config/arm/constraints.md (Dj): New constraint.
* config/arm/arm.md (arm_andsi3_insn): Add alternative to use BFC.
(insv_zero): Convert to an insn with a split.
(*bfi, *bfi_alt1, *bfi_alt2, *bfi_alt3): New patterns.
liuhongt [Mon, 6 Jun 2022 05:39:19 +0000 (13:39 +0800)]
Fix insn does not satisfy its constraints: sse2_lshrv1ti3
21114(define_insn_and_split "ssse3_palignrdi"
21115 [(set (match_operand:DI 0 "register_operand" "=y,x,Yv")
21116 (unspec:DI [(match_operand:DI 1 "register_operand" "0,0,Yv")
21117 (match_operand:DI 2 "register_mmxmem_operand" "ym,x,Yv")
21118 (match_operand:SI 3 "const_0_to_255_mul_8_operand")]
21119 UNSPEC_PALIGNR))]
21120 "(TARGET_MMX || TARGET_MMX_WITH_SSE) && TARGET_SSSE3"
Alternative 2 requires Yw instead of Yv since it's splitted to vpsrldq
which requires AVX512VL & AVX512BW for evex version.
gcc/ChangeLog:
PR target/105854
* config/i386/sse.md (ssse3_palignrdi): Change alternative 2
from Yv to Yw.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr105854.c: New test.
Roger Sayle [Tue, 7 Jun 2022 09:09:49 +0000 (10:09 +0100)]
PR middle-end/105853: Call store_constructor directly from calls.cc.
This patch fixes both ICE regressions PR middle-end/105853 and
PR target/105856 caused by my recent patch to expand small const structs
as immediate constants. That patch updated code generation in three
places: two in expr.cc that call store_constructor directly, and the
third in calls.cc's load_register_parameters that expands its CONSTRUCTOR
via expand_expr, as store_constructor is local/static to expr.cc, and
the "public" API, should usually simply forward the constructor to the
appropriate store_constructor function.
Alas, despite the clean regression testing on multiple targets, the above
ICEs show that expand_expr isn't a suitable proxy for store_constructor,
and things that (I'd assumed) shouldn't affect how/whether a struct is
placed in a register [such as whether the struct is considered packed/
aligned or not] actually interfere with the optimization that is being
attempted.
The (proposed) solution is to export store_constructor (and it's helper
function int_expr_size) from expr.cc, by removing their static qualifier
and prototyping both functions in expr.h, so they can be called directly
from load_register_parameters in calls.cc. This cures both ICEs, but
almost as importantly improves code generation over GCC 12.
For PR 105853, GCC 12 generates:
compose_nd_na_ipv6_src:
movzx eax, WORD PTR eth_addr_zero[rip+2]
movzx edx, WORD PTR eth_addr_zero[rip]
movzx edi, WORD PTR eth_addr_zero[rip+4]
sal rax, 16
or rax, rdx
sal rdi, 32
or rdi, rax
xor eax, eax
jmp packet_set_nd
eth_addr_zero: .zero 6
where now (with this fix) GCC 13 generates:
compose_nd_na_ipv6_src:
xorl %edi, %edi
xorl %eax, %eax
jmp packet_set_nd
Likewise, for PR 105856 on ARM, we'd previously generate:
g_329_3:
movw r3, #:lower16:.LANCHOR0
movt r3, #:upper16:.LANCHOR0
ldr r0, [r3]
b func_19
but with this optimization we now generate:
g_329_3:
mov r0, #6
b func_19
2022-06-07 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR middle-end/105853
PR target/105856
* calls.cc (load_register_parameters): Call store_constructor
and int_expr_size directly instead of expanding via expand_expr.
* expr.cc (static void store_constructor): Don't prototype here.
(static HOST_WIDE_INT int_expr_size): Likewise.
(store_constructor): No longer static.
(int_expr_size): Likewise, no longer static.
* expr.h (store_constructor): Prototype here.
(int_expr_size): Prototype here.
gcc/testsuite/ChangeLog
PR middle-end/105853
PR target/105856
* gcc.dg/pr105853.c: New test case.
* gcc.dg/pr105856.c: New test case.
Jan Beulich [Tue, 7 Jun 2022 08:24:53 +0000 (10:24 +0200)]
Revert "configure: arrange to use appropriate objcopy"
This reverts commit
6124f4248888484f419671f4f7bd40d253d3de06.
It lacks pieces to work with system binutils.
Jakub Jelinek [Tue, 7 Jun 2022 08:05:08 +0000 (10:05 +0200)]
openmp: Add support for OpenMP 5.2 linear clause syntax for C/C++
The syntax for linear clause changed in 5.2, the original syntax
which is still valid is:
linear (var1, var2)
linear (var3, var4 : step1)
The 4.5 syntax with modifiers like:
linear (val (var5, var6))
linear (val (var7, var8) : step2)
is still supported in 5.2, but is deprecated there.
Instead, one can use a new syntax:
linear (var9, var10 : val)
linear (var11, var12 : step (step3), val)
As val, ref, uval or step (someexpr) can be valid expressions (and especially
in C++ can be const / constexpr / consteval), the spec says that
when the whole step expression is val (or ref or uval) or step ( ... )
then it is the new modifier syntax, one can use + 0 or 0 + or 1 * or * 1
or ()s to say it is the old step expression.
Also, 5.2 now allows val modifier to be specified even outside of declare simd
(but not the other modifiers). I've implemented this for the new modifier
syntax only, the old one keeps the old restriction (which is why
OMP_CLAUSE_LINEAR_OLD_LINEAR_MODIFIER flag has been introduced).
2022-06-07 Jakub Jelinek <jakub@redhat.com>
gcc/
* tree.h (OMP_CLAUSE_LINEAR_OLD_LINEAR_MODIFIER): Define.
* tree-pretty-print.cc (dump_omp_clause) <case OMP_CLAUSE_LINEAR>:
Adjust clause printing style depending on
OMP_CLAUSE_LINEAR_OLD_LINEAR_MODIFIER.
gcc/c/
* c-parser.cc (c_parser_omp_clause_linear): Parse OpenMP 5.2
style linear clause modifiers. Set
OMP_CLAUSE_LINEAR_OLD_LINEAR_MODIFIER flag on the clauses when
old style modifiers are used.
* c-typeck.cc (c_finish_omp_clauses): Only reject linear clause
with val modifier on simd or for if the old style modifiers are
used.
gcc/cp/
* parser.cc (cp_parser_omp_clause_linear): Parse OpenMP 5.2
style linear clause modifiers. Set
OMP_CLAUSE_LINEAR_OLD_LINEAR_MODIFIER flag on the clauses when
old style modifiers are used.
* semantics.cc (finish_omp_clauses): Only reject linear clause
with val modifier on simd or for if the old style modifiers are
used.
gcc/fortran/
* trans-openmp.cc (gfc_trans_omp_clauses): Set
OMP_CLAUSE_LINEAR_OLD_LINEAR_MODIFIER on OMP_CLAUSE_LINEAR
clauses unconditionally for now.
gcc/testsuite/
* c-c++-common/gomp/linear-2.c: New test.
* c-c++-common/gomp/linear-3.c: New test.
* g++.dg/gomp/linear-3.C: New test.
* g++.dg/gomp/linear-4.C: New test.
* g++.dg/gomp/linear-5.C: New test.
Jan Beulich [Tue, 7 Jun 2022 07:18:28 +0000 (09:18 +0200)]
x86: harmonize __builtin_ia32_psadbw*() types
The 64-bit, 128-bit, and 512-bit variants have V<n>DI return type, in
line with instruction behavior. Make the 256-bit builtin match, thus
also making it match the insn it expands to (using VI8_AVX2_AVX512BW).
gcc/
* config/i386/i386-builtin.def (__builtin_ia32_psadbw256):
Change type.
* config/i386/i386-builtin-types.def: New function type
(V4DI, V32QI, V32QI).
* config/i386/i386-expand.cc (ix86_expand_args_builtin): Handle
V4DI_FTYPE_V32QI_V32QI.
Jan Beulich [Tue, 7 Jun 2022 07:17:25 +0000 (09:17 +0200)]
x86-64: make "length_vex" also account for VEX.B use by register operand
The length attribute ought to be "the (bounding maximum) length of an
instruction" according to the comment next to its definition. A register
operand encoded using the ModR/M.rm field will additionally use VEX.B
for encoding the highest bit of the register number. Hence for the high
8 GPR registers as well as the [xy]mm{8..15} ones 3-byte VEX encoding
may be needed. Since it isn't known to the function calculating the
length which register goes where in the insn encoding, be conservative
and assume a 3-byte VEX prefix whenever any such register operand is
present and there's no memory operand.
gcc/
* config/i386/i386.cc (ix86_attr_length_vex_default): Take REX.B
into account for reg-only insns.
Roger Sayle [Tue, 7 Jun 2022 06:54:13 +0000 (07:54 +0100)]
PR c++/96442: Improved error recovery in enumerations.
This patch is a revised fix for PR c++/96442 providing a cleaner
solution, setting ENUM_UNDERLYING_TYPE to integer_type_node when
issuing an error, so that this invariant holds during the parser's
error recovery.
2022-06-07 Roger Sayle <roger@nextmovesoftware.com>
gcc/cp/ChangeLog
PR c++/96442
* decl.cc (start_enum): When emitting a "must be integral" error,
set ENUM_UNDERLYING_TYPE to integer_type_node, to avoid an ICE
downstream in build_enumeration.
gcc/testsuite/ChangeLog
PR c++/96442
* g++.dg/parse/pr96442.C: New test case.
Roger Sayle [Tue, 7 Jun 2022 06:49:40 +0000 (07:49 +0100)]
Recognize vpcmov in combine with -mxop on x86.
By way of an apology for causing PR target/105791, where I'd overlooked
the need to support V1TImode in TARGET_XOP's vpcmov instruction, this
patch further improves support for TARGET_XOP's vpcmov instruction, by
recognizing it in combine.
Currently, the test case:
typedef int v4si __attribute__ ((vector_size (16)));
v4si foo(v4si c, v4si t, v4si f)
{
return (c&t)|(~c&f);
}
on x86_64 with -O2 -mxop generates:
vpxor %xmm2, %xmm1, %xmm1
vpand %xmm0, %xmm1, %xmm1
vpxor %xmm2, %xmm1, %xmm0
ret
but with this patch now generates:
vpcmov %xmm0, %xmm2, %xmm1, %xmm0
ret
On its own, the new combine splitter works fine on TARGET_64BIT, but
alas with -m32 combine incorrectly thinks the replacement instruction
is more expensive, as IF_THEN_ELSE isn't currently/correctly handled
in ix86_rtx_costs. So to avoid the need for a target selector in the
new tescase, I've updated ix86_rtx_costs to report that AMD's vpcmov
has a latency of two cycles [it's now an obsolete instruction set
extension and there's unlikely to ever be a processor where this
instruction has a different timing], and while there I also added
rtx_costs for x86_64's integer conditional move instructions (which
have single cycle latency).
2022-06-07 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
* config/i386/i386.cc (ix86_rtx_costs): Add a new case for
IF_THEN_ELSE, and provide costs for TARGET_XOP's vpcmov and
TARGET_CMOVE's (scalar integer) conditional moves.
* config/i386/sse.md (define_split): Recognize XOP's vpcmov
from its equivalent (canonical) pxor;pand;pxor sequence.
gcc/testsuite/ChangeLog
* gcc.target/i386/xop-pcmov3.c: New test case.
Kewen Lin [Tue, 7 Jun 2022 03:08:23 +0000 (22:08 -0500)]
Update document for VECTOR_MODES_WITH_PREFIX
r10-3912 updated the format of VECTOR_MODES_WITH_PREFIX by
adding one more parameter ORDER, the related document is out
of date. So update the document for ORDER.
gcc/ChangeLog:
* machmode.def (VECTOR_MODES_WITH_PREFIX): Update document for
parameter ORDER.
GCC Administrator [Tue, 7 Jun 2022 00:16:20 +0000 (00:16 +0000)]
Daily bump.
Patrick Palka [Mon, 6 Jun 2022 18:29:12 +0000 (14:29 -0400)]
c++: function NTTP argument considered unused [PR53164, PR105848]
Here at parse time the template argument f (an OVERLOAD) in A<f> gets
resolved ahead of time to the FUNCTION_DECL f<int>, and we defer marking
f<int> as used until instantiation (of g) as usual.
Later when instantiating g the type A<f> (where f has already been
resolved) is non-dependent, so tsubst_aggr_type avoids re-processing its
template arguments, and we end up never actually marking f<int> as used
(which means we never instantiate it) even though A<f>::h() later calls
it, leading to a link error.
This patch works around this issue by looking through ADDR_EXPR when
calling mark_used on the substituted callee of a CALL_EXPR.
PR c++/53164
PR c++/105848
gcc/cp/ChangeLog:
* pt.cc (tsubst_copy_and_build) <case CALL_EXPR>: Look through an
ADDR_EXPR callee when calling mark_used.
gcc/testsuite/ChangeLog:
* g++.dg/template/fn-ptr3.C: New test.
Andrew Stubbs [Mon, 6 Jun 2022 14:35:49 +0000 (15:35 +0100)]
arm: reinstate HAVE_GAS_ARM_EXTENDED_ARCH
The check was removed by accident.
gcc/ChangeLog:
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Reinstate HAVE_GAS_ARM_EXTENDED_ARCH test.
GCC Administrator [Mon, 6 Jun 2022 00:16:21 +0000 (00:16 +0000)]
Daily bump.
GCC Administrator [Sun, 5 Jun 2022 00:16:27 +0000 (00:16 +0000)]
Daily bump.
Marek Polacek [Thu, 2 Jun 2022 19:44:20 +0000 (15:44 -0400)]
c++: Allow mixing GNU/std-style attributes [PR69585]
cp_parser_attributes_opt doesn't accept GNU attributes followed by
[[]] attributes and vice versa; only a sequence of attributes of the
same kind. That causes grief for code like:
struct __attribute__ ((may_alias)) alignas (2) struct S { };
or
#define EXPORT __attribute__((visibility("default")))
struct [[nodiscard]] EXPORT F { };
It doesn't seem to a documented restriction, so this patch fixes the
problem.
However, the patch does not touch the C FE. The C FE doesn't have
a counterpart to C++'s cp_parser_attributes_opt -- it only has
c_parser_transaction_attributes (which parses both GNU and [[]]
attributes), but that's TM-specific. The C FE seems to use either
c_parser_gnu_attributes or c_parser_std_attribute_specifier_sequence.
As a consequence, this works:
[[maybe_unused]] __attribute__((deprecated)) void f2 ();
but this doesn't:
__attribute__((deprecated)) [[maybe_unused]] void f1 ();
I'm not sure what, if anything, should be done about this.
PR c++/102399
PR c++/69585
gcc/cp/ChangeLog:
* parser.cc (cp_parser_attributes_opt): Accept GNU attributes
followed by [[]] attributes and vice versa.
gcc/testsuite/ChangeLog:
* g++.dg/ext/attrib65.C: New test.
* g++.dg/ext/attrib66.C: New test.
* g++.dg/ext/attrib67.C: New test.
Roger Sayle [Sat, 4 Jun 2022 11:21:51 +0000 (12:21 +0100)]
PR middle-end/95126: Expand small const structs as immediate constants.
This patch resolves PR middle-end/95126 which is a code quality regression,
by teaching the RTL expander to emit small const structs/unions as integer
immediate constants.
The motivating example from the bugzilla PR is:
struct small{ short a,b; signed char c; };
extern int func(struct small X);
void call_func(void)
{
static struct small const s = { 1, 2, 0 };
func(s);
}
which on x86_64 is currently compiled to:
call_func:
movzwl s.0+2(%rip), %eax
movzwl s.0(%rip), %edx
movzwl s.0+4(%rip), %edi
salq $16, %rax
orq %rdx, %rax
salq $32, %rdi
orq %rax, %rdi
jmp func
but with this patch is now optimized to:
call_func:
movl $131073, %edi
jmp func
2022-06-04 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR middle-end/95126
* calls.cc (load_register_parameters): When loading a suitable
immediate_const_ctor_p VAR_DECL into a single word_mode register,
construct it directly in a pseudo rather than read it (by parts)
from memory.
* expr.cc (int_expr_size): Make tree argument a const_tree.
(immediate_const_ctor_p): Helper predicate. Return true for
simple constructors that may be materialized in a register.
(expand_expr_real_1) [VAR_DECL]: When expanding a constant
VAR_DECL with a suitable immediate_const_ctor_p constructor
use store_constructor to materialize it directly in a pseudo.
* expr.h (immediate_const_ctor_p): Prototype here.
* varasm.cc (initializer_constant_valid_for_bitfield_p): Change
VALUE argument from tree to const_tree.
* varasm.h (initializer_constant_valid_for_bitfield_p): Update
prototype.
gcc/testsuite/ChangeLog
PR middle-end/95126
* gcc.target/i386/pr95126-m32-1.c: New test case.
* gcc.target/i386/pr95126-m32-2.c: New test case.
* gcc.target/i386/pr95126-m32-3.c: New test case.
* gcc.target/i386/pr95126-m32-4.c: New test case.
* gcc.target/i386/pr95126-m64-1.c: New test case.
* gcc.target/i386/pr95126-m64-2.c: New test case.
* gcc.target/i386/pr95126-m64-3.c: New test case.
* gcc.target/i386/pr95126-m64-4.c: New test case.
Jakub Jelinek [Sat, 4 Jun 2022 08:36:24 +0000 (10:36 +0200)]
i386: Fix up *_doubleword_mask [PR105825]
My PR105778 patch apparently broke the following testcase.
If the mask has the top relevant bit clear (i.e. we know we are shifting
by 0 to wordsize bits - 1) but doesn't have all the bits below it set,
we emit andsi3 before the shift sequence. When the pattern had :SI
for that operand, that was just fine, but now that it can be also HImode
or for -m64 DImode, we either can use a lowpart or paradoxical subreg to
SImode as the following patch, or we use a HImode or DImode AND.
This patch does the latter.
2022-06-04 Jakub Jelinek <jakub@redhat.com>
PR target/105825
* config/i386/i386.md (*ashl<dwi>3_doubleword_mask,
*<insn><dwi>3_doubleword_mask): If top bit of mask is clear, but lower
bits of mask aren't all set, use operands[2] mode for the AND
operation instead of always SImode.
* gcc.dg/pr105825.c: New test.
GCC Administrator [Sat, 4 Jun 2022 00:16:27 +0000 (00:16 +0000)]
Daily bump.
Jason Merrill [Fri, 3 Jun 2022 18:53:59 +0000 (14:53 -0400)]
c++: more-specialized test
I noticed the need for this testcase while working on PR102629; since there
is no information about the target type, we don't want to choose the most
specialized overload.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/auto56.C: New test.
Patrick Palka [Fri, 3 Jun 2022 18:58:22 +0000 (14:58 -0400)]
c++: value-dep but not type-dep decltype expr [PR105756]
Here during ahead of time instantiation of the value-dependent but not
type-dependent decltype expression (5 % N) == 0, cp_build_binary_op folds
the operands of the == via cp_fully_fold, which performs speculative
constexpr evaluation, and from which we crash for (5 % N) due to the
value-dependence.
Since the operand folding performed by cp_build_binary_op appears to
be solely for sake of diagnosing overflow, and since these diagnostics
are suppressed when in an unevaluated context, this patch avoids this
crash by suppressing cp_build_binary_op's operand folding accordingly.
PR c++/105756
gcc/cp/ChangeLog:
* typeck.cc (cp_build_binary_op): Don't fold operands
when c_inhibit_evaluation_warnings.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/decltype82.C: New test.
Jason Merrill [Fri, 3 Jun 2022 16:35:12 +0000 (12:35 -0400)]
c++: redeclared hidden friend [PR105761]
Here, when we see the second declaration of f we match it with the first
one, copy over DECL_TEMPLATE_INFO, and then try to use it when parsing the
definition, leading to confusion.
PR c++/105761
gcc/cp/ChangeLog:
* decl.cc (duplicate_decls): Don't copy DECL_TEMPLATE_INFO
from a hidden friend.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/auto-fn64.C: New test.
Patrick Palka [Fri, 3 Jun 2022 16:06:59 +0000 (12:06 -0400)]
c++: cv-quals of dummy obj for non-dep memfn call [PR105637]
In non-dependent23.C below we expect the Base::foo calls to
resolve to the second, third and fourth overloads respectively in light
of the cv-qualifiers of 'this' in each case. But ever since
r12-6075-g2decd2cabe5a4f, the calls incorrectly resolve to the first
overload at instantiation time.
This happens because the calls to Base::foo are all deemed
non-dependent (ever since r7-755-g23cb72663051cd made us ignore 'this'
dependence when considering the dependence of a non-static memfn call),
hence we end up checking the call ahead of time, using as the object
argument a dummy object of type Base. Since this object argument is
cv-unqualified, the calls in turn resolve to the unqualified overload
of baseDevice. Before r12-6075 this incorrect result would just get
silently discarded and we'd end up redoing OR at instantiation time
using 'this' as the object argument. But after r12-6075 we now reuse
this incorrect result at instantiation time.
This patch fixes this by making maybe_dummy_object respect the cv-quals
of (the non-lambda) 'this' when returning a dummy object. Thus, ahead
of time OR using a dummy object will give us the right answer that's
consistent with the instantiation time answer.
An earlier version of this patch didn't handle 'this'-capturing lambdas
correctly, which broke lambda-this22.C below.
PR c++/105637
gcc/cp/ChangeLog:
* tree.cc (maybe_dummy_object): When returning a dummy
object, respect the cv-quals of 'this' if available.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/lambda/lambda-this22.C: New test.
* g++.dg/template/non-dependent23.C: New test.
Tobias Burnus [Fri, 3 Jun 2022 13:55:03 +0000 (15:55 +0200)]
gfortran.dg/gomp/scope-6.f90: Add \\ to scan-tree-dump
Missed git add for the hot fix before committing
r13-982-gff35a75473d28205e52ecbcf9e6b5107b8b5ab90
gcc/testsuite/
* gfortran.dg/gomp/scope-6.f90: Fix dg-final scan-tree-dump.
Tobias Burnus [Fri, 3 Jun 2022 13:52:22 +0000 (15:52 +0200)]
OpenMP/Fortran: Add support for firstprivate and allocate clauses on scope construct
Fortran commit to C/C++/backend commit
r13-862-gf38b20d68fade5a922b9f68c4c3841e653d1b83c
gcc/fortran/ChangeLog:
* openmp.cc (OMP_SCOPE_CLAUSES): Add firstprivate and allocate.
libgomp/ChangeLog:
* libgomp.texi (OpenMP 5.2): Mark scope w/ firstprivate/allocate as Y.
* testsuite/libgomp.fortran/scope-2.f90: New test.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/scope-5.f90: New test.
* gfortran.dg/gomp/scope-6.f90: New test.
Patrick Palka [Fri, 3 Jun 2022 13:29:12 +0000 (09:29 -0400)]
c++: don't substitute TEMPLATE_PARM_CONSTRAINTS [PR100374]
This patch makes us avoid substituting into the TEMPLATE_PARM_CONSTRAINTS
of each template parameter except as necessary for declaration matching,
like we already do for the other constituent constraints of a declaration.
This patch also improves the CA104 implementation of explicit
specialization matching of a constrained function template inside a
class template, by considering the function's combined constraints
instead of just its trailing constraints. This allows us to correctly
handle the first three explicit specializations in concepts-spec2.C
below, but because we compare the constraints as a whole, it means we
incorrectly accept the fourth explicit specialization which writes #3's
constraints in a different way. For complete correctness here,
determine_specialization should use tsubst_each_template_parm_constraints
and template_parameter_heads_equivalent_p.
PR c++/100374
gcc/cp/ChangeLog:
* pt.cc (determine_specialization): Compare overall constraints
not just the trailing constraints.
(tsubst_each_template_parm_constraints): Define.
(tsubst_friend_function): Use it.
(tsubst_friend_class): Use it.
(tsubst_template_parm): Don't substitute TEMPLATE_PARM_CONSTRAINTS.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-spec2.C: New test.
* g++.dg/cpp2a/concepts-template-parm11.C: New test.
Patrick Palka [Fri, 3 Jun 2022 13:08:41 +0000 (09:08 -0400)]
c++: find_template_parameters and PARM_DECLs [PR105797]
As explained in r11-4959-gde6f64f9556ae3, the atom cache assumes two
equivalent expressions (according to cp_tree_equal) must use the same
template parameters (according to find_template_parameters). This
assumption turned out to not hold for TARGET_EXPR, which was addressed
by that commit.
But this assumption apparently doesn't hold for PARM_DECL either:
find_template_parameters walks its DECL_CONTEXT but cp_tree_equal by
default doesn't consider DECL_CONTEXT unless comparing_specializations
is set. Thus in the first testcase below, the atomic constraints of #1
and #2 are equivalent according to cp_tree_equal, but according to
find_template_parameters the former uses T and the latter uses both T
and U (surprisingly).
We could fix this assumption violation by setting comparing_specializations
in the atom_hasher, which would make cp_tree_equal return false for the
two atoms, but that seems overly pessimistic here. Ideally the atoms
should continue being considered equivalent and we instead fix
find_template_paremeters to return just T for #2's atom.
To that end this patch makes for_each_template_parm_r stop walking the
DECL_CONTEXT of a PARM_DECL. This should be safe to do because
tsubst_copy / tsubst_decl only substitutes the TREE_TYPE of a PARM_DECL
and doesn't bother substituting the DECL_CONTEXT, thus the only relevant
template parameters are those used in its type. any_template_parm_r is
currently responsible for walking its TREE_TYPE, but I suppose it now makes
sense for for_each_template_parm_r to do so instead.
In passing this patch also makes for_each_template_parm_r stop walking
the DECL_CONTEXT of a VAR_/FUNCTION_DECL since doing so after walking
DECL_TI_ARGS is redundant, I think.
I experimented with not walking DECL_CONTEXT for CONST_DECL, but the
second testcase below demonstrates it's necessary to walk it.
PR c++/105797
gcc/cp/ChangeLog:
* pt.cc (for_each_template_parm_r) <case FUNCTION_DECL, VAR_DECL>:
Don't walk DECL_CONTEXT.
<case PARM_DECL>: Likewise. Walk TREE_TYPE.
<case CONST_DECL>: Simplify.
(any_template_parm_r) <case PARM_DECL>: Don't walk TREE_TYPE.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-decltype4.C: New test.
* g++.dg/cpp2a/concepts-memfun3.C: New test.
Jakub Jelinek [Fri, 3 Jun 2022 09:41:21 +0000 (11:41 +0200)]
match.pd: Optimize __builtin_mul_overflow_p (x, cst, (stype)0) [PR105777]
The following patch is an incremental change to the PR30314 enhancement,
this one handles signed types.
For signed types (but still, the same for 1st and result element type
and non-zero constant that fits into that type), we actually need to
watch for overflow in direction to positive and negative infinity
and it also depends on whether the cst operand is positive or negative.
For __builtin_mul_overflow_p (x, cst, (stype) 0):
For cst > 0, we can simplify it to:
x > INT_MAX / cst || x < INT_MIN / cst
aka:
x + (unsigned) (INT_MIN / cst) > (unsigned) (INT_MAX / cst) - (unsigned) (INT_MIN / cst)
and for cst < 0 to:
x < INT_MAX / cst || x > INT_MIN / cst
aka:
x + (unsigned) (INT_MAX / cst) > (unsigned) (INT_MIN / cst) - (unsigned) (INT_MAX / cst)
Additionally, I've added executable testcases, so we don't just check for
the optimization to be performed, but also that it is correct (done that
even for the other PR's testcase).
2022-06-03 Jakub Jelinek <jakub@redhat.com>
PR middle-end/30314
PR middle-end/105777
* match.pd (__builtin_mul_overflow_p (x, cst, (stype) 0) ->
x > stype_max / cst || x < stype_min / cst): New simplification.
* gcc.dg/tree-ssa/pr30314.c: Add noipa attribute to all functions.
* gcc.dg/tree-ssa/pr105777.c: New test.
* gcc.c-torture/execute/pr30314.c: New test.
* gcc.c-torture/execute/pr105777.c: New test.
Aldy Hernandez [Thu, 2 Jun 2022 17:52:41 +0000 (19:52 +0200)]
Misc range temporary fixes.
This fixes a couples places that were using int_range_max, but needed
a generic temporary. Found while merging the frange work.
Also, copying between range temporaries is actually useful :).
Tested on x86-64 Linux.
gcc/ChangeLog:
* gimple-range-cache.cc (ranger_cache::range_from_dom): Use
Value_Range.
* gimple-range.cc (gimple_ranger::register_inferred_ranges): Same.
* value-range.h (Value_Range::Value_Range): Implement copy
constructor for Value_Range.
Aldy Hernandez [Wed, 1 Jun 2022 15:41:10 +0000 (17:41 +0200)]
Remove unneeded vrange_traits.
The traits struct is no longer needed.
Tested on x86-64 Linux.
gcc/ChangeLog:
* value-range.h (struct vrange_traits): Remove.
(is_a): Rewrite without vrange_traits.
(as_a): Same.
Aldy Hernandez [Wed, 1 Jun 2022 14:58:36 +0000 (16:58 +0200)]
Flesh out unsupported_range.
It's cleaner to have the unsupported_range fully fleshed out, instead
of trapping on every operation. It can also serve as the basis for
the default vrange methods that frange and prange will inherit.
This patch implements most methods, including union and intersect, to
handle an UNDEFINED and a VARYING range.
Since this can serve as the basis for other classes, I have moved
everything into the vrange class, making the unsupported_range
trivial.
Note that vrange is still an abstract class, as I have purposely left
the dump() method abstract.
Also, I have made the unsupported range in the temporary class
(Value_Range) a method field, instead of a static member. This way
the temporary can set UNDEFINED and VARYING as needed.
Tested on x86-64 Linux.
gcc/ChangeLog:
* value-range.cc (vrange::contains_p): Implement.
(vrange::type): Return void.
(vrange::supports_type_p): Implement.
(irange::fits_p): Same.
(vrange::set_undefined): Same.
(irange::set_nonnegative): Same.
(vrange::set_varying): Same.
(vrange::union_): Same.
(unsupported_range::set): Move to vrange.
(unsupported_range::type): Move to vrange.
(vrange::intersect): Implement for varying and undefined.
(vrange::zero_p): Implement.
(unsupported_range::supports_type_p): Move to vrange.
(vrange::nonzero_p): Implement.
(unsupported_range::set_undefined): Move to vrange.
(unsupported_range::set_varying): Same.
(unsupported_range::dump): Same.
(unsupported_range::union_): Same. Implement for varying and
undefined.
(unsupported_range::intersect): Move to vrange.
(unsupported_range::zero_p): Same.
(unsupported_range::nonzero_p): Same.
(unsupported_range::set_nonzero): Same.
(unsupported_range::set_zero): Same.
(unsupported_range::set_nonnegative): Same.
(unsupported_range::fits_p): Same.
* value-range.h (class vrange): Remove abstract markers for most
methods.
(class unsupported_range): Remove most methods as they will now be
inherited from vrange.
Aldy Hernandez [Tue, 31 May 2022 12:04:51 +0000 (14:04 +0200)]
Implement vrange::supports_type_p.
[I have conservatively assumed that both the loop-ch and loop-unswitch
passes, which also use the ranger, only support integers and pointers.
If the goal is to handle other types as well, irange::supports_p()
should be Value_Range::supports_type_p(), and any uses of
int_range_max should be converted to Value_Range. I can help in the
conversion if you'd like.]
As discussed, this patch disambiguates the use of supports_type_p
throughout, as what ranger supports is a totally different question
than what a given range variant (irange, frange, etc) supports.
Unfortunately we need both a static method and a virtual method, and
they can't be named the same. The uses are documented in the vrange
class:
+// To query what types ranger and the entire ecosystem can support,
+// use Value_Range::supports_type_p(tree type). This is a static
+// method available independently of any vrange object.
+//
+// To query what a given vrange variant can support, use:
+// irange::supports_p ()
+// frange::supports_p ()
+// etc
+//
+// To query what a range object can support, use:
+// void foo (vrange &v, irange &i, frange &f)
+// {
+// if (v.supports_type_p (type)) ...
+// if (i.supports_type_p (type)) ...
+// if (f.supports_type_p (type)) ...
+// }
The value_range_equiv::supports_p() method can be use to determine
what legacy VRP supports, as irange::supports_p() will no longer be
applicable in the evrp analyzer code base once irange and prange are
split.
Tested on x86-64 Linux.
gcc/ChangeLog:
* gimple-range-edge.cc (gimple_outgoing_range_stmt_p): Adjust for
an object level supports_type_p for irange and a static
Value_Range::supports_type_p.
* gimple-range-fold.cc (fold_using_range::range_of_range_op): Same.
(fold_using_range::range_of_address): Same.
(fold_using_range::range_of_builtin_call): Same.
* gimple-range-fold.h (gimple_range_type): Same.
(gimple_range_ssa_p): Same.
* gimple-range-path.cc (path_range_query::internal_range_of_expr):
Same.
(path_range_query::range_of_stmt): Same.
(path_range_query::add_to_imports): Same.
* gimple-range.cc (gimple_ranger::range_on_edge): Same.
(gimple_ranger::export_global_ranges): Same.
* gimple-ssa-evrp-analyze.cc
(evrp_range_analyzer::record_ranges_from_phis): Same.
* range-op.cc (range_operator::wi_fold): Same.
(range_operator::fold_range): Same.
* tree-ssa-loop-ch.cc (entry_loop_condition_is_static): Same.
* tree-ssa-loop-unswitch.cc (struct unswitch_predicate): Same.
(evaluate_control_stmt_using_entry_checks): Same.
* tree-ssa-threadedge.cc
(hybrid_jt_simplifier::compute_ranges_from_state): Same.
* tree-vrp.cc (supported_types_p): Same.
* value-query.cc (range_query::value_of_expr): Same.
(range_query::value_on_edge): Same.
(range_query::value_of_stmt): Same.
(range_query::get_tree_range): Same.
(get_range_global): Same.
(global_range_query::range_of_expr): Same.
* value-range-equiv.h (class value_range_equiv): Same.
* value-range.cc (irange::supports_type_p): Same.
(unsupported_range::supports_type_p): Same.
* value-range.h (enum value_range_discriminator): Same.
(Value_Range::init): Same.
(Value_Range::supports_type_p): Same.
(irange::supports_type_p): Same.
(irange::supports_p): Same.
(vrange::supports_type_p): Same.
(vrange_allocator::alloc_vrange): Same.
Jan Beulich [Fri, 3 Jun 2022 08:22:25 +0000 (10:22 +0200)]
configure: arrange to use appropriate objcopy
Using the system objcopy is wrong when other configure checks have
probed a different set of binutils (I've noticed the problem on a system
where the base objcopy can't deal with compressed debug sections).
Arrange for the matching one to be picked up, first and foremost if an
"in tree" one is available, by mirroring respective logic already
present for nm.
gcc/
* Makefile.in (ORIGINAL_OBJCOPY_FOR_TARGET): New.
* configure.ac: Check for objcopy, producing
ORIGINAL_OBJCOPY_FOR_TARGET.
* configure: Update accordingly.
* exec-tool.in (ORIGINAL_OBJCOPY_FOR_TARGET): New.
Handle objcopy.
Jan Beulich [Fri, 3 Jun 2022 08:21:21 +0000 (10:21 +0200)]
x86: {,v}psadbw have commutative source operands
Like noticed for gas as well (binutils-gdb commit
c8cad9d389b7), the
"absolute difference" aspect of the insns makes their source operands
commutative.
gcc/
* config/i386/mmx.md (mmx_psadbw): Convert to expander.
(*mmx_psadbw): New. Mark as commutative.
* config/i386/sse.md (<sse2_avx2>_psadbw): Convert to expander.
(*<sse2_avx2>_psadbw): New. Mark as commutative.
Alexandre Oliva [Fri, 3 Jun 2022 06:59:03 +0000 (03:59 -0300)]
[PR105665] ivopts: check defs of names in base for undefs
The patch for PR 100810 tested for undefined SSA_NAMEs appearing
directly in the base expression of the potential IV candidate, but
that's not enough. The testcase for PR105665 shows an undefined
SSA_NAME has the same ill effect if it's referenced as an PHI_NODE arg
in the referenced SSA_NAME. The variant of that test shows it can be
further removed from the referenced SSA_NAME.
To avoid deep recursion, precompute maybe-undefined SSA_NAMEs: start
from known-undefined nonvirtual default defs, and propagate them to
any PHI nodes reached by a maybe-undefined arg, as long as there
aren't intervening non-PHI uses, that would imply the maybe-undefined
name must be defined at that point, otherwise it would invoke
undefined behavior. Also test for intervening non-PHI uses of DEFs in
the base expr.
The test for intervening uses implemented herein relies on dominance;
this could be further extended, regarding conditional uses in every
path leading to a point as an unconditional use dominating that point,
but I haven't implemented that.
for gcc/ChangeLog
PR tree-optimization/105665
PR tree-optimization/100810
* tree-ssa-loop-ivopts.cc
(ssa_name_maybe_undef_p, ssa_name_set_maybe_undef): New.
(ssa_name_any_use_dominates_bb_p, mark_ssa_maybe_undefs): New.
(find_ssa_undef): Check precomputed flag and intervening uses.
(tree_ssa_iv_optimize): Call mark_ssa_maybe_undefs.
for gcc/testsuite/ChangeLog
PR tree-optimization/105665
PR tree-optimization/100810
* gcc.dg/torture/pr105665.c: New.
Alexandre Oliva [Fri, 3 Jun 2022 06:59:01 +0000 (03:59 -0300)]
libcody: fix nonportable shell code in revision.stamp build rule
Two non-portable shell constructs have been long present in libcody's
build rule for revision.stamp: $() instead of ``, and += to append to
a shell variable. The former seems to work even when bash is
operating as /bin/sh, but += doesn't, and it ends up trying to run
revision+=M as a command name, and issuing an error as that command is
(hopefully) not found.
This patch replaces both constructs with more portable ones.
for libcody/ChangeLog
* Makefile.in (revision.stamp): Replace $() and += with more
portable shell constructs.
GCC Administrator [Fri, 3 Jun 2022 00:16:40 +0000 (00:16 +0000)]
Daily bump.
Marek Polacek [Thu, 2 Jun 2022 19:56:18 +0000 (15:56 -0400)]
c++: new-expression is potentially constant in C++20
... so adjust p_c_e accordingly.
gcc/cp/ChangeLog:
* constexpr.cc (potential_constant_expression_1): Treat
{,VEC_}NEW_EXPR and {,VEC_}DELETE_EXPRas potentially constant in C++20.
Marek Polacek [Wed, 1 Jun 2022 22:21:36 +0000 (18:21 -0400)]
c++: ICE with template NEW_EXPR [PR105803]
Here we ICE because value_dependent_expression_p gets a NEW_EXPR
whose operand is a type, and we go to the default case which just
calls v_d_e_p on each operand of the NEW_EXPR. Since one of them
is a type, we crash on the new assert in t_d_e_p.
t_d_e_p has code to handle {,VEC_}NEW_EXPR, which at this point
was already performed, so I think we can handle these two codes
specifically and skip the second operand, which is always going
to be a type.
PR c++/105803
gcc/cp/ChangeLog:
* pt.cc (value_dependent_expression_p): Handle {,VEC_}NEW_EXPR
in the switch.
gcc/testsuite/ChangeLog:
* g++.dg/template/new13.C: New test.
David Malcolm [Thu, 2 Jun 2022 19:40:22 +0000 (15:40 -0400)]
diagnostics: add SARIF output format
This patch adds support to gcc's diagnostic subsystem for emitting
diagnostics in SARIF, aka the Static Analysis Results Interchange Format:
https://sarifweb.azurewebsites.net/
by extending -fdiagnostics-format= to add two new options:
-fdiagnostics-format=sarif-stderr
and:
-fdiagnostics-format=sarif-file
The patch targets SARIF v2.1.0
This is a JSON-based format suited for capturing the results of static
analysis tools (like GCC's -fanalyzer), but it can also be used for plain
GCC warnings and errors.
SARIF supports per-event metadata in diagnostic paths such as
["acquire", "resource"] and ["release", "lock"] (specifically, the
threadFlowLocation "kinds" property: SARIF v2.1.0 section 3.38.8), so
the patch extends GCC"s diagnostic_event subclass with a "struct meaning"
with similar purpose. The patch implements this for -fanalyzer so that
the various state-machine-based warnings set these in the SARIF output.
The heart of the implementation is in the new file
diagnostic-format-sarif.cc. Much of the rest of the patch is interface
classes, isolating the diagnostic subsystem (which has no knowledge of
e.g. tree or langhook) from the "client" code in the compiler proper
cc1 etc).
The patch adds a langhook for specifying the SARIF v2.1.0
"artifact.sourceLanguage" property, based on the list in
SARIF v2.1.0 Appendix J.
The patch adds automated DejaGnu tests to our testsuite via new
scan-sarif-file and scan-sarif-file-not directives (although these
merely use regexps, rather than attempting to use a proper JSON parser).
I've tested the patch by hand using the validator at:
https://sarifweb.azurewebsites.net/Validation
and the react-based viewer at:
https://microsoft.github.io/sarif-web-component/
which successfully shows most of the information (although not paths,
and not CWE IDs), and I've fixed all validation errors I've seen (though
bugs no doubt remain).
I've also tested the generated SARIF using the VS Code extension linked
to from the SARIF website; I'm a novice with VS Code, but it seems to be
able to handle my generated SARIF files (e.g. showing the data in the
SARIF tab, and showing squiggly underlines under issues, and when I
click on them, it visualizes the events in the path inline within the
source window).
Has anyone written an Emacs mode for SARIF files? (pretty please)
gcc/ChangeLog:
* Makefile.in (OBJS): Add tree-diagnostic-client-data-hooks.o and
tree-logical-location.o.
(OBJS-libcommon): Add diagnostic-format-sarif.o; reorder.
(CFLAGS-tree-diagnostic-client-data-hooks.o): Add TARGET_NAME.
* common.opt (fdiagnostics-format=): Add sarif-stderr and sarif-file.
(sarif-stderr, sarif-file): New enum values.
* diagnostic-client-data-hooks.h: New file.
* diagnostic-format-sarif.cc: New file.
* diagnostic-path.h (enum diagnostic_event::verb): New enum.
(enum diagnostic_event::noun): New enum.
(enum diagnostic_event::property): New enum.
(struct diagnostic_event::meaning): New struct.
(diagnostic_event::get_logical_location): New vfunc.
(diagnostic_event::get_meaning): New vfunc.
(simple_diagnostic_event::get_logical_location): New vfunc impl.
(simple_diagnostic_event::get_meaning): New vfunc impl.
* diagnostic.cc: Include "diagnostic-client-data-hooks.h".
(diagnostic_initialize): Initialize m_client_data_hooks.
(diagnostic_finish): Clean up m_client_data_hooks.
(diagnostic_event::meaning::dump_to_pp): New.
(diagnostic_event::meaning::maybe_get_verb_str): New.
(diagnostic_event::meaning::maybe_get_noun_str): New.
(diagnostic_event::meaning::maybe_get_property_str): New.
(get_cwe_url): Make non-static.
(diagnostic_output_format_init): Handle
DIAGNOSTICS_OUTPUT_FORMAT_SARIF_STDERR and
DIAGNOSTICS_OUTPUT_FORMAT_SARIF_FILE.
* diagnostic.h (enum diagnostics_output_format): Add
DIAGNOSTICS_OUTPUT_FORMAT_SARIF_STDERR and
DIAGNOSTICS_OUTPUT_FORMAT_SARIF_FILE.
(class diagnostic_client_data_hooks): New forward decl.
(class logical_location): New forward decl.
(diagnostic_context::m_client_data_hooks): New field.
(diagnostic_output_format_init_sarif_stderr): New decl.
(diagnostic_output_format_init_sarif_file): New decl.
(get_cwe_url): New decl.
* doc/invoke.texi (-fdiagnostics-format=): Add sarif-stderr and
sarif-file.
* doc/sourcebuild.texi (Scan a particular file): Add
scan-sarif-file and scan-sarif-file-not.
* langhooks-def.h (lhd_get_sarif_source_language): New decl.
(LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): New macro.
(LANG_HOOKS_INITIALIZER): Add
LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE.
* langhooks.cc (lhd_get_sarif_source_language): New.
* langhooks.h (lang_hooks::get_sarif_source_language): New field.
* logical-location.h: New file.
* plugin.cc (struct for_each_plugin_closure): New.
(for_each_plugin_cb): New.
(for_each_plugin): New.
* plugin.h (for_each_plugin): New decl.
* tree-diagnostic-client-data-hooks.cc: New file.
* tree-diagnostic.cc: Include "diagnostic-client-data-hooks.h".
(tree_diagnostics_defaults): Populate m_client_data_hooks.
* tree-logical-location.cc: New file.
* tree-logical-location.h: New file.
gcc/ada/ChangeLog:
* gcc-interface/misc.cc (gnat_get_sarif_source_language): New.
(LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine.
gcc/analyzer/ChangeLog:
* checker-path.cc (checker_event::get_meaning): New.
(function_entry_event::get_meaning): New.
(state_change_event::get_desc): Add dump of meaning of the event
to the -fanalyzer-verbose-state-changes output.
(state_change_event::get_meaning): New.
(cfg_edge_event::get_meaning): New.
(call_event::get_meaning): New.
(return_event::get_meaning): New.
(start_consolidated_cfg_edges_event::get_meaning): New.
(warning_event::get_meaning): New.
* checker-path.h: Include "tree-logical-location.h".
(checker_event::checker_event): Construct m_logical_loc.
(checker_event::get_logical_location): New.
(checker_event::get_meaning): New decl.
(checker_event::m_logical_loc): New.
(function_entry_event::get_meaning): New decl.
(state_change_event::get_meaning): New decl.
(cfg_edge_event::get_meaning): New decl.
(call_event::get_meaning): New decl.
(return_event::get_meaning): New decl.
(start_consolidated_cfg_edges_event::get_meaning): New.
(warning_event::get_meaning): New decl.
* pending-diagnostic.h: Include "diagnostic-path.h".
(pending_diagnostic::get_meaning_for_state_change): New vfunc.
* sm-file.cc (file_diagnostic::get_meaning_for_state_change): New
vfunc impl.
* sm-malloc.cc (malloc_diagnostic::get_meaning_for_state_change):
Likewise.
* sm-sensitive.cc
(exposure_through_output_file::get_meaning_for_state_change):
Likewise.
* sm-taint.cc (taint_diagnostic::get_meaning_for_state_change):
Likewise.
* varargs.cc
(va_list_sm_diagnostic::get_meaning_for_state_change): Likewise.
gcc/c/ChangeLog:
* c-lang.cc (LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine.
(c_get_sarif_source_language): New.
* c-tree.h (c_get_sarif_source_language): New decl.
gcc/cp/ChangeLog:
* cp-lang.cc (LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine.
(cp_get_sarif_source_language): New.
gcc/d/ChangeLog:
* d-lang.cc (d_get_sarif_source_language): New.
(LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine.
gcc/fortran/ChangeLog:
* f95-lang.cc (gfc_get_sarif_source_language): New.
(LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine.
gcc/go/ChangeLog:
* go-lang.cc (go_get_sarif_source_language): New.
(LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine.
gcc/objc/ChangeLog:
* objc-act.h (objc_get_sarif_source_language): New decl.
* objc-lang.cc (LANG_HOOKS_GET_SARIF_SOURCE_LANGUAGE): Redefine.
(objc_get_sarif_source_language): New.
gcc/testsuite/ChangeLog:
* c-c++-common/diagnostic-format-sarif-file-1.c: New test.
* c-c++-common/diagnostic-format-sarif-file-2.c: New test.
* c-c++-common/diagnostic-format-sarif-file-3.c: New test.
* c-c++-common/diagnostic-format-sarif-file-4.c: New test.
* gcc.dg/analyzer/file-meaning-1.c: New test.
* gcc.dg/analyzer/malloc-meaning-1.c: New test.
* gcc.dg/analyzer/malloc-sarif-1.c: New test.
* gcc.dg/plugin/analyzer_gil_plugin.c
(gil_diagnostic::get_meaning_for_state_change): New vfunc impl.
* gcc.dg/plugin/diagnostic-test-paths-5.c: New test.
* gcc.dg/plugin/plugin.exp (plugin_test_list): Add
diagnostic-test-paths-5.c to tests for
diagnostic_plugin_test_paths.c.
* lib/gcc-dg.exp: Load scansarif.exp.
* lib/scansarif.exp: New test.
libatomic/ChangeLog:
* testsuite/lib/libatomic.exp: Add load_gcc_lib of scansarif.exp.
libgomp/ChangeLog:
* testsuite/lib/libgomp.exp: Add load_gcc_lib of scansarif.exp.
libitm/ChangeLog:
* testsuite/lib/libitm.exp: Add load_gcc_lib of scansarif.exp.
libphobos/ChangeLog:
* testsuite/lib/libphobos-dg.exp: Add load_gcc_lib of scansarif.exp.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Thu, 2 Jun 2022 19:38:38 +0000 (15:38 -0400)]
Add -fdiagnostics-format={json-stderr|json-file}
This commit adds -fdiagnostics-format=json-file, writing to
DUMP_BASE_NAME.gcc.json, and adds -fdiagnostics-format=json-stderr,
a synonym for the existing -fdiagnostics-format=json.
gcc/ChangeLog:
* common.opt (fdiagnostics-format=): Add json-stderr and json-file
to description.
(DIAGNOSTICS_OUTPUT_FORMAT_JSON): Rename to...
(DIAGNOSTICS_OUTPUT_FORMAT_JSON_STDERR): ...this.
(diagnostics_output_format): Add json-stderr and json-file.
* diagnostic-format-json.cc (json_flush_to_file): New.
(json_final_cb): Convert to...
(json_flush_to_file): ...this, ...
(json_stderr_final_cb): ...this, and...
(json_file_final_cb): ...this.
(diagnostic_output_format_init): Move to diagnostic.cc.
(json_output_base_file_name): New.
(diagnostic_output_format_init_json): New.
(diagnostic_output_format_init_json_stderr): New.
(diagnostic_output_format_init_json_file): New.
* diagnostic.cc (diagnostic_output_format_init): Move here from
diagnostic-format-json.cc; update for changes to enum.
* diagnostic.h (enum diagnostics_output_format): Rename
DIAGNOSTICS_OUTPUT_FORMAT_JSON to
DIAGNOSTICS_OUTPUT_FORMAT_JSON_STDERR, and add
DIAGNOSTICS_OUTPUT_FORMAT_JSON_FILE.
(diagnostic_output_format_init): Add base_file_name param.
(diagnostic_output_format_init_json_stderr): New decl.
(diagnostic_output_format_init_json_file): New dec.
* doc/invoke.texi (-fdiagnostics-format=): Add "json-stderr" and
"json-file". Rewrite so that the existing "json" is a synonym of
"json-stderr".
* gcc.cc (driver_handle_option): Pass dump_base_name to
diagnostic_output_format_init.
* opts.cc (common_handle_option): Likewise.
gcc/testsuite/ChangeLog:
* c-c++-common/diagnostic-format-json-file-1.c: New test.
* c-c++-common/diagnostic-format-json-stderr-1.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Thu, 2 Jun 2022 19:36:27 +0000 (15:36 -0400)]
json: fix escaping of '\'
gcc/ChangeLog:
* json.cc (string::print): Fix escaping of '\'.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Philipp Tomsich [Mon, 29 Jun 2020 13:15:10 +0000 (15:15 +0200)]
RISC-V: bitmanip: improve constant-loading for (1ULL << 31) in DImode
The SINGLE_BIT_MASK_OPERAND() is overly restrictive, triggering for
bits above 31 only (to side-step any issues with the negative SImode
value 0x80000000/(-1ull << 31)/(1 << 31)). This moves the special
handling of this SImode value (i.e. the check for (-1ull << 31) to
riscv.cc and relaxes the SINGLE_BIT_MASK_OPERAND() test.
With this, the code-generation for loading (1ULL << 31) from:
li a0,1
slli a0,a0,31
to:
bseti a0,zero,31
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_build_integer_1): Rewrite value as
(-1 << 31) for the single-bit case, when operating on (1 << 31)
in SImode.
* config/riscv/riscv.h (SINGLE_BIT_MASK_OPERAND): Allow for
any single-bit value, moving the special case for (1 << 31) to
riscv_build_integer_1 (in riscv.c).
Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
Jason Merrill [Wed, 1 Jun 2022 21:30:25 +0000 (17:30 -0400)]
c++: more constexpr empty base [PR105795]
Following on from the previous patch, for trunk let's consistently set
ctx->ctor to NULL_TREE for empty subobjects.
PR c++/105795
gcc/cp/ChangeLog:
* constexpr.cc (init_subob_ctx): Clear ctx->ctor for empty subob.
(cxx_eval_store_expression): Likewise.
(cxx_eval_bare_aggregate): Handle null ctx->ctor.
Jason Merrill [Wed, 1 Jun 2022 20:13:48 +0000 (16:13 -0400)]
c++: constexpr empty aggr [PR105795]
In this testcase, leaving ctx->ctor pointing to the enclosing object meant
that evaluating the initializer for the subobject clobbered previous
initializers for the enclosing object. So do update ctx->ctor, just don't
add it to the enclosing object ctor.
PR c++/105795
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_bare_aggregate): Always call
init_subob_ctx.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/constexpr-aggr-base1.C: New test.
Roger Sayle [Thu, 2 Jun 2022 17:46:37 +0000 (18:46 +0100)]
PR target/105791: Add V1TI to V_128_256 for xop_pcmov_v1ti on x86_64.
This patch resolves PR target/105791 which is a regression that was
accidentally introduced for my workaround to PR tree-optimization/10566.
(a deeper problem in GCC's vectorizer creating VEC_COND_EXPR when it
shouldn't). The latest issues is that by providing a vcond_mask_v1tiv1ti
pattern in sse.md, the backend now calls ix86_expand_sse_movcc with
V1TImode operands, which has a special case for TARGET_XOP to generate
a vpcmov instruction. Unfortunately, there wasn't previously a V1TImode
variant, xop_pcmov_v1ti, so we'd ICE.
This is easily fixed by adding V1TImode (and V2TImode) to V_128_256
which is only used for defining XOP's vpcmov instruction. This in turn
requires V1TI (and V2TI) to be supported by <avxsizesuffix> (though
the use if <avxsizesuffix> in the names xop_pcmov_<mode><avxsizesuffix>
seems unnecessary; the mode makes the name unique).
2022-06-02 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR target/105791
* config/i386/sse.md (V_128_256):Add V1TI and V2TI.
(define_mode_attr avxsizesuffix): Add support for V1TI and V2TI.
gcc/testsuite/ChangeLog
PR target/105791
* gcc.target/i386/pr105791.c: New test case.
Jakub Jelinek [Thu, 2 Jun 2022 09:14:09 +0000 (11:14 +0200)]
testsuite: Also test swapped arguments of __builtin_mul_overflow_p [PR30314]
To test the commutativity of __builtin_mul_overflow* arguments in the
optimization, I've added 2 further tests.
2022-06-02 Jakub Jelinek <jakub@redhat.com>
PR middle-end/30314
* gcc.dg/tree-ssa/pr30314.c: Add tests with swapped arguments.