* Marek Polacek:
> On Tue, Nov 14, 2023 at 06:50:58PM +0100, Florian Weimer wrote:
>> --- a/gcc/c-family/c.opt
>> +++ b/gcc/c-family/c.opt
>> @@ -591,6 +591,10 @@ Wdeclaration-after-statement
>> C ObjC Var(warn_declaration_after_statement) Init(-1) Warning
>> Warn when a declaration is found aft
On 11/14/23 10:43, Patrick Palka wrote:
On Fri, 10 Nov 2023, Jason Merrill wrote:
On 11/10/23 10:28, Patrick Palka wrote:
On Fri, 10 Nov 2023, Patrick Palka wrote:
On Thu, 9 Nov 2023, Jason Merrill wrote:
On 11/8/23 16:59, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux
On 11/14/23 16:04, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
Here we're ICEing from strip_typedefs for the partially instantiated
requires-expression when walking its REQUIRES_EXPR_EXTRA_ARGS since it's
a TREE_LIST with
Tested x86_64-linux. Pushed to trunk. Backports needed too.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/112348
* include/std/stacktrace (hash>): Fix
type of hash functio nfor entries.
* testsuite/19_diagnostics/stacktrace/hash.cc: New test.
---
libstdc++-v3/inc
On 11/14/23 11:35, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
OK.
-- >8 --
The NON_DEPENDENT_EXPR removal exposed that is_direct_enum_init may end
up checking convertibility of a type-dependent argument.
PR c++/112515
gcc/cp
On 11/14/23 11:10, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
For decltype((x)) within a lambda where x is not captured, we dubiously
require that the lambda has a capture default, unlike for decltype(x).
This patch fixes this i
Tested x86_64-linux. Pushed to trunk. Backports needed too.
-- >8 --
In we pass the int __base parameter to our internal versions
of functions, __bit_width and __countr_zero. Those functions are
only defined for unsigned types, so we need to convert the base to
unsigned. The base must be in the
On Sat, 11 Nov 2023 at 16:46, Cassio Neri wrote:
>
> When year_month_day_last::day() was implemented, Dr. Matthias Kretz realised
> that the operation "& 1" wasn't necessary but we did not patch it at that
> time. This patch removes the unnecessary operation.
>
> libstdc++-v3/ChangeLog:
>
>
On Sat, 11 Nov 2023 at 23:00, Cassio Neri wrote:
>
> The current implementation returns
> (_M_y & (__is_multiple_of_100 ? 15 : 3)) == 0;
> where __is_multiple_of_100 is calculated using an obfuscated algorithm which
> saves one ror instruction when compared to _M_y % 100 == 0 [1].
>
> In leap
On Sun, 12 Nov 2023 at 01:34, Cassio Neri wrote:
>
> The following has undefined behaviour (signed overflow) [1]:
> weekday max{sys_days{days{numeric_limits::max()}}};
>
> The issue is in this line when __n is very large and __n + 4 overflows:
> return weekday(__n >= -4 ? (__n + 4) % 7 : (
On Tue, 14 Nov 2023 at 00:27, Cassio Neri wrote:
>
> The current implementation calls __detail::__modulo which is relatively
> expensive.
>
> A better implementation is possible if we assume that x.ok() && y.ok() ==
> true,
> so that n = x.c_encoding() - y.c_encoding() is in [-6, 6]. In this case
On 11/1/23 11:07, Patrick Palka wrote:
On Tue, 31 Oct 2023, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Does it look OK for release branches as well for sake of PR111703?
-- >8 --
potential_constant_expression was incorrectly treating
Hi David,
David Edelsohn writes:
> Arsen,
>
> Unfortunately this broke bootstrap on AIX.
>
> I had not seen this series of patches.
I've added Bruno to CC as the libintl maintainer, to keep him in the
loop. Could you provide some extra information w.r.t. the failure mode?
I'll try to investig
On 11/12/23 6:08 AM, Lehua Ding wrote:
> V3 Changes:
> 1. fix three ICE.
> 2. rebase
I tested this on powerpc64le-linux and powerpc64-linux. The LE build
bootstrapped fine and it looks like only one testsuite FAIL which I have
to look into why it's FAILing.
The BE build did bootstrap, but t
On 11/13/23 11:37 PM, Lehua Ding wrote:
> On 2023/11/14 3:37, Vladimir Makarov wrote:
>> Also besides testing major targets I'd recommend testing at least one big
>> endian target (I'd recommend ppc64be. gcc110.fsfrance.org could be used
>> for this). Plenty RA issues occur because BE targets are
> > OK, but then I think the fix is to not use
> > standard_iv_increment_position (it's a weird API anyway). Instead insert
> before the main exit condition.
>
> I figured as much, Almost done respinning it with the vectorizer's own simpler
> copy.
> Should be out today with the rest.
>
> >
> >
Patch updated to latest trunk,
This splits the part of the function that does peeling for loops at exits to
a different function. In this new function we also peel for early breaks.
Peeling for early breaks works by redirecting all early break exits to a
single "early break" block and combine th
Patch updated to latest trunk:
Hi All,
This changes the PHI node updates to support early breaks.
It has to support both the case where the loop's exit matches the normal loop
exit and one where the early exit is "inverted", i.e. it's an early exit edge.
In the latter case we must always restart
Patch updated to trunk.
This adds support to vectorizable_live_reduction to handle multiple exits by
doing a search for which exit the live value should be materialized in.
Additinally which value in the index we're after depends on whether the exit
it's materialized in is an early exit or whethe
> I wouldn't try to handle that case unless we had actual evidence it was
> useful to do so. Just wanted to point out that unlike pseudos we can
> have multiple modes referencing the same memory location.
Got the point here, thanks Jeff for emphasizing this, 😉.
Pan
-Original Message-
Li, Pan2 would like to recall the message, "[PATCH v4] DSE: Allow vector type
for get_stored_val when read < store".
RV64 compare and branch instructions only support 64-bit operands.
At Expand time, the backend conservatively zero/sign extends
its operands even if not needed, such as incoming function args
which ABI/ISA guarantee to be sign-extended already (this is true for
SI, HI, QI operands)
And subsequentl
Sorry for disturbing, looks I have a typo for Richard S's email address, cc the
right email address for awareness.
Pan
-Original Message-
From: Li, Pan2
Sent: Wednesday, November 15, 2023 8:18 AM
To: Jeff Law ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang ;
kito.ch.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-5473-g2220263f0e032a.
gcc/ChangeLog:
* json.cc (selftest::assert_print_eq): Add "loc" param and use
ASSERT_STREQ_AT.
(ASSERT_PRINT_EQ): New macro.
(selftest::test_writing_objects):
Previously our JSON output emitted the JSON all on one line, with
no indentation or newlines to show the structure of the values.
Although it's easy to reformat such output (e.g. with
"python -m json.tool"), I've found it's a pain to need to do so
e.g. my text editor sometimes hangs when opening a
Passing in a base extension in non-canonical order (i, e, g) causes GCC
to ICE:
xgcc: error: '-march=rv64ge': ISA string is not in canonical order. 'e'
xgcc: internal compiler error: in add, at
common/config/riscv/riscv-common.cc:671
...
This is fixed by skipping to the next extension when a non-
On Tue, Nov 14, 2023 at 6:09 PM Arsen Arsenović wrote:
> Hi David,
>
> David Edelsohn writes:
>
> > Arsen,
> >
> > Unfortunately this broke bootstrap on AIX.
> >
> > I had not seen this series of patches.
>
> I've added Bruno to CC as the libintl maintainer, to keep him in the
> loop. Could you
LGTM, and BTW...I am thinking we could relax the canonical order
during parsing, did you have interesting and time working on that
item?
On Wed, Nov 15, 2023 at 9:35 AM Patrick O'Neill wrote:
>
> Passing in a base extension in non-canonical order (i, e, g) causes GCC
> to ICE:
> xgcc: error: '-ma
On 2023/11/14 0:43, Dimitar Dimitrov wrote:
On Sun, Nov 12, 2023 at 08:08:10PM +0800, Lehua Ding wrote:
V3 Changes:
1. fix three ICE.
2. rebase
Hi,
These patchs try to support subreg coalesce feature in
register allocation passes (ira and lra).
Hi Lehua,
V3 indeed fixes the arm-no
Hi,
This patch cleans up by_pieces_ninsns and does following things.
1. Do the length and alignment adjustment for by pieces compare when
overlap operation is enabled.
2. Remove unnecessary mov_optab checks.
Bootstrapped and tested on x86 and powerpc64-linux BE and LE with
no regressions. Is t
Hi,
This patch cleans up by_pieces_ninsns and does following things.
1. Do the length and alignment adjustment for by pieces compare when
overlap operation is enabled.
2. Remove unnecessary mov_optab checks.
Bootstrapped and tested on x86 and powerpc64-linux BE and LE with
no regressions. Is t
I propose a new attribute for C++, labelled gnu::extended. This attribute
is for asm declarations, and the attribute marks them as extended asm. This
attribute shall contain all of the features of existing extended asm, but
also have additional features, described below.
gnu::extended(OutputOperan
PCREL data accesses are only officially supported on ELFv2. We currently
incorrectly enable PCREL on all Power10 compiles in which prefix instructions
are also enabled. Rework the option override code so we only enable PCREL
for those ABIs that actually support it.
Jeevitha has confirmed this pa
Hi,
Trunk gcc supports more constants to be built via two instructions: e.g.
"li/lis; xori/xoris/rldicl/rldicr/rldic".
And then num_insns_constant should also be updated.
Function "rs6000_emit_set_long_const" is used to build complicate
constants; and "num_insns_constant_gpr" is used to compute '
Hi,
Sometimes, a complicated constant is built via 3(or more)
instructions to build. Generally speaking, it would not be
as faster as loading it from the constant pool (as a few
discussions in PR63281):
* "ld" is one instruction. If consider "address/toc"
adjust, we may count it as 2 instructio
Hi,
For constants with 16bit values, 'li or lis' can be used to generate
the value. For 34bit constant, 'pli' is ok to generate the value.
For example: 0xULL, "pli 3,1717986918; rldimi 3,3,32,0"
can be used.
Compare with previous:
https://gcc.gnu.org/pipermail/gcc-patches/2023-Oc
On 2023/11/15 7:22, Peter Bergner wrote:
On 11/12/23 6:08 AM, Lehua Ding wrote:
V3 Changes:
1. fix three ICE.
2. rebase
I tested this on powerpc64le-linux and powerpc64-linux. The LE build
bootstrapped fine and it looks like only one testsuite FAIL which I have
to look into why it's
On 11/14/23 9:12 PM, Lehua Ding wrote:
> I've applied for machine permissions on the compile farm, can you give
> me the way to compile and run tests on PPC64BE machine? I'll take a look
> at it too, thanks a lot.
That's an old system, with too old system libgmp, etc. Let me attempt a
build there
From: Pan Li
We take vec_init element int mode when generate the mask for
case 2. But actually we don't need as many bits as the element.
The extra bigger mode may introduce some unnecessary insns.
For example as below code:
typedef int64_t v16di __attribute__ ((vector_size (16 * 8)));
void __a
Could you test it v4096qi ?
Also, VLS modes need to be tested.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-11-15 11:48
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Refine the mask generation for vec_init case 2
From: Pan Li
We take vec_i
Florian Weimer writes:
> Most -Wimplicit-int warnings were unconditionally disabled for system
> headers. Only missing types for parameters in old-style function
> definitions resulted in warnings. This is inconsistent with the
> treatment of other permerrors, which are active in system heade
* Sam James:
> Florian Weimer writes:
>
>> Most -Wimplicit-int warnings were unconditionally disabled for system
>> headers. Only missing types for parameters in old-style function
>> definitions resulted in warnings. This is inconsistent with the
>> treatment of other permerrors, which are act
Florian Weimer writes:
> * Sam James:
>
>> Florian Weimer writes:
>>
>>> Most -Wimplicit-int warnings were unconditionally disabled for system
>>> headers. Only missing types for parameters in old-style function
>>> definitions resulted in warnings. This is inconsistent with the
>>> treatmen
Florian Weimer writes:
> This new series covers:
>
> -Wint-conversion
> -Wimplicit-function-declaration
> -Wimplicit-int
> -Wreturn-mismatch
> -Wincompatible-pointer-types
> -Wdeclaration-missing-parameter-type (new)
>
> There are now gcc.dg/permerror-*.c tests which track the gradu
The gdb tests of the libcc1 plugin have been failing lately. I
tracked this down to a crash trying to access an enum's underlying
type. This patch fixes the crash by setting this type.
libcc1/ChangeLog
* libcc1plugin.cc (plugin_build_enum_type): Set
ENUM_UNDERLYING_TYPE.
---
li
Hello,
sorry, in the patch I should use targetm.have_atomic instead of
TARGET_HAVE_LIBATOMIC.
---
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Following several remarks on a previous patch of _Hashtable I considered
clarifying its implementation.
libstdc++: [_Hashtable] Fix some implementation inconsistencies
Get rid of the different usages of the mutable keyword. For
_Prime_rehash_policy methods are exported from the libr
* Sam James:
> When posting v3, I guess consider CCing the aarch64 maintainers (or just
> pinging them separately)?
I already pinged them, they are likely busy with posting their patches
before stage 1 closes.
> I'm not really sure how approval of (an earlier version of) this series
> interacts
From: Juzhe-Zhong
Fixes: f0e28d8c1371 ("RISC-V: Fix failed hoist in LICM of vmv.v.x instruction")
Since above commit, we have the following failure:
FAIL: gcc.c-torture/execute/memset-3.c -O3 -g execution test
The issue was not the commit but it unravled an issue in vsetvli pass.
Here's J
LGTM. You can commit it.
Thanks.
juzhe.zh...@rivai.ai
From: Vineet Gupta
Date: 2023-11-15 14:41
To: gcc-patches
CC: Jeff Law; Robin Dapp; gnu-toolchain; Patrick O'Neill; Juzhe-Zhong; Vineet
Gupta
Subject: [PATCH] RISC-V: fix vsetvli pass testsuite failure [PR/112447]
From: Juzhe-Zhong
Fi
This patch is quite obvious patch which disallow for load/store address register
with RVV mode.
PR target/112535
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_legitimate_address_p): Disallow RVV
modes base address.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autove
Curious about the code gen impact, does it make IRA/LRA insert one more
move like (set (reg:DI) (subreg:DI (reg:V1DI 155) 0)) and then (set (mem:SI
(reg:DI)) (const_int 0))?
On Wed, Nov 15, 2023 at 3:15 PM Juzhe-Zhong wrote:
> This patch is quite obvious patch which disallow for load/store addre
Yes.
(set (reg:DI) (subreg:DI (reg:V1DI 155) 0)) become vmv.x.s
So, you will see:
vsetivli zero,1,e64,m1,ta,ma
sb zero,%lo(c)(a2)
vle64.v v1,0(a5)
lbu a5,%lo(b)(a4)
vse64.v v1,0(a3)
beq a5,zero,.L6
vmv.x.s a5,v1
sw zero,0(a5)
I think the codegen is not good. It should be using scalar load/store.
LGTM, and yeah, I agree that's a code model issue.
On Wed, Nov 15, 2023 at 3:29 PM juzhe.zh...@rivai.ai
wrote:
>
> Yes.
> (set (reg:DI) (subreg:DI (reg:V1DI 155) 0)) become vmv.x.s
>
> So, you will see:
> vsetivli zero,1,e64,m1,ta,ma
> sb zero,%lo(c)(a2)
> vle64.v v1,0(a5)
> lbu a5,%lo(b)(a4)
> v
Committed, thanks Kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Wednesday, November 15, 2023 3:36 PM
To: juzhe.zh...@rivai.ai
Cc: Kito.cheng ; gcc-patches ;
jeffreyalaw ; Robin Dapp
Subject: Re: Re: [PATCH] RISC-V: Disallow RVV mode address for any
load/store[PR112535]
LGTM, a
On Tue, Nov 14, 2023 at 09:47:31PM -0700, Jeff Law wrote:
> > c++: Implement C++26 P1854R4 - Making non-encodable string literals
> > ill-formed [PR110341]
> > This paper voted in as DR makes some multi-character literals
> > ill-formed.
> > 'abcd' stays valid, but e.g. 'á' is newly i
101 - 156 of 156 matches
Mail list logo
