Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Tuesday, September 26, 2023 11:18 AM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v1] RISC-V: Rename rounding const fp function for refactor
LGTM.
LGTM.
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-09-26 11:12
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Rename rounding const fp function for refactor
From: Pan Li
The rounding related API shared one const, rename it to avoid
From: Pan Li
The rounding related API shared one const, rename it to avoid
unnecessary redundant code.
gcc/ChangeLog:
* config/riscv/riscv-v.cc (gen_ceil_const_fp): Remove.
(get_fp_rounding_coefficient): Rename.
(gen_floor_const_fp): Remove.
(expand_vec_ceil):
Hi Andrew,
Thanks for your explain! And sorry for later reply.
Andrew MacLeod writes:
> On 9/14/23 22:07, Jiufu Guo wrote:
>>>
>>> undefined is a perfectly acceptable range. It can be used to
>>> represent either values which has not been initialized, or more
>>> frequently it identifies
+static rtx
+gen_nearbyint_const_fp (machine_mode inner_mode)
+{
+ /* The nearbyint needs the same floating point const as ceil. */
+ return gen_ceil_const_fp (inner_mode);
+}
This is redundant.
Also, this is also redundant:
static rtx
gen_floor_const_fp (machine_mode inner_mode)
{
/* The
Hi,
Gentle ping...
BR,
Jeff (Jiufu Guo)
Jiufu Guo via Gcc-patches writes:
> Hi,
>
> Gentle ping...
>
> BR,
> Jeff (Jiufu Guo)
>
> Jiufu Guo writes:
>
>> Hi,
>>
>> If a constant is possible to be rotated to/from a positive or negative
>> value which "li" can generated, then "li;rotldi" can be
When doing fortran test with 'V' extension enabled on RISC-V port.
I saw multiple ICE: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111590
The root cause is on DSE:
internal compiler error: in smallest_mode_for_size, at stor-layout.cc:356
0x1918f70 smallest_mode_for_size(poly_int<2u, unsigned
From: Pan Li
This patch would like to support auto-vectorization for the
nearbyint API in math.h. It depends on the -ffast-math option.
When we would like to call nearbyint/nearbyintf like v2 = nearbyint (v1),
we will convert it into below insns (reference the implementation of llvm).
*
> Yes, but I'll warn you that grokdeclarator has resisted refactoring for
> a long time...
That will certainly be what I work on after this is squared off then,
I've been up and down grokdeclarator so I'm confident I'll be able to
do it.
As for the patch, I sure took my sweet time with it, but
Hi Ramana,
>> __sync_val_compare_and_swap may be used on 128-bit types and either calls the
>> outline atomic code or uses an inline loop. On AArch64 LDXP is only atomic
>> if
>> the value is stored successfully using STXP, but the current implementations
>> do not perform the store if the
On Mon, 25 Sep 2023, Tobias Burnus wrote:
> The 'description' words looked a bit misplaced when reading the full
> sentence. Likewise "the libnuma" - I changed that to simply "libnuma".
> (Alternatives would be "the libnuma library" or "the numa library".)
>
> Hence, I fixed my own wording :-)
On Mon, 25 Sep 2023, Maciej W. Rozycki wrote:
> NB the use of this specific header, still in place elsewhere,
> seems gratuitous to me. We don't need or indeed want to print anything in
> the test cases (unless verifying something specific to the print facility)
> and if we want to avoid
On Mon, Sep 25, 2023 at 1:04 PM Andrew Pinski wrote:
>
> On Mon, Sep 25, 2023 at 12:59 PM Philipp Tomsich
> wrote:
> >
> > On Mon, 25 Sept 2023 at 21:54, Andrew Pinski wrote:
> > >
> > > On Mon, Sep 25, 2023 at 12:50 PM Manos Anagnostakis
> > > wrote:
> > > >
> > > > This patch implements the
On Wed, Sep 13, 2023 at 3:55 PM Wilco Dijkstra via Gcc-patches
wrote:
>
>
> __sync_val_compare_and_swap may be used on 128-bit types and either calls the
> outline atomic code or uses an inline loop. On AArch64 LDXP is only atomic if
> the value is stored successfully using STXP, but the current
On Sun, 24 Sep 2023, Vineet Gupta wrote:
> This fix is great but is there a more general solution to the problem when we
> toolchain is built for say just rv64 (and thus only those headers) vs. test
> building for say rv32 (and failing to build due to lack of headers) or
> vice-versa.
The MIPS
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
This tree code dates all the way back to r69130[1] which implemented
typing of non-dependent expressions. Its motivation was never clear (to
me at least) since the documentation for it in e.g. cp-tree.def
This much more mechanical patch removes build_non_dependent_expr
(and make_args_non_dependent) and adjusts callers accordingly,
no functional change.
gcc/cp/ChangeLog:
* call.cc (build_new_method_call): Remove calls to
build_non_dependent_expr and/or make_args_non_dependent.
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111497
The patch was successfully tested and bootstrapped on x86-64 and aarch64.
commit 3c23defed384cf17518ad6c817d94463a445d21b
Author: Vladimir N. Makarov
Date: Mon Sep 25 16:19:50 2023 -0400
[PR111497][LRA]: Copy
On Mon, Sep 25, 2023 at 12:59 PM Philipp Tomsich
wrote:
>
> On Mon, 25 Sept 2023 at 21:54, Andrew Pinski wrote:
> >
> > On Mon, Sep 25, 2023 at 12:50 PM Manos Anagnostakis
> > wrote:
> > >
> > > This patch implements the following TODO in gcc/config/aarch64/aarch64.cc
> > > to provide the
Hello Andrew,
what you describe was my previous version, but @Kyrylo Tkachov
prompted me to use -param.
Thank you for taking a look anyway!
Manos Anagnostakis | Compiler Engineer
| E: manos.anagnosta...@vrull.eu
VRULL GmbH | Beatrixgasse 32 1030 Vienna | W: www.vrull.eu
Στις Δευ 25 Σεπ 2023,
On Mon, 25 Sept 2023 at 21:54, Andrew Pinski wrote:
>
> On Mon, Sep 25, 2023 at 12:50 PM Manos Anagnostakis
> wrote:
> >
> > This patch implements the following TODO in gcc/config/aarch64/aarch64.cc
> > to provide the requested behaviour for handling ldp and stp:
> >
> > /* Allow the tuning
On Mon, Sep 25, 2023 at 12:50 PM Manos Anagnostakis
wrote:
>
> This patch implements the following TODO in gcc/config/aarch64/aarch64.cc
> to provide the requested behaviour for handling ldp and stp:
>
> /* Allow the tuning structure to disable LDP instruction formation
> from combining
This patch implements the following TODO in gcc/config/aarch64/aarch64.cc
to provide the requested behaviour for handling ldp and stp:
/* Allow the tuning structure to disable LDP instruction formation
from combining instructions (e.g., in peephole2).
TODO: Implement fine-grained
The 'description' words looked a bit misplaced when reading the full sentence.
Likewise "the libnuma" - I changed that to simply "libnuma". (Alternatives
would be
"the libnuma library" or "the numa library".)
Hence, I fixed my own wording :-)
Committed as attached. See also
I stumbled over this during the ARM64 talk at the cauldron as they
consider using -fopenmp-simd by default.
→ https://gcc.gnu.org/wiki/cauldron2023 (I put my talk/BoF slides up;
others aren't, yet)
I did stumble over 'omp loop' with SIMD. It turns out that -fopenmp-simd
just turns 'loop' into
Hi all,
I stumbled over this as I found the wording in the release notes rather
unclear.is.
First, the following gives only a -pedantic warning and not a
-Wflex-array-member-not-at-end:
struct t { int b; int x[]; };
struct q { int b; struct t a[2]; int c; };
warning: invalid use of
Xi Ruoyao writes:
> On Mon, 2023-09-25 at 17:00 +0200, Arsen Arsenović wrote:
>> Afternoon,
>>
>> This patch series replaces the old (early 2000s era, AFAICT) libintl
>> implementation in-tree, which relies on C constructs some compilers
>> (newer clang, hopefully GCC 14) refuse to compile by
On Mon, 2023-09-25 at 17:00 +0200, Arsen Arsenović wrote:
> Afternoon,
>
> This patch series replaces the old (early 2000s era, AFAICT) libintl
> implementation in-tree, which relies on C constructs some compilers
> (newer clang, hopefully GCC 14) refuse to compile by default with
> out-of-tree
OK for trunk at least. Thanks. I presume it'll be fine for the other
releases.
Andrew
On 9/25/23 11:51, Eric Botcazou wrote:
Hi,
the varying case currently falls through to the 1/true case.
Tested on x86_64-suse-linux, OK for mainline, 13 and 12 branches?
2023-09-25 Eric Botcazou
Hi,
the varying case currently falls through to the 1/true case.
Tested on x86_64-suse-linux, OK for mainline, 13 and 12 branches?
2023-09-25 Eric Botcazou
* gimple-range-gori.cc (gori_compute::logical_combine): Add missing
return statement in the varying case.
2023-09-25
Committed to trunk.
Dave
---
Update baseline symbols for hppa-linux.
2023-09-25 John David Anglin
libstdc++-v3/ChangeLog:
* config/abi/post/hppa-linux-gnu/baseline_symbols.txt: Update.
diff --git a/libstdc++-v3/config/abi/post/hppa-linux-gnu/baseline_symbols.txt
Hi Yujie,
Sorry, I did not know Loongson Technologies is also working on this.
However, you can jump onto that GitHub pull request to review my changes
so that they align with your implementation and nobody's effort would go
to waste.
Thanks,
Zixing
On 2023/9/25 04:04, Yang Yujie wrote:
Afternoon,
This patch series replaces the old (early 2000s era, AFAICT) libintl
implementation in-tree, which relies on C constructs some compilers
(newer clang, hopefully GCC 14) refuse to compile by default with
out-of-tree gettext, in a manner similar to GMP et al, and adds gettext
to
> Am 25.09.2023 um 14:18 schrieb Aldy Hernandez :
>
> In auditing the DOM code to see what the scoped tables catch that
> ranger doesn't, I've run accross this test, which seems to
> have uninitialized reads from both j and present[].
>
> From the original PR, it looks like this came from a
In auditing the DOM code to see what the scoped tables catch that
ranger doesn't, I've run accross this test, which seems to
have uninitialized reads from both j and present[].
>From the original PR, it looks like this came from a reduction of a
failing test in SPEC's 464.h264ref. A google
On 25/09/2023 19:51, Richard Biener wrote:
On Sun, Sep 24, 2023 at 3:09 PM Jørgen Kvalsvik wrote:
This is a request for feedback and a proof-of-concept, not something I
intend to merge as-is. It would be nice if gcc, maybe just under some
circumstances, always generated an else-block for
Thanks for the feedback, Kyrill.
I'll resend it as a V3. I believe you have also checked V2 containing just
a small test adjustment.
Manos Anagnostakis | Compiler Engineer
| E: manos.anagnosta...@vrull.eu
VRULL GmbH | Beatrixgasse 32 1030 Vienna | W: www.vrull.eu
Στις Δευ 25 Σεπ 2023, 13:59 ο
On 9/25/23 04:18, Palmer Dabbelt wrote:
On Mon, 18 Sep 2023 15:13:04 PDT (-0700), Vineet Gupta wrote:
On 9/18/23 09:11, Jeff Law wrote:
On 9/18/23 09:24, Kito Cheng wrote:
I may missed that one time too, not on plane yet, but need to go bed
earlier due to my flight is in next day early
Hi Manos,
Apologies for the long delay.
> -Original Message-
> From: Manos Anagnostakis
> Sent: Friday, August 18, 2023 8:50 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Philipp Tomsich
> ; Manos Anagnostakis
>
> Subject: [PATCH] aarch64: Fine-grained ldp and stp policies
> This is why I got a bit uncertain and hoped to get some feedback whether
> my intuition is correct or not. Meanwhile I also found a comment in
> the internals book at "14.7 Constant Expression Types" where we have:
>
>"Constants generated for modes with fewer bits than in HOST_WIDE_INT
>
On Sun, Sep 24, 2023 at 3:09 PM Jørgen Kvalsvik wrote:
>
> This is a request for feedback and a proof-of-concept, not something I
> intend to merge as-is. It would be nice if gcc, maybe just under some
> circumstances, always generated an else-block for coverage purposes.
>
> I am working on the
On Mon, 18 Sep 2023 15:13:04 PDT (-0700), Vineet Gupta wrote:
On 9/18/23 09:11, Jeff Law wrote:
On 9/18/23 09:24, Kito Cheng wrote:
I may missed that one time too, not on plane yet, but need to go bed
earlier due to my flight is in next day early morning...
I'm unavailable as well, though I
Hi Zixing,
We are also working on a patch series that could pass the libphobos regression
tests.
Will post this later once all failed items are fixed.
Yujie
On Sun, Sep 24, 2023 at 03:40:32PM -0600, Zixing Liu wrote:
> This patch adds the LoongArch64 support for GCC D frontend.
>
> The
On Mon, Sep 18, 2023 at 08:39:34AM +0200, Paul Iannetta wrote:
> On Thu, Sep 14, 2023 at 04:24:33PM +0200, Paul Iannetta wrote:
> > Hi,
> >
> > This is a small patch so that both dg-extract-results.py and
> > dg-extract-results.sh share the same header. In particular, it fixes
> > the fact that
Thanks! I will try to improve it.
On Mon, 2023-09-25 at 17:44 +0800, Xi Ruoyao wrote:
> On Mon, 2023-09-25 at 17:38 +0800, Chenghui Pan wrote:
> > Hi!
> >
> > After some attemptions, I think we still ne to check
> > "check_effective_target_loongarch_sx" in vect_int_mod. I wrote some
> > temp
On Mon, 2023-09-25 at 17:38 +0800, Chenghui Pan wrote:
> Hi!
>
> After some attemptions, I think we still ne to check
> "check_effective_target_loongarch_sx" in vect_int_mod. I wrote some
> temp logics in gcc/testsuite/lib/target-supports.exp like this:
>
> diff --git
Hi!
After some attemptions, I think we still ne to check
"check_effective_target_loongarch_sx" in vect_int_mod. I wrote some
temp logics in gcc/testsuite/lib/target-supports.exp like this:
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index
Tested x86_64-linux. Pushed to trunk.
-- >8 --
As noted in PR c++/111512, GCC does ADL for __builtin_memcpy if it is
unqualified, which can cause errors for template argument types which
cannot be completed.
Casting the memcpy arguments to void* prevents ADL from considering the
problem type.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/move.h (forward_list): Define for C++23.
* include/bits/version.def (forward_like): Define.
* include/bits/version.h: Regenerate.
* include/std/utility
> >> PR 108007 is another manifestation where we rely on DCE to clean-up
> >> after IPA-SRA and if the user explicitely switches DCE off, IPA-SRA
> >> can leave behind statements which are fed uninitialized values and
> >> trap, even though their results are themselves never used.
> >>
> >> I have
> >> gcc/ChangeLog:
> >>
> >> 2023-08-18 Martin Jambor
> >>
> >>PR ipa/110378
> >>* ipa-param-manipulation.cc
> >>(ipa_param_body_adjustments::mark_dead_statements): Verify that any
> >>return uses of PARAM will be removed.
> >>
On Mon, 2023-09-25 at 16:26 +0800, chenglulu wrote:
> LGTM!
>
> Thank you for your modification!
Pushed r14-4250.
> 在 2023/9/25 下午4:13, Xi Ruoyao 写道:
> > gcc/ChangeLog:
> >
> > * doc/invoke.texi: Update -m[no-]explicit-relocs for r14-4160.
> > ---
> >
> > I've not regtested this as it's
LGTM!
Thank you for your modification!
在 2023/9/25 下午4:13, Xi Ruoyao 写道:
gcc/ChangeLog:
* doc/invoke.texi: Update -m[no-]explicit-relocs for r14-4160.
---
I've not regtested this as it's only a doc change. Ok for trunk?
gcc/doc/invoke.texi | 10 ++
1 file changed, 6
gcc/ChangeLog:
* doc/invoke.texi: Update -m[no-]explicit-relocs for r14-4160.
---
I've not regtested this as it's only a doc change. Ok for trunk?
gcc/doc/invoke.texi | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/gcc/doc/invoke.texi
Hi,
on 2023/9/20 16:49, HAO CHEN GUI wrote:
> Hi,
> This patch enables vector compare for 16-byte memory equality compare.
> The 16-byte memory equality compare can be efficiently implemented by
> instruction "vcmpequb." It reduces one branch and one compare compared
> with two 8-byte compare
55 matches
Mail list logo
