On Wed, Jun 7, 2023 at 8:32 AM Uros Bizjak wrote:
>
> On Wed, Jun 7, 2023 at 1:05 AM Roger Sayle wrote:
> >
> >
> > This patch addresses the last remaining issue with PR target/31985, that
> > GCC could make better use of memory addressing modes when implementing
> > double word addition. This i
On Tue, Jun 06, 2023 at 05:17:05PM -0700, Andrew Pinski via Gcc-patches wrote:
> While working on `bool0 ? bool1 : bool2` I noticed that
> zero_one_valued_p does not match on the constant zero
> as in that case tree_nonzero_bits will return 0 and
> that is different from 1.
>
> OK? Bootstrapped an
Hi!
On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote:
> On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge
> wrote:
>> This issue comes up in context of me working on C++ support for GCN and
>> nvptx target. Those targets shall default to '-fno-exceptions' -- or,
>> "in other words", '-fexceptions'
Hi Tobias,
We are also seeing this failure on arm-linux-gnueabihf.
It seems the problem is different order of variables in output:
- c a e d b
versus expected
- c a e b d
This is tree-dump output on arm-linux-gnueabihf:
#pragma omp target update to(c [len: 4]) to(present:a [len: 4000]) to(
On 2023/6/7 11:36, Lulu Cheng wrote:
在 2023/6/7 上午11:26, WANG Xuerui 写道:
Hi,
On 2023/6/7 10:31, Lulu Cheng wrote:
If the $ra register is modified during the jump to the jump table,
the hardware
branch prediction function will be broken, resulting in a significant
increase
in the branch fals
On Mon, 5 Jun 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Co-authored-by: Richard Sandiford
>
> This patch address comments from Richard and rebase to trunk.
>
> This patch is adding SELECT_VL middle-end support
> allow target have target dependent optimization in case of
> leng
During the regression testing of the LoongArch architecture GCC, it was
found that the tests in the pr90883.C file failed. The problem was modulated and
found that the error was caused by setting the macro LARCH_CALL_RATIO to a too
large value. Combined with the actual LoongArch architectur
在 2023/6/7 下午3:37, WANG Xuerui 写道:
On 2023/6/7 11:36, Lulu Cheng wrote:
在 2023/6/7 上午11:26, WANG Xuerui 写道:
Hi,
On 2023/6/7 10:31, Lulu Cheng wrote:
If the $ra register is modified during the jump to the jump table,
the hardware
branch prediction function will be broken, resulting in a
si
Hi, Richi.
Thanks for review.
>> At least for VMAT_GATHER_SCATTER you wouldn't execute this function
>> but get into
>>This function belongs to tree-vect-data-refs.cc alongside the
>>other vect_create_data_ref_* functions.
I want to support data reference pointer adjusted by outcome of SELECT_VL.
From: Pan Li
This patch would like to refactor the requirement of both the ZVFH
and ZVFHMIN. The related define_insn and iterator will take the
requirement based on the ZVFHMIN and ZVFH.
Please note the ZVFH will cover the ZVFHMIN instructions. This patch
add one test for this.
Signed-off-by: P
On Wed, 7 Jun 2023 at 05:43, François Dumont wrote:
>
> On 06/06/2023 17:59, Jonathan Wakely via Libstdc++ wrote:
> > Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
> >
> > -- >8 --
> >
> > Add the recently added CXXABI_1.3.15 version. Also remove two "frozen"
> > versions from the la
Minor change in PATCH V5, please help to turn to V5 as below, sorry for
inconvenient.
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620890.html
Pan
From: Li, Pan2
Sent: Wednesday, June 7, 2023 2:57 PM
To: 'juzhe.zh...@rivai.ai' ; 'gcc-patches'
Cc: 'Kito.cheng' ; Wang, Yanzhang
Subject
I am not sure for load/stores of FP16 vector should be gated by ZVFHMIN or ZVFH?
Since IMHO, load/stores of FP16 is no different from load/stores of INT16?
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-06-07 16:06
To: gcc-patches
CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang
On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge wrote:
> Hi!
>
> On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote:
> > On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge
> > wrote:
> >> This issue comes up in context of me working on C++ support for GCN and
> >> nvptx target. Those targets shall defau
Several tests are timing out when targeting x86-*-vxworks with qemu.
Bump their timeout factor.
for gcc/testsuite/ChangeLog
* gcc.dg/vect/tsvc/vect-tsvc-s116.c: Bump timeout factor.
* gcc.dg/vect/tsvc/vect-tsvc-s241.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s254.c: Li
Hi,
This patch tries to optimize "(X - N * M) / N" to "X / N - M".
For C code, "/" towards zero (trunc_div), and "X - N * M" maybe
wrap/overflow/underflow. So, it is valid that "X - N * M" does
not cross zero and does not wrap/overflow/underflow.
Compare with previous version:
https://gcc.gnu.org
In this patch, you add TARGET_ZVFH into VF iterator which is not correct.
When TARGET_ZVFH is true, TARGET_ZVFHMIN is always true.
For vfadd, it is true we should enable "vfadd" for TARGET_ZVFH
For vle16, we should enable for TARGET_ZVFHMIN.
This patch will disable both "vle16" and "vfadd" for F
Ping #2 for:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618976.html
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20230519/9536bf8c/attachment-0001.bin
Ping #1:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620098.html
Johann
Am 19.05.23 um 10:49 schrieb Georg-Johann Lay:
This patch improves bit-extractions on AVR.
Andrew added some patches so that more bit extractions are
recognized in the middle-end and rtl optimizers.
The patch adds pattern for "extzv" and replaces the
deprecated "extzv".
There are still situations where expensive shifts are passed
down to th
Thanks Jakub!
I do need those includes and sorry I broke your bootstrap it didn't show
up on my aarch64-unknown-linux-gnu bootstrap, I'm guessing the rules
there were just run in a different order. Glad you were able to fix it :)
On 06/06/2023 22:28, Jakub Jelinek wrote:
Hi!
internal-fn.h s
Thanks Juzhe for reviewing. I see, this way may have even smaller code change
which treats the zvfhmin as minimal base sub extension.
I will have a try for PATCH V6.
Pan
From: juzhe.zh...@rivai.ai
Sent: Wednesday, June 7, 2023 4:27 PM
To: Li, Pan2 ; gcc-patches
Cc: Robin Dapp ; jeffreyalaw ; L
Hi!
On 2023-06-07T09:12:31+0100, Jonathan Wakely wrote:
> On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge wrote:
>> On 2023-06-06T20:31:21+0100, Jonathan Wakely wrote:
>> > On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge
>> > wrote:
>> >> This issue comes up in context of me working on C++ support fo
Hi,
on 2023/6/7 03:54, Carl Love wrote:
> On Mon, 2023-06-05 at 16:45 +0800, Kewen.Lin wrote:
>> Hi Carl,
>>
>> on 2023/5/2 23:52, Carl Love via Gcc-patches wrote:
>>> GCC maintainers:
>>>
>>> The following patch adds three buitins for inserting and extracting
>>> the
>>> exponent and significand
On 5/29/23 16:51, Martin Jambor wrote:
Hi,
On Mon, May 22 2023, Aldy Hernandez via Gcc-patches wrote:
Implement hashing for ipa_vr. When all is said and done, all these
patches incurr a 7.64% slowdown for ipa-cp, with is entirely covered by
the similar 7% increase in this area last week. S
Seems there are some indent format problems in the patch, could you fix them :)
```
patch:509: indent with spaces.
x_save_size = riscv_stack_align (num_multi_push * UNITS_PER_WORD);
error: patch failed: gcc/config/riscv/riscv.cc:5652
error: gcc/config/riscv/riscv.cc: patch does not apply
On 5/26/23 18:17, Martin Jambor wrote:
Hello,
On Mon, May 22 2023, Aldy Hernandez wrote:
I've adjusted the patch with some minor cleanups that came up when I
implemented the rest of the IPA revamp.
Rested. OK?
On Wed, May 17, 2023 at 4:31 PM Aldy Hernandez wrote:
This converts the latti
I saw this while working on something else:
pex_unix_cleanup signature doesn't always match the
body of the function in terms of ATTRIBUTE_UNUSED.
If the conditional code in the body is compiled, then
ATTRIBUTE_UNUSED isn't correct.
This change makes it always match, thereby making it
a bit clean
Hello All:
This patch provide functionality to improve ree pass for rs6000 target.
Eliminated sign_extend/zero_extend/AND with varying constants.
Bootstrapped and regtested on powerpc64-linux-gnu.
Thanks & Regards
Ajit
ree: Improve ree pass for rs6000 target
For rs6000 target we see redundant
I see what you mean now, so I've made adjustment in order for testcase to work
on assembly. Following is the updated patch.
Regards,
Jovan
>From 2744357b5232c61bf1f780c4915d47b19d71f993 Mon Sep 17 00:00:00 2001
From: Jovan Dmitrovic
Date: Fri, 19 May 2023 12:36:55 +0200
Subject: [PATCH] mips: Fi
Hi, Richi. Since SELECT_VL only apply on single-rgroup (ncopies == 1 && vec_num
== 1)
Should I make SELECT_VL stuff out side the loop?
for (i = 0; i < vec_num; i++)
for (j = 0; j < ncopies; j++)
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-06-07 15:41
To: Ju-Zhe Zhong
On Wed, 7 Jun 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi. Since SELECT_VL only apply on single-rgroup (ncopies == 1 &&
> vec_num == 1)
> Should I make SELECT_VL stuff out side the loop?
>
> for (i = 0; i < vec_num; i++)
> for (j = 0; j < ncopies; j++)
>
No, but please put assertions i
This patch fixes a corner case issue (missing list items in a map clause)
and ensures that such an issue is caught.
Committed to mainline as https://gcc.gnu.org/r14-1605-gdd958667821e38
It is a forward port of Thomas' OG12 then OG13 commit which fixed
a run-time issue which the mainline version
This patch fixes a corner case issue (missing list items in a map clause)
and ensures that such an issue is caught.
Committed to mainline as https://gcc.gnu.org/r14-1605-gdd958667821e38
It is a forward port of Thomas' OG12 then OG13 commit which fixed
a run-time issue which the mainline version
On Tue, Jun 6, 2023 at 8:37 PM David Malcolm wrote:
>
> On Tue, 2023-06-06 at 18:05 +0200, Benjamin Priour wrote:
[...]
> [Looks like you droppped the mailing list from the recipients; was that
> intentional?]
>
Not at all, just me missing the reply all button.
> >
> > I indeed bootstrapped an
On Wed, 7 Jun 2023 at 10:08, Thomas Schwinge
wrote:
> Hi!
>
> On 2023-06-07T09:12:31+0100, Jonathan Wakely wrote:
> > On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge wrote:
> >> On 2023-06-06T20:31:21+0100, Jonathan Wakely
> wrote:
> >> > On Tue, 6 Jun 2023 at 20:14, Thomas Schwinge >
> >> > wrot
From: Ju-Zhe Zhong
Co-authored-by: Richard Sandiford
Co-authored-by: Richard Biener
This patch address comments from Richard && Richi and rebase to trunk.
This patch is adding SELECT_VL middle-end support
allow target have target dependent optimization in case of
length calculation.
This patc
Hi, Richi. I have fixed data reference pointer part following your comments
Could you take a look at it ?
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620916.html
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-06-07 19:04
To: juzhe.zh...@rivai.ai
CC: gcc-patches; richard.
This patch is the minimal support for ZC* extensions, include the extension
name, mask and target defination. Also define the dependencies with Zca
and Zce extension. Notes that all ZC* extensions depend on the Zca extension.
Zce includes all relevant ZC* extensions for microcontrollers using. Zce
RISC-V Code Size Reduction(ZC*) extensions is a group of extensions
which define subsets of the existing C extension (Zca, Zcd, Zcf) and new
extensions(Zcb, Zcmp, Zcmt) which only contain 16-bit encodings.[1]
The implementation of the RISC-V Code Size Reduction extension in GCC is
an important st
This patch enables the compressible features with ZC* extensions.
Since all ZC* extension depends on the Zca extension, it's sufficient to only
add the target Zca to extend the target RVC.
Co-Authored by: Mary Bennett
Co-Authored by: Nandni Jamnadas
Co-Authored by: Simon Cook
gcc/ChangeLog:
Add ZC* extensions march args tests for error input cases.
Co-Authored by: Nandni Jamnadas
Co-Authored by: Jiawei
Co-Authored by: Mary Bennett
Co-Authored by: Simon Cook
gcc/testsuite/ChangeLog:
* gcc.target/riscv/arch-22.c: New test.
* gcc.target/riscv/arch-23.c: New test.
On 6/7/23 04:21, Costas Argyris via Gcc-patches wrote:
I saw this while working on something else:
pex_unix_cleanup signature doesn't always match the
body of the function in terms of ATTRIBUTE_UNUSED.
If the conditional code in the body is compiled, then
ATTRIBUTE_UNUSED isn't correct.
This
On 6/7/23 01:12, Jakub Jelinek via Gcc-patches wrote:
+/* zero_one_valued_p will match when a value is known to be either
+ 0 or 1 including the constant 0. */
(match zero_one_valued_p
@0
(if (INTEGRAL_TYPE_P (type) && tree_nonzero_bits (@0) == 1)))
So perhaps instead change th
Oh OK, thanks for the clarification.
Costas
On Wed, 7 Jun 2023 at 13:59, Jeff Law wrote:
>
>
> On 6/7/23 04:21, Costas Argyris via Gcc-patches wrote:
> > I saw this while working on something else:
> >
> > pex_unix_cleanup signature doesn't always match the
> > body of the function in terms of
gcc/ChangeLog:
* config/riscv/riscv-cores.def: Add veyron-v1
core and tune info.
* config/riscv/riscv-opts.h
(riscv_microarchitecture_type): Add veyron-v1.
* config/riscv/riscv.cc (veyron_v1_tune_info): New.
* config/riscv/riscv.md: Include veyron-v1
Hi,
This patch series fixes various defects with the FEAT_LS64 ACLE
implementation in the AArch64 backend.
The series is organised as follows:
- Patch 1/3 fixes whitespace errors in the existing code.
- Patch 2/3 fixes PR110100 where we generate wrong code for the st64b
builtin.
- Patch 3/
The st64b pattern incorrectly had an output constraint on the register
operand containing the destination address for the store, leading to
wrong code. This patch fixes that.
gcc/ChangeLog:
PR target/110100
* config/aarch64/aarch64-builtins.cc (aarch64_expand_builtin_ls64):
This patch refactors the ls64 builtins to allow the compiler to define them
directly instead of having wrapper functions in arm_acle.h. This should be not
only easier to maintain, but it makes two important correctness fixes:
- It fixes PR110132, where the builtins ended up getting declared with
On Sun, Jun 4, 2023 at 10:43 AM Jeff Law via Gcc-patches
wrote:
>
> With Vlad's recent LRA fix to the elimination code, the H8 can be
> converted to LRA.
Could you update the h8300 entry on https://gcc.gnu.org/backends.html
for this change?
Thanks,
Andrew
>
> This patch has two changes of note.
I would like vendor cpu name start with vendor name, like ventana-veyron-v1
which is consistent with all other vendor cpu, and llvm are using same
convention too.
Raphael Moreira Zinsly 於 2023年6月7日 週三，21:18寫道：
> gcc/ChangeLog:
>
> * config/riscv/riscv-cores.def: Add veyron-v1
> co
Hi,
This patch fixes an issue introduced by
g:2f482a07365d9f4a94a56edd13b7f01b8f78b5a0, where a subtype was beeing
passed to vect_widened_op_tree, when no subtype was to be used. This
lead to an errorneous use of IFN_VEC_WIDEN_MINUS.
gcc/ChangeLog:
* tree-vect-patterns.cc (vect_reco
On Tue, Jun 6, 2023 at 11:53 AM Florian Weimer via Gcc-patches
wrote:
>
> The eh_frame value is only used by linear_search_fdes, not the binary
> search directly in find_fde_tail, so the bug is not immediately
> apparent with most programs.
>
> Fixes commit e724b0480bfa5ec04f39be8c7290330b495c59de
Thanks Jiawei, v2 patch set are LGTM, but I would like to defer this until
binutils part has merged, I know you guys already implement that for a
while, so I think it’s almost there :)
Jiawei 於 2023年6月7日 週三，20:57寫道：
> RISC-V Code Size Reduction(ZC*) extensions is a group of extensions
> which def
> Date: Tue, 6 Jun 2023 16:30:12 +0100
> From: Jonathan Wakely via Gcc-patches
> On Thu, 1 Jun 2023 at 16:59, Jonathan Wakely via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
> > Tested x86_64-linux. I'd appreciate a second set of eyeballs on this
> > before I push it.
> >
>
> Pushed to trunk
On 6/7/23 08:13, Kito Cheng wrote:
I would like vendor cpu name start with vendor name, like
ventana-veyron-v1 which is consistent with all other vendor cpu, and
llvm are using same convention too.
Fair enough. Better to get it right now than have this stuff be
inconsistent. It'll be a lit
Recent changes in the hoisting code change the optimized gimple for the
shadd-3 testcase on the PA. That in turn changes the number of expected
shadd instructions.
I'm not entirely sure the test is actually testing what we want anymore
since I don't see a CSE for postreload to discover. But
Hi!
On 2020-11-03T16:56:48-0700, Martin Sebor via Gcc-patches
wrote:
> Attached is a simple middle end implementation of detection of
> mismatched pairs of calls to C++ new and delete, along with
> a substantially enhanced implementation of -Wfree-nonheap-object.
This eventually became commit d
On Wed, 7 Jun 2023 at 15:42, Hans-Peter Nilsson wrote:
> > Date: Tue, 6 Jun 2023 16:30:12 +0100
> > From: Jonathan Wakely via Gcc-patches
>
> > On Thu, 1 Jun 2023 at 16:59, Jonathan Wakely via Libstdc++ <
> > libstd...@gcc.gnu.org> wrote:
> >
> > > Tested x86_64-linux. I'd appreciate a second se
On Wed, 7 Jun 2023 at 15:54, Jonathan Wakely wrote:
>
>
> On Wed, 7 Jun 2023 at 15:42, Hans-Peter Nilsson wrote:
>
>> > Date: Tue, 6 Jun 2023 16:30:12 +0100
>> > From: Jonathan Wakely via Gcc-patches
>>
>> > On Thu, 1 Jun 2023 at 16:59, Jonathan Wakely via Libstdc++ <
>> > libstd...@gcc.gnu.org
Hi!
On 2020-12-08T13:46:32-0700, Martin Sebor via Gcc-patches
wrote:
> The attached changes [...]
... eventually became commit fe7f75cf16783589eedbab597e6d0b8d35d7e470
"Correct/improve maybe_emit_free_warning (PR middle-end/98166, PR c++/57111, PR
middle-end/98160)".
> * c-c++-common/Wf
On Jun 07 2023, Jonathan Wakely via Gcc-patches wrote:
> Let's just revert it then. The manual says we should use AS_IF, but what we
> had previously was working well enough. I'll figure out what happened here
> later.
I think AS_IF is doing its job here: moving the expansion of
AC_REQUIRE'd macr
Hi all,
Similar to the ADDLP instructions the non-widening ADDP ones can be
represented by adding the odd lanes with the even lanes of a vector.
These instructions take two vector inputs and the architecture spec
describes the operation as concatenating them together before going
through it with p
Hi all,
This patch removes UNSPEC_SQXTUN and uses organic RTL codes to represent the
operation.
SQXTUN is an odd one. It's described in the architecture as "Signed saturating
extract Unsigned Narrow".
It's not a straightforward ss_truncate nor a us_truncate.
It is a sort of truncating signed cla
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
The patch was successfully bootstrapped and tested on x86-64, aarcha64,
and ppc64le.
Hi Di,
The compile options I use are: "-march=native -Ofast -funroll-loops -flto"
I re-ran 503, 507, and 527 on two neoverse-n1 machines, and found that one
machine fluctuated greatly, and the score was only 70% of the other machine. I
also couldn't reproduce the gain on the stable machine. For
On Wed, 2023-06-07 at 13:38 +0200, Benjamin Priour wrote:
> On Tue, Jun 6, 2023 at 8:37 PM David Malcolm
> wrote:
> >
> > On Tue, 2023-06-06 at 18:05 +0200, Benjamin Priour wrote:
>
> [...]
>
> > [Looks like you droppped the mailing list from the recipients; was
> > that
> > intentional?]
> >
Alex Coplan writes:
> Hi,
>
> This patch series fixes various defects with the FEAT_LS64 ACLE
> implementation in the AArch64 backend.
>
> The series is organised as follows:
>
> - Patch 1/3 fixes whitespace errors in the existing code.
> - Patch 2/3 fixes PR110100 where we generate wrong code f
Tested x86_64-linux (-m32/-m64) and powerpc64le-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/20_util/duration/cons/2.cc: Use values that aren't
affected by rounding.
* testsuite/20_util/from_chars/5.cc: Cast arithmetic result to
double befo
Tested x86_64-linux (-m32/-m64) and powerpc64le-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/18_support/nested_exception/rethrow_if_nested-term.cc:
Require effective target exceptions_enabled instead of using
dg-skip-if.
* testsuite/23_cont
Tested x86_64-linux (-m32/-m64) and powerpc64le-linux. Pushed to trunk.
-- >8 --
In r14-1583-g192665feef7129 I meant to add CXXABI_1.3.15 but instead I
replaced CXXABI_1.3.14 with it. This restores the CXXABI_1.3.14 version.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_abi.cc (che
On Wed, 7 Jun 2023 at 09:06, Jonathan Wakely wrote:
> On Wed, 7 Jun 2023 at 05:43, François Dumont wrote:
>
>>
>> On 06/06/2023 17:59, Jonathan Wakely via Libstdc++ wrote:
>> > Tested x86_64-linux and powerpc64le-linux. Pushed to trunk.
>> >
>> > -- >8 --
>> >
>> > Add the recently added CXXABI_1
On Wed, 7 Jun 2023 at 12:51, Jonathan Wakely wrote:
>
>
> On Wed, 7 Jun 2023 at 10:08, Thomas Schwinge
> wrote:
>
>> Hi!
>>
>> On 2023-06-07T09:12:31+0100, Jonathan Wakely wrote:
>> > On Wed, 7 Jun 2023 at 08:13, Thomas Schwinge wrote:
>> >> On 2023-06-06T20:31:21+0100, Jonathan Wakely
>> wrot
On Wed, 7 Jun 2023 at 16:19, Andreas Schwab wrote:
> On Jun 07 2023, Jonathan Wakely via Gcc-patches wrote:
>
> > Let's just revert it then. The manual says we should use AS_IF, but what
> we
> > had previously was working well enough. I'll figure out what happened
> here
> > later.
>
> I think AS
"Andre Vieira (lists)" writes:
> Hi,
>
> This patch fixes an issue introduced by
> g:2f482a07365d9f4a94a56edd13b7f01b8f78b5a0, where a subtype was beeing
> passed to vect_widened_op_tree, when no subtype was to be used. This
> lead to an errorneous use of IFN_VEC_WIDEN_MINUS.
>
> gcc/ChangeLog:
Hi All,
Three more fixes for PR87477. Please note that PR99350 was a blocker
but, as pointed out in comment #5 of the PR, this has nothing to do
with the associate construct.
All three fixes are straight forward and the .diff + ChangeLog suffice
to explain them. 'rankguessed' was made redundant b
On 6/7/23 09:35, Vladimir Makarov via Gcc-patches wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
The patch was successfully bootstrapped and tested on x86-64, aarcha64,
and ppc64le.
-ENOPATCH
On 6/7/23 12:20, Jeff Law wrote:
On 6/7/23 09:35, Vladimir Makarov via Gcc-patches wrote:
The following patch fixes
-ENOPATCH
Sorry, here is the patch.
commit 08ca31fb27841cb7f3bff7086be6f139136be1a7
Author: Vladimir N. Makarov
Date: Wed Jun 7 09:51:54 2023 -0400
RA: Constrain c
Hi!
I'm getting
+FAIL: gcc.target/i386/3dnow-1.c (internal compiler error: Segmentation fault
signal terminated program cc1)
+FAIL: gcc.target/i386/3dnow-1.c (test for excess errors)
+FAIL: gcc.target/i386/3dnow-2.c (internal compiler error: Segmentation fault
signal terminated program cc1)
+FAI
Hi!
We have expand_doubleword_clz for a couple of years, where we emit
double-word CLZ as if (high_word == 0) return CLZ (low_word) + word_size;
else return CLZ (high_word);
We can do something similar for CTZ and FFS IMHO, just with the 2
words swapped. So if (low_word == 0) return CTZ (high_wor
On Jun 7, 2023, at 1:12 AM, Alexandre Oliva wrote:
>
> Several tests are timing out when targeting x86-*-vxworks with qemu.
>
> Bump their timeout factor.
Ok. I think these are obvious to people that have to work with simulators and
the testsuite so if you want to self approve you can.
On Jun 7, 2023, at 7:54 AM, Thomas Schwinge wrote:
>
> On 2020-11-03T16:56:48-0700, Martin Sebor via Gcc-patches
> wrote:
>> Attached is a simple middle end implementation of detection of
>> mismatched pairs of calls to C++ new and delete, along with
>> a substantially enhanced implementation o
On Jun 7, 2023, at 8:01 AM, Thomas Schwinge wrote:
> On 2020-12-08T13:46:32-0700, Martin Sebor via Gcc-patches
> wrote:
>> The attached changes [...]
>
> ... eventually became commit fe7f75cf16783589eedbab597e6d0b8d35d7e470
> "Correct/improve maybe_emit_free_warning (PR middle-end/98166, PR c++
Hi!
This test apparently contains 3 problematic floating point constants,
1e126, 4.91e-6 and 5.547e-6. These constants suffer from double rounding
when -fexcess-precision=standard evaluates double constants in the precision
of Intel extended 80-bit long double.
As written in the PR, e.g. the firs
On Wed, 7 Jun 2023, 18:17 Jakub Jelinek via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> Hi!
>
> This test apparently contains 3 problematic floating point constants,
> 1e126, 4.91e-6 and 5.547e-6. These constants suffer from double rounding
> when -fexcess-precision=standard evaluates double con
Hi FX,
On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
Hi,
I cannot see if there is proper support for kind=17 in your patch;
at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
seem to have any related code.
Can real(kind=17) ever be an IEEE mode? If so, something seriously w
Hi Paul!
On 6/7/23 18:10, Paul Richard Thomas via Gcc-patches wrote:
Hi All,
Three more fixes for PR87477. Please note that PR99350 was a blocker
but, as pointed out in comment #5 of the PR, this has nothing to do
with the associate construct.
All three fixes are straight forward and the .diff
On Wed, Jun 07, 2023 at 08:31:35PM +0200, Harald Anlauf via Fortran wrote:
> Hi FX,
>
> On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
> > Hi,
> >
> > > I cannot see if there is proper support for kind=17 in your patch;
> > > at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
> >
On Tue, Jun 06, 2023 at 08:38:14PM -0600, Jeff Law wrote:
>
>
> > Regression tested for riscv32-none-elf. No changes in gcc.sum and
> > g++.sum. I don't have setup to test riscv64.
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv.cc (riscv_print_operand): Calculate
> > memmodel only
Andrew Stubbs writes:
> On 30/05/2023 07:26, Richard Biener wrote:
>> On Fri, May 26, 2023 at 4:35 PM Andrew Stubbs wrote:
>>>
>>> Hi all,
>>>
>>> I want to implement a vector DIVMOD libfunc for amdgcn, but I can't just
>>> do it because the GCC middle-end models DIVMOD's return value as
>>> "com
Hi, Joseph,
A question here: can an identifier in C be a wide char string?
Qing
> On May 26, 2023, at 2:15 PM, Joseph Myers wrote:
>
> On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote:
>
>>> What if the string is a wide string? I don't expect that to work (either
>>> as a matter of in
On Wed, 7 Jun 2023 at 18:26, Jonathan Wakely wrote:
>
>
> On Wed, 7 Jun 2023, 18:17 Jakub Jelinek via Libstdc++, <
> libstd...@gcc.gnu.org> wrote:
>
>> Hi!
>>
>> This test apparently contains 3 problematic floating point constants,
>> 1e126, 4.91e-6 and 5.547e-6. These constants suffer from doub
On 5/24/23 17:14, Jivan Hakobyan via Gcc-patches wrote:
Subject:
[RFC] RISC-V: Eliminate extension after for *w instructions
From:
Jivan Hakobyan via Gcc-patches
Date:
5/24/23, 17:14
To:
gcc-patches@gcc.gnu.org
`This patch tries to prevent generating unnecessary sign extension
after *w inst
On 6/7/23 13:15, Dimitar Dimitrov wrote:
On Tue, Jun 06, 2023 at 08:38:14PM -0600, Jeff Law wrote:
Regression tested for riscv32-none-elf. No changes in gcc.sum and
g++.sum. I don't have setup to test riscv64.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_print_operand): Calcula
On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
> Hi, Joseph,
>
> A question here: can an identifier in C be a wide char string?
Identifiers and strings are different kinds of tokens; an identifier can't
be a string of any kind, wide or narrow. It just so happens that the
proposed inte
On 6/6/23 14:29, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
In the second testcase of PR110122, during regeneration of the generic
lambda with V=Bar{}, substitution followed by coerce_template_parms for
A's template argument nat
On 6/7/23 08:43, Jeff Law wrote:
On 6/7/23 08:13, Kito Cheng wrote:
I would like vendor cpu name start with vendor name, like
ventana-veyron-v1 which is consistent with all other vendor cpu, and
llvm are using same convention too.
Fair enough. Better to get it right now than have this stu
On 6/7/23 08:06, Andrew Pinski wrote:
On Sun, Jun 4, 2023 at 10:43 AM Jeff Law via Gcc-patches
wrote:
With Vlad's recent LRA fix to the elimination code, the H8 can be
converted to LRA.
Could you update the h8300 entry on https://gcc.gnu.org/backends.html
for this change?
Thanks for the r
The patterns match more than just `a & 1` so change the comment
for these two patterns to say that.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
gcc/ChangeLog:
* match.pd: Fix comment for the
`(zero_one ==/!= 0) ? y : z y` patterns.
---
gcc/match.pd | 4 ++--
> On Jun 7, 2023, at 4:53 PM, Joseph Myers wrote:
>
> On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>> Hi, Joseph,
>>
>> A question here: can an identifier in C be a wide char string?
>
> Identifiers and strings are different kinds of tokens; an identifier can't
> be a string of
This allows unsigned types if the inner type where the negation is
located has greater than or equal to precision than the outer type.
branchless-cond.c needs to be updated since now we change it to
use a multiply rather than still having (-a)&c in there.
OK? Bootstrapped and tested on x86_64-lin
1 - 100 of 136 matches
Mail list logo
