Hi!
The first two testcases show different ways how e.g. the glibc
_FORTIFY_SOURCE wrappers are implemented, and on Winfinite-recursion-3.c
the new -Winfinite-recursion warning emits a false positive warning.
It is a false positive because when a builtin with 2 names is called
through the __built
Hi!
The following patch avoids infinite recursion during generic folding.
The (cmp (bswap @0) INTEGER_CST@1) simplification relies on
(bswap @1) actually being simplified, if it is not simplified, we just
move the bswap from one operand to the other and if @0 is also INTEGER_CST,
we apply the same
PING**2 for the ME review or at least comments to that patch,
which fixes a build issue/ICE with nvptx (at least when bumping the
default -misa).
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590139.html
(for gcc/cfgexpand.cc + gcc/expr.cc)
(There is some discussion by Tom and R
Hi Tom!
This is me again, following along GCC/nvptx devlopment, and asking
questions. ;-)
On 2022-02-19T20:07:18+0100, Tom de Vries via Gcc-patches
wrote:
> With the default ptx isa 6.0, we have for uniform-simt-1.c:
> ...
> @%r33 atom.global.cas.b32 %r26, [a], %r28, %r29;
>
For evex encoding vp{xor,or,and}, suffix is needed.
Or there would be an error for
vpxor %ymm0, %ymm31, %ymm1
Error: unsupported instruction `vpxor'
Bootstrapped and regtested x86_64-pc-linux-gnu{-m32,}.
Pushed to trunk.
gcc/ChangeLog:
* config/i386/sse.md (v1ti3): Add suffix and repla
On Wed, Feb 23, 2022 at 09:32:41AM +0100, Jakub Jelinek via Gcc-patches wrote:
> The following patch avoids infinite recursion during generic folding.
> The (cmp (bswap @0) INTEGER_CST@1) simplification relies on
> (bswap @1) actually being simplified, if it is not simplified, we just
> move the bs
From: LiaoShihua
gcc/ChangeLog:
* config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins):Add __riscv_zks,
__riscv_zk, __riscv_zkn
gcc/testsuite/ChangeLog:
* gcc.target/riscv/predef-17.c: New test.
---
gcc/config/riscv/riscv-c.cc| 9
gcc/testsuite/gcc.target/r
From: LiaoShihua
This patch set is the implementation of Crypto extension, which includes
zbkb, zbkc, zbkx,
zknd, zknh, zkne,zksed and zksh extension.
It includes instruction/md patterns, intrinsic functions, testcases for
intrinsic functions,
and test macros.
The definitio
From: LiaoShihua
gcc/ChangeLog:
* config/riscv/riscv-builtins.cc (RISCV_FTYPE_NAME2): Defined new
function prototypes.
(RISCV_FTYPE_NAME3): Ditto.
(AVAIL): Defined new riscv_builtin_avail for crypto extension.
(RISCV_ATYPE_SI): Defined new argument type.
From: LiaoShihua
gcc/ChangeLog:
* config/riscv/predicates.md (bs_operand): operand for bs
(rnum_operand):
* config/riscv/riscv.md: include crypto.md
* config/riscv/crypto.md: New file.
Co-Authored-By: Wu
---
gcc/config/riscv/crypto.md | 383 +
From: LiaoShihua
These testcases use intrinsics .
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/z
From: LiaoShihua
These headers are in https://github.com/rvkrypto/rvkrypto-fips .
gcc/ChangeLog:
* config.gcc: Add extra_headers.
* config/riscv/riscv_crypto.h: New file.
* config/riscv/riscv_crypto_scalar.h: New file.
* config/riscv/rvk_asm_intrin.h: New
On Wed, Feb 23, 2022 at 05:21:26PM +0800, liuhongt via Gcc-patches wrote:
> For evex encoding vp{xor,or,and}, suffix is needed.
>
> Or there would be an error for
> vpxor %ymm0, %ymm31, %ymm1
The insn is about V1TImode, so the error would be on
vpxor %xmm0, %xmm31, %xmm1
>
> Error: unsupported
On Wed, Feb 23, 2022 at 5:48 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Wed, Feb 23, 2022 at 05:21:26PM +0800, liuhongt via Gcc-patches wrote:
> > For evex encoding vp{xor,or,and}, suffix is needed.
> >
> > Or there would be an error for
> > vpxor %ymm0, %ymm31, %ymm1
>
> The insn is about V1T
Hello,
In line of porting the latest build of libgo/go with gcc-12 to GNU/Hurd, support
of split-stack was found to be removed.
After patching the files in libgo the build of gotools fails:
go1: error: '-fsplit-stack' currently only supported on GNU/Linux
go1: error: '-fsplit-stack' is not suppo
On Wed, 23 Feb 2022, Jakub Jelinek wrote:
> Hi!
>
> The first two testcases show different ways how e.g. the glibc
> _FORTIFY_SOURCE wrappers are implemented, and on Winfinite-recursion-3.c
> the new -Winfinite-recursion warning emits a false positive warning.
>
> It is a false positive because
On Wed, 23 Feb 2022, Jakub Jelinek wrote:
> Hi!
>
> The following patch avoids infinite recursion during generic folding.
> The (cmp (bswap @0) INTEGER_CST@1) simplification relies on
> (bswap @1) actually being simplified, if it is not simplified, we just
> move the bswap from one operand to the
On Wed, 23 Feb 2022, Jakub Jelinek wrote:
> On Wed, Feb 23, 2022 at 09:32:41AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > The following patch avoids infinite recursion during generic folding.
> > The (cmp (bswap @0) INTEGER_CST@1) simplification relies on
> > (bswap @1) actually being simplif
On Wed, Feb 23, 2022 at 11:36:26AM +0100, Richard Biener wrote:
> > The following patch avoids infinite recursion during generic folding.
> > The (cmp (bswap @0) INTEGER_CST@1) simplification relies on
> > (bswap @1) actually being simplified, if it is not simplified, we just
> > move the bswap fro
On 2/23/22 10:06, Thomas Schwinge wrote:
Hi Tom!
This is me again, following along GCC/nvptx devlopment, and asking
questions. ;-)
Yes, thanks for that, that's useful :)
On 2022-02-19T20:07:18+0100, Tom de Vries via Gcc-patches
wrote:
With the default ptx isa 6.0, we have for uniform-si
Ping :)
> This patch is sorting issue with LS64 intrinsics tests failing with
> aarch64-linux-gnu_ilp32 target.
>
> Regtested on aarch64-linux-gnu_ilp32, aarch64-elf and aarch64_be-elf
> and no issues.
>
> OK to install?
>
> gcc/ChangeLog:
>
> PR target/103729
> * con
On Wed, Feb 23, 2022 at 11:38:30AM +0100, Richard Biener wrote:
> If we go for a match.pd solution I'd go with the other one but as said
> in the PR I think we should constant fold bswap (1(OVF)) but simply
> make the (OVF) sticky as done in other constant foldings.
Changing what fold-const-call.c
The following fixes an ICE when vectorizing the defs of a CTOR
results in a different vector type than expected. That can happen
with AARCH64 SVE and a fixed vector length as noted in r10-5979
and on x86 with AVX512 mask CTORs and trying to re-vectorize
using SSE as shown in this bug.
The fix is
[ Re: [committed][nvptx] Add -mptx-comment ]
On 2/22/22 14:53, Tom de Vries wrote:
Hi,
Add functionality that indicates which insns are added by -minit-regs, such
that for instance we have for pr53465.s:
...
// #APP
// 9 "gcc/testsuite/gcc.c-torture/execute/pr53465.c" 1
// Sta
On Wed, 23 Feb 2022, Jakub Jelinek wrote:
> On Wed, Feb 23, 2022 at 11:38:30AM +0100, Richard Biener wrote:
> > If we go for a match.pd solution I'd go with the other one but as said
> > in the PR I think we should constant fold bswap (1(OVF)) but simply
> > make the (OVF) sticky as done in other
Currently we fail to parse
int * _3;
as SSA name and instead get a VAR_DECL because of the way the C
frontends declarator specs work. That causes havoc if those
supposed SSA names are used in PHIs or in other places where
VAR_DECLs are not allowed. The following fixes the pointer case
in an a
On 2/22/22 PM3:26, Richard Biener wrote:
On Tue, 22 Feb 2022, Jiufu Guo wrote:
Hi,
For constants, there are some codes to check: if it is able to put
to instruction as an immediate operand or it is profitable to load from
mem. There are still some places that could be improved for platform
Hi,
Ptx contains funnel shift operations shf.l.wrap and shf.r.wrap that can be
used to implement 32-bit left or right rotate.
Add define_insns rotlsi3 and rotrsi3.
Currently testing.
Thanks,
- Tom
[nvptx] Add shf.{l,r}.wrap insn
gcc/ChangeLog:
2022-02-23 Tom de Vries
* config/nvp
Hi!
On 2022-02-23T12:14:57+0100, Tom de Vries via Gcc-patches
wrote:
> [ Re: [committed][nvptx] Add -mptx-comment ]
>
> On 2/22/22 14:53, Tom de Vries wrote:
>> Add functionality that indicates which insns are added by -minit-regs, such
>> that for instance we have for pr53465.s:
>> ...
>>
The following patch avoids infinite recursion during generic folding.
The (cmp (bswap @0) INTEGER_CST@1) simplification relies on
(bswap @1) actually being simplified, if it is not simplified, we just
move the bswap from one operand to the other and if @0 is also INTEGER_CST,
we apply the same rule
On Wed, Feb 23, 2022 at 01:53:38PM +0100, Richard Biener wrote:
> The following patch avoids infinite recursion during generic folding.
> The (cmp (bswap @0) INTEGER_CST@1) simplification relies on
> (bswap @1) actually being simplified, if it is not simplified, we just
> move the bswap from one op
On Wed, 23 Feb 2022, guojiufu wrote:
>
>
> On 2/22/22 PM3:26, Richard Biener wrote:
> > On Tue, 22 Feb 2022, Jiufu Guo wrote:
> >
> >> Hi,
> >>
> >> For constants, there are some codes to check: if it is able to put
> >> to instruction as an immediate operand or it is profitable to load from
>
When pattern recognition fails to sanitize all defs of a mask
producing operation and the respective def is external or constant
we end up trying to produce a VECTOR_BOOLEAN_TYPE_P constructor
which in turn ends up exposing stmts like
_135 = _49 ? -1 : 0;
which isn't handled well in followup S
On 2/23/22 02:25, Richard Biener wrote:
On Tue, Feb 22, 2022 at 5:42 PM Andrew MacLeod via Gcc-patches
wrote:
Ranger currently waits until the end of the VRP pass, then calls
export_global_ranges ().
This method walks the list of ssa-names looking for names which it
thinks should have SSA_NAME
On 2/23/22 02:33, Richard Biener wrote:
On Tue, Feb 22, 2022 at 5:42 PM Andrew MacLeod via Gcc-patches
wrote:
This patch simply leverages the existing computation machinery to
re-evaluate values dependent on a newly found non-null value
Ranger associates a monotonically increasing temporal val
Hi,
The patch for adding the has_device_addr clause on the target construct was
recently committed (bbb7f8604e1dfc08f44354cfd93d2287f2fdd489).
Additionally, this patch adds support for list items in the has_device_addr
clause which type is given by C++ template parameters.
Marcel
--
On 2/23/22 02:48, Richard Biener wrote:
On Tue, Feb 22, 2022 at 8:19 PM Andrew MacLeod via Gcc-patches
wrote:
On 2/22/22 13:07, Jeff Law wrote:
On 2/22/2022 10:57 AM, Jakub Jelinek via Gcc-patches wrote:
On Tue, Feb 22, 2022 at 12:39:28PM -0500, Andrew MacLeod wrote:
That is EH, then there
Hi, Richard,
> On Feb 23, 2022, at 1:38 AM, Richard Biener wrote:
>
> On Tue, 22 Feb 2022, Qing Zhao wrote:
>
>> __builtin_clear_padding(&object) will clear all the padding bits of the
>> object.
>> actually, it doesn't involve any use of an user variable. Therefore, users do
>> not expect any
Fixed with r10-1280.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/70077
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept76.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/noexcept76.C | 17 +
1 file changed, 17 insertions(+)
create mode 100644 gcc/testsuit
Hello,
The following patch is a testcase for PR93432,which deals with the
warning for uninitialized variables.The testcase is for the bug
already fixed.
Regtested on x86_64, OK for commit ? Please do review it.
2022-02-23 Krishna Narayanan
PR c/93432
gcc/testsuite/Changelog:
*gcc.dg/pr93432.c:
A nice side effect of r12-1822 was improving the diagnostic
we emit for the following test.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/79493
gcc/testsuite/ChangeLog:
* g++.dg/diagnostic/undeclared1.C: New test.
---
gcc/testsuite/g++.dg/diagnostic/undeclared1.C | 7 ++
On Wed, Feb 23, 2022 at 05:33:57PM +, Qing Zhao wrote:
> From my understanding, __builtin_clear_padding (&object), does not _use_ any
> variable,
> therefore, no uninitialized usage warning should be emitted for it.
__builtin_clear_padding (&object)
sometimes expands to roughly:
*(int *)((c
This patch changes the build machinery in order to disable the build
of GCOV (both compiler and libgcc) in bpf-*-* targets. The reason for
this change is that BPF is (currently) too restricted in order to
support the coverage instrumentalization.
Tested in bpf-unknown-none and x86_64-linux-gnu ta
On Feb 23 2022, Jose E. Marchesi wrote:
> diff --git a/gcc/configure.ac b/gcc/configure.ac
> index 06750cee977..a892e170997 100644
> --- a/gcc/configure.ac
> +++ b/gcc/configure.ac
> @@ -1042,6 +1042,12 @@ AC_SUBST(enable_shared)
> AC_ARG_ENABLE(gcov,
> [ --disable-gcov don't provide l
> On Feb 23 2022, Jose E. Marchesi wrote:
>
>> diff --git a/gcc/configure.ac b/gcc/configure.ac
>> index 06750cee977..a892e170997 100644
>> --- a/gcc/configure.ac
>> +++ b/gcc/configure.ac
>> @@ -1042,6 +1042,12 @@ AC_SUBST(enable_shared)
>> AC_ARG_ENABLE(gcov,
>> [ --disable-gcov don
This patch changes the build machinery in order to disable the build
of GCOV (both compiler and libgcc) in bpf-*-* targets. The reason for
this change is that BPF is (currently) too restricted in order to
support the coverage instrumentalization.
Tested in bpf-unknown-none and x86_64-linux-gnu ta
> On Feb 23, 2022, at 11:49 AM, Jakub Jelinek wrote:
>
> On Wed, Feb 23, 2022 at 05:33:57PM +, Qing Zhao wrote:
>> From my understanding, __builtin_clear_padding (&object), does not _use_ any
>> variable,
>> therefore, no uninitialized usage warning should be emitted for it.
>
> __builti
On Wed, Feb 23, 2022 at 02:02:59PM +0100, Richard Biener wrote:
> I'm assuming we're always dealing with
>
> (set (reg:MODE ..) )
>
> here and CSE is not substituting into random places of an
> instruction(?). I don't know what 'rtx_cost' should evaluate
> to for a constant, if it should impli
>
> On 2/22/2022 10:57 AM, Jakub Jelinek via Gcc-patches wrote:
> > On Tue, Feb 22, 2022 at 12:39:28PM -0500, Andrew MacLeod wrote:
> >>> That is EH, then there are calls that might not return because they leave
> >>> in some other way (e.g. longjmp), or might loop forever, might exit, might
> >>>
On Wed, Feb 23, 2022 at 07:32:55PM +0800, guojiufu wrote:
> >We already have TARGET_INSN_COST which you could ask for a cost.
> >Like if we'd have a single_set then just temporarily substitute
> >the RHS with the candidate and cost the insns and compare against
> >the original insn cost. So why ex
On Mon, 07 Feb 2022 16:48:41 PST (-0800), patr...@rivosinc.com wrote:
RISC-V has no support for subword atomic operations; code currently
generates libatomic library calls.
This patch changes the default behavior to inline subword atomic calls
(using the same logic as the existing library call).
Dear Fortranners,
Fortran 2018 added a QUIET= specifier to STOP and ERROR STOP statements.
Janne already implemented the library side code four (4!) years ago,
but so far the frontend implementation was missing.
Furthermore, F2018 allows for non-default-integer stopcode expressions
(finally!).
T
When compiling Linux kernel with -fcf-protection=branch to enable x86
Indiret Branch Tracking (IBT), ENDBR is added to all global functions.
This creates more "legal" forward edges than necessary. -mmanual-endbr
provides a way to insert ENDBR instruction at function entry only via
the 'cf_check' f
Skip the 4-byte ENDBR when emitting a direct call/jmp to a local function
with ENDBR at function entry.
This has been tested on Linux kernel.
gcc/
PR target/102953
* config/i386/i386-features.cc
(rest_of_insert_endbr_and_patchable_area): Set
SYMBOL_FLAG_FUNCTION_E
Am 16.02.22 um 22:20 schrieb Harald Anlauf via Gcc-patches:
Dear Fortranners,
while we detect invalid uses of type(*), we may run into other issues
later when the declared variable is used, leading to an ICE due to a
NULL pointer dereference. This is demonstrated by Gerhard's testcase.
Steve a
On Feb 21, 2022, Richard Biener wrote:
>> Ok to revert commit r12-5852-g50e8b0c9bca6cdc57804f860ec5311b641753fbb
> OK. Please re-open the bug as appropriate.
Thanks. I've reopened it. Here's what I'm installing. I'm not
reverting the testcase, since it stopped failing even before the patch
When we duplicate a throwing compare for hardening, the EH edge from
the original compare gets duplicated for the inverted compare, but we
failed to adjust any PHI nodes in the EH block. This patch adds the
needed adjustment, copying the PHI args from those of the preexisting
edge.
Regstrapped
In def_cfa_0, we may set the 2nd operand's dw_cfi_cfa_loc to NULL, but
then cfi_oprnd_equal_p calls cfa_equal_p with a NULL dw_cfa_location*.
This patch aranges for us to tolerate NULL dw_cfi_cfa_loc.
Regstrapped on x86_64-linux-gnu. Ok to install?
for gcc/ChangeLog
PR middle-end/10
This problem was already fixed as part of PR104263: the abnormal edge
that remained from before inlining didn't make sense after inlining.
So this patch adds only the testcase.
Regstrapped on x86_64-linux-gnu. Ok to install?
for gcc/testsuite/ChangeLog
PR tree-optimization/103845
On Thu, Feb 17, 2022 at 05:38:07PM -0600, Segher Boessenkool wrote:
> Hi!
>
> First, you need to adjust after Robin's patch, and retest.
Robin's patch has the effct making rs6000_emit_int_cmove return false for
floating point comparisons, so I marked the bug as being a duplicate of PR
target/1043
When testing -fanalyzer on openblas-0.3, I noticed slightly over 2000
false positives from -Wanalyzer-malloc-leak on code like this:
if( LAPACKE_lsame( vect, 'b' ) || LAPACKE_lsame( vect, 'p' ) ) {
pt_t = (lapack_complex_float*)
LAPACKE_malloc( sizeof(lapack_com
On 2/23/22 2:21 PM, Harald Anlauf via Fortran wrote:
Dear Fortranners,
Fortran 2018 added a QUIET= specifier to STOP and ERROR STOP statements.
Janne already implemented the library side code four (4!) years ago,
but so far the frontend implementation was missing.
Furthermore, F2018 allows for
Ping.
Qing
Begin forwarded message:
From: Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>>
Subject: [PATCH 1/2][middle-end/102276] Don't emit switch-unreachable warnings
for -ftrivial-auto-var-init (PR102276)
Date: February 19, 2022 at 10:22:43 AM CST
To: richard Biener mailto:rguent
Ping...
Qing
Begin forwarded message:
From: Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>>
Subject: [PATCH 2/2][middle-end/102276] Adding -Wtrivial-auto-var-init and
update documentation.
Date: February 19, 2022 at 10:24:09 AM CST
To: richard Biener mailto:rguent...@suse.de>>, Jaku
Segher Boessenkool writes:
> On Wed, Feb 23, 2022 at 02:02:59PM +0100, Richard Biener wrote:
>> I'm assuming we're always dealing with
>>
>> (set (reg:MODE ..) )
>>
>> here and CSE is not substituting into random places of an
>> instruction(?). I don't know what 'rtx_cost' should evaluate
>>
Jiufu Guo via Gcc-patches writes:
> Segher Boessenkool writes:
>
>> On Wed, Feb 23, 2022 at 02:02:59PM +0100, Richard Biener wrote:
>>> I'm assuming we're always dealing with
>>>
>>> (set (reg:MODE ..) )
>>>
>>> here and CSE is not substituting into random places of an
>>> instruction(?). I
Hi,
> Robin's patch has the effct making rs6000_emit_int_cmove return false for
> floating point comparisons, so I marked the bug as being a duplicate of PR
> target/104335.
Didn't I just return false for MODE_CC? This should not affect proper
floating-point comparisons. It looks like the probl
Segher Boessenkool writes:
> On Wed, Feb 23, 2022 at 07:32:55PM +0800, guojiufu wrote:
>> >We already have TARGET_INSN_COST which you could ask for a cost.
>> >Like if we'd have a single_set then just temporarily substitute
>> >the RHS with the candidate and cost the insns and compare against
>>
68 matches
Mail list logo
