These macros are completely same in definition, so we can keep the previous one
and
eliminate later one.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_hard_regno_mode_ok_uncached):
Combine UNITS_PER_FP_REG and UNITS_PER_FPREG macros.
(loongarch_hard_regno_nreg
This function is always return true at the end of function implementation,
so the return value is useless.
gcc/ChangeLog:
* config/loongarch/lasx.md: Remove checking of
loongarch_expand_vec_cmp()'s
return value.
* config/loongarch/loongarch-protos.h (loongarch_expand_vec_
There's some ununsed/useless definition inside LoongArch target support
codes, these patches make a simple cleanup. Regression test passed.
Chenghui Pan (3):
LoongArch: Remove unused/useless definitions.
LoongArch: Change loongarch_expand_vec_cmp()'s return type from bool
to void.
LoongA
This patch removes some unnecessary definitions of target hook
functions according to the documentation of GCC.
gcc/ChangeLog:
* config/loongarch/loongarch-protos.h
(loongarch_cfun_has_cprestore_slot_p): Delete.
(loongarch_adjust_insn_length): Delete.
(current_section_nam
On Fri, Mar 8, 2024 at 6:50 PM Ken Matsui wrote:
>
> On Thu, Mar 7, 2024 at 10:49 PM Richard Biener
> wrote:
> >
> > On Thu, Mar 7, 2024 at 8:29 PM Ken Matsui wrote:
> > >
> > > On Tue, Mar 5, 2024 at 7:58 AM Richard Biener
> > > wrote:
> > > >
> > > > On Tue, Mar 5, 2024 at 1:51 PM Ken Matsui
On Sat, Mar 9, 2024 at 10:10 AM Alexandre Oliva wrote:
>
>
> The earlier patch for PR112938 arranged for volatile parms to be made
> indirect in internal strub wrapped bodies.
>
> The first problem that remained, more evident, was that the indirected
> parameter remained volatile, despite the indi
On Sun, Mar 10, 2024 at 10:09 PM Jeff Law wrote:
>
>
>
> On 3/10/24 3:05 PM, Andrew Pinski wrote:
> > On Sun, Mar 10, 2024 at 2:04 PM Jeff Law wrote:
> >>
> >> Here's a potential approach to fixing PR92539, a P2 -Warray-bounds false
> >> positive triggered by loop unrolling.
> >>
> >> As I specul
On Sat, Mar 09, 2024 at 12:25:42PM +0100, Richard Biener wrote:
> Ideally we’d clear TREE_ADDRESSABLE but set DECL_NOT_GIMPLE_REG,
> I think the analysis where we check the base would be a more
> appropriate place to enforce that.
So like this?
Bootstrapped/regtested on x86_64-linux and i686-linu
On Mon, Mar 11, 2024 at 8:46 AM Richard Biener
wrote:
>
> On Sun, Mar 10, 2024 at 10:09 PM Jeff Law wrote:
> >
> >
> >
> > On 3/10/24 3:05 PM, Andrew Pinski wrote:
> > > On Sun, Mar 10, 2024 at 2:04 PM Jeff Law wrote:
> > >>
> > >> Here's a potential approach to fixing PR92539, a P2 -Warray-boun
They both come from an oversight of mine in the placement of the DIE created
for an enumeration type with reverse scalar storage order.
Tested on x86-64/Linux, both GCC and GDB, applied on mainline as obvious.
2024-03-11 Eric Botcazou
PR debug/113519
PR debug/113777
On 2/29/24 13:13, Stefan Schulze Frielinghaus wrote:
> RTX X must not necessarily be a SYMBOL_REF and may e.g. be an
> UNSPEC_GOTENT for which SYMBOL_FLAG_NOTALIGN2_P fails.
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (s390_secondary_reload): Guard
> SYMBOL_FLAG_NOTALIGN2_P.
Ok. Than
On Sat, 9 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because update-address-taken subpass of
> fre5 rewrites
> _BitInt(128) b;
> vector(16) unsigned char _3;
>
>[local count: 1073741824]:
> _3 = MEM [(char * {ref-all})p_2(D)];
> MEM [(char * {ref-all})&b]
On 2/29/24 13:14, Stefan Schulze Frielinghaus wrote:
> Starting with r14-2047-gd0e891406b16dc two SI mode tests are optimized
> into DI mode. Thus, the scan-assembler directives fail. For example
> RTL expression
>
> (ior:SI (subreg:SI (lshiftrt:DI (reg:DI 69)
> (const_int 2 [0x2]))
Using dummy procedures in a target region with 'defaultmap(none)' leads to:
Error: 'g' not specified in enclosing 'target'
and this cannot be fixed by using 'firstprivate' as non-pointer dummy routines
are rejected as "Error: Object 'g' is not a variable".
Fixed by doing the same for mapping
On 2/29/24 13:15, Stefan Schulze Frielinghaus wrote:
> Starting with r14-8319-g86de9b66480b71 fwprop improved so that vpdi is
> no longer required.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/vector/long-double-to-i64.c: Fix scan
> assembler directive.
Should we perhaps rather
On 3/1/24 10:29, Stefan Schulze Frielinghaus wrote:
> Similar as to s390_lcbb, s390_vll, s390_vstl, et al. make use of a
> signed vector type for vlbb. Furthermore, a const void pointer seems
> more common and an integer for the mask.
>
> For s390_vfi(s,d)b make use of integers for masks, too.
>
On 3/1/24 16:57, Stefan Schulze Frielinghaus wrote:
> According to IBM Open XL C/C++ for z/OS version 1.1 builtins
>
> - vec_permi
> - vec_ctd
> - vec_ctsl
> - vec_ctul
> - vec_ld2f
> - vec_st2f
>
> are deprecated. Also deprecate helper builtins vec_ctd_s64 and
> vec_ctd_u64.
>
> Furthermore, t
When internal_get_tmp_var fails to gimplify the value the temporary
SSA name is supposed to be initialized with we can leak SSA names
with a NULL SSA_NAME_DEF_STMT into the IL. That's bad, so recover
from this by instead returning a decl in that case.
Bootstrapped and tested on x86_64-unknown-lin
On Mon, Mar 11, 2024 at 11:07:46AM +0100, Tobias Burnus wrote:
> Using dummy procedures in a target region with 'defaultmap(none)' leads to:
>
> Error: 'g' not specified in enclosing 'target'
>
> and this cannot be fixed by using 'firstprivate' as non-pointer dummy routines
> are rejected as "E
Tom Tromey writes:
>> "Andrew" == Andrew Burgess writes:
>
> Andrew> Tom Tromey writes:
>>> This reverts commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f.
>>>
>>> This patch caused problems for some users when building gdb, because
>>> it would cause 'guild' to be invoked with the wrong ver
Changes compared to v1:
- Added reference to r14-6517-gb7e4a4c626e in dg-bogus comment
- Changed arm-*-* to short_enums in target selector
- Updated commit message to align with above changes
As the entire block generating the warning was removed in
r14-6517-gb7e4a4c626e, does it still make sense
On Mon, 11 Mar 2024, Jakub Jelinek wrote:
> On Sat, Mar 09, 2024 at 12:25:42PM +0100, Richard Biener wrote:
> > Ideally we?d clear TREE_ADDRESSABLE but set DECL_NOT_GIMPLE_REG,
> > I think the analysis where we check the base would be a more
> > appropriate place to enforce that.
>
> So like this
On Mon, Mar 11, 2024 at 11:31:51AM +0100, Richard Biener wrote:
> On Mon, 11 Mar 2024, Jakub Jelinek wrote:
>
> > On Sat, Mar 09, 2024 at 12:25:42PM +0100, Richard Biener wrote:
> > > Ideally we?d clear TREE_ADDRESSABLE but set DECL_NOT_GIMPLE_REG,
> > > I think the analysis where we check the bas
On Mon, 11 Mar 2024, Jakub Jelinek wrote:
> On Mon, Mar 11, 2024 at 11:31:51AM +0100, Richard Biener wrote:
> > On Mon, 11 Mar 2024, Jakub Jelinek wrote:
> >
> > > On Sat, Mar 09, 2024 at 12:25:42PM +0100, Richard Biener wrote:
> > > > Ideally we?d clear TREE_ADDRESSABLE but set DECL_NOT_GIMPLE_R
Several vectorization tests FAIL on 32 and 64-bit Solaris/SPARC:
FAIL: gcc.dg/vect/pr37027.c -flto -ffat-lto-objects scan-tree-dump-times vect
"vectorized 1 loops" 1
FAIL: gcc.dg/vect/pr37027.c -flto -ffat-lto-objects scan-tree-dump-times vect
"vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/
Several gcc.dg/vect/vect-cost-model-?.c tests FAIL on 32 and 64-bit
Solaris/SPARC:
FAIL: gcc.dg/vect/vect-cost-model-1.c -flto -ffat-lto-objects scan-tree-dump
vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-cost-model-1.c scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-cost-model-3.c
On Mon, 11 Mar 2024, Rainer Orth wrote:
> Several vectorization tests FAIL on 32 and 64-bit Solaris/SPARC:
>
> FAIL: gcc.dg/vect/pr37027.c -flto -ffat-lto-objects scan-tree-dump-times
> vect "vectorized 1 loops" 1
> FAIL: gcc.dg/vect/pr37027.c -flto -ffat-lto-objects scan-tree-dump-times
> ve
On Mon, 11 Mar 2024, Rainer Orth wrote:
> Several gcc.dg/vect/vect-cost-model-?.c tests FAIL on 32 and 64-bit
> Solaris/SPARC:
>
> FAIL: gcc.dg/vect/vect-cost-model-1.c -flto -ffat-lto-objects scan-tree-dump
> vect "LOOP VECTORIZED"
> FAIL: gcc.dg/vect/vect-cost-model-1.c scan-tree-dump vect "L
On Sun, 10 Mar 2024, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu and
> aarch64-unknown-linux-gnu, OK for trunk?
>
> It's worth noting that the AArch64 machines I had available to test with
> didn't have a new enough glibc to reproduce the ICEs in the PR, but this
>
The following makes sure to pass in the SLP node for the live stmts
we are generating the reduction epilogue for to
vect_create_epilog_for_reduction. This follows the previous fix for
the non-SLP path.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
PR tree-optim
On 2024-02-16 14:47, Qing Zhao wrote:
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the C99 flexible
array member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
same structure as th
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk and release branches?
-- >8 --
r13-6452-g341e6cd8d603a3 made build_extra_args walk evaluated contexts
first so that we prefer processing a local specialization in an evaluated
context even if its first use is in an une
On 2024-02-16 14:47, Qing Zhao wrote:
Including the following changes:
* The definition of the new internal function .ACCESS_WITH_SIZE
in internal-fn.def.
* C FE converts every reference to a FAM with a "counted_by" attribute
to a call to the internal function .ACCESS_WITH_SIZE.
(buil
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
* gcc.d
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array-counted-by-bounds-2.c: New test
On 3/8/24 18:18, Nathaniel Shead wrote:
On Fri, Mar 08, 2024 at 10:19:52AM -0500, Jason Merrill wrote:
On 3/7/24 21:55, Nathaniel Shead wrote:
On Mon, Nov 27, 2023 at 03:59:39PM +1100, Nathaniel Shead wrote:
On Thu, Nov 23, 2023 at 03:03:37PM -0500, Nathan Sidwell wrote:
On 11/20/23 04:47, Na
Dear all,
the attached patch fixes an ICE-on-valid code when assigning
a procedure pointer that is a component of a DT array and
the function in question is array-valued. (The procedure
pointer itself cannot be an array.)
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From
Hi,
this is a regression present on all active branches: the attached Ada testcase
triggers an assertion failure when compiled with -O2 -gnatp -flto:
/* Initialize the static chain. */
p = DECL_STRUCT_FUNCTION (fn)->static_chain_decl;
gcc_assert (fn != current_function_decl);
if (p)
> [Public]
>
>
> Hi all,
>
>
>
> PFA, the patch that enables support for the next generation AMD Zen5 CPU via
> -march=znver5 with basic znver5 scheduler Model.
>
> We may update the scheduler model going forward.
>
>
>
> Good for trunk?
>
> Thanks and Regards
> Karthiban
>
>
> Patch i
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/13?
-- >8 --
This ICE started with the fairly complicated r13-765. We crash in
gimplify_var_or_parm_decl because a stray VAR_DECL leaked there.
The problem is ultimately that potential_prvalue_result_of wasn't
correctly handling arrays a
Previously, calling erase(key) on both std::map and std::set
would execute that same code that std::multi{map,set} would.
However, doing that is unnecessary because std::{map,set}
guarantee that all elements are unique.
It is reasonable to expect that erase(key) is equivalent
or better than:
au
On 3/11/24 4:38 PM, Eric Botcazou wrote:
Hi,
this is a regression present on all active branches: the attached Ada testcase
triggers an assertion failure when compiled with -O2 -gnatp -flto:
/* Initialize the static chain. */
p = DECL_STRUCT_FUNCTION (fn)->static_chain_decl;
gcc_as
Hi from crosstool-ng,
I've had a user report a build error for GCC 13.2.0 with and aarch64
config with libsanitizer enabled
(https://github.com/crosstool-ng/crosstool-ng/issues/2010).
[ERROR]
/home/ctng/crosstool-ng/.build/aarch64-unknown-linux-gnu/src/gcc/libsanitizer/sanitizer_common/saniti
On 3/11/24 1:46 AM, Richard Biener wrote:
On Sun, Mar 10, 2024 at 10:09 PM Jeff Law wrote:
On 3/10/24 3:05 PM, Andrew Pinski wrote:
On Sun, Mar 10, 2024 at 2:04 PM Jeff Law wrote:
Here's a potential approach to fixing PR92539, a P2 -Warray-bounds false
positive triggered by loop unrol
Add support for TLS descriptors on normal code model and extreme code model.
Normal code model instruction sequence:
-mno-explicit-relocs:
la.tls.desc $r4, s
add.d $r12, $r4, $r2
-mexplicit-relocs:
pcalau12i $r4,%desc_pc_hi20(s)
addi.d $r4,$r4,%desc_pc_lo12(s)
The patch is here:
https://sourceware.org/pipermail/gcc-patches/2024-March/647578.html,
first email was blocked by the server.
在 2024/3/11 下午4:21, mengqinggang 写道:
Add support for TLS descriptors on normal code model and extreme code model.
Normal code model instruction sequence:
-mno-expl
The behavior of non-zero unused bits in xvpermi.q instruction's
third operand is undefined on LoongArch, according to our
discussion (https://github.com/llvm/llvm-project/pull/83540),
we think that keeping original insn operand as unmodified
state is better solution.
This patch partially reverts 7
Thanks Vinnet for reminder.
> While at it, can you also add the support for feature detection macro
> |__riscv_v_fixed_vlen
Kito told me that Greg will help to add that parts. Let's wait the comments
from Kito.
Personally prefer a separated PATCH to cover that instead of appending here.
Pan
--
Hi Jeff,
Is there any suggestion(s) for how to fix this ICE in the reasonable approach?
Thanks a lot.
Pan
-Original Message-
From: Li, Pan2
Sent: Tuesday, March 5, 2024 2:23 PM
To: Jeff Law ; Robin Dapp ;
gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.
When -fmultiflags option support was added in r13-3693-g6b1a2474f9e422,
it accidently allowed -fno-multiflags which then would pass on to cc1.
This fixes that oversight.
Committed as obvious after bootstrap/test on x86_64-linux-gnu.
gcc/ChangeLog:
PR driver/114314
* common.opt (f
From: Pan Li
Update in v3:
* Add pre-defined __riscv_v_fixed_vlen when zvl.
Update in v2:
* Cleanup some unused code.
* Fix some typo of commit log.
Original log:
This patch would like to introduce one new gcc attribute for RVV.
This attribute is used to define fixed-length variants of one
exi
> -Original Message-
> From: Andrew Pinski (QUIC)
> Sent: Monday, March 11, 2024 8:59 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Andrew Pinski (QUIC)
> Subject: [Committed] Reject -fno-multiflags [PR114314]
>
> When -fmultiflags option support was added in r13-3693-g6b1a2474f9e422,
> it acci
> -Original Message-
> From: Andrew Pinski (QUIC)
> Sent: Sunday, March 10, 2024 7:58 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Andrew Pinski (QUIC)
> Subject: [COMMITTED] Fold: Fix up merge_truthop_with_opposite_arm for
> NaNs [PR95351]
>
> The problem here is that merge_truthop_with_oppos
53 matches
Mail list logo
