When enabling XTheadFmv/Zfa and XThead(F)MemIdx, we might end up
with the following insn (registers are examples, but of correct class):
(set (reg:DF a4)
(mem:DF (plus:SI (mult:SI (reg:SI a0)
(const_int 8))
(reg:SI a5
This is a result
We have a huge amount of optimization patterns (insn_and_split) for
XTheadMemIdx and XTheadFMemIdx that attempt to do something, that can be
done more efficient by generic GCC passes, if we have proper support code.
A key function in eliminating the optimization patterns is
th_memidx_classify_addr
Test file xtheadfmemidx-medany.c has been added in b79cd204c780 as a
test case that provoked an ICE when loading DFmode registers via two
SImode register loads followed by a SI->DF[63:32] move from XTheadFmv.
Since Zfa is affected in the same way as XTheadFmv, even if both
have slightly different i
Xi Ruoyao writes:
> The check was implemented incorrectly, so vec_widen_smult_{even,odd}_M
> was never used. This is not good for targets with native even/odd
> widening multiplication but not lo/hi multiplication.
>
> The fix is actually developed by Richard Biener.
Please use Co-authored-by f
Philipp Tomsich writes:
Hi,
> Sam, Jakub & Robin,
>
> We had an "OK for trunk" from Jeff for v4 (see
> https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656907.html) and
> it has been two more weeks for this RESEND.
> I'll push this by end of this week unless I hear otherwise.
I'd ping Jeff f
The check was implemented incorrectly, so vec_widen_smult_{even,odd}_M
was never used. This is not good for targets with native even/odd
widening multiplication but not lo/hi multiplication.
The fix is actually developed by Richard Biener.
gcc/ChangeLog:
PR tree-optimization/116142
On Tue, 6 Aug 2024, Alexander Monakov wrote:
> --- a/libcpp/files.cc
> +++ b/libcpp/files.cc
[...]
> + pad = HAVE_AVX2 ? 32 : 16;
This should have been
#ifdef HAVE_AVX2
pad = 32;
#else
pad = 16;
#endif
Alexander
MAINTAINERS: Change my contact email in MAINTAINERS file.
* MAINTAINERS: Changing my email to gnu email.
Best wishes,
Navid.
0001-MAINTAINERS-Change-my-contact-email-in-MAINTAINERS-f.patch
Description: Binary data
在 2024/8/5 23:16, Jeff Law 写道:
On 7/15/24 10:08 PM, Jiawei wrote:
在 2024/07/16 8:28, Jeff Law 写道:
IIRC these fails are dependent upon whether or not the statements
turn into vector stores or not.
So to remove the xfail don't you have to know if vector is enabled/
disabled?
I am not s
> On 6 Aug 2024, at 4:14 PM, Richard Sandiford
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Kyrylo Tkachov writes:
>>> On 5 Aug 2024, at 18:00, Richard Sandiford
>>> wrote:
>>>
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> Kyryl
2024-08-07 11:13 Xiao Zeng wrote:
The existing test cases 'gcc.dg/portal/float16 complex.c' for gcc are
already good, so no new test cases were added.
Of course, more test cases are always good, and if necessary, I will
supplement the test cases.
>
>gcc/ChangeLog:
>
> * builtin-types.def
gcc/ChangeLog:
* builtin-types.def (BT_COMPLEX_BFLOAT16): Support BF16 node.
(BT_BFLOAT16_PTR): Ditto.
(BT_FN_BFLOAT16): New.
(BT_FN_BFLOAT16_BFLOAT16): Ditto.
(BT_FN_COMPLEX_BFLOAT16_COMPLEX_BFLOAT16): Ditto.
(BT_FN_BFLOAT16_COMPLEX_BFLOAT16): Ditto
1 Why should bf16 be modified to f16b?
--
diff --git a/gcc/c-family/c-cppbuiltin.cc b/gcc/c-family/c-cppbuiltin.cc
index a80372c8991..273bb9cf028 100644
--- a/gcc/c-family/c-cppbuiltin.cc
+++
As suggested by Richard Biener in bugzilla.commit b844775283a620b8826adf734ecfc97d820c3611
Author: Joern Rennecke
Date: Wed Aug 7 02:48:45 2024 +0100
Fix vect/pr115278.cc for targets where uint32_t is distinct from unsigned.
gcc/testsuite/
* g++.dg/vect/pr115278.cc: Ma
On Tue, 6 Aug 2024, Jason Merrill wrote:
> On 8/6/24 5:47 PM, Patrick Palka wrote:
> > On Tue, 6 Aug 2024, Jason Merrill wrote:
> >
> > > On 8/6/24 2:00 PM, Patrick Palka wrote:
> > > > On Tue, 6 Aug 2024, Jason Merrill wrote:
> > > >
> > > > > On 8/5/24 6:09 PM, Patrick Palka wrote:
> > > > > >
Hi Jeff
On 8/5/24 21:31, Jeff Law wrote:
> On 8/5/24 5:35 PM, Vineet Gupta wrote:
>> Hi Richard,
>>
>> I'm reaching out for some insight on PR/114729. Apologies in advance for
>> the long email.
>>
>> On RISC-V we are hitting sched1 pathology on SPEC2017 Cactu where
>> codegen spills are overwhelm
On Tue, Aug 6, 2024 at 9:35 PM Jeff Law wrote:
>
>
> On 8/6/24 3:31 AM, Nick Clifton wrote:
> > Hi Jeff,
> >
> >>> 2.43 was released over an weekend. Is it possible to let it be
> >>> supported after 2.44? cc Nick and jan.
> >> I don't think it's critical enough to backport to 2.43. I'd just pu
is bouncing. FYI. I've removed it.
On Wed, Aug 07, 2024 at 01:12:00AM GMT, Alejandro Colomar wrote:
> Hi!
>
> This is ready for review.
>
> v5:
>
> - Add changelog entries.
> - Wording fixes in commit messages.
> - s/sizeof/lengthof/ in comment.
> - CC += David, Florian, Andreas [Qing]
On Wed, Aug 07, 2024 at 01:12:17AM GMT, Alejandro Colomar wrote:
> This operator is similar to sizeof but can only be applied to an array,
> and returns its length (number of elements).
>
> FUTURE DIRECTIONS:
>
> We could make it work with array parameters to functions, and
> somehow magicall
This operator is similar to sizeof but can only be applied to an array,
and returns its length (number of elements).
FUTURE DIRECTIONS:
We could make it work with array parameters to functions, and
somehow magically return the length designator of the array,
regardless of it being really a
The old name was misleading.
While at it, also rename some temporary variables that are used with
this function, for consistency.
Link:
https://inbox.sourceware.org/gcc-patches/9fffd80-dca-2c7e-14b-6c9b509a7...@redhat.com/T/#m2f661c67c8f7b2c405c8c7fc3152dd85dc729120
Cc: Gabriel Ravier
Cc: Marti
There were two identical definitions, and none of them are available
where they are needed for implementing __lengthof__. Merge them, and
provide the single definition in gcc/tree.{h,cc}, where it's available
for __lengthof__, which will be added in the following commit.
gcc/ChangeLog:
*
Hi!
This is ready for review.
v5:
- Add changelog entries.
- Wording fixes in commit messages.
- s/sizeof/lengthof/ in comment.
- CC += David, Florian, Andreas [Qing]
- Docs: Remove some details about future directions. [Qing]
- Docs: Add examples. [Qing]
- Docs: Clarify when __lengtho
For bar1 and bar2, we currently is expecting to use the bsl instruction but
with slightly different register allocation inside the loop (which happens after
the removal of the vcond{,u,eq} patterns), we get the bit instruction. The
pattern that
outputs bsl instruction will output bit and bif too
On Tue, 2024-08-06 at 17:52 -0400, Jason Merrill wrote:
> On 8/6/24 5:47 PM, Patrick Palka wrote:
> > On Tue, 6 Aug 2024, Jason Merrill wrote:
> >
> > > On 8/6/24 2:00 PM, Patrick Palka wrote:
> > > > On Tue, 6 Aug 2024, Jason Merrill wrote:
> > > >
> > > > > On 8/5/24 6:09 PM, Patrick Palka wrot
On Linux/x86_64,
2f759fa9f4dd78ae8d86482ccda72a335aaac404 is the first bad commit
commit 2f759fa9f4dd78ae8d86482ccda72a335aaac404
Author: Roger Sayle
Date: Tue Aug 6 17:19:29 2024 +0100
i386: Refactor V2DI arithmetic right shift expansion for STV.
caused
FAIL: g++.dg/other/sse2-pr85572-1
After r15-2414-g2d105efd6f60 which fixed the dg-do directive, the testcase
stopped working because there was a missing -save-temps. This adds that and
now the testcase passes again.
Pushed as obvious.
gcc/testsuite/ChangeLog:
PR testsuite/116207
* gcc.target/aarch64/simd/vmmla.c:
Tested powerpc64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
PR libstdc++/116247
* include/bits/fs_path.h: Use __UINTPTR_TYPE__ instead of
uintptr_t.
* include/bits/shared_ptr_atomic.h: Likewise.
* include/ext/pointer.h: Include .
---
libstdc
Previously the invocation's "executionSuccessful" property (§3.20.14)
was only false if there was an ICE.
Update it so that it will also be false if we will exit with a non-zero
exit code (due to errors, Werror, and "sorry").
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed t
On 8/6/24 17:27, Andrew Pinski wrote:
This is a set of 5 small cleanups for the ranger op table.
I noticed it after was pointed out an uninitialized warning
sometimes happens for it. We should use final classes a lot more,
even if it just used for documentation that you can't use it as a
base c
On 8/6/24 5:47 PM, Patrick Palka wrote:
On Tue, 6 Aug 2024, Jason Merrill wrote:
On 8/6/24 2:00 PM, Patrick Palka wrote:
On Tue, 6 Aug 2024, Jason Merrill wrote:
On 8/5/24 6:09 PM, Patrick Palka wrote:
On Mon, 5 Aug 2024, Jason Merrill wrote:
On 8/5/24 3:47 PM, Patrick Palka wrote:
On Mo
On Tue, 6 Aug 2024, Jason Merrill wrote:
> On 8/6/24 2:00 PM, Patrick Palka wrote:
> > On Tue, 6 Aug 2024, Jason Merrill wrote:
> >
> > > On 8/5/24 6:09 PM, Patrick Palka wrote:
> > > > On Mon, 5 Aug 2024, Jason Merrill wrote:
> > > >
> > > > > On 8/5/24 3:47 PM, Patrick Palka wrote:
> > > > > >
Hi Martin,
On Tue, Aug 06, 2024 at 04:43:27PM GMT, Martin Uecker wrote:
> There are also *.sum files which you can diff against a build
> without your patch to see whether there are any regressions.
In my working copy, it all looks good. Thanks! I'll mention that in v5.
Have a lovely night!
Al
On 8/1/24 2:39 PM, Jakub Jelinek wrote:
Hi!
When working on unsequenced/reproducible attributes, I've noticed that on
templates for some attributes decl_attributes isn't called at all, so they
are kept in TYPE_ATTRIBUTES without any verification/transformations and
also without argument substitu
On 8/6/24 8:03 AM, Nathaniel Shead wrote:
On Fri, Jul 26, 2024 at 01:17:57PM -0400, Jason Merrill wrote:
On 7/26/24 12:52 AM, Nathaniel Shead wrote:
On Tue, Jul 23, 2024 at 04:17:22PM -0400, Jason Merrill wrote:
On 6/15/24 10:29 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-
This is another small cleanup in the ranger code,
since these classes and the instance of them are local
to the sources already, make them final classes and make them
local by wrapping them with an anonymous namespace.
Note some classes/instances were unused in the first place
so I didn't deleted t
This is a small cleanup with respect to the ranger_op_table class.
There should only ever be one instance of ranger_op_table so
this adds a static member function which returns the instance.
A few variables that are defined in range-op.cc should be local
to the file so wrap them with an anonymous n
With LTO, initialize_integral_ops, initialize_integral_ops and
initialize_float_ops
are all inlined into the constructor of range_op_table, so you get an
uninitialized
warning about m_range_tree not being initialized due to it having a clobber at
the
begining of the constructor. This adds a valu
While making range_op_table a singleton, I noticed that constification
should be done to `operator[]` and that operator_table could be made
as const as it does not get changed after it is initialized.
Bootstrapped and tested on x86_64-linux.
gcc/ChangeLog:
* range-op.h (range_op_table):
Since there will be only one instance of this class
alive at any time, it is better to declare this class as final.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* range-op.h (class range_op_table): Declare as a final class.
Signed-off-by: Andrew Pinski
---
gcc/range-op.
This is a set of 5 small cleanups for the ranger op table.
I noticed it after was pointed out an uninitialized warning
sometimes happens for it. We should use final classes a lot more,
even if it just used for documentation that you can't use it as a
base class. Also local instances should really b
On Mon, Aug 5, 2024 at 3:23 AM Roger Sayle wrote:
>
>
> This patch refactors ashrv2di RTL expansion into a function so that it may
> be reused by a pre-reload splitter, such that DImode right shifts may be
> considered candidates during the Scalar-To-Vector (STV) pass. Currently
> DImode arithmet
Hi Joseph,
On Tue, Aug 06, 2024 at 08:50:19PM GMT, Joseph Myers wrote:
> static int f(), f2();
> int a[10][10];
> int x;
>
> void
> g()
> {
> __lengthof__ (a[f()]); // Should be valid that f is not defined.
> int b[x][x];
> __lengthof__ (b[f2()]); // Should be invalid that f2 is not defined
Hi Mikael and Harald,
- inline expansion is inhibited at -Os. But wouldn't it be good if
we make this expansion also dependent on -ffrontend-optimize?
(This was the case for rank-1 before your patch).
The original idea was to have -ffrontend-optimize as a check if anything
went wrong wi
On Tue, 6 Aug 2024, Alejandro Colomar wrote:
> > Next question for the specification, implementation and tests: how does
> > this feature interact with the rules on external definitions (the contexts
> > in which it's OK to refer to an identifier with internal or external
> > linkage that's nev
On 8/6/24 2:00 PM, Patrick Palka wrote:
On Tue, 6 Aug 2024, Jason Merrill wrote:
On 8/5/24 6:09 PM, Patrick Palka wrote:
On Mon, 5 Aug 2024, Jason Merrill wrote:
On 8/5/24 3:47 PM, Patrick Palka wrote:
On Mon, 5 Aug 2024, Jason Merrill wrote:
On 8/5/24 1:14 PM, Patrick Palka wrote:
On Mo
On Tue, Aug 06, 2024 at 10:38:55PM GMT, Alejandro Colomar wrote:
> Hi Qing,
>
> On Tue, Aug 06, 2024 at 08:15:50PM GMT, Qing Zhao wrote:
> > Some comments on the documentation part.
> >
> > (Hopefully, this time my quoting format is good, I checked the email
> > sent back to myself, no formatti
Hi Qing,
On Tue, Aug 06, 2024 at 08:15:50PM GMT, Qing Zhao wrote:
> Some comments on the documentation part.
>
> (Hopefully, this time my quoting format is good, I checked the email
> sent back to myself, no formatting issue, but when I checked the emails
> in the archive,
> https://gcc.gnu.o
Hi Jerry,
this is OK for mainline.
I have no reservations against a backport after a waiting period.
If Roland is fine with it and nobody else objects, 14-branch might
be ok.
Thanks for the patch!
Harald
Am 06.08.24 um 21:52 schrieb Jerry D:
Hi all,
The attached patch changes all the snprin
Hi Joseph!
On Tue, Aug 06, 2024 at 05:38:50PM GMT, Joseph Myers wrote:
> On Tue, 6 Aug 2024, Alejandro Colomar wrote:
>
> > - The tests seem to work as expected if I compile them manually, and
> >run (the one that should be run) as a normal program. The one that
> >should not be run als
Some comments on the documentation part.
(Hopefully, this time my quoting format is good, I checked the email
sent back to myself, no formatting issue, but when I checked the emails
in the archive,
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659593.html,
yst, I see the quoting forma
Hi Mikael,
thanks for this nice set of patches!
I've played around a bit, and it seems to look good.
I have only minor comments left (besides the nan issue raised):
- inline expansion is inhibited at -Os. But wouldn't it be good if
we make this expansion also dependent on -ffrontend-optimiz
Hi all,
The attached patch changes all the snprintf calls to regular gfc_error
calls to cleanup translation. I introduced a simple macro to facilitate
doing the checks that were being done in the bad_op code section.
From the description for the call to gfc_extend_expr interfaces are
mentio
Gerald Pfeifer writes:
> I noticed a non-working link, then some other details in that section.
>
> Here is a suggestion to rework it a bit.
>
> Okay?
>
> Gerald
>
>
>
>>From 83e856355a94bd78afbf19eed32ca1726658f581 Mon Sep 17 00:00:00 2001
> From: Gerald Pfeifer
> Date: Mon, 5 Aug 2024 21:06:20
The test case uses "atomic", which fails to link on
pru-unknown-elf target due to missing __atomic_load_4 symbol.
Fix by filtering for sync_int_long effective target. Ensured that the
test still passes for x86_64-pc-linux-gnu.
Ok for master?
gcc/testsuite/ChangeLog:
* g++.dg/init/array
Tested on hppa-unknown-linux-gnu. Committed to active branches.
Dave
---
hppa: Fix (plus (plus (mult (a) (mem_shadd_constant)) (b)) (c)) optimization
The constant C must be an integral multiple of the shift value in
the above optimization. Non integral values can occur evaluating
IMAGPART_EXPR
On Tue, Aug 06, 2024 at 11:50:00AM -0700, Andi Kleen wrote:
> > - s += 16;
> > + v16qi data, t;
> > + /* Unaligned load. Reading beyond the final newline is safe, since
> > +files.cc:read_file_guts pads the allocation. */
>
> You need to change that function to use 32 byte pad
> - s += 16;
> + v16qi data, t;
> + /* Unaligned load. Reading beyond the final newline is safe, since
> + files.cc:read_file_guts pads the allocation. */
You need to change that function to use 32 byte padding as Jakub
pointed out (I forgot that too)
> + data = *(const
> Andi, can you push your own patch?).
Done.
-Andi
On Tue, 6 Aug 2024, Jason Merrill wrote:
> On 8/5/24 6:09 PM, Patrick Palka wrote:
> > On Mon, 5 Aug 2024, Jason Merrill wrote:
> >
> > > On 8/5/24 3:47 PM, Patrick Palka wrote:
> > > > On Mon, 5 Aug 2024, Jason Merrill wrote:
> > > >
> > > > > On 8/5/24 1:14 PM, Patrick Palka wrote:
> > > > > >
On Tue, 6 Aug 2024, Alejandro Colomar wrote:
> - The tests seem to work as expected if I compile them manually, and
>run (the one that should be run) as a normal program. The one that
>should not be run also gives the expected diagnostics.
>Can anyone give advice of why it's not runn
On 8/5/24 20:20, Jeff Law wrote:
On 8/5/24 4:29 PM, Patrick O'Neill wrote:
This fixes typos in function names and executed code.
gcc/ChangeLog:
* config/riscv/riscv-target-attr.cc (num_occurences_in_str):
Rename...
(num_occurrences_in_str): here.
(riscv_process_target_attr):
On 8/5/24 20:19, Jeff Law wrote:
On 8/5/24 4:29 PM, Patrick O'Neill wrote:
This fixes most of the typos I found when reading various parts of
the RISC-V
backend.
Comment typos are always OK to fix under the "obvious" rule. No need
to wait for an ACK.
Jeff
Committed.
Patrick
On 8/5/24 6:09 PM, Patrick Palka wrote:
On Mon, 5 Aug 2024, Jason Merrill wrote:
On 8/5/24 3:47 PM, Patrick Palka wrote:
On Mon, 5 Aug 2024, Jason Merrill wrote:
On 8/5/24 1:14 PM, Patrick Palka wrote:
On Mon, 5 Aug 2024, Jason Merrill wrote:
On 8/2/24 4:18 PM, Patrick Palka wrote:
On Fr
On 8/6/24 5:55 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
When forgetting the '<>' on an explicit specialisation, the suggested
fixit hint suggests to add 'template <>', but naively applying will
cause nonsense results like 'templ
On Tue, 6 Aug 2024, 17:28 Andi Kleen, wrote:
> Cassio Neri writes:
>
> > Implement the template function teju_jagua which finds the shortest
> > representation of a floating-point number. The floating-point type is a
> > template parameter and the implementation is generic enough to handle all
>
On 8/6/24 12:09 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
Patrick noticed a few more concept_check_p checks that can be removed
now.
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_call_expression): Remove concept_check_p check.
Save LIBS around calls to AC_SEARCH_LIBS to avoid clobbering $LIBS.
ChangeLog:
* configure: Regenerate.
* configure.ac: Save LIBS around calls to AC_SEARCH_LIBS.
Signed-off-by: Marc Poulhiès
Reviewed-by: Thomas Schwinge
Tested-by: Thomas Schwinge
---
Hello,
This has already b
Tested x86_64-pc-linux-gnu, applying to trunk (not 14).
-- 8< --
Building on the last patch, deduction should probably look through all
IMPLICIT_CONV_EXPR like we do other conversions.
One resulting regression turned out to be due to PR94568, fixed separately.
The one other regression was for a
Tested x86_64-pc-linux-gnu, applying to trunk and 14.
-- 8< --
My r14-8291 for PR112632 introduced IMPLICIT_CONV_EXPR_FORCED to express
conversions to the type of an alias template parameter. In this example,
that broke deduction of X in the call to foo, so let's teach deduction to
look through
On 8/6/24 09:12, Richard Biener wrote:
Currently the forward threader isn't limited as to the search space
it explores and with it now using path-ranger for simplifying
conditions it runs into it became pretty slow for degenerate cases
like compiling insn-emit.cc for RISC-V esp. when compiling
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
A zero-initializer should not reflect the constness of what it's
initializing, as it does not for initializers with different syntax.
This does have mangling implications for rare C++20 code, but it seems
infeasable to make the mangling dep
On Tue, 6 Aug 2024, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
LGTM
>
> -- >8 --
> Patrick noticed a few more concept_check_p checks that can be removed
> now.
>
> gcc/cp/ChangeLog:
>
> * constexpr.cc (cxx_eval_call_expression): Remove concept_ch
Sam, Jakub & Robin,
We had an "OK for trunk" from Jeff for v4 (see
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656907.html) and
it has been two more weeks for this RESEND.
I'll push this by end of this week unless I hear otherwise.
Thanks,
Philipp.
On Fri, 26 Jul 2024 at 12:50, Sam Jame
[CC += David, Florian, Andreas]
On Tue, Aug 06, 2024 at 03:59:11PM GMT, Qing Zhao wrote:
> Hi, Alex,
Hi Qing,
> I noticed that all your 4 versions of the patches and the
> corresponding discussion are all in the same email thread, it’s very
> inconvenient to read. Can you start a new email threa
Use the same PSHUFB-based matching as in the SSSE3 helper, just 2x
wider.
Directly use the new helper if __AVX2__ is defined. It makes the other
helpers unused, so mark them inline to prevent warnings.
Rewrite and simplify init_vectorized_lexer.
libcpp/ChangeLog:
* files.cc (read_file_g
Since the characters we are searching for (CR, LF, '\', '?') all have
distinct ASCII codes mod 16, PSHUFB can help match them all at once.
libcpp/ChangeLog:
* lex.cc (search_line_sse42): Replace with...
(search_line_ssse3): ... this new function. Adjust the use...
(init_v
Upcoming patches first drop Binutils ISA support from SSE4.2 to SSSE3,
then bump it to AVX2. Instead of fiddling with detection, just bump
our configure check to AVX2 immediately: if by some accident somebody
builds GCC without AVX2 support in the assembler, they will get SSE2
vectorized lexer, whi
Hello!
As discussed, I'm sending patches that reimplement our SSE4.2 search_line_fast
helper with SSSE3, and then add the corresponding AVX2 helper. They are on top
of Andi's "Remove MMX code path in lexer" patch, which was approved, but not
committed yet (Andi, can you push your own patch?).
App
On 8/6/24 09:12, Palmer Dabbelt wrote:
On Tue, 06 Aug 2024 09:07:26 PDT (-0700), Patrick O'Neill wrote:
gcc/ChangeLog:
PR target/116152
* config/riscv/riscv.cc (riscv_option_override): Fix url
formatting.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/predef-9.c: Update testc
On Tue, 06 Aug 2024 09:07:26 PDT (-0700), Patrick O'Neill wrote:
gcc/ChangeLog:
PR target/116152
* config/riscv/riscv.cc (riscv_option_override): Fix url
formatting.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/predef-9.c: Update testcase.
Co-authored-by: Jaku
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Patrick noticed a few more concept_check_p checks that can be removed
now.
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_call_expression): Remove concept_check_p check.
(cxx_eval_outermost_constant_expr): Likewise
gcc/ChangeLog:
PR target/116152
* config/riscv/riscv.cc (riscv_option_override): Fix url
formatting.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/predef-9.c: Update testcase.
Co-authored-by: Jakub Jelinek
Signed-off-by: Patrick O'Neill
---
Tested using rv64gc.
Hi, Alex,
I noticed that all your 4 versions of the patches and the corresponding
discussion are all in the same email thread, it’s very inconvenient to read.
Can you start a new email thread for each of the new version of the patch?
(i.e, Please not reply to the previous version when you have a
Hi Martin,
On Tue, Aug 06, 2024 at 04:43:27PM GMT, Martin Uecker wrote:
> > When running `make check -j24 -Orecurse |& tee log`, this is what I see:
> >
> > FAIL: gcc.dg/lengthof-compile.c (test for excess errors)
> >
> > Is there any way to see more details?
>
> See gcc/testsuite/g
On 8/6/24 10:01 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?
I might add it after std::forward instead of at the bottom? OK either way.
-- >8 --
This extends our folding of cast-like standard library functions
to also include C++2
Cassio Neri writes:
> Implement the template function teju_jagua which finds the shortest
> representation of a floating-point number. The floating-point type is a
> template parameter and the implementation is generic enough to handle all
> floating-point types of interest, namely, IEEE 754, std
On Aug 5, 2024, at 16:59, Alejandro Colomar wrote:
The “counted-by” attribute currently is not in the TYPE system, and
we plan to add it into the TYPE system later through language
standard (or an GCC extension). If that happens, then both the
“sizeof” and the “__lengthof__” operators should
Steve:
Agreed the documentation only specifies unsigned char argument for the
two built-ins.
Do you think we should add support signed char arguments in addition to
the documented unsigned char arguments?
Do you see any situations where a user might want to to have both signed
and unsigned
On Tue, 6 Aug 2024, Filip Kastl wrote:
> So I thought I might create the GCC 15 porting_to.html page and add an
> entry about this (I just copied the entry from GCC 14 porting_to.html).
Nice.
> Ha! As I'm writing this I noticed that actually Jonathan predicted this
> and suggested a correspond
Am Dienstag, dem 06.08.2024 um 16:12 +0200 schrieb Alejandro Colomar:
> Hi Martin,
>
> On Tue, Aug 06, 2024 at 03:37:13PM GMT, Martin Uecker wrote:
> > Am Dienstag, dem 06.08.2024 um 14:22 +0200 schrieb Alejandro Colomar:
> > > Hi!
> > >
> > > - The tests seem to work as expected if I compile th
On Tue, May 28, 2024 at 8:28 PM Andrew Pinski wrote:
>
> Sometimes initialize_sanitizer_builtins is not called before emitting
> the asan builtins with hwasan. In the case of the bug report, there
> was a path with the fortran front-end where it was not called.
> So let's call it in asan_instrumen
Hi,
I recently had to add '#include ' to a program to compile it with the
latest trunk GCC due to
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659176.html
So I thought I might create the GCC 15 porting_to.html page and add an entry
about this (I just copied the entry from GCC 14 porting
The gimple-if-to-switch pass converts if statements with
multiple equal checks on the same value to a switch. This breaks
vectorization which cannot handle switches.
Teach the tree-if-conv pass used by the vectorizer to handle
simple switch statements, like those created by if-to-switch earlier.
T
On Tue, Aug 06, 2024 at 03:07:44PM +0100, Matthieu Longo wrote:
> On AArch64, the RA state informs the unwinder whether the return address
> is mangled and how, or not. This information is encoded in a boolean in
> the CFI row. This binary approach prevents from expressing more complex
> configurat
On 8/4/24 12:35 PM, Mary Bennett wrote:
Spec:
github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
Contributors:
Mary Bennett
Nandni Jamnadas
Pietra Ferreira
Charlie Keaney
Jessica Mills
Craig Blackmore
Simon Cook
Jeremy Bennett
H
Hi Martin,
On Tue, Aug 06, 2024 at 03:37:13PM GMT, Martin Uecker wrote:
> Am Dienstag, dem 06.08.2024 um 14:22 +0200 schrieb Alejandro Colomar:
> > Hi!
> >
> > - The tests seem to work as expected if I compile them manually, and
> >run (the one that should be run) as a normal program. The o
> OK.
Thanks Richard.
Just notice we can put type_has_mode_precision_p as the first condition to
avoid unnecessary
pattern matching (which is heavy), will commit with this change if no surprise
from test suite.
From:
> + if (gimple_unsigned_integer_sat_trunc (lhs, ops, NULL)
> + && type_
On AArch64, the RA state informs the unwinder whether the return address
is mangled and how, or not. This information is encoded in a boolean in
the CFI row. This binary approach prevents from expressing more complex
configuration, as it is the case with PAuth_LR introduced in Armv9.5-A.
This patc
Architecture-specific CFI directives are currently declared an processed
among others architecture-independent CFI directives in gcc/dwarf2* files.
This approach creates confusion, specifically in the case of DWARF
instructions in the vendor space and using the same instruction code.
Such a clash
1 - 100 of 162 matches
Mail list logo
