Marek Polacek [Tue, 17 Jan 2023 22:34:58 +0000 (17:34 -0500)]
c++: -Wdangling-reference with reference wrapper [PR107532]
Here, -Wdangling-reference triggers where it probably shouldn't, causing
some grief. The code in question uses a reference wrapper with a member
function returning a reference to a subobject of a non-temporary object:
const Plane & meta = fm.planes().inner();
I've tried a few approaches, e.g., checking that the member function's
return type is the same as the type of the enclosing class (which is
the case for member functions returning *this), but that then breaks
Wdangling-reference4.C with std::optional<std::string>.
This patch adjusts do_warn_dangling_reference so that we look through
reference wrapper classes (meaning, has a reference member and a
constructor taking the same reference type, or is std::reference_wrapper
or std::ranges::ref_view) and don't warn for them, supposing that the
member function returns a reference to a non-temporary object.
PR c++/107532
gcc/cp/ChangeLog:
* call.cc (reference_like_class_p): New.
(do_warn_dangling_reference): Add new bool parameter. See through
reference_like_class_p.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wdangling-reference8.C: New test.
* g++.dg/warn/Wdangling-reference9.C: New test.
Jakub Jelinek [Tue, 7 Mar 2023 15:28:20 +0000 (16:28 +0100)]
c++: Fix up ICE in emit_support_tinfo_1 [PR109042]
In my recent rtti.cc change I assumed when emitting the support tinfos
that the tinfos for the fundamental types haven't been created yet.
Normally (in libsupc++.a (fundamental_type_info.o)) that is the case,
but as can be seen on the testcase, one can violate it by using typeid
etc. in the same TU and do it before ~__fundamental_type_info ()
definition.
The following patch fixes that by popping from unemitted_tinfo_decls
only in the normal case when it is there, and treating non-NULL
DECL_INITIAL on a tinfo node as indication that emit_tinfo_decl has
processed it already.
2023-03-07 Jakub Jelinek <jakub@redhat.com>
PR c++/109042
* rtti.cc (emit_support_tinfo_1): Don't assert that last
unemitted_tinfo_decls element is tinfo, instead pop from it only in
that case.
* decl2.cc (c_parse_final_cleanups): Don't call emit_tinfo_decl
for unemitted_tinfO_decls which have already non-NULL DECL_INITIAL.
Marek Polacek [Mon, 6 Mar 2023 23:06:39 +0000 (18:06 -0500)]
c++: noexcept and copy elision [PR109030]
When processing a noexcept, constructors aren't elided: build_over_call
has
/* It's unsafe to elide the constructor when handling
a noexcept-expression, it may evaluate to the wrong
value (c++/53025). */
&& (force_elide || cp_noexcept_operand == 0))
so the assert I added recently needs to be relaxed a little bit.
Marek Polacek [Fri, 3 Mar 2023 16:24:24 +0000 (11:24 -0500)]
c++: error with constexpr operator() [PR107939]
Similarly to PR107938, this also started with r11-557, whereby cp_finish_decl
can call check_initializer even in a template for a constexpr initializer.
Here we are rejecting
extern const Q q;
template<int>
constexpr auto p = q(0);
even though q has a constexpr operator(). It's deemed non-const by
decl_maybe_constant_var_p because even though 'q' is const it is not
of integral/enum type.
If fun is not a function pointer, we don't know if we're using it as an
lvalue or rvalue, so with this patch we pass 'any' for want_rval. With
that, p_c_e/VAR_DECL doesn't flat out reject the underlying VAR_DECL.
PR c++/107939
gcc/cp/ChangeLog:
* constexpr.cc (potential_constant_expression_1) <case CALL_EXPR>: Pass
'any' when recursing on a VAR_DECL and not a pointer to function.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/var-templ74.C: Remove dg-error.
* g++.dg/cpp1y/var-templ77.C: New test.
Pan Li [Tue, 7 Mar 2023 12:05:15 +0000 (20:05 +0800)]
RISC-V: Bugfix for rvv bool mode precision adjustment
Fix the bug of the rvv bool mode precision with the adjustment.
The bits size of vbool*_t will be adjusted to
[1, 2, 4, 8, 16, 32, 64] according to the rvv spec 1.0 isa. The
adjusted mode precison of vbool*_t will help underlying pass to
make the right decision for both the correctness and optimization.
However, there may be some optimization opportunates after
the mode precision adjustment. It can be token care of in
the RISC-V backend in the underlying separted PR(s).
PR target/108185
PR target/108654
* gcc.target/riscv/rvv/base/pr108185-1.c: New test.
* gcc.target/riscv/rvv/base/pr108185-2.c: New test.
* gcc.target/riscv/rvv/base/pr108185-3.c: New test.
* gcc.target/riscv/rvv/base/pr108185-4.c: New test.
* gcc.target/riscv/rvv/base/pr108185-5.c: New test.
* gcc.target/riscv/rvv/base/pr108185-6.c: New test.
* gcc.target/riscv/rvv/base/pr108185-7.c: New test.
* gcc.target/riscv/rvv/base/pr108185-8.c: New test.
Signed-off-by: Pan Li <pan2.li@intel.com> Co-authored-by: Ju-Zhe Zhong <juzhe.zhong@rivai.ai>
Xi Ruoyao [Sat, 24 Sep 2022 07:16:57 +0000 (15:16 +0800)]
aarch64: testsuite: disable stack protector for tests relying on stack offset
Stack protector needs a guard value on the stack and change the stack
layout. So we need to disable it for those tests, to avoid test failure
with --enable-default-ssp.
Xi Ruoyao [Sat, 24 Sep 2022 06:50:03 +0000 (14:50 +0800)]
aarch64: testsuite: disable stack protector for pr104005.c
Storing stack guarding variable need one stp instruction, breaking the
scan-assembler-not pattern in the test. Disable stack protector to
avoid a test failure with --enable-default-ssp.
Xi Ruoyao [Sat, 24 Sep 2022 06:38:31 +0000 (14:38 +0800)]
aarch64: testsuite: disable stack protector for auto-init-7.c
The test scans for "const_int 0" in the RTL dump, but stack protector
can produce more "const_int 0". To avoid a failure with
--enable-default-ssp, disable stack protector for this.
Xi Ruoyao [Sat, 24 Sep 2022 06:28:44 +0000 (14:28 +0800)]
aarch64: testsuite: disable PIE for tests with large code model [PR70150]
These tests set large code model with -mcmodel=large or target pragma for
AArch64. But if GCC is configured with --enable-default-pie, it triggers
"sorry: unimplemented: code model large with -fpic". Disable PIE to make
avoid the issue.
testsuite: Gate gcc.dg/plugin/must-tail-call-1.c and -2.c on tail_call
While gcc.dg/plugin/must-tail-call-2.c passes for all targets even
without this, the error message is, for a target like cris-elf that
doesn't implement sibling calls: "error: cannot tail-call: machine
description does not have a sibcall_epilogue instruction pattern"
rather than "error: cannot tail-call: callee returns a structure".
Also, it'd be confusing to exclude must-tail-call-1.c but not
must-tail-call-2.c
* gcc.dg/plugin/must-tail-call-1.c, gcc.dg/plugin/must-tail-call-2.c:
Gate on effective target tail_call.
The RTL "expand" dump is the first RTL dump, and it also appears to be
the earliest trace of the target having implemented sibcalls.
Including the "," in the pattern searched for, to try and avoid
possible false matches, but there doesn't appear to be any identifiers
or target names nearby so this is just belts and suspenders. Using
"tail_call" as a shorter and more commonly used term than a derivative
of "sibling calls", and expecting only gcc folks to have heard of
"sibcalls".
For 32-bit newlib targets (such as cris-elf and pru-elf),
that int32_t is "long int". See other regexps in the
testsuite matching "aka (long )?int" (with single-quotes
where needed) where the pattern in
allocation-size-multiline-3.c matches plain "int". Uses the
special syntax recently introduced for multi-line patterns.
testsuite:
* gcc.dg/analyzer/allocation-size-multiline-3.c: Handle
int32_t being "long int".
testsuite: Provide means to regexp in multiline patterns
Those multi-line-patterns are literal. Sometimes a regexp
needs to be matched. This is a start: just three elements
are supported: "(" ")" and the compound ")?" (and on second
thought, it can be argued that "(...)" alone is not useful).
Note that Tcl "string map" is documented to have the desired
effect: a once-over but no re-recognitions of previously
replaced mapped elements. Also, drop a doubled "containing".
testsuite:
* lib/multiline.exp (_build_multiline_regex): Map
"{re:" to "(", similarly ")?" from ":re?}" and the
same without question mark.
PR target/107299: Fix build issue when long double is IEEE 128-bit
This patch updates the IEEE 128-bit types used in libgcc.
At the moment, we cannot build GCC when the target uses IEEE 128-bit long
doubles, such as building the compiler for a native Fedora 36 system. The
build dies when it is trying to build the _mulkc3.c and _divkc3 modules.
This patch changes libgcc to use long double for the IEEE 128-bit base type if
long double is IEEE 128-bit, and it uses _Float128 otherwise. The built-in
functions are adjusted to be the correct version based on the IEEE 128-bit base
type used.
While it is desirable to ultimately have __float128 and _Float128 use the same
internal type and mode within GCC, at present if you use the option
-mabi=ieeelongdouble, the __float128 type will use the long double type and not
the _Float128 type. We get an internal compiler error if we combine the
signbitf128 built-in with a long double type.
I've gone through several iterations of trying to fix this within GCC, and
there are various problems that have come up. I developed this alternative
patch that changes libgcc so that it does not tickle the issue. I hope we can
fix the compiler at some point, but right now, this is preventing people on
Fedora 36 systems from building compilers where the default long double is IEEE
128-bit.
2023-03-06 Michael Meissner <meissner@linux.ibm.com>
libgcc/
PR target/107299
* config/rs6000/_divkc3.c (COPYSIGN): Use the correct built-in based on
whether long double is IBM or IEEE.
(INFINITY): Likewise.
(FABS): Likewise.
* config/rs6000/_mulkc3.c (COPYSIGN): Likewise.
(INFINITY): Likewise.
* config/rs6000/quad-float128.h (TF): Remove definition.
(TFtype): Define to be long double or _Float128.
(TCtype): Define to be _Complex long double or _Complex _Float128.
* libgcc2.h (TFtype): Allow machine config files to override this.
(TCtype): Likewise.
* soft-fp/quad.h (TFtype): Likewise.
amdgcn: Add instruction patterns for conditional min/max operations
gcc/ChangeLog:
* config/gcn/gcn-valu.md (<expander><mode>3_exec): Add patterns for
{s|u}{max|min} in QI, HI and DI modes.
(<expander><mode>3): Add pattern for {s|u}{max|min} in DI mode.
(cond_<fexpander><mode>): Add pattern for cond_f{max|min}.
(cond_<expander><mode>): Add pattern for cond_{s|u}{max|min}.
* config/gcn/gcn.cc (gcn_spill_class): Allow the exec register to be
saved in SGPRs.
gcc/testsuite/ChangeLog:
* gcc.target/gcn/cond_fmaxnm_1.c: New test.
* gcc.target/gcn/cond_fmaxnm_1_run.c: New test.
* gcc.target/gcn/cond_fmaxnm_2.c: New test.
* gcc.target/gcn/cond_fmaxnm_2_run.c: New test.
* gcc.target/gcn/cond_fmaxnm_3.c: New test.
* gcc.target/gcn/cond_fmaxnm_3_run.c: New test.
* gcc.target/gcn/cond_fmaxnm_4.c: New test.
* gcc.target/gcn/cond_fmaxnm_4_run.c: New test.
* gcc.target/gcn/cond_fmaxnm_5.c: New test.
* gcc.target/gcn/cond_fmaxnm_5_run.c: New test.
* gcc.target/gcn/cond_fmaxnm_6.c: New test.
* gcc.target/gcn/cond_fmaxnm_6_run.c: New test.
* gcc.target/gcn/cond_fmaxnm_7.c: New test.
* gcc.target/gcn/cond_fmaxnm_7_run.c: New test.
* gcc.target/gcn/cond_fmaxnm_8.c: New test.
* gcc.target/gcn/cond_fmaxnm_8_run.c: New test.
* gcc.target/gcn/cond_fminnm_1.c: New test.
* gcc.target/gcn/cond_fminnm_1_run.c: New test.
* gcc.target/gcn/cond_fminnm_2.c: New test.
* gcc.target/gcn/cond_fminnm_2_run.c: New test.
* gcc.target/gcn/cond_fminnm_3.c: New test.
* gcc.target/gcn/cond_fminnm_3_run.c: New test.
* gcc.target/gcn/cond_fminnm_4.c: New test.
* gcc.target/gcn/cond_fminnm_4_run.c: New test.
* gcc.target/gcn/cond_fminnm_5.c: New test.
* gcc.target/gcn/cond_fminnm_5_run.c: New test.
* gcc.target/gcn/cond_fminnm_6.c: New test.
* gcc.target/gcn/cond_fminnm_6_run.c: New test.
* gcc.target/gcn/cond_fminnm_7.c: New test.
* gcc.target/gcn/cond_fminnm_7_run.c: New test.
* gcc.target/gcn/cond_fminnm_8.c: New test.
* gcc.target/gcn/cond_fminnm_8_run.c: New test.
* gcc.target/gcn/cond_smax_1.c: New test.
* gcc.target/gcn/cond_smax_1_run.c: New test.
* gcc.target/gcn/cond_smin_1.c: New test.
* gcc.target/gcn/cond_smin_1_run.c: New test.
* gcc.target/gcn/cond_umax_1.c: New test.
* gcc.target/gcn/cond_umax_1_run.c: New test.
* gcc.target/gcn/cond_umin_1.c: New test.
* gcc.target/gcn/cond_umin_1_run.c: New test.
* gcc.target/gcn/smax_1.c: New test.
* gcc.target/gcn/smax_1_run.c: New test.
* gcc.target/gcn/smin_1.c: New test.
* gcc.target/gcn/smin_1_run.c: New test.
* gcc.target/gcn/umax_1.c: New test.
* gcc.target/gcn/umax_1_run.c: New test.
* gcc.target/gcn/umin_1.c: New test.
* gcc.target/gcn/umin_1_run.c: New test.
Javier Miranda [Mon, 6 Mar 2023 10:43:28 +0000 (11:43 +0100)]
Fix assertion failure on VSS library
gcc/ada/
PR ada/108858
* sem_ch6.adb (Analyze_Subprogram_Body_Helper): For functions with
separate spec, if their return type was visible through a limited-
with context clause, their extra formals were not added when the
spec was analyzed. Now the full view must be available, and the
extra formals can be created and Returns_By_Ref computed.
The following closes a gap in double reduction detection where we
in the outer loop analysis fail to verify the inner LC PHI use is
the latch definition of the inner loop PHI. That latch definition
is used to detect that an inner loop is part of a double reduction
when later doing the inner loop analysis.
PR tree-optimization/109025
* tree-vect-loop.cc (vect_is_simple_reduction): Verify
the inner LC PHI use is the inner loop PHI latch definition
before classifying an outer PHI as double reduction.
Xi Ruoyao [Fri, 3 Mar 2023 08:32:41 +0000 (16:32 +0800)]
LoongArch: testsuite: Disable stack protector for some tests
Stack protector will affect stack layout and break the expectation of
these tests, causing test failures if GCC is configured with
--enable-default-ssp.
Xi Ruoyao [Thu, 2 Mar 2023 10:05:23 +0000 (18:05 +0800)]
LoongArch: Stop -mfpu from silently breaking ABI [PR109000]
In the toolchain convention, we describe -mfpu= as:
"Selects the allowed set of basic floating-point instructions and
registers. This option should not change the FP calling convention
unless it's necessary."
Though not explicitly stated, the rationale of this rule is to allow
combinations like "-mabi=lp64s -mfpu=64". This will be useful for
running applications with LP64S/F ABI on a double-float-capable
LoongArch hardware and using a math library with LP64S/F ABI but native
double float HW instructions, for a better performance.
And now a case in Linux kernel has again proven the usefulness of this
kind of combination. The AMDGPU DCN kernel driver needs to perform some
floating-point operation, but the entire kernel uses LP64S ABI. So the
translation units of the AMDGPU DCN driver need to be compiled with
-mfpu=64 (the kernel lacks soft-FP routines in libgcc), but -mabi=lp64s
(or you can't link it with the other part of the kernel).
Unfortunately, currently GCC uses TARGET_{HARD,SOFT,DOUBLE}_FLOAT to
determine the floating calling convention. This causes "-mfpu=64"
silently allow using $fa* to pass parameters and return values EVEN IF
-mabi=lp64s is used. To make things worse, the generated object file
has SOFT-FLOAT set in the eflags field so the linker will happily link
it with other LP64S ABI object files, but obviously this will lead to
bad results at runtime. And for now all loongarch64 CPU models (-march
settings) implies -mfpu=64 on by default, so the issue makes a single
"-mabi=lp64s" option basically broken (fortunately most projects for eg
the Linux kernel have used -msoft-float which implies both -mabi=lp64s
and -mfpu=none as we've recommended in the toolchain convention doc).
The fix is simple: use TARGET_*_FLOAT_ABI instead.
I consider this a bug fix: the behavior difference from the toolchain
convention doc is a bug, and generating object files with SOFT-FLOAT
flag but parameters/return values passed through FPRs is definitely a
bug.
Bootstrapped and regtested on loongarch64-linux-gnu. Ok for trunk and
release/gcc-12 branch?
gcc/ChangeLog:
PR target/109000
* config/loongarch/loongarch.h (FP_RETURN): Use
TARGET_*_FLOAT_ABI instead of TARGET_*_FLOAT.
(UNITS_PER_FP_ARG): Likewise.
gcc/testsuite/ChangeLog:
PR target/109000
* gcc.target/loongarch/flt-abi-isa-1.c: New test.
* gcc.target/loongarch/flt-abi-isa-2.c: New test.
* gcc.target/loongarch/flt-abi-isa-3.c: New test.
* gcc.target/loongarch/flt-abi-isa-4.c: New test.
Harald Anlauf [Thu, 2 Mar 2023 21:37:14 +0000 (22:37 +0100)]
Fortran: fix CLASS attribute handling [PR106856]
gcc/fortran/ChangeLog:
PR fortran/106856
* class.cc (gfc_build_class_symbol): Handle update of attributes of
existing class container.
(gfc_find_derived_vtab): Fix several memory leaks.
(find_intrinsic_vtab): Ditto.
* decl.cc (attr_decl1): Manage update of symbol attributes from
CLASS attributes.
* primary.cc (gfc_variable_attr): OPTIONAL shall not be taken or
updated from the class container.
* symbol.cc (free_old_symbol): Adjust management of symbol versions
to not prematurely free array specs while working on the declation
of CLASS variables.
gcc/testsuite/ChangeLog:
PR fortran/106856
* gfortran.dg/interface_41.f90: Remove dg-pattern from valid testcase.
* gfortran.dg/class_74.f90: New test.
* gfortran.dg/class_75.f90: New test.
* gcc.target/riscv/zksed32.c: New test.
* gcc.target/riscv/zksed64.c: New test.
* gcc.target/riscv/zksh32.c: New test.
* gcc.target/riscv/zksh64.c: New test.
* gcc.target/riscv/zknd32.c: New test.
* gcc.target/riscv/zknd64.c: New test.
* gcc.target/riscv/zkne32.c: New test.
* gcc.target/riscv/zkne64.c: New test.
Liao Shihua [Mon, 20 Feb 2023 07:01:22 +0000 (15:01 +0800)]
RISC-V: Implement ZBKB, ZBKC and ZBKX extensions
This patch supports Zkbk, Zbkc and Zkbx extension.
It includes instruction's machine description and built-in funtions.
It is worth mentioning that this patch only adds instructions in Zbkb but no
longer in Zbb.
If any instructions both in Zbb and Zbkb, they will be generated by code
generator instead of built-in functions.
gcc/ChangeLog:
* config/riscv/bitmanip.md: Add ZBKB's instructions.
* config/riscv/riscv-builtins.cc (AVAIL): Add new.
* config/riscv/riscv.md: Add new type for crypto instructions.
* config/riscv/crypto.md: Add Scalar Cryptography extension's machine
description file.
* config/riscv/riscv-scalar-crypto.def: Add Scalar Cryptography
extension's built-in function file.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zbkb32.c: New test.
* gcc.target/riscv/zbkb64.c: New test.
* gcc.target/riscv/zbkc32.c: New test.
* gcc.target/riscv/zbkc64.c: New test.
* gcc.target/riscv/zbkx32.c: New test.
* gcc.target/riscv/zbkx64.c: New test.
This showed up as dynamic icount regression in SPEC 531.deepsjeng with upstream
gcc (vs. gcc 12.2). gcc was resorting to synthetic multiply using shift+add(s)
even when multiply had clear cost benefit.
Bisected this to f90cb39235c4 ("RISC-V: costs: support shift-and-add in
strength-reduction"). The intent was to optimize cost for
shift-add-pow2-{1,2,3} corresponding to bitmanip insns SH*ADD, but ended
up doing that for all shift values which seems to favor synthezing
multiply among others.
The bug itself is trivial, IN_RANGE() calling pow2p_hwi() which returns bool
vs. exact_log2() returning power of 2.
This fix also requires update to the test introduced by the same commit
which now generates MUL vs. synthesizing it.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_rtx_costs): Fixed IN_RANGE() to
use exact_log2().
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zba-shNadd-07.c: f2(i*783) now generates MUL vs.
5 insn sh1add+slli+add+slli+sub.
* gcc.target/riscv/pr108987.c: New test.
Signed-off-by: Vineet Gupta <vineetg@rivosinc.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
* gcc.target/riscv/rvv/base/binop_vx_constraint-167.c: New test.
* gcc.target/riscv/rvv/base/binop_vx_constraint-168.c: New test.
* gcc.target/riscv/rvv/base/binop_vx_constraint-169.c: New test.
* gcc.target/riscv/rvv/base/binop_vx_constraint-170.c: New test.
* gcc.target/riscv/rvv/base/binop_vx_constraint-171.c: New test.
* gcc.target/riscv/rvv/base/binop_vx_constraint-172.c: New test.
* gcc.target/riscv/rvv/base/binop_vx_constraint-173.c: New test.
* gcc.target/riscv/rvv/base/binop_vx_constraint-174.c: New test.
Ju-Zhe Zhong [Fri, 24 Feb 2023 15:19:14 +0000 (23:19 +0800)]
RISC-V: Add testcase for VSETVL PASS
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/scalar_move-1.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-2.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-3.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-4.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-5.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-6.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-7.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-8.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-100.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-101.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-78.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-79.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-80.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-81.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-82.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-83.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-84.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-85.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-86.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-87.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-88.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-89.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-90.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-91.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-92.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-93.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-94.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-95.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-96.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-97.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-98.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-99.c: New test.
Gaius Mulley [Sat, 4 Mar 2023 13:11:05 +0000 (13:11 +0000)]
Fix modula-2 rename autogenerated .c files to .cc
This patch adds the replacement .cc files for the
autogenerated tools.
gcc/m2/ChangeLog:
* mc-boot-ch/GBuiltins.cc: New file.
* mc-boot-ch/Gdtoa.cc: New file.
* mc-boot-ch/Gerrno.cc: New file.
* mc-boot-ch/Gldtoa.cc: New file.
* mc-boot-ch/Gm2rtsdummy.cc: New file.
* mc-boot/GASCII.cc: New file.
* mc-boot/GArgs.cc: New file.
* mc-boot/GAssertion.cc: New file.
* mc-boot/GBreak.cc: New file.
* mc-boot/GCmdArgs.cc: New file.
* mc-boot/GDebug.cc: New file.
* mc-boot/GDynamicStrings.cc: New file.
* mc-boot/GEnvironment.cc: New file.
* mc-boot/GFIO.cc: New file.
* mc-boot/GFormatStrings.cc: New file.
* mc-boot/GFpuIO.cc: New file.
* mc-boot/GIO.cc: New file.
* mc-boot/GIndexing.cc: New file.
* mc-boot/GM2Dependent.cc: New file.
* mc-boot/GM2EXCEPTION.cc: New file.
* mc-boot/GM2RTS.cc: New file.
* mc-boot/GMemUtils.cc: New file.
* mc-boot/GNumberIO.cc: New file.
* mc-boot/GPushBackInput.cc: New file.
* mc-boot/GRTExceptions.cc: New file.
* mc-boot/GRTint.cc: New file.
* mc-boot/GSArgs.cc: New file.
* mc-boot/GSFIO.cc: New file.
* mc-boot/GStdIO.cc: New file.
* mc-boot/GStorage.cc: New file.
* mc-boot/GStrCase.cc: New file.
* mc-boot/GStrIO.cc: New file.
* mc-boot/GStrLib.cc: New file.
* mc-boot/GStringConvert.cc: New file.
* mc-boot/GSysStorage.cc: New file.
* mc-boot/GTimeString.cc: New file.
* mc-boot/Galists.cc: New file.
* mc-boot/Gdecl.cc: New file.
* mc-boot/Gkeyc.cc: New file.
* mc-boot/Glists.cc: New file.
* mc-boot/GmcComment.cc: New file.
* mc-boot/GmcComp.cc: New file.
* mc-boot/GmcDebug.cc: New file.
* mc-boot/GmcError.cc: New file.
* mc-boot/GmcFileName.cc: New file.
* mc-boot/GmcLexBuf.cc: New file.
* mc-boot/GmcMetaError.cc: New file.
* mc-boot/GmcOptions.cc: New file.
* mc-boot/GmcPreprocess.cc: New file.
* mc-boot/GmcPretty.cc: New file.
* mc-boot/GmcPrintf.cc: New file.
* mc-boot/GmcQuiet.cc: New file.
* mc-boot/GmcReserved.cc: New file.
* mc-boot/GmcSearch.cc: New file.
* mc-boot/GmcStack.cc: New file.
* mc-boot/GmcStream.cc: New file.
* mc-boot/Gmcp1.cc: New file.
* mc-boot/Gmcp2.cc: New file.
* mc-boot/Gmcp3.cc: New file.
* mc-boot/Gmcp4.cc: New file.
* mc-boot/Gmcp5.cc: New file.
* mc-boot/GnameKey.cc: New file.
* mc-boot/GsymbolKey.cc: New file.
* mc-boot/Gtop.cc: New file.
* mc-boot/Gvarargs.cc: New file.
* mc-boot/Gwlists.cc: New file.
* pge-boot/GASCII.cc: New file.
* pge-boot/GArgs.cc: New file.
* pge-boot/GAssertion.cc: New file.
* pge-boot/GBuiltins.cc: New file.
* pge-boot/GDebug.cc: New file.
* pge-boot/GDynamicStrings.cc: New file.
* pge-boot/GFIO.cc: New file.
* pge-boot/GIO.cc: New file.
* pge-boot/GIndexing.cc: New file.
* pge-boot/GLists.cc: New file.
* pge-boot/GM2Dependent.cc: New file.
* pge-boot/GM2EXCEPTION.cc: New file.
* pge-boot/GM2LINK.cc: New file.
* pge-boot/GM2RTS.cc: New file.
* pge-boot/GNameKey.cc: New file.
* pge-boot/GNumberIO.cc: New file.
* pge-boot/GOutput.cc: New file.
* pge-boot/GPushBackInput.cc: New file.
* pge-boot/GRTExceptions.cc: New file.
* pge-boot/GRTco.cc: New file.
* pge-boot/GSFIO.cc: New file.
* pge-boot/GSYSTEM.cc: New file.
* pge-boot/GSelective.cc: New file.
* pge-boot/GStdIO.cc: New file.
* pge-boot/GStorage.cc: New file.
* pge-boot/GStrCase.cc: New file.
* pge-boot/GStrIO.cc: New file.
* pge-boot/GStrLib.cc: New file.
* pge-boot/GSymbolKey.cc: New file.
* pge-boot/GSysExceptions.cc: New file.
* pge-boot/GSysStorage.cc: New file.
* pge-boot/Gabort.cc: New file.
* pge-boot/Gbnflex.cc: New file.
* pge-boot/Gcbuiltin.cc: New file.
* pge-boot/Gdtoa.cc: New file.
* pge-boot/Gerrno.cc: New file.
* pge-boot/Gldtoa.cc: New file.
* pge-boot/Glibc.cc: New file.
* pge-boot/Glibm.cc: New file.
* pge-boot/Gmcrts.cc: New file.
* pge-boot/Gpge.cc: New file.
* pge-boot/Gwrapc.cc: New file.
* pge-boot/main.cc: New file.
* pge-boot/network.cc: New file.
Gaius Mulley [Sat, 4 Mar 2023 12:44:49 +0000 (12:44 +0000)]
Modula-2 rename autogenerated .c files to .cc
This patch renames all the pge-boot/*.c files to .cc. It also renames
the m2/mc-boot/*.c files to .cc. Finally it renames some of the
mc-boot-ch hand built interface files to .cc.
gcc/m2/ChangeLog:
* Make-lang.in (MC-LIB-BOOT-C): Rename to MC-LIB-BOOT-CC.
(MC-BOOT-C): Rename to MC-BOOT-CC.
(BUILD-MC-BOOT-C): Rename to BUILD-MC-BOOT-CC.
(BUILD-MC-BOOT-AUTO-C): Rename to BUILD-MC-BOOT-AUTO-CC.
(m2/mc-boot/$(SRC_PREFIX)%.o): Change source file extension to .cc.
(m2/mc-boot-ch/$(SRC_PREFIX)%.o): Ditto.
* Make-maintainer.in (m2/gm2-ppg-boot/$(SRC_PREFIX)%.o): Change
source file extension to .cc.
(m2/gm2-ppg-boot/main.o): Ditto.
(m2/gm2-ppg-boot/$(SRC_PREFIX)%.o): Ditto.
to .cc.
(m2/gm2-pg-boot/main.o): Ditto.
(m2/gm2-pge-boot/$(SRC_PREFIX)ldtoa.o): Ditto.
(m2/gm2-pge-boot/$(SRC_PREFIX)dtoa.o): Ditto.
(m2/gm2-pge-boot/$(SRC_PREFIX)errno.o): Ditto.
(m2/gm2-pge-boot/$(SRC_PREFIX)M2RTS.o): Ditto.
(m2/gm2-pge-boot/$(SRC_PREFIX)%.o): Ditto.
(m2/gm2-pge-boot/$(SRC_PREFIX)%.o): Ditto.
(m2/gm2-pge-boot/$(SRC_PREFIX)pge.o): Ditto.
(m2/gm2-pge-boot/main.o): Ditto.
(mc-push): Ditto.
(mc-clean): Ditto.
(mc-stage2): Ditto.
((objdir)/m2/mc-boot-gen): Ditto.
(m2/mc-boot-gen/$(SRC_PREFIX)decl.c): Ditto.
(m2/mc-boot-gen/$(SRC_PREFIX)%.c): Ditto.
* mc-boot-ch/GBuiltins.c: Correct comment and rename.
* mc-boot-ch/Gdtoa.c: Correct comment and rename.
* mc-boot-ch/Gldtoa.c: Correct comment and rename
* mc-boot-ch/Gtermios.cc: Rename from Gtermios.c.
* mc-boot-ch/Gerrno.c: Rename.
* mc-boot-ch/GRTco.c: Removed.
* mc-boot/GASCII.c: Rename to mc-boot/GASCII.cc.
* mc-boot/GArgs.c: Rename to mc-boot/GArgs.cc.
* mc-boot/GAssertion.c: Rename to mc-boot/GAssertion.cc.
* mc-boot/GBreak.c: Rename to mc-boot/GBreak.cc.
* mc-boot/GCmdArgs.c: Rename to mc-boot/GCmdArgs.cc.
* mc-boot/GDebug.c: Rename to mc-boot/GDebug.cc.
* mc-boot/GDynamicStrings.c: Rename to mc-boot/GDynamicStrings.cc.
* mc-boot/GEnvironment.c: Rename to mc-boot/GEnvironment.cc.
* mc-boot/GFIO.c: Rename to mc-boot/GFIO.cc.
* mc-boot/GFormatStrings.c: Rename to mc-boot/GFormatStrings.cc.
* mc-boot/GFpuIO.c: Rename to mc-boot/GFpuIO.cc.
* mc-boot/GIO.c: Rename to mc-boot/GIO.cc.
* mc-boot/GIndexing.c: Rename to mc-boot/GIndexing.cc.
* mc-boot/GM2Dependent.c: Rename to mc-boot/GM2Dependent.cc.
* mc-boot/GM2EXCEPTION.c: Rename to mc-boot/GM2EXCEPTION.cc.
* mc-boot/GM2RTS.c: Rename to mc-boot/GM2RTS.cc.
* mc-boot/GMemUtils.c: Rename to mc-boot/GMemUtils.cc.
* mc-boot/GNumberIO.c: Rename to mc-boot/GNumberIO.cc.
* mc-boot/GPushBackInput.c: Rename to mc-boot/GPushBackInput.cc.
* mc-boot/GRTExceptions.c: Rename to mc-boot/GRTExceptions.cc.
* mc-boot/GRTint.c: Rename to mc-boot/GRTint.cc.
* mc-boot/GSArgs.c: Rename to mc-boot/GSArgs.cc.
* mc-boot/GSFIO.c: Rename to mc-boot/GSFIO.cc.
* mc-boot/GStdIO.c: Rename to mc-boot/GStdIO.cc.
* mc-boot/GStorage.c: Rename to mc-boot/GStorage.cc.
* mc-boot/GStrCase.c: Rename to mc-boot/GStrCase.cc.
* mc-boot/GStrIO.c: Rename to mc-boot/GStrIO.cc.
* mc-boot/GStrLib.c: Rename to mc-boot/GStrLib.cc.
* mc-boot/GStringConvert.c: Rename to mc-boot/GStringConvert.cc.
* mc-boot/GSysStorage.c: Rename to mc-boot/GSysStorage.cc.
* mc-boot/GTimeString.c: Rename to mc-boot/GTimeString.cc.
* mc-boot/Galists.c: Rename to mc-boot/Galists.cc.
* mc-boot/Gdecl.c: Rename to mc-boot/Gdecl.cc.
* mc-boot/Gkeyc.c: Rename to mc-boot/Gkeyc.cc.
* mc-boot/Glists.c: Rename to mc-boot/Glists.cc.
* mc-boot/GmcComment.c: Rename to mc-boot/GmcComment.cc.
* mc-boot/GmcComp.c: Rename to mc-boot/GmcComp.cc.
* mc-boot/GmcDebug.c: Rename to mc-boot/GmcDebug.cc.
* mc-boot/GmcError.c: Rename to mc-boot/GmcError.cc.
* mc-boot/GmcFileName.c: Rename to mc-boot/GmcFileName.cc.
* mc-boot/GmcLexBuf.c: Rename to mc-boot/GmcLexBuf.cc.
* mc-boot/GmcMetaError.c: Rename to mc-boot/GmcMetaError.cc.
* mc-boot/GmcOptions.c: Rename to mc-boot/GmcOptions.cc.
* mc-boot/GmcPreprocess.c: Rename to mc-boot/GmcPreprocess.cc.
* mc-boot/GmcPretty.c: Rename to mc-boot/GmcPretty.cc.
* mc-boot/GmcPrintf.c: Rename to mc-boot/GmcPrintf.cc.
* mc-boot/GmcQuiet.c: Rename to mc-boot/GmcQuiet.cc.
* mc-boot/GmcReserved.c: Rename to mc-boot/GmcReserved.cc.
* mc-boot/GmcSearch.c: Rename to mc-boot/GmcSearch.cc.
* mc-boot/GmcStack.c: Rename to mc-boot/GmcStack.cc.
* mc-boot/GmcStream.c: Rename to mc-boot/GmcStream.cc.
* mc-boot/Gmcp1.c: Rename to mc-boot/Gmcp1.cc.
* mc-boot/Gmcp2.c: Rename to mc-boot/Gmcp2.cc.
* mc-boot/Gmcp3.c: Rename to mc-boot/Gmcp3.cc.
* mc-boot/Gmcp4.c: Rename to mc-boot/Gmcp4.cc.
* mc-boot/Gmcp5.c: Rename to mc-boot/Gmcp5.cc.
* mc-boot/GnameKey.c: Rename to mc-boot/GnameKey.cc.
* mc-boot/GsymbolKey.c: Rename to mc-boot/GsymbolKey.cc.
* mc-boot/Gtop.c: Rename to mc-boot/Gtop.cc.
* mc-boot/Gvarargs.c: Rename to mc-boot/Gvarargs.cc.
* mc-boot/Gwlists.c: Rename to mc-boot/Gwlists.cc.
* pge-boot/GASCII.c: Rename to pge-boot/GASCII.cc.
* pge-boot/GArgs.c: Rename to pge-boot/GArgs.cc.
* pge-boot/GAssertion.c: Rename to pge-boot/GAssertion.cc.
* pge-boot/GBuiltins.c: Rename to pge-boot/GBuiltins.cc.
* pge-boot/GDebug.c: Rename to pge-boot/GDebug.cc.
* pge-boot/GDynamicStrings.c: Rename to pge-boot/GDynamicStrings.cc.
* pge-boot/GFIO.c: Rename to pge-boot/GFIO.cc.
* pge-boot/GIO.c: Rename to pge-boot/GIO.cc.
* pge-boot/GIndexing.c: Rename to pge-boot/GIndexing.cc.
* pge-boot/GLists.c: Rename to pge-boot/GLists.cc.
* pge-boot/GM2Dependent.c: Rename to pge-boot/GM2Dependent.cc.
* pge-boot/GM2EXCEPTION.c: Rename to pge-boot/GM2EXCEPTION.cc.
* pge-boot/GM2LINK.c: Rename to pge-boot/GM2LINK.cc.
* pge-boot/GM2RTS.c: Rename to pge-boot/GM2RTS.cc.
* pge-boot/GNameKey.c: Rename to pge-boot/GNameKey.cc.
* pge-boot/GNumberIO.c: Rename to pge-boot/GNumberIO.cc.
* pge-boot/GOutput.c: Rename to pge-boot/GOutput.cc.
* pge-boot/GPushBackInput.c: Rename to pge-boot/GPushBackInput.cc.
* pge-boot/GRTExceptions.c: Rename to pge-boot/GRTExceptions.cc.
* pge-boot/GRTco.c: Rename to pge-boot/GRTco.cc.
* pge-boot/GSFIO.c: Rename to pge-boot/GSFIO.cc.
* pge-boot/GSYSTEM.c: Rename to pge-boot/GSYSTEM.cc.
* pge-boot/GSelective.c: Rename to pge-boot/GSelective.cc.
* pge-boot/GStdIO.c: Rename to pge-boot/GStdIO.cc.
* pge-boot/GStorage.c: Rename to pge-boot/GStorage.cc.
* pge-boot/GStrCase.c: Rename to pge-boot/GStrCase.cc.
* pge-boot/GStrIO.c: Rename to pge-boot/GStrIO.cc.
* pge-boot/GStrLib.c: Rename to pge-boot/GStrLib.cc.
* pge-boot/GSymbolKey.c: Rename to pge-boot/GSymbolKey.cc.
* pge-boot/GSysExceptions.c: Rename to pge-boot/GSysExceptions.cc.
* pge-boot/GSysStorage.c: Rename to pge-boot/GSysStorage.cc.
* pge-boot/Gabort.c: Rename to pge-boot/Gabort.cc.
* pge-boot/Gbnflex.c: Rename to pge-boot/Gbnflex.cc.
* pge-boot/Gcbuiltin.c: Rename to pge-boot/Gcbuiltin.cc.
* pge-boot/Gdtoa.c: Rename to pge-boot/Gdtoa.cc.
* pge-boot/Gerrno.c: Rename to pge-boot/Gerrno.cc.
* pge-boot/Gldtoa.c: Rename to pge-boot/Gldtoa.cc.
* pge-boot/Glibc.c: Rename to pge-boot/Glibc.cc.
* pge-boot/Glibm.c: Rename to pge-boot/Glibm.cc.
* pge-boot/Gmcrts.c: Rename to pge-boot/Gmcrts.cc.
* pge-boot/Gpge.c: Rename to pge-boot/Gpge.cc.
* pge-boot/Gwrapc.c: Rename to pge-boot/Gwrapc.cc.
* pge-boot/README: Correct description.
* pge-boot/main.c: Rename to pge-boot/main.cc.
* pge-boot/network.c: Rename to pge-boot/network.cc.
Jakub Jelinek [Sat, 4 Mar 2023 09:42:17 +0000 (10:42 +0100)]
testsuite: Fix up syntax errors in scan-tree-dump-times target selectors
On Thu, Mar 02, 2023 at 07:23:32PM +0100, Robin Dapp via Gcc-patches wrote:
> this patch changes SLP test expectations. As we only vectorize when no
> more than one rgroup is present, no vectorization is performed.
Jakub Jelinek [Sat, 4 Mar 2023 09:21:45 +0000 (10:21 +0100)]
c-family: Incremental fix for -Wsign-compare BIT_NOT_EXPR handling [PR107465]
There can be too many extensions and seems I didn't get everything right in
the previously posted patch.
The following incremental patch ought to fix that.
The code can deal with quite a few sign/zero extensions at various spots
and it is important to deal with all of them right.
On the argument that contains BIT_NOT_EXPR we have:
MSB bits#4 bits#3 BIT_NOT_EXPR bits#2 bits#1 LSB
where bits#1 is one or more bits (TYPE_PRECISION (TREE_TYPE (arg0))
at the end of the function) we don't know anything about, for the purposes
of this warning it is VARYING that is inverted with BIT_NOT_EXPR to some other
VARYING bits;
bits#2 is one or more bits (TYPE_PRECISION (TREE_TYPE (op0)) -
TYPE_PRECISION (TREE_TYPE (arg0)) at the end of the function)
which are known to be 0 before the BIT_NOT_EXPR and 1 after it.
bits#3 is zero or more bits from the TYPE_PRECISION (TREE_TYPE (op0))
at the end of function to the TYPE_PRECISION (TREE_TYPE (op0)) at the
end of the function to TYPE_PRECISION (TREE_TYPE (op0)) at the start
of the function, which are either zero extension or sign extension.
And bits#4 is zero or more bits from the TYPE_PRECISION (TREE_TYPE (op0))
at the start of the function to TYPE_PRECISION (result_type), which
again can be zero or sign extension.
Now, vanilla trunk as well as the previously posted patch mishandles the
case where bits#3 are sign extended (as bits#2 are known to be all set,
that means bits#3 are all set too) but bits#4 are zero extended and are
thus all 0.
The patch fixes it by tracking the lowest bit which is known to be clear
above the known to be set bits (if any, otherwise it is precision of
result_type).
2023-03-04 Jakub Jelinek <jakub@redhat.com>
PR c/107465
* c-warn.cc (warn_for_sign_compare): Don't warn for unset bits
above innermost zero extension of BIT_NOT_EXPR result.
Jakub Jelinek [Sat, 4 Mar 2023 09:18:37 +0000 (10:18 +0100)]
c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling [PR107465]
The following patch fixes multiple bugs in warn_for_sign_compare related to
the BIT_NOT_EXPR related warnings.
My understanding is that what those 3 warnings are meant to warn (since 1995
apparently) is the case where we have BIT_NOT_EXPR of a zero-extended
value, so in result_type the value is something like:
0b11111111XXXXXXXX (e.g. ~ of a 8->16 bit zero extension)
0b000000000000000011111111XXXXXXXX (e.g. ~ of a 8->16 bit zero extension
then zero extended to 32 bits)
0b111111111111111111111111XXXXXXXX (e.g. ~ of a 8->16 bit zero extension
then sign extended to 32 bits)
and the intention of the warning is to warn when this is compared against
something that has some 0 bits at the place where the above has guaranteed
1 bits, either ensured through comparison against constant where we know
the bits exactly, or through zero extension from some narrower type where
again we know at least some upper bits are zero extended.
The bugs in the warning code are:
1) misunderstanding of the {,c_common_}get_narrower APIs - the unsignedp
it sets is only meaningful if the function actually returns something
narrower (in that case it says whether the narrower value is then
sign (0) or zero (1) extended to the originally passed value.
Though op0 or op1 at this point might be already narrower than
result_type, and if the function doesn't return anything narrower,
it all depends on whether the passed in op{0,1} had TYPE_UNSIGNED
type or not
2) the code didn't check at all whether the BIT_NOT_EXPR operand
was actually zero extended (i.e. that it was narrower and unsignedp
was set to 1 for it), all it did is check that unsignedp from the
call was 1. But that isn't well defined thing, if the argument
is returned as is, the function sets unsignedp to 0, but if there
is e.g. a useless cast to the same or compatible type in between,
it can return 1 if the cast is unsigned; now, if BIT_NOT_EXPR
operand is not zero extended, we know nothing at all about any bits
in the operand containing BIT_NOT_EXPR, so there is nothing to warn
about
3) the code was actually testing both operands after calling
c_common_get_narrower on them and on the one with BIT_NOT_EXPR
again for constants; I think that is just wrong in case the BIT_NOT_EXPR
operand wouldn't be fully folded, the warning makes sense only if the
other operand not having BIT_NOT_EXPR in it is constant
4) as can be seen from the above bit pattern examples, the upper bits above
(in the patch arg0) aren't always all 1s, there could be some zero extension
above it and from it one would have 0s, so that needs to be taken into
account for the choice which constant bits to test for being always set
otherwise warning is emitted, or for the zero extension guaranteed zero
bits
5) the patch also simplifies the handling, we only do it if one but not
both operands are BIT_NOT_EXPR after first {,c_common_}get_narrower,
so we can just use std::swap to ensure it is the first one
6) the code compared bits against HOST_BITS_PER_LONG, which made sense
back in 1995 when the values were stored into long, but now that they
are HOST_WIDE_INT should test HOST_BITS_PER_WIDE_INT (or we could rewrite
the stuff to wide_int, not done in the patch)
2023-03-04 Jakub Jelinek <jakub@redhat.com>
PR c/107465
* c-warn.cc (warn_for_sign_compare): If c_common_get_narrower
doesn't return a narrower result, use TYPE_UNSIGNED to set unsignedp0
and unsignedp1. For the one BIT_NOT_EXPR case vs. one without,
only check for constant in the non-BIT_NOT_EXPR operand, use std::swap
to simplify the code, only warn if BIT_NOT_EXPR operand is extended
from narrower unsigned, fix up computation of mask for the constant
cases and for unsigned other operand case handle differently
BIT_NOT_EXPR result being sign vs. zero extended.
* c-c++-common/Wsign-compare-2.c: New test.
* c-c++-common/pr107465.c: New test.
Jakub Jelinek [Sat, 4 Mar 2023 09:14:33 +0000 (10:14 +0100)]
c-family: Account for integral promotions of left shifts for -Wshift-overflow warning [PR107846]
The r13-1100-gacb1e6f43dc2bbedd124 change added match.pd narrowing
of left shifts, and while I believe the C++ FE calls the warning on unfolded
trees, the C FE folds them and so left shifts where integral promotion
happened and so were done in int type will be usually narrowed back to
char/signed char/unsigned char/short/unsigned short left shifts if the
shift count is constant and fits into the precision of the var being
shifted.
One possibility would be to restrict the match.pd optimization to GIMPLE
only, another don't fold in C FE before this warning (well, we need to
fold the shift count operand to constant if possible), the following patch
just takes integral promotion into account in the warning code.
2023-03-04 Jakub Jelinek <jakub@redhat.com>
PR c/107846
* c-warn.cc: Include langhooks.h.
(maybe_warn_shift_overflow): Set type0 to what TREE_TYPE (op0)
promotes to rather than TREE_TYPE (op0) itself, if TREE_TYPE (op0)
is narrower than type0 and unsigned, use wi::min_precision with
UNSIGNED and fold_convert op0 to type0 before emitting the warning.
Jakub Jelinek [Sat, 4 Mar 2023 08:51:31 +0000 (09:51 +0100)]
c++: Don't defer local statics initialized with constant expressions [PR108702]
The stmtexpr19.C testcase used to be rejected as it has a static
variable in statement expression in constexpr context, but as that
static variable is initialized by constant expression, when P2647R1
was implemented we agreed to make it valid.
Now, as reported, the testcase compiles fine, but doesn't actually link
because the static variable isn't defined anywhere, and with -flto ICEs
because of this problem. This is because we never
varpool_node::finalize_decl those vars, the constant expression in which
the DECL_EXPR is present for the static VAR_DECL is folded (constant
evaluated) into just the address of the VAR_DECL.
Now, similar testcase included below (do we want to include it in the
testsuite too?) works fine, because in
cp_finish_decl -> make_rtl_for_nonlocal_decl
we have since PR70353 fix:
/* We defer emission of local statics until the corresponding
DECL_EXPR is expanded. But with constexpr its function might never
be expanded, so go ahead and tell cgraph about the variable now. */
defer_p = ((DECL_FUNCTION_SCOPE_P (decl)
&& !var_in_maybe_constexpr_fn (decl))
|| DECL_VIRTUAL_P (decl));
and so don't defer them in constexpr/consteval functions. The following
patch calls rest_of_decl_compilation which make_rtl_for_nonlocal_decl didn't
call when encountering DECL_EXPRs of such vars during constant evaluation
if they weren't finalized yet.
2023-03-04 Jakub Jelinek <jakub@redhat.com>
PR c++/108702
* constexpr.cc: Include toplev.h.
(cxx_eval_constant_expression) <case DECL_EXPR>: When seeing a local
static initialized by constant expression outside of a constexpr
function which has been deferred by make_rtl_for_nonlocal_decl,
call rest_of_decl_compilation on it.
* g++.dg/ext/stmtexpr19.C: Use dg-do link rather than dg-do compile.
Jakub Jelinek [Sat, 4 Mar 2023 08:48:17 +0000 (09:48 +0100)]
diagnostics: Fix up selftests with $COLUMNS < 42 [PR108973]
As mentioned in the PR, GCC's diagnostics self-tests fail if $COLUMNS < 42.
Guarding each self-test with if (get_terminal_width () > 41) or similar
would be a maintainance nightmare (PR has a patch to do so without
reformatting to make it work for $COLUMNS in [30, 41] inclusive, but
I'm afraid going down to $COLUMNS 1 would mean marking everything).
Furthermore, the self-tests don't really emit stuff to the terminal,
but into a buffer, so using get_terminal_width () for it seems
inappropriate. The following patch makes sure test_diagnostic_context
constructor uses exactly 80 columns wide caret max width, of course
some tests override it already if they want to test for behavior in narrower
cases.
2023-03-04 Jakub Jelinek <jakub@redhat.com>
PR testsuite/108973
* selftest-diagnostic.cc
(test_diagnostic_context::test_diagnostic_context): Set
caret_max_width to 80.
CRIS defines DATA_ALIGNMENT such that alignment can be
applied differently to different data of the same type, when
"references to it must bind to the current definition"
(varasm.cc:align_variable). Here, it means that more
alignment is then applied to g, but not f, so the test-case
fails because another message is emitted than the expected:
a same-alignment test dominates the not-discardable test,
and we get "Not unifying; original and alias have
incompatible alignments" rather than "Not unifying; alias
cannot be created; target is discardable". Because this
DATA_ALIGNMENT behavior for CRIS depends on target options,
and this test is already artificial by the use of -fcommon,
better skip it.
David Malcolm [Fri, 3 Mar 2023 22:59:21 +0000 (17:59 -0500)]
analyzer: provide placeholder implementation of sprintf
Previously, the analyzer lacked a known_function implementation of
sprintf, and thus would handle calls to sprintf with the "anything could
happen" fallback.
Whilst working on PR analyzer/107565 I noticed that this was preventing
a lot of genuine memory leaks from being reported for Doom; fixing
thusly.
Integration testing of the effect of the patch shows a big increase in
true positives due to the case mentioned in Doom, and one new false
positive (in pcre2), which I'm tracking as PR analyzer/109014.
gcc/analyzer/ChangeLog:
* kf.cc (class kf_sprintf): New.
(register_known_functions): Register it.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/doom-d_main-IdentifyVersion.c: New test.
* gcc.dg/analyzer/sprintf-1.c: New test.
* gcc.dg/analyzer/sprintf-concat.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Alexandre Oliva [Thu, 5 May 2022 02:41:38 +0000 (23:41 -0300)]
libstdc++: testsuite: async.cc early timeout
The async call and future variable initialization may take a while to
complete on uniprocessors, especially if the async call and other
unrelated processes run before context switches back to the main
thread.
Taking steady_begin only then sometimes causes the 11*100ms in the
slow clock, counted from before the async call, to not be enough for
the measured wait to last 1s in the steady clock. I've seen it fall
short of 1s by as little as a third of a tenth of a second in some
cases, but in one surprisingly extreme case the elapsed wait time got
only up to 216.7ms.
Initializing both timestamps next to each other, before the async
call, appears to avoid the problem entirely. I've renamed the
variable moved out of the block so as to avoid name hiding in the
subsequent block, that has another steady_begin variable.
The second wait fails a lot less frequently, but the 2s limit has been
exceeded, so I'm bumping up the max sleep to ~4s, and the tolerance to
3s.
for libstdc++-v3/ChangeLog
* testsuite/30_threads/async/async.cc (test04): Initialize
steady_start, renamed from steady_begin, next to slow_start.
Increase tolerance for final wait.
Alexandre Oliva [Fri, 3 Mar 2023 18:59:33 +0000 (15:59 -0300)]
[libstdc++] [prettyprint] add local std::string use to more tests
We're getting regressions after ugprading to GDB 13 in a few of the
libstdc++ pretty-printing tests. It might seem like a GDB regression,
but that update has a new symbol reader, and Tom Tromey says it
exposes a latent problem in the pretty-printer, namely, when a name is
not defined locally in the local translation unit, GDB will look for
it in other units, and if multiple different definitions are
available, there are no guarantees as to which one it will find.
Since libstdc++ contains units in which std::string maps to different
types, in order to ensure the tests get the std::string definition we
expect, we need std::string to be present in the debug information for
the test itself, as we already do in other tests.
for libstdc++-v3/ChangeLog
* testsuite/libstdc++-prettyprinters/80276.cc: Add
std::string to debug info.
* testsuite/libstdc++-prettyprinters/libfundts.cc: Likewise.
Alexandre Oliva [Fri, 3 Mar 2023 18:59:36 +0000 (15:59 -0300)]
link pthread_join from std::thread ctor
Like pthread_create, pthread_join may fail to be statically linked in
absent strong uses, so add to user code strong references to both when
std::thread objects are created.
for libstdc++-v3/ChangeLog
PR libstdc++/104852
PR libstdc++/95989
PR libstdc++/52590
* include/bits/std_thread.h (thread::_M_thread_deps): New
static implicitly-inline member function.
(std::thread template ctor): Pass it to _M_start_thread.
* src/c++11/thread.cc (thread::_M_start_thread): Name depend
parameter, force it live on entry.
Alexandre Oliva [Fri, 3 Mar 2023 18:59:30 +0000 (15:59 -0300)]
-Wdangling-pointer: don't mark SSA lhs sets as stores
check_dangling_stores has some weirdnesses that causes its behavior to
change when the target ABI requires C++ ctors to return this: while
scanning stmts backwards in e.g. the AS ctor on a target that returns
this in ctors, the scan first encounters a copy of this to the SSA
name used to hold the return value. m_ptr_query.get_ref resolves lhs
(the return SSA name) to the rhs (the default SSA name for this), does
not skip it because auto_var_p is false for SSA_NAMEs, and proceeds to
add it to stores, which seems to prevent later attempts to add stores
into *this from succeeding, which disables warnings that should have
triggered.
This is also the case when the backwards search finds unrelated stores
to other fields of *this before it reaches stores that IMHO should be
warned about. The store found first disables checking of other
stores, as if the store appearing later in the code would necessarily
overwrite the store that should be warned about. I've added an
xfailed variant of the existing test (struct An) that triggers this
problem, but I'm not sure how to go about fixing it.
Meanwhile, this patch prevents assignments with SSA_NAMEs in the lhs
from being regarded as stores, which is enough to remove the
undesirable side effect on -Wdangling-pointer of ABI-mandated ctors'
returning this. Another variant of the existing test (struct Al) that
demonstrates the problem regardless of this aspect of the ABI, and
that gets the desired warning with the proposed patch, but not
without.
Curiously, this fix exposes yet another problem in
Wdangling-pointer-5.c: it is the return stmt of the unrelated pointer
p, not the store into possibly-overlapping *vpp2, that caused the
warning to not be issued for the store in *vpp1. I'm not sure whether
we should or should not warn in that case, but this patch adjusts the
test to reflect the behavior change.
* g++.dg/warn/Wdangling-pointer.C (warn_init_ref_member): Add
two new variants, one fixed, one xfailed.
* c-c++-common/Wdangling-pointer-5.c
(nowarn_store_arg_store_arg): Add now-expected warnings.
Alexandre Oliva [Fri, 3 Mar 2023 18:59:27 +0000 (15:59 -0300)]
[arm] adjust tests for quotes around +cdecp<N>
Back when quotes were added around "+cdecp<N>" in the "coproc must be
a constant immediate" error in arm-builtins.cc, tests for that message
lagged behind. Fixed thusly.
for gcc/testsuite/ChangeLog
* gcc.target/arm/acle/cde-errors.c: Adjust messages for quote
around +cdecp<N>.
* gcc.target/arm/acle/cde-mve-error-2.c: Likewise.
Alexandre Oliva [Fri, 3 Mar 2023 18:59:24 +0000 (15:59 -0300)]
[arm] adjust expectations for armv8_2-fp16-move-[12].c
Commit 3a7ba8fd0cda387809e4902328af2473662b6a4a, a patch for
tree-ssa-sink, enabled the removal of basic blocks in ways that
affected the generated code for both of these tests, deviating from
the expectations of the tests.
The simplest case is that of -2, in which the edge unsplitting ends up
enabling a conditional return rather than a conditional branch to a
set-and-return block. That looks like an improvement to me, but the
condition in which the branch or the return takes place can be
reasonably reversed (and, with the current code, it is), I've relaxed
the pattern in the test so as to accept reversed and unreversed
conditions applied to return or branch opcodes.
The situation in -1 is a little more elaborate: conditional branches
based on FP compares in test_select_[78] are initially expanded with
CCFPE compare-and-cbranch on G{T,E}, but when ce2 turns those into a
cmove, because now we have a different fallthrough block, the
condition is reversed, and that lands us with a compare-and-cmove
sequence that needs CCFP for UNL{E,T}. The insn output reverses the
condition and swaps the cmove input operands, so the vcmp and vsel
insns come out the same except for the missing 'e' (for the compare
mode) in vcmp, so, since such reversals could have happened to any of
the tests depending on legitimate basic block layout, I've combined
the vcmp and vcmpe counts.
I see room for improving cmove sequence generation, e.g. trying direct
and reversed conditions and selecting the cheapest one (which would
require CCFP conditions to be modeled as more expensive than CCFPE),
or for some other machine-specific (peephole2?) optimization to turn
CCFP-requiring compare and cmove into CCFPE compare and swapped-inputs
cmove, but I haven't tried that.
for gcc/testsuite/ChangeLog
* gcc.target/arm/armv8_2-fp16-move-1.c: Combine vcmp and vcmpe
expected counts into a single pattern.
* gcc.target/arm/armv8_2-fp16-move-2.c: Accept conditional
return and reversed conditions.
Alexandre Oliva [Fri, 3 Mar 2023 18:59:21 +0000 (15:59 -0300)]
[PR51534] [arm] split out pr51534 test for softfp
The test uses arm_hard_ok and arm_softfp_ok as if they were mutually
exclusive, but they test whether the corresponding -mfloat-abi= flag
is usable, not whether it is in effect, so it is possible for both to
pass, and then the test comes out with incorrect expectations
whichever the default float-abi is.
Separate the test into hard and softfp variants, and extend the softfp
variant to accept both ARM and Thumb opcodes; it unwarrantedly assumed
the latter.
for gcc/testsuite/ChangeLog
PR target/51534
* gcc.target/arm/pr51534.c: Split softfp variant into...
* gcc.target/arm/pr51534s.c: ... this, and support ARM too.
Alexandre Oliva [Fri, 3 Mar 2023 18:59:17 +0000 (15:59 -0300)]
[arm] complete vmsr/vmrs blank and case adjustments
Back in September last year, some of the vmsr and vmrs patterns had an
extraneous blank removed, and the case of register names lowered, but
another instance remained, and so did a testcase.
for gcc/ChangeLog
* config/arm/vfp.md (*thumb2_movsi_vfp): Drop blank after tab
after vmsr and vmrs, and lower the case of P0.
for gcc/testsuite/ChangeLog
* gcc.target/arm/acle/cde-mve-full-assembly.c: Drop blank
after tab after vmsr, and lower the case of P0.
Patrick Palka [Fri, 3 Mar 2023 16:37:02 +0000 (11:37 -0500)]
c++: thinko in extract_local_specs [PR108998]
In order to fix PR100295, r13-4730-g18499b9f848707 attempted to make
extract_local_specs walk the given pattern twice, ignoring unevaluated
operands the first time around so that we prefer to process a local
specialization in an evaluated context if it appears in one (we process
each local specialization once even if it appears multiple times in the
pattern).
But there's a thinko in the patch, namely that we don't actually walk
the pattern twice since we don't clear the visited set for the second
walk (to avoid processing a local specialization twice) and so the root
node (and any node leading up to an unevaluated operand) is considered
visited already. So the patch effectively made extract_local_specs
ignore unevaluated operands altogether, which this testcase demonstrates
isn't quite safe (extract_local_specs never sees 'aa' and we don't record
its local specialization, so later we try to specialize 'aa' on the spot
with the args {{int},{17}} which causes us to nonsensically substitute
its auto with 17.)
This patch fixes this by refining the second walk to start from the
trees we skipped over during the first walk.
PR c++/108998
gcc/cp/ChangeLog:
* pt.cc (el_data::skipped_trees): New data member.
(extract_locals_r): Push to skipped_trees any unevaluated
contexts that we skipped over.
(extract_local_specs): For the second walk, start from each
tree in skipped_trees.
This is a follow-up to commit a4c6bd0821099f6b8c0f64a96ffd9d01a025c413
introducing a runtime check for alignment for 16 byte atomic
compare-exchange, load, and store.
libatomic/ChangeLog:
* config/s390/cas_n.c: New file.
* config/s390/load_n.c: New file.
* config/s390/store_n.c: New file.
Jakub Jelinek [Fri, 3 Mar 2023 15:11:11 +0000 (16:11 +0100)]
waccess: Fix two -Wnonnull warning issues [PR108986]
The following patch fixes 2 issues with the -Wnonnull warning.
One, fixed by the second hunk, is that the warning wording is bogus
since r11-3305, instead of printing
warning: argument 1 to ‘int[static 7]’ is null where non-null expected [-Wnonnull]
it prints
warning: argument 1 to ‘int[static 28]’ is null where non-null expected [-Wnonnull]
access_size is measured in bytes, so obviously will be correct as array
number of elements only if it is 1 byte element array.
In the function, access_nelts is either constant (if sizidx == -1) or
when the array size is determined by some other parameter, I believe a value
passed to that argument.
Later on we query the range of it:
if (get_size_range (m_ptr_qry.rvals, access_nelts, stmt, sizrng, 1))
which I bet must just return accesS_nelts in sizrng[0] and [1] if it is
constant. access_size is later computed as:
tree access_size = NULL_TREE;
if (tree_int_cst_sgn (sizrng[0]) >= 0)
{
if (COMPLETE_TYPE_P (argtype))
{
...
wide_int minsize = wi::to_wide (sizrng[0], prec);
minsize *= wi::to_wide (argsize, prec);
access_size = wide_int_to_tree (sizetype, minsize);
}
}
else
access_size = access_nelts;
}
and immediately after this the code does:
if (integer_zerop (ptr))
{
if (sizidx >= 0 && tree_int_cst_sgn (sizrng[0]) > 0)
{
some other warning wording
}
else if (access_size && access.second.static_p)
{
this spot
}
}
So, because argtype is complete, access_size has been multiplied by
argsize, but in case of this exact warning ("this spot" above)
I believe access_nelts must be really constant, otherwise
"some other warning wording" would handle it. So, I think access_nelts
is exactly what we want to print there.
The other problem is that since the introduction of -Wdangling-pointer
in r12-6606, the pass has early and late instances and while lots of
stuff in the pass is guarded on being done in the late pass only,
this particular function is not, furthermore it is emitting two different
warnings in a loop and already messes up with stuff like clearing
warning suppression for one of the warning (ugh!). The end effect is
that we warn twice about the same problem, once in the early and once in
the late pass. Now, e.g. with -O2 -Wall we warn just once, during the
early pass, as it is then optimized away, so I think just making this
late warning only wouldn't be best. This patch instead returns early
if either of the warnings is suppressed on the call stmt already.
I think if one of the passes warned on it already (even if say on some other
argument), then warning again (even on some other argument) is unnecessary,
if both problems are visible in the same pass we'll still warn about both.
2023-03-03 Jakub Jelinek <jakub@redhat.com>
PR c/108986
* gimple-ssa-warn-access.cc (pass_waccess::maybe_check_access_sizes):
Return immediately if OPT_Wnonnull or OPT_Wstringop_overflow_ is
suppressed on stmt. For [static %E] warning, print access_nelts
rather than access_size. Fix up comment wording.
Robin Dapp [Wed, 1 Feb 2023 18:39:10 +0000 (19:39 +0100)]
s390: Use arch14 instead of z16 for -march=native.
When compiling on a system where binutils do not yet support the 'z16'
name assembling fails with -march=native on a z16 machine.
Currently, this is interpreted as -march=z16. This patch uses -march=arch14
instead.
gcc/ChangeLog:
* config/s390/driver-native.cc (s390_host_detect_local_cpu): Use
arch14 instead of z16.
Xi Ruoyao [Fri, 3 Mar 2023 08:50:53 +0000 (16:50 +0800)]
driver: toplev: Fix a typo
The driver emits a warning when -fstack-check and
-fstack-clash-protection are used together, but the message refers to
"-fstack-clash_protection" (underline instead of dash).
gcc/ChangeLog:
* toplev.cc (process_options): Fix the spelling of
"-fstack-clash-protection".
Richard Biener [Fri, 3 Mar 2023 09:41:29 +0000 (10:41 +0100)]
tree-optimization/109002 - partial PRE miscompilation
Partial PRE ends up miscompiling the testcase in PR109002, likely
involving a corner case when inifinite loops are involved. The
following avoids the miscompilation by addressing a long-standing
oddity that manifests in odd partial partial redundancies eliminated
that are full redundancies. The oddity is that while we properly
PHI translate the PA_IN set from the successors when computing
PA_OUT but we fail to do the same for ANTIC_IN which is supposed
to be unioned. That results in expressions with wrong virtual
operands being placed in the PA_OUT/IN sets and the pruning
machinery to go wrong because it assumes the expressions in the
sets have virtual operands that are valid in the respective blocks.
Jakub Jelinek [Fri, 3 Mar 2023 10:13:40 +0000 (11:13 +0100)]
gimple-fold: Fix up fputs -> fwrite folding [PR108988]
gimple_fold_builtin_fputs when folding fputs into fwrite emits the third
argument (INTEGER_CST) with incorrect type - get_maxval_strlen or c_strlen
return ssizetype, while fwrite argument is size_type_node.
The following patch fixes that, I've skimmed through the rest of
gimple-fold.cc and in all other places get_maxval_strlen/c_strlen result
was fold_converted to size_type_node already (or GIMPLE cast stmt has been
emitted directly etc.).
2023-03-03 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/108988
* gimple-fold.cc (gimple_fold_builtin_fputs): Fold len to
size_type_node before passing it as argument to fwrite. Formatting
fixes.
Richard Biener [Thu, 2 Mar 2023 12:43:51 +0000 (13:43 +0100)]
target/108738 - limit STV chain discovery
The following puts a hard limit on the inherently quadratic STV chain
discovery. Without a limit for the compiler.i testcase in PR26854
we see at -O2
machine dep reorg : 574.45 ( 53%)
with release checking while with the proposed limit it's
machine dep reorg : 2.86 ( 1%)
PR target/108738
* config/i386/i386.opt (--param x86-stv-max-visits): New param.
* doc/invoke.texi (--param x86-stv-max-visits): Document it.
* config/i386/i386-features.h (scalar_chain::max_visits): New.
(scalar_chain::build): Add bitmap parameter, return boolean.
(scalar_chain::add_insn): Likewise.
(scalar_chain::analyze_register_chain): Likewise.
* config/i386/i386-features.cc (scalar_chain::scalar_chain):
Initialize max_visits.
(scalar_chain::analyze_register_chain): When we exhaust
max_visits, abort. Also abort when running into any
disallowed insn.
(scalar_chain::add_insn): Propagate abort.
(scalar_chain::build): Likewise. When aborting amend
the set of disallowed insn with the insns set.
(convert_scalars_to_vector): Adjust. Do not convert aborted
chains.
Richard Biener [Wed, 1 Mar 2023 09:01:10 +0000 (10:01 +0100)]
debug/108772 - ICE with late debug generated with -flto
When combining -g1 with -flto we run into the DIE location annotation
machinery for globals calling dwarf2out_late_global_decl but not
having any early generated DIE for function scope statics. In
this process we'd generate a limbo DIE since also the function scope
doesn't have any early generated DIE. The limbo handling then tries
to force a DIE for the context chain which ultimatively fails and
ICEs at the std namespace decl because at -g1 we don't represent that.
The following avoids this situation by making sure to never generate
any DIEs from dwarf2out_late_global_decl in the in_lto_p path
for function scope globals but rely on DIE generation for
the function to output a DIE for the local static (which doesn't
happen for -g1).
I explored a lot of other options to fix this but in the end this
seems to be the most spot-on fix with the least risk of unwanted
effects.
PR debug/108772
* dwarf2out.cc (dwarf2out_late_global_decl): Do not
generate a DIE for a function scope static.
Alexandre Oliva [Fri, 3 Mar 2023 04:47:00 +0000 (01:47 -0300)]
[PR100127] Test for coroutine header in clang-compatible tests
The test is compatible with clang as well as gcc, but ISTM that
testing for the __clang__ macro is just as potentially error-prone as
macros that used to be GCC-specific are now defined in compilers that
aim for GCC compatibility. Use a __has_include feature test instead.
for gcc/testsuite/ChangeLog
PR c++/100127
* g++.dg/coroutines/pr100127.C: Test for header rather than
compiler macro.
* g++.dg/coroutines/pr100772-a.C: Likewise.
* g++.dg/coroutines/pr100772-b.C: Likewise.
Alexandre Oliva [Fri, 3 Mar 2023 04:47:04 +0000 (01:47 -0300)]
[vxworks] make wint_t and wchar_t the same distinct type
We used to define WINT_TYPE to WCHAR_TYPE, so that both wint_t and
wchar_t mapped to the same underlying type, but this caused a glitch
in Wstringop-overflow-6.C: on vxworks, wint_t is typedef'ed to
wchar_t, headers got included in the test that declared functions that
take wint_t parameters, and those conflicted with the builtin
declarations that had wint_t mapped to the underlying integral type.
The problem is that, in C++, wchar_t is a distinct type. Having
wint_t be a typedef to wchar_t in the headers, but a typedef to
wchar_t's underlying integral type in builtins, makes for mismatches
between the declarations.
This patch defines WINT_TYPE to "wchar_t" for vxworks, and adjusts the
fallout, namely:
- since wchar_t may not have been defined yet when
c_common_nodes_and_builtins runs, use the node already reserved for
wchar_t for wint_t when WINT_TYPE is defined to wchar_t.
- for the same reason, when WINT_TYPE is wchar_t and we're not
compiling C++ where wchar_t is a compiler built-in, define
__WINT_TYPE__ to WCHAR_TYPE rather than WINT_TYPE, because wchar_t
may not even be defined in the translation unit.
- recognize and handle wchar_type_node when type_suffix is called for
wint_type_node.
for gcc/ChangeLog
* config/vx-common.h (WINT_TYPE): Alias to "wchar_t".
for gcc/c-family/ChangeLog
* c-common.cc (c_common_nodes_and_builtins): Take
wchar_type_node for wint_type_node when aliased.
(c_stddef_cpp_builtins): Define __WINT_TYPE__, when aliased to
wchar_t, to the underlying type rather than wchar_t in
non-C++.
* c-cppbuiltin.cc (type_suffix): Handle wchar_type_node.
Alexandre Oliva [Fri, 3 Mar 2023 04:46:56 +0000 (01:46 -0300)]
[c++] suppress redundant null-addr warn in pfn from pmfn
When TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta, when
we warn about comparing a pointer-to-member-function with NULL, we
also warn about comparing the pointer-to-function extracted from it
with NULL, which is redundant. Suppress the redundant warning.
for gcc/cp/ChangeLog
* typeck.cc (cp_build_binary_op): Suppress redundant warning
for pfn null test in pmfn test with vbit-in-delta.
tm.texi says for BIGGEST_ALIGNMENT (from which
__BIGGEST_ALIGNMENT__ is derived): "Biggest alignment that
any data type can require on this machine, in bits."
That is, using that value might be too strict for alignment
of *functions* and CRIS requires at least 16-bit alignment
for functions. But, one purpose of the test is to test that
alignment can be set to a large but valid value, so pick
512, which has some use as a historically required alignment
for certain I/O descriptors.
* gcc.dg/attr-aligned.c: Adjust comment for ALIGN_MAX_STATIC.
(ALIGN_MAX_STATIC): Set to 512 for CRIS.
Iain Buclaw [Thu, 2 Mar 2023 23:00:44 +0000 (00:00 +0100)]
d: Allow vectors to be compared for identity [PR108946]
Vector equality and comparisons are now accepted by the language
implementation, but identity wasn't. Implement it as an extra integer
comparison of the bit-casted bitmask.
git://gcc.gnu.org / gcc.git / log