No, that error is fixed by some earlier patches sent early last week that are
awaiting review :)
From: Toon Moene
Sent: Sunday, January 7, 2024 7:11 PM
To: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH]middle-end: thread through existing LCSSA variable for
altern
Conditional moves are not available in SPARC V8.
gcc/testsuite/ChangeLog:
* gcc.dg/ifcvt-4.c: Skip for SPARC V8
---
gcc/testsuite/gcc.dg/ifcvt-4.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/ifcvt-4.c b/gcc/testsuite/gcc.dg/ifcvt-4.c
index 8b2583d00e92..99ed3
After commit 01f4251b8775c832a92d55e2df57c9ac72eaceef, early break
vectorization is supported. The two testcases need to be fixed.
gcc/testsuite/ChangeLog:
* gcc.target/i386/avx512fp16-xorsign-1.c: Fix testcase.
* gcc.target/i386/part-vect-absneghf.c: Ditto.
---
gcc/testsuite/gcc
Patch v8: Resubmit after fix the rtl-checking issue. Passed all the riscv
regression test.
Patch v7: Add newline at the end of file.
Patch v6: Move intrinsic tests into rvv/base.
Patch v5: Rebase
Patch v4: Add some RV32 vx constraint testcase.
Patch v3: Refine crypto vector api-testing cases.
Patc
Patch v7:Resubmit after fix trl-checking issue. Passed all the riscv regression
test.
Patch v6:Remove unused code.
Patch v5:Rebase.
Patch v4:Merge crypto vector function.def into vector.
Patch v3:Define a shape for vaesz and merge vector-crypto-types.def
into riscv-vector-builtins-types.d
> pr88077 fails on SPARC since char HeaderStr[1] in pr88077_1.c and
> long HeaderStr in pr88077_0.c differs in alignment.
>
> warning: alignment 4 of normal symbol `HeaderStr' in c_lto_pr88077_0.o is
> smaller than 8 used by the common definition in c_lto_pr88077_1.o
I have never seen it though.
> On 6 Jan 2024, at 22:30, Nathan Sidwell wrote:
>
> Richard Smith & I discussed whether we should use the module interface's
> capability of giving vague linkage entities a strong location. I didn't want
> to go messing with that, 'cos it was changing yet more stuff.
>
> But, perhaps we sh
> LEON5 has a deeper write-buffer and hence stb is not enough to flush a
> write out. For compatibility, use the default V8 approach for both
> LEON3 and LEON5.
>
> This reverts commit 49cc765db35a5a21cab2aece27a44983fa70b94b,
> "sync.md (*membar_storeload_leon3): New insn."
>
> gcc/ChangeLog:
>
On 06/01/2024 21:20, Tobias Burnus wrote:
Hi Andrew,
I just spotted that this define was missing.
OK for mainline?
OK.
Andrew
Bootstrap and regtest running on x86_64-redhat-linux,
ppc64le-redhat-linux and s390x-redhat-linux. Ok for trunk when
successful?
Using ASAN on i686-linux with -fPIC causes an ICE, because when
pc_thunks are generated, there is no current function anymore, but
asan_function_start () expects one.
> This is to handle the membar_empty instruction that can be generated
> when compiling for UT699.
>
> gcc/ChangeLog:
>
> * config/sparc/sparc.cc (next_active_non_empty_insn): Length 0 treated
> as empty
OK without the superfluous parentheses.
--
Eric Botcazou
> LEON now uses the standard V8 membar patterns that contains an ldstub
> instruction. This instruction needs to be aligned properly when the
> GR712RC errata workaround is enabled.
>
> gcc/ChangeLog:
>
> * config/sparc/sparc.cc (atomic_insn_for_leon3_p): Treat
membar_storeload as atomic
>
On Mon, Jan 08, 2024 at 10:22:57AM +0100, Ilya Leoshkevich wrote:
> Bootstrap and regtest running on x86_64-redhat-linux,
> ppc64le-redhat-linux and s390x-redhat-linux. Ok for trunk when
> successful?
>
>
>
> Using ASAN on i686-linux with -fPIC causes an ICE, because when
> pc_thunks are genera
It was noticed that -mmovbe doesn't use movbe for __builtin_bswap{32,64}
when not optimizing. The follownig adjusts the documentation to
say it will be used for optimizing and applies to all byte swaps,
not just those carried out via builtin function calls.
OK?
Thanks,
Richard.
* doc/in
On Thu, Jan 04, 2024 at 03:39:15PM -0500, Patrick Palka wrote:
> On Sun, 3 Dec 2023, Nathaniel Shead wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > -- >8 --
> >
> > The TYPE_DECL_SUPPRESS_DEBUG and DECL_EXTERNAL flags use the same
> > underlying bit. This i
This patch fixes a runtime error with offload kernels that use a lot of
registers, such as libgomp.fortran/target1.f90.
Committed to mainline.
Andrewamdgcn: Don't double-count AVGPRs
CDNA2 devices have VGPRs and AVGPRs combined into a single hardware register
file (they're seperate in CDNA1).
This patch fixes build failures with the offload toolchain since my
recent XNACK patch. The problem was simply that mkoffload made
out-of-date assumptions about the -mxnack defaults. This patch fixes the
mismatch.
Committed to mainline.
Andrewamdgcn: Don't double-count AVGPRs
CDNA2 devices h
On 07/01/2024 19:20, Tobias Burnus wrote:
ROCm meanwhile supports also some consumer cards; besides the semi-new
gfx1030, support for gfx1100 was added more recently (in ROCm 5.7.1 for
"Ubuntu 22.04 only" and without parenthesis since ROCm 6.0.0).
GCC has already very limited support for gfx10
On 1/5/24 11:47, Richard Sandiford wrote:
Victor Do Nascimento writes:
The armv9.4-a architectural revision adds three new atomic operations
associated with the LSE128 feature:
* LDCLRP - Atomic AND NOT (bitclear) of a location with 128-bit
value held in a pair of registers, with orig
On Tue, Jan 2, 2024 at 2:37 PM wrote:
>
> From: Pan Li
>
> According to the sematics of no-signed-zeros option, the backend
> like RISC-V should treat the minus zero -0.0f as plus zero 0.0f.
>
> Consider below example with option -fno-signed-zeros.
>
> void
> test (float *a)
> {
> *a = -0.0;
>
Hi everyone,
This patch address the problem reported in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113225
Looking forward to your review.
Cheers,
Cupertino
This patch fix a problem with kernel_helper attribute BTF information,
which incorrectly generates BTF_KIND_FUNC entry.
This BTF entry
Hi everyone,
This patch adds a comment to the BTF strings regarding their position
within the section. This is useful for assembly inspection purposes.
Regards,
Cupertino
When using -dA, this function was only printing as comment btf_string or
btf_aux_string.
This patch changes the comment to al
The following avoids creating a niter peeling epilog more consistently,
matching what peeling later uses for the skip_vector condition, in
particular when versioning is required which then also ensures the
vector loop is entered unless the epilog is vectorized. This should
ideally match LOOP_VINFO
On Sat, 6 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs during regimplificatgion since the addition of
> (convert (eqne zero_one_valued_p@0 INTEGER_CST@1))
> simplification. That simplification is novel in the sense that in
> gimplify_expr it can turn an expression (compar
On 2024-01-08 10:20, Eric Botcazou wrote:
pr88077 fails on SPARC since char HeaderStr[1] in pr88077_1.c and
long HeaderStr in pr88077_0.c differs in alignment.
warning: alignment 4 of normal symbol `HeaderStr' in c_lto_pr88077_0.o is
smaller than 8 used by the common definition in c_lto_pr88077_
On Mon, Jan 8, 2024 at 3:35 AM Kewen.Lin wrote:
>
> Hi,
>
> As PR113100 shows, the unbiasing introduced by r14-6737 can
> cause the scrubbing to overrun and screw some critical data
> on stack like saved toc base consequently cause segfault on
> Power.
>
> By checking PR112917, IMHO we should keep
Jeff Law writes:
> The other issue that's been in the back of my mind is costing. But I
> think the model here is combine without regards to cost.
No, it does take costing into account. For size, it's the usual
"sum up the before and after insn costs and see which one is lower".
For speed, the
On Mon, Jan 8, 2024 at 10:58 AM Nathaniel Shead
wrote:
>
> On Thu, Jan 04, 2024 at 03:39:15PM -0500, Patrick Palka wrote:
> > On Sun, 3 Dec 2023, Nathaniel Shead wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > >
> > > -- >8 --
> > >
> > > The TYPE_DECL_SUPPRES
On Fri, 29 Dec 2023, Tamar Christina wrote:
> Hi All,
>
> We can't support nonlinear inductions other than neg when vectorizing
> early breaks and iteration count is known.
>
> For early break we currently require a peeled epilog but in these cases
> we can't compute the remaining values.
>
> B
On Fri, 29 Dec 2023, Tamar Christina wrote:
> Hi All,
>
> Only trying to update certain dominators doesn't seem to work very well
> because as the loop gets versioned, peeled, or skip_vector then we end up with
> very complicated control flow. This means that the final merge blocks for the
> loo
On 1/5/24 11:10, Richard Sandiford wrote:
Victor Do Nascimento writes:
The introduction of further architectural-feature dependent ifuncs
for AArch64 makes hard-coding ifunc `_i' suffixes to functions
cumbersome to work with. It is awkward to remember which ifunc maps
onto which arch featur
On Fri, 29 Dec 2023, Tamar Christina wrote:
> Hi All,
>
> This patch fixes several interconnected issues.
>
> 1. When picking an exit we wanted to check for niter_desc.may_be_zero not
> true.
>i.e. we want to pick an exit which we know will iterate at least once.
>However niter_desc.may
On Tue, 2 Jan 2024, Tamar Christina wrote:
> Hi All,
>
> I was generating the vector reverse mask without checking if the target
> actually supported such an operation.
>
> It also seems like more targets implement VEC_EXTRACT than permute on mask
> registers.
>
> So this adds a check for IFN_V
On Thu, 4 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> _BitInt lowering for .{ADD,SUB,MUL}_OVERFLOW calls which have both
> REALPART_EXPR and IMAGPART_EXPR used and have a cast from the IMAGPART_EXPR
> to a boolean or normal integral type lowers them at the point of
> the REALPART_EXPR statement (whi
On Thu, 4 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> The PHI argument expansion of INTEGER_CSTs where bitint_min_cst_precision
> returns significantly smaller precision than the PHI result precision is
> optimized by loading the much smaller constant (if any) from memory and
> then either setting t
Hi All,
In C you can have loops without a condition, the original version of the patch
was rejecting the use of #pragma GCC novector, however during review it was
changed to not due this with the reason that we didn't want to give a compile
error with such cases.
However because annotations seem
On Thu, 4 Jan 2024, Jan Hubicka wrote:
> Hi,
> this patch adds new option -falign-all-functions which works like
> -falign-functions, but applies to all functions including those in cold
> regions. As discussed in the PR log, this is needed for atomically
> patching function entries in the kernel
Hi,
>> Is there no benefit to using SWPPL for RELEASE here? Similarly for the
>> others.
>
> We started off implementing all possible memory orderings available.
> Wilco saw value in merging less restricted orderings into more
> restricted ones - mainly to reduce codesize in less frequently use
Thank you for reviewing my patches and merging XCVelw.
This patch series presents the comprehensive implementation of the BI
extension for CORE-V.
Tested with riscv-gnu-toolchain on binutils, ld, gas and gcc testsuites to
ensure its correctness and compatibility with the existing codebase.
Howeve
Spec:
github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
Contributors:
Mary Bennett
Nandni Jamnadas
Pietra Ferreira
Charlie Keaney
Jessica Mills
Craig Blackmore
Simon Cook
Jeremy Bennett
Helene Chelin
gcc/ChangeLog:
* common/config/
On Mon, Dec 11, 2023 at 03:13:03PM +, Richard Ball wrote:
> ACLE has added intrinsics to bridge between SVE and Neon.
>
> The NEON_SVE Bridge adds intrinsics that allow conversions between NEON and
> SVE vectors.
>
> This patch adds support to GCC for the following 3 intrinsics:
> svset_neonq
> -Original Message-
> From: Richard Biener
> Sent: Monday, January 8, 2024 11:29 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Tamar Christina
> Subject: [PATCH] tree-optimization/113026 - avoid vector epilog in more cases
>
> The following avoids creating a niter peeling epilog more consisten
> -Original Message-
> From: Richard Biener
> Sent: Monday, January 8, 2024 12:07 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH]middle-end: rejects loops with nonlinear inductions and
> early
> breaks [PR113163]
>
> On Fri, 29 D
Do you know how to build a ISA string with following extension?
- g
- c
- zba
- zbs
- svnapot
- zve64d
- zvl128b
Don't trial and error with your gcc and don't read RISC-V ISA spec! OK, I
believe it's impossible for most people, even I work for RISC-V so many years,
I remember most of the rule
-march was require canonical order before, however it's not easy for
most user when we have so many extension, so this patch is relax the
constraint, -march accept the ISA string in any order, it only has few
requirement:
1. Must start with rv[32|64][e|i|g].
2. Multi-letter and single letter exten
Minor refactor, preparation for further change.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::parse_base_ext): New.
(riscv_subset_list::parse): Extract part of logic into
riscv_subset_list::parse_base_ext.
* config/riscv/riscv-sub
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::parse_std_ext): Remove.
(riscv_subset_list::parse_multiletter_ext): Remove.
* config/riscv/riscv-subset.h
(riscv_subset_list::parse_std_ext): Remove.
(riscv_subset_list::parse_m
We has relaxed -march string, it no longer require canonical order, so
we need update some of those testcase.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/arch-23.c: Update test.
* gcc.target/riscv/arch-27.c: Ditto.
* gcc.target/riscv/arch-28.c: Ditto.
* gcc.target/
---
gcc/doc/invoke.texi | 16
1 file changed, 16 insertions(+)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 68d1f364ac0..81ee7ac758a 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -30037,6 +30037,22 @@ Generate code for given RISC-V ISA (e.g.@:
@sa
On Mon, Jan 8, 2024 at 10:56 AM Richard Biener wrote:
>
> It was noticed that -mmovbe doesn't use movbe for __builtin_bswap{32,64}
> when not optimizing. The follownig adjusts the documentation to
> say it will be used for optimizing and applies to all byte swaps,
> not just those carried out via
> -Original Message-
> From: Richard Biener
> Sent: Monday, January 8, 2024 12:38 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH]middle-end: maintain LCSSA form when peeled vector
> iterations have virtual operands
>
> On Fri, 29
> -Original Message-
> From: Richard Biener
> Sent: Monday, January 8, 2024 12:48 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH]middle-end: check if target can do extract first for
> early breaks
> [PR113199]
>
> On Tue, 2 Jan 2
Hi Andrew,
Andrew Stubbs wrote:
OK for mainline ?
This looks fine to me. I know there will be things that need fixing for
both experimental architectures.
Indeed. I tried to be a bit more verbose also to avoid too high
expectations by occasional gcc-patches@ readers.
P.S. Apologies, b
Hi jasonwucj,
> -Original Message-
> From: Chung-Ju Wu
> Sent: Monday, January 8, 2024 6:16 AM
> To: gcc-patches ; Kyrylo Tkachov
> ; Richard Earnshaw
> Cc: jason...@anshingtek.com.tw
> Subject: [PATCH 1/2] arm: Add cortex-m52 core
>
> Hi,
>
> Recently, Arm announced the Cortex-M52, de
> -Original Message-
> From: Chung-Ju Wu
> Sent: Monday, January 8, 2024 6:17 AM
> To: gcc-patches ; Kyrylo Tkachov
> ; Richard Earnshaw
> Cc: jason...@anshingtek.com.tw
> Subject: [PATCH 2/2] arm: Add cortex-m52 doc
>
> Hi,
>
> This is the patch to add cortex-m52 in the Arm-related o
Wilco Dijkstra writes:
> Hi,
>
>>> Is there no benefit to using SWPPL for RELEASE here? Similarly for the
>>> others.
>>
>> We started off implementing all possible memory orderings available.
>> Wilco saw value in merging less restricted orderings into more
>> restricted ones - mainly to reduce
Instead of converting XOR or PLUS of two values, ANDed with two constants that
have no bits in common, to IOR expression, convert IOR or XOR of said two
ANDed values to PLUS expression.
If we consider the following testcase:
--cut here--
unsigned int foo (unsigned int a, unsigned int b)
{
unsig
On Mon, 8 Jan 2024, Nathaniel Shead wrote:
> On Thu, Jan 04, 2024 at 03:39:15PM -0500, Patrick Palka wrote:
> > On Sun, 3 Dec 2023, Nathaniel Shead wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > >
> > > -- >8 --
> > >
> > > The TYPE_DECL_SUPPRESS_DEBUG and
Victor Do Nascimento writes:
> On 1/5/24 11:10, Richard Sandiford wrote:
>> Victor Do Nascimento writes:
>>> The introduction of further architectural-feature dependent ifuncs
>>> for AArch64 makes hard-coding ifunc `_i' suffixes to functions
>>> cumbersome to work with. It is awkward to remembe
Jeff Law writes:
>>> +
>>> +/* Initialization of the ext-dce pass. Primarily this means
>>> + setting up the various bitmaps we utilize. */
>>> +
>>> +static void
>>> +ext_dce_init (void)
>>> +{
>>> +
>>
>> Nit: excess blank line.
> Various nits have been fixed. I think those are all mine.
Bootstrapping GCC on arm-linux-gnueabihf with --with-arch=armv6 currently
has a large number of FAILs in libatomic (regressions since last time I
attempted this). The failure mode is related to IFUNC handling with the
file tas_8_2_.o containing an unresolved reference to the function
libat_test_a
Tested x86_64-linux, pushed to trunk.
-- >8 --
The name __null_sentinel is defined as a macro by newlib, so we can't
use it as an identifier. That variable is not actually used by
libstdc++, it was added because P2728R6 proposes std::uc::null_sentinel.
Since we don't need it and it breaks bootstr
On 1/8/24 04:52, Richard Sandiford wrote:
Jeff Law writes:
The other issue that's been in the back of my mind is costing. But I
think the model here is combine without regards to cost.
No, it does take costing into account. For size, it's the usual
"sum up the before and after insn costs
(Sorry, never a bringer of good news...)
> From: Jonathan Wakely
> Date: Mon, 8 Jan 2024 01:15:50 +
> Tested x86_64-linux and aarch64-linux. Pushed to trunk.
>
> -- >8 --
>
> This change ensures that char and wchar_t arguments are formatted
> consistently when using integer presentation t
> From: Hans-Peter Nilsson
> Date: Mon, 8 Jan 2024 17:24:35 +0100
> For some reason, this (r14-6990-g74a0dab18292be) breaks a
> build of (newlib targets) at least cris-elf and arm-eabi:
...aaand, just now fixed in r14-7007-geb846114ed7c49.
(Thanks!)
brgds, H-P
Hi Richard,
>> Benchmarking showed that LSE and LSE2 RMW atomics have similar performance
>> once
>> the atomic is acquire, release or both. Given there is already a significant
>> overhead due
>> to the function call, PLT indirection and argument setup, it doesn't make
>> sense to add
>> extra
> > + if (is_gimple_min_invariant (op))
> > + return true;
> > + if (SSA_NAME_IS_DEFAULT_DEF (op)
> > + || !flow_bb_inside_loop_p (loop, gimple_bb (SSA_NAME_DEF_STMT
> (op
> > + return true;
> > + return gimple_uid (SSA_NAME_DEF_STMT (op)) & 1;
> > +}
On Mon, 8 Jan 2024 at 16:28, Hans-Peter Nilsson wrote:
>
> > From: Hans-Peter Nilsson
> > Date: Mon, 8 Jan 2024 17:24:35 +0100
>
> > For some reason, this (r14-6990-g74a0dab18292be) breaks a
> > build of (newlib targets) at least cris-elf and arm-eabi:
>
> ...aaand, just now fixed in r14-7007-geb8
On Mon, 8 Jan 2024 at 16:25, Hans-Peter Nilsson wrote:
>
> (Sorry, never a bringer of good news...)
Regarding this bit ... even if you're reporting something I've broken,
I like to see it as an incremental step towards better portability, so
it's always good news ;-)
On Mon, Jan 8, 2024 at 6:44 AM Uros Bizjak wrote:
>
> Instead of converting XOR or PLUS of two values, ANDed with two constants that
> have no bits in common, to IOR expression, convert IOR or XOR of said two
> ANDed values to PLUS expression.
I think this only helps targets which have leal like
Jeff Law writes:
> On 1/8/24 04:52, Richard Sandiford wrote:
>> Jeff Law writes:
>>> The other issue that's been in the back of my mind is costing. But I
>>> think the model here is combine without regards to cost.
>>
>> No, it does take costing into account. For size, it's the usual
>> "sum u
On 1/8/24 09:57, Andrew Pinski wrote:
On Mon, Jan 8, 2024 at 6:44 AM Uros Bizjak wrote:
Instead of converting XOR or PLUS of two values, ANDed with two constants that
have no bits in common, to IOR expression, convert IOR or XOR of said two
ANDed values to PLUS expression.
I think this on
On Mon, 8 Jan 2024, Nathaniel Shead wrote:
> On Sat, Jan 06, 2024 at 05:32:37PM -0500, Nathan Sidwell wrote:
> > I;m not sure about this, there was clearly a reason I did it the way it is,
> > but perhaps that reasoning became obsolete -- something about an existing
> > declaration and reading in
Hi Cupertino,
On 1/8/24 02:55, Cupertino Miranda wrote:
> Hi everyone,
>
> This patch adds a comment to the BTF strings regarding their position
> within the section. This is useful for assembly inspection purposes.
>
> Regards,
> Cupertino
>
> When using -dA, this function was only printing as
On 1/8/24 09:59, Richard Sandiford wrote:
This is a bit of a hopeful stab, but is the problem that recog_data still
had the previous contents of insn 3674, and so extract_insn_cached wrongly
thought that it doesn't need to do anything? If so, does something like:
diff --git a/gcc/recog.cc
Hi Cupetino,
On 1/8/24 03:05, Cupertino Miranda wrote:
> Hi everyone,
>
> This patch address the problem reported in:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113225
>
> Looking forward to your review.
LGTM, thanks. Please apply.
>
> Cheers,
> Cupertino
>
>
> This patch fix a problem
Hi,
Arm GCC backend does not define __ARM_FEATURE_BF16 when +bf16 is
specified (via -march option, or target pragma) whereas it is supposed
to be tested before including arm_bf16.h (as specified in ACLE document:
https://arm-software.github.io/acle/main/acle.html#arm_bf16h).
gcc/ChangeLog:
On Thu, 21 Dec 2023 17:05:18 +0100
Tobias Burnus wrote:
> I think it makes sense to split this patch into two parts:
>
> * The libgomp/plugin/plugin-gcn.c – which is independent and would
> already used by omp_memcpy_rect.
I will commit this version in a moment. I needed to add the
DLSYM_OPT_FN
Thanks! Committed.
David Faust writes:
> Hi Cupetino,
>
> On 1/8/24 03:05, Cupertino Miranda wrote:
>> Hi everyone,
>>
>> This patch address the problem reported in:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113225
>>
>> Looking forward to your review.
>
> LGTM, thanks. Please apply.
>
>>
Thanks! Committed.
David Faust writes:
> Hi Cupertino,
>
> On 1/8/24 02:55, Cupertino Miranda wrote:
>> Hi everyone,
>>
>> This patch adds a comment to the BTF strings regarding their position
>> within the section. This is useful for assembly inspection purposes.
>>
>> Regards,
>> Cupertino
>>
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13/12?
-- >8 --
The get_target_expr call added in r12-7069-g119cea98f66476 causes us
for the below testcase to call build_vec_delete in a template context,
which builds a templated destructor call and checks expr_noexc
The attached patch does a tiny updated to the OpenMP features (AMD GCN
now also has an optimized memcpy_rect not only nvptx), but the main
change is some shifting around to make it more consistent and better
readable.
I intend to commit this relatively soon; like always, comments and
suggesti
* MAINTAINERS: Update my email address.
diff --git a/MAINTAINERS b/MAINTAINERS
index fe5d95ae970..882694cc47d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -34,7 +34,7 @@ Jeff Law
Michael Meissner
Jason Merrill
diff --git a/htdocs/steering.html b/htdocs/steering.html
index 95d6a4a8..6039a503 100644
--- a/htdocs/steering.html
+++ b/htdocs/steering.html
@@ -36,7 +36,7 @@ place to reach them is the gcc mailing
list.
Jason Merrill (Red Hat)
David Miller (Red Hat)
Toon Moene (Koninklijk Nederlands Meteorol
Jeff Law writes:
> On 1/8/24 09:59, Richard Sandiford wrote:
>> This is a bit of a hopeful stab, but is the problem that recog_data still
>> had the previous contents of insn 3674, and so extract_insn_cached wrongly
>> thought that it doesn't need to do anything? If so, does something like:
>>
>
Hi!
On 2024-01-08T15:30:06+0100, Tobias Burnus wrote:
> Andrew Stubbs wrote:
>> I know there will be things that need fixing for
>> both experimental architectures.
>
> Indeed. [...]
..., like, making it even build? ;-P
>> P.S. Apologies, but I think my commits today conflict a little; you
>>
On Mon, Jan 8, 2024 at 5:57 PM Andrew Pinski wrote:
>
> On Mon, Jan 8, 2024 at 6:44 AM Uros Bizjak wrote:
> >
> > Instead of converting XOR or PLUS of two values, ANDed with two constants
> > that
> > have no bits in common, to IOR expression, convert IOR or XOR of said two
> > ANDed values to P
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
hppa: Fix bind_c_coms.f90 and bind_c_vars.f90 tests on hppa
Commit 6271dd98 changed the default from -fcommon to -fno-common.
This silently changed the alignment of uninitialized BSS data on
hppa where the alignment of common data must
On 1/8/24 12:11, Richard Sandiford wrote:
Thanks. That led me to the following, which seems a bit more plausible
than my first attempt. I'll test it on aarch64-linux-gnu and
x86_64-linux-gnu. Does it look OK?
It looks reasonable to me. I'm going to send another failure (ICE in
finalize_
Hi Paul,
your patch looks already very impressive!
Regarding the patch as is, I am still trying to grok it, even with your
explanations at hand...
While the testcase works as advertised, I noticed that it exhibits a
runtime memleak that occurs for (likely) each case where the associate
target i
On Mon, 8 Jan 2024, Tamar Christina wrote:
> Hi All,
>
> In C you can have loops without a condition, the original version of the patch
> was rejecting the use of #pragma GCC novector, however during review it was
> changed to not due this with the reason that we didn't want to give a compile
> e
On Linux/x86_64,
b3cc5a1efead520bc977b4ba51f1328d01b3e516 is the first bad commit
commit b3cc5a1efead520bc977b4ba51f1328d01b3e516
Author: Richard Biener
Date: Fri Dec 15 10:32:29 2023 +0100
tree-optimization/113026 - avoid vector epilog in more cases
caused
FAIL: gcc.c-torture/execute/95
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
Skip gfortran.dg/dec_math.f90 on hppa
hppa*-*-hpux* doesn't have any long double trig functions.
2024-01-08 John David Anglin
gcc/testsuite/ChangeLog:
* gfortran.dg/dec_math.f90: Skip on hppa*-*-hpux*.
diff --git a/gcc/t
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
xfail dg-final "Sunk statements: 5" on hppa*64*-*-*
2024-01-08 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/ssa-sink-18.c: xfail dg-final "Sunk statements: 5"
on hppa*64*-*-*.
diff --git a/gcc/test
On 1/8/24 04:21, Iain Sandoe wrote:
On 6 Jan 2024, at 22:30, Nathan Sidwell wrote:
Richard Smith & I discussed whether we should use the module interface's
capability of giving vague linkage entities a strong location. I didn't want to go
messing with that, 'cos it was changing yet more stuff
On Mon, 8 Jan 2024 at 01:19, Jonathan Wakely wrote:
>
> I decided to push this now, not wait for the morning.
>
> This is mostly the same as V2, but adds to the contrib/unicode/README as
> suggested by Lewis, and avoids a trailing whitespace character in the
> generated header.
>
> Tested x86_64-l
LGTM.
juzhe.zh...@rivai.ai
From: Feng Wang
Date: 2024-01-08 17:12
To: gcc-patches
CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang
Subject: [PATCH v7 1/2] RISC-V: Add crypto vector builtin function.
Patch v7:Resubmit after fix trl-checking issue. Passed all the riscv regression
test.
Patch
LGTM.
juzhe.zh...@rivai.ai
From: Feng Wang
Date: 2024-01-08 17:12
To: gcc-patches
CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang
Subject: [PATCH v8 2/2] RISC-V: Add crypto vector api-testing cases.
Patch v8: Resubmit after fix the rtl-checking issue. Passed all the riscv
regression test.
This patch looks ok from myside.
juzhe.zh...@rivai.ai
From: Jun Sha (Joshua)
Date: 2024-01-03 14:08
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw;
christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu
Subject: [PATCH v4] RISC-V: Adds the pre
From: trcrsired
In the case of x86_64-w64-mingw32 gcc with multilibs, a conflict arises as both
64-bit and 32-bit DLLs attempt to copy into the bin/ directory. This
discrepancy results in coverage issues.
This commit aligns the Canadian build process for gcc targeting Windows with
cross build
1 - 100 of 119 matches
Mail list logo
