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 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 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:
> > > > > >
> Andi, can you push your own patch?).
Done.
-Andi
> - 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
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
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
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
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
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
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
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 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
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 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
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
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, 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
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
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
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
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
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.
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):
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
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
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
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-
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
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 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 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 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
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
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
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:
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
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
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
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
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:
*
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
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
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
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 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
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, 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:
> > > > > >
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
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
+++
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
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
> 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/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
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
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
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
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
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
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
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
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
101 - 162 of 162 matches
Mail list logo
