On 9/21/22 03:40, FX via Gcc-patches wrote:
ping*2
Le 9 sept. 2022 à 19:55, FX a écrit :
ping
Le 1 sept. 2022 à 23:02, FX a écrit :
Attached patch adds __builtin_iseqsig() to the middle-end and C family
front-ends.
Testing does not currently check whether the signaling part works,
On 10/20/22 13:01, Andrea Parri wrote:
On Wed, Oct 12, 2022 at 07:16:20PM +0200, Andrea Parri wrote:
+Andrea, in case he has time to look at the memory model / ABI
issues.
+Jeff, who was offering to help when the threads got crossed. I'd punted on
a lot of this in the hope Andrea
On 10/24/22 00:04, Aldy Hernandez via Gcc-patches wrote:
PING
I'd be a lot more comfortable if Jakub would chime in here.
Jeff
On 10/16/22 04:09, Jakub Jelinek wrote:
Hi!
When working on libstdc++ extended float support in , I found that
we need various builtins for the _Float{16,32,64,128,32x,64x,128x} types.
Glibc 2.26 and later provides the underlying libm routines (except for
_Float16 and _Float128x for the time
On 10/15/22 06:08, A. Binzberger wrote:
Re: [PATCH] improved const shifts for AVR targets
On 12.10.22 19:57, Jeff Law wrote:
On 10/4/22 11:06, Alexander Binzberger via Gcc-patches wrote:
Hi,
recently I used some arduino uno for a project and realized some areas
which do not output optimal
On 10/28/22 06:34, Xiongchuan Tan via Gcc-patches wrote:
Reviewed-by: Palmer Dabbelt
Acked-by: Palmer Dabbelt
libitm/ChangeLog:
* configure.tgt: Add riscv support.
* config/riscv/asm.h: New file.
* config/riscv/sjlj.S: New file.
* config/riscv/target.h:
On 10/20/22 19:52, Cui, Lili via Gcc-patches wrote:
Hi Honza,
Gentle ping
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601934.html
gcc/ChangeLog
* ipa-inline-analysis.cc (do_estimate_edge_time): Add function attribute
judgement for INLINE_HINT_known_hot hint.
On 10/17/22 03:06, Florian Weimer via Gcc-patches wrote:
BFD ld (and the other linkers) only produce one encoding of these
values. It is not necessary to use the general
read_encoded_value_with_base decoding routine. This avoids the
data-dependent branches in its implementation.
libgcc/
On 10/25/22 13:59, Jan-Benedict Glaw wrote:
Hi Jeff!
On Mon, 2022-10-17 17:47:16 -0600, Jeff Law via Gcc-patches
wrote:
--- a/gcc/config/h8300/h8300.cc
+++ b/gcc/config/h8300/h8300.cc
@@ -5531,6 +5531,32 @@ h8300_ok_for_sibcall_p (tree fndecl, tree)
return 1;
}
+
+/* Return TRUE
On 10/28/22 04:14, Thomas Schwinge wrote:
Hi!
This minor clean-up had fallen out of me working on something else in
GCC's options machinery, several months ago:
On 2019-03-12T18:14:04+0100, marxin wrote:
gcc/lto/ChangeLog:
* lang.opt: Add new language LTODump and options related
On 10/27/22 22:23, Xi Ruoyao via Gcc-patches wrote:
On Thu, 2022-10-27 at 17:44 -0700, Palmer Dabbelt wrote:
though I don't have an opinion on whether libitm should be taking ports
to new targets, I'd never even heard of it before.
I asked this question to myself when I reviewed LoongArch
Tested powerpc64le-linux. Pushed to trunk. Worth backporting too.
-- >8 --
The new -Wdangling-reference warning noticed this.
libstdc++-v3/ChangeLog:
* include/bits/fs_path.h (path::filename()): Fix dangling
reference.
---
libstdc++-v3/include/bits/fs_path.h | 6 +++---
1 file
On Fri, Oct 28, 2022 at 2:34 PM Segher Boessenkool
wrote:
>
> On Wed, Oct 26, 2022 at 11:58:57AM -0700, H.J. Lu via Gcc-patches wrote:
> > In i386.md, neg patterns which set MODE_CC register like
> >
> > (set (reg:CCC FLAGS_REG)
> > (ne:CCC (match_operand:SWI48 1 "general_reg_operand")
> You mean in CCV? That works yes, but only because (or if) the setter
> and getter of the CC reg both use CCV (so never use any other flag at
> the same time; CCV has an empty intersection with all other CC modes).
We're talking about CCC here AFAIK, i.e. the carry, not CCV.
--
Eric Botcazou
Hi!
On Fri, Oct 28, 2022 at 10:35:03AM +0200, Eric Botcazou via Gcc-patches wrote:
> > (set (reg:SI 93)
> > (neg:SI (ltu:SI (reg:CCC 17 flags) (const_int 0 [0]
> >
> > as
> >
> > (set (reg:SI 93)
> > (neg:SI (ltu:SI (const_int 1) (const_int 0 [0]
> >
> > which leads to
On Wed, Oct 26, 2022 at 11:58:57AM -0700, H.J. Lu via Gcc-patches wrote:
> In i386.md, neg patterns which set MODE_CC register like
>
> (set (reg:CCC FLAGS_REG)
> (ne:CCC (match_operand:SWI48 1 "general_reg_operand") (const_int 0)))
>
> can lead to errors when operand 1 is a constant value.
On Linux/x86_64,
0607307768b66a90e27c5bc91a247acc938f070e is the first bad commit
commit 0607307768b66a90e27c5bc91a247acc938f070e
Author: Thomas Schwinge
Date: Tue Oct 25 13:10:52 2022 +0200
Fix target selector syntax in 'gcc.dg/vect/bb-slp-cond-1.c'
caused
FAIL:
Two things here:
1) when we're pointing out that std::move on a constant object is
redundant, don't say "in return statement" when we aren't in a
return statement;
2) suppress the warning when the std::move call was dependent, because
removing the std::move may not be correct for a
Dear all,
the passing of procedure arguments in Fortran sometimes requires
ancillary parameters that are "hidden". Examples are string length
and the presence status of scalar variables with optional+value
attribute.
The gfortran ABI is actually documented:
On Wed, Oct 26, 2022 at 7:09 AM Martin Liška wrote:
>
> PR sanitizer/107298
>
> gcc/ChangeLog:
>
> * doc/invoke.texi: Document sanitizers can trigger warnings.
> ---
> gcc/doc/invoke.texi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/gcc/doc/invoke.texi
> COMPARE may also set CC register to a constant when both operands are
> known constants.
No, a COMPARE is never evaluated alone, only the CC user may be evaluated.
--
Eric Botcazou
> I get a clean testsuite run configured and bootstrapped with
>
> --enable-languages=c,c++,go,fortran,ada,obj-c++,jit --enable-host-shared
>
> Is there a PR or specific tests in either fortran or ada for those
> improvements? ie, something specific I should check for? Part of rangers
>
On 10/27/22 11:39, Marek Polacek wrote:
I got this testcase:
auto f() -> std::optional;
for (char c : f().value()) { }
which has a dangling reference: std::optional::value returns
a reference to the contained value, but here it's the f() temporary.
We warn, which is great, but only with
On Fri, Oct 28, 2022 at 12:52:44PM -0400, Patrick Palka wrote:
> IIRC for hex formatting of denormals I opted to be consistent with how
> glibc printf formats them, instead of outputting the truly shortest
> form.
Note, it isn't just denormals,
1.18cp-4
2.318p-5
4.63p-6
8.c6p-7
463p-10
8c6p-11
On Thu, Oct 27, 2022 at 19:16:44 -0400, Ben Boeckel wrote:
> diff --git a/gcc/testsuite/g++.dg/modules/modules.exp
> b/gcc/testsuite/g++.dg/modules/modules.exp
> index afb323d0efd..7fe8825144f 100644
> --- a/gcc/testsuite/g++.dg/modules/modules.exp
> +++ b/gcc/testsuite/g++.dg/modules/modules.exp
On Fri, Oct 28, 2022 at 08:59:16 -0400, David Malcolm wrote:
> On Thu, 2022-10-27 at 19:16 -0400, Ben Boeckel wrote:
> > This simplifies the interface for other UTF-8 validity detections
> > when a
> > simple "yes" or "no" answer is sufficient.
> >
> > Signed-off-by: Ben Boeckel
> > ---
> >
On Fri, Sep 2, 2022 at 1:09 PM Kito Cheng via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> LGTM with minor comments, it's time to move forward, thanks Patrick and
> Palmer.
>
Ping.
Any plans to finally land this one for GCC 13?
The hope is that this patch would make life significantly
On Thu, 27 Oct 2022, Jakub Jelinek wrote:
> Hi!
>
> The following patch on top of
> https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html
> adds std::{,b}float16_t support for std::to_chars.
> When precision is specified (or for std::bfloat16_t for hex mode even if not),
> I believe
On Fri, 28 Oct 2022 02:37:13 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
I guess we don't really care about RV32E here, but in case you add a
guard for that?
#ifdef __riscv_e
#error "rv32e unsupported"
#endif
Ah, thanks. There's rv64e now too, but that's just an error message
problem so
Hi all,
please find attached the third iteration of this patch addresing review
comments.
Thanks
Andrea
>From e3001bd662b84dafeca200b52fc644b7bf81c4af Mon Sep 17 00:00:00 2001
From: Andrea Corallo
Date: Thu, 7 Apr 2022 11:51:56 +0200
Subject: [PATCH] [PATCH 12/15] arm: implement bti
Hi all,
the third iteration of this patch is attached addresing review comments.
Thanks
Andrea
>From b42e28be75f374a4e1a5943c8c9002e07dbcc567 Mon Sep 17 00:00:00 2001
From: Andrea Corallo
Date: Thu, 20 Jan 2022 15:36:23 +0100
Subject: [PATCH] [PATCH 10/15] arm: Implement cortex-M return
On Fri, 2022-10-28 at 17:20 +0200, Arthur Cohen wrote:
>
>
> On 10/28/22 15:06, David Malcolm wrote:
> > On Fri, 2022-10-28 at 13:48 +0200, Arthur Cohen wrote:
> > > Hi David,
> > >
> > > On 10/26/22 23:15, David Malcolm wrote:
> > > > On Wed, 2022-10-26 at 10:17 +0200,
> > > >
On Fri, Oct 28, 2022 at 1:35 AM Eric Botcazou wrote:
>
> > (set (reg:SI 93)
> > (neg:SI (ltu:SI (reg:CCC 17 flags) (const_int 0 [0]
> >
> > as
> >
> > (set (reg:SI 93)
> > (neg:SI (ltu:SI (const_int 1) (const_int 0 [0]
> >
> > which leads to incorrect results since LTU on
On 10/28/22 15:06, David Malcolm wrote:
On Fri, 2022-10-28 at 13:48 +0200, Arthur Cohen wrote:
Hi David,
On 10/26/22 23:15, David Malcolm wrote:
On Wed, 2022-10-26 at 10:17 +0200, arthur.co...@embecosm.com wrote:
This is the fixed version of our previous patch set for gccrs -
We've
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
Comparing attributes between declarations of a friend function has been
complicated by pushdecl happening before decl_attributes. I assumed there
was some complicated reason we weren't calling decl_attributes here, but it
doesn't break
On 20/10/22 16:58 +0200, Arsen Arsenović wrote:
This slightly lowers the dependency of generated code on libstdc++.so.
Looks good, I'll test and push, thanks.
libstdc++-v3/ChangeLog:
* include/std/functional: Make placeholders inline, if possible.
---
On 20/10/22 16:20 +0200, Arsen Arsenović wrote:
libstdc++-v3/ChangeLog:
* configure.ac: Stop generating gstdint.h.
* src/c++11/compatibility-atomic-c++0x.cc: Stop using gstdint.h.
---
> +using guintptr_t = __UINTPTR_TYPE__;
I think this should be local in the only function
On Wed, 26 Oct 2022 at 21:07, Richard Sandiford
wrote:
>
> Sorry for the slow response. I wanted to find some time to think
> about this a bit more.
>
> Prathamesh Kulkarni writes:
> > On Fri, 30 Sept 2022 at 21:38, Richard Sandiford
> > wrote:
> >>
> >> Richard Sandiford via Gcc-patches
On 10/28/22 10:14, Richard Biener wrote:
Am 28.10.2022 um 15:59 schrieb Andrew MacLeod :
On 10/28/22 09:46, Richard Biener wrote:
On Fri, Oct 28, 2022 at 3:43 PM Andrew MacLeod wrote:
On 10/28/22 03:17, Richard Biener wrote:
On Wed, Oct 26, 2022 at 4:24 PM Andrew MacLeod wrote:
Tested powerpc64le-linux. Pushed to trunk.
-- >8 --
The PR points out that we assume the match_results allocator is default
constuctible, which might not be true. We also have a related issue with
unwanted propagation from an object that might have an unequal
allocator.
Ideally we use the same
在 2022/10/28 17:38, WANG Xuerui 写道:
Hi,
The code change seems good but a few grammatical nits.
Patch subject should be a verb phrase, something like "libvtv: add
LoongArch support" could be better.
Ok, thank you. I'll make the changes.
On 2022/10/28 16:01, Lulu Cheng wrote:
After
> Am 28.10.2022 um 15:59 schrieb Andrew MacLeod :
>
>
>> On 10/28/22 09:46, Richard Biener wrote:
>>> On Fri, Oct 28, 2022 at 3:43 PM Andrew MacLeod wrote:
>>>
>>> On 10/28/22 03:17, Richard Biener wrote:
On Wed, Oct 26, 2022 at 4:24 PM Andrew MacLeod wrote:
> Figured I would ask
On 10/28/22 09:46, Richard Biener wrote:
On Fri, Oct 28, 2022 at 3:43 PM Andrew MacLeod wrote:
On 10/28/22 03:17, Richard Biener wrote:
On Wed, Oct 26, 2022 at 4:24 PM Andrew MacLeod wrote:
Figured I would ask what you guys think of making ranger the default for
the VRP1 pass now.
With
On Fri, 28 Oct 2022, Andre Vieira (lists) wrote:
>
> On 24/10/2022 14:29, Richard Biener wrote:
> > On Mon, 24 Oct 2022, Andre Vieira (lists) wrote:
> >
> >> Changing if-convert would merely change this testcase but we could still
> >> trigger using a different structure type, changing the size
On Fri, Oct 28, 2022 at 3:43 PM Andrew MacLeod wrote:
>
>
> On 10/28/22 03:17, Richard Biener wrote:
> > On Wed, Oct 26, 2022 at 4:24 PM Andrew MacLeod wrote:
> >> Figured I would ask what you guys think of making ranger the default for
> >> the VRP1 pass now.
> >>
> >> With partial equivalences
On 24/10/2022 14:29, Richard Biener wrote:
On Mon, 24 Oct 2022, Andre Vieira (lists) wrote:
Changing if-convert would merely change this testcase but we could still
trigger using a different structure type, changing the size of Int24 to 32
bits rather than 24:
package Loop_Optimization23_Pkg
On 10/28/22 03:17, Richard Biener wrote:
On Wed, Oct 26, 2022 at 4:24 PM Andrew MacLeod wrote:
Figured I would ask what you guys think of making ranger the default for
the VRP1 pass now.
With partial equivalences and the other bits I checked in the past few
weeks I'm not aware of much that
Hi Richard,
> It's n_invs + 2 * n_cands?
Correct, n_invs + 2 * n_cands, my apologies.
> The comment says we want to prefer eliminating IVs over invariants. Your
> patch
> undoes that by weighting invariants the same so it does no longer have
> the effect
> of the comment.
I see how my patch
Hi Richard,
> But something is wrong then - it shouldn't ever pick a candidate with
> an addressing
> mode that isn't supported?
Test case I presented in [0] only has non-"BASE + OFFSET" candidates. Correct me
if I'm wrong, but the candidate selection algorithm doesn't take into account
which
So what happens is that we elide processing of this check with
/* In addition to kills we can remove defs whose only use
is another def in defs. That can only ever be PHIs of which
we track two for simplicity reasons, the first and last in
The following makes sure to not hoist returns-twice calls in LIM
since we have no way to move the abnormal edge associated with it
and we are prone having stray abnormal edges in the IL which will
then cause IL verification failures even when the actual call
does not return twice.
Bootstrapped
On Fri, 2022-10-28 at 13:48 +0200, Arthur Cohen wrote:
> Hi David,
>
> On 10/26/22 23:15, David Malcolm wrote:
> > On Wed, 2022-10-26 at 10:17 +0200, arthur.co...@embecosm.com wrote:
> > > This is the fixed version of our previous patch set for gccrs -
> > > We've
> > > adressed
> > > the
This implements the missed conversion from pointer to integer.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/107435
* tree-vect-loop.cc (vectorizable_recurr): Convert initial
value to vector component type.
*
Martin Liška writes:
> Hello.
>
> I noticed the devel/modula-2 branch contains the following dead links:
>
> - http://www.gccsummit.org/2006
> - http://www.gccsummit.org/2010/speakers.php?types=LIGHTNING
> - http://floppsie.comp.glam.ac.uk/Papers/paper23/gaius-mulley-gnu-m2.pdf
> -
On Thu, 2022-10-27 at 19:16 -0400, Ben Boeckel wrote:
> This simplifies the interface for other UTF-8 validity detections
> when a
> simple "yes" or "no" answer is sufficient.
>
> Signed-off-by: Ben Boeckel
> ---
> libcpp/ChangeLog | 6 ++
> libcpp/charset.cc | 18 ++
>
On Thu, 2022-10-27 at 19:16 -0400, Ben Boeckel wrote:
> Unicode does not support such values because they are unrepresentable
> in
> UTF-16.
Wikipedia pointed me to RFC 3629, which was when UTF-8 introduced this
restriction, whereas libcpp was implementing the higher upper limit
from the earlier,
Reviewed-by: Palmer Dabbelt
Acked-by: Palmer Dabbelt
libitm/ChangeLog:
* configure.tgt: Add riscv support.
* config/riscv/asm.h: New file.
* config/riscv/sjlj.S: New file.
* config/riscv/target.h: New file.
---
v2: Change HW_CACHELINE_SIZE to 64 (in accordance
On Fri, Oct 28, 2022 at 1:45 PM Arthur Cohen wrote:
>
> Hi David,
>
> On 10/26/22 23:15, David Malcolm wrote:
> > On Wed, 2022-10-26 at 10:17 +0200, arthur.co...@embecosm.com wrote:
> >> This is the fixed version of our previous patch set for gccrs - We've
> >> adressed
> >> the comments raised
On Fri, Oct 28, 2022 at 2:27 PM Richard Biener
wrote:
>
> On Fri, Oct 28, 2022 at 11:11 AM Eric Botcazou via Gcc-patches
> wrote:
> >
> > Hi,
> >
> > the following change:
> >
> > 2021-07-28 Bin Cheng
> >
> > * alias.c (init_alias_analysis): Don't skip prologue/epilogue.
> >
> > broke
On Fri, Oct 28, 2022 at 11:11 AM Eric Botcazou via Gcc-patches
wrote:
>
> Hi,
>
> the following change:
>
> 2021-07-28 Bin Cheng
>
> * alias.c (init_alias_analysis): Don't skip prologue/epilogue.
>
> broke the alias analysis for the hard frame pointer (when it is used as a
> frame
Hi David,
On 10/26/22 23:15, David Malcolm wrote:
On Wed, 2022-10-26 at 10:17 +0200, arthur.co...@embecosm.com wrote:
This is the fixed version of our previous patch set for gccrs - We've
adressed
the comments raised in our previous emails.
[...snip...]
(Caveat: I'm not a global reviewer)
Hi!
This minor clean-up had fallen out of me working on something else in
GCC's options machinery, several months ago:
On 2019-03-12T18:14:04+0100, marxin wrote:
> gcc/lto/ChangeLog:
> * lang.opt: Add new language LTODump and options related
> to LTO dump tool.
As this new
> -Original Message-
> From: Andrew Pinski
> Sent: Thursday, October 27, 2022 4:15 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
> ; nd ; Richard Sandiford
> ; Marcus Shawcroft
>
> Subject: Re: [PATCH 2/3]AArch64 Promote function arguments using a
>
Hi,
The code change seems good but a few grammatical nits.
Patch subject should be a verb phrase, something like "libvtv: add
LoongArch support" could be better.
On 2022/10/28 16:01, Lulu Cheng wrote:
After several considerations, I decided to set VTV_PAGE_SIZE to 16KB under
loongarch64.
I guess we don't really care about RV32E here, but in case you add a
guard for that?
#ifdef __riscv_e
#error "rv32e unsupported"
#endif
On Fri, Oct 28, 2022 at 4:39 PM Xiongchuan Tan via Gcc-patches
wrote:
>
> Reviewed-by: Palmer Dabbelt
> Acked-by: Palmer Dabbelt
>
> libitm/ChangeLog:
>
>
On Windows, the ':' character is special and when the module name is
a single character, like 'A', then the flatname would be (for
example) 'A:Foo'. On Windows, 'A:Foo' is treated as an absolute
path by the module loader and is likely not found.
Without this patch, the test case pr98944_c.C fails
Hi,
the following change:
2021-07-28 Bin Cheng
* alias.c (init_alias_analysis): Don't skip prologue/epilogue.
broke the alias analysis for the hard frame pointer (when it is used as a
frame pointer, i.e. when the frame pointer is not eliminated) described in the
large comment at
Hi!
Previously we've been allowing that comma only in C++ when in attribute
form (which was the reason why it has been allowed), but 5.1 allows that
even in pragma form in C/C++ (with clarifications in 5.2) and 5.2
also in Fortran (which this patch doesn't implement).
Note, for directives which
Hi Andrew!
On 2022-10-28T10:38:11+0200, "Stubbs, Andrew" wrote:
>> -Original Message-
>> Looking into commit r13-3225-gbd9a05594d227cde79a67dc715bd9d82e9c464e9
>> "amdgcn: vector testsuite tweaks" for a moment, I also did wonder about
>> the following changes, because for
Hi,
Because we switch intrinsics for avx512bf16 to the new type __bf16. Now we
could use m128/256bh for vector bf16 type instead of m128/256bf16.
And unified builtin for avx512bf16/avxneconvert.
Thanks,
Lingling
> -Original Message-
> From: Hongtao Liu
> Sent: Tuesday, October 25,
Hi!
On 2022-10-18T16:46:07+0200, Thomas Schwinge wrote:
> On 2022-10-14T13:38:56+, Julian Brown wrote:
>> This patch prevents compiler-generated artificial variables from being
>> treated as privatization candidates for OpenACC.
>>
>> The rationale is that e.g. "gang-private" variables
On Fri, Oct 28, 2022 at 10:08 AM Hongyu Wang wrote:
>
> > Ugh, that's all quite ugly and unmaintainable, no?
> Agreed, I have the same feeling.
>
> > I'm quite sure that if this works it's not by intention. Doesn't this
> > also disable
> > register renaming and web when the user explicitely
Reviewed-by: Palmer Dabbelt
Acked-by: Palmer Dabbelt
libitm/ChangeLog:
* configure.tgt: Add riscv support.
* config/riscv/asm.h: New file.
* config/riscv/sjlj.S: New file.
* config/riscv/target.h: New file.
---
v2: Change HW_CACHELINE_SIZE to 64 (in accordance
> -Original Message-
> Looking into commit r13-3225-gbd9a05594d227cde79a67dc715bd9d82e9c464e9
> "amdgcn: vector testsuite tweaks" for a moment, I also did wonder about
> the following changes, because for 'vect_multiple_sizes' (for example,
> x86_64-pc-linux-gnu) that seems to lose more
> (set (reg:SI 93)
> (neg:SI (ltu:SI (reg:CCC 17 flags) (const_int 0 [0]
>
> as
>
> (set (reg:SI 93)
> (neg:SI (ltu:SI (const_int 1) (const_int 0 [0]
>
> which leads to incorrect results since LTU on MODE_CC register isn't the
> same as "unsigned less than" in x86 backend.
On Tue, Oct 25, 2022 at 9:42 PM Joseph Myers wrote:
>
> On Tue, 25 Oct 2022, Richard Biener wrote:
>
> > You are missing to stream the new type flag in tree-streamer-{in,out}.cc
> > and checking for tree merging in lto-common.cc:compare_tree_sccs_1
> >
> > Otherwise looks reasonable. Can you add
The following adjusts the testcase to require no epilogue also
for larger vectors than V4SI.
Pushed.
* gcc.dg/vect/pr100756.c: Adjust for larger vectors.
---
gcc/testsuite/gcc.dg/vect/pr100756.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Tue, Oct 25, 2022 at 11:05 PM Lewis Hyatt wrote:
>
> On Tue, Oct 25, 2022 at 7:35 AM Richard Biener
> wrote:
> >
> > On Thu, Oct 20, 2022 at 1:09 AM Lewis Hyatt via Gcc-patches
> > wrote:
> > >
> > > Currently, the ipa-free-lang-data pass resets most of the frontend's
> > > diagnostic
On Fri, Oct 28, 2022, 08:49 Richard Biener
wrote:
> On Fri, Oct 28, 2022 at 12:45 AM Jeff Law wrote:
> >
> >
> > On 10/25/22 15:01, Aldy Hernandez via Gcc-patches wrote:
> > > [Richi/Jakub/FP experts, does this sound like the right solution, or
> am I
> > > missing some subtle IPA/inlining
Hi!
On 2022-10-28T10:11:04+0200, I wrote:
> On 2022-10-18T15:59:24+0100, Julian Brown wrote:
>> On Tue, 18 Oct 2022 16:46:07 +0200 Thomas Schwinge
>> wrote:
>>> On 2022-10-14T13:38:56+, Julian Brown wrote:
>>> ..., but to my surprised, that did fire in one occasion:
>>>
>>> > ---
Hi!
On 2022-10-18T15:59:24+0100, Julian Brown wrote:
> On Tue, 18 Oct 2022 16:46:07 +0200 Thomas Schwinge
> wrote:
>> On 2022-10-14T13:38:56+, Julian Brown wrote:
>> ..., but to my surprised, that did fire in one occasion:
>>
>> > ---
> Ugh, that's all quite ugly and unmaintainable, no?
Agreed, I have the same feeling.
> I'm quite sure that if this works it's not by intention. Doesn't this
> also disable
> register renaming and web when the user explicitely specifies -funroll-loops?
>
> Doesn't this change -funroll-loops
After several considerations, I decided to set VTV_PAGE_SIZE to 16KB under
loongarch64.
v1 - > v2:
1. When the macro __loongarch_lp64 is defined, the VTV_PAGE_SIZE is set to 64K.
2. In the vtv_malloc.cc file __vtv_malloc_init function, it does not check
whether VTV_PAGE_SIZE is equal to the
Hi!
In addition to the technical issues pointed out by Jakub for this og12
commit:
On 2022-07-12T15:16:35+0100, Andrew Stubbs wrote:
> This patch [...]
> I will commit a backport to OG12 shortly.
> openmp: fix max_vf setting for amdgcn offloading
> --- a/gcc/omp-general.h
> +++
Hi!
On 2022-10-11T12:02:08+0100, Andrew Stubbs wrote:
> The testsuite needs a few tweaks following my patches to add multiple vector
> sizes for amdgcn.
While 'grep'ping for some other GCN thing, this:
> --- a/gcc/testsuite/gcc.dg/vect/bb-slp-cond-1.c
> +++
On Tue, Oct 25, 2022 at 3:00 PM Dimitrije Milosevic
wrote:
>
> Hi Richard,
>
> > don't you add n_invs twice now given
> >
> > unsigned n_old = data->regs_used, n_new = n_invs + n_cands;
> > unsigned regs_needed = n_new + n_old, available_regs = target_avail_regs;
> >
> > ?
>
> If you are
On Wed, Oct 26, 2022 at 7:53 AM Hongyu Wang wrote:
>
> Hi,
>
> Inspired by rs6000 and s390 port changes, this patch
> enables loop unrolling for small size loop at O2 by default.
> The default behavior is to unroll loop with unknown trip-count and
> less than 4 insns by 1 time.
>
> This improves
On Wed, Oct 26, 2022 at 4:24 PM Andrew MacLeod wrote:
>
> Figured I would ask what you guys think of making ranger the default for
> the VRP1 pass now.
>
> With partial equivalences and the other bits I checked in the past few
> weeks I'm not aware of much that the legacy VRP pass gets that
On Wed, Oct 26, 2022 at 1:38 PM Cui, Lili wrote:
>
> Hi Richard,
>
> > +@item x86-vect-unroll-min-ldst-threshold
> > +The vectorizer will check with target information to determine whether
> > +unroll it. This parameter is used to limit the mininum of loads and
> > +stores in the main loop.
> >
>
On Fri, Oct 28, 2022 at 8:43 AM Dimitrije Milosevic
wrote:
>
> Hi Jeff,
>
> > THe part I don't understand is, if you only have BASE+OFF, why does
> > preventing the calculation of more complex addressing modes matter? ie,
> > what's the point of computing the cost of something like base + off +
On Fri, Oct 28, 2022 at 8:48 AM Richard Biener
wrote:
>
> On Fri, Oct 28, 2022 at 12:45 AM Jeff Law wrote:
> >
> >
> > On 10/25/22 15:01, Aldy Hernandez via Gcc-patches wrote:
> > > [Richi/Jakub/FP experts, does this sound like the right solution, or am I
> > > missing some subtle IPA/inlining
On Fri, Oct 28, 2022 at 12:45 AM Jeff Law wrote:
>
>
> On 10/25/22 15:01, Aldy Hernandez via Gcc-patches wrote:
> > [Richi/Jakub/FP experts, does this sound like the right solution, or am I
> > missing some subtle IPA/inlining issue?]
> >
> > The problem here is that we're inlining a global range
Hi Jeff,
> THe part I don't understand is, if you only have BASE+OFF, why does
> preventing the calculation of more complex addressing modes matter? ie,
> what's the point of computing the cost of something like base + off +
> scaled index when the target can't utilize it?
Well, the
On Fri, Oct 28, 2022 at 2:20 PM Kong, Lingling via Gcc-patches
wrote:
>
> Hi,
>
> Previously we use unsigned short to represent bf16. It's not a good
> expression, and at the time the front end didn't support bf16 type.
> Now we introduced __bf16 to X86 psABI. So we can switch intrinsics to the
On Fri, Oct 28, 2022 at 1:00 AM Jeff Law wrote:
>
>
> On 10/25/22 14:59, Aldy Hernandez via Gcc-patches wrote:
> > [As Richi, and probably Jakub, have mentioned in the past...]
> >
> > As mentioned earlier, we should be using HONOR_* on types rather than
> > flag_finite_math_only.
> >
> > Will
Hi,
Previously we use unsigned short to represent bf16. It's not a good expression,
and at the time the front end didn't support bf16 type.
Now we introduced __bf16 to X86 psABI. So we can switch intrinsics to the new
type.
Ok for trunk ?
Thanks,
Lingling
gcc/ChangeLog:
*
On Fri, Oct 28, 2022 at 1:56 PM Hongtao Liu wrote:
>
> On Thu, Oct 27, 2022 at 2:59 AM H.J. Lu via Gcc-patches
> wrote:
> >
> > In i386.md, neg patterns which set MODE_CC register like
> >
> > (set (reg:CCC FLAGS_REG)
> > (ne:CCC (match_operand:SWI48 1 "general_reg_operand") (const_int 0)))
97 matches
Mail list logo
