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
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;
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
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:
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
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]
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;
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:
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
> [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
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,
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
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.
*
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.
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
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
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
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
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
>
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:
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:
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
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
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
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
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
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
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
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,
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
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})]
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.
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
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
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
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
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.
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.
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.
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
50 matches
Mail list logo
