On 10/5/23 08:46, Stefan Schulze Frielinghaus wrote:
> gcc/ChangeLog:
>
> * config/s390/s390.md: Make use of new copysign RTL.
Ok. Thanks!
Andreas
> ---
> gcc/config/s390/s390.md | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/config/s390/s390.md
Thanks Jeff, committed with a better Changelog as your suggestion.
Pan
-Original Message-
From: Jeff Law
Sent: Saturday, October 7, 2023 12:53 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang ;
kito.ch...@gmail.com
Subject: Re: [PATCH v1] RISC-V:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111634
--- Comment #2 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:a809a556dc0792a34fca7b754ff96ea3ea7d1e7f
commit r14-4443-ga809a556dc0792a34fca7b754ff96ea3ea7d1e7f
Author: Pan Li
Date: Sat Oct 7
On 10/6/23 22:49, pan2...@intel.com wrote:
From: Pan Li
Given we have RTL as below.
(plus:DI (mult:DI (reg:DI 138 [ g.4_6 ])
(const_int 8 [0x8]))
(lo_sum:DI (reg:DI 167)
(symbol_ref:DI ("f") [flags 0x86] )
))
When handling (plus (plus
From: Pan Li
Given we have RTL as below.
(plus:DI (mult:DI (reg:DI 138 [ g.4_6 ])
(const_int 8 [0x8]))
(lo_sum:DI (reg:DI 167)
(symbol_ref:DI ("f") [flags 0x86] )
))
When handling (plus (plus (mult (a) (mem_shadd_constant)) (fp)) (C)) case,
the fp
Commited, thanks juzhe.
--
Li Xu
>OK.
>
>
>
>juzhe.zh...@rivai.ai
>
>From: Li Xu
>Date: 2023-10-07 11:18
>To: gcc-patches
>CC: kito.cheng; palmer; juzhe.zhong; xuli
>Subject: [PATCH] RISC-V: Fix scan-assembler-times of RVV test case
>From: xuli
>
>gcc/testsuite/ChangeLog:
>
> *
On Wed, Oct 04, 2023 at 02:13:46PM +0200, Jan-Benedict Glaw wrote:
> Seems this breaks for me with
>
> ../gcc/configure [...] --enable-werror-always --enable-languages=all
> --disable-gcov --disable-shared --disable-threads
> --target=loongarch64-linux-gnuf32 --without-headers
> make V=1
OK.
juzhe.zh...@rivai.ai
From: Li Xu
Date: 2023-10-07 11:18
To: gcc-patches
CC: kito.cheng; palmer; juzhe.zhong; xuli
Subject: [PATCH] RISC-V: Fix scan-assembler-times of RVV test case
From: xuli
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-25.c: Adjust
From: xuli
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-25.c: Adjust assembler
times.
* gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-26.c: Ditto.
---
.../gcc.target/riscv/rvv/vsetvl/vlmax_back_prop-25.c | 10 +-
On Fri, Sep 22, 2023 at 6:58 PM Hongyu Wang wrote:
>
> From: Kong Lingling
>
> Add -mapx-features= enumeration to separate subfeatures of APX_F.
> -mapxf is treated same as previous ISA flag, while it sets
> -mapx-features=apx_all that enables all subfeatures.
Ok for this and the resest of
On Thu, Sep 28, 2023 at 11:23 AM ZiNgA BuRgA wrote:
>
> That sounds about right. The code I had in mind would perhaps look like:
>
>
> #if defined(__AVX512BW__) && defined(__AVX512VL__)
> #if defined(__EVEX256__) && !defined(__EVEX512__)
> // compiled code is AVX10.1/256 and AVX512
Thanks for reporting it.
I think we may need to change it into:
+ /* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 4 "vect" {
target {! vect_load_lanes } } } } */
+/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 3 "vect" {
target vect_strided5 &&
Hi, Kito & Jeff
Due to National Day reasons, I was unable to reply to the email in a timely
manner.
Thank you for making the necessary changes to this patch. For the introduction
of this bug,
I will also carefully summarize my experience and lessons to avoid the
recurrence of such problems.
On Fri, Oct 6, 2023 at 6:49 PM Jakub Svojgr via Gcc wrote:
> Hello,
> this is an extremely specific scenario - however while compiling
> computer-generated code for a fibonnacci function which looks like this:
>
> I32 GF_fib_I_I(I32 L_0_0)
> {
> I32 L_2_0; I32 L_5_0; I32 L_6_0;
> bb0:;
>
Hello,
this is an extremely specific scenario - however while compiling
computer-generated code for a fibonnacci function which looks like this:
I32 GF_fib_I_I(I32 L_0_0)
{
I32 L_2_0; I32 L_5_0; I32 L_6_0;
bb0:;
bool L_0_1 = ((I32)L_0_0) == ((I32)0);
if (L_0_1)
{
goto
Snapshot gcc-12-20231006 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20231006/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #14 from Lukas Grätz ---
(In reply to Andrew Pinski from comment #13)
> (In reply to Andrew Pinski from comment #12)
> > Gcc does have tail call optimization which should allow the instrumentation
> > with less overhead. Though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #13 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #12)
> Gcc does have tail call optimization which should allow the instrumentation
> with less overhead. Though tail call optimization happens at -O2 and above
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #12 from Andrew Pinski ---
Gcc does have tail call optimization which should allow the instrumentation
with less overhead. Though tail call optimization happens at -O2 and above only
(by default).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #11 from Lukas Grätz ---
(In reply to Alexander Monakov from comment #10)
> (In reply to Lukas Grätz from comment #9)
> > I also wondered whether
> >
> > int bar_alias (void) { return bar_original(); }
> >
> > could be a portable
> So if you think you got everything correct the patch is OK as-is,
> I just wasn't sure - maybe the neutral_element change deserves
> a comment as to how MINUS_EXPR is handled.
Heh, I never think I got everything correct ;)
Added this now:
static bool
fold_left_reduction_fn (code_helper
Dear all,
the attached simple patch fixes a mixup of error messages for -ffpe-trap
and -ffpe-summary. While at it, I though it might be useful to accept
'none' as allowable argument to -ffpe-trap, so that traps previously set
on the command line may be cleared. This change is also documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110957
--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 56071
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56071=edit
Patch to fix mixed up parsing of fpe options
The attached patch fixes the mixup and adds the possibility
Am Freitag, dem 06.10.2023 um 06:50 -0400 schrieb Siddhesh Poyarekar:
> On 2023-10-06 01:11, Martin Uecker wrote:
> > Am Donnerstag, dem 05.10.2023 um 15:35 -0700 schrieb Kees Cook:
> > > On Thu, Oct 05, 2023 at 04:08:52PM -0400, Siddhesh Poyarekar wrote:
> > > > 2. How would you handle signedness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #19 from Vineet Gupta ---
FWIW with today's change, splitter is now hidden from IRA, but we are still
getting the extraneous mv.
2023-10-06 c1bc7513b1d7 RISC-V: const: hide mvconst splitter from IRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #18 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #17)
> (In reply to Vineet Gupta from comment #16)
> > > Which is what this produces:
> > > ```
> > > long long f(void)
> > > {
> > > unsigned t = 16843009;
> > >
Office Hours for the GNU Toolchain on October 17th at 11am EDT.
Agenda:
* First Office Hours and test of the meeting system.
* No specific agenda will be presented, but feel free to attend.
Meeting Link:
* https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6
--
Cheers,
Carlos.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111663
Sergei Trofimovich changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |slyfox at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111663
--- Comment #2 from CVS Commits ---
The master branch has been updated by Sergei Trofimovich :
https://gcc.gnu.org/g:2551e10038a70901f30b2168e6e3af4536748f3c
commit r14-4439-g2551e10038a70901f30b2168e6e3af4536748f3c
Author: Sergei Trofimovich
Vlad recently introduced a new gate @ira_in_progress, similar to
counterparts @{reload,lra}_in_progress.
Use this to hide the constant synthesis splitter from being recog* ()
by IRA register equivalence logic which is eager to undo the splits,
generating worse code for constants (and sometimes no
On 10/6/23 11:49, Vineet Gupta wrote:
Vlad recently introduced a new gate @ira_in_progress, similar to
counterparts @{reload,lra}_in_progress.
Use this to hide the constant synthesis splitter from being recog* ()
by IRA register equivalence logic which is eager to undo the splits,
generating
On 10/6/23 08:17, Manolis Tsamis wrote:
SNIP
So I was ready to ACK, but realized there weren't any testresults for a
primary platform mentioned. So I ran this on x86.
It's triggering one regression (code quality).
Specifically gcc.target/i386/pr52146.c
The f-m-o code is slightly worse
Vlad recently introduced a new gate @ira_in_progress, similar to
counterparts @{reload,lra}_in_progress.
Use this to hide the constant synthesis splitter from being recog* ()
by IRA register equivalence logic which is eager to undo the splits,
generating worse code for constants (and sometimes no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
--- Comment #4 from Andrew Macleod ---
(In reply to Richard Biener from comment #3)
> Looks like some frange / relation mistake then.
l_3(D) [frange] double [-Inf, +Inf]
Equivalence set : [l_3(D), r_4(D)]
:
_1 = __builtin_signbit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111717
Andrew Pinski changed:
What|Removed |Added
Keywords||c++-lambda
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111716
--- Comment #4 from Andrew Pinski ---
Short testcase:
```
struct f
{
int a[10];
int b[10];
int c;
int d[10];
int e[10];
};
void g(int a[10], int b[10], int e, int i[10], int j[10]);
void h(void *a1)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111716
--- Comment #3 from King Lok Chung ---
(In reply to Andrew Pinski from comment #1)
> (In reply to King Lok Chung from comment #0)
> > I also find that the type of the parameter is not propagated correctly. For
> > example, an array type is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111716
Andrew Pinski changed:
What|Removed |Added
Target|riscv64-linux-gnu |riscv64-linux-gnu
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111717
--- Comment #1 from 康桓瑋 ---
#include
namespace std {
constexpr size_t dynamic_extent = -1;
template
class extents { };
template
using dextents = decltype([](index_sequence) {
return extents{};
}(make_index_sequence{}));
// this works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111717
Bug ID: 111717
Summary: syntax error When CTAD encounters complex alias
template
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #9 from Lukas Grätz ---
Thanks for everything, it seemed to be a misunderstanding from my side anyway
and the documentation fix should help others.
I am sorry for being silent, I was sick for a few days. As for my original
problem,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111716
--- Comment #1 from Andrew Pinski ---
(In reply to King Lok Chung from comment #0)
> I also find that the type of the parameter is not propagated correctly. For
> example, an array type is propagated as a pointer type. Should I open
> another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #4 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111716
Bug ID: 111716
Summary: call site parameter not matching with formal parameter
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714
--- Comment #3 from Carlos Galvez ---
Thanks for the quick response! Unfortunately we are stuck on GCC 9 for reasons
so I'll try to shuffle the code around a bit to make it work :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111672
--- Comment #13 from Hanke Zhang ---
(In reply to Andrew Pinski from comment #12)
> (In reply to Hanke Zhang from comment #11)
> > But I have never seen this '_FORTIFY_SOURCE' before. So I'm a confused as
> > well. And when I try gcc@11.4 built
gcc/ChangeLog:
* doc/extend.texi (Function Attributes): Mention standard attribute
syntax.
(Variable Attributes): Likewise.
(Type Attributes): Likewise.
(Attribute Syntax): Likewise.
---
gcc/doc/extend.texi | 74
Hi Bruno,
Bruno Haible writes:
>> * intlmacosx.m4: Import from gettext-0.22 (serial 8).
>
> A further suggestion (can be done in a separate patch, later):
>
> Use intlmacosx.m4 from gettext-0.22.3 (serial 9).
>
> This version enables portability to macOS 14, which was released
> on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110368
--- Comment #7 from Sam James ---
That said, I suppose we should do better here with -Wstrict-aliasing. No level
detects it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714
--- Comment #2 from Andrew Pinski ---
>From IV-OPTs dup:
inv_expr 3: (-() _13 - () ) - -1
inv_expr 4: -() _13 - ()
That is totally bogus (that was even in GCC 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715
--- Comment #1 from Richard Biener ---
Created attachment 56068
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56068=edit
preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715
Bug ID: 111715
Summary: Missed optimization in FRE because of weak TBAA
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714
--- Comment #1 from Richard Biener ---
looks like a bug in GCC 9.x, note that's EOL and thus will receive no fixes.
You can try to bisect where it was fixed since GCC 10.1 seems to work. There
might be a duplicate fixed bugreport for this.
Arsen Arsenović wrote:
> * intlmacosx.m4: Import from gettext-0.22 (serial 8).
A further suggestion (can be done in a separate patch, later):
Use intlmacosx.m4 from gettext-0.22.3 (serial 9).
This version enables portability to macOS 14, which was released
on 2023-09-26. (Older versions
On 15/09/2023 10:16, Juzhe-Zhong wrote:
This test failed in RISC-V:
FAIL: gcc.dg/vect/slp-1.c -flto -ffat-lto-objects scan-tree-dump-times vect
"vectorizing stmts using SLP" 4
FAIL: gcc.dg/vect/slp-1.c scan-tree-dump-times vect "vectorizing stmts using
SLP" 4
Because this loop:
/* SLP
On Thu, Oct 5, 2023 at 1:05 AM Jeff Law wrote:
>
>
>
> On 10/3/23 05:45, Manolis Tsamis wrote:
> > This is a new RTL pass that tries to optimize memory offset calculations
> > by moving them from add immediate instructions to the memory loads/stores.
> > For example it can transform this:
> >
> >
I've just committed this patch. It should have no functional changes
except to make it easier to add new alternatives into the
alternative-heavy move instructions.
Andrewamdgcn: switch mov insns to compact syntax
The move instructions typically have many alternatives (and I'm about to add
Afternoon,
This patch is a rebase and rewording of
https://inbox.sourceware.org/20230925150921.894157-1-ar...@aarsen.me/
Changes since v1:
- Implement Brunos suggested changes to install.texi.
- Elaborate commit message in p2 (as requested by the Binutils
maintainers).
Arsen Arsenović (2):
ChangeLog:
* intl: Remove directory. Replaced with out-of-tree GNU
gettext.
---
Note that the commit message here doesn't pass the changelog verifier.
What should I reword it as? mklog suggests:
ChangeLog:
* intl/ChangeLog: Removed.
* intl/Makefile.in: Removed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111700
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-10-06
Ever confirmed|0
Grr! I've done it again. ENOPATCH.
> -Original Message-
> From: Roger Sayle
> Sent: 06 October 2023 14:58
> To: 'gcc-patches@gcc.gnu.org'
> Cc: 'Uros Bizjak'
> Subject: [X86 PATCH] Implement doubleword right shifts by 1 bit using
s[ha]r+rcr.
>
>
> This patch tweaks the i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714
Bug ID: 111714
Summary: Strange behavior when casting std::size_t to bool, UB
or compiler bug?
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Severity:
This patch tweaks the i386 back-end's ix86_split_ashr and ix86_split_lshr
functions to implement doubleword right shifts by 1 bit, using a shift
of the highpart that sets the carry flag followed by a rotate-carry-right
(RCR) instruction on the lowpart.
Conceptually this is similar to the recent
On Thu, Oct 5, 2023 at 5:54 PM Jeff Law wrote:
>
>
>
> On 10/3/23 05:45, Manolis Tsamis wrote:
> > This is a new RTL pass that tries to optimize memory offset calculations
>
> > +
> > +/* If INSN is a root memory instruction then compute a potentially new
> > offset
> > + for it and test if
On Fri, 6 Oct 2023, Robin Dapp wrote:
> > We might need a similar assert
> >
> > gcc_assert (HONOR_SIGNED_ZEROS (vectype_out)
> > && !HONOR_SIGN_DEPENDENT_ROUNDING (vectype_out));?
>
> erm, obviously not that exact assert but more something like
>
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255
Patrick Palka changed:
What|Removed |Added
CC||hewillk at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111712
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
On 10/6/2023 2:24 PM, Saurabh Jha wrote:
Hey,
This patch adds support for the Cortex-X4 CPU to GCC.
Regression testing for aarch64-none-elf target and found no regressions.
Okay for gcc-master? I don't have commit access so if it looks okay,
could someone please help me commit this?
Hey,
This patch adds support for the Cortex-X4 CPU to GCC.
Regression testing for aarch64-none-elf target and found no regressions.
Okay for gcc-master? I don't have commit access so if it looks okay,
could someone please help me commit this?
Thanks,
Saurabh
gcc/ChangeLog
*
I've just committed this simple patch to silence an enum warning.
Andrewamdgcn: silence warning
gcc/ChangeLog:
* config/gcn/gcn.cc (print_operand): Adjust xcode type to fix warning.
diff --git a/gcc/config/gcn/gcn.cc b/gcc/config/gcn/gcn.cc
index f6cff659703..ef3b6472a52 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708
--- Comment #5 from Kirill Frolov ---
C standard states,that:
6.2.2 Linkages of identifiers
7) If, within a translation unit, the same identifier appears with both
internal and external linkage, the behavior is undefined.
So, I think only
> We might need a similar assert
>
> gcc_assert (HONOR_SIGNED_ZEROS (vectype_out)
> && !HONOR_SIGN_DEPENDENT_ROUNDING (vectype_out));?
erm, obviously not that exact assert but more something like
if (HONOR_SIGNED_ZEROS && !HONOR_SIGN_DEPENDENT_ROUNDING...)
{
> ... here we probably get PLUS_EXPR for MINUS_EXPR above but IIRC
> for MINUS_EXPR the !as_initial case should return positive zero.
>
> Can you double-check?
You're referring to the canonicalization from a - CST to a + -CST so
that the neutral op would need to change with it? Argh, good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708
--- Comment #4 from Kirill Frolov ---
With updated source ICC still gives an error.
MSVC works from my point of view correcly, same as Clang.
Lets see to a C-standard
(https://files.lhmouse.com/standards/ISO%20C%20N2176.pdf),
section 6.2.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708
--- Comment #3 from Kirill Frolov ---
Looks like example demonstrates undefined behaviour. This article
(https://wiki.sei.cmu.edu/confluence/display/c/DCL36-C.+Do+not+declare+an+identifier+with+conflicting+linkage+classifications)
contains
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN variants of the
vst1 intrinsic for arm32.
This patch adds the _x4 variants of the vst1 intrinsic.
ACLE documents are at https://developer.arm.com/documentation/ihi0053/latest/
ISA documents are at
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN variants of the
vst1 intrinsic for arm32.
This patch adds the _x3 variants of the vst1 intrinsic.
ACLE documents are at https://developer.arm.com/documentation/ihi0053/latest/
ISA documents are at
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN variants of the
vst1 intrinsic for arm32.
This patch adds the _x2 variants of the vst1 intrinsic. Tests use xN so that
the latter variants (_x3, _x4) could be added.
ACLE documents are at
Add xN variants of vst1_types intrinsic.
On 2023-10-06 01:11, Martin Uecker wrote:
Am Donnerstag, dem 05.10.2023 um 15:35 -0700 schrieb Kees Cook:
On Thu, Oct 05, 2023 at 04:08:52PM -0400, Siddhesh Poyarekar wrote:
2. How would you handle signedness of the size field? The size gets
converted to sizetype everywhere it is used and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111685
--- Comment #12 from Fedor Chelnokov ---
Related discussion: https://stackoverflow.com/q/77224270/7325599
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN variants of the
vld1q intrinsic for arm32.
This patch adds the _x4 variants of the vld1q intrinsic. This depends on the
the _x2 patch.
ACLE documents are at
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN variants of the
vld1q intrinsic for arm32.
This patch adds the _x3 variants of the vld1q intrinsic. This depends on the
the _x2 patch.
ACLE documents are at
From: Ezra Sitorus
This patch is part of a series of patches implementing the _xN variants of the
vld1q intrinsic for arm32.
This patch adds the _x2 variants of the vld1q intrinsic. Tests use xN so that
the latter variants (_x3, _x4) could be added.
ACLE documents are at
Add xN variants of vld1q_types intrinsic.
On Thu, 5 Oct 2023, Jan Hubicka wrote:
[...]
> Richi, can you please look at the gimple matching part?
What did you have in mind? I couldn't find anything obvious in the
patch counting as gimple matching - do you have a pointer?
Thanks,
Richard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111713
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109088
--- Comment #14 from Richard Biener ---
Sorry for the delay - but this looks exactly like Robins transform to COND_ADD,
no? But sure, the current code doesn't handle a reduction path through
multiple stmts but when if-conversion would convert
On Thu, Sep 14, 2023 at 2:43 PM Di Zhao OS
wrote:
>
> This is a new version of the patch on "nested FMA".
> Sorry for updating this after so long, I've been studying and
> writing micro cases to sort out the cause of the regression.
Sorry for taking so long to reply.
> First, following previous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111713
--- Comment #1 from 康桓瑋 ---
The "+*" part is not valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111713
Bug ID: 111713
Summary: libstdc++ accepts regular expression
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
On Thu, 5 Oct 2023, Robin Dapp wrote:
> Hi Tamar,
>
> > The only comment I have is whether you actually need this helper
> > function? It looks like all the uses of it are in cases you have, or
> > will call conditional_internal_fn_code directly.
> removed the cond_fn_p entirely in the attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111712
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> Better reduced testcase:
> ```
> long f(int a)
> {
> int b = 822920;
> int t = a == b;
> return t * (long)b;
> }
> ```
Here is one that ICEs on both arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260
--- Comment #7 from Andrew Pinski ---
Better reduced testcase:
```
long f(int a)
{
int b = 822920;
int t = a == b;
return t * (long)b;
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260
--- Comment #6 from Andrew Pinski ---
*** Bug 111711 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111711
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260
Andrew Pinski changed:
What|Removed |Added
Target|arm-linux-gnueabihf |arm-*-* aarch64-*-*
1 - 100 of 124 matches
Mail list logo
