Hi all,
When I was backporting my doc patch in gcc trunk today, I found when adding
-march=gracemont in GCC14, the corresponding wwwdoc is missing. This patch
is adding that.
Ok for wwwdocs trunk?
Thx,
Haochen
---
htdocs/gcc-14/changes.html | 4
1 file changed, 4 insertions(+)
diff --git
Thanks Richard for comments.
Will commit it with that change if no surprise from test suite.
Pan
-Original Message-
From: Richard Biener
Sent: Thursday, September 19, 2024 2:23 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; tamar.christ...@arm.com; juzhe.zh...@rivai.ai;
kito.ch...@gmai
On Wed, Sep 18, 2024 at 1:35 PM Haochen Jiang wrote:
>
> Hi all,
>
> Since r15-3539, there are requests coming in to add other alias option
> documentation. This patch will add all ot them, including corei7, corei7-avx,
> core-avx-i, core-avx2, atom, slm, gracemont and emerarldrapids.
>
> Also in
On Wed, Sep 18, 2024 at 1:40 PM Haochen Jiang wrote:
>
> Hi all,
>
> Since commit r15-3594, we fixed the bugs in MASK_TYPE for AVX10.2
> testcases, but we missed the following four.
>
> The tests are not FAIL since the binutils part haven't been merged
> yet, which leads to UNSUPPORTED test. But t
On Thu, Sep 19, 2024 at 6:12 AM wrote:
>
> From: Pan Li
>
> This patch would like to support the form 3 of the scalar signed
> integer .SAT_ADD. Aka below example:
>
> Form 3:
> #define DEF_SAT_S_ADD_FMT_3(T, UT, MIN, MAX) \
> T __attribute__((noinline))
On Thu, Sep 19, 2024 at 6:11 AM wrote:
>
> From: Pan Li
>
> This patch would like to leverage the match_cond_with_binary_phi to
> match the phi on cond, and get the true/false arg if matched. This
> helps a lot to simplify the implementation of gen_phi_on_cond.
>
> Before this patch:
> basic_blo
On Thu, Sep 19, 2024 at 6:11 AM wrote:
>
> From: Pan Li
>
> When matching the cond with 2 args phi node, we need to figure out
> which arg of phi node comes from the true edge of cond block, as
> well as the false edge. This patch would like to add interface
> to perform the action and return th
On Wed, Sep 18, 2024 at 7:33 PM Jakub Jelinek wrote:
>
> On Wed, Sep 18, 2024 at 06:17:58PM +0100, Richard Sandiford wrote:
> > +1 I'd much rather learn about this kind of error before the code reaches
> > a review tool :)
> >
> > >From a quick check, it doesn't look like Clang has this, so there
On Wed, Sep 18, 2024 at 8:41 PM Andrew Carlotti wrote:
>
> On Thu, Sep 19, 2024 at 01:01:39AM +0800, Yangyu Chen wrote:
> >
> >
> > > On Sep 18, 2024, at 23:36, Andrew Carlotti
> > > wrote:
> > >
> > > On Wed, Sep 18, 2024 at 09:46:15AM +0100, Richard Sandiford wrote:
> > >> Yangyu Chen writes:
On Wed, Sep 18, 2024 at 7:55 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Thu, Sep 12, 2024 at 4:50 PM Hongtao Liu wrote:
> >>
> >> On Wed, Sep 11, 2024 at 4:21 PM Hongtao Liu wrote:
> >> >
> >> > On Wed, Sep 11, 2024 at 4:04 PM Richard Biener
> >> > wrote:
> >> > >
> >> > > O
On Wed, Sep 18, 2024 at 6:22 PM Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu with 5.5.0 bootstrap compiler. Thoughts?
I'm fine with this in general - do we have needs of bumping the requirement for
GCC 15 though? IMO we should bump once we are requiring actual C++14
in some place.
As of
On Wed, Sep 18, 2024 at 1:42 PM Haochen Jiang wrote:
>
> Hi all,
>
> For AVX10.2 convert tests, all of them are missing mask tests
> previously, this patch will add them in the tests.
>
> Tested on sde with assembler with these insts. Ok for trunk?
Ok.
>
> Thx,
> Haochen
>
> gcc/testsuite/ChangeLo
On Thu, Sep 19, 2024 at 9:34 AM Hu, Lin1 wrote:
>
> Hi, all
>
> The memory attr of some instructions should be 'load', but these is 'none'
> currently.
>
> This patch add two new types ssemov2, sseicvt2 for some load instructions that
> use memory on operands. So their memory attr will be 'load'.
The following changes the fallback to disable SLP when any of the
discovered SLP instances failed to pass vectorization checking into
a fallback that emulates what no SLP would do with SLP - force
single-lane discovery for all instances.
The patch does not remove the final fallback to disable SLP
From: Pan Li
This patch would like to support the form 3 of the scalar signed
integer .SAT_ADD. Aka below example:
Form 3:
#define DEF_SAT_S_ADD_FMT_3(T, UT, MIN, MAX) \
T __attribute__((noinline))\
sat_s_add_##T##_fmt_3 (T x, T y)
From: Pan Li
This patch would like fix the dump check times of vector SAT_ADD. The
middle-end change makes the match times from 2 to 4 times.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/b
From: Pan Li
This patch would like to leverage the match_cond_with_binary_phi to
match the phi on cond, and get the true/false arg if matched. This
helps a lot to simplify the implementation of gen_phi_on_cond.
Before this patch:
basic_block _b1 = gimple_bb (_a1);
if (gimple_phi_num_args (_a1)
From: Pan Li
When matching the cond with 2 args phi node, we need to figure out
which arg of phi node comes from the true edge of cond block, as
well as the false edge. This patch would like to add interface
to perform the action and return the true and false arg in TREE type.
The below test su
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv.md: Change "truncate" to unspec for the Zfa extension
> > on rv32.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/riscv/zfa-fmovh-fmovp-bug.c: New test.
> I've pushed this version to the trunk.
>
> Thanks,
> jeff
Thanks Jeff and Christoph
Hi, all
The memory attr of some instructions should be 'load', but these is 'none'
currently.
This patch add two new types ssemov2, sseicvt2 for some load instructions that
use memory on operands. So their memory attr will be 'load'.
Bootstrapped and Regtested on x86-64-pc-linux-gnu, OK for trun
Thanks Jeff for comments.
> Not particularly happy with the wall of expected assembly output, though
> it at least tries to be generic in terms of registers and such.
Sort of, the asm check for ssadd is quit long up to a point.
> So I'll ACK. But
> I'd like us to start thinking about what
On 9/18/24 11:00 AM, Jakub Jelinek wrote:
On Wed, Sep 18, 2024 at 10:51:49AM -0600, Jeff Law wrote:
On 9/18/24 10:04 AM, Jakub Jelinek wrote:
Hi!
Similarly to the previous patch, dwarf2asm.cc had
HAVE_DESIGNATED_INITIALIZERS support, and as fallback a huge switch.
The switch from what I can
Got, thanks Richard and will have a try in v5.
Pan
-Original Message-
From: Richard Biener
Sent: Wednesday, September 18, 2024 8:06 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; tamar.christ...@arm.com; juzhe.zh...@rivai.ai;
kito.ch...@gmail.com; jeffreya...@gmail.com; rdapp@gmail.
Tested x86_64-pc-linux-gnu, applying to trunk as obvious.
-- 8< --
GCC compiles with -fno-exceptions, so __throw_exception_again is a no-op,
and compilation gives a -Wempty-body warning here, so let's wrap it as is
already done in a few other files.
libstdc++-v3/ChangeLog:
* include/bit
This patch implements support for frames and promises with new-extended
alignment.
There are two kinds of alignment to worry about here:
- Promise alignment, which causes "internal" padding inside the frame
struct. The reason this is a problem is because the (yet to be
formalized, but agreed
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
1) We're hitting the assert in cp_parser_placeholder_type_specifier.
It says that if it turns out to be false, we should do error() instead.
Do so, then.
2) lambda-targ8.C should compile fine, though. The problem was that
loca
This patch series implements support for coroutines whose frames require
alignment.
The standard currently does not specify much about this case AFAICT, so
we can do this for now (until P2014 progresses).
The new dump was useful for testing, and might be useful to coroutine
hackers.
This patchse
This provides to people working on coroutines, as well as writing tests
for coroutines, a way to have insight into the results and inputs of the
coroutine transformation passes, which is quite essential to
understanding what happens in the coroutine transformation. Currently,
the information dumpe
Our implementation of the CWG 2273 inheritedness tiebreaker seems to be
incorrectly considering all inherited members, not just inherited
constructors. This patch restricts the tiebreaker accordingly.
DR 2273
gcc/cp/ChangeLog:
* call.cc (joust): Restrict inheritedness tiebreaker
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk? I'm not sure this is worth backporting
without the previous CWG 2273 tweak since it'll mean inconsistent
behavior between implict vs explicit object members in GCC 14: the call
to S<>{}.f() in concepts-memfun4.C would
On 9/9/24 14:55, Sandra Loosemore wrote:
On 9/9/24 05:01, Jakub Jelinek wrote:
I think also testing the device={kind(any,any)} and
device={kind("any",any)}
and device={kind(any,"any"))} would be useful.
Hmmm, it looks like GCC does not presently check for the restriction
"Each trait-proper
This patch adds random number support for UNSIGNED, plus fixes
two bugs, with array I/O where the type used to be set to BT_INTEGER,
and for division with the divisor being a constant.
Again, depends on prevous submissions.
OK for trunk?
gcc/fortran/ChangeLog:
* check.cc (gfc_check_ran
OK for trunk?
This is based on the previous submissions. Again, this does not
generate a new library version; rather it re-uses the signed
integer version already present in the library.
OK for trunk?
Previous submissions (without which this will not work):
https://gcc.gnu.org/pipermail/fortra
On Wed, Sep 18, 2024 at 1:33 PM Jakub Jelinek wrote:
>
> On Wed, Sep 18, 2024 at 06:17:58PM +0100, Richard Sandiford wrote:
> > +1 I'd much rather learn about this kind of error before the code reaches
> > a review tool :)
> >
> > >From a quick check, it doesn't look like Clang has this, so there
Hi Wilco,
Thanks for the patch. This mostly looks good. Just added a couple
clarifications.
On 9/18/2024 8:17 PM, Wilco Dijkstra wrote:
v2: Add more testcase fixes.
The current copysign pattern has a mismatch in the predicates and constraints -
operand[2] is a register_operand but also has a
Fix typos in comments.
Signed-off-by: Andrew Kreimer
---
libcody/README.md | 2 +-
libcody/cody.hh | 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/libcody/README.md b/libcody/README.md
index a95085eac7a..4530db95d28 100644
--- a/libcody/README.md
+++ b/libc
On Wed, Sep 18, 2024 at 09:43:03PM +0200, Arsen Arsenović wrote:
> Hi!
>
> Thanks for the patch.
>
> Andrew Kreimer writes:
>
> > Fix typos in comments.
>
> I'm not sure we should further diverge our local libtool copy compared
> to upstream. Best check whether the same errors exist in upstre
> > Pengxuan Zheng writes:
> > > We can still use SVE's INDEX instruction to construct vectors even
> > > if not all elements are constants. For example, { 0, x, 2, 3 } can
> > > be constructed by first using "INDEX #0, #1" to generate { 0, 1, 2,
> > > 3 }, and then set the elements which are non-
Fix a typo in comments.
Signed-off-by: Andrew Kreimer
---
libcc1/configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libcc1/configure b/libcc1/configure
index ea689a353c8..d27b9a1f600 100755
--- a/libcc1/configure
+++ b/libcc1/configure
@@ -17682,7 +17682,7 @@ func_base
Hi!
Thanks for the patch.
Andrew Kreimer writes:
> Fix typos in comments.
I'm not sure we should further diverge our local libtool copy compared
to upstream. Best check whether the same errors exist in upstream
libtool ( https://savannah.gnu.org/projects/libtool/ ) and fix them
there, I think
Fix typos in comments.
Signed-off-by: Andrew Kreimer
---
ltmain.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/ltmain.sh b/ltmain.sh
index 70990740b6c..54f5b964282 100644
--- a/ltmain.sh
+++ b/ltmain.sh
@@ -177,7 +177,7 @@ basename="s,^.*/,,"
# to NONDI
v2: Add more testcase fixes.
The current copysign pattern has a mismatch in the predicates and constraints -
operand[2] is a register_operand but also has an alternative X which allows any
operand. Since it is a floating point operation, having an integer alternative
makes no sense. Change the e
Bootstrapped and regtested on s390. Both expander are constrained to
z196 because of the conditional moves. I guess this is reasonable
nowadays.
Would be great if you could have a second look that setting the
carry/borrow bit (bit 18 of the PSW) is indeed correct. Brain twisted
me at first ;-)
On Thu, Sep 19, 2024 at 01:01:39AM +0800, Yangyu Chen wrote:
>
>
> > On Sep 18, 2024, at 23:36, Andrew Carlotti wrote:
> >
> > On Wed, Sep 18, 2024 at 09:46:15AM +0100, Richard Sandiford wrote:
> >> Yangyu Chen writes:
> >>> I recently found that target_clones functions cannot inline even when
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR reports that the warning would be better off using a check
for trivially constructible rather than trivially copyable.
LLVM accepted a similar fix:
https://github.com/llvm/llvm-project/issues/47355
PR c++/11673
Jennifer Schmitz writes:
> From 05e010a4ad5ef8df082b3e03b253aad85e2a270c Mon Sep 17 00:00:00 2001
> From: Jennifer Schmitz
> Date: Tue, 17 Sep 2024 00:15:38 -0700
> Subject: [PATCH] SVE intrinsics: Fold svmul with all-zero operands to zero
> vector
>
> As recently implemented for svdiv, this pat
On 9/5/24 9:44 AM, Hans-Peter Nilsson wrote:
Tested adding 0..more-than-four environment variables,
running cris-sim+cris-elf. I also checked that foo stays
the same generated code regardless of the new code: this is
not obviously true as foo is "just" noinline, not __noipa__.
Ok to commit?
Richard Biener writes:
> On Thu, Sep 12, 2024 at 4:50 PM Hongtao Liu wrote:
>>
>> On Wed, Sep 11, 2024 at 4:21 PM Hongtao Liu wrote:
>> >
>> > On Wed, Sep 11, 2024 at 4:04 PM Richard Biener
>> > wrote:
>> > >
>> > > On Wed, Sep 11, 2024 at 4:17 AM liuhongt wrote:
>> > > >
>> > > > GCC12 enable
Thanks, pushed as
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fe1ed68000d5e9d41ed48ef1202fd21c8b8c9ff8
FX
On 9/8/24 5:43 AM, Andrew Kreimer wrote:
Fix typos in comments.
Signed-off-by: Andrew Kreimer
---
configure| 2 +-
configure.ac | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Thanks. I create a suitable ChangeLog and pushed this to the trunk.
jeff
On Wed, Sep 18, 2024 at 06:17:58PM +0100, Richard Sandiford wrote:
> +1 I'd much rather learn about this kind of error before the code reaches
> a review tool :)
>
> >From a quick check, it doesn't look like Clang has this, so there is no
> existing name to follow.
I was considering also -Wtrail
On 9/18/24 12:45 AM, Eikansh Gupta wrote:
The pattern `a rrotate (32-b)` should be optimized to `a lrotate b`.
The same is also true for `a lrotate (32-b)`. It can be optimized to
`a rrotate b`.
This patch adds following patterns:
a rrotate (32-b) -> a lrotate b
a lrotate (32-b) -> a rrotate
Jeff Law writes:
> On 9/18/24 10:11 AM, Jakub Jelinek wrote:
>> Hi!
>>
>> Trailing blanks is something even git diff diagnoses; while it is a coding
>> style issue, if it is so common that git diff diagnoses it, I think it could
>> be useful to various projects to check that at compile time.
Nic
Matthieu Longo writes:
> Architecture-specific CFI directives are currently declared an processed
> among others architecture-independent CFI directives in gcc/dwarf2* files.
> This approach creates confusion, specifically in the case of DWARF
> instructions in the vendor space and using the sa
Matthieu Longo writes:
> This patch series is only a refactoring of the existing implementation of
> PAuth and returned-address signing. The existing behavior is preserved.
The series LGTM, thanks. OK for trunk if there are no objections
before Monday.
Richard
>
> 1. aarch64: store signing ke
1. GNAT needs GCC 5.1 or later
2. Ubuntu 16.04 uses GCC 5.4
3. The propose is bump to GCC 5.5
4. Debian 9 uses GCC 6.3
5. D need GCC 9.4 or later
GCC 9.4 is obviously too new, and using GCC 5.5 rules out Ubuntu
16.04. So unless there is a strong reason to do so, it is recommended
to bump to GCC 5.
Jason Merrill writes:
> Tested x86_64-pc-linux-gnu with 5.5.0 bootstrap compiler. Thoughts?
>
> -- 8< --
>
> This implements my proposal to update our bootstrap requirement to C++14.
> The big benefit of the change is the greater constexpr power, but C++14 also
> added variable templates, generi
> On Sep 18, 2024, at 23:36, Andrew Carlotti wrote:
>
> On Wed, Sep 18, 2024 at 09:46:15AM +0100, Richard Sandiford wrote:
>> Yangyu Chen writes:
>>> I recently found that target_clones functions cannot inline even when
>>> the caller has exactly the same target. However, if we only use targe
On Wed, Sep 18, 2024 at 10:51:49AM -0600, Jeff Law wrote:
> On 9/18/24 10:04 AM, Jakub Jelinek wrote:
> > Hi!
> >
> > Similarly to the previous patch, dwarf2asm.cc had
> > HAVE_DESIGNATED_INITIALIZERS support, and as fallback a huge switch.
> > The switch from what I can see is expanded as a jump
On 9/18/24 10:04 AM, Jakub Jelinek wrote:
Hi!
Similarly to the previous patch, dwarf2asm.cc had
HAVE_DESIGNATED_INITIALIZERS support, and as fallback a huge switch.
The switch from what I can see is expanded as a jump table with 256
label pointers and code at those labels then loads addresses
On 9/18/24 6:36 PM, Iain Sandoe wrote:
On 18 Sep 2024, at 17:18, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu with 5.5.0 bootstrap compiler. Thoughts?
Despite that adequate support is available in GCC-5.5/6, would it be
useful to jump to a version that allows a single toolchain to boot
On 9/18/24 10:11 AM, Jakub Jelinek wrote:
Hi!
Trailing blanks is something even git diff diagnoses; while it is a coding
style issue, if it is so common that git diff diagnoses it, I think it could
be useful to various projects to check that at compile time.
Dunno if it should be included in
On 9/17/24 5:25 AM, Jovan Vukic wrote:
The patch optimizes code generated for comparisons of the form x > y ? 2 : 3
(x <= y ? 3 : 2) and x < y ? 2 : 3 (x >= y ? 3 : 2).
For the following C code:
long f1(long x, long y) {
return (x > y) ? 2 : 3;
}
long f2(long x, long y) {
return (
> On 18 Sep 2024, at 17:18, Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu with 5.5.0 bootstrap compiler. Thoughts?
Despite that adequate support is available in GCC-5.5/6, would it be
useful to jump to a version that allows a single toolchain to bootstrap
all the currently supported la
Hi Andre,
Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
Extremely minor nit: In the commit message and ChangeLog entry,
Build a derived type component's type only, when it is not already being
build and the component uses pointer semantics.
I believe that should be "being
Tested x86_64-pc-linux-gnu with 5.5.0 bootstrap compiler. Thoughts?
-- 8< --
This implements my proposal to update our bootstrap requirement to C++14.
The big benefit of the change is the greater constexpr power, but C++14 also
added variable templates, generic lambdas, lambda init-capture, bina
Am 18.09.24 um 12:31 schrieb Andre Vehreschild:
Regtested ok on x86_64-pc-linux-gnu / F39. Ok for mainline?
OK.
Thanks for the patch!
Best regards
Thomas
Hi!
Trailing blanks is something even git diff diagnoses; while it is a coding
style issue, if it is so common that git diff diagnoses it, I think it could
be useful to various projects to check that at compile time.
Dunno if it should be included in -Wextra, currently it isn't, and due to
tons o
Hi!
Similarly to the previous patch, dwarf2asm.cc had
HAVE_DESIGNATED_INITIALIZERS support, and as fallback a huge switch.
The switch from what I can see is expanded as a jump table with 256
label pointers and code at those labels then loads addresses of
string literals.
The following patch instea
On Wed, Sep 18, 2024 at 09:46:15AM +0100, Richard Sandiford wrote:
> Yangyu Chen writes:
> > I recently found that target_clones functions cannot inline even when
> > the caller has exactly the same target. However, if we only use target
> > attributes in C++ and let the compiler generate IFUNC fo
The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and
mandatory from Armv9.5-a. It introduces instructions for computing the
floating point absolute maximum and minimum of the two vectors
element-wise.
This patch adds code generation support for famax and famin in terms of
existing R
The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and
mandatory from Armv9.5-a. It introduces instructions for computing the
floating point absolute maximum and minimum of the two vectors element-wise.
This patch introduces AdvSIMD faminmax intrinsics. The intrinsics of
this extensio
From: Saurabh Jha
This is a revised version of this patch series:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663204.html
The only new thing in both patches of this series are fixing directives
in test cases, replace /* { dg-do assemble} */ with
/* { dg-do compile } */. We need comp
> On Sep 18, 2024, at 16:46, Richard Sandiford
> wrote:
>
> Yangyu Chen writes:
>> I recently found that target_clones functions cannot inline even when
>> the caller has exactly the same target. However, if we only use target
>> attributes in C++ and let the compiler generate IFUNC for us,
On 9/10/24 9:59 AM, Georg-Johann Lay wrote:
The order in which multi-byte EQ and NE comparisons are performing
the byte comparisons does not matter, and there are situations where
using SBIW on the high word can save an instruction.
This is for trunk.
Johann
--
AVR: Tweak 32-bit EQ and NE
On 9/12/24 7:21 PM, pan2...@intel.com wrote:
From: Pan Li
The int8_t test for signed SAT_ADD is sat_s_add-1.c, the sat_s_add-4.c
should be for int64_t. Thus, update sat_s_add-4.c for int64_t type.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/sat_s_add-4.c: Update test for int64_t
On 9/12/24 4:42 PM, pan2...@intel.com wrote:
From: Pan Li
This patch would like fix the dump check times of vector SAT_ADD. The
middle-end change makes the match times from 2 to 4 times.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/Ch
On 9/12/24 8:14 PM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to add testcases of the signed scalar SAT_ADD
for form 2. Aka:
Form 2:
#define DEF_SAT_S_ADD_FMT_2(T, UT, MIN, MAX) \
T __attribute__((noinline)) \
sat_s_add_##T##_fmt_2 (T x, T y)
Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11. Committed
to trunk.
Dave
---
hppa: Add peephole2 optimizations for REG+D loads and stores
The PA 1.x architecture only supports long displacements in
integer loads and stores. Floating-point loads and stores
only support short displacement
On 9/9/24 3:10 AM, Jin Ma wrote:
gcc/ChangeLog:
* config/riscv/riscv.md: Change "truncate" to unspec for the Zfa
extension on rv32.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zfa-fmovh-fmovp-bug.c: New test.
I've pushed this version to the trunk.
Thanks,
jeff
On Wed, Sep 18, 2024 at 03:53:37PM +0200, Michael Matz wrote:
> Hello,
>
> On Thu, 12 Sep 2024, Stefan Schulze Frielinghaus wrote:
>
> > > > #define call_on_stack(stack, func, asm_call, argconstr...)
> > > > \
> > > > {
On 9/13/24 9:17 PM, Jin Ma wrote:
Hi, any more comments about this patch to fix zfa's ICE?
Sorry, need to correct the final conclusion in my last message. We
should go with the v3 patch, not the v2 patch.
jeff
Thanks for the approval Richard!
I've incorporated your suggestion to remove the "digits skip" code and I've
pushed the patch.
Cheers,
Filip Kastl
-- 8< --
Currently check-params-in-docs.py reports extra params being listed in
invoke.texi. However, those aren't actual params but items in a t
Since genoutput has no information about hard register names we cannot
statically verify those names in constraints of the machine description.
Therefore, we have to do it at runtime. Although verification shouldn't
be too expensive, restrict it to checking builds. This should be
sufficient since
On 9/18/24 8:03 AM, Christoph Müllner wrote:
On Wed, Sep 18, 2024 at 3:55 PM Jeff Law wrote:
On 9/10/24 10:09 AM, Christoph Müllner wrote:
But if the generated code is just moving bits, why can't we use the
standard movXX patterns for the data movement? Clearly there's
something about
This implements some basic error handling for hard register constraints
including potential conflics with register asm operands.
In contrast to register asm operands, hard register constraints allow
more than just one register per operand. Even more than just one
register per alternative. For ex
Currently a register asm already materializes during expand. This
means, a hard register is allocated for the very first access of a
register asm as e.g. in an assignment. As a consequence this might lead
to suboptimal register allocation if the assignment and the using asm
statement are spread f
This is a follow-up to
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662725.html
I basically added only some documentation to the first patch. If you
think that gcc/doc/extend.texi isn't the right place (especially the
discussion part which will be dropped/rephrased in the end anyway),
Implement hard register constraints of the form {regname} where regname
must be any valid register name for the target. Such constraints may be
used in asm statements as a replacement for register asm and in machine
descriptions.
Due to optimizations it is not unexpected if two or more inputs req
On Thu, 12 Sept 2024 at 21:51, Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu. Thoughts about the remaining warnings discussed
> below? Any other comments?
>
> -- 8< --
>
> The use of #pragma GCC system_header in libstdc++ has led to bugs going
> undetected for a while due to the silencing
writes:
> The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and
> mandatory from Armv9.5-a. It introduces instructions for computing the
> floating point absolute maximum and minimum of the two vectors
> element-wise.
>
> This patch adds code generation support for famax and famin in
writes:
> The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and
> mandatory from Armv9.5-a. It introduces instructions for computing the
> floating point absolute maximum and minimum of the two vectors element-wise.
>
> This patch introduces AdvSIMD faminmax intrinsics. The intrinsics
On AArch64, the RA state informs the unwinder whether the return address
is mangled and how, or not. This information is encoded in a boolean in
the CFI row. This binary approach prevents from expressing more complex
configuration, as it is the case with PAuth_LR introduced in Armv9.5-A.
This patc
gcc/testsuite/ChangeLog:
* g++.target/aarch64/pr94515-1.C: Improve test documentation.
* g++.target/aarch64/pr94515-2.C: Same.
---
gcc/testsuite/g++.target/aarch64/pr94515-1.C | 8
gcc/testsuite/g++.target/aarch64/pr94515-2.C | 39 +---
2 files changed, 41 in
Architecture-specific CFI directives are currently declared an processed among
others architecture-independent CFI directives in gcc/dwarf2* files. This
approach creates confusion, specifically in the case of DWARF instructions in
the vendor space and using the same instruction code.
Such a clas
Architecture-specific CFI directives are currently declared an processed
among others architecture-independent CFI directives in gcc/dwarf2* files.
This approach creates confusion, specifically in the case of DWARF
instructions in the vendor space and using the same instruction code.
Such a clash
The current name REG_CFA_TOGGLE_RA_MANGLE is not representative of what
it really is, i.e. a register to represent several states, not only a
binary one. Same for dwarf2out_frame_debug_cfa_toggle_ra_mangle.
gcc/ChangeLog:
* combine-stack-adj.cc
(no_unhandled_cfa): Rename.
On Wed, Sep 18, 2024 at 3:55 PM Jeff Law wrote:
>
>
>
> On 9/10/24 10:09 AM, Christoph Müllner wrote:
>
> >> But if the generated code is just moving bits, why can't we use the
> >> standard movXX patterns for the data movement? Clearly there's
> >> something about this that I'm missing.
> > > Th
libgcc/ChangeLog:
* configure: Regenerate.
---
libgcc/configure | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libgcc/configure b/libgcc/configure
index a69d314374a..15a0be23644 100755
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -587,6 +587,7 @@ ac_includes_default='/* none */
This patch provides a new handler MD_ARCH_FRAME_STATE_T to hide an
architecture-specific structure containing CIE and FDE data related
to DWARF architecture extensions.
Hiding the architecture-specific attributes behind a handler has the
following benefits:
1. isolating those data from the generic
1 - 100 of 139 matches
Mail list logo
