On Jun 18, 2025, "Richard Earnshaw (lists)" wrote:
> On 18/06/2025 21:46, Alexandre Oliva wrote:
>> The compiler, in kernel mode (that's implicit), rejects thumb mode:
>> $ arm-wrs-vxworks7r2-gcc -march=armv7 -S whatever.c
>> arm-wrs-vxworks7r2-gcc: error: -mthumb and kernel mode are mutually
>>
On Thu, Jun 19, 2025 at 08:33:10AM +0200, Richard Biener wrote:
> How does this interact with -mincoming-stack-boundary? Is this, and thus
> when we need stack realignment, visible here? Do we know whether we need
> to realign the stack anyway for other reasons?
-mincoming-stack-boundary= like -
> Am 18.06.2025 um 21:48 schrieb Jakub Jelinek :
>
> Hi!
>
> The following testcase shows a regression caused by the r10-577 change
> made for cris. Before that change, the MEM holding (in this case 3 byte)
> struct parameter was BITS_PER_WORD aligned, now it is just BITS_PER_UNIT
> aligned
> Am 18.06.2025 um 21:37 schrieb Jakub Jelinek :
>
> Hi!
>
> Unfortunately, the following further testcase shows that there aren't
> problems only with very large precisions and large exponents, but pretty
> much anything larger than 64-bits. After all, before _BitInt support dfp
> didn't ev
Andrew MacLeod writes:
> + // Use ths opportunity to make sure mask reflects always reflects the
> + // best mask we have.
>m_bitmask = bm;
May I suggest:
"Use this opportunity to make sure mask always reflects the best mask we have."
Aldy
Andrew MacLeod writes:
> - // See if we can exclude CST based on the known 0 bits.
> - if (!m_bitmask.unknown_p ()
> - && cst != 0
> - && wi::bit_and (m_bitmask.get_nonzero_bits (), cst) == 0)
> + // Check is the known bits in bitmask exclude CST.
> + if (!m_bitmask.member_p (cst))
It is really cool that you're tackling all this. It looks like you're
running into some of the things I ran into: getting it perfect is hard,
and if you do, it's expensive. Glad you're looking into it.
Also, loved the switch rewrite you did in vr-values.c. That whole file really
needs rangerifi
longlong.h for RISCV should define count_leading_zeros and
count_trailing_zeros and COUNT_LEADING_ZEROS_0 when ZBB is enabled.
The following patch patch fixes the bug reported in,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110181
The divdi3 on riscv32 with zbb extension generates __clz_tab
ins
Extend the remove_redundant_vector pass to handle vector broadcasts from
constant and variable scalars. When broadcasting from constants and
function arguments, we can place a single widest vector broadcast at
entry of the nearest common dominator for basic blocks with all uses
since constants and
On 2025-06-18 18:40, Qing Zhao wrote:
Okay, I guess that I didn’t put enough attention on the above example
previously, sorry about that...
Read it multiple times this time, my question is for the following code portion:
objsz = __builtin_dynamic_object_size (ptr, 0);
__memcpy_chk (ptr, src,
On 18/06/2025 21:46, Alexandre Oliva wrote:
On Jun 18, 2025, Richard Earnshaw wrote:
On 18/06/2025 10:31, Alexandre Oliva wrote:
On Jun 9, 2025, "Richard Earnshaw (lists)" wrote:
On 08/06/2025 14:15, Alexandre Oliva wrote:
VxWorks kernel mode doesn't support thumb code, so the test fail
> On Jun 18, 2025, at 17:57, Siddhesh Poyarekar wrote:
>
> On 2025-06-18 17:46, Qing Zhao wrote:
>> Okay, I guess that I didn’t put enough attention on the above example
>> previously, sorry about that...
>> Read it multiple times this time, my question is for the following code
>> portion:
>
On Wed, 18 Jun 2025, Gábor Németh wrote:
> > If normal user code that includes gets this warning (built with
> > an installed compiler), that needs fixing in some way. If not, what is
> > different about how GCC uses its own libstdc++? (For example, it's
> > important to include system headers
On Wed, 18 Jun 2025, Georg-Johann Lay wrote:
> Should read "older than" instead of "older then".
>
> Ok with that typo fixed?
>> PR other/115893
>> gcc/
>> * doc/install.texi (Prerequisites): Note that Texinfo older
>> than v7.1 may throw incorrect build warnings, cf.
>> https:/
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-1567-g4eb111363899a9.
gcc/analyzer/ChangeLog:
* checker-event.h (checker_event::get_kind): New accessor.
(checker_event::m_kind): Make private.
* checker-pa
On 2025-06-18 17:46, Qing Zhao wrote:
Okay, I guess that I didn’t put enough attention on the above example
previously, sorry about that...
Read it multiple times this time, my question is for the following code portion:
objsz = __builtin_dynamic_object_size (ptr, 0);
__memcpy_chk (ptr, src
Hi Mikael,
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
Just wondering... how does this relate to the recent fix of PR120483
by Andre? Is this also a regression? If so, maybe a backport would be
in order.
Best regads
Thomas
> On Jun 18, 2025, at 12:17, Siddhesh Poyarekar wrote:
>
> On 2025-06-18 10:32, Qing Zhao wrote:
>>> A NULL check alone does not solve this problem because the pointer could be
>>> arbitrary and invalid. I thought some more about adding the size
>>> expression only if there's an existing acc
On 6/17/25 5:58 PM, Jeff Law wrote:
> You could make the argument that instead of defaulting to rocket that we
> should use a default generic tuning model. That would make much more
> sense than deliberately choosing the wrong values for the rocket uarch
> because it happens to be used as the d
On 2025-06-18 17:16, Kees Cook wrote:
I agree, validating invalid pointers is not the job of __bdos. My concern
is about having __bdos *generate* code that results in invalid pointer
access.
I would like a way to indicate the desire to do the dereference. Having
an invalid pointer is a totally
On Mon, 16 Jun 2025, Qing Zhao wrote:
> Current array bound checker only instruments ARRAY_REF, and the INDEX
> information is the 2nd operand of the ARRAY_REF.
>
> When extending the array bound checker to pointer references with
> counted_by attributes, the hardest part is to get the INDEX of t
On Mon, 16 Jun 2025, Qing Zhao wrote:
> +The counted_by attribute is not allowed for a pointer to @code{void},
@code{counted_by}.
This patch is OK with that fix once the rest of this series is approved.
--
Joseph S. Myers
josmy...@redhat.com
On 6/18/25 2:02 PM, Mikael Morin wrote:
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
Was there a PR for this? or something you just ran into?
Not a problem either way, just curious.
It looks OK to me. OK for master.
Jerry
-- >8 --
gcc/fortran/ChangeL
On Wed, Jun 18, 2025 at 03:50:42PM -0400, Siddhesh Poyarekar wrote:
> On 2025-06-18 15:14, Qing Zhao wrote:
> > > struct fam_container
> > > {
> > > int a;
> > > int count;
> > > char fam[] __counted_by__ (count);
> > > };
> > >
> > > size_t
> > > baz (struct fam_container *ptr)
> > > {
> >
On Wed, 18 Jun 2025, Alfie Richards wrote:
> gcc/c-family/ChangeLog:
>
> * c-format.cc (local_string_slice_node): New node type.
> (asm_fprintf_char_table): New entry.
> (init_dynamic_diag_info): Add support for string_slice.
> * c-format.h (T_STRING_SLICE): New node type.
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_trans_deferred_array): Statically
initialize deferred length variable for SAVEd character arrays.
gcc/testsuite/ChangeLog:
* gfortran.d
On Jun 18, 2025, Richard Earnshaw wrote:
> On 18/06/2025 10:31, Alexandre Oliva wrote:
>> On Jun 9, 2025, "Richard Earnshaw (lists)" wrote:
>>
>>> On 08/06/2025 14:15, Alexandre Oliva wrote:
VxWorks kernel mode doesn't support thumb code, so the test fails.
Require thumb2 suppo
On 2025-06-18 16:20, Qing Zhao wrote:
On Jun 18, 2025, at 15:50, Siddhesh Poyarekar wrote:
On 2025-06-18 15:14, Qing Zhao wrote:
struct fam_container
{
int a;
int count;
char fam[] __counted_by__ (count);
};
size_t
baz (struct fam_container *ptr)
{
...
ptr->count = 0;
__builtin_f
> On Jun 18, 2025, at 15:50, Siddhesh Poyarekar wrote:
>
> On 2025-06-18 15:14, Qing Zhao wrote:
>>> struct fam_container
>>> {
>>> int a;
>>> int count;
>>> char fam[] __counted_by__ (count);
>>> };
>>>
>>> size_t
>>> baz (struct fam_container *ptr)
>>> {
>>> ...
>>> ptr->count = 0;
>>>
On 2025-06-18 15:14, Qing Zhao wrote:
struct fam_container
{
int a;
int count;
char fam[] __counted_by__ (count);
};
size_t
baz (struct fam_container *ptr)
{
...
ptr->count = 0;
__builtin_free (ptr);
...
return 0;
}
void
bar (size_t insz)
{
struct fam_container *c =
__builtin_
Hi!
The following testcase shows a regression caused by the r10-577 change
made for cris. Before that change, the MEM holding (in this case 3 byte)
struct parameter was BITS_PER_WORD aligned, now it is just BITS_PER_UNIT
aligned and that causes significantly worse generated code.
So, the MAX (DEC
Hi!
Unfortunately, the following further testcase shows that there aren't
problems only with very large precisions and large exponents, but pretty
much anything larger than 64-bits. After all, before _BitInt support dfp
didn't even have {,unsigned }__int128 <-> _Decimal{32,64,128,64x} support,
an
> On Jun 18, 2025, at 12:17, Siddhesh Poyarekar wrote:
>
> On 2025-06-18 10:32, Qing Zhao wrote:
>>> A NULL check alone does not solve this problem because the pointer could be
>>> arbitrary and invalid. I thought some more about adding the size
>>> expression only if there's an existing acc
Am 17.06.25 um 21:27 schrieb Harald Anlauf:
Am 17.06.25 um 19:44 schrieb Steve Kargl:
On Tue, Jun 17, 2025 at 12:05:34PM +0300, Janne Blomqvist wrote:
On Mon, Jun 16, 2025 at 9:41 PM Harald Anlauf wrote:
Am 16.06.25 um 02:18 schrieb Steve Kargl:
Harald,
I did a quick glance at the patch an
On Wed, Jun 18, 2025 at 04:06:14PM +0100, Stafford Horne wrote:
> On Sat, Jun 07, 2025 at 06:53:28PM +0300, Dimitar Dimitrov wrote:
> > On Sat, Jun 07, 2025 at 11:38:46AM +0100, Stafford Horne wrote:
> > > On Fri, Jun 06, 2025 at 09:54:53PM +0100, Stafford Horne wrote:
> > > > On Fri, Jun 06, 2025
On 6/18/25 14:17, Andrew Pinski wrote:
On Wed, Jun 18, 2025, 11:11 AM Andrew MacLeod wrote:
On 6/18/25 14:00, Andrew Pinski wrote:
>
>
> +/* { dg-final { scan-tree-dump-not "foo" "evrp" } } */
>
> May I suggest this be changed to "foo " (adding a space). To avoid
On Thu, Jun 12, 2025 at 08:12:59AM -0600, Jeff Law wrote:
>
>
> On 6/12/25 4:04 AM, Richard Sandiford wrote:
>
> > > > Richard, Jeff, it does not seem appropriate to merge this patch now,
> > > > given that it breaks avr and or1k. Let me know if such experiment is
> > > > desired despite the kn
On Wed, Jun 18, 2025, 11:11 AM Andrew MacLeod wrote:
>
> On 6/18/25 14:00, Andrew Pinski wrote:
> >
> >
> > +/* { dg-final { scan-tree-dump-not "foo" "evrp" } } */
> >
> > May I suggest this be changed to "foo " (adding a space). To avoid
> > maybe matching on a directory name that contains foo.
On 6/18/25 14:00, Andrew Pinski wrote:
+/* { dg-final { scan-tree-dump-not "foo" "evrp" } } */
May I suggest this be changed to "foo " (adding a space). To avoid
maybe matching on a directory name that contains foo.
I only noticed this today after you pushed thr change sorry.
Thanks,
And
On Tue, Jun 10, 2025, 10:03 AM Andrew MacLeod wrote:
> simplify_switch_using_ranges has never been converted over properly to
> use irange. It still uses get_legacy_range, and as a result, is very
> limited in how it processes cases labels. In particular it is unable to
> remove cases in the mi
bitmask intersection does not update the m_bitmask field if the new mask
matches the get_bitmask () result.
the get_bitmask () routine also incorporates a mask calculated from the
range itself.
THe problem in intersection is we use the get_bitmask() version to
compare to the new one to see
This patch improves switch handling when the index has a bitmask
irange::contains__p (wide_int&) was checking whether a constant was a
member of range with a bitmask by first checking if the bitmask was
unknown, and if not, then perform a bitwise-and on the constant.. This
overlooks the fact
Pushed. Lets see if the thread testcase triggers a different number of
threads somewhere else.
Andrew
On 6/10/25 13:01, Andrew MacLeod wrote:
simplify_switch_using_ranges has never been converted over properly to
use irange. It still uses get_legacy_range, and as a result, is very
limited
Should read "older than" instead of "older then".
Ok with that typo fixed?
Johann
Am 18.06.25 um 19:04 schrieb Georg-Johann Lay:
This patch adds a note to doc/install.text, Prerequisites, Texinfo
that Texinfo may throw incorrect build warnings when a version older
than v7.1 is used. See also
This patch adds a note to doc/install.text, Prerequisites, Texinfo
that Texinfo may throw incorrect build warnings when a version older
than v7.1 is used. See also https://gcc.gnu.org/PR115893
Ok for trunk?
Johann
--
install.texi: Note that Texinfo < v7.1 may throw incorrect warnings.
This patch adds the vmtest-tool subdirectory under contrib which tests
BPF programs under a live kernel using a QEMU VM. It automatically
builds the specified kernel version with eBPF support enabled
and stores it under "~/.vmtest-tool", which is reused for future
invocations.
It can also compile
This patch adds initial version of vmtest-tool script to test BPF programs on
live kernel
For now, the tool is standalone, but it is intended to be integrated with the
DejaGnu testsuite to run BPF testcases in future patches.
Current Limitations:
- Only x86_64 is supported. Support for additiona
On 2025-06-18 10:32, Qing Zhao wrote:
A NULL check alone does not solve this problem because the pointer could be
arbitrary and invalid. I thought some more about adding the size expression
only if there's an existing access like I suggested in that email, but I
realize that doesn't make sens
On 16/06/25 22:31, Jan Hubicka wrote:
External email: Use caution opening links or attachments
gcc/ChangeLog:
* auto-profile.cc (AUTO_PROFILE_VERSION): Bump from 2 to 3.
(string_table::get_real_name): Define new member function.
(string_table::get_file_name): Likewise.
Hi all,
This adds support for -mcpu=gb10. This is a big.LITTLE configuration
involving Cortex-X925 and Cortex-A725 cores. The appropriate MIDR numbers
are added to detect them in -mcpu=native. We did not add an
-mcpu=cortex-x925.cortex-a725 option because GB10 does include the crypto
instructions
If normal user code that includes gets this warning (built with
an installed compiler), that needs fixing in some way. If not, what is
different about how GCC uses its own libstdc++? (For example, it's
important to include system headers with -isystem not -I, does GCC get
this right when buildi
On 6/17/25 4:03 PM, Iain Sandoe wrote:
}
+ finish_expr_stmt (body_use);
Would it work to emit body_use where you build it, instead of separately for
EH/non-EH?
Yes it works fine, as below, OK?
OK.
thanks
Iain
--- 8< ---
This implements the final piece of the revised CWG25
On Sat, Jun 07, 2025 at 06:53:28PM +0300, Dimitar Dimitrov wrote:
> On Sat, Jun 07, 2025 at 11:38:46AM +0100, Stafford Horne wrote:
> > On Fri, Jun 06, 2025 at 09:54:53PM +0100, Stafford Horne wrote:
> > > On Fri, Jun 06, 2025 at 11:31:00PM +0300, Dimitar Dimitrov wrote:
> > > > On Fri, Jun 06, 202
> On Jun 17, 2025, at 17:15, Siddhesh Poyarekar wrote:
>
> On 2025-05-07 12:59, Qing Zhao wrote:
>> Hi,
>> This is the 2nd version of the patch for:
>> Evaluate the object size by the size of the pointee type when the type
>> is a structure with flexible array member which is annotated with
>>
> -Original Message-
> From: Uros Bizjak
> Sent: Wednesday, June 18, 2025 9:22 PM
> To: Cui, Lili
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao ;
> hongjiu...@intel.com
> Subject: Re: [PATCH] x86: Fix shrink wrap separate ICE under -fstack-clash-
> protection [PR120697]
>
> On Wed, Jun 1
The was_finalized tracking mechanism was introduced in commit 1af22e4 to
prevent duplicate finalization of the same expression+component combination
within a namespace. However, this mechanism had a flaw: it
stored gfc_expr* pointers that could become stale, leading to use-after-free
bugs and compi
On 17/06/2025 18:19, Jeff Law wrote:
On 6/17/25 7:15 AM, Paul-Antoine Arras wrote:
This is part of my vector-scalar FMA series. See:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679513.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685624.html
The attached patch handles vfmacc
The function gets dump flags as 'flags' parameter, so shouldn't use
dump_flags.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
* tree-cfg.cc (dump_function_to_file): Use flags, not dump_flags.
---
gcc/tree-cfg.cc | 20 ++--
1 file changed, 10 insertions(+), 10
On Wed, Jun 18, 2025 at 3:11 PM Cui, Lili wrote:
>
> From: Lili Cui
>
> Hi Uros,
>
> An assertion I added in shrink wrap separate V2 reports ICE when
> -fstack-clash-protection is enabled. The assertion should not be added here.
>
> I created a patch to remove 3 assertions and their associated c
From: Lili Cui
Hi Uros,
An assertion I added in shrink wrap separate V2 reports ICE when
-fstack-clash-protection is enabled. The assertion should not be added here.
I created a patch to remove 3 assertions and their associated code.
1. Reproduced PR120697 issue and solved the issue with thi
On Wed, Jun 11, 2025 at 5:02 PM Andrew MacLeod wrote:
>
>
> On 6/10/25 17:05, Richard Biener wrote:
> >
> >
> >> Am 10.06.2025 um 22:18 schrieb Andrew MacLeod :
> >>
> >>
> >>
> >> I had a question asked of me, and now I'm passing the buck.
> >>
> >> extern void *memcpy(void *, const void *,
Minor update to this patch addressing Jeff Law's feedback.
It turns out I ended up not using the strcmp function, so no edits to other
patches are required. I've left the function in as I have future work that I
plan to use it for.
Regression tested and bootstrapped for aarch64-none-linux-gnu
and
On Wed, Jun 11, 2025 at 11:04 AM Eric Botcazou wrote:
>
> > While you are at it
> >
> > if ((code2 == BIT_AND_EXPR
> > - && TYPE_PRECISION (TREE_TYPE (op0)) == 1
> >&& TREE_CODE (gimple_assign_rhs2 (second)) !=
> > INTEGER_CST)
> >
On 06.06.2025 08:42, Jan Beulich wrote:
> As per documentation, even 4.7 ought to suffice. At least 4.13 objects
> to there being a blank between @anchor and the opening curly brace.
Short of feedback I've committed this as (hopefully) obvious.
> ---
> Noticed with gcc15, so may want backporting.
Hi,
this patch moves afdo inlining from early inliner into specialized one.
The reason is that early inliner is by design non-recursive while afdo
inliner needs to recurse. In the past google handled it by increasing
early inliner iterations, but it can be done easily and cheaply without
it by sim
>
> IMO doing this in a loop would have to handle all the above cases and would
> make it hard to read. Also, we would have two level for now. Even if this
> change in the future, this is not going to be too long.
>
> Here is the revised patch,
>
> Is this OK for mainline.
> gcc/ChangeLog:
>
OKay, the patch v2 is in the link :
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686987.html
Thanks
Dongyan Chen
在 2025/6/18 17:40, Kito Cheng 写道:
@@ -78,6 +79,7 @@ RISCV_CORE("sifive-e31", "rv32imac", "sifive-3-series")
RISCV_CORE("sifive-e34", "rv32imafc", "sifive-3-se
According to the discussion in
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686893.html, by creating
a -mtune=generic may be a good idea to slove the question regarding the branch
cost.
Changes for v2:
- Delete the code about -mcpu=generic.
gcc/ChangeLog:
* config/riscv/riscv-cor
Hi,
Thanks for looking.
>
> I think this can be simplified to
>
> while (*(++ptr) && only_digits)
>only_digits = is_digit (*ptr);
IMO this is harder to read but I am OK either way.
>
>> + if (only_digits)
>> +*last_dot = 0;
>> + char *next_dot = strrchr (ret, '.');
>> + /* if nested fu
On 10.06.2025 21:11, Sandra Loosemore wrote:
> On 6/9/25 23:56, Jan Beulich wrote:
>> On 06.06.2025 17:28, Sandra Loosemore wrote:
>>> On 6/6/25 00:44, Jan Beulich wrote:
As per documentation, even 4.7 ought to suffice. At least 4.13 objects
to there being nothing ahead of the first comma
commit ef26c151c14a87177d46fd3d725e7f82e040e89f
Author: Roger Sayle
Date: Thu Dec 23 12:33:07 2021 +
x86: PR target/103773: Fix wrong-code with -Oz from pop to memory.
added "*mov_and" and extended "*mov_or" to transform
"mov $0,mem" to the shorter "and $0,mem" and "mov $-1,mem" to the
On 18/06/25 14:21, Kugan Vivekanandarajah wrote:
Hi,
On 17 Jun 2025, at 4:51 pm, Kugan Vivekanandarajah
wrote:
External email: Use caution opening links or attachments
On 17 Jun 2025, at 4:18 pm, Dhruv Chawla wrote:
On 17/06/25 06:10, Kugan Vivekanandarajah wrote:
External email: Use c
ping?
On Mon, 26 May 2025 at 17:26, Christophe Lyon
wrote:
>
> On Mon, 26 May 2025 at 17:14, Christophe Lyon
> wrote:
> >
> > Commit r15-7152-g57b706d141b87c removed
> > /* { dg-do run { target*-*-linux* *-*-gnu* *-*-uclinux* } } */
> >
> > from these tests, turning them into 'compile' only test
@@ -78,6 +79,7 @@ RISCV_CORE("sifive-e31", "rv32imac", "sifive-3-series")
RISCV_CORE("sifive-e34", "rv32imafc", "sifive-3-series")
RISCV_CORE("sifive-e76", "rv32imafc", "sifive-7-series")
+RISCV_CORE("generic", "rv64gc","generic")
^^^ Drop this and add -mtune=ge
On 18/06/2025 10:31, Alexandre Oliva wrote:
On Jun 9, 2025, "Richard Earnshaw (lists)" wrote:
On 08/06/2025 14:15, Alexandre Oliva wrote:
VxWorks kernel mode doesn't support thumb code, so the test fails.
Require thumb2 support.
You already have -march=armv7, so that implies any thumb co
Hi,
> On 17 Jun 2025, at 2:14 am, Jan Hubicka wrote:
>
> External email: Use caution opening links or attachments
>
>
> Hi,
>> Introduction
>>
>>
>> Per PR120229 (gcc.gnu.org/PR120229), the auto-profile pass cannot distinguish
>> profile information for `function_instance's with
> @@ -78,6 +79,7 @@ RISCV_CORE("sifive-e31", "rv32imac",
> "sifive-3-series")
> RISCV_CORE("sifive-e34", "rv32imafc", "sifive-3-series")
> RISCV_CORE("sifive-e76", "rv32imafc", "sifive-7-series")
>
> +RISCV_CORE("generic", "rv64gc","generic")
^^^ Drop this and add
On Jun 9, 2025, "Richard Earnshaw (lists)" wrote:
> On 08/06/2025 14:15, Alexandre Oliva wrote:
>>
>> VxWorks kernel mode doesn't support thumb code, so the test fails.
>> Require thumb2 support.
> You already have -march=armv7, so that implies any thumb code will be
> thumb2.
The parm of arm
On 17/06/2025 14:37, Jeff Law wrote:
On 6/12/25 10:53 AM, Alfie Richards wrote:
The string_slice inherits from array_slice and is used to refer to a
substring of an array that is memory managed elsewhere without modifying
the underlying array.
For example, this is useful in cases such as when
longlong.h for RISCV should define count_leading_zeros and
count_trailing_zeros and COUNT_LEADING_ZEROS_0 when ZBB is enabled.
The following patch patch fixes the bug reported in,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110181
The divdi3 on riscv32 with zbb extension generates __clz_tab
inst
Hi,
> On 17 Jun 2025, at 4:51 pm, Kugan Vivekanandarajah
> wrote:
>
> External email: Use caution opening links or attachments
>
>
>> On 17 Jun 2025, at 4:18 pm, Dhruv Chawla wrote:
>>
>> On 17/06/25 06:10, Kugan Vivekanandarajah wrote:
>>> External email: Use caution opening links or attac
On Wed, Jun 18, 2025 at 2:30 PM Hongtao Liu wrote:
>
> On Mon, May 26, 2025 at 2:30 PM H.J. Lu wrote:
> >
> > On Sun, May 25, 2025 at 7:02 PM H.J. Lu wrote:
> > >
> > > On Sun, May 25, 2025 at 8:12 AM H.J. Lu wrote:
> > > >
> > > > On Sun, May 25, 2025 at 7:47 AM H.J. Lu wrote:
> > > > >
> > >
1. Don't generate the loop if the loop count is 1.
2. For memset with vector on small size, use vector if small size supports
vector, otherwise use the scalar value.
3. Duplicate the promoted scalar value for vector.
4. Always expand vector-version of memset for vector_loop.
5. Use misaligned prolo
On Mon, Jun 16, 2025 at 4:28 PM Hongtao Liu wrote:
>
> On Mon, Jun 16, 2025 at 4:30 PM Hongtao Liu wrote:
> >
> > >+enum redundant_load_kind
> > >+{
> > >+ LOAD_CONST0_VECTOR,
> > >+ LOAD_CONSTM1_VECTOR,
> > >+ LOAD_VECTOR
> > >+};
> > Perhaps rename to x86_cse_kind, X86_CSE_CONST0_VECTOR,
> >
According to the discussion in
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686893.html, by creating
a -mtune=generic may be a good idea to slove the question regarding the branch
cost.
gcc/ChangeLog:
* config/riscv/riscv-cores.def (RISCV_TUNE): Add "generic" tune.
(RISCV_
According to the discussion in
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686893.html, by creating
a -mtune=generic may be a good idea to slove the question regarding the branch
cost.
gcc/ChangeLog:
* config/riscv/riscv-cores.def (RISCV_TUNE): Add "generic" tune.
(RISCV_
On Wed, Jun 18, 2025 at 2:55 PM Hongtao Liu wrote:
>
> On Wed, Jun 18, 2025 at 2:39 PM H.J. Lu wrote:
> >
> > On Mon, Jun 16, 2025 at 4:14 PM Hongtao Liu wrote:
> > >
> > > >+enum redundant_load_kind
> > > >+{
> > > >+ LOAD_CONST0_VECTOR,
> > > >+ LOAD_CONSTM1_VECTOR,
> > > >+ LOAD_VECTOR
> >
87 matches
Mail list logo
