> -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
> -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
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
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
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.
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
--
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
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
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)
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
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 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
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
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
> [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
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)
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
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
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 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:
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
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:
'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
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 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
>
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 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
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
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/
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
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 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
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
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
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
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 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
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 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
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: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]))
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: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
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 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
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 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 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 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
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
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
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_
53 matches
Mail list logo
