Non-parallel build can fail, depending on the ./configure parameters -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 .
The change below does fix the problem.
I do not understand the build system to say, that this is the best
approach, so if there are questions I might or might not be abl
在 2024/3/13 上午6:15, Xi Ruoyao 写道:
On Tue, 2024-03-12 at 17:20 +0800, mengqinggang wrote:
+(define_insn "@got_load_tls_desc"
+ [(set (match_operand:P 0 "register_operand" "=r")
+ (unspec:P
+ [(match_operand:P 1 "symbolic_operand" "")]
+ UNSPEC_TLS_DESC))
+ (clobber
On Wed, 2024-03-13 at 06:56 +0800, Xi Ruoyao wrote:
> On Wed, 2024-03-13 at 06:15 +0800, Xi Ruoyao wrote:
> > > +(define_insn "@got_load_tls_desc"
> > > + [(set (match_operand:P 0 "register_operand" "=r")
>
> Hmm, and it looks like we should use (reg:P 4) instead of match_operand
> here, because
On Tue, Mar 12, 2024 at 8:00 PM liuhongt wrote:
>
> if alignb > ASAN_RED_ZONE_SIZE and offset[0] is not multiple of
> alignb. (base_align_bias - base_offset) may not aligned to alignb, and
> caused segement fault.
>
> Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
> Ok for trunk and backpo
On Wed, 2024-03-13 at 06:15 +0800, Xi Ruoyao wrote:
> > +(define_insn "@got_load_tls_desc"
> > + [(set (match_operand:P 0 "register_operand" "=r")
Hmm, and it looks like we should use (reg:P 4) instead of match_operand
here, because the instruction does not work for a different register:
with TAR
On 3/12/24 11:56, Marek Polacek wrote:
On Tue, Mar 12, 2024 at 09:57:14AM -0400, Jason Merrill wrote:
On 3/11/24 19:27, Marek Polacek wrote:
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_
On Tue, 2024-03-12 at 17:20 +0800, mengqinggang wrote:
> +(define_insn "@got_load_tls_desc"
> + [(set (match_operand:P 0 "register_operand" "=r")
> + (unspec:P
> + [(match_operand:P 1 "symbolic_operand" "")]
> + UNSPEC_TLS_DESC))
> + (clobber (reg:SI FCC0_REGNUM))
> + (cl
Dear all,
here's another small fix: IS_CONTIGUOUS did erroneously always
return .true. for CLASS dummy arguments. The solution was to
adjust the logic in gfc_is_simply_contiguous to also handle
CLASS symbols.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 8f535b19bd0cb
Given the recent change with adding the scheduler pipeline descriptions,
many scan-dump failures emerged. Relax the expected assembler output
conditions on the affected tests to reduce noise.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul4-6.c: Disable scheduling
Hi Harald,
Roger that about the comments. The major part of my recent efforts has been
to maximise comments - apparently not always successfully!
The main reason that I want to "fix everything" is that this is it; I will
not work on this approach anymore. The gfortran/g95 founder's approach was
v
Hi Paul,
On 3/12/24 15:54, Paul Richard Thomas wrote:
Hi All,
This is the last posting of this patch before I push it. Harald is OK with
it on the grounds that the inferred_type flag guards the whole lot,
except for the chunks in trans-stmt.cc.
In spite of Harald's off-list admonition not to t
On Tue, Mar 12, 2024 at 05:21:58PM +0100, Jakub Jelinek wrote:
> On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote:
> > I am sorry for delaying this. I made the variant that simply compares
> > value range of functions and prevents merging if they diverge and wanted
> > to make some bigg
On x86, this compiles into movdqa which segfaults on unaligned access.
This kind of failure has been seen when running against glibc 2.39,
which incidentally changed the printf implementation to move away from
alloca() for this data to instead append it at the end of an existing
"scratch buffer",
Forgot to CC gcc-patches@ ML... sorry for the duplicate...
The compiler, configured with --enable-checking=yes,rtl,extra ICEs with:
internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
have 'E' (rtx unspec) in try_combine, at combine.cc:3237
This is
3236 /* Just repl
> Patch is still OK, but ipa-ICF will only identify the functions if
> static chain is unused. Perhaps just picking the winning candidate to be
> version without static chain and making ipa-inline to not ICE when calls
> with static chain lands to function with no static chain would help us
> to op
On Tue, Mar 12, 2024 at 10:46:42AM +0100, Jan Hubicka wrote:
> I am sorry for delaying this. I made the variant that simply compares
> value range of functions and prevents merging if they diverge and wanted
> to make some bigger statistics. This made me notice some performance
> problems on clan
On Thu, Feb 15, 2024 at 10:53:08PM +, Sam James wrote:
> With _FORTIFY_SOURCE >= 2 (enabled by -fhardened), vfprintf-chk-1.c's
> __vfprintf_chk ends up calling __vprintf_chk rather than vprintf.
s/__vprintf_chk/__vfprintf_chk/ above
>
> ```
> --- a/fortify.s
> +++ b/no-fortify.s
> @@ -8,27 +
Hi All,
This is a backport of g:306713c953d509720dc394c43c0890548bb0ae07.
The AArch64 vector PCS does not allow simd calls with simdlen 1,
however due to a bug we currently do allow it for num == 0.
This causes us to emit a symbol that doesn't exist and we fail to link.
Bootstrapped Regtested o
Sam James writes:
> With _FORTIFY_SOURCE >= 2 (enabled by -fhardened), vfprintf-chk-1.c's
> __vfprintf_chk ends up calling __vprintf_chk rather than vprintf.
>
> ```
> --- a/fortify.s
> +++ b/no-fortify.s
> @@ -8,27 +8,28 @@
> [...]
> __vfprintf_chk:
> [...]
> movl$1, should_optimize
On Tue, Mar 12, 2024 at 09:57:14AM -0400, Jason Merrill wrote:
> On 3/11/24 19:27, Marek Polacek wrote:
> > 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
The ordering problem was reported on #gfortran's IRC.
The warning disappears between texinfo 6.7 and 6.8 – and my bet is that
it has been caused by the texinfo commit
fa1ee0cf35 Do not warn if external node in menu is not consistent with
sections
which implies that it was done on purpose i
On Mon, Mar 11, 2024 at 11:14:04AM +0100, Andreas Krebbel wrote:
> 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-dou
Hi All,
This is the last posting of this patch before I push it. Harald is OK with
it on the grounds that the inferred_type flag guards the whole lot,
except for the chunks in trans-stmt.cc.
In spite of Harald's off-list admonition not to try to fix everything at
once, this version fixes most of
On Tue, 12 Mar 2024, Patrick Palka wrote:
> On Tue, 12 Mar 2024, Jason Merrill wrote:
>
> > On 3/11/24 12:53, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk and release branches?
> > >
> > > -- >8 --
> > >
> > > r13-6452-g341e6cd8
On Tue, 12 Mar 2024, Jason Merrill wrote:
> On 3/11/24 12:53, Patrick Palka wrote:
> > 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
> > firs
On Tue, Mar 12, 2024 at 02:31:28PM +0100, Richard Biener wrote:
> Ah, yeah, I see :/
>
> > So, the intention of edge_before_returns_twice_call is just that
> > it in the common case just finds the non-EDGE_ABNORMAL edge if there is one,
> > if there isn't just one, it adjusts the IL such that ther
On 3/11/24 12:53, Patrick Palka wrote:
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
c
The SCHEDULER_IDENT for this CPU was incorrectly
set to cortexa55, which is incorrect. This can cause
sub-optimal asm to be generated.
Ok for trunk?
gcc/ChangeLog:
PR target/114272
* config/aarch64/aarch64-cores.def (AARCH64_CORE):
Change SCHEDULER_IDENT from cortexa55 to
The following addresses endless recursion in the
chrec_fold_{plus,multiply} functions when handling sign-conversions.
We only need to apply tricks when we'd fail (there's a chrec in the
converted operand) and we need to make sure to not turn the other
operand into something worse (for the chrec-vs-
The SCHEDULER_IDENT for this CPU was incorrectly
set to cortexa55, which is incorrect. This can cause
sub-optimal asm to be generated.
Ok for trunk?
Can I also backport this to gcc-12 and gcc-13?
gcc/ChangeLog:
PR target/114272
* config/aarch64/aarch64-cores.def (AARCH64_CORE):
On 3/11/24 19:27, Marek Polacek wrote:
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_res
On Tue, 12 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> The following patch on top of the previously posted ubsan/gimple-iterator
> one handles asan the same. While the case of returning by hidden reference
> is handled differently because of the first recently posted asan patch,
> this deals with i
On Tue, 12 Mar 2024, Jakub Jelinek wrote:
> On Tue, Mar 12, 2024 at 01:47:53PM +0100, Richard Biener wrote:
> > > Admittedly the above is the ugliest part of the patch IMHO.
> > > It isn't needed in all cases, but e.g. for the pr112709-2.c (qux) case
> > > we have before ubsan pass
> > > # _7(ab
On 3/12/24 08:21, Nathaniel Shead wrote:
On Tue, Mar 12, 2024 at 11:11:40PM +1100, Nathaniel Shead wrote:
On Mon, Mar 11, 2024 at 10:36:06AM -0400, Patrick Palka wrote:
On Sun, 10 Mar 2024, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu and
aarch64-unknown-linux-gnu,
On Tue, Mar 12, 2024, at 2:15 AM, pan2...@intel.com wrote:
> 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 attri
>
>
> 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_FUNCTIO
On 3/11/24 06:23, Torbjörn SVENSSON wrote:
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
r1
On Tue, Mar 12, 2024 at 01:47:53PM +0100, Richard Biener wrote:
> > Admittedly the above is the ugliest part of the patch IMHO.
> > It isn't needed in all cases, but e.g. for the pr112709-2.c (qux) case
> > we have before ubsan pass
> > # _7(ab) = PHI <_20(9), _8(ab)(11)>
> > _22 = bar (*_7(ab)
On Tue, 12 Mar 2024, Nathaniel Shead wrote:
> On Tue, Mar 12, 2024 at 11:11:40PM +1100, Nathaniel Shead wrote:
> > On Mon, Mar 11, 2024 at 10:36:06AM -0400, Patrick Palka wrote:
> > > On Sun, 10 Mar 2024, Nathaniel Shead wrote:
> > >
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu and
>
On Tue, 12 Mar 2024, Jakub Jelinek wrote:
> On Tue, Mar 12, 2024 at 11:42:03AM +0100, Richard Biener wrote:
> > > +static edge
> > > +edge_before_returns_twice_call (basic_block bb)
> > > +{
> > > + gimple_stmt_iterator gsi = gsi_start_nondebug_bb (bb);
> > > + gcc_checking_assert (is_gimple_cal
On Tue, Mar 12, 2024 at 11:11:40PM +1100, Nathaniel Shead wrote:
> On Mon, Mar 11, 2024 at 10:36:06AM -0400, Patrick Palka wrote:
> > 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?
> > >
>
On Tue, Mar 12, 2024 at 11:42:03AM +0100, Richard Biener wrote:
> > +static edge
> > +edge_before_returns_twice_call (basic_block bb)
> > +{
> > + gimple_stmt_iterator gsi = gsi_start_nondebug_bb (bb);
> > + gcc_checking_assert (is_gimple_call (gsi_stmt (gsi))
> > + && (gimple_ca
On Mon, Mar 11, 2024 at 10:36:06AM -0400, Patrick Palka wrote:
> 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
>
if alignb > ASAN_RED_ZONE_SIZE and offset[0] is not multiple of
alignb. (base_align_bias - base_offset) may not aligned to alignb, and
caused segement fault.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
Ok for trunk and backport to GCC13?
gcc/ChangeLog:
PR sanitizer/110027
Jakub Jelinek wrote:
So firstprivate clause handling remaps them then if declare target indirect
is used? If so, the patch looks reasonable to me.
[I have now updated the patch to turn the testcase to ensure
that is also keeps works at runtime.]
OpenMP leaves it a bit open when the remapping
[Public]
Hi Honza,
> -Original Message-
> From: Jan Hubicka
> Sent: Tuesday, March 12, 2024 4:11 AM
> To: Anbazhagan, Karthiban
> Cc: gcc-patches@gcc.gnu.org; Kumar, Venkataramanan
> ; Joshi, Tejas Sanjay
> ; Nagarajan, Muthu kumar raj
> ; Gopalasubramanian, Ganesh
>
> Subject: Re: [PA
On Tue, 12 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> ubsan, asan (both PR112709) and _BitInt lowering (PR113466) want to
> insert some instrumentation or adjustment statements before some statement.
> This unfortunately creates invalid IL if inserting before a returns_twice
> call, because we requ
Hi,
I pushed this patch on Fri 8th and sent this mail to notify that I did so.
I had some trouble with sending the mail though and it didn't arrive to the
mailing list. I'm sending it now instead.
Filip Kastl
-- 8< --
ChangeLog:
* MAINTAINERS: Fix order of names in Write After Aproval
On Tue, 12 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> asan currently instruments since PR69276 r6-6758 fix calls which store
> the return value into memory on the caller side, before the call it
> verifies the memory is writable.
> Now PR112709 where we ICE on trying to instrument such calls made m
> Hi!
Hi,
>
> On Thu, Feb 15, 2024 at 08:29:24AM +0100, Jakub Jelinek wrote:
> > 2024-02-15 Jakub Jelinek
> >
> > PR middle-end/113907
> > * ipa-icf.cc (sem_item_optimizer::merge_classes): Reset
> > SSA_NAME_RANGE_INFO and SSA_NAME_PTR_INFO on successfully ICF merged
> > functi
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)
Hi!
The following patch on top of the previously posted ubsan/gimple-iterator
one handles asan the same. While the case of returning by hidden reference
is handled differently because of the first recently posted asan patch,
this deals with instrumentation of the aggregates returned in registers
Hi!
ubsan, asan (both PR112709) and _BitInt lowering (PR113466) want to
insert some instrumentation or adjustment statements before some statement.
This unfortunately creates invalid IL if inserting before a returns_twice
call, because we require that such calls are the first statement in a basic
Hi!
asan currently instruments since PR69276 r6-6758 fix calls which store
the return value into memory on the caller side, before the call it
verifies the memory is writable.
Now PR112709 where we ICE on trying to instrument such calls made me
think about whether that is what we want to do.
Ther
On Tue, 12 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> This PR is similar to PR110603 fixed with r14-8487, except in a different
> spot. From the memset with -1 size of non-zero value we determine minimum
> of (size_t) -1 and the code uses PTRDIFF_MAX - 2 (not really sure I
> understand why it is -
Hi!
This PR is similar to PR110603 fixed with r14-8487, except in a different
spot. From the memset with -1 size of non-zero value we determine minimum
of (size_t) -1 and the code uses PTRDIFF_MAX - 2 (not really sure I
understand why it is - 2 and not - 1, e.g. heap allocated array
with PTRDIFF_
Hi!
On Thu, Feb 15, 2024 at 08:29:24AM +0100, Jakub Jelinek wrote:
> 2024-02-15 Jakub Jelinek
>
> PR middle-end/113907
> * ipa-icf.cc (sem_item_optimizer::merge_classes): Reset
> SSA_NAME_RANGE_INFO and SSA_NAME_PTR_INFO on successfully ICF merged
> functions.
>
>
Committed, thanks Kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Tuesday, March 12, 2024 3:11 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
Subject: Re: [PATCH v1] RISC-V: Fix some code style issue(s) in riscv-c.cc [NFC]
LGTM :)
On Tue, Mar
Hi Harald,
This looks good to me. OK for mainline and, since it is so straightforward,
for backporting.
Thanks for the patch.
Paul
On Mon, 11 Mar 2024 at 21:20, Harald Anlauf wrote:
> Dear all,
>
> the attached patch fixes an ICE-on-valid code when assigning
> a procedure pointer that is a c
LGTM :)
On Tue, Mar 12, 2024 at 3:07 PM wrote:
>
> From: Pan Li
>
> Notice some code style issue(s) when add __riscv_v_fixed_vlen, includes:
>
> * Meanless empty line.
> * Line greater than 80 chars.
> * Indent with 3 space(s).
> * Argument unalignment.
>
> gcc/ChangeLog:
>
> * config/ri
From: Pan Li
Notice some code style issue(s) when add __riscv_v_fixed_vlen, includes:
* Meanless empty line.
* Line greater than 80 chars.
* Indent with 3 space(s).
* Argument unalignment.
gcc/ChangeLog:
* config/riscv/riscv-c.cc (riscv_ext_version_value): Fix
code style greate
61 matches
Mail list logo
