On Wed, 19 Jun 2024, Jakub Jelinek wrote:
> On Wed, Jun 19, 2024 at 08:04:55AM +0200, Richard Biener wrote:
> > >> Note a canonical type should always be unqualified (for
> > >> classical qualifiers, not address space or atomic qualification)
> > >
> > > The logic in build_qualified_type is the s
On Wed, 19 Jun 2024, Martin Uecker wrote:
> Am Mittwoch, dem 19.06.2024 um 08:04 +0200 schrieb Richard Biener:
> >
> > > Am 18.06.2024 um 20:18 schrieb Martin Uecker :
> > >
> > > Am Dienstag, dem 18.06.2024 um 17:27 +0200 schrieb Richard Biener:
> > > >
> > > > > > Am 18.06.2024 um 17:20 schr
Am Mittwoch, dem 19.06.2024 um 08:29 +0200 schrieb Jakub Jelinek:
> On Wed, Jun 19, 2024 at 08:04:55AM +0200, Richard Biener wrote:
> > > > Note a canonical type should always be unqualified (for
> > > > classical qualifiers, not address space or atomic qualification)
> > >
> > > The logic in buil
Am Mittwoch, dem 19.06.2024 um 08:04 +0200 schrieb Richard Biener:
>
> > Am 18.06.2024 um 20:18 schrieb Martin Uecker :
> >
> > Am Dienstag, dem 18.06.2024 um 17:27 +0200 schrieb Richard Biener:
> > >
> > > > > Am 18.06.2024 um 17:20 schrieb Martin Uecker :
> > > >
> > > >
> > > > As discuss
On Wed, Jun 19, 2024 at 08:04:55AM +0200, Richard Biener wrote:
> >> Note a canonical type should always be unqualified (for
> >> classical qualifiers, not address space or atomic qualification)
> >
> > The logic in build_qualified_type is the same as in this patch,
> > it constructs TYPE_CANONICA
There is already one such link pretty directly above, so avoid the
second one.
---
htdocs/gcc-3.0/criteria.html | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/htdocs/gcc-3.0/criteria.html b/htdocs/gcc-3.0/criteria.html
index 97be2e30..3e679d28 100644
--- a/htdocs/gcc-3.0/cri
Pushed.
Gerald
---
htdocs/codingrationale.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/codingrationale.html b/htdocs/codingrationale.html
index c51c9da4..5e3d6b88 100644
--- a/htdocs/codingrationale.html
+++ b/htdocs/codingrationale.html
@@ -18,7 +18,7 @@
I
On Tue, 22 Mar 2022, Pokechu22 via Gcc-patches wrote:
> htdocs/codingrationale.html | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Thank you for this, and sorry for us missing it originally.
> -working set size, compile time, and debuggablity.
> +working set size, compile time, and
> Am 18.06.2024 um 20:18 schrieb Martin Uecker :
>
> Am Dienstag, dem 18.06.2024 um 17:27 +0200 schrieb Richard Biener:
>>
Am 18.06.2024 um 17:20 schrieb Martin Uecker :
>>>
>>>
>>> As discussed this replaces the use of check_qualified_type with
>>> a simple check for qualifiers as su
Committed the series, thanks Juzhe.
Pan
From: 钟居哲
Sent: Wednesday, June 19, 2024 11:55 AM
To: Li, Pan2 ; gcc-patches
Cc: kito.cheng ; jeffreyalaw ;
rdapp.gcc ; Li, Pan2
Subject: Re: [PATCH v1 1/2] RISC-V: Add testcases for unsigned .SAT_SUB scalar
form 11
lgtm
--Reply to Message
Committed the series, thanks Juzhe.
Pan
From: 钟居哲
Sent: Wednesday, June 19, 2024 12:01 PM
To: Li, Pan2 ; gcc-patches
Cc: kito.cheng ; jeffreyalaw ;
rdapp.gcc ; Li, Pan2
Subject: Re: [PATCH v1 2/7] RISC-V: Add testcases for unsigned .SAT_ADD vector
form 3
lgtm
--Reply to Message--
lgtm
--Reply to Message--
On Mon, Jun 17, 2024 22:34 PM pan2.li
lgtm
--Reply to Message--
On Mon, Jun 17, 2024 22:34 PM pan2.li
lgtm
--Reply to Message--
On Mon, Jun 17, 2024 22:34 PM pan2.li
lgtm
--Reply to Message--
On Mon, Jun 17, 2024 22:34 PM pan2.li
lgtm
--Reply to Message--
On Mon, Jun 17, 2024 22:34 PM pan2.li
lgtm
--Reply to Message--
On Mon, Jun 17, 2024 22:34 PM pan2.li
lgtm
--Reply to Message--
On Mon, Jun 17, 2024 22:34 PM pan2.li
lgtm
--Reply to Message--
On Tue, Jun 18, 2024 16:25 PM Li, Pan2
lgtm
--Reply to Message--
On Tue, Jun 18, 2024 16:25 PM Li, Pan2
Hi Carl,
>> I'd expect the "-runnable" test case focuses on testing for run. Normally,
>> the one without "-runnable" would focus on testing for compiling (scan some
>> desired insn), but this altivec-1.c and altivec-1-runnable.c seems to test
>> for different things, maybe we should separate the
Hi Carl,
on 2024/6/14 03:40, Carl Love wrote:
> GCC maintainers:
>
> The patch has been updated per the feedback from version 3. Please let me
> know it the patch is acceptable for mainline.
>
> Thanks.
>
> Carl
>
> -
Hi Carl,
on 2024/6/14 03:40, Carl Love wrote:
>
> GCC maintainers:
>
> The patch has been updated per the comments from version 3. Please let me
> know if the patch is acceptable for mainline.
>
> Thanks.
>
> Carl
>
> ---
Hi Carl,
on 2024/6/14 03:40, Carl Love wrote:
>
> GCC maintainers:
>
> The patch has been updated per the comments from version 3. Please let me
> know if the patch is acceptable for mainline.
>
> Carl
>
>
Hi Carl,
on 2024/6/14 03:40, Carl Love wrote:
>
> GCC maintainers:
>
> As noted the removal of __builtin_vsx_xvcvdpuxds_uns and
> __builtin_vsx_xvcvspuxws was moved to patch 2 in the seris. The patch has
> been updated per the comments from version 3.
>
> Please let me know if this patch is
Hi Carl,
on 2024/6/14 03:40, Carl Love wrote:
> GCC maintainers:
>
> Per the comments on patch 0004 from version 3, the removal of
> The built-in __builtin_vsx_xvcvdpuxds_uns and __builtin_vsx_xvcvspuxws was
> moved to this patch. The rest of the patch is unchanged from version 3.
> There we
Great news, thanks for the quick reply.
BR，
Jin
--
From:wangf...@eswincomputing.com
Send Time:2024 Jun. 19 (Wed.) 08:18
To:Jin Ma
Cc:"kito.cheng"; "juzhe.zhong";
"jinma.contrib";
zengxiao; "gcc-patches";
gaofei
Subje
As $Subject.
Pushed.
Ramana
commit 01691a6d0582a921bbcc09ab5e0cd9e7deca2cca
Author: Ramana Radhakrishnan
Date: Tue Jun 18 16:05:31 2024 +0530
[MAINTAINERS] Update my email address and move to DCO.
Signed-off-by: Ramana Radhakrishnan
* MAINTAINERS: Update m
Hi Jin,
Will submit patch after internal review，maybe today.
wangf...@eswincomputing.com
From: Jin Ma
Date: 2024-06-18 18:25
To: wangfeng
CC: Kito Cheng; juzhe.zhong; jinma.contrib; zengxiao; gcc-patches; Fei Gao
Subject: Re: [RE] [v2] RISC-V: Add Zfbfmin extension
Hi, Feng
Any new develo
On Tue, 18 Jun 2024, Jeff Law wrote:
> This has gone through my tester. I'll wait for a verdict from pre-commit CI
> before moving forward.
Why do these "[to-be-committed]" annotations end up in the repository
though? It does not appear to me to be useful information to be stored
there forev
Updated patch. This passed bootstrap and regtesting on powerpc64le-linux
with no regressions. Ok for trunk?
Changes from v1:
1. Moved the disabling of shrink-wrapping to rs6000_emit_prologue
and beefed up comment. Used a more accurate test.
2. Added comment to the test case on wh
Thanks!
Edwin
On 6/17/2024 5:33 PM, Jeff Law wrote:
On 6/17/24 12:33 PM, Edwin Lu wrote:
When emitting insns, we have an early assertion to ensure the input
operand's mode and the expanded operand's mode are the same; however, it
does not perform this check if the pattern does not have an ex
Committed. Thanks!
Edwin
On 6/17/2024 5:31 PM, Jeff Law wrote:
On 6/17/24 12:33 PM, Edwin Lu wrote:
On rv32 targets, vwsll_zext1_scalar_ would trigger an ice in
maybe_legitimize_instruction when zero extending a uint32 to uint64 due
to a mismatch between the input operand's mode (DI) and the
On 6/18/24 3:38 PM, Segher Boessenkool wrote:
> From my viewpoint, -mrop-protect should not change code generation at
> all, except of course it has to emit some hash* insns :-)
Ideally, I agree with that. That said, the hash* insns only accept negative
offsets and the allowed range is rather lim
Binutils 2.42 and before don't support Zaamo/Zalrsc. When users specify
both Zaamo and Zalrsc, promote them to 'a' in the -march string.
This does not affect testsuite results for users with old versions of binutils.
Testcases that failed due to 'call'/isa string continue to fail after this PATCH
This patch tweaks ix86_ternlog_idx to allow any SUBREG that matches
the register_operand predicate, and is split out as an independent
piece of a patch that I have to clean-up redundant ternlog patterns
in sse.md. It turns out that some of these patterns aren't (yet)
sufficiently redundant to be
> On Mon, Jun 17, 2024 at 11:25 PM Pengxuan Zheng
> wrote:
> >
> > This patch improves GCC’s vectorization of __builtin_popcount for
> > aarch64 target by adding popcount patterns for vector modes besides
> > QImode, i.e., HImode, SImode and DImode.
> >
> > With this patch, we now generate the fol
On Tue, Jun 18, 2024 at 12:53:09PM -0500, Peter Bergner wrote:
> On 6/18/24 8:20 AM, Segher Boessenkool wrote:
> > On Mon, Jun 17, 2024 at 08:54:46PM -0500, Peter Bergner wrote:
> >> So we should be able to shrink-wrap in the presence of the ROP protection.
> [snip]
> > But do we want to? And, how
This patch improves GCC’s vectorization of __builtin_popcount for aarch64 target
by adding popcount patterns for vector modes besides QImode, i.e., HImode,
SImode and DImode.
With this patch, we now generate the following for V8HI:
cnt v1.16b, v0.16b
uaddlp v2.8h, v1.16b
For V4HI, we gen
On Fri, Feb 10, 2023 at 10:59:52AM +0800, Xionghu Luo via Gcc-patches wrote:
So, nothing here is obvious at all still. Could you please split it up
a bit more, so that every step is either small or simple?
So maybe first just split patterns to BE and LE versions, and nothing
else?
And one patch
Ajit Agarwal writes:
> Hello Richard:
>
> On 14/06/24 4:26 pm, Richard Sandiford wrote:
>> Ajit Agarwal writes:
>>> Hello Richard:
>>>
>>> All comments are addressed.
>>
>> I don't think this addresses the following comments from the previous
>> reviews:
>>
>> (1) It is not correct to mark exis
HAO CHEN GUI writes:
> Hi Richard,
>
> 在 2024/6/17 17:04, Richard Sandiford 写道:
>> I don't think we should keep the single_set condition after this change.
>> insn_cost can handle all instructions.
>
> Just tested with removing single_set condition. It causes some regressions.
> If the new_rtl is
Dear all,
the attached simple patch fixes warnings for use of uninitialized
temporaries for the string length before being defined. The cause
is obvious: type sizes were being calculated before the temporaries
were set from the descriptor for the dummy passed to the BIND(C)
procedure. Wrong code
This patch introduces a bit_optab iterator that maps IOR/XOR to bset and
binv (and one day bclr if we need it). That allows us to combine some
patterns that only differed in the RTL opcode (IOR vs XOR) and in the
name/assembly (bset vs binv).
Additionally this also allow us to use the iterato
On Tue, 18 Jun 2024 at 19:05, Stephan Bergmann wrote:
>
> On 6/3/24 22:22, Jonathan Wakely wrote:
> > Pushed to trunk now.
>
> Just a heads-up that this started to cause Clang (at least 18/19) to
> emit a -Wdeprecated-declarations now,
Yes, I saw this too.
> (There already is another such pragma
Hi!
The following patch adds on top of the just posted #embed patch
a first extension, gnu::offset which allows to seek in the data
file (for seekable files, otherwise read and throw away).
I think this is useful e.g. when some binary data start with
some well known header which shouldn't be inclu
Hi!
Here is an updated patch. It fixes one-liner in files.cc (|| instead of
&&), fixes -fdirectives-only preprocessing of #embed (it isn't 100% in the
spirit of -fdirectives-only mode, because for the tokens from
prefix/suffix/if_empty clauses it has to actually preprocess them and can't
leave th
On 6/12/24 2:50 AM, Kewen.Lin wrote:
> As the recent PR115355 shows, this issue can also affect the
> behavior when users are adopting vectorization optimization,
> IMHO we should get this landed as soon as possible.
I agree we want this fixed ASAP.
> As all said above, I believe this patch is
Hi all,
I am working paper for the following syntax extension
int a[10];
int (*a)[*] = &a;
This would not be a wide pointer, it will just initialize
the size of the type from the initializer. This would
also work for VM type. So the result is a conventional
pointer to an arrays and either a
On arm-none-eabi, 29_atomics/atomic_float/compare_exchange_padding.cc
fails to build:
FAIL: 29_atomics/atomic_float/compare_exchange_padding.cc -std=gnu++20 (test
for excess errors)
Excess errors:
/home/bauermann/.cache/builds/combined-tree-thumb-m55-hard-eabi/ld/.libs/ld-new:
cannot find -lato
On Tue, 2024-06-18 at 11:08 -0400, David Malcolm wrote:
> No functional change intended.
Sorry, it looks like I should have combined patches 6 and 7, in that
patch 6 temporarily breaks the build:
e.g.:
https://builder.sourceware.org/buildbot/#/builders/156/builds/10063
make[2]: Leaving directo
Kewen, Peter, Segher:
On 6/17/24 19:56, Kewen.Lin wrote:
> Hi,
>
> on 2024/6/18 00:08, Peter Bergner wrote:
>> On 6/14/24 1:37 PM, Carl Love wrote:
>>> Per the additional feedback after patch:
>>>
>>> commit c892525813c94b018464d5a4edc17f79186606b7
>>> Author: Carl Love
>>> Date: Tue Ju
Am Dienstag, dem 18.06.2024 um 17:27 +0200 schrieb Richard Biener:
>
> > Am 18.06.2024 um 17:20 schrieb Martin Uecker :
> >
> >
> > As discussed this replaces the use of check_qualified_type with
> > a simple check for qualifiers as suggested by Jakub in
> > c_update_type_canonical.
>
> Note a
If the address register is dead after load/store operation it looks
beneficial to use LDMIA/STMIA instead of pair of LDR/STR instructions,
at least if optimizing for size.
Changes v1 -> v2:
- switching to peephole2 approach
- added test case
gcc/ChangeLog:
* config/arm/thumb1.md (peeph
Applied the wrong patch which didn't have the final testsuite adjustment
to skip -Os on the new test. Fixed thusly.
Pushed to the trunk.
Jeff
commit cbf7245c8b305fe997a535051a4fec379a429243
Author: Jeff Law
Date: Tue Jun 18 12:10:57 2024 -0600
[committed] [RISC-V] Fix wrong patch ap
On 6/3/24 22:22, Jonathan Wakely wrote:
Pushed to trunk now.
Just a heads-up that this started to cause Clang (at least 18/19) to
emit a -Wdeprecated-declarations now,
$ cat test.cc
#include
void f(int * p1, int * p2) { std::stable_sort(p1, p2); }
$ clang++
--gcc-install-dir=/home/sber
On 6/18/24 8:20 AM, Segher Boessenkool wrote:
> On Mon, Jun 17, 2024 at 08:54:46PM -0500, Peter Bergner wrote:
>> So we should be able to shrink-wrap in the presence of the ROP protection.
[snip]
> But do we want to? And, how far, in what cases not?
My answer to the above would be "yes", "as far
On Tue, Jun 18, 2024 at 09:13:23AM +0200, Gerald Pfeifer wrote:
> The original subsite has disappeared and we couldn't find it elsewhere.
>
https://github.com/gklimowicz/FCVS
gklimowicz is a flang developer and member of J3.
--
Steve
Hello Richard:
On 14/06/24 4:26 pm, Richard Sandiford wrote:
> Ajit Agarwal writes:
>> Hello Richard:
>>
>> All comments are addressed.
>
> I don't think this addresses the following comments from the previous
> reviews:
>
> (1) It is not correct to mark existing insn uses as live-out.
> Th
Hello Richard:
All comments are addressed.
Common infrastructure using generic code for pair mem fusion of different
targets.
rs6000 target specific code implement virtual functions defined by generic code.
Target specific code are added in rs6000-mem-fusion.cc.
Bootstrapped and regtested on p
Ah that makes sense. We discussed it a bit during the patchworks
meeting - I'll drop the other changes and add it to riscv_combine_info.
Thanks,
Patrick
On 6/17/24 22:45, Kito Cheng wrote:
When 'a' is put into riscv_combine_info, 'a' will only be added into
arch string only if zaamo *AND* zalr
On Mon, Jun 17, 2024 at 11:25 PM Pengxuan Zheng wrote:
>
> This patch improves GCC’s vectorization of __builtin_popcount for aarch64
> target
> by adding popcount patterns for vector modes besides QImode, i.e., HImode,
> SImode and DImode.
>
> With this patch, we now generate the following for V8
> Am 18.06.2024 um 17:20 schrieb Martin Uecker :
>
>
> As discussed this replaces the use of check_qualified_type with
> a simple check for qualifiers as suggested by Jakub in
> c_update_type_canonical.
Note a canonical type should always be unqualified (for classical qualifiers,
not addres
As discussed this replaces the use of check_qualified_type with
a simple check for qualifiers as suggested by Jakub in
c_update_type_canonical.
Martin
Bootstrapped and regression tested on x86_64.
C23: Fix ICE related to incomplete structures [PR114930,PR115502].
The fix for PR1
Eliminate a dependency on "tree" from the code used by
diagnostic_path handling.
No functional change intended.
gcc/ChangeLog:
* Makefile.in (OBJS): Add diagnostic-macro-unwinding.o.
gcc/c-family/ChangeLog:
* c-opts.cc: Replace include of "tree-diagnostic.h" with
"diagnos
Now that nothing in tree-diagnostic-path.cc uses "tree", this patch
renames it to diagnostic-path.cc and moves it from OBJS to
OBJS-libcommon.
No functional change intended.
gcc/ChangeLog:
* Makefile.in (OBJS): Move selftest-diagnostic-path.o,
selftest-logical-location.o, and tree
This patch eliminates the use of "tree" from diagnostic_{event,path} in
favor of const logical_location *.
No functional change intended.
gcc/analyzer/ChangeLog:
* checker-event.h (checker_event::fndecl): Drop "final" and
"override", converting from a vfunc implementation to a pla
No functional change intended.
gcc/ChangeLog:
* Makefile.in (OBJS): Add selftest-diagnostic-path.o and
selftest-logical-location.o.
* logical-location.h: Include "label-text.h".
(class logical_location): Update leading comment.
* selftest-diagnostic-path.cc:
No functional change intended.
gcc/ChangeLog:
* diagnostic-format-json.cc (diagnostic_output_format_init_json):
Replace clearing of diagnostic_context::m_print_path callback with
setting the path format to DPF_NONE.
* diagnostic-format-sarif.cc
(diagnostic_o
Now that the path-handling code for json_output_format no longer
needs "tree", and thus can be in OBJS-libcommon we can move it
from tree-diagnostic-path.cc to diagnostic-format-json.cc where it
should have been all along.
No functional change intended.
gcc/ChangeLog:
* diagnostic-format-
As work towards eliminating the dependency on "tree" from
path-printing, move these classes to a new simple-diagnostic-path.h/cc.
No functional change intended.
gcc/analyzer/ChangeLog:
* checker-path.h: Include "simple-diagnostic-path.h".
gcc/ChangeLog:
* Makefile.in (OBJS): Add
This patch kit removes the dependency on "tree" from diagnostic paths,
renaming tree-diagnostic-path.cc to diagnostic-path.cc.
I have an updated prototype of libdiagnostics that uses this to support
execution paths.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Since r13-3299, build_dynamic_cast_1 calls pushdecl which calls
duplicate_decls and that in this testcase emits the "conflicting
declaration" error and returns error_mark_node, so the subsequent
build_cxx_call crashes on the err
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
-- >8 --
Here we started to ICE with r13-25: in check_trait_type, for "X[]" we
return true here:
if (kind == 1 && TREE_CODE (type) == ARRAY_TYPE && !TYPE_DOMAIN (type))
return true; // Array of unknown bound. Don't care abou
On Linux/x86_64,
c9b96a68860bfdee49d40b4a844af7c5ef69cd12 is the first bad commit
commit c9b96a68860bfdee49d40b4a844af7c5ef69cd12
Author: Martin Uecker
Date: Sat May 18 22:00:04 2024 +0200
c23: Fix for redeclared enumerator initialized with different type
[PR115109]
caused
FAIL: gcc.dg/
Thanks Richard, will commit this one and then have a try to reduce unnecessary
pattern following your suggestion.
Pan
-Original Message-
From: Richard Biener
Sent: Tuesday, June 18, 2024 7:08 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com;
jef
Thanks Richard for comments.
> we might want to consider such transform in match.pd, in this case this
> would allow to elide one of the patterns.
That makes much more sense to me, it is not good idea to have many patterns for
SAT_ADD,
will commit this first and have a try in another PATCH for t
On Mon, Jun 17, 2024 at 08:54:46PM -0500, Peter Bergner wrote:
> On 6/17/24 7:57 PM, Segher Boessenkool wrote:
> > On Mon, Jun 17, 2024 at 06:49:18PM -0500, Peter Bergner wrote:
> >> On 6/17/24 6:11 PM, Segher Boessenkool wrote:
> >> Yeah, I didn't write that, I only moved it, but I can try to come
On 6/14/24 19:59, Jonathan Wakely wrote:
On Fri, 14 Jun 2024 at 18:45, Xi Ruoyao wrote:
On Fri, 2024-06-14 at 19:37 +0200, Detlef Vollmann wrote:
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 5645e991af7..17dbae7bd87 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/c
Pushed to trunk.
-->8 --
The long long and unsigned long long types have been standard since
C++11, so are not extensions. There are also the char8_t, char16_t and
char32_t types. Just refer to the standard integer types, without saying
how many there are.
libstdc++-v3/ChangeLog:
* incl
пн, 17 июн. 2024 г. в 15:43, Richard Earnshaw (lists)
:
> I like the idea behind this patch, but I think I'd try first doing this as a
> peephole2 rule to rewrite the address in this case. That has the additional
> advantage that we then estimate the size of the instruction more accurately.
In
Hi,
I have found that this patch has introduced a regression in the arm-none-eabi
toolchain for a testcase in the libstdc++ testsuite, which was previously
passing:
FAIL: 27_io/basic_istream/ignore/char/94749.cc execution test
The toolchain was built with:
Build = x86_64-none-linux-gnu
Host =
The condition rejecting "multiple-type" SLP condition reduction lacks
handling EXTRACT_LAST reductions.
Bootstrap and regtest in progress on x86_64-unknown-linux-gnu.
Richard.
PR tree-optimization/115537
* tree-vect-loop.cc (vectorizable_reduction): Also reject
SLP condit
Hi all,
Pushing to trunk.
Thanks,
Kyrill
Signed-off-by: Kyrylo Tkachov
* MAINTAINERS (aarch64 port): Update my email address.
(DCO section): Likewise.
maintainers.patch
Description: maintainers.patch
On Tue, 11 Jun 2024, Hu, Lin1 wrote:
> I wrap a part of code about indirect conversion. The API refers to
> supportable_narrowing/widening_operations.
Sorry for the delay - comments inline.
> BRs,
> Lin
>
> gcc/ChangeLog:
>
> PR target/107432
> * tree-vect-generic.cc
> (expa
On Mon, Jun 17, 2024 at 11:55 AM Richard Sandiford
wrote:
>
> This series expands on the fix for PR115464 by using force_subreg
> in more places. It also adds some convenience wrappers for lowpart
> and highpart subregs.
>
> A part of this will need to be backported after a grace period,
> but I'
On Mon, Jun 17, 2024 at 9:07 AM wrote:
>
> From: Pan Li
>
> We missed one match pattern for the unsigned scalar .SAT_SUB, aka
> form 11.
>
> Form 11:
> #define SAT_SUB_U_11(T) \
> T sat_sub_u_11_##T (T x, T y) \
> { \
> T ret; \
> bool overflow = __builtin_sub_overflow (x, y, &ret)
On Mon, Jun 17, 2024 at 3:41 AM wrote:
>
> From: Pan Li
>
> When investigate the vectorization of .SAT_ADD, we notice there
> are additional 2 forms, aka form 7 and 8 for .SAT_ADD.
>
> Form 7:
> #define DEF_SAT_U_ADD_FMT_7(T) \
> T __attribute__((noinline)) \
> sat_u_
On Tue, Jun 18, 2024 at 10:35 AM Sam James wrote:
>
> YunQiang Su writes:
>
> > OK for trunk?
>
> It looks good to me, but I can't approve. (I'd dare say it's obvious,
> even.)
>
> Richard, any chance you could give it a quick ack?
OK
Hi, Feng
Any new developments here on zvfbfmin and zvfbfwma?
BR,
Jin
--
From:Fei Gao
Send Time:2024 Jun. 7 (Fri.) 17:34
To:jinma; "gcc-patches";
zengxiao; wangfeng
Cc:jeffreyalaw; Kito Cheng;
"juzhe.zhong"; "j
On 2024/6/6 9:41 PM, Chung-Lin Tang wrote:
> This is v2 of the C/C++/middle-end parts of array/struct
> support for OpenACC reductions.
>
> The main changes are much fixed support for sub-arrays,
> and some new testcases.
>
> Tested on mainline using x86_64 host and nvptx/amdgcn offloading.
> Wil
On Thu, 13 Jun 2024, Maciej W. Rozycki wrote:
> > Maciej, would you be so kind as to give it a spin with a native
> > regstrap? TIA,
>
> I will certainly run regression-testing once the job I started yesterday
> has finished with my Alpha system, which should be fairly soon as it's
> already
We suffer from an inconsistency in the names of uninstalled gnattools
executables in cross-compiler configurations. The cause is a recipe we
have:
ada.all.cross:
for tool in $(ADA_TOOLS) ; do \
if [ -f $$tool$(exeext) ] ; \
then \
$(MV) $$tool$(exeext) $$
Hi,
Having rebuilt GCC with no changes relevant to Ada I saw all the gnat
tests fail all of a sudden. Upon a closer inspection I have noticed that
in the earlier build where tests passed `gnatmake' was invoked (in an
`alpha-linux-gnu' cross-compiler build) as:
/path/to/alpha-linux/obj/gcc/gc
Hi Richard,
在 2024/6/17 17:04, Richard Sandiford 写道:
> I don't think we should keep the single_set condition after this change.
> insn_cost can handle all instructions.
Just tested with removing single_set condition. It causes some regressions.
If the new_rtl is a debug insn, it still can do the
On most uarch, the cost condmove is same as other noraml integer,
and it should be COSTS_N_INSNS(1).
In GCC12 or previous, the condmove is always enabled, and from
GCC13, we start to compare the cost.
The generic rtx_cost give the result of COSTS_N_INSN(2).
Let's define it to COSTS_N_INSN(1) in m
Am 18.06.24 um 00:06 schrieb Gerald Pfeifer:
On Sat, 15 Jun 2024, Georg-Johann Lay wrote:
Applied this one:
Cool.
+SimulAVR at https://www.nongnu.org/simulavr";
This one gives a http response of "301 Moved Permanently" redirecting to
https://www.nongnu.org/simulavr/ . I'll fix this
YunQiang Su writes:
> OK for trunk?
It looks good to me, but I can't approve. (I'd dare say it's obvious,
even.)
Richard, any chance you could give it a quick ack?
From: Pan Li
After the middle-end support the form 12 of unsigned SAT_SUB and
the RISC-V backend implement the SAT_SUB for vector mode, add
more test case to cover the form 12.
Form 12:
#define DEF_SAT_U_SUB_FMT_12(T)\
T __attribute__((noinline))
On Tue, 22 Mar 2022, Pokechu22 via Gcc-patches wrote:
> htdocs/codingconventions.html | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Thank you for this patch, and apologies it fell through the cracks.
Applying your patch I found that I independently had discovered and fixed
the f
1 - 100 of 109 matches
Mail list logo
