From: Pan Li
We missed one match pattern for the unsigned scalar .SAT_SUB, aka
form 11.
Form 11:
#define SAT_SUB_U_11(T) \
T sat_sub_u_11_##T (T x, T y) \
{ \
T ret; \
bool overflow = __builtin_sub_overflow (x, y, &ret); \
return overflow ? 0 : ret; \
}
Thus, add above for
Hi Harald,
thank you very much for the review. Committed as:
gcc-15-1369-gdb75a6657e9
Regarding your question on the coarray-tests that are not in the
coarray-directory: These test in most cases test only one method of
implementing coarrays. I.e., they are either testing just -fcoarray=single or
Fix test for APX ZU. Add attribute for no-inline and target APX, and
target-support check.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Committed as an obvious patch.
gcc/testsuite/ChangeLog:
* gcc.target/i386/apx-zu-1.c: Add attribute for noinline,
Hi,
This patch creates an insn_and_split pattern which helps the duplicated
constant vector replace the source pseudo of store insn in fwprop pass.
Thus the store can be implemented by a single stxvd2x and it eliminates the
unnecessary byte swap insn on P8 LE. The test case shows the optimization
HAO CHEN GUI writes:
> Hi,
> This patch replaces rtx_cost with insn_cost in forward propagation.
> In the PR, one constant vector should be propagated and replace a
> pseudo in a store insn if we know it's a duplicated constant vector.
> It reduces the insn cost but not rtx cost. In this case, t
> On Thu, 17 Aug 2023, Jose E. Marchesi via Gcc-patches wrote:
>> [Changes from V3:
> :
>> LLVM supports an option -W[no-]compare-distinct-pointer-types that can
>> be used in order to enable or disable the emission of such warnings.
>
> It looks this went in, alas is not covered in gcc-14/change
Richard Biener writes:
> On Fri, 14 Jun 2024, Richard Biener wrote:
>
>> On Fri, 14 Jun 2024, Richard Sandiford wrote:
>>
>> > Richard Biener writes:
>> > > On Fri, 14 Jun 2024, Richard Sandiford wrote:
>> > >
>> > >> Richard Biener writes:
>> > >> > The following retires vcond{,u,eq} optabs by
This series expands on the fix for PR115464 by using force_subreg
in more places. It also adds some convenience wrappers for lowpart
and highpart subregs.
A part of this will need to be backported after a grace period,
but I'll post the cherry-picked parts separately.
Tested on aarch64-linux-gnu
While adding more uses of force_subreg, I realised that it should
be more careful to emit no instructions on failure. This kind of
failure should be very rare, so I don't think it's a case worth
optimising for.
gcc/
* explow.cc (force_subreg): Emit no instructions on failure.
---
gcc/exp
This patch makes the aarch64 code use force_subreg instead of
simplify_gen_subreg in more places. The criteria were:
(1) The code is obviously specific to expand (where new pseudos
can be created).
(2) The value is obviously an rvalue rather than an lvalue.
(3) The offset wasn't a simple lo
This patch makes target-independent code use force_subreg instead
of simplify_gen_subreg in some places. The criteria were:
(1) The code is obviously specific to expand (where new pseudos
can be created), or at least would be invalid to call when
!can_create_pseudo_p () and temporaries ar
This patch makes more use of force_lowpart_subreg, similarly
to the recent patch for force_subreg. The criteria were:
(1) The code is obviously specific to expand (where new pseudos
can be created).
(2) The value is obviously an rvalue rather than an lvalue.
gcc/
PR target/115464
optabs had a local function called lowpart_subreg_maybe_copy
that is very similar to the lowpart version of force_subreg.
This patch adds a force_lowpart_subreg wrapper around
force_subreg and uses it in optabs.cc.
The only difference between the old and new functions is that
the old one asserted
This patch makes target-independent code use force_lowpart_subreg
instead of simplify_gen_subreg and lowpart_subreg in some places.
The criteria were:
(1) The code is obviously specific to expand (where new pseudos
can be created), or at least would be invalid to call when
!can_create_pseu
This patch adds uses of force_highpart_subreg to places that
already use force_lowpart_subreg.
gcc/
* config/aarch64/aarch64.cc (aarch64_addti_scratch_regs): Use
force_highpart_subreg instead of gen_highpart and simplify_gen_subreg.
(aarch64_subvti_scratch_regs): Likewise.
This patch adds a force_highpart_subreg to go along with the
recently added force_lowpart_subreg.
gcc/
* explow.h (force_highpart_subreg): Declare.
* explow.cc (force_highpart_subreg): New function.
* builtins.cc (expand_builtin_issignaling): Use it.
* expmed.cc (em
On 14/06/2024 11:31, Richard Biener wrote:
The following retires vcond{,u,eq} optabs by stopping to use them
from the middle-end. Targets instead (should) implement vcond_mask
and vec_cmp{,u,eq} optabs. The PR this change refers to lists
possibly affected targets - those implementing these patt
On Sat, 15 Jun 2024 at 14:04, François Dumont wrote:
>
> Here is the simplified patch then.
The use of std::__to_address seems wrong.
The allocator returns a __buckets_ptr, and that function returns a
__buckets_ptr, so it should just be returned unchanged, not by
converting to a raw pointer with
On Mon, 17 Jun 2024 at 11:18, Jonathan Wakely wrote:
>
> On Sat, 15 Jun 2024 at 14:04, François Dumont wrote:
> >
> > Here is the simplified patch then.
>
> The use of std::__to_address seems wrong.
>
> The allocator returns a __buckets_ptr, and that function returns a
> __buckets_ptr, so it shou
on 2024/6/15 13:00, Gaius Mulley wrote:
> "Kewen.Lin" writes:
>
>> Hi Gaius,
>>
static tree
build_m2_short_real_node (void)
{
- tree c;
-
- /* Define `REAL'. */
-
- c = make_node (REAL_TYPE);
- TYPE_PRECISION (c) = FLOAT_TYPE_SIZE;
- layo
Now that all remaining users of value_range have been renamed to
int_range<>, we can reclaim value_range as a temporary, thus removing
the annoying CamelCase.
gcc/ChangeLog:
* data-streamer-in.cc (streamer_read_value_range): Rename
Value_Range to value_range.
* data-stream
This is a minor tidy-up, tested on x86_64-darwin,
OK For trunk?
thanks
Iain
--- 8< ---
At present, for pre-conditions and for post-conditions with a void
return, we are not emitting a return statement. This patch adds the
relevant return statements.
gcc/cp/ChangeLog:
* contracts.cc (fin
This patch came out of a discussion on Mattermost about how to deal
with contracts/coroutines integration. Actually, it would also allow
some semantic checking to be deferred until the same spot - at which
time there are no dependent types, which can simplify the process.
NOTE: this is a fix for
When there's a permute after an extern vector we can run into a case
that didn't consider the scheduled node being a permute which lacks
a representative.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/115508
* tree-vect-slp.cc (vect_schedule_slp
Hi Siarahei,
On 16/06/2024 09:51, Siarhei Volkau wrote:
> If the address register is dead after load/store operation it looks
> beneficial to use LDMIA/STMIA instead of pair of LDR/STR instructions,
> at least if optimizing for size.
>
> E.g.
> ldr r0, [r3, #0]
> ldr r1, [r3, #4] @ r3 is dead
Hi,
> -Original Message-
> From: Pengxuan Zheng
> Sent: Friday, June 14, 2024 12:57 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Pengxuan Zheng
> Subject: [PATCH v3] aarch64: Add vector popcount besides QImode [PR113859]
>
> This patch improves GCC’s vectorization of __builtin_popcount for aa
Hi,
Gently ping it.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653001.html
Thanks
Gui Haochen
在 2024/6/3 10:37, HAO CHEN GUI 写道:
> Hi,
> All issues were addressed. Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/653001.html
>
> Thanks
> Gui Haochen
>
>
> 在 2024
Pushed. (The diff is a bit larger due to line breaks.)
Gerald
gcc:
* doc/install.texi (Configuration): Mark up __cxa_atexit as @code.
---
gcc/doc/install.texi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 298
Combine will use zero_extract destinations for certain bitfield
insertions. If the bitfield is a single bit constant, then we can use
bset/bclr.
In this case we are only dealing with word_mode objects, so we don't
have to worry about the SI->DI extension issues for TARGET_64BIT.
The testcas
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653573.html
patch. While the committed and backported patch fixed PCH on PIE
cc1/cc1plus etc. on PowerPC, it grew up the size of the
rs6000_init_generated_builtins function quite a lot.
The above patch decreases it back,
The following fixes a bad final value being used when doing single-lane
SLP integer induction cond reduction vectorization.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR tree-optimization/115493
* tree-vect-loop.cc (vect_create_epilog_for_reduction): Use
th
Automatic arrays that are not address-taken should not be subject to
store data races. This applies to OMP SIMD in-branch lowered
functions result array which for the testcase otherwise prevents
vectorization with SSE and for AVX and AVX512 ends up with spurious
.MASK_STORE to the stack surviving.
On Mon, Jun 17, 2024, 5:59 AM Tamar Christina
wrote:
> Hi,
>
> > -Original Message-
> > From: Pengxuan Zheng
> > Sent: Friday, June 14, 2024 12:57 AM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Pengxuan Zheng
> > Subject: [PATCH v3] aarch64: Add vector popcount besides QImode
> [PR113859]
>
From: Pan Li
After the middle-end support the form 2 of unsigned SAT_ADD and
the RISC-V backend implement the .SAT_ADD for vector mode, add
more test case to cover the form 2.
Form 2:
#define DEF_VEC_SAT_U_ADD_FMT_2(T) \
void __attribute__((noinline))
From: Pan Li
After the middle-end support the form 3 of unsigned SAT_ADD and
the RISC-V backend implement the .SAT_ADD for vector mode, add
more test case to cover the form 3.
Form 3:
#define DEF_VEC_SAT_U_ADD_FMT_3(T) \
void __attribute__((noinline))
From: Pan Li
After the middle-end support the form 4 of unsigned SAT_ADD and
the RISC-V backend implement the .SAT_ADD for vector mode, add
more test case to cover the form 4.
Form 4:
#define DEF_VEC_SAT_U_ADD_FMT_4(T) \
void __attribute__((noinline))
From: Pan Li
After the middle-end support the form 5 of unsigned SAT_ADD and
the RISC-V backend implement the .SAT_ADD for vector mode, add
more test case to cover the form 5.
Form 5:
#define DEF_VEC_SAT_U_ADD_FMT_5(T) \
void __attribute__((noinline))
From: Pan Li
After the middle-end support the form 7 of unsigned SAT_ADD and
the RISC-V backend implement the .SAT_ADD for vector mode, add
more test case to cover the form 7.
Form 7:
#define DEF_VEC_SAT_U_ADD_FMT_7(T) \
void __attribute__((noinline))
From: Pan Li
After the middle-end support the form 6 of unsigned SAT_ADD and
the RISC-V backend implement the .SAT_ADD for vector mode, add
more test case to cover the form 6.
Form 6:
#define DEF_VEC_SAT_U_ADD_FMT_6(T) \
void __attribute__((noinline))
From: Pan Li
After the middle-end support the form 8 of unsigned SAT_ADD and
the RISC-V backend implement the .SAT_ADD for vector mode, add
more test case to cover the form 8.
Form 8:
#define DEF_VEC_SAT_U_ADD_FMT_8(T) \
void __attribute__((noinline))
on 2024/6/17 14:16, Richard Biener wrote:
> On Mon, 17 Jun 2024, Kewen.Lin wrote:
>
>> Hi Richi,
>>
>> on 2024/6/14 18:31, Richard Biener wrote:
>>> The following retires vcond{,u,eq} optabs by stopping to use them
>>> from the middle-end. Targets instead (should) implement vcond_mask
>>> and vec
on 2024/6/17 10:31, Peter Bergner wrote:
> On 6/16/24 9:10 PM, Kewen.Lin wrote:
>> on 2024/6/15 01:05, Peter Bergner wrote:
>>> That said, the --with-cpu=power5 build without fortran did bootstrap and
>>> regtest with no regressions, so the build did test that code path and
>>> exposed no problems.
Hi,
Gently ping the series of patches.
[PATCH-1v3, rs6000] Implement optab_isinf for SFDF and IEEE128
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652593.html
[PATCH-2v3, rs6000] Implement optab_isfinite for SFDF and IEEE128
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652594.htm
Hi,
Gently ping it.
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652991.html
Thanks
Gui Haochen
在 2024/6/3 10:37, HAO CHEN GUI 写道:
> Hi,
> All issues were addressed. Gently ping it.
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/652991.html
>
> Thanks
> Gui Haochen
>
> 在 2024/5/
On Mon, Jun 17, 2024 at 03:26:52PM +0200, Jakub Jelinek wrote:
> I'd like to ping the
> https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653573.html
> patch. While the committed and backported patch fixed PCH on PIE
> cc1/cc1plus etc. on PowerPC, it grew up the size of the
> rs6000_init_generat
Hi!
The option_map array for most entries contains just non-NULL opt0
{ "-Wno-", NULL, "-W", false, true },
{ "-fno-", NULL, "-f", false, true },
{ "-gno-", NULL, "-g", false, true },
{ "-mno-", NULL, "-m", false, true },
{ "--debug=", NULL, "-g", false, false },
{ "--machi
Binutils 2.42 and before don't support Zaamo/Zalrsc. Add a configure
check to prevent emitting Zaamo/Zalrsc in the arch string when the
assember does not support it.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::to_string): Skip zaamo/zalrsc when not
On 6/13/24 13:02, Jeff Law wrote:
On 6/12/24 5:20 PM, Patrick O'Neill wrote:
Binutils 2.42 and before don't support Zaamo/Zalrsc. Add a configure
check to prevent emitting Zaamo/Zalrsc in the arch string when the
assember does not support it.
gcc/ChangeLog:
* common/config/riscv/riscv-
on 2024/6/15 01:05, Peter Bergner wrote:
> On 6/13/24 10:26 PM, Peter Bergner wrote:
>> On 6/13/24 9:26 PM, Kewen.Lin wrote:
> I understand this is just copied from the if arm, but if I read this
> right, it can be
> simplified as:
Ok, I'll retest with that simplification.
>>
Hi!
On AVR and SH with some options sizeof (float) == sizeof (double) and
the 2 types have the same set of values.
http://eel.is/c++draft/conv.rank#2.2 for this says that double still
has bigger rank than float and http://eel.is/c++draft/conv.rank#2.2
says that extended type with the same set of v
Hi!
The warning code uses %D to print the ARRAY_REF first operands.
That works in the most common case where those operands are decls, but
as can be seen on the following testcase, they can be other expressions
with array type.
Just changing %D to %E isn't enough, because then the diagnostics can
Hi Paul,
on 2024/6/14 23:20, Paul Koning wrote:
> Ok, I understand better now. But if those macros are supposed to be replaced
> by hook functions, could you make that replacement part of the proposed patch?
The default implementation of the introduced hook mode_for_floating_type
returns SFmode
On Mon, Jun 17, 2024 at 08:16:34AM +0200, Richard Biener wrote:
> On Mon, 17 Jun 2024, Kewen.Lin wrote:
>
> > Hi Richi,
> >
> > on 2024/6/14 18:31, Richard Biener wrote:
> > > The following retires vcond{,u,eq} optabs by stopping to use them
> > > from the middle-end. Targets instead (should) im
Hi!
While my r15-1001-g4cf2de9b5268224 PCH PIE power fix change decreased the
.data section sizes (219792 -> 189336), it increased the size of already
huge rs6000_init_generated_builtins generated function, from 218328
to 228668 bytes. That is because there are thousands of array references
to gl
On Mon, Jun 17, 2024 at 07:09:03PM +0200, Jakub Jelinek wrote:
> Hi!
>
> The warning code uses %D to print the ARRAY_REF first operands.
> That works in the most common case where those operands are decls, but
> as can be seen on the following testcase, they can be other expressions
> with array t
Hi,
On Thu, Jun 6, 2024 at 7:05 PM Andrew Pinski wrote:
>
> On Thu, Jun 6, 2024 at 9:00 AM David Malcolm wrote:
> >
> > On Thu, 2024-06-06 at 08:40 -0700, Andrew Pinski wrote:
> > > On Thu, Jun 6, 2024 at 6:02 AM Bert Wesarg
> > > wrote:
> > > >
> > > > Dear David,
> > > >
> > > > On Tue, May 2
On 6/14/24 1:37 PM, Carl Love wrote:
> Per the additional feedback after patch:
>
> commit c892525813c94b018464d5a4edc17f79186606b7
> Author: Carl Love
> Date: Tue Jun 11 14:01:16 2024 -0400
>
> rs6000, altivec-2-runnable.c should be a runnable test
>
> The test case ha
On Fri, 14 Jun 2024, Jonathan Wakely wrote:
> Both, ideally. The libstdc++ test should definitely be fixed because
> it fails with released versions of glibc already in the wild. But
> glibc should also be fixed because it's a standards conformance issue.
The __ctx macro used in various sys/ucont
Thanks Kewen.
Given that background, the patch is OK.
paul
> On Jun 16, 2024, at 10:01 PM, Kewen.Lin wrote:
>
> Hi Paul,
>
> on 2024/6/14 23:20, Paul Koning wrote:
>> Ok, I understand better now. But if those macros are supposed to be
>> replaced by hook functions, could you make th
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
In r13-272 we hardened the *_PACK_EXPANSION and *_ARGUMENT_PACK macros.
That trips up here because make_pack_expansion returns error_mark_node
and we access that with PACK_EXPANSION_LOCAL_P.
PR c++/115425
gcc/cp/Change
The following testcases have been failing on rv32 targets since
r15-953-gaf4bf422a69:
FAIL: gcc.target/riscv/rvv/autovec/binop/vwsll-1.c (internal compiler
error: in maybe_legitimize_operand, at optabs.cc:8056)
FAIL: gcc.target/riscv/rvv/autovec/binop/vwsll-1.c (test for excess
errors)
Fix the bu
On rv32 targets, vwsll_zext1_scalar_ would trigger an ice in
maybe_legitimize_instruction when zero extending a uint32 to uint64 due
to a mismatch between the input operand's mode (DI) and the expanded insn
operand's mode (Pmode == SI). Ensure that mode of the operands match
Tested on rv32/64 gcv
When emitting insns, we have an early assertion to ensure the input
operand's mode and the expanded operand's mode are the same; however, it
does not perform this check if the pattern does not have an explicit
machine mode specifying the operand. In this scenario, it will always
assume that mode =
On Mon, 17 Jun 2024 at 19:03, Joseph Myers wrote:
>
> On Fri, 14 Jun 2024, Jonathan Wakely wrote:
>
> > Both, ideally. The libstdc++ test should definitely be fixed because
> > it fails with released versions of glibc already in the wild. But
> > glibc should also be fixed because it's a standards
On Sat, 15 Jun 2024, Martin Uecker wrote:
> The patch fails on arm because the tests make assumptions
> about enums that are not true everywhere. Should we just
> limit the tests to x86?
For compilation tests, using -fno-short-enums should work. That won't
work for link / execute tests, but in
On 6/16/24 9:10 PM, Kewen.Lin wrote:
> on 2024/6/15 01:05, Peter Bergner wrote:
>> That said, the --with-cpu=power5 build without fortran did bootstrap and
>> regtest with no regressions, so the build did test that code path and
>> exposed no problems.
>
> OK, nice! Thanks!
I assume this means y
On Mon, Jun 17, 2024 at 09:09:37PM +0200, Andreas Krebbel wrote:
> On 6/14/24 20:03, Jakub Jelinek wrote:
> > Also wonder about the
> > // { dg-additional-options "-march=z14" { target s390*-*-* } }
> > line, doesn't that mean the test will FAIL on all pre-z14 HW?
> > Shouldn't it use some z14_runt
On 17.06.24 20:53, Jonathan Wakely wrote:
On Mon, 17 Jun 2024 at 19:03, Joseph Myers wrote:
On Fri, 14 Jun 2024, Jonathan Wakely wrote:
Both, ideally. The libstdc++ test should definitely be fixed because
it fails with released versions of glibc already in the wild. But
glibc should also be
Hi Andre,
Am 17.06.24 um 09:51 schrieb Andre Vehreschild:
Regarding your question on the coarray-tests that are not in the
coarray-directory: These test in most cases test only one method of
implementing coarrays. I.e., they are either testing just -fcoarray=single or
-fcoarray=lib -lcaf_single,
C2Y has adopted support for alignof applied to incomplete array types
(N3273). Add this support to GCC. As the relevant checks are in
c-family code that doesn't have access to functions such as
pedwarn_c23, this remains a hard error for older versions and isn't
handled by -Wc23-c2y-compat, althou
On Mon, 17 Jun 2024, Jakub Jelinek wrote:
> 2024-06-17 Jakub Jelinek
>
> PR driver/115440
> * opts-common.cc (add_misspelling_candidates): If opt1 is non-NULL,
> add a space and opt1 to the alternative suggestion text.
>
> * g++.dg/cpp1z/pr115440.C: New test.
OK.
--
Hi Richi,
on 2024/6/14 18:31, Richard Biener wrote:
> The following retires vcond{,u,eq} optabs by stopping to use them
> from the middle-end. Targets instead (should) implement vcond_mask
> and vec_cmp{,u,eq} optabs. The PR this change refers to lists
> possibly affected targets - those impleme
Hi Suwa-san,
On Mon, Jun 17, 2024 at 04:17:15PM +0900, Takayuki 'January June' Suwa wrote:
> The previous constant synthesis logic had some issues that were non-fatal
> but worth considering:
>
> - It didn't work with DFmode literals, because those were cast to SImode
> rather SFmode when split
Tested on x86-64/Linux, applied on the mainline.
2024-06-17 Eric Botcazou
c-family/
* c-ada-spec.cc (is_float16): New predicate.
(dump_ada_node) : Call it.
--
Eric Botcazoudiff --git a/gcc/c-family/c-ada-spec.cc b/gcc/c-family/c-ada-spec.cc
index a41e93aeafb..e1b1b2a4b73 100
On Mon, Jun 17, 2024 at 2:29 PM Eric Botcazou wrote:
>
> Tested on x86-64/Linux, applied on the mainline.
>
>
> 2024-06-17 Eric Botcazou
>
> c-family/
> * c-ada-spec.cc (is_float16): New predicate.
> (dump_ada_node) : Call it.
Hmm, is_float16 seems to be me would be _Float16 ra
This is a new version of the patch. This adds the -fno-short-enums flag
to the tests. I will commit it if the CI for am does not claim this time.
Bootstrapped and regression tested on x86_64.
c23: Fix for redeclared enumerator initialized with different type
[PR115109]
c23 spec
On Sat, 15 Jun 2024, Georg-Johann Lay wrote:
> Applied this one:
Cool.
> +SimulAVR at https://www.nongnu.org/simulavr";
This one gives a http response of "301 Moved Permanently" redirecting to
https://www.nongnu.org/simulavr/ . I'll fix this in a minute.
On a related note, though, can we u
The original link gives a "301 Moved Permanently", easily fixed by
appending a slash.
Pushed.
Gerald
---
htdocs/backends.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/backends.html b/htdocs/backends.html
index 1f7c85d7..d86783a6 100644
--- a/htdocs/backend
Hi!
Thanks for posting this again. Much easier to find that way :-)
On Mon, Jun 17, 2024 at 07:15:48PM +0200, Jakub Jelinek wrote:
> While my r15-1001-g4cf2de9b5268224 PCH PIE power fix change decreased the
> .data section sizes (219792 -> 189336), it increased the size of already
> huge rs6000_
Hi!
On Mon, Jun 17, 2024 at 05:26:39PM -0500, Peter Bergner wrote:
> While auditing our ROP code generation for some test cases I wrote, I noticed
> a few issues which I'm tracking in PR114759. The first issue I noticed is we
> disable shrink-wrapping when using -mrop-protect, even in the cases w
On 6/16/24 9:40 PM, Kewen.Lin wrote:
> on 2024/6/17 10:31, Peter Bergner wrote:
>> On 6/16/24 9:10 PM, Kewen.Lin wrote:
>>> on 2024/6/15 01:05, Peter Bergner wrote:
That said, the --with-cpu=power5 build without fortran did bootstrap and
regtest with no regressions, so the build did test
On 6/17/24 12:33 PM, Edwin Lu wrote:
On rv32 targets, vwsll_zext1_scalar_ would trigger an ice in
maybe_legitimize_instruction when zero extending a uint32 to uint64 due
to a mismatch between the input operand's mode (DI) and the expanded insn
operand's mode (Pmode == SI). Ensure that mode of
On 6/17/24 12:33 PM, Edwin Lu wrote:
When emitting insns, we have an early assertion to ensure the input
operand's mode and the expanded operand's mode are the same; however, it
does not perform this check if the pattern does not have an explicit
machine mode specifying the operand. In this sc
This aarch64 sve specific code was fixed by r15-917-gc9842f99042454
which added a riscv specific testcase so adding an aarch64 one to test
the fix does not regress is a good idea.
Committed as obvious after testing the testcase for aarch64-linux-gnu.
PR tree-optimization/97405
gcc/testsu
Binutils 2.42 and before don't support Zaamo/Zalrsc. Promote Zaamo/Zalrsc to
'a' in the -march string when assembling.
This change respects Zaamo/Zalrsc when generating code.
Testcases that check for the default isa string will fail with the old binutils
since zaamo/zalrsc aren't emitted anymore.
> Pengxuan Zheng writes:
> > This patch adds the fix_truncv4sfv4hi2 (V4SF->V4HI) pattern which is
> > implemented using fix_truncv4sfv4si2 (V4SF->V4SI) and then truncv4siv4hi2
> (V4SI->V4HI).
> >
> > PR target/113882
> >
> > gcc/ChangeLog:
> >
> > * config/aarch64/aarch64-simd.md (fix_trun
Be explicit when we use "cfun".
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
OK for trunk?
gcc/ChangeLog:
* dominance.cc (compute_dom_fast_query): Replace uses of
"dom_computed" macro with explicit use of cfun.
(compute_do
This patch series adds support for outputting global variables when the
-gcodeview option is provided, along with the type system to go along
with this.
As with previous patches, the best way to see the output is run
Microsoft's cvdump.exe against the object file:
https://github.com/microsoft/micr
Translates DW_TAG_pointer_type DIEs into LF_POINTER symbols, which get
output into the .debug$T section.
gcc/
* dwarf2codeview.cc (FIRST_TYPE): Define.
(struct codeview_custom_type): New structure.
(custom_types, last_custom_type): New variables.
Parse the DW_TAG_variable DIEs, and outputs S_GDATA32 (for global variables)
and S_LDATA32 (static global variables) symbols into the .debug$S section.
gcc/
* dwarf2codeview.cc (S_LDATA32, S_GDATA32): Define.
(struct codeview_symbol): New structure.
(sym, la
Translates DW_TAG_structure_type DIEs into LF_STRUCTURE symbols, and
DW_TAG_class_type DIEs into LF_CLASS symbols.
gcc/
* dwarf2codeview.cc
(struct codeview_type): Add is_fwd_ref member.
(struct codeview_subtype): Add lf_member to union.
(struct
Translate DW_TAG_const_type and DW_TAG_volatile_type DIEs into
LF_MODIFIER symbols.
gcc/
* dwarf2codeview.cc
(struct codeview_custom_type): Add lf_modifier to union.
(write_cv_padding, write_lf_modifier): New functions.
(write_custom_types): Call
Translates structure members with DW_AT_data_bit_offset set in DWARF
into LF_BITFIELD symbols.
gcc/
* dwarf2codeview.cc
(struct codeview_custom_type): Add lf_bitfield to union.
(write_lf_bitfield): New function.
(write_custom_types): Call write_l
gcc/
* dwarf2codeview.cc (get_type_num): Handle typedefs.
---
gcc/dwarf2codeview.cc | 6 ++
1 file changed, 6 insertions(+)
diff --git a/gcc/dwarf2codeview.cc b/gcc/dwarf2codeview.cc
index eb7c1270e31..5006a176260 100644
--- a/gcc/dwarf2codeview.cc
+++ b/gcc/dwarf2codeview.cc
On 6/14/24 20:03, Jakub Jelinek wrote:
Also wonder about the
// { dg-additional-options "-march=z14" { target s390*-*-* } }
line, doesn't that mean the test will FAIL on all pre-z14 HW?
Shouldn't it use some z14_runtime or similar effective target, or
check in main (in that case copied over to g+
Adds a get_type_num function to translate type DIEs into CodeView
numbers, along with a hash table for this. For now we just deal with
the base types (integers, Unicode chars, floats, and bools).
gcc/
* dwarf2codeview.cc (struct codeview_type): New structure.
(struct d
On 6/17/24 6:11 PM, Segher Boessenkool wrote:
> "ROP insns" are the instructions used in such exploits, not what you
> mean here :-)
>
> The instructions are called "hash*"C, so maybe call tbem "hash insns"
> or "ROP protect hash insns"?.
Ok, that bad verbiage was in the extra commentary not part
Translates DW_TAG_enumeration_type DIEs into LF_ENUM symbols.
gcc/
* dwarf2codeview.cc (MAX_FIELDLIST_SIZE): Define.
(struct codeview_integer): New structure.
(struct codeview_subtype): Likewise
(struct codeview_custom_type): Add lf_fieldlist and
Translates DW_TAG_union_type DIEs into LF_UNION symbols.
gcc/
* dwarf2codeview.cc (write_lf_union): New function.
(write_custom_types): Call write_lf_union.
(add_struct_forward_def): Handle DW_TAG_union_type DIEs.
(get_type_num_struct): Handle un
Translates DW_TAG_array_type DIEs into LF_ARRAY symbols.
gcc/
* dwarf2codeview.cc
(struct codeview_custom_type): Add lf_array to union.
(write_lf_array): New function.
(write_custom_types): Call write_lf_array.
(get_type_num_array_typ
1 - 100 of 123 matches
Mail list logo
