Hi!
The following patch changes the memcpy etc. folding to use bitwise vector
types rather than huge INTEGER_TYPEs for copying of > MAX_FIXED_MODE_SIZE
lengths. The problem with the huge INTEGER_TYPEs is that they aren't
supported very much, usually there are just optabs to handle moves of
On Tue, Feb 27, 2024 at 10:20 PM Robert Dubner wrote:
>
> Richard,
>
> Thank you very much for your comments.
>
> When I set out to create the capability, I had a "specification" in mind.
>
> I didn't have a clue how to create a GENERIC tree that could be fed to the
> middle end in a way that
Oh, I see, that indicates simply convert this option value to
riscv_vector_chunks is not good enough here.
I thought the term zvl* indicates the minimal vector length(somehow similar to
the concept of scalable)
in previous, which is mentioned in the RVV 1.0 spec if my memory is correct.
Looks
Harald,
Jerry helped me figure out my editor settings so that I could fix
whitespace and formatting issues in my code. With my editor configured
correctly, I saw that my code was not conforming to coding standards
as I previously thought it was. I have fixed those things and updated
my patch.
Keep SCALABLE, since it has different semantics with ZVL:
-mrvv-vector-bits=scalble means zvl*b specify the minimal VLEN
-mrvv-vector-bits=zvl means zvl*b specify the exactly VLEN
What's difference exactly?
-mrvv-vector-bits=scalble with zvl128b can run on any machine with VLEN >= 128
> if (!targetm.modes_tieable_p (src_int_mode, src_mode))
> return NULL_RTX;
> if (!targetm.modes_tieable_p (int_mode, mode))
> return NULL_RTX;
Yes, will return NULL_RTX for in the first if, given src_int_mode is E_DImode
while src_mode is
E_V2SFmode and mode is E_V4QImode. The
From: Pan Li
This patch would like to introduce one new gcc option for RVV. To
appoint the bits size of one RVV vector register. Valid arguments to
'-mrvv-vector-bits=' are:
* zvl
The zvl will pick up the zvl*b from the march option. For example,
the mrvv-vector-bits will be 1024 when
On Tue, Feb 27, 2024 at 11:59:46AM -0500, Patrick Palka wrote:
> On Fri, 16 Feb 2024, Nathaniel Shead wrote:
>
> > On Tue, Feb 13, 2024 at 07:52:01PM -0500, Jason Merrill wrote:
> > > On 2/10/24 17:57, Nathaniel Shead wrote:
> > > > The fix for PR107398 weakened the restrictions that lambdas must
On 2/27/24 1:00 PM, Harald Anlauf wrote:
Dear all,
the attached patch fixes invalid Fortran in testcase
gfortran.dg/pr101026.f, which might prohibit progress
in fixing pr111781. (Note that the testcase was for a
tree-optimizer issue, not the Fortran frontend.)
OK for mainline?
Will commit
> -Original Message-
> Friday, February 23, 2024 6:16 PM
> Richard Sandiford wrote:
>
> > +
> > +#undef TARGET_SEH
> > +#define TARGET_SEH 0
> > +
> > +#define SSE_REGNO_P(N) 0
> > +#define GENERAL_REGNO_P(N) 0
>
> Could you add a comment to explain how these two macros are consumed?
>
> Pan, can you confirm what path we take through extract_low_bits?
Thanks Jeff for comments, will have a try soon and keep you posted.
Pan
-Original Message-
From: Jeff Law
Sent: Tuesday, February 27, 2024 11:03 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai;
Add proper hints for implicit declaration of strerror.
The results could be confusing depending on the other included headers.
These example messages are from compiling a trivial program to print the
string for an errno value. It only includes stdio.h (cstdio for C++).
Before:
$
On Tue, Feb 27, 2024 at 1:18 PM Evgeny Karpov
wrote:
>
> SEH is not implemented yet and needs to be disabled in mingw/winnt.cc.
> Disabling every SEH function that uses references to these macros might
> trigger significant refactoring, and to avoid this, required macros are
> defined with 0.
All,
Consider,
! { dg-do run }
program foo
implicit none
real y
associate (x => log(cmplx(-1,0)))
y = x%im
if (int(100*y)-314 /= 0) stop 1
end associate
end program
% gfcx -c a.f90
a.f90:6:13:
6 | y = x%im
| 1
Error: Symbol 'x' at (1) has no
On Tue, 27 Feb 2024 15:53:19 PST (-0800), jeffreya...@gmail.com wrote:
On 2/27/24 15:56, 钟居哲 wrote:
>> I don't think it's that simple. On some uarchs vsetvls are nearly free
while on others they can be fairly expensive. It's not clear (to me)
yet if one approach or the other is going to
Hello-
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641247.html
There was a request on the PR
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755#c5) for me to ping
this again, so I am complying :). Might anyone have a minute to take a
look please? Thanks...
-Lewis
On Thu, Jan 11,
On 2/27/24 15:56, 钟居哲 wrote:
>> I don't think it's that simple. On some uarchs vsetvls are nearly free
while on others they can be fairly expensive. It's not clear (to me)
yet if one approach or the other is going to be the more common.
That's uarch dependent which is not the stuff I am
>> I don't think it's that simple. On some uarchs vsetvls are nearly free
>>while on others they can be fairly expensive. It's not clear (to me)
>>yet if one approach or the other is going to be the more common.
That's uarch dependent which is not the stuff I am talking about.
What's I want to
On 2/27/24 6:40 AM, Segher Boessenkool wrote:
> On Tue, Feb 27, 2024 at 02:02:38AM +0530, jeevitha wrote:
>> There is no immediate value splatting instruction in Power. Currently, those
>> values need to be stored in a register or memory. To address this issue, I
>> have updated the predicate for
On e.g. gcc211 the use of "%li" with unsigned HOST_WIDE_INT led to this warning:
../../src/gcc/analyzer/access-diagram.cc: In member function ‘void
ana::string_literal_spatial_item::add_column_for_byte(text_art::table&, const
ana::bit_to_table_map&, text_art::style_manager&, ana::byte_offset_t,
On Tue, 27 Feb 2024, Tobias Burnus wrote:
> Minor update for older and more recent changes.
> supported for stack variables in C and Fortran, including the OpenMP 5.1
> - align modifier. For Fortran, OpenMP allocators can now be
> + align modifier. In C and C++, the map clause
>
> This patch looks odd to me.
> I don't see memrefs in the trunk code.
It's on top of the vle/vse offset handling patch from
a while back that I haven't committed yet.
> Also, I prefer list all cost in cost tune info for NF = 2 ~ 8 like ARM SVE
> does:
I don't mind having separate costs for
Hi Cupertino,
On 2/27/24 11:04, Cupertino Miranda wrote:
> Kernel verifier complains in some particular cases for missing func_info
> implementation in .BTF.ext. This patch implements it.
>
> Strings are cached locally in coreout.cc to avoid adding duplicated
> strings in the string list. This
From: Fangrui Song
ChangeLog:
* MAINTAINERS: Add myself.
Signed-off-by: Fangrui Song
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 986e8d0a725..b01fab16061 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -669,6 +669,7 @@ Edward
Richard,
Thank you very much for your comments.
When I set out to create the capability, I had a "specification" in mind.
I didn't have a clue how to create a GENERIC tree that could be fed to the
middle end in a way that would successfully result in an executable. And I
needed to be able to
SEH is not implemented yet and needs to be disabled in mingw/winnt.cc.
Disabling every SEH function that uses references to these macros might trigger
significant refactoring, and to avoid this, required macros are defined with 0.
It is needed only for compilation. A comment with an explanation
Dear all,
the attached patch fixes invalid Fortran in testcase
gfortran.dg/pr101026.f, which might prohibit progress
in fixing pr111781. (Note that the testcase was for a
tree-optimizer issue, not the Fortran frontend.)
OK for mainline?
Will commit within 24h unless there are comments.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk and perhaps 13?
-- >8 --
In r12-6773-g09845ad7569bac we gave CTAD placeholders a level of 0 and
ensured we never replaced them via tsubst. It turns out that autos
representing an explicit cast need the same treatment
Richard, thank you for the initial review! Hopefully, the required actions have
been addressed, which should improve the patch quality in v2.
Regards,
Evgeny
-Original Message-
Thursday, February 22, 2024 2:40 PM
Richard Earnshaw (lists) wrote:
Thanks for posting this.
I've only read
On 2/27/24 8:25 AM, Jeff Law wrote:
On 2/25/24 21:53, Greg McGary wrote:
Add option -m(no-)autovec-segment to enable/disable autovectorizer
from emitting vector segment load/store instructions. This is useful for
performance experiments.
gcc/ChangeLog:
* config/riscv/autovec.md
On 2/27/24 11:04, Cupertino Miranda wrote:
> gcc/ChangeLog:
>
> * config.gcc (target_gtfiles): Changes coreout to btfext-out.
> (extra_objs): Changes coreout to btfext-out.
> * config/bpf/coreout.cc: Renamed to btfext-out.cc.
> * config/bpf/btfext-out.cc: Added.
> *
On 2/27/24 11:04, Cupertino Miranda wrote:
> BPF applications, when generating BTF information should always create a
> .BTF.ext section.
> Current implementation was only creating it when -mco-re option was used.
> This patch makes .BTF.ext always be generated for BPF target objects.
> The
Hi Cupertino,
Similar to patch 1, please use present tense to match the style of
existing commits, in commit message and in ChangeLog.
On 2/27/24 11:04, Cupertino Miranda wrote:
> Added a traversal function to traverse all BTF_KIND_FUNC nodes with a
> callback function. Used for .BTF.ext section
@xref{Cygwin and MinGW Options} re-direct from "x86 Windows Options" will be
added in v2. Thanks!
Regards,
Evgeny
-Original Message-
Thursday, February 22, 2024 2:32 PM
Richard Earnshaw (lists) wrote:
For this change you might want to put some form of re-direct in the manual
under
Hi Cupertino,
Just some nits below. Apologies for incoming pedantry.
On 2/27/24 11:04, Cupertino Miranda wrote:
> This patch correct the aditition of +1 on the type id, which originally
> was done in the wrong location and leaded to func_sts->dtd_type for
> BTF_KIND_FUNCS struct data to contain
Minor update for older and more recent changes.
Comments?
Tobias
gcc-14/changes.html + projects/gomp/: OpenMP + OpenACC update
Update OpenMP for two meanwhile implemented features (lvalue-expr in map,
indirect now also in Fortran).
Update OpenACC for one new feature (Fortran interface to
gcc/ChangeLog:
* config.gcc (target_gtfiles): Changes coreout to btfext-out.
(extra_objs): Changes coreout to btfext-out.
* config/bpf/coreout.cc: Renamed to btfext-out.cc.
* config/bpf/btfext-out.cc: Added.
* config/bpf/coreout.h: Renamed to btfext-out.h.
Kernel verifier complains in some particular cases for missing func_info
implementation in .BTF.ext. This patch implements it.
Strings are cached locally in coreout.cc to avoid adding duplicated
strings in the string list. This string deduplication should eventually
be moved to the CTFC functions
BPF applications, when generating BTF information should always create a
.BTF.ext section.
Current implementation was only creating it when -mco-re option was used.
This patch makes .BTF.ext always be generated for BPF target objects.
The patch also adds conditions around btf_finalize function
Added a traversal function to traverse all BTF_KIND_FUNC nodes with a
callback function. Used for .BTF.ext section content creation.
gcc/ChangeLog:
* btfout.cc (output_btf_func_types): Use FOR_EACH_VEC_ELT.
(traverse_btf_func_types): Defined function.
* ctfc.h
Hi everyone,
Just an updated version of the patches based on recent reviews from
David Faust.
Thanks for the feedback.
Regards,
Cupertino
This patch correct the aditition of +1 on the type id, which originally
was done in the wrong location and leaded to func_sts->dtd_type for
BTF_KIND_FUNCS struct data to contain the type id of the previous entry.
gcc/ChangeLog:
* btfout.cc (btf_collect_dataset): Corrected BTF type id.
On Mon, 26 Feb 2024, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this approach
> look reasonable?
>
> -- >8 --
>
> One known missing piece in the modules implementation is merging of a
> streamed-in local class with the corresponding in-TU version of the
>
On Tue, 27 Feb 2024 at 15:21, Tim Song wrote:
>
> [print.fun] requires a system_error, but I don't think
> [ostream.formatted.print] does?
Yeah it looks like I got confused (again) jumping back and forth
between [print.fun] and [ostream.formatted.print]. So we're doing the
right thing, and
On Fri, 16 Feb 2024, Patrick Palka wrote:
> On Thu, 15 Feb 2024, Patrick Palka wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk?
> >
> > -- >8 --
> >
> > One would expect consecutive calls to bytes_in/out::b for streaming
> > adjacent bits, as we
On Thu, 15 Feb 2024, Patrick Palka wrote:
> On Thu, 15 Feb 2024, Jason Merrill wrote:
>
> > On 2/15/24 16:10, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> > > -- >8 --
> > >
> > > Issuing a hard error when the GMF
On Tue, Feb 27, 2024 at 06:25:21PM +0100, Jakub Jelinek wrote:
> I guess we need some testsuite coverage for caller/callee ABI match of
> struct S { char p[64]; };
> struct S foo (...);
Maybe the test below? Passes on x86_64 -m32/-m64, but I guess that doesn't
care at all about the named vs. not
Also handle V2BF mode.
PR target/113871
gcc/ChangeLog:
* config/i386/mmx.md (V248FI): Add V2BF mode.
(V24FI_32): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr113871-5a.c: New test.
* gcc.target/i386/pr113871-5b.c: New test.
Bootstrapped and regression tested on
On Tue, Feb 27, 2024 at 04:41:32PM +, Richard Earnshaw wrote:
> > 2023-01-09 Jakub Jelinek
> >
> > PR target/107453
> > * calls.cc (expand_call): For calls with
> > TYPE_NO_NAMED_ARGS_STDARG_P (funtype) use zero for n_named_args.
> > Formatting fix.
>
> This one has been
[resending, apologies, I accidentally CC'd the wrong person last time]
On 27/02/2024 16:41, Richard Earnshaw wrote:
>
>
> On 09/01/2023 10:32, Jakub Jelinek via Gcc-patches wrote:
>> Hi!
>>
>> On powerpc64le-linux, the following patch fixes
>> -FAIL: gcc.dg/c2x-stdarg-4.c execution test
>>
On Fri, 16 Feb 2024, Nathaniel Shead wrote:
> On Tue, Feb 13, 2024 at 07:52:01PM -0500, Jason Merrill wrote:
> > On 2/10/24 17:57, Nathaniel Shead wrote:
> > > The fix for PR107398 weakened the restrictions that lambdas must belong
> > > to namespace scope. However this was not sufficient: we
On 09/01/2023 10:32, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> On powerpc64le-linux, the following patch fixes
> -FAIL: gcc.dg/c2x-stdarg-4.c execution test
> -FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O0 execution test
> -FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O1 execution
The gcov function summaries only output the covered lines, not the
branches and calls. Since the function summaries is an opt-in it
probably makes sense to also include branch coverage. Simply adds the
branch- and call information to the function-summaries output.
$ gcc --coverage hello.c -o
This patch adds IFN_ARG_PARTS, and generate this IFN for parameters access
in fsra pass. And this IFN is expanded according to the incoming registers
of the parameter. "fsra" is tunned for the access of parameters.
PR target/108073
gcc/ChangeLog:
* internal-fn.cc
On 2/26/24 5:17 PM, Greg McGary wrote:
diff --git a/gcc/testsuite/gcc.c-torture/execute/pr113010.c
b/gcc/testsuite/gcc.c-torture/execute/pr113010.c
new file mode 100644
index 000..a95c613c1df
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr113010.c
@@ -0,0 +1,9 @@
+int
On 2/25/24 21:53, Greg McGary wrote:
Add option -m(no-)autovec-segment to enable/disable autovectorizer
from emitting vector segment load/store instructions. This is useful for
performance experiments.
gcc/ChangeLog:
* config/riscv/autovec.md (vec_mask_len_load_lanes,
On 2/26/24 18:21, juzhe.zh...@rivai.ai wrote:
If the scheduling model increases the vsetvls, we shouldn't set it as
default scheduling model
I don't think it's that simple. On some uarchs vsetvls are nearly free
while on others they can be fairly expensive. It's not clear (to me)
yet if
[print.fun] requires a system_error, but I don't think
[ostream.formatted.print] does?
On Tue, Feb 27, 2024 at 5:47 AM Jonathan Wakely wrote:
> Tested x86_64-linux. Reviews invited.
>
> -- >8 --
>
> The standard requires an exception if std::print fails to write to a
> std::ostream.
>
>
On 2/26/24 20:12, Tom Tromey wrote:
While working on another patch, I discovered that the libcc1 plugin
code never did version negotiation correctly. So, the patches to
introduce v1 never did anything -- the new code, as far as I know, has
never been run.
Making version negotiation work
On 2/26/24 07:22, pan2...@intel.com wrote:
From: Pan Li
We allowed vector type for get_stored_val when read is less than or
equal to store in previous. Unfortunately, we missed to adjust the
validate_subreg part accordingly. When the vector type's size is
less than vector register, it
On Tue, Feb 27, 2024 at 01:09:09PM +0100, Jakub Jelinek wrote:
> So, IMHO either revert the changes altogether, or guard on -mcmodel=kernel
> (but talk to kernel people on linux-toolchains if that is what they actually
> want).
Here is a patch which guards this by non-default option, so kernel
Ooops, I forgot to add --no-numbered so these were eight unrelated
patches, not PATCH 1/8 .. PATCH 8/8. Sorry for any confusion.
On Tue, 27 Feb 2024 at 14:33, Jonathan Wakely wrote:
>
> On Tue, 27 Feb 2024 at 11:49, Jonathan Wakely wrote:
> >
> > Tested x86_64-linux. I think we should make this
Thanks Richard and Tammer for moving this forward.
> That said, I would like to see the bigger picture to be kept in mind
> before altering the GIMPLE IL.
> Adding an internal function for an already present optab is a
> no-brainer. Adding a vectorizer
> and/or if-conversion pattern to make use
On Tue, 27 Feb 2024 at 11:49, Jonathan Wakely wrote:
>
> Tested x86_64-linux. I think we should make this change, because
> otherwise we define the typedefs for platforms with no lock-free
> atomics, like hppa-hpux. Instead of lying, those typedefs should be
> absent on that target.
>
> -- >8 --
On Tue, 27 Feb 2024, Jeff Law wrote:
>
>
> On 2/27/24 06:53, Richard Biener wrote:
> > On Tue, 27 Feb 2024, Jeff Law wrote:
> >
> >>
> >>
> >> On 2/27/24 00:43, Richard Biener wrote:
> >>> On Tue, 27 Feb 2024, haochen.jiang wrote:
> >>>
> On Linux/x86_64,
>
>
On 2/27/24 06:53, Richard Biener wrote:
On Tue, 27 Feb 2024, Jeff Law wrote:
On 2/27/24 00:43, Richard Biener wrote:
On Tue, 27 Feb 2024, haochen.jiang wrote:
On Linux/x86_64,
af66ad89e8169f44db723813662917cf4cbb78fc is the first bad commit
commit
This patch adds support for MVE Tail-Predicated Low Overhead Loops by using the
doloop funcitonality added to support predicated vectorized hardware loops.
gcc/ChangeLog:
* config/arm/arm-protos.h (arm_target_bb_ok_for_lob): Change
declaration to pass basic_block.
This patch adds support in the target agnostic doloop pass for the detection of
predicated vectorized hardware loops. Arm is currently the only target that
will make use of this feature.
gcc/ChangeLog:
* df-core.cc (df_bb_regno_only_def_find): New helper function.
* df.h
This patch adds an attribute to the mve md patterns to be able to identify
predicable MVE instructions and what their predicated and unpredicated variants
are. This attribute is used to encode the icode of the unpredicated variant of
an instruction in its predicated variant.
This will make it
This patch annotates some MVE across lane instructions with a new attribute.
We use this attribute to let the compiler know that these instructions can be
safely implicitly predicated when tail predicating if their operands are
guaranteed to have zeroed tail predicated lanes. These instructions
This patch fixes the erroneous use of a mode attribute without a mode iterator
in the pattern and removes unused unspecs and iterators.
gcc/ChangeLog:
* config/arm/iterators.md (supf): Remove VMLALDAVXQ_U, VMLALDAVXQ_P_U,
VMLALDAVAXQ_U cases.
(VMLALDAVXQ): Remove
Hi,
Re-ordered patches, our latest plan is to only commit patches 1-3, and leave
4-5 for GCC 15, as we believe it is too late in Stage 4 to be making changes to
target agnostic parts, especially since these affect so many ports that we can
not easily test.
[1/5] arm: Add define_attr to to create
On Tue, 27 Feb 2024, Jeff Law wrote:
>
>
> On 2/27/24 00:43, Richard Biener wrote:
> > On Tue, 27 Feb 2024, haochen.jiang wrote:
> >
> >> On Linux/x86_64,
> >>
> >> af66ad89e8169f44db723813662917cf4cbb78fc is the first bad commit
> >> commit af66ad89e8169f44db723813662917cf4cbb78fc
> >>
Hi Tobias!
On 2024-02-27T13:29:33+0100, Tobias Burnus wrote:
> Thomas Schwinge:
>>> @table @asis
>>> @item @emph{Description}
>>> -This function allocates @var{len} bytes of device memory. It returns
>>> +This function allocates @var{bytes} of device memory. It returns
>> Not '@var{bytes}
On Tue, Feb 27, 2024 at 1:57 PM Tamar Christina wrote:
>
> > Thanks Tamar.
> >
> > > Those two cases also *completely* stop vectorization because of either the
> > > control flow or the fact the vectorizer can't handle complex types.
> >
> > Yes, we eventually would like to vectorize the SAT ALU
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-9195-g43ad6ce60108ac.
gcc/analyzer/ChangeLog:
PR analyzer/111881
* constraint-manager.cc (bound::ensure_closed): Assert that
Hey,
Dropped the first patch and dealt with the comments above, hopefully I
didn't miss any this time.
--
This patch adds support for C23's _BitInt for the AArch64 port when
compiling
for little endianness. Big Endianness requires further target-agnostic
On Tue, Feb 27, 2024 at 1:50 PM Eric Botcazou wrote:
>
> Hi,
>
> this is a regression present on the mainline, 13 and 12 branches. For the
> attached Ada case, it's a tree checking failure on the mainline at -O:
>
> +===GNAT BUG DETECTED==+
> |
On 2/27/24 00:43, Richard Biener wrote:
On Tue, 27 Feb 2024, haochen.jiang wrote:
On Linux/x86_64,
af66ad89e8169f44db723813662917cf4cbb78fc is the first bad commit
commit af66ad89e8169f44db723813662917cf4cbb78fc
Author: Richard Biener
Date: Fri Feb 23 16:06:05 2024 +0100
Ping
On 08/01/24 11:19 am, Surya Kumari Jangala wrote:
> Ping
>
> On 28/11/23 6:24 pm, Surya Kumari Jangala wrote:
>> Ping
>>
>> On 10/11/23 12:27 pm, Surya Kumari Jangala wrote:
>>> Ping
>>>
>>> On 03/11/23 1:14 pm, Surya Kumari Jangala wrote:
Hi Segher,
I have incorporated changes in
> Thanks Tamar.
>
> > Those two cases also *completely* stop vectorization because of either the
> > control flow or the fact the vectorizer can't handle complex types.
>
> Yes, we eventually would like to vectorize the SAT ALU but we start with
> scalar part
> first.
> I tried the
Hi,
this is a regression present on the mainline, 13 and 12 branches. For the
attached Ada case, it's a tree checking failure on the mainline at -O:
+===GNAT BUG DETECTED==+
| 14.0.1 20240226 (experimental) [master r14-9171-g4972f97a265] GCC
Thanks Tamar.
> Those two cases also *completely* stop vectorization because of either the
> control flow or the fact the vectorizer can't handle complex types.
Yes, we eventually would like to vectorize the SAT ALU but we start with scalar
part first.
I tried the
Hi!
On Tue, Feb 27, 2024 at 02:02:38AM +0530, jeevitha wrote:
> There is no immediate value splatting instruction in Power. Currently, those
> values need to be stored in a register or memory. To address this issue, I
> have updated the predicate for the second operand in vsx_splat to
>
Hi,
As known there are a few PRs (meta-bug PR101926) about
accessing aggregate param/returns which are passed through registers.
Given the suggestion from:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637935.html:
We could even use the actual SRA pass in a special mode right before
Hi Thomas,
(Regarding 'call acc_attach(x)' – the problem is that one needs the
address of '' and 'x'; while 'x' is readily available, for '' no
temporary variable has to get involved – and there are plenty of ways
temporaries can get introduced; for most cases, an interface exists that
On Tue, Feb 27, 2024 at 10:13:14AM +0100, Jakub Jelinek wrote:
> For __libc_start_main, glibc surely just could use no_callee_saved_registers
> attribute, because that is typically the outermost frame in backtrace,
> there is no need to save those there.
> And for kernel if it really wants it and
Am 27.02.24 um 12:15 schrieb Tamar Christina:
Am 19.02.24 um 08:36 schrieb Richard Biener:
On Sat, Feb 17, 2024 at 11:30 AM wrote:
From: Pan Li
This patch would like to add the middle-end presentation for the
unsigned saturation add. Aka set the result of add to the max
when overflow.
This patch adds IFN_SET_RET_PARTS, and generate this IFN for the accesses of
the 'returns' in fsra pass. And the IFN is expanded according to the outgoing
registers of the 'return'. "fsra" is tunned for the access analyze for
'returns'.
'IFN_SET_RET_LAST_PARTS' is just for this prototype, it
Tested x86_64-linux. I think we should make this change, because
otherwise we define the typedefs for platforms with no lock-free
atomics, like hppa-hpux. Instead of lying, those typedefs should be
absent on that target.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/114103
*
This patch adds a new mode for sra pass: "fsra".
This 'fsra' pass handle function parameters and returns as candidates.
And run it at the end of GIMPLE passes sequences.
gcc/ChangeLog:
* passes.def: Add pass pass_sra_final.
* tree-pass.h (make_pass_sra_final): Declare
Tested x86_64-linux. I am unable to test this on Cygwin myself. Testing
and reviews invited.
-- >8 --
Cygwin should use std::fwrite, not WriteConsoleW. And the -lstdc++exp
library is only needed when running the tests on *-*-mingw*.
libstdc++-v3/ChangeLog:
* include/std/ostream
Tested x86_64-linux. Reviews invited.
-- >8 --
The bitwise operators for combining bitmask types such as std::launch
are not consistently annotated with noexcept, constexpr, and nodiscard.
This is the subject of LWG 3977, although the proposed resolution
doesn't work. We can make the changes in
Tested x86_64-linux. Reviews invited.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/stl_bvector.h (vector::at): Add
nodiscard.
* include/bits/stl_vector.h (vector::at): Likewise.
(operator==, operator<=>, operator<, operator!=, operator>)
(operator<=,
Tested x86_64-linux. Reviews invited.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/stl_algo.h:
* testsuite/25_algorithms/unique/1.cc: Add dg-warning.
* testsuite/25_algorithms/unique/11480.cc: Likewise.
* testsuite/25_algorithms/unique_copy/26133.cc: Likewise.
Tested x86_64-linux. Reviews invited.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/stacktrace: Add nodiscard attribute to all
functions without side effects.
---
libstdc++-v3/include/std/stacktrace | 36 +
1 file changed, 31 insertions(+), 5
Tested x86_64-linux. Reviews invited.
-- >8 --
The standard requires an exception if std::print fails to write to a
std::ostream.
libstdc++-v3/ChangeLog:
* include/std/ostream (vprint_nonunicode): Throw if stream state
indicates writing failed.
*
Tested x86_64-linux. Reviews invited.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/alloc_traits.h: Include for
__make_move_if_noexcept_iterator.
---
libstdc++-v3/include/bits/alloc_traits.h | 3 +++
1 file changed, 3 insertions(+)
diff --git
Hi Tobias!
On 2024-02-19T22:36:51+0100, Tobias Burnus wrote:
> While waiting for some testing to finish, I got distracted and added the
> very low hanging OpenACC 3.3 fruits, i.e. those Fortran routines that directly
> map to their C counter part.
>
> Comments, remarks?
Thanks, that largely
> Am 19.02.24 um 08:36 schrieb Richard Biener:
> > On Sat, Feb 17, 2024 at 11:30 AM wrote:
> >>
> >> From: Pan Li
> >>
> >> This patch would like to add the middle-end presentation for the
> >> unsigned saturation add. Aka set the result of add to the max
> >> when overflow. It will take the
1 - 100 of 121 matches
Mail list logo
