Jason Merrill [Wed, 22 Jun 2022 22:19:11 +0000 (18:19 -0400)]
c++: dependence of baselink [PR105964]
helper<token>::c isn't dependent just because we haven't deduced its return
type yet. type_dependent_expression_p already knows how to deal with that
for bare FUNCTION_DECL, but needs to learn to look through a BASELINK.
PR c++/105964
gcc/cp/ChangeLog:
* pt.cc (type_dependent_expression_p): Look through BASELINK.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/nontype-auto21.C: New test.
Jason Merrill [Wed, 22 Jun 2022 18:57:21 +0000 (14:57 -0400)]
c++: class scope function lookup [PR105908]
In r12-1273 for PR91706, I removed the code in get_class_binding that
stripped BASELINK. This testcase demonstrates that we still need to strip
it in outer_binding before putting the overload set in IDENTIFIER_BINDING,
for compatibility with bindings added directly for declarations.
PR c++/105908
gcc/cp/ChangeLog:
* name-lookup.cc (outer_binding): Strip BASELINK.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/trailing16.C: New test.
Richard Sandiford [Wed, 15 Jun 2022 10:12:51 +0000 (11:12 +0100)]
aarch64: Revert bogus fix for PR105254
In
f2ebf2d98efe0ac2314b58cf474f44cb8ebd5244 I'd forced the
chosen unroll factor to be a factor of the VF, in order to
work around an exact_div ICE in PR105254. This was completely
bogus -- clearly I didn't look in enough detail at why we ended
up with an unrolled VF that wasn't a multiple of the UF.
Kewen has since fixed the bug properly for PR105940, so this
patch reverts my earlier attempt. Sorry for the stupidity.
gcc/
PR tree-optimization/105254
PR tree-optimization/105940
Revert:
* config/aarch64/aarch64.cc
(aarch64_vector_costs::determine_suggested_unroll_factor): Take a
loop_vec_info as argument. Restrict the unroll factor to values
that divide the VF.
(aarch64_vector_costs::finish_cost): Update call accordingly.
gcc/testsuite/
* gcc.target/aarch64/sve/cost_model_14.c: New test.
(cherry picked from commit
2636660b6f35423e0cfbf53bfad5c5fed6ae6471)
Kewen Lin [Tue, 14 Jun 2022 05:57:01 +0000 (00:57 -0500)]
vect: Move suggested_unroll_factor applying [PR105940]
As PR105940 shown, when rs6000 port tries to assign
m_suggested_unroll_factor by 4 or so, there will be ICE on:
exact_div (LOOP_VINFO_VECT_FACTOR (loop_vinfo),
loop_vinfo->suggested_unroll_factor);
In function vect_analyze_loop_2, the current place of
suggested_unroll_factor applying can't guarantee it's
applied for all cases. As the case shows, vectorizer
could retry with SLP forced off, the vf is reset by
saved_vectorization_factor which isn't applied with
suggested_unroll_factor before. It means it can end
up with one vf which neglects suggested_unroll_factor.
I think it's off design, we should move the applying
of suggested_unroll_factor after start_over.
PR tree-optimization/105940
gcc/ChangeLog:
* tree-vect-loop.cc (vect_analyze_loop_2): Move the place of
applying suggested_unroll_factor after start_over.
(cherry picked from commit
f907cf4c07cf51863dadbe90894e2ae3382bada5)
GCC Administrator [Thu, 23 Jun 2022 00:19:39 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Wed, 22 Jun 2022 00:19:10 +0000 (00:19 +0000)]
Daily bump.
H.J. Lu [Tue, 14 Jun 2022 15:20:16 +0000 (08:20 -0700)]
i386: Disallow sibcall for calling ifunc functions with PIC register
Disallow siball when calling ifunc functions with PIC register so that
PIC register can be restored.
gcc/
PR target/105960
* config/i386/i386.cc (ix86_function_ok_for_sibcall): Return
false if PIC register is used when calling ifunc functions.
gcc/testsuite/
PR target/105960
* gcc.target/i386/pr105960.c: New test.
(cherry picked from commit
fe9765c0b97e6b4ce2cd226631d329fc05ba2aa5)
GCC Administrator [Tue, 21 Jun 2022 00:19:12 +0000 (00:19 +0000)]
Daily bump.
Uros Bizjak [Fri, 17 Jun 2022 15:19:44 +0000 (17:19 +0200)]
alpha: Introduce target specific store_data_bypass_p function [PR105209]
This patch introduces alpha-specific version of store_data_bypass_p that
ignores TRAP_IF that would result in assertion failure (and internal
compiler error) in the generic store_data_bypass_p function.
While at it, also remove ev4_ist_c reservation, store_data_bypass_p
can handle the patterns with multiple sets since some time ago.
2022-06-17 Uroš Bizjak <ubizjak@gmail.com>
gcc/ChangeLog:
PR target/105209
* config/alpha/alpha-protos.h (alpha_store_data_bypass_p): New.
* config/alpha/alpha.cc (alpha_store_data_bypass_p): New function.
(alpha_store_data_bypass_p_1): Ditto.
* config/alpha/ev4.md: Use alpha_store_data_bypass_p instead
of generic store_data_bypass_p.
(ev4_ist_c): Remove insn reservation.
gcc/testsuite/ChangeLog:
PR target/105209
* gcc.target/alpha/pr105209.c: New test.
(cherry picked from commit
cc378e655740e93743e7f43e14faaff707aef6c1)
Uros Bizjak [Fri, 17 Jun 2022 15:01:31 +0000 (17:01 +0200)]
i386: Fix assert in ix86_function_arg [PR105970]
The mode of pointer argument should equal ptr_mode, not Pmode.
2022-06-17 Uroš Bizjak <ubizjak@gmail.com>
gcc/ChangeLog:
PR target/105970
* config/i386/i386.cc (ix86_function_arg): Assert that
the mode of pointer argumet is equal to ptr_mode, not Pmode.
gcc/testsuite/ChangeLog:
PR target/105970
* gcc.target/i386/pr105970.c: New test.
(cherry picked from commit
1f8278bfcfc7f7157bf2b405471e67dd5097636b)
GCC Administrator [Mon, 20 Jun 2022 00:18:49 +0000 (00:18 +0000)]
Daily bump.
Jakub Jelinek [Sat, 18 Jun 2022 09:07:13 +0000 (11:07 +0200)]
varasm: Fix up ICE in narrowing_initializer_constant_valid_p [PR105998]
The following testcase ICEs because there is NON_LVALUE_EXPR (location
wrapper) around a VAR_DECL and has TYPE_MODE V2SImode and
SCALAR_INT_TYPE_MODE on that ICEs. Or for -m32 -march=i386 TYPE_MODE
is DImode, but SCALAR_INT_TYPE_MODE still uses the raw V2SImode and ICEs
too.
2022-06-18 Jakub Jelinek <jakub@redhat.com>
PR middle-end/105998
* varasm.cc (narrowing_initializer_constant_valid_p): Check
SCALAR_INT_MODE_P instead of INTEGRAL_MODE_P, also break on
! INTEGRAL_TYPE_P and do the same check also on op{0,1}'s type.
* c-c++-common/pr105998.c: New test.
(cherry picked from commit
ef662120177d39af5f88ffc622d90bb6ae0ca1d3)
Jakub Jelinek [Fri, 17 Jun 2022 15:40:49 +0000 (17:40 +0200)]
c++: Use fold_non_dependent_expr rather than maybe_constant_value in __builtin_shufflevector handling [PR106001]
In this case the STATIC_CAST_EXPR expressions in the call aren't
type nor value dependent, but maybe_constant_value still ICEs on those
when processing_template_decl. Calling fold_non_dependent_expr on it
instead fixes the ICE and folds them to INTEGER_CSTs.
2022-06-17 Jakub Jelinek <jakub@redhat.com>
PR c++/106001
* typeck.cc (build_x_shufflevector): Use fold_non_dependent_expr
instead of maybe_constant_value.
* g++.dg/ext/builtin-shufflevector-4.C: New test.
(cherry picked from commit
a284fadcce8ef443cc3cc047a8017745efb51758)
Jakub Jelinek [Thu, 16 Jun 2022 08:58:58 +0000 (10:58 +0200)]
expand: Fix up IFN_ATOMIC_{BIT*,*CMP_0} expansion [PR105951]
Both IFN_ATOMIC_BIT_TEST_AND_* and IFN_ATOMIC_*_FETCH_CMP_0 ifns
are matched if their corresponding optab is implemented for the particular
mode. The fact that those optabs are implemented doesn't guarantee
they will succeed though, they can just FAIL in their expansion.
The expansion in that case uses expand_atomic_fetch_op as fallback, but
as has been reported and and can be reproduced on the testcases,
even those can fail and we didn't have any fallback after that.
For IFN_ATOMIC_BIT_TEST_AND_* we actually have such calls. One is
done whenever we lost lhs of the ifn at some point in between matching
it in tree-ssa-ccp.cc and expansion. The following patch for that case
just falls through and expands as if there was a lhs, creates a temporary
for it. For the other expand_atomic_fetch_op call in the same expander
and for the only expand_atomic_fetch_op call in the other, this falls
back the hard way, by constructing a CALL_EXPR to the call from which
the ifn has been matched and expanding that. Either it is lucky and manages
to expand inline, or it emits a libatomic API call.
So that we don't have to rediscover which builtin function to call in the
fallback, we record at tree-ssa-ccp.cc time gimple_call_fn (call) in
an extra argument to the ifn.
2022-06-16 Jakub Jelinek <jakub@redhat.com>
PR middle-end/105951
* tree-ssa-ccp.cc (optimize_atomic_bit_test_and,
optimize_atomic_op_fetch_cmp_0): Remember gimple_call_fn (call)
as last argument to the internal functions.
* builtins.cc (expand_ifn_atomic_bit_test_and): Adjust for the
extra call argument to ifns. If expand_atomic_fetch_op fails for the
lhs == NULL_TREE case, fall through into the optab code with
gen_reg_rtx (mode) as target. If second expand_atomic_fetch_op
fails, construct a CALL_EXPR and expand that.
(expand_ifn_atomic_op_fetch_cmp_0): Adjust for the extra call argument
to ifns. If expand_atomic_fetch_op fails, construct a CALL_EXPR and
expand that.
* gcc.target/i386/pr105951-1.c: New test.
* gcc.target/i386/pr105951-2.c: New test.
(cherry picked from commit
6a27c430468cb85454b19cef881a1422580657ff)
Jan Hubicka [Tue, 14 Jun 2022 12:05:53 +0000 (14:05 +0200)]
Fix ipa-cp wrt volatile loads
Check for volatile flag to ipa_load_from_parm_agg.
gcc/ChangeLog:
2022-06-10 Jan Hubicka <hubicka@ucw.cz>
PR ipa/105739
* ipa-prop.cc (ipa_load_from_parm_agg): Punt on volatile loads.
gcc/testsuite/ChangeLog:
2022-06-10 Jan Hubicka <hubicka@ucw.cz>
* gcc.dg/ipa/pr105739.c: New test.
(cherry picked from commit
8f6c317b3a16350698f3c9e0accb43a9b4acb4ae)
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.
(cherry picked from commit
4c334e0e4ff05d3a7ca9ebb832428c446cd0ae8d)
GCC Administrator [Sun, 19 Jun 2022 00:18:54 +0000 (00:18 +0000)]
Daily bump.
GCC Administrator [Sat, 18 Jun 2022 00:18:44 +0000 (00:18 +0000)]
Daily bump.
GCC Administrator [Fri, 17 Jun 2022 12:17:57 +0000 (12:17 +0000)]
Daily bump.
Richard Earnshaw [Wed, 15 Jun 2022 15:07:20 +0000 (16:07 +0100)]
arm: big-endian issue in gen_cpymem_ldrd_strd [PR105981]
The code in gen_cpymem_ldrd_strd has been incorrect for big-endian
since r230663. The problem is that we use gen_lowpart, etc. to split
the 64-bit quantity, but fail to account for the fact that these
routines are really dealing with 64-bit /values/ and in big-endian the
ordering of the sub-registers changes.
To fix this, I've renamed the conceptually misnamed low_reg and hi_reg
as first_reg and second_reg, and then used different logic for
big-endian targets to initialize these values. This makes the logic
clearer than trying to think about high bits and low bits.
gcc/ChangeLog:
PR target/105981
* config/arm/arm.cc (gen_cpymem_ldrd_strd): Rename low_reg and hi_reg
to first_reg and second_reg respectively. Initialize them correctly
when generating big-endian code.
(cherry picked from commit
8aaa948059a8b5f0a62ad010d0aa6346b7ac9cd3)
GCC Administrator [Thu, 16 Jun 2022 00:19:13 +0000 (00:19 +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.
(cherry picked from commit
add1adaa17a294ea25918ffb4fdd40f115362632)
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>
(cherry picked from commit
6725f186cb70d48338f69456864bf469a12ee5be)
Iain Sandoe [Sun, 29 May 2022 15:14:32 +0000 (16:14 +0100)]
Darwin: Fix empty g++ command lines [PR105599].
An empty g++ command line should produce a diagnostic that there are no
inputs. The PR is that currently Darwin produces a dignostic about missing
link items instead - this is because (errnoeously), for this driver, we are
creating a link job for empty command lines.
The problem occurs in four stages:
The g++ driver appends -shared-libgcc to the command line.
The Darwin driver_init code in the backend does not see this (it sees an
empty command line).
When the back end driver code driver sees an empty command line, it does not
add any supplementary flags (e.g. asm-macosx-version-min) - precisely to
avoid anything being claimed as an input_file and therefore triggering a link
line.
Since we do not have a value for asm-macosx-version-min when processing the
driver specs, we unconditionally inject 'multiply_defined suppress' which is
used with shared libgcc (but only intended on very old Darwin). This then
causes the generation of a link job.
The solution, for the present, is to move version-specific link params to the
LINK_SPEC so that they are only processed when a link job has already been
decided.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
PR target/105599
gcc/ChangeLog:
* config/darwin.h: Move versions-specific handling of multiply_defined
from SUBTARGET_DRIVER_SELF_SPECS to LINK_SPEC.
(cherry picked from commit
794737976b9a6418eab817f143bb4eb2d0c834d2)
Iain Buclaw [Wed, 15 Jun 2022 11:20:15 +0000 (13:20 +0200)]
d: Set TYPE_ARTIFICIAL on internal TypeInfo types
Prevents them from triggering warnings when compiling with `-Wpadded'.
gcc/d/ChangeLog:
* typeinfo.cc (make_internal_typeinfo): Set TYPE_ARTIFICIAL.
gcc/testsuite/ChangeLog:
* gdc.dg/Wpadded.d: New test.
(cherry picked from commit
57b2adae536a6399ed7d2c881b1bc0d4b88e936a)
liuhongt [Tue, 14 Jun 2022 08:27:04 +0000 (16:27 +0800)]
Fix ICE in extract_insn, at recog.cc:2791
(In reply to Uroš Bizjak from comment #1)
> Instruction does not accept memory operand for operand 3:
>
> (define_insn_and_split
> "*<sse4_1>_blendv<ssefltmodesuffix><avxsizesuffix>_ltint"
> [(set (match_operand:<ssebytemode> 0 "register_operand" "=Yr,*x,x")
> (unspec:<ssebytemode>
> [(match_operand:<ssebytemode> 1 "register_operand" "0,0,x")
> (match_operand:<ssebytemode> 2 "vector_operand" "YrBm,*xBm,xm")
> (subreg:<ssebytemode>
> (lt:VI48_AVX
> (match_operand:VI48_AVX 3 "register_operand" "Yz,Yz,x")
> (match_operand:VI48_AVX 4 "const0_operand")) 0)]
> UNSPEC_BLENDV))]
>
> The problematic insn is:
>
> (define_insn_and_split "*avx_cmp<mode>3_ltint_not"
> [(set (match_operand:VI48_AVX 0 "register_operand")
> (vec_merge:VI48_AVX
> (match_operand:VI48_AVX 1 "vector_operand")
> (match_operand:VI48_AVX 2 "vector_operand")
> (unspec:<avx512fmaskmode>
> [(subreg:VI48_AVX
> (not:<ssebytemode>
> (match_operand:<ssebytemode> 3 "vector_operand")) 0)
> (match_operand:VI48_AVX 4 "const0_operand")
> (match_operand:SI 5 "const_0_to_7_operand")]
> UNSPEC_PCMP)))]
>
> which gets split to the above pattern.
>
> In the preparation statements we have:
>
> if (!MEM_P (operands[3]))
> operands[3] = force_reg (<ssebytemode>mode, operands[3]);
> operands[3] = lowpart_subreg (<MODE>mode, operands[3], <ssebytemode>mode);
>
> Which won't fly when operand 3 is memory operand...
>
gcc/ChangeLog:
PR target/105953
* config/i386/sse.md (*avx_cmp<mode>3_ltint_not): Force_reg
operands[3].
gcc/testsuite/ChangeLog:
* g++.target/i386/pr105953.C: New test.
GCC Administrator [Wed, 15 Jun 2022 00:19:12 +0000 (00:19 +0000)]
Daily bump.
Jonathan Wakely [Mon, 13 Jun 2022 15:36:14 +0000 (16:36 +0100)]
libstdc++: Use type_identity_t for non-deducible std::atomic_xxx args
This is LWG 3220 which is about to become Tentatively Ready.
libstdc++-v3/ChangeLog:
* include/std/atomic (__atomic_val_t): Use __type_identity_t
instead of atomic<T>::value_type, as per LWG 3220.
* testsuite/29_atomics/atomic/lwg3220.cc: New test.
(cherry picked from commit
30cc1b65e4efa1a2c57fec5574fcae7a446b822f)
Mark Mentovai [Mon, 13 Jun 2022 15:40:19 +0000 (16:40 +0100)]
libstdc++: Rename __null_terminated to avoid collision with Apple SDK
The macOS 13 SDK (and equivalent-version iOS and other Apple OS SDKs)
contain this definition in <sys/cdefs.h>:
863 #define __null_terminated
This collides with the use of __null_terminated in libstdc++'s
experimental fs_path.h.
As libstdc++'s use of this token is entirely internal to fs_path.h, the
simplest workaround, renaming it, is most appropriate. Here, it's
renamed to __nul_terminated, referencing the NUL ('\0') value that is
used to terminate the strings in the context in which this tag structure
is used.
libstdc++-v3/ChangeLog:
* include/experimental/bits/fs_path.h (__detail::__null_terminated):
Rename to __nul_terminated to avoid colliding with a macro in
Apple's SDK.
Signed-off-by: Mark Mentovai <mark@mentovai.com>
(cherry picked from commit
254e88b3d7e8abcc236be3451609834371cf4d5d)
H.J. Lu [Fri, 10 Jun 2022 18:22:00 +0000 (11:22 -0700)]
x86: Require AVX for F16C and VAES
Since F16C and VAES are only usable with AVX, require AVX for F16C and
VAES.
libgcc/105920
* common/config/i386/cpuinfo.h (get_available_features): Require
AVX for F16C and VAES.
(cherry picked from commit
751f306688508b08842d0ab967dee8e6c3b91351)
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>
(cherry picked from commit
4e72ccad80d69a76d149fba59603b8173fffe8fe)
GCC Administrator [Tue, 14 Jun 2022 00:19:10 +0000 (00:19 +0000)]
Daily bump.
Iain Buclaw [Mon, 13 Jun 2022 12:35:38 +0000 (14:35 +0200)]
d: Improve TypeInfo errors when compiling in -fno-rtti mode
The existing TypeInfo errors can be cryptic. This alters the diagnostic
to include which expression is requiring `object.TypeInfo'.
gcc/d/ChangeLog:
* d-tree.h (check_typeinfo_type): Add Expression* parameter.
(build_typeinfo): Likewise. Declare new override.
* expr.cc (ExprVisitor): Call build_typeinfo with Expression*.
* typeinfo.cc (check_typeinfo_type): Include expression in the
diagnostic message.
(build_typeinfo): New override.
gcc/testsuite/ChangeLog:
* gdc.dg/rtti1.d: New test.
(cherry picked from commit
e55eda238545e93708c020fd21249459be64c463)
GCC Administrator [Mon, 13 Jun 2022 00:19:01 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Sun, 12 Jun 2022 00:19:03 +0000 (00:19 +0000)]
Daily bump.
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.
(cherry picked from commit
0ecb6b906f215ec56df1a555139abe9ad95414fb)
GCC Administrator [Sat, 11 Jun 2022 00:19:07 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Fri, 10 Jun 2022 00:19:33 +0000 (00:19 +0000)]
Daily bump.
Joseph Myers [Thu, 9 Jun 2022 22:05:36 +0000 (22:05 +0000)]
Update gcc sv.po
* sv.po: Update.
GCC Administrator [Thu, 9 Jun 2022 00:19:07 +0000 (00:19 +0000)]
Daily bump.
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.
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.
(cherry picked from commit
e94c6dbfb57a862dd8a8685eabc4886ad1aaea25)
Jonathan Wakely [Fri, 27 May 2022 11:43:18 +0000 (12:43 +0100)]
libstdc++: Mark non-exported function always_inline [PR105671]
This new function was added for gcc 11.1 but is not exported from the
shared library. Depending on inlining decisions, its callers might get
inlined but an external definition be needed for this function. That
then fails to link.
Since we can't add the export to the gcc-11 release branch now, mark it
always_inline. We can consider exporting it for gcc-13 if/when we bump
the shared library version (and maybe also for gcc-12 which is currently
at the same version as trunk). For now, the attribute will solve the
problem on all affected branches. The function is small enough that
force-inlining it shouldn't cause problems.
libstdc++-v3/ChangeLog:
PR libstdc++/105671
* include/std/sstream (basic_stringbuf::_M_high_mark): Add
always_inline attribute.
(cherry picked from commit
de57440858591a88e8fd7ba2505ca54546c86021)
Jonathan Wakely [Thu, 26 May 2022 20:32:55 +0000 (21:32 +0100)]
libstdc++: Fix narrowing conversions for 16-bit size_t [PR105681]
On a 16-bit target such as msp430 we get errors about narrowing long
values to size_t, which is only 16-bit. When --enable-libstdcxx-pch is
used the <bits/extc++.h> header breaks the build because of these
narrowing errors.
libstdc++-v3/ChangeLog:
PR libstdc++/105681
* include/ext/pb_ds/detail/resize_policy/hash_prime_size_policy_imp.hpp:
Limit ga_sizes array to values that fit in size_t.
* include/ext/random [__SIZE_WIDTH < 32] (sfmt86243)
(sfmt86243_64, sfmt132049, sfmt132049_64, sfmt216091)
(sfmt216091_64): Do not declare.
(cherry picked from commit
367740bf6d3a6627798b3955e5d85efc7549ef50)
Jonathan Wakely [Thu, 19 May 2022 11:54:41 +0000 (12:54 +0100)]
libstdc++: Only include <ext/atomicity.h> for COW string
Since the COW std::string was moved to its own header, we don't need the
atomic dispatch helpers in the definition of std::__cxx11::string. Move
the inclusion of the <ext/atomicity.h> header to <bits/cow_string.h>
where it's needed.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h: Do not include <ext/atomicity.h>
here.
* include/bits/cow_string.h: Include it here.
(cherry picked from commit
f3e22baec0290c23654e99bf184153765944f4aa)
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 Administrator [Wed, 8 Jun 2022 00:19:05 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Tue, 7 Jun 2022 00:19:09 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Mon, 6 Jun 2022 00:18:53 +0000 (00:18 +0000)]
Daily bump.
GCC Administrator [Sun, 5 Jun 2022 00:19:01 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Sat, 4 Jun 2022 00:19:03 +0000 (00:19 +0000)]
Daily bump.
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.
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.
Philipp Tomsich [Fri, 1 Apr 2022 12:42:58 +0000 (14:42 +0200)]
RISC-V: Implement C[LT]Z_DEFINED_VALUE_AT_ZERO
The Zbb support has introduced ctz and clz to the backend, but some
transformations in GCC need to know what the value of c[lt]z at zero
is. This affects how the optab is generated and may suppress use of
CLZ/CTZ in tree passes.
Among other things, this is needed for the transformation of
table-based ctz-implementations, such as in deepsjeng, to work
(see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838).
Prior to this change, the test case from PR90838 would compile to
on RISC-V targets with Zbb:
myctz:
lui a4,%hi(.LC0)
ld a4,%lo(.LC0)(a4)
neg a5,a0
and a5,a5,a0
mul a5,a5,a4
lui a4,%hi(.LANCHOR0)
addi a4,a4,%lo(.LANCHOR0)
srli a5,a5,58
sh2add a5,a5,a4
lw a0,0(a5)
ret
After this change, we get:
myctz:
ctz a0,a0
andi a0,a0,63
ret
Testing this with deepsjeng_r (from SPEC 2017) against QEMU, this
shows a clear reduction in dynamic instruction count:
- before
1961888067076
- after
1907928279874 (2.75% reduction)
This also merges the various target-specific test-cases (for x86-64,
aarch64 and riscv) within gcc.dg/pr90838.c.
This extends the macros (i.e., effective-target keywords) used in
testing (lib/target-supports.exp) to reliably distinguish between RV32
and RV64 via __riscv_xlen (i.e., the integer register bitwidth) :
testing for ILP32 could be misleading (as ILP32 is a valid memory
model for 64bit systems).
gcc/ChangeLog:
* config/riscv/riscv.h (CLZ_DEFINED_VALUE_AT_ZERO): Implement.
(CTZ_DEFINED_VALUE_AT_ZERO): Same.
* doc/sourcebuild.texi: add documentation for RISC-V specific
test target keywords
gcc/testsuite/ChangeLog:
* gcc.dg/pr90838.c: Add additional flags (dg-additional-options)
when compiling for riscv64 and subsume gcc.target/aarch64/pr90838.c
and gcc.target/i386/pr95863-2.c.
* gcc.target/aarch64/pr90838.c: Removed.
* gcc.target/i386/pr95863-2.c: Removed.
* lib/target-supports.exp: Recognize RV32 or RV64 via XLEN
Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
Signed-off-by: Manolis Tsamis <manolis.tsamis@vrull.eu>
Co-authored-by: Manolis Tsamis <manolis.tsamis@vrull.eu>
(cherry picked from commit
16f7fcadac19dabd04a5abbe6601df52d22e9685)
Richard Biener [Wed, 1 Jun 2022 12:13:01 +0000 (14:13 +0200)]
tree-optimization/105786 - avoid strlen replacement for pointers
This avoids matching strlen to a pointer result, avoiding ICEing
because of an integer adjustment using PLUS_EXPR on pointers.
2022-06-01 Richard Biener <rguenther@suse.de>
PR tree-optimization/105786
* tree-loop-distribution.cc
(loop_distribution::transform_reduction_loop): Only do strlen
replacement for integer type reductions.
* gcc.dg/torture/pr105786.c: New testcase.
(cherry picked from commit
57a8fb92ac4161ebbf9381b009e8c5af843e3e5f)
Richard Biener [Wed, 25 May 2022 09:49:03 +0000 (11:49 +0200)]
tree-optimization/105726 - adjust array bound heuristic
There's heuristic to detect ptr[1].a[...] out of bound accesses
reasoning that if ptr points to an array of aggregates a trailing
incomplete array has to have size zero. The following more
thoroughly constrains the cases this applies to avoid false
positive diagnostics.
2022-05-25 Richard Biener <rguenther@suse.de>
PR tree-optimization/105726
* gimple-ssa-warn-restrict.cc (builtin_memref::set_base_and_offset):
Constrain array-of-flexarray case more.
* g++.dg/warn/Warray-bounds-27.C: New testcase.
(cherry picked from commit
e7c482b08076bb299742883c4ffd65b31e33200c)
Richard Biener [Tue, 24 May 2022 08:09:25 +0000 (10:09 +0200)]
middle-end/105711 - properly handle CONST_INT when expanding bitfields
This is another place where we fail to pass down the mode of a
CONST_INT.
2022-05-24 Richard Biener <rguenther@suse.de>
PR middle-end/105711
* expmed.cc (extract_bit_field_as_subreg): Add op0_mode parameter
and use it.
(extract_bit_field_1): Pass down the mode of op0 to
extract_bit_field_as_subreg.
* gcc.target/i386/pr105711.c: New testcase.
(cherry picked from commit
91c7c5edd2c1d31bf379be1d077b39644391cc31)
Martin Sebor [Tue, 24 May 2022 22:01:12 +0000 (16:01 -0600)]
PR middle-end/105604 - ICE: in tree_to_shwi with vla in struct and sprintf
gcc/ChangeLog:
PR middle-end/105604
* gimple-ssa-sprintf.cc (set_aggregate_size_and_offset): Add comments.
(get_origin_and_offset_r): Remove null handling. Handle variable array
sizes.
(get_origin_and_offset): Handle null argument here. Simplify.
(alias_offset): Update comment.
* pointer-query.cc (field_at_offset): Update comment. Handle members
of variable-length types.
gcc/testsuite/ChangeLog:
PR middle-end/105604
* gcc.dg/Wrestrict-24.c: New test.
* gcc.dg/Wrestrict-25.c: New test.
* gcc.dg/Wrestrict-26.c: New test.
Co-authored-by: Richard Biener <rguenther@suse.de>
(cherry picked from commit
10d1986aee47c592f903527bb68546efc557735d)
Vineet Gupta [Mon, 23 May 2022 18:12:09 +0000 (11:12 -0700)]
RISC-V: Inhibit FP <--> int register moves via tune param
Under extreme register pressure, compiler can use FP <--> int
moves as a cheap alternate to spilling to memory.
This was seen with SPEC2017 FP benchmark 507.cactu:
ML_BSSN_Advect.cc:ML_BSSN_Advect_Body()
| fmv.d.x fa5,s9 # PDupwindNthSymm2Xt1, PDupwindNthSymm2Xt1
| .LVL325:
| ld s9,184(sp) # _12469, %sfp
| ...
| .LVL339:
| fmv.x.d s4,fa5 # PDupwindNthSymm2Xt1, PDupwindNthSymm2Xt1
|
The FMV instructions could be costlier (than stack spill) on certain
micro-architectures, thus this needs to be a per-cpu tunable
(default being to inhibit on all existing RV cpus).
Testsuite run with new test reports 10 failures without the fix
corresponding to the build variations of pr105666.c
| === gcc Summary ===
|
| # of expected passes 123318 (+10)
| # of unexpected failures 34 (-10)
| # of unexpected successes 4
| # of expected failures 780
| # of unresolved testcases 4
| # of unsupported tests 2796
gcc/ChangeLog:
* config/riscv/riscv.cc: (struct riscv_tune_param): Add
fmv_cost.
(rocket_tune_info): Add default fmv_cost 8.
(sifive_7_tune_info): Ditto.
(thead_c906_tune_info): Ditto.
(optimize_size_tune_info): Ditto.
(riscv_register_move_cost): Use fmv_cost for int<->fp moves.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr105666.c: New test.
Signed-off-by: Vineet Gupta <vineetg@rivosinc.com>
(cherry picked from commit
b646d7d279ae0c0d35564542d09866bf3e8afac0)
GCC Administrator [Thu, 2 Jun 2022 00:19:00 +0000 (00:19 +0000)]
Daily bump.
Jason Merrill [Tue, 31 May 2022 20:31:35 +0000 (16:31 -0400)]
c++: auto and dependent member name [PR105734]
In r12-3643 I improved our handling of type names after . or -> when
unqualified lookup doesn't find anything, but it needs to handle auto
specially.
PR c++/105734
gcc/cp/ChangeLog:
* parser.cc (cp_parser_postfix_dot_deref_expression): Use typeof
if the expression has auto type.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/auto57.C: New test.
Jason Merrill [Tue, 31 May 2022 20:17:58 +0000 (16:17 -0400)]
c++: auto function as function argument [PR105779]
This testcase demonstrates that the issue in PR105623 is not limited to
templates, so we should do the marking in a less template-specific place.
PR c++/105779
gcc/cp/ChangeLog:
* call.cc (resolve_args): Call mark_single_function here.
* pt.cc (unify_one_argument): Not here.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/auto-fn63.C: New test.
Patrick Palka [Wed, 1 Jun 2022 12:47:25 +0000 (08:47 -0400)]
c++: constexpr init of union sub-aggr w/ base [PR105491]
Here ever since r10-7313-gb599bf9d6d1e18, reduced_constant_expression_p
in C++11/14 is rejecting the marked sub-aggregate initializer (of type S)
W w = {.D.2445={.s={.D.2387={.m=0}, .b=0}}};
^
ultimately because said initializer has CONSTRUCTOR_NO_CLEARING set,
hence the function must verify that all fields of S are initialized.
And before C++17 it doesn't expect to see base class fields (since
next_initializable_field skips over them), so the presence thereof
causes r_c_e_p to return false.
The reason r10-7313-gb599bf9d6d1e18 causes this is because in that
commit we began using CONSTRUCTOR_NO_CLEARING to precisely track whether
we're in middle of activating a union member. This ends up affecting
clear_no_implicit_zero, which recurses into sub-aggregate initializers
only if the outer initializer has CONSTRUCTOR_NO_CLEARING set. After
that commit, the outer union initializer above no longer has the flag
set at this point and so clear_no_implicit_zero no longer recurses into
the marked inner initializer.
But arguably r_c_e_p should be able to accept the marked initializer
regardless of whether CONSTRUCTOR_NO_CLEARING is set. The primary bug
therefore seems to be that r_c_e_p relies on next_initializable_field
which skips over base class fields in C++11/14. To fix this, this patch
introduces a new helper function next_subobject_field which is like
next_initializable_field except that it never skips base class fields,
and makes r_c_e_p use it. This patch then renames next_initializable_field
to next_aggregate_field (and makes it skip over vptr fields again).
NB: This minimal backport of r13-211-g0c7bce0ac184c0 for 12.2 just adds
next_subobject_field and makes reduced_constant_expression_p use it.
PR c++/105491
gcc/cp/ChangeLog:
* constexpr.cc (reduced_constant_expression_p): Use
next_subobject_field instead.
* cp-tree.h (next_subobject_field): Declare.
* decl.cc (next_subobject_field): Define.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-union7.C: New test.
* g++.dg/cpp0x/constexpr-union7a.C: New test.
* g++.dg/cpp2a/constinit17.C: New test.
(cherry picked from commit
0c7bce0ac184c057bacad9c8e615ce82923835fd)
GCC Administrator [Wed, 1 Jun 2022 00:19:09 +0000 (00:19 +0000)]
Daily bump.
Jason Merrill [Fri, 27 May 2022 02:43:05 +0000 (22:43 -0400)]
c++: lambda in concept [PR105652]
We currently check satisfaction in the context of the constrained
declaration (which may be wrong, see PR104111). When checking C<int>
for S<int>, we currently substitute into the lambda in the context of
S<T> (rather than S<int>, which seems wrong if the above isn't wrong), so
the new closure type thinks its context is S<T>, which confuses debug
output. For the moment, let's work around all of this by overriding the
context of the closure.
PR c++/105652
gcc/cp/ChangeLog:
* pt.cc (tsubst_lambda_expr): Don't let a namespace-scope lambda
instantiate into a class-scope lambda.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-lambda20.C: New test.
Jason Merrill [Wed, 25 May 2022 16:38:58 +0000 (12:38 -0400)]
c++: CTAD with alias and nested template [PR105655]
Here, alias_ctad_tweaks expect tsubst_decl of a FUNCTION_DECL to return a
FUNCTION_DECL. A reasonable expectation, but in this case we were replacing
the template args of the class-scope deduction guide with equivalent args,
so looking in the hash table we found the partial instantiation stored when
instantiating A<int>, which is a TEMPLATE_DECL. It's fine for that to be
what is stored, but tsubst_function_decl should never return it.
PR c++/105655
gcc/cp/ChangeLog:
* pt.cc (build_template_decl): Add assert.
(tsubst_function_decl): Don't return a template.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/class-deduction-alias13.C: New test.
Jason Merrill [Tue, 24 May 2022 21:37:58 +0000 (17:37 -0400)]
c++: deduction from auto fn [PR105623]
Since my patch for PR90451, we defer mark_used of single functions as late
as possible. And since my r12-1273, we keep BASELINK from lookup around
rather than reconstruct it later. These both made us try to instantiate g
with a function type that still had 'auto' as its return type.
PR c++/105623
gcc/cp/ChangeLog:
* decl2.cc (mark_used): Copy type from fn to BASELINK.
* pt.cc (unify_one_argument): Call mark_single_function.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/auto-fn62.C: New test.
Jason Merrill [Tue, 26 Apr 2022 15:15:04 +0000 (11:15 -0400)]
c++: constexpr ref to array of array [PR102307]
The problem here is that first check_initializer calls
build_aggr_init_full_exprs, which does overload resolution, but then in the
case of failed constexpr throws away the result and does it again in
build_functional_cast. But in the first overload resolution,
reshape_init_array_1 decided to reuse the inner CONSTRUCTORs because
tf_error is set, so we know we're committed. But the second pass gets
confused by the CONSTRUCTORs with non-init-list types.
Fixed by avoiding a second pass: instead, pass the call from build_aggr_init
to build_cplus_new, which will turn it into a TARGET_EXPR. I don't bother
to change the object argument because it will be replaced later in
simplify_aggr_init_expr.
PR c++/102307
gcc/cp/ChangeLog:
* decl.cc (check_initializer): Use build_cplus_new in case of
constexpr failure.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/constexpr-array2.C: New test.
Iain Buclaw [Tue, 31 May 2022 12:45:02 +0000 (14:45 +0200)]
d: Fix D lexer sometimes fails to compile code read from stdin
As of gdc-12, the lexer expects there 4 bytes of zero padding at the end
of the source buffer to mark the end of input. Sometimes when reading
from stdin, the data at the end of input is garbage rather than zeroes.
Fix that by explicitly calling memset past the end of the buffer.
PR d/105544
gcc/d/ChangeLog:
* d-lang.cc (d_parse_file): Zero padding past the end of the stdin
buffer so the D lexer has a sentinel to stop parsing at.
(cherry picked from commit
a0bc7fd42136f124726985b1ab4dcde739cd260e)
GCC Administrator [Tue, 31 May 2022 00:19:02 +0000 (00:19 +0000)]
Daily bump.
Martin Jambor [Mon, 30 May 2022 20:04:21 +0000 (22:04 +0200)]
ipa: Check cst type when propagating controled uses info
PR 105639 shows that code with type-mismatches can trigger an assert
after runnning into a branch that was inteded only for references to
variables - as opposed to references to functions. Fixed by moving
the condition from the assert to the guarding if statement.
gcc/ChangeLog:
2022-05-25 Martin Jambor <mjambor@suse.cz>
PR ipa/105639
* ipa-prop.cc (propagate_controlled_uses): Check type of the
constant before adding a LOAD reference.
gcc/testsuite/ChangeLog:
2022-05-25 Martin Jambor <mjambor@suse.cz>
PR ipa/105639
* gcc.dg/ipa/pr105639.c: New test.
(cherry picked from commit
f571596f8cd8fbad34305b4bec1a813620e0cbf0)
Jakub Jelinek [Sun, 29 May 2022 19:57:51 +0000 (21:57 +0200)]
libcpp: Ignore CPP_PADDING tokens in _cpp_parse_expr [PR105732]
The first part of the following testcase (m1-m3 macros and its use)
regressed with my PR89971 fix, but as the m1,m4-m5 and its use part shows,
the problem isn't new, we can emit a CPP_PADDING token to avoid it from
being adjacent to whatever comes after the __VA_OPT__ (in this case there
is nothing afterwards, true).
In most cases these CPP_PADDING tokens don't matter, all other
callers of cpp_get_token_with_location either ignore CPP_PADDING tokens
completely (e.g. c_lex_with_flags) or they just remember them and
take them into account when printing stuff whether there should be
added whitespace or not (scan_translation_unit + token_streamer::stream).
So, I think we should just ignore CPP_PADDING tokens the same way in
_cpp_parse_expr.
2022-05-27 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/105732
* expr.cc (_cpp_parse_expr): Handle CPP_PADDING by just another
token.
* c-c++-common/cpp/va-opt-10.c: New test.
(cherry picked from commit
58a40e76ebadce78639644cd3d56e42b68336927)
Jakub Jelinek [Sat, 28 May 2022 06:30:47 +0000 (08:30 +0200)]
libgomp: Don't define GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC for _aligned_malloc [PR105745]
since apparently _aligned_malloc requires freeing with _aligned_free and:
/* Defined if gomp_aligned_alloc doesn't use fallback version
and free can be used instead of gomp_aligned_free. */
#define GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC 1
so the second condition isn't satisfied. For uses inside of the OpenMP
allocators we can still use _aligned_malloc but we need to call _aligned_free
in gomp_aligned_free.
2022-05-28 Jakub Jelinek <jakub@redhat.com>
PR libgomp/105745
* libgomp.h (GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC): Don't define for
defined(HAVE__ALIGNED_MALLOC) case.
* alloc.c (gomp_aligned_alloc): Move defined(HAVE__ALIGNED_MALLOC)
handling as last option before fallback instead of first.
(gomp_aligned_free): For defined(HAVE__ALIGNED_MALLOC) call
_aligned_free.
(cherry picked from commit
42fd2cd932384288914174f4af7974a060972bff)
Jakub Jelinek [Fri, 27 May 2022 09:40:42 +0000 (11:40 +0200)]
fold-const: Fix up -fsanitize=null in C++ [PR105729]
The following testcase triggers a false positive UBSan binding a reference
to null diagnostics.
In the FE we instrument conversions from pointer to reference type
to diagnose at runtime if the operand of such a conversion is 0.
The problem is that a GENERIC folding folds
((const struct Bar *) ((const struct Foo *) this)->data) + (sizetype) range_check (x)
conversion to const struct Bar & by converting to that the first
operand of the POINTER_PLUS_EXPR. But that changes when the -fsanitize=null
binding to reference runtime check occurs. Without the optimization,
it is invoked on the result of the POINTER_PLUS_EXPR, and as range_check
call throws, that means it never triggers in the testcase.
With the optimization, it checks whether this->data is NULL and it is.
The following patch avoids that optimization during GENERIC folding when
-fsanitize=null is enabled and it is a cast from non-REFERENCE_TYPE to
REFERENCE_TYPE.
2022-05-27 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/105729
* fold-const.cc (fold_unary_loc): Don't optimize (X &) ((Y *) z + w)
to (X &) z + w if -fsanitize=null during GENERIC folding.
* g++.dg/ubsan/pr105729.C: New test.
(cherry picked from commit
e2f014fcefcd2ad56b31995329820bbd99072eae)
Jakub Jelinek [Wed, 25 May 2022 10:05:08 +0000 (12:05 +0200)]
asan: Fix up instrumentation of assignments which are both loads and stores [PR105714]
On the following testcase with -Os asan pass sees:
<bb 6> [local count:
354334800]:
# h_21 = PHI <h_15(6), 0(5)>
*c.3_5 = *d.2_4;
h_15 = h_21 + 1;
if (h_15 != 3)
goto <bb 6>; [75.00%]
else
goto <bb 7>; [25.00%]
<bb 7> [local count:
118111600]:
*c.3_5 = MEM[(struct a *)&b + 12B];
_13 = c.3_5->x;
return _13;
It instruments the
*c.3_5 = *d.2_4;
assignment by adding
.ASAN_CHECK (7, c.3_5, 4, 4);
.ASAN_CHECK (6, d.2_4, 4, 4);
before it (which later lowers to checking the corresponding shadow
memory). But when considering instrumentation of
*c.3_5 = MEM[(struct a *)&b + 12B];
it doesn't instrument anything, because it sees that *c.3_5 store is
already instrumented in a dominating block and so there is no need
to instrument *c.3_5 store again (i.e. add another
.ASAN_CHECK (7, c.3_5, 4, 4);
). That is true, but misses the fact that we still want to
instrument the MEM[(struct a *)&b + 12B] load.
The following patch fixes that by changing has_stmt_been_instrumented_p
to consider both store and load in the assignment if it does both
(returning true iff both have been instrumented).
That matches how we handle e.g. builtin calls, where we also perform AND
of all the memory locs involved in the call.
I've verified that we still don't add the redundant
.ASAN_CHECK (7, c.3_5, 4, 4);
call but just add
_18 = &MEM[(struct a *)&b + 12B];
.ASAN_CHECK (6, _18, 4, 4);
to instrument the load.
2022-05-25 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/105714
* asan.cc (has_stmt_been_instrumented_p): For assignments which
are both stores and loads, return true only if both destination
and source have been instrumented.
* gcc.dg/asan/pr105714.c: New test.
(cherry picked from commit
af02daff557a0abbf5521c143f1cdda406848a9b)
Jakub Jelinek [Thu, 19 May 2022 09:56:21 +0000 (11:56 +0200)]
pointer-query: Fix ICE with non-pointer param [PR105635]
The gimple_parm_array_size function comment talks about pointe parameters
but doesn't actually verify it, it checks whether an attribute is present
on the function and then just uses TREE_TYPE (TREE_TYPE (var)) which
assumes a pointer type (or in theory could work for ARRAY_TYPE but
c-family languages which only have that attribute will never have ARRAY_TYPE
parameters; and for VECTOR_TYPE/COMPLEX_TYPE it would mean something quite
different).
So, this patch punts early if var doesn't have pointer/reference type.
2022-05-19 Jakub Jelinek <jakub@redhat.com>
PR c/105635
* pointer-query.cc (gimple_parm_array_size): Return NULL if var
doesn't have pointer or reference type.
* gcc.dg/pr105635.c: New test.
(cherry picked from commit
3b4daa0b3c3d8eb2ac3b40ad6898f314ed4d7919)
GCC Administrator [Mon, 30 May 2022 00:19:10 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Sun, 29 May 2022 00:18:53 +0000 (00:18 +0000)]
Daily bump.
GCC Administrator [Sat, 28 May 2022 00:19:07 +0000 (00:19 +0000)]
Daily bump.
Jonathan Wakely [Thu, 26 May 2022 14:44:08 +0000 (15:44 +0100)]
libstdc++: Fix atomic and error_code printers for versioned namespace
This fixes the printers to work with std::__8::atomic and
std::__v8::ios_errc and std::__v8::future_errc.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdErrorCodePrinter): Make
lookup for ios_errc and future_errc check versioned namespace.
(StdAtomicPrinter): Strip versioned namespace from typename.
(cherry picked from commit
11e1ee1b38f0d3a825b0cb70122cb345636b0534)
François Dumont [Wed, 25 May 2022 20:05:48 +0000 (22:05 +0200)]
libstdc++: Fix printing of std::span for versioned namespace
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdSpanPrinter.__init__):
Strip typename from version namespace.
(cherry picked from commit
ace4b7f295f407b16cfbc2e359f4ef7cd61d4a46)
Jonathan Wakely [Thu, 26 May 2022 08:49:40 +0000 (09:49 +0100)]
libstdc++: Fix printing of std::atomic<shared_ptr<T>> for versioned namespace
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (SharedPointerPrinter): Strip
versioned namespace from the template argument too.
(cherry picked from commit
634b0089f664cca96d71262b295025e057054f2c)
Jonathan Wakely [Thu, 26 May 2022 11:41:03 +0000 (12:41 +0100)]
libstdc++: Add constexpr to std::counted_iterator post-increment (LWG 3643)
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (counted_iterator::operator++(int)):
Add 'constexpr' as per LWG 3643.
* testsuite/24_iterators/counted_iterator/lwg3643.cc: New test.
(cherry picked from commit
47b20d027ade5bfbd932724d0ea2aedee7421243)
Jonathan Wakely [Thu, 19 May 2022 12:26:49 +0000 (13:26 +0100)]
libstdc++: Implement LWG 3683 for pmr::polymorphic_allocator
This issue has recently been moved to Tentatively Ready, and seems
uncontroversial. This allows equality comparison with types that are
convertible to pmr::polymorphic_allocator, which fail deduction for the
existing equality operator.
libstdc++-v3/ChangeLog:
* include/std/memory_resource (polymorphic_allocator): Add
non-template equality operator, as proposed for LWG 3683.
* testsuite/20_util/polymorphic_allocator/lwg3683.cc: New test.
(cherry picked from commit
f13f9c99dbee9c495955a430dd10bdb24a16f24a)
Jonathan Wakely [Fri, 20 May 2022 14:44:25 +0000 (15:44 +0100)]
libstdc++: Reduce <random> test iterations for simulators
Some of these tests take several minutes on a simulator like cris-elf,
so we can conditionally run fewer iterations. The testDiscreteDist
helper already supports custom sizes so we just need to make use of that
when { target simulator } matches.
The relevant code is sufficiently tested on other targets, so we're not
losing anything by only running a small number of iterators for sims.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/bernoulli_distribution/operators/values.cc:
Run fewer iterations for simulator targets.
* testsuite/26_numerics/random/binomial_distribution/operators/values.cc:
Likewise.
* testsuite/26_numerics/random/discrete_distribution/operators/values.cc:
Likewise.
* testsuite/26_numerics/random/geometric_distribution/operators/values.cc:
Likewise.
* testsuite/26_numerics/random/negative_binomial_distribution/operators/values.cc:
Likewise.
* testsuite/26_numerics/random/poisson_distribution/operators/values.cc:
Likewise.
* testsuite/26_numerics/random/uniform_int_distribution/operators/values.cc:
Likewise.
(cherry picked from commit
e3b8b4f7814c54543d9b7ea3ee8cf2cb9cff351d)
Jonathan Wakely [Tue, 17 May 2022 08:32:36 +0000 (09:32 +0100)]
libstdc++: Skip tests that fail for the versioned namespace
Most tests for the contents of header synopses need to be supressed for
the versioned namespace build, because redeclaring the entities in std
fails when they were originally declared in std::__8.
I added these tests recently without the suppression, so they fail.
libstdc++-v3/ChangeLog:
* testsuite/20_util/expected/synopsis.cc: Skip for versioned
namespace.
* testsuite/27_io/headers/iosfwd/synopsis.cc: Likewise.
(cherry picked from commit
1815462a6e53465c404f8a5f6116891492d4b50b)
Jonathan Wakely [Wed, 11 May 2022 15:06:13 +0000 (16:06 +0100)]
libstdc++: Fix typo in doxygen @headerfile command
libstdc++-v3/ChangeLog:
* include/bits/mofunc_impl.h: Fix doxygen command.
(cherry picked from commit
4163b0be816f596147fa9a2732fc652e4ea9572c)
Jonathan Wakely [Thu, 12 May 2022 18:33:58 +0000 (19:33 +0100)]
libstdc++: Add noexcept to std::launch operators
libstdc++-v3/ChangeLog:
* include/std/future (launch): Make operators noexcept.
(cherry picked from commit
8659bcd6b7e692a9a516cd57bb19303a2efe78ba)
Marek Polacek [Fri, 27 May 2022 14:51:30 +0000 (10:51 -0400)]
c++: Fix ICE with -Wmismatched-tags [PR105725]
Here we ICE with -Wmismatched-tags on something like
template <class T>
bool B<T, enable_if_t<is_class_v<class T::foo>>>;
Specifically, the "class T::foo" bit. There, class_decl_loc_t::add gets
a TYPENAME_TYPE as TYPE, rather than a class/union type, so checking
TYPE_BEING_DEFINED will crash. I think it's OK to allow a TYPENAME_TYPE to
slip into that function; we just shouldn't consider the 'class' tag redundant
(which works as a 'typename'). In fact, every other compiler *requires* it.
PR c++/105725
gcc/cp/ChangeLog:
* parser.cc (class_decl_loc_t::add): Check CLASS_TYPE_P.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wmismatched-tags-10.C: New test.
(cherry picked from commit
d822f4bbd714c6595f70cc68888dcebecfb6662d)
GCC Administrator [Fri, 27 May 2022 00:18:42 +0000 (00:18 +0000)]
Daily bump.
Simon Cook [Wed, 25 May 2022 13:25:43 +0000 (14:25 +0100)]
RISC-V: Don't unconditionally add m,a,f,d in arch-canonicalize
This solves an issue where rv32i, etc. are canonicalized to rv32imafd
since the g->i addition of 'm', 'a', 'f', 'd' is not actually gated by
whether the input was rv32g/rv64g.
gcc/ChangeLog:
* config/riscv/arch-canonicalize: Only add mafd extension if
base was rv32/rv64g.
(cherry picked from commit
63f198553d3940495bfaa49da30b2ce93375c916)
Kito Cheng [Mon, 9 May 2022 03:44:30 +0000 (11:44 +0800)]
RISC-V: Fix wrong expansion for arch-canonicalize
rv64gcv should exapnd into:
rv64imafdcv_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b
but we exapnd fd twice for now:
rv64imafdfdcv_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b
gcc/ChangeLog:
* config/riscv/arch-canonicalize: Handle g correctly.
(cherry picked from commit
27239e13b1ba383e2706231917062aa6e14150a8)
GCC Administrator [Thu, 26 May 2022 00:19:12 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Wed, 25 May 2022 00:19:20 +0000 (00:19 +0000)]
Daily bump.
Qing Zhao [Tue, 24 May 2022 15:03:40 +0000 (15:03 +0000)]
i386: Adjust -fzero-call-used-regs to always use XOR [PR101891]
Currently on i386, -fzero-call-used-regs uses a pattern of:
XOR regA,regA
MOV regA,regB
MOV regA,regC
...
RET
However, this introduces both a register ordering dependency (e.g. the CPU
cannot clear regB without clearing regA first), and while greatly reduces
available ROP gadgets, it does technically leave a set of "MOV" ROP gadgets
at the end of functions (e.g. "MOV regA,regC; RET").
This patch will switch to always use XOR on i386:
XOR regA,regA
XOR regB,regB
XOR regC,regC
...
RET
gcc/ChangeLog:
PR target/101891
* config/i386/i386.cc (zero_call_used_regno_mode): use V2SImode
as a generic MMX mode instead of V4HImode.
(zero_all_mm_registers): Use SET to zero instead of MOV for
zeroing scratch registers.
(ix86_zero_call_used_regs): Likewise.
gcc/testsuite/ChangeLog:
* gcc.target/i386/zero-scratch-regs-1.c: Add -fno-stack-protector
-fno-PIC.
* gcc.target/i386/zero-scratch-regs-10.c: Adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-13.c: Add -msse.
* gcc.target/i386/zero-scratch-regs-14.c: Adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-15.c: Add -fno-stack-protector
-fno-PIC.
* gcc.target/i386/zero-scratch-regs-16.c: Likewise.
* gcc.target/i386/zero-scratch-regs-17.c: Likewise.
* gcc.target/i386/zero-scratch-regs-18.c: Add -fno-stack-protector
-fno-PIC, adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-19.c: Add -fno-stack-protector
-fno-PIC.
* gcc.target/i386/zero-scratch-regs-2.c: Adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-20.c: Add -msse.
* gcc.target/i386/zero-scratch-regs-21.c: Add -fno-stack-protector
-fno-PIC, Adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-22.c: Adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-23.c: Likewise.
* gcc.target/i386/zero-scratch-regs-26.c: Likewise.
* gcc.target/i386/zero-scratch-regs-27.c: Likewise.
* gcc.target/i386/zero-scratch-regs-28.c: Likewise.
* gcc.target/i386/zero-scratch-regs-3.c: Add -fno-stack-protector.
* gcc.target/i386/zero-scratch-regs-31.c: Adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-4.c: Add -fno-stack-protector
-fno-PIC.
* gcc.target/i386/zero-scratch-regs-5.c: Adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-6.c: Add -fno-stack-protector.
* gcc.target/i386/zero-scratch-regs-7.c: Likewise.
* gcc.target/i386/zero-scratch-regs-8.c: Adjust mov to xor.
* gcc.target/i386/zero-scratch-regs-9.c: Add -fno-stack-protector.
(cherry picked from commit
0b86943aca51175968e40bbb6f2662dfe3fbfe59)
Bruno Haible [Wed, 11 May 2022 15:10:07 +0000 (17:10 +0200)]
Extend --with-zstd documentation
The patch that was so far added for documenting --with-zstd is pretty
minimal:
- it refers to undocumented options --with-zstd-include and
--with-zstd-lib;
- it suggests that --with-zstd can be used without an argument;
- it does not clarify how this option applies to cross-compilation.
How about adding the same details as for the --with-isl,
--with-isl-include, --with-isl-lib options, mutatis mutandis? This patch
does that.
PR other/105527
gcc/ChangeLog:
* doc/install.texi (Configuration): Add more details about --with-zstd.
Document --with-zstd-include and --with-zstd-lib
Signed-off-by: Bruno Haible <bruno@clisp.org>
(cherry picked from commit
3677eb80b683cead7db972bc206fd2e75d997bd2)
Martin Liska [Wed, 11 May 2022 11:21:26 +0000 (13:21 +0200)]
docs: document --with-zstd
PR other/105527
gcc/ChangeLog:
* doc/install.texi: Document the configure option --with-zstd.
(cherry picked from commit
8fa689767a8a55c889683d178ae3a003ec689927)
GCC Administrator [Tue, 24 May 2022 00:19:29 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Mon, 23 May 2022 00:19:03 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Sun, 22 May 2022 00:19:11 +0000 (00:19 +0000)]
Daily bump.