> - avl = GEN_INT (0);
> + avl = TARGET_XTHEADVECTOR ? gen_rtx_REG(Pmode, 0) : GEN_INT (0);
Ah, the CI linter complains about a missing space after gen_rtx_REG.
--
Regards
Robin
> From: Yunze Zhu
>
> Fix a bug th.vsetvli generates from vext_x_v with an imm operand,
> which reports illegal operand. This patch fix this by replacing
> imm operand with reg operand in th.vsetvli.
LGTM but you might want to add check force_vector_length_operand
which likely needs similar handl
Both patches LGTM.
--
Regards
Robin
On Linux/x86_64,
87f97ffba93a2de17eca3927af901e3b3a103df7 is the first bad commit
commit 87f97ffba93a2de17eca3927af901e3b3a103df7
Author: Alexandre Oliva
Date: Wed Dec 18 22:17:31 2024 -0300
ifcombine field merge: handle masks with sign extensions
caused
FAIL: gcc.dg/field-merge-16.c sca
Introduce flags to disable ifcombine as a whole, or its new components.
Disable the potentially quadratic noncontiguous ifcombine at -O1.
Adjust the tests that expected it with -O to use -O2 instead.
Is this of interest? I've made it mostly for PR118032, but turned it
into a proper patch becau
From: Yunze Zhu
Fix a bug th.vsetvli generates from vext_x_v with an imm operand,
which reports illegal operand. This patch fix this by replacing
imm operand with reg operand in th.vsetvli.
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc:
gcc/testsuite/ChangeLog:
* gcc.target/ri
A gimple block with __builtin_unreachable () can't have code after it,
and gimple optimizers ensure there isn't any, even without
optimization. But if the block requires stack adjustments,
e.g. because of a call that passes arguments on the stack, expand will
emit that after the barrier, and the
We don't want to indirect pointers in strub wrappers, because it
generally isn't profitable, but if the argument is volatile, then we
must use indirection to preserve access patterns, so amend the
assertion check.
Regstrapped on x86_64-linux-gnu. Ok to install?
for gcc/ChangeLog
PR mi
When we emit a sequence before a preexisting insn and naming a BB to
store in the insns, we will attempt to store the BB even in barriers
present in the sequence.
Barriers don't expect blocks, and rtl checking catches the problem.
When emitting after a preexisting insn, we skip the block settin
Here's the consolidated patch what I've just installed.
ifcombine field merge: do not follow a second conversion [PR118046]
The testcase shows that conversions that would impact negatively the
ifcombine field merging implementation won't always have been
optimized out by the time we reach ifcomb
The ChangeLog entries were missing gcc.dg/.
Here's the consolidated patch what I've just installed.
ifcombine field merge: adjust testcases [PR118025]
There was a thinko in the testcase field-merge-9.c: I overcorrected it
for big-endian.
As a bonus, I'm including stdbool.h in field-merge-12.c,
On Dec 17, 2024, Alexandre Oliva wrote:
> On Dec 17, 2024, Sam James wrote:
>>> +/* { dg-options "-O3 -fno-tree-copy-prop -fno-tree-vrp" */
>> Missing closing '}'.
> Thanks, I've fixed that, and retested.
Here's the consolidated patch what I've just installed.
noncontiguous ifcombine: skip
From: Pan Li
Almost the same as the RVV strided load, the vector strided store
doesn't involve the (mem:BLK (scratch)) to alias all other memories.
It will make the alias analysis only consider the base address of
strided store.
PR target/118075
gcc/ChangeLog:
* config/riscv/ve
From: Pan Li
The vsse* dump check times changes on options (O2, O3) after we add
(mem:BLK (scratch)) to the define_insn of strided load.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/strided/strided_ld_st-1-f64.c: Adjust
the vsse check times based on optimization optio
Hello-
Happened to notice this minor issue that seems worth fixing. bootstrap +
regtest on x86-64, is it OK please? Thanks!
-Lewis
-- >8 --
It seems that tokens_buff_new() has always been allocating the virtual
location buffer 4 times larger than intended, and now that location_t is
64-bit, it
On 12/18/24 1:17 PM, Patrick O'Neill wrote:
On 12/18/24 15:09, Jeff Law wrote:
On 12/17/24 8:27 AM, Robin Dapp wrote:
Hi,
in PR117682 we build an interleaving pattern
{ 1, 201, 209, 25, 161, 105, 113, 185, 65, 9,
17, 89, 225, 169, 177, 249, 129, 73, 81, 153,
33, 233, 241, 5
On Wed, Dec 18, 2024 at 05:35:28PM -0500, David Malcolm wrote:
> Is _Bool meant to be usable in c90?
It is a keyword even when GCC compiles with -std={c89,c90,gnu89,gnu90}
(why not, _Bool is a reserved identifier in C89).
With -pedantic/-pedantic-errors there is a pedwarn about using it as a type,
Sam James writes:
> David Malcolm writes:
>
>> On Tue, 2024-11-26 at 16:35 -0500, Marek Polacek wrote:
>>> On Mon, Nov 25, 2024 at 10:49:02PM -0500, David Malcolm wrote:
>>> > This patch attempts to provide better error messages for
>>> > code compiled with C23 that hasn't been updated for
>>> >
On Wed, Dec 18, 2024 at 2:37 PM David Malcolm wrote:
>
> On Tue, 2024-11-26 at 16:35 -0500, Marek Polacek wrote:
> > On Mon, Nov 25, 2024 at 10:49:02PM -0500, David Malcolm wrote:
> > > This patch attempts to provide better error messages for
> > > code compiled with C23 that hasn't been updated f
David Malcolm writes:
> On Tue, 2024-11-26 at 16:35 -0500, Marek Polacek wrote:
>> On Mon, Nov 25, 2024 at 10:49:02PM -0500, David Malcolm wrote:
>> > This patch attempts to provide better error messages for
>> > code compiled with C23 that hasn't been updated for
>> > "bool", "true", and "false"
On Tue, 2024-11-26 at 16:35 -0500, Marek Polacek wrote:
> On Mon, Nov 25, 2024 at 10:49:02PM -0500, David Malcolm wrote:
> > This patch attempts to provide better error messages for
> > code compiled with C23 that hasn't been updated for
> > "bool", "true", and "false" becoming keywords (based on
>
On Wed, Dec 18, 2024 at 10:09:26AM -0800, Jerry D wrote:
> On 12/18/24 4:11 AM, Harald Anlauf wrote:
> > Hi Steve,
> >
> > thanks for the draft patch.
> >
> > I haven't looked close enough, but you may have to add support
> > for 'asis' being an optional dummy variable. The following
> > example
On Sat, 14 Dec 2024 at 13:36, François Dumont wrote:
>
> Hi
>
> Here is an update with the alloc ptr specific tests and so fixes.
>
> PR updated:
>
> https://forge.sourceware.org/gcc/gcc-TEST/pulls/27
Approved on the forge. Please add PR 57272 to the commit msg and push
to trunk - thanks for all
Am 18.12.24 um 22:05 schrieb Steve Kargl:
On Wed, Dec 18, 2024 at 01:11:14PM +0100, Harald Anlauf wrote:
I haven't looked close enough, but you may have to add support
for 'asis' being an optional dummy variable. The following
example crashes here with a segfault:
(program snipped for brevi
This replaces the use of FAIL in the new vec_cmp[u] expanders by that of a
predicate for the operator, which is (apparently) required for the optabs
machinery to properly compute the set of supported vector comparisons.
Tested on SPARC64/Solaris 11.4, applied on the mainline.
2024-12-18 Eric
std::regex builds a cache of equivalence classes by calling
std::regex_traits::transform_primary(c) for every char, which then
calls std::collate::transform which calls strxfrm. On several
targets strxfrm fails for non-ASCII characters. Because strxfrm has no
return value reserved to indicate an er
Hi Jerry,
I am working on the OpenCoarrays library in parallel. At the moment some of
their tests are non functional. And today I even found a bug in the current
implementation of caf-single and in my new approach. I am still fixing that.
But that should not keep you from looking into this patch
On Wed, Dec 18, 2024 at 01:11:14PM +0100, Harald Anlauf wrote:
>
> I haven't looked close enough, but you may have to add support
> for 'asis' being an optional dummy variable. The following
> example crashes here with a segfault:
>
(program snipped for brevity)
>
> There are other intrinsics
On 18 Dec 2024, at 20:33, Eric Botcazou wrote:
>
>> Bootstrapped and regtested (ada onlyj) on x86_64-apple-darwin.
>>
>> * gcc/ada/libgnat/s-trasym.adb: Returns the traceback in the required
>> form, using __gnat_get_executable_load_address to get the address
>> (or null, if not present).
>>
>>
Andre, have you tested this with the tests in OpenCoarrays suite?
I ask since this touches coarray things.
Jerry
On 12/16/24 1:58 AM, Andre Vehreschild wrote:
PING!
On Fri, 6 Dec 2024 19:10:08 +0100
Andre Vehreschild wrote:
Hi all,
I had to dive deeply into the issue with handling allocat
On Tue, 17 Dec 2024, James K. Lowden wrote:
> On Tue, 17 Dec 2024 18:04:01 + (UTC)
> Joseph Myers wrote:
>
> > I don't think we should introduce man pages as a new source format
> > for documentation in GCC. Either .texi or .rst (with generated man
> > pages) would be fine.
>
> I hope you
> Bootstrapped and regtested (ada onlyj) on x86_64-apple-darwin.
>
> * gcc/ada/libgnat/s-trasym.adb: Returns the traceback in the required
> form, using __gnat_get_executable_load_address to get the address
> (or null, if not present).
>
> 2024-12-17 Simon Wright
>
> gcc/ada/Changelog:
>
>
On Wed, Dec 18, 2024 at 01:19:43PM +0100, Andreas Schwab wrote:
> On Dez 12 2024, Jakub Jelinek wrote:
>
> > The intent was to test %cN because %N doesn't DTRT on various targets.
> > I have a patch to add %ccN support which should then work even on riscv
> > hopefully, but unfortunately it hasn't
The following patch is for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117248
The first patch variant resulted in PR117999 (new libgo test failures).
The patch was successfully bootstrapped and tested on x86-64.
The patch was also checked for libgo on arm for PR11799.
commit 936058ce9ed159b4
Hi Sandra, hi Jakub, hello world,
pre-remark: SA Sandra's patch is an updated post of her v4 version at
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669054.html
v4 (and, hence, v5) address Jakub's review comments to v3, i.e.
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660029
On 12/17/24 8:27 AM, Robin Dapp wrote:
Hi,
in PR117682 we build an interleaving pattern
{ 1, 201, 209, 25, 161, 105, 113, 185, 65, 9,
17, 89, 225, 169, 177, 249, 129, 73, 81, 153,
33, 233, 241, 57, 193, 137, 145, 217, 97, 41,
49, 121 };
with negative step expecting wraparo
Ok for trunk?
--
Update test case to align with used function in C++26.
gcc/testsuite/ChangeLog:
* g++.dg/abi/arm_rtti1.C: Check for expected symbol in C++26.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/g++.dg/abi/arm_rtti1.C | 3 ++-
1 file changed, 2 insertions(+), 1 deletio
The fuzzer tripped over a risc-v target issue in the expansion of CRCs.
In particular we want to use brev instruction to improve the reflection
code.
In the case where the item to be reflected is smaller than a word we
would end up triggering an ICE due to mode mismatching since the
expansion
On Tue, Dec 17, 2024 at 11:43:45AM -0500, Jason Merrill wrote:
> On 12/12/24 1:42 PM, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > This ICE started with the recent prvalue optimization (r15-6052). In
> > cp_fold_r we have:
> >
> >
On Wed, 18 Dec 2024 at 18:39, François Dumont wrote:
>
> Hi
>
> As proposed on another thread here is the patch to make std::__addressof
> and std::addressof compile time equivalent.
>
> Maybe not entirely because of the [[__nodiscard__]] on std::addressof
> but still closer.
>
> libstdc++: H
Changes since v1:
- Split tests into two parts. One part for doing asm checkes. Another part
for doing run test as these require hardware to be available.
- Changed existing tests to be "compile" instead of "run".
Changes since v2:
- Applied the same fix to memset-inline-8.c and memset-inline-
Am 18.12.24 um 19:09 schrieb Jerry D:
On 12/18/24 4:11 AM, Harald Anlauf wrote:
Hi Steve,
thanks for the draft patch.
I haven't looked close enough, but you may have to add support
for 'asis' being an optional dummy variable. The following
example crashes here with a segfault:
program foo
Hi
As proposed on another thread here is the patch to make std::__addressof
and std::addressof compile time equivalent.
Maybe not entirely because of the [[__nodiscard__]] on std::addressof
but still closer.
libstdc++: Have std::addressof use __builtin_addressof
Rather than calling
The patch reverses a fix for PR117248 because it adds new failures in
libgo test on arm (PR117999).
I'll fix PR117248 with another patch soon which will not result in PR117999.
commit 1a28ff1c01c290d50fb4ebd6e6a49482195cab9c
Author: Vladimir N. Makarov
Date: Wed Dec 18 13:28:43 2024 -0500
On Tue, 17 Dec 2024 18:04:01 + (UTC)
Joseph Myers wrote:
> I don't think we should introduce man pages as a new source format
> for documentation in GCC. Either .texi or .rst (with generated man
> pages) would be fine.
I hope you can be persuaded to accept our man pages, at least for now,
b
On 12/18/24 4:11 AM, Harald Anlauf wrote:
Hi Steve,
thanks for the draft patch.
I haven't looked close enough, but you may have to add support
for 'asis' being an optional dummy variable. The following
example crashes here with a segfault:
program foo
use iso_c_binding, only : c_null_char
Hi Kyrill,
On 17/12/2024 15:15, Kyrylo Tkachov wrote:
We avoid using the __builtin_aarch64_* builtins in test cases as they are
undocumented and we don’t make any guarantees about their stability to users.
I’d prefer if the saturating operation was open-coded in C. I expect the midend
machiner
> On 17 Dec 2024, at 18:57, Richard Biener wrote:
>
> External email: Use caution opening links or attachments
>
>
>> Am 16.12.2024 um 09:10 schrieb Jennifer Schmitz :
>>
>>
>>
>>> On 14 Dec 2024, at 09:32, Richard Biener wrote:
>>>
>>> External email: Use caution opening links or attac
Hi,
in PR116351 we try to vectorize with -march=...zve32x which does not
have 64-bit vector element sizes, don't find a proper mode and end up
using word_mode = DImode.
vect_verify_loop_lens calls get_len_load_store_mode which asserts
VECTOR_MODE_P (vecmode) so DImode will cause an ICE.
In check
Gentle ping :)
Kind regards,
Torbjörn
On 2024-11-14 17:16, Torbjorn SVENSSON wrote:
On 2024-11-14 16:32, Christophe Lyon wrote:
On Fri, 8 Nov 2024 at 19:49, Torbjörn SVENSSON
wrote:
Ok for trunk and releases/gcc-14?
--
A long time ago, this test forced -march=armv6.
With -marm, the gen
On 2024-08-27 13:49, Richard Earnshaw (lists) wrote:
On 13/08/2024 17:18, Andre Vieira (lists) wrote:
I'm not a maintainer but I'd argue the entire test is bogus.
The error reporting in this area seems to be somewhat fragile, if you compile it with
'-march=armv7-a -mfloat-abi=soft', you als
On Wed, 18 Dec 2024, Jonathan Wakely wrote:
> We don't know what state an arbitrary sequence container will be in
> after moving from it, so a moved-from std::priority_queue needs to clear
> the moved-from container to ensure it doesn't contain elements that are
> in an invalid order for the queue
Changes since v1:
- Split tests into two parts. One part for doing asm checkes. Another part
for doing run test as these require hardware to be available.
- Changed existing tests to be "compile" instead of "run".
Ok for trunk and releases/gcc-14?
--
Split tests into 2 parts:
- The first par
> Am 18.12.2024 um 14:35 schrieb Alexandre Oliva :
>
> On Dec 17, 2024, Alexandre Oliva wrote:
>
>> diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
>> index 92f02ddd77408..06913d57f8aec 100644
>> --- a/gcc/gimple-fold.cc
>> +++ b/gcc/gimple-fold.cc
>> @@ -7554,13 +7554,10 @@ decode_fiel
> Am 17.12.2024 um 14:30 schrieb Alexandre Oliva :
>
>
> ACATS-4 ca11d02 exposed an error in the logic for recognizing and
> identifying the inner object in decode_field_ref: a view-converting
> load, inserted in a previous successful field merging operation, was
> recognized by gimple_conver
On Wed, 18 Dec 2024, Jason Merrill wrote:
> On 12/17/24 10:43 AM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk? Shall we also backport this to release branches?
> > It's not a regression but seems like a safe fix for an inconvenient
>
Hi,
The attached patch temporarily reverts
e2f6ed54f75bbf8dd0292af90304890f06a9be17, until pending issues with multilib
and others get resolved.
Thanks,
Prathamesh
diff --git a/Makefile.def b/Makefile.def
index 90899fa28cf..19954e7d731 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -656,26 +656
On Tue, Dec 17, 2024 at 05:34:38PM -0500, Jason Merrill wrote:
> On 9/11/24 8:26 AM, Jakub Jelinek wrote:
> > On Wed, Sep 11, 2024 at 10:16:18PM +1000, Nathaniel Shead wrote:
> > > In the header_module_p case, it is valid to have internal linkage
> > > definitions (e.g. in an anonymous namespace),
Changes since v1:
- Updated the commit message to reflect the changes (including the subject).
- Replaced the POP/BEQ checks with chesk for {cmp,mov,orr,and}{eq,ne}.
- Removed the size check
Ok for trunk and releases/gcc-14?
Should I also push this to releases/gcc-13 and releases/gcc-12 as this
I think this counts as obvious, but I'll leave it a few days before committing
in case Andrew (or anyone else) disagrees.
gcc/ChangeLog:
* tree-assume.cc: Fix comment typos.
diff --git a/gcc/tree-assume.cc b/gcc/tree-assume.cc
index
883338bcef1e41e15a67fd015834d74319ca11af..9a934f21dc0
On 12/17/24 5:11 PM, Palmer Dabbelt wrote:
This came up on IRC this morning and we talked a bit on the patchwork
call this morning. I'm not really sure what the right answer is here,
but it seems at least reasonable to talk about -- we've got a lot more
testing these days are we've been somew
On 12/17/24 9:48 PM, Bohan Lei wrote:
Hi all!
I would like to ping the patch in
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670763.html
(Message-Id: <20241204045717.12982-1-garth...@linux.alibaba.com>).
It is supposed to be a generalization of the existing stack pointer VALUE reu
In a later patch, I need to add "@" to a pattern that uses subst
iterators. This combination is problematic for two reasons:
(1) define_substs are applied and filtered at a later stage than the
handling of "@" patterns, so that the handling of "@" patterns
doesn't know which subst variant
On Wed, 18 Dec 2024 at 14:14, Tamar Christina wrote:
>
> > e791e52ec329277474f3218d8a44cd37ded14ac3..8101d868d0c5f7ac4f97931a
> > > ffcf71d826c88094 100644
> > > > --- a/libstdc++-v3/include/bits/hashtable.h
> > > > +++ b/libstdc++-v3/include/bits/hashtable.h
> > > > @@ -2171,7 +2171,7 @@ _GLIBCXX
On Tue, Dec 17, 2024 at 05:54:36PM -0500, Jason Merrill wrote:
> On 9/5/24 3:27 AM, Jakub Jelinek wrote:
> > When adding test coverage for maybe_unused attribute, I've run into
> > several things:
> > 1) similarly to deprecated attribute, the attribute shouldn't pedantically
> > appertain to ty
On Tue, Dec 17, 2024 at 05:40:15PM -0500, Jason Merrill wrote:
> > --- gcc/cp/tree.cc.jj 2024-08-15 22:23:07.908239976 +0200
> > +++ gcc/cp/tree.cc 2024-08-30 13:15:26.863829810 +0200
> > @@ -5087,6 +5087,25 @@ handle_likeliness_attribute (tree *node,
> > return error_mark_node;
> >
> -Original Message-
> From: Tobias Burnus
> Sent: 18 December 2024 17:46
> To: Prathamesh Kulkarni ; Joseph Myers
>
> Cc: Xi Ruoyao ; Matthew Malcomson
> ; gcc-patches@gcc.gnu.org
> Subject: Re: [RFC] PR81358: Enable automatic linking of libatomic
>
> External email: Use caution openi
Ping!
please review.
Thanks & Regards
Jeevitha
On 02/12/24 2:04 pm, jeevitha wrote:
> Ping!
>
> please review.
>
> Thanks & Regards
> Jeevitha
>
> On 15/10/24 12:49 pm, jeevitha wrote:
>> Hi All,
>>
>> Removed powerpc*-*-* from the target test as it is always true. Simplified
>> options by
On 2024-12-18 14:59, Richard Earnshaw (lists) wrote:
On 17/12/2024 21:01, Torbjörn SVENSSON wrote:
Regtested for arm-none-eabi (Cortex-M0/M23/M33/M55/M85).
Ok for trunk?
--
Without the escape of the tab, newline and semicolon, the generated
assembler output will not match the expected assm
On 12/18/24 9:04 AM, Jakub Jelinek wrote:
On Tue, Dec 17, 2024 at 05:01:48PM -0500, Jason Merrill wrote:
@@ -742,6 +748,72 @@ cp_lexer_new_main (void)
module_token_lang (tok->type, tok->keyword, tok->u.value,
tok->location, filter);
+ /* Attempt to optimiz
On Tue, Dec 17, 2024 at 03:58:38PM -0500, Jason Merrill wrote:
> On 11/27/24 3:53 AM, Nathaniel Shead wrote:
> > Gentle ping for this series:
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665108.html
> >
> > Most of the patches no longer applied cleanly to trunk since the last
> > tim
> e791e52ec329277474f3218d8a44cd37ded14ac3..8101d868d0c5f7ac4f97931a
> > ffcf71d826c88094 100644
> > > --- a/libstdc++-v3/include/bits/hashtable.h
> > > +++ b/libstdc++-v3/include/bits/hashtable.h
> > > @@ -2171,7 +2171,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > > if (this->_M_equals(__k,
On Tue, Dec 17, 2024 at 05:01:48PM -0500, Jason Merrill wrote:
> > @@ -742,6 +748,72 @@ cp_lexer_new_main (void)
> > module_token_lang (tok->type, tok->keyword, tok->u.value,
> >tok->location, filter);
> > + /* Attempt to optimize long lists of 0-255 integers
> > +
On 17/12/2024 21:01, Torbjörn SVENSSON wrote:
> Regtested for arm-none-eabi (Cortex-M0/M23/M33/M55/M85).
>
> Ok for trunk?
>
> --
>
> Without the escape of the tab, newline and semicolon, the generated
> assembler output will not match the expected assmbler in the test cases.
>
> Fixes Linaro C
On 12/17/24 10:43 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
OK.
-- >8 --
Since atomic constraints are interned the subsumption machinery can
safely use pointer instead of structural hashing for them. This speeds
up compilation o
Hi,
> >
> > Hi,
> >
> > I think I managed to fix indentation from the previous version.
> >
> > When comparing the tables showing the candidates for the group 1
> > before and after applying this patch, it can be observed that
> > complexities for the candidates where the computation depends on th
On 12/17/24 10:43 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk? Shall we also backport this to release branches?
It's not a regression but seems like a safe fix for an inconvenient
issue.
OK for trunk and 14.
I wonder about using __bu
On Dec 17, 2024, Alexandre Oliva wrote:
> diff --git a/gcc/gimple-fold.cc b/gcc/gimple-fold.cc
> index 92f02ddd77408..06913d57f8aec 100644
> --- a/gcc/gimple-fold.cc
> +++ b/gcc/gimple-fold.cc
> @@ -7554,13 +7554,10 @@ decode_field_reference (tree *pexp, HOST_WIDE_INT
> *pbitsize,
> narrow
On Dec 18, 2024, Jakub Jelinek wrote:
> and the comment right above the xor_p handling says
> /* Turn (a ^ b) [!]= 0 into a [!]= b. */
> but I don't see anything that would actually check that the other operand is
> 0, in the testcase below it happily optimizes (a ^ 1) == 8 into a == 1.
> The
On Wed, Dec 18, 2024 at 01:31:15PM +0100, Tobias Burnus wrote:
> I now tried it again – with a patch-wise clean bootstrap and w/o
> --enable-offload-targets=...
> (i.e. on x86_64-gnu-linux with--enable-languages=c,c++,fortran,lto,objc,
> which enables bootstrap + m32 mulilib support).
>
> I think
I now tried it again – with a patch-wise clean bootstrap and w/o
--enable-offload-targets=...
(i.e. on x86_64-gnu-linux with--enable-languages=c,c++,fortran,lto,objc, which enables bootstrap + m32
mulilib support).
I think I saw the same error previously but when trying to see the error again,
On Dez 12 2024, Jakub Jelinek wrote:
> The intent was to test %cN because %N doesn't DTRT on various targets.
> I have a patch to add %ccN support which should then work even on riscv
> hopefully, but unfortunately it hasn't been fully reviewed yet.
That didn't change toplevel-asm-1, so the failu
A x86_64-gnu-linux bootstrap which also builds -m32 now fails.
While I have local patches, they should not affect this,
hence, I fear that it has been caused by this patch.
Namely, if I do a bootstrap into an empty directory with:
$ /configure --prefix=...
--enable-languages=c,c++,fortra
Hi Steve,
thanks for the draft patch.
I haven't looked close enough, but you may have to add support
for 'asis' being an optional dummy variable. The following
example crashes here with a segfault:
program foo
use iso_c_binding, only : c_null_char, c_char, f_c_string, c_size_t
implicit n
> -Original Message-
> From: Joseph Myers
> Sent: 04 December 2024 22:19
> To: Prathamesh Kulkarni
> Cc: Xi Ruoyao ; Matthew Malcomson
> ; gcc-patches@gcc.gnu.org
> Subject: RE: [RFC] PR81358: Enable automatic linking of libatomic
>
> External email: Use caution opening links or attac
ok
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-12-18 18:37
To: gcc-patches
CC: pal...@dabbelt.com; kito.ch...@gmail.com; juzhe.zh...@rivai.ai;
jeffreya...@gmail.com; pan2...@intel.com; rdapp@gmail.com
Subject: [PATCH] RISC-V: Expand shift count in Xmode in interleave pattern.
Hi,
c
Hi!
On Fri, Dec 06, 2024 at 05:07:40PM +0100, Jakub Jelinek wrote:
> I'd like to ping the
> https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668699.html
> patch.
>
> The patches it depended on are already committed and there is a patch
> which depends on this (the builtins shift from nonnu
On 2024-12-12 15:50, Richard Earnshaw (lists) wrote:
On 12/12/2024 13:36, Torbjorn SVENSSON wrote:
On 2024-12-12 12:26, Richard Earnshaw (lists) wrote:
On 10/11/2024 13:38, Torbjörn SVENSSON wrote:
Hi Richard,
I'm not sure if I'm doing something wrong here, or if it was an
oversight
wh
Hi,
currently ssa-dse-1.C ICEs because expand_simple_binop returns NULL
when building the scalar that is used to IOR two interleaving
sequences.
That's because we try to emit a shift in HImode. This patch shifts in
Xmode and then lowpart-subregs the result to HImode.
Regtested on rv64gcv_zvl512
> Am 18.12.2024 um 10:10 schrieb Jakub Jelinek :
>
> Hi!
>
> The function comment says:
> *XOR_P is to be FALSE if EXP might be a XOR used in a compare, in which
> case, if XOR_CMP_OP is a zero constant, it will be overridden with *PEXP,
> *XOR_P will be set to TRUE, and the left-hand o
On Wed, 2024-12-18 at 15:09 +0800, Lulu Cheng wrote:
>
> 在 2024/12/16 下午9:19, Xi Ruoyao 写道:
> > A generic CRC optimization pass has been implemented in r15-5850.
> > But
> > without target-specific code, it'll only optimize the CRC loop to a
> > table lookup. With LoongArch-specific code we can
Hi!
The function comment says:
*XOR_P is to be FALSE if EXP might be a XOR used in a compare, in which
case, if XOR_CMP_OP is a zero constant, it will be overridden with *PEXP,
*XOR_P will be set to TRUE, and the left-hand operand of the XOR will be
decoded. If *XOR_P is TRUE, XOR_CMP
On Sat, 16 Nov 2024 at 11:20, Luca Bacci wrote:
>
> This is both a performance optimization and a partial fix for
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98723.
>
> This commit fixes the issue for bracket expressions that do not
> depend on the locale's collation facet. Examples:
>
> * Cha
93 matches
Mail list logo
