Commit graph

208270 commits

Author SHA1 Message Date
Sandra Loosemore
4666cbde5e Sort warning options in c-family/c.opt.
In spite of the plea "Please try to keep this file in ASCII collating
order" at the top of the file, the sorting of the entries for the
various -Wfoo options had increased in entropy.  This made it hard to
correlate them against e.g. the list of options enabled by -Wall in
the manual (see PR90463).  This patch is at least a step in the right
direction to restore order to the file.

I confirmed that no lines were added or removed by these changes, and
that the output of "gcc -Q --help=warnings" is unchanged both with or
without -Wall added to the command.

gcc/c-family/ChangeLog
	* c.opt: Improve sorting of warning options.
2024-01-23 00:21:24 +00:00
GCC Administrator
e2d1f8587c Daily bump. 2024-01-23 00:18:32 +00:00
Marek Polacek
c596ce0312 c++: extend Wdangling-reference17.C [PR109642]
This patch extends g++.dg/warn/Wdangling-reference17.C with code
from PR109642.  I'm not creating a new test because this one
already #includes the required headers.

	PR c++/109642

gcc/testsuite/ChangeLog:

	* g++.dg/warn/Wdangling-reference17.C: Additional testing.
2024-01-22 16:13:03 -05:00
John David Anglin
bc77c035c4 Add -gno-strict-dwarf to dg-options in various btf enum tests
The -gno-strict-dwarf option is needed to ensure enum signedness
is added to type_die.

2024-01-22  John David Anglin  <danglin@gcc.gnu.org>

gcc/testsuite/ChangeLog:

	PR debug/113382
	* gcc.dg/debug/btf/btf-bitfields-3.c: Add -gno-strict-dwarf
	option to dg-options.
	* gcc.dg/debug/btf/btf-enum-1.c: Likewise.
	* gcc.dg/debug/btf/btf-enum-small.c: Likewise.
	* gcc.dg/debug/btf/btf-enum64-1.c: Likewise.
2024-01-22 19:07:32 +00:00
Andrew Pinski
41caf6b0d6 arm: Fix parsecpu.awk for aliases [PR113030]
So the problem here is the 2 functions check_cpu and check_arch use
the wrong variable to check if an alias is valid for that cpu/arch.
check_cpu uses cpu_optaliases instead of cpu_opt_alias. cpu_optaliases
is an array of index'ed by the cpuname that contains all of the valid aliases
for that cpu but cpu_opt_alias is an double index array which is index'ed
by cpuname and the alias which provides what is the alias for that option.
Similar thing happens for check_arch and arch_optaliases vs arch_optaliases.

Tested by running:
```
awk -f config/arm/parsecpu.awk -v cmd="chkarch armv7-a+simd" config/arm/arm-cpus.in
awk -f config/arm/parsecpu.awk -v cmd="chkarch armv7-a+neon" config/arm/arm-cpus.in
awk -f config/arm/parsecpu.awk -v cmd="chkarch armv7-a+neon-vfpv3" config/arm/arm-cpus.in
```
And they don't return error back.

gcc/ChangeLog:

	PR target/113030
	* config/arm/parsecpu.awk (check_cpu): Use cpu_opt_alias
	instead of cpu_optaliases.
	(check_arch): Use arch_opt_alias instead of arch_optaliases.

Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
2024-01-22 09:30:42 -08:00
Tobias Burnus
a1b2953924 xfail libgomp.c/declare-variant-4-{fiji,gfx803}.c
Since r14-4734-g56ed1055b2f40ac162ae8d382280ac07a33f789f, GCC no longer
builds the Fiji (alias gfx803) libraries by default as support for it was
removed in ROCm 4.0 and will be removed in LLVM 18.

Thus, unless gfx803 is explicitly enabled, the following testcases will
fail to link as libgomp is not available for Fiji. Hence, this commit
xfails those testcases.

libgomp/ChangeLog:

	* testsuite/libgomp.c/declare-variant-4-fiji.c: Xfail as fiji
	support is no longer enabled by default.
	* testsuite/libgomp.c/declare-variant-4-gfx803.c: Likewise.

Signed-off-by: Tobias Burnus <tburnus@baylibre.com>
2024-01-22 17:56:36 +01:00
Juzhe-Zhong
f9df00340e RISC-V: Lower vmv.v.x (avl = 1) into vmv.s.x
Notice there is a AI benchmark, GCC vs Clang has 3% performance drop.

It's because Clang/LLVM has a simplification transform vmv.v.x (avl = 1) into vmv.s.x.

Since vmv.s.x has more flexible vsetvl demand than vmv.v.x that can allow us to have
better chances to fuse vsetvl.

Consider this following case:

void
foo (uint32_t *outputMat, uint32_t *inputMat)
{
  vuint32m1_t matRegIn0 = __riscv_vle32_v_u32m1 (inputMat, 4);
  vuint32m1_t matRegIn1 = __riscv_vle32_v_u32m1 (inputMat + 4, 4);
  vuint32m1_t matRegIn2 = __riscv_vle32_v_u32m1 (inputMat + 8, 4);
  vuint32m1_t matRegIn3 = __riscv_vle32_v_u32m1 (inputMat + 12, 4);

  vbool32_t oddMask
    = __riscv_vreinterpret_v_u32m1_b32 (__riscv_vmv_v_x_u32m1 (0xaaaa, 1));

  vuint32m1_t smallTransposeMat0
    = __riscv_vslideup_vx_u32m1_tumu (oddMask, matRegIn0, matRegIn1, 1, 4);
  vuint32m1_t smallTransposeMat2
    = __riscv_vslideup_vx_u32m1_tumu (oddMask, matRegIn2, matRegIn3, 1, 4);

  vuint32m1_t outMat0 = __riscv_vslideup_vx_u32m1_tu (smallTransposeMat0,
						      smallTransposeMat2, 2, 4);

  __riscv_vse32_v_u32m1 (outputMat, outMat0, 4);
}

Before this patch:

        vsetivli        zero,4,e32,m1,ta,ma
        li      a5,45056
        addi    a2,a1,16
        addi    a3,a1,32
        addi    a4,a1,48
        vle32.v v1,0(a1)
        vle32.v v4,0(a2)
        vle32.v v2,0(a3)
        vle32.v v3,0(a4)
        addiw   a5,a5,-1366
        vsetivli        zero,1,e32,m1,ta,ma
        vmv.v.x v0,a5                         ---> Since it avl = 1, we can transform it into vmv.s.x
        vsetivli        zero,4,e32,m1,tu,mu
        vslideup.vi     v1,v4,1,v0.t
        vslideup.vi     v2,v3,1,v0.t
        vslideup.vi     v1,v2,2
        vse32.v v1,0(a0)
        ret

After this patch:

	li	a5,45056
	addi	a2,a1,16
	vsetivli	zero,4,e32,m1,tu,mu
	addiw	a5,a5,-1366
	vle32.v	v3,0(a2)
	addi	a3,a1,32
	addi	a4,a1,48
	vle32.v	v1,0(a1)
	vmv.s.x	v0,a5
	vle32.v	v2,0(a3)
	vslideup.vi	v1,v3,1,v0.t
	vle32.v	v3,0(a4)
	vslideup.vi	v2,v3,1,v0.t
	vslideup.vi	v1,v2,2
	vse32.v	v1,0(a0)
	ret

Tested on both RV32 and RV64 no regression.

gcc/ChangeLog:

	* config/riscv/riscv-protos.h (splat_to_scalar_move_p): New function.
	* config/riscv/riscv-v.cc (splat_to_scalar_move_p): Ditto.
	* config/riscv/vector.md: Simplify vmv.v.x. into vmv.s.x.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/rvv/vsetvl/attribute-2.c: New test.
	* gcc.target/riscv/rvv/vsetvl/attribute-3.c: New test.
2024-01-22 21:48:21 +08:00
Jonathan Wakely
8229214fae libstdc++: Fix check in testsuite/std/time/clock/file/io.cc
The test_format() function contained an incorrect assertion but wasn't
actually being called from main.

libstdc++-v3/ChangeLog:

	* testsuite/std/time/clock/file/io.cc: Fix expected result in
	assertion and call test_format() from main.
2024-01-22 13:06:00 +00:00
Juzhe-Zhong
f625c017e6 RISC-V: Fix regressions due to 86de9b6648
This patch fixes the recent regression:

FAIL: gcc.dg/torture/float32-tg-2.c   -O1  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg-2.c   -O1  (test for excess errors)
FAIL: gcc.dg/torture/float32-tg-2.c   -O2  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg-2.c   -O2  (test for excess errors)
FAIL: gcc.dg/torture/float32-tg-2.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg-2.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  (test for excess errors)
FAIL: gcc.dg/torture/float32-tg-2.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg-2.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
FAIL: gcc.dg/torture/float32-tg-2.c   -O3 -g  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg-2.c   -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/float32-tg-2.c   -Os  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg-2.c   -Os  (test for excess errors)
FAIL: gcc.dg/torture/float32-tg.c   -O1  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg.c   -O1  (test for excess errors)
FAIL: gcc.dg/torture/float32-tg.c   -O2  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg.c   -O2  (test for excess errors)
FAIL: gcc.dg/torture/float32-tg.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  (test for excess errors)
FAIL: gcc.dg/torture/float32-tg.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
FAIL: gcc.dg/torture/float32-tg.c   -O3 -g  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg.c   -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/float32-tg.c   -Os  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/float32-tg.c   -Os  (test for excess errors)
FAIL: gcc.dg/torture/pr48124-4.c   -O1  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/pr48124-4.c   -O1  (test for excess errors)
FAIL: gcc.dg/torture/pr48124-4.c   -O2  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/pr48124-4.c   -O2  (test for excess errors)
FAIL: gcc.dg/torture/pr48124-4.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/pr48124-4.c   -O2 -flto -fno-use-linker-plugin -flto-partition=none  (test for excess errors)
FAIL: gcc.dg/torture/pr48124-4.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/pr48124-4.c   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
FAIL: gcc.dg/torture/pr48124-4.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/pr48124-4.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gcc.dg/torture/pr48124-4.c   -O3 -g  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/pr48124-4.c   -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/pr48124-4.c   -Os  (internal compiler error: in reg_or_subregno, at jump.cc:1895)
FAIL: gcc.dg/torture/pr48124-4.c   -Os  (test for excess errors)

due to commit 86de9b6648.

The root cause is register_operand and reg_or_subregno are consistent so we reach the assertion fail.

We shouldn't worry about subreg:...VL_REGNUM since it's impossible that we can have such situation,
that is, we only have (set (reg) (reg:VL_REGNUM)) which generate "csrr vl" ASM for first fault load instructions (vleff).
So, using REG_P and REGNO must be totally solid and robostic.

Since we don't allow VL_RENUM involved into register allocation and we don't have such constraint, we always use this
following pattern to generate "csrr vl" ASM:

(define_insn "read_vlsi"
  [(set (match_operand:SI 0 "register_operand" "=r")
	(reg:SI VL_REGNUM))]
  "TARGET_VECTOR"
  "csrr\t%0,vl"
  [(set_attr "type" "rdvl")
   (set_attr "mode" "SI")])

So the check in riscv.md is to disallow such situation fall into move pattern in riscv.md

Tested on both RV32/RV64 no regression.

	PR target/109092

gcc/ChangeLog:

	* config/riscv/riscv.md: Use reg instead of subreg.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/rvv/base/pr109092.c: New test.
2024-01-22 20:52:35 +08:00
Tobias Burnus
13127dac10 [gcn] mkoffload: Fix linking with "-g"; fix file deletion; improve diagnostic [PR111966]
With debugging enabled, '*.mkoffload.dbg.o' files are generated. The e_flags
header of all *.o files must be the same - otherwise, the linker complains.
Since r14-4734-g56ed1055b2f40ac162ae8d382280ac07a33f789f the -march= default
is now gfx900. If compiling without any -march= flag, the default value is
used by the compiler but not passed to mkoffload. Hence, mkoffload.cc's uses
its own default for march - unfortunately, it still had gfx803/fiji as default,
leading to the linker error: 'incompatible mach'. Solution: Update the
default to gfx900.

While debugging it, I saw that /tmp/cc*.mkoffload.dbg.o kept accumulating;
there were a couple of issues with the handling:
* dbgobj was always added to files_to_cleanup
* If copy_early_debug_info returned true, dbgobj was added again
  -> pointless and in theory a race if the same file was added in the
     faction of a second.
* If copy_early_debug_info returned false,
  - In exactly one case, it already deleted the file it self
    (same potential race as above)
  - The pointer dbgobj was freed - such that files_to_cleanup contained
    a dangling pointer - probably the reason that stale files remained.
Solution: Only if copy_early_debug_info returns true, dbgobj is added to
files_to_cleanup. If it returns false, the file is unlinked before freeing
the pointer.

When compiling, GCC warned about several fatal_error messages as having
no %<...%> or %qs quotes. This patch now silences several of those warnings
by using those quotes.

gcc/ChangeLog:

	PR other/111966
	* config/gcn/mkoffload.cc (elf_arch): Change default to gfx900
	to match the compiler default.
	(simple_object_copy_lto_debug_sections): Never unlink the outfile
	on error as the caller does so.
	(maybe_unlink, compile_native): Use %<...%> and %qs in fatal_error.
	(main): Likewise. Fix 'mkoffload.dbg.o' cleanup.

Signed-off-by: Tobias Burnus <tburnus@baylibre.com>
2024-01-22 12:17:12 +01:00
Marc Poulhiès
06c565cc01 Update copyright years. 2024-01-22 10:57:42 +01:00
Richard Biener
86f3cbdaa6 tree-optimization/113373 - add missing LC PHIs for live operations
The following makes reduction epilogue code generation happy by properly
adding LC PHIs to the exit blocks for multiple exit vectorized loops.

Some refactoring might make the flow easier to follow but I've refrained
from doing that with this patch.

I've kept some fixes in reduction epilogue generation from the earlier
attempt fixing this PR.

	PR tree-optimization/113373
	* tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg):
	Create LC PHIs in the exit blocks where necessary.
	* tree-vect-loop.cc (vectorizable_live_operation): Do not try
	to handle missing LC PHIs.
	(find_connected_edge): Remove.
	(vect_create_epilog_for_reduction): Cleanup use of auto_vec.

	* gcc.dg/vect/vect-early-break_104-pr113373.c: New testcase.
2024-01-22 08:48:26 +01:00
Juzhe-Zhong
a618b3c657 RISC-V: Fix vfirst/vmsbf/vmsif/vmsof ratio attributes
vfirst/vmsbf/vmsif/vmsof instructions are supposed to demand ratio instead of demanding sew_lmul.
But my previous typo makes VSETVL PASS miss honor the risc-v v spec.

Consider this following simple case:

int foo4 (void * in, void * out)
{
  vint32m1_t v = __riscv_vle32_v_i32m1 (in, 4);
  v = __riscv_vadd_vv_i32m1 (v, v, 4);
  vbool32_t mask = __riscv_vreinterpret_v_i32m1_b32(v);
  mask = __riscv_vmsof_m_b32(mask, 4);
  return __riscv_vfirst_m_b32(mask, 4);
}

Before this patch:

foo4:
        vsetivli        zero,4,e32,m1,ta,ma
        vle32.v v1,0(a0)
        vadd.vv v1,v1,v1
        vsetvli zero,zero,e8,mf4,ta,ma    ----> redundant.
        vmsof.m v2,v1
        vfirst.m        a0,v2
        ret

After this patch:

foo4:
	vsetivli	zero,4,e32,m1,ta,ma
	vle32.v	v1,0(a0)
	vadd.vv	v1,v1,v1
	vmsof.m	v2,v1
	vfirst.m	a0,v2
	ret

Confirm RVV spec and Clang, this patch makes VSETVL PASS match the correct behavior.

Tested on both RV32/RV64, no regression.

gcc/ChangeLog:

	* config/riscv/vector.md: Fix vfirst/vmsbf/vmsof ratio attributes.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/rvv/vsetvl/attribute-1.c: New test.
2024-01-22 15:01:15 +08:00
xuli
46a664dd59 RISC-V: Bugfix for resolve_overloaded_builtin[PR113420]
v2:
Avoid internal ICE for the case below.
vint8mf8_t test_vle8_v_i8mf8_m(vbool64_t vm, const int32_t *rs1, size_t vl) {
  return __riscv_vle8(vm, rs1, vl);
}

v1:
Change the hash value of overloaded intrinsic from considering
all parameter types to:
1. Encoding vector data type
2. In order to distinguish vle8_v_i8mf8_m(vbool64_t vm, const int8_t *rs1, size_t vl)
   and vle8_v_u8mf8_m(vbool64_t vm, const uint8_t *rs1, size_t vl), encode the pointer type
3. In order to distinguish vfadd_vv_f32mf2_rm(vfloat32mf2_t vs2, vfloat32mf2_t vs1, size_t vl)
   and vfadd_vv_f32mf2(vfloat32mf2_t vs2, vfloat32mf2_t vs1, size_t vl), encode the number of
   parameters. The same goes for the vxrm intrinsics.

	PR target/113420

gcc/ChangeLog:

	* config/riscv/riscv-vector-builtins.cc (has_vxrm_or_frm_p):remove.
	(registered_function::overloaded_hash):refactor.
	(resolve_overloaded_builtin):avoid internal ICE.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/rvv/base/pr113420-1.c: New test.
	* gcc.target/riscv/rvv/base/pr113420-2.c: New test.
2024-01-22 06:45:55 +00:00
Jeff Law
7e16f819ff [committed] Adjust expectations for pr59533-1.c
The change for pr111267 twiddled code generation for sh/pr59533-1.c

We end up eliminating two comparisons, but require two shll instructions to do
so.  And in a couple places we're using an addc sequence rather than a subc
sequence.   This patch adjusts the expected codegen for the test as all those
are either a wash or a

The fwprop change does cause some code regressions on the same test.  I'll file
a distinct but for that issue.

gcc/testsuite
	* gcc.target/sh/pr59533-1.c: Adjust expected output.
2024-01-21 19:12:21 -07:00
GCC Administrator
d9ed3ac20e Daily bump. 2024-01-22 00:17:47 +00:00
Mary Bennett
3a6b650689 [PATCH v3 2/2] RISC-V: Fix XCValu test
gcc/testsuite/ChangeLog:
	* gcc.target/riscv/cv-alu-fail-compile.c: Change warning to error.
2024-01-21 16:24:14 -07:00
Mikael Pettersson
bdcf7226c9 Re: [PATCH] Avoid ICE with m68k-elf -malign-int and libcalls
>> emit_library_call_value_1 calls emit_push_insn with NULL_TREE
>> for TYPE.  Sometimes emit_push_insn needs to assign a temp with
>> that TYPE, which causes a segfault.
>>
>> Fixed by computing the TYPE from MODE when needed.
>>
>> Original patch by Thorsten Otto.
>>
[ ... ]
> This really needs to happen in the two call paths which pass in
> NULL_TREE for the type.  Note how the type is used to determine padding
> earlier in emit_push_insn.  That would also make the code more
> consistent with the comment before emit_push_insn which implies that
> both MODE and TYPE are valid.
>
>
> Additionally you should bootstrap and regression test this patch on at
> least one target.

Updated as requested, and bootstrapped and tested on
{x86_64,aarch64,m68k}-linux-gnu without regressions.

gcc/

	PR target/82420
	PR target/111279
	* calls.cc (emit_library_call_value_1): Pass valid TYPE
	to emit_push_insn.
	* expr.cc (emit_push_insn): Likewise.

gcc/testsuite/

	PR target/82420
	* gcc.target/m68k/pr82420.c: New test.

	    Co-authored-by: Thorsten Otto  <admin@tho-otto.de>
2024-01-21 15:59:33 -07:00
Jeff Law
5efd98c6f8 Install right version of last change.
gcc/
	* config/riscv/riscv.cc (riscv_init_cumulative_args): Install
	correcction version of last change.
2024-01-21 15:45:11 -07:00
Jeff Law
b1829de17b [committed] [NFC] Fix riscv_init_cumulative_args for unused arguments
The signature was still using ATTRIBUTE_UNUSED and actually marked one
of the used arguments with ATTRIBUTE_UNUSED.

This patch drops the decorations and instead remove the name of arguments
which are actually unused which is the preferred way to handle this now
when we can.

Bootstrapped.  I didn't have test results on the platform where I
bootstrapped, so no results to compare against.  Given its NFC, I
think we're OK without the regression results.

gcc/
	* config/riscv/riscv.cc (riscv_init_cumulative_args): Update and
	fix bugs in signature.
2024-01-21 15:41:38 -07:00
Jonathan Wakely
7431fcea6b libstdc++: Fix std::format for floating-point chrono::time_point [PR113500]
Currently trying to use std::format with certain specializations of
std::chrono::time_point is ill-formed, due to one member function of the
__formatter_chrono type which tries to write a time_point to an ostream.
For sys_time<floating-point> or sys_time with a period greater than days
there is no operator<< that can be used.

That operator<< is only needed when using an empty chrono-specs in the
format string, like "{}", but the ill-formed expression gives an error
even if not actually used. This means it's not possible to format some
other specializations of chrono::time_point, even when using a non-empty
chrono-specs.

This fixes it by avoiding using 'os << t' for all chrono::time_point
specializations, and instead using std::format("{:L%F %T}", t). So that
we continue to reject std::format("{}", sys_time{1.0s}) a check for
empty chrono-specs is added to the formatter<sys_time<D>, C>
specialization.

While testing this I noticed that the output for %S with a
floating-point duration was incorrect, as the subseconds part was being
appended to the seconds without a decimal point, and without the correct
number of leading zeros.

libstdc++-v3/ChangeLog:

	PR libstdc++/113500
	* include/bits/chrono_io.h (__formatter_chrono::_M_S): Fix
	printing of subseconds with floating-point rep.
	(__formatter_chrono::_M_format_to_ostream): Do not write
	time_point specializations directly to the ostream.
	(formatter<chrono::sys_time<D>, C>::parse): Do not allow an
	empty chrono-spec if the type fails to meet the constraints for
	writing to an ostream with operator<<.
	* testsuite/std/time/clock/file/io.cc: Check formatting
	non-integral times with empty chrono-specs.
	* testsuite/std/time/clock/gps/io.cc: Likewise.
	* testsuite/std/time/clock/utc/io.cc: Likewise.
	* testsuite/std/time/hh_mm_ss/io.cc: Likewise.
2024-01-21 22:15:06 +00:00
Jonathan Wakely
fba15da8fa libstdc++: Fix std::chrono::file_clock conversions for low-precision times
THe std::chrono::file_clock conversions were not using common_type and
so failed to compile when converting anything that should have increased
precision after arithmetic with a std::chrono::seconds value.

libstdc++-v3/ChangeLog:

	* include/bits/chrono.h (__file_clock::from_sys)
	(__file_clock::to_sys, __file_clock::_S_from_sys)
	(__file_clock::_S_to_sys): Use common_type for return type.
	* testsuite/std/time/clock/file/members.cc: Check round trip
	conversion for time with lower precision that seconds.
2024-01-21 22:15:06 +00:00
Roger Sayle
86de9b6648 PR rtl-optimization/111267: Improved forward propagation.
This patch resolves PR rtl-optimization/111267 by improving RTL-level
forward propagation.  This x86_64 code quality regression was caused
(exposed) by my changes to improve how x86's (TImode) argument passing
is represented at the RTL-level (reducing the use of SUBREGs to catch
more optimization opportunities in combine).  The pitfall is that the
more complex RTL representations expose a limitation in RTL's fwprop
pass.

At the heart of fwprop, in try_fwprop_subst_pattern, the logic can
be summarized as three steps.  Step 1 is a heuristic that rejects the
propagation attempt if the expression is too complex, step 2 calls
the backend's recog to see if the propagated/simplified instruction
is recognizable/valid, and step 3 then calls set_src_cost to compare
the rtx costs of the replacement vs. the original, and accepts the
transformation if the final cost is the same of better.

The logic error (or missed optimization opportunity) is that the
step 1 heuristic that attempts to predict (second guess) the
process is flawed.  Ultimately the decision on whether to fwprop
or not should depend solely on actual improvement, as measured
by RTX costs.  Hence the prototype fix in the bugzilla PR removes
the heuristic of calling prop.profitable_p entirely, relying
entirely on the cost comparison in step 3.

Unfortunately, things are a tiny bit more complicated.  The cost
comparison in fwprop uses the older set_src_cost API and not the
newer (preffered) insn_cost API as currently used in combine.
This means that the cost improvement comparisons are only done
for single_set instructions (more complex PARALLELs etc. aren't
supported).  Hence we can only rely on skipping step 1 for that
subset of instructions actually evaluated by step 3.

The other subtlety is that to avoid potential infinite loops
in fwprop we should only reply purely on rtx costs when the
transformation is obviously an improvement.  If the replacement
has the same cost as the original, we can use the prop.profitable_p
test to preserve the current behavior.

Finally, to answer Richard Biener's remaining question about this
approach: yes, there is an asymmetry between how patterns are
handled and how REG_EQUAL notes are handled.  For example, at
the moment propagation into notes doesn't use rtx costs at all,
and ultimately when fwprop is updated to use insn_cost, this
(and recog) obviously isn't applicable to notes.  There's no reason
the logic need be identical between patterns and notes, and during
stage4 we only need update propagation into patterns to fix this
P1 regression (notes and use of cost_insn can be done for GCC 15).

For Jakub's reduced testcase:

struct S { float a, b, c, d; };
int bar (struct S x, struct S y) {
  return x.b <= y.d && x.c >= y.a;
}

On x86_64-pc-linux-gnu with -O2 gcc currently generates:

bar:    movq    %xmm2, %rdx
        movq    %xmm3, %rax
        movq    %xmm0, %rsi
        xchgq   %rdx, %rax
        movq    %rsi, %rcx
        movq    %rax, %rsi
        movq    %rdx, %rax
        shrq    $32, %rcx
        shrq    $32, %rax
        movd    %ecx, %xmm4
        movd    %eax, %xmm0
        comiss  %xmm4, %xmm0
        jb      .L6
        movd    %esi, %xmm0
        xorl    %eax, %eax
        comiss  %xmm0, %xmm1
        setnb   %al
        ret
.L6:	xorl    %eax, %eax
        ret

with this simple patch to fwprop, we now generate:

bar:	shufps  $85, %xmm0, %xmm0
        shufps  $85, %xmm3, %xmm3
        comiss  %xmm0, %xmm3
        jb      .L6
        xorl    %eax, %eax
        comiss  %xmm2, %xmm1
        setnb   %al
        ret
.L6:	xorl    %eax, %eax
        ret

2024-01-21  Roger Sayle  <roger@nextmovesoftware.com>
	    Richard Biener  <rguenther@suse.de>

gcc/ChangeLog
	PR rtl-optimization/111267
	* fwprop.cc (fwprop_propagation::profitabe_p): Rename
	profitable_p method to likely_profitable_p.
	(try_fwprop_subst_node): Update call to likely_profitable_p.
	Only bail-out early when !prop.likely_profitable_p for instructions
	that are not single sets.  When comparing costs, bail-out if the
	cost is unchanged and !prop.likely_profitable_p.

gcc/testsuite/ChangeLog
	PR rtl-optimization/111267
	* gcc.target/i386/pr111267.c: New test case.
2024-01-21 21:22:28 +00:00
Sandra Loosemore
5c3e2e134b Make the manual clearer about what options -Wunused enables [PR90464]
gcc/ChangeLog
	PR c++/90464
	* doc/invoke.texi (Warning Options): Document that -Wunused-parameter
	isn't enabled by -Wunused unless -Wextra is provided, and that
	-Wunused does enable -Wunused-const-variable=1 for C.  Clarify that
	-Wunused doesn't enable -Wunused-* options documented as behaving
	otherwise, and list them explicitly.
2024-01-21 20:50:50 +00:00
Harald Anlauf
68862e5c75 Fortran: passing of optional scalar arguments with VALUE attribute [PR113377]
gcc/fortran/ChangeLog:

	PR fortran/113377
	* trans-expr.cc (gfc_conv_procedure_call): Fix handling of optional
	scalar arguments of intrinsic type with the VALUE attribute.

gcc/testsuite/ChangeLog:

	PR fortran/113377
	* gfortran.dg/optional_absent_9.f90: New test.
2024-01-21 21:21:07 +01:00
Martin Uecker
1ead42f983 C23: Fix ICE for composite type for structs with unsigned bitfields [PR113492]
This patch fixes a bug when forming a composite type from structs that
contain an unsigned bitfield declared with int while using -funsigned-bitfields.
In such structs the unsigned integer type was not compatible to the
regular unsigned integer type used elsewhere in the C FE.

	PR c/113492
gcc/c:
	* c-decl.cc (grokdeclarator): Use c_common_unsigned_type instead of
	unsigned_type_for to create the unsigned type for bitfields declared
	with int when using -funsigned-bitfields.

gcc/testsuite:
	* gcc.dg/pr113492.c: New test.
2024-01-21 18:58:49 +01:00
Jonathan Wakely
a57439d619 libstdc++: Fix std::format floating-point alternate forms [PR113512]
The logic for handling '#' forms was ... not good. The count of
significant figures just counted digits, instead of ignoring leading
zeros. And when moving the result from the stack buffer to a dynamic
string the exponent could get lost in some cases.

libstdc++-v3/ChangeLog:

	PR libstdc++/113512
	* include/std/format (__formatter_fp::format): Fix logic for
	alternate forms.
	* testsuite/std/format/functions/format.cc: Check buggy cases of
	alternate forms with g presentation type.
2024-01-21 13:31:28 +00:00
Sandra Loosemore
29f931e39f Clean up examples for -Wdangling-pointer [PR109708]
gcc/ChangeLog
	PR c/109708
	* doc/invoke.texi (Warning Options): Fix broken example and
	clean up/reorganize the others.  Also describe what the short-form
	options mean.
2024-01-21 03:56:09 +00:00
GCC Administrator
11a5f26c4e Daily bump. 2024-01-21 00:17:42 +00:00
John David Anglin
0366231967 Remove several xfails for 32-bit hppa*-*-*
These arise because 32-bit ELF targets were changed from
callee copies to caller copies.

2024-01-20  John David Anglin  <danglin@gcc.gnu.org>

gcc/testsuite/ChangeLog:

	* gcc.dg/ipa/iinline-4.c: Remove dg-final xfail for
	32-bit hppa*-*-*.
	* gcc.dg/ipa/inline-5.c: Likewise.
	* gcc.dg/ipa/ipcp-cstagg-7.c: Likewise.
	* gcc.dg/tree-ssa/vector-4.c: Likewise.
2024-01-20 22:06:52 +00:00
John David Anglin
c9c507ff8b Increase timeout by 2 in libgomp.fortran/alloc-comp-3.f90 on hppa*-*-*
2024-01-20  John David Anglin  <danglin@gcc.gnu.org>

libgomp/ChangeLog:

	* testsuite/libgomp.fortran/alloc-comp-3.f90: Increase
	timeout by 2 on hppa*-*-*.
2024-01-20 21:47:35 +00:00
John David Anglin
584e43e434 Don't run libgomp.c/simd-math-1.c on hppa*-*-hpux*
hppa*-*-hpux* lacks necessary math functions.

2024-01-20  John David Anglin  <danglin@gcc.gnu.org>

libgomp/ChangeLog:

	* testsuite/libgomp.c/simd-math-1.c: Don't run on
	hppa*-*-hpux*.
2024-01-20 21:36:01 +00:00
John David Anglin
543b38f2ed xfail scan-tree-dump-times checks on hppa*64*-*-* in gcc.dg/tree-ssa/slsr-13.c
2024-01-20  John David Anglin  <danglin@gcc.gnu.org>

gcc/testsuite/ChangeLog:

	* gcc.dg/tree-ssa/slsr-13.c: xfail scan-tree-dump-times
	checks on hppa*64*-*-*.
2024-01-20 21:23:23 +00:00
John David Anglin
e5c5bb4390 Require target lra in gcc.dg/torture/pr110422.c
LRA is required for asm goto.

2024-01-20  John David Anglin  <danglin@gcc.gnu.org>

gcc/testsuite/ChangeLog:

	* gcc.dg/torture/pr110422.c: Require target lra.
2024-01-20 21:10:44 +00:00
Marek Polacek
7db802d972 libstdc++: suppress -Wdangling-reference with operator| [PR111410]
It seems to me that we should exclude std::ranges::views::__adaptor::operator|
from the -Wdangling-reference warning.  It's commonly used when handling
ranges.

	PR c++/111410

libstdc++-v3/ChangeLog:

	* include/std/ranges: Add #pragma to disable -Wdangling-reference with
	std::ranges::views::__adaptor::operator|.

gcc/testsuite/ChangeLog:

	* g++.dg/warn/Wdangling-reference17.C: New test.
2024-01-20 15:41:52 -05:00
Andrew Pinski
17473a93cf ipa: Add testcase for already fixed case [PR110705]
This testcase was fixed with r13-1695-gb0f02eeb906b63 which
added an Ada testcase for the issue but adding a C testcase
is a good idea and that is what this does.

Committed after making sure it passes on  x86_64-linux-gnu.

	PR ipa/110705

gcc/testsuite/ChangeLog:

	* gcc.c-torture/compile/pr110705-1.c: New test.

Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
2024-01-20 11:39:11 -08:00
Mikael Morin
6930e1f105 fortran: Restore current interface info on error [PR111291]
This change is a followup to the fix for PR48776 (namely
r14-3572-gd58150452976c4ca65ddc811fac78ef956fa96b0 AKA
fortran: Restore interface to its previous state on error [PR48776]),
which cleaned up new changes from interfaces upon error.

Unfortunately, there is one case in that fix that is mishandled, visible
on unexpected_interface.f90 with valgrind or an asan-instrumented gfortran.
when an interface statement is found while parsing an interface body (which
is invalid), the current interface is replaced by the one from the new
statement, and as parsing continues, new procedures are added
to the new interface, which has been rejected and freed, instead of the
original one.

This change restores the current interface pointer to its previous value
on each rejected statement.

	PR fortran/48776
	PR fortran/111291

gcc/fortran/ChangeLog:

	* parse.cc: Restore current interface to its previous value on error.
2024-01-20 16:35:17 +01:00
Sandra Loosemore
8fd992a3df Correct documentation for -Warray-parameter [PR102998]
gcc/ChangeLog
	PR c/102998
	* doc/invoke.texi (Option Summary): Add -Warray-parameter.
	(Warning Options): Correct/edit discussion of -Warray-parameter
	to make the first example less confusing, and fill in missing info.
2024-01-20 14:38:45 +00:00
Jakub Jelinek
efc677f3e7 lower-bitint: Handle INTEGER_CST rhs1 in handle_cast [PR113462]
The following patch ICEs because fre3 leaves around unfolded
  _1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0);
statement and in handle_cast I was expecting just SSA_NAMEs for the
large/huge _BitInt to large/huge _BitInt casts; INTEGER_CST is something
we can handle in that case exactly the same, as the handle_operand recursion
handles those.

Of course, maybe we should also try to fold_stmt such cases somewhere in
bitint lowering preparation.

2024-01-20  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/113462
	* gimple-lower-bitint.cc (bitint_large_huge::handle_cast):
	Handle rhs1 INTEGER_CST like SSA_NAME.

	* gcc.dg/bitint-76.c: New test.
2024-01-20 12:36:32 +01:00
Jakub Jelinek
291e00e2d8 tree-switch-conversion: Bugfixes for _BitInt [PR113491]
The following patch fixes various issues with large/huge _BitInt used as switch
expressions.
In particular:
1) the indexes in CONSTRUCTORs shouldn't be types with precision larger than
   sizetype precision, varasm uses wi::to_offset on those and too large
   indexes ICE; we've already checked earlier that the cluster is at most
   sizetype bits and arrays can't be larger than that anyway
2) some spots were using SCALAR_INT_TYPE_MODE or
   lang_hooks.types.type_for_mode on TYPE_MODE to determine types to use,
   that obviously doesn't work for the large/huge BITINT_TYPE
3) like the recent change in the C FE, this patch makes sure we don't create
   ARRAY_REFs with indexes with precision above sizetype precision, because
   bitint lowering isn't prepared for that and because the indexes can't be
   larger than sizetype anyway; the subtraction of the cluster minimum from
   the index obviously needs to be done in unsigned __int128 or large/huge
   BITINT_TYPE, but then we cast to sizetype if the precision is larger than
   sizetype

2024-01-20  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/113491
	* tree-switch-conversion.cc (switch_conversion::build_constructors):
	If elt.index has precision higher than sizetype, fold_convert it to
	sizetype.
	(switch_conversion::array_value_type): Return type if type is
	BITINT_TYPE with precision above MAX_FIXED_MODE_SIZE or with BLKmode.
	(switch_conversion::build_arrays): Use unsigned_type_for rather than
	lang_hooks.types.type_for_mode if utype is BITINT_TYPE with precision
	above MAX_FIXED_MODE_SIZE or with BLKmode.  If utype has precision
	higher than sizetype, use sizetype as tidx type and fold_convert the
	subtraction to sizetype.

	* gcc.dg/torture/bitint-51.c: New test.
2024-01-20 12:35:38 +01:00
Juzhe-Zhong
615e25c82d RISC-V: Suppress warning
../../gcc/config/riscv/riscv.cc: In function 'void riscv_init_cumulative_args(CUMULATIVE_ARGS*, tree, rtx, tree, int)':
../../gcc/config/riscv/riscv.cc:4879:34: error: unused parameter 'fndecl' [-Werror=unused-parameter]
4879 |                             tree fndecl,
      |                             ~~~~~^~~~~~
../../gcc/config/riscv/riscv.cc: In function 'bool riscv_vector_mode_supported_any_target_p(machine_mode)':
../../gcc/config/riscv/riscv.cc:10537:56: error: unused parameter 'mode' [-Werror=unused-parameter]
10537 | riscv_vector_mode_supported_any_target_p (machine_mode mode)
      |                                           ~~~~~~~~~~~~~^~~~
cc1plus: all warnings being treated as errors
make[3]: *** [Makefile:2559: riscv.o] Error 1

Suppress these warnings.

gcc/ChangeLog:

	* config/riscv/riscv.cc (riscv_init_cumulative_args): Suppress warning.
	(riscv_vector_mode_supported_any_target_p): Ditto.
2024-01-20 08:36:47 +08:00
GCC Administrator
c2544854ca Daily bump. 2024-01-20 00:18:14 +00:00
Mikael Pettersson
f1dea0fed9 [PATCH] Avoid ICE on m68k -fzero-call-used-regs -fpic [PR110934]
PR110934 is a problem on m68k where -fzero-call-used-regs -fpic ICEs
when clearing an FP register.

The generic code generates an XFmode move of zero to that register,
which becomes an XFmode load from initialized data, which due to -fpic
uses a non-constant address, which the backend rejects.  The
zero-call-used-regs pass runs very late, after register allocation and
frame layout, and at that point we can't allow new uses of the PIC
register or new pseudos.

To clear an FP register on m68k it's enough to do the move in SFmode,
but the generic code can't be told to do that, so this patch updates
m68k to use its own TARGET_ZERO_CALL_USED_REGS.

Bootstrapped and regression tested on m68k-linux-gnu.

Ok for master? (I don't have commit rights.)

gcc/

	PR target/110934
	* config/m68k/m68k.cc (m68k_zero_call_used_regs): New function.
	(TARGET_ZERO_CALL_USED_REGS): Define.

gcc/testsuite/

	PR target/110934
	* gcc.target/m68k/pr110934.c: New test.
2024-01-19 16:24:13 -07:00
Mikael Pettersson
a834414794 [PATCH] Avoid ICE in single-bit logical RMWs on m68k-uclinux [PR108640]
When generating RMW logical operations on m68k, the backend
recognizes single-bit operations and rewrites them as bit
instructions on operands adjusted to address the intended byte.
When offsetting the addresses the backend keeps the modes as
SImode, even though the actual access will be in QImode.

The uclinux target defines M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P
which adds a check that the adjusted operand is within the bounds
of the original object.  Since the address has been offset it is
not, and the compiler ICEs.

The bug is that the modes of the adjusted operands should have been
narrowed to QImode, which is that this patch does.  Nearby code
which narrows to HImode gets that right.

Bootstrapped and regression tested on m68k-linux-gnu.

Ok for master? (Note: I don't have commit rights.)

gcc/

	PR target/108640
	* config/m68k/m68k.cc (output_andsi3): Use QImode for
	address adjusted for 1-byte RMW access.
	(output_iorsi3): Likewise.
	(output_xorsi3): Likewise.

gcc/testsuite/

	PR target/108640
	* gcc.target/m68k/pr108640.c: New test.
2024-01-19 16:05:34 -07:00
Antoni Boucher
07b392550f libgccjit: Add missing builtins needed by optimizations
gcc/jit/ChangeLog:

	* jit-builtins.cc (ensure_optimization_builtins_exist): Add
	popcount builtins.

gcc/testsuite/ChangeLog:

	* jit.dg/all-non-failing-tests.h: New test.
	* jit.dg/test-popcount.c: New test.
2024-01-19 16:02:46 -05:00
Antoni Boucher
63736351ec libgccjit: Make is_int return false on vector types
gcc/jit/ChangeLog:

	* jit-recording.h (is_numeric_vector, vector_type::new_int): New
	functions.
	* libgccjit.cc (gcc_jit_context_new_unary_op,
	gcc_jit_context_new_binary_op): add checks for
	is_numeric_vector.

gcc/testsuite/ChangeLog:

	* jit.dg/test-reflection.c: Add check to make sure
	gcc_jit_type_is_integral returns 0 on a vector type.
2024-01-19 15:50:58 -05:00
Harald Anlauf
94b2e6cb1c Fortran: fix wrong array bounds check [PR113471]
gcc/fortran/ChangeLog:

	PR fortran/113471
	* trans-array.cc (array_bound_check_elemental): Array bounds check
	shall apply here to elemental dimensions of an array section only.

gcc/testsuite/ChangeLog:

	PR fortran/113471
	* gfortran.dg/bounds_check_24.f90: New test.
2024-01-19 21:20:44 +01:00
Jason Merrill
1338ad23ff c++: requires and using-decl [PR113498]
get_template_info was crashing because it assumed that any decl with
DECL_LANG_SPECIFIC could use DECL_TEMPLATE_INFO.  It's more complicated than
that.

	PR c++/113498

gcc/cp/ChangeLog:

	* pt.cc (decl_template_info): New fn.
	(get_template_info): Use it.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/concepts-using4.C: New test.
2024-01-19 14:21:14 -05:00
Jonathan Wakely
631a922e5c libstdc++: Do not use CTAD for _Utf32_view alias template (redux)
My change in r14-8181-g665a3ff1539ce2 was incomplete as there's a second
place using CTAD with the _Utf32_view alias template. This fixes it.

libstdc++-v3/ChangeLog:

	* include/std/format (_Spec::_M_parse_fill_and_align): Do not
	use CTAD for _Utf32_view.
2024-01-19 19:13:15 +00:00
Jonathan Wakely
502a3c03e4 libstdc++: Fix P2255R2 dangling checks for std::tuple in C++17 [PR108822]
I accidentally used && in a fold-expression instead of || which meant
that in C++17 the tuple(UElements&&...) constructor only failed its
debug assertion if all tuple elements were dangling references. Some
missing tests (noted as "TODO") meant this wasn't tested.

This fixes the fold expression and adds the missing tests.

libstdc++-v3/ChangeLog:

	PR libstdc++/108822
	* include/std/tuple (__glibcxx_no_dangling_refs) [C++17]: Fix
	wrong fold-operator.
	* testsuite/20_util/tuple/dangling_ref.cc: Check tuples with one
	element and three elements. Check allocator-extended
	constructors.
2024-01-19 19:12:38 +00:00