https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Fri, 12 Jan 2024 at 06:53, Daniel Krügler wrote:
>
> Am Do., 11. Jan. 2024 um 21:23 Uhr schrieb Jonathan Wakely
> :
> >
> > Tested x86_64-linux. Does this look better now?
>
> Yes, thank you.
Thanks, pushed.
Tested aarch64-linux, pushed to trunk.
-- >8 --
This was approved for C++23 at he June 2021 virtual meeting.
This allows more efficient construction of std::pair members when {} is
used as a constructor argument. The perfect forwarding constructor can
be used, so that the member variables are
On Fri, 12 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> This is the case I was talking about in
> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642423.html
> and Zdenek kindly found a testcase for it.
> We can only create BITINT_TYPE with precision at most 65535, not 65536,
> so need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113320
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:5fbc1b2e7c1bdf11f64765b278f477310c0f3436
commit r14-7174-g5fbc1b2e7c1bdf11f64765b278f477310c0f3436
Author: Jonathan Wakely
On Fri, 12 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> The code to assign large/huge _BitInt SSA_NAMEs to partitions intentionally
> ignores uninitialized SSA_NAMEs:
> /* Also ignore uninitialized uses. */
> if (SSA_NAME_IS_DEFAULT_DEF (s)
> && (!SSA_NAME_VAR (s)
On Fri, 12 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase revealed a typo in condition, as the comment
> says the intent is
>/* If lhs of stmt is large/huge _BitInt SSA_NAME not in m_names
>it means it will be handled in a loop or straight line code
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105505
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:35f8c661d67f53486f2f3e25887323476a7d0c2b
commit r14-7173-g35f8c661d67f53486f2f3e25887323476a7d0c2b
Author: Jonathan Wakely
On Fri, 12 Jan 2024, Jakub Jelinek wrote:
> On Thu, Jan 11, 2024 at 12:12:59PM +0100, Jakub Jelinek wrote:
> > So, the problem was that in 2 spots I was comparing TYPE_SIZE of large/huge
> > BITINT_TYPEs to determine if it can be handled cheaply.
> > On x86_64 with limb_mode == abi_limb_mode
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/format (__format::_Arg_store): Fix PR number in
comment. Simplify preprocessor code.
---
libstdc++-v3/include/std/format | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git
Hi!
This is the case I was talking about in
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642423.html
and Zdenek kindly found a testcase for it.
We can only create BITINT_TYPE with precision at most 65535, not 65536,
so need to punt if we'd want to create it.
Bootstrapped/regtested on
Hi!
The following testcase revealed a typo in condition, as the comment
says the intent is
/* If lhs of stmt is large/huge _BitInt SSA_NAME not in m_names
it means it will be handled in a loop or straight line code
at the location of its (ultimate) immediate use, so
Hi!
The code to assign large/huge _BitInt SSA_NAMEs to partitions intentionally
ignores uninitialized SSA_NAMEs:
/* Also ignore uninitialized uses. */
if (SSA_NAME_IS_DEFAULT_DEF (s)
&& (!SSA_NAME_VAR (s) || VAR_P (SSA_NAME_VAR (s
continue;
Hi!
When build_array_ref doesn't use ARRAY_REF, it casts the index to sizetype
already, performs POINTER_PLUS_EXPR and then dereferences.
While when emitting ARRAY_REF, we try to keep index expression as is in
whatever type it had, which is reasonable e.g. for signed or unsigned types
narrower
On Thu, Jan 11, 2024 at 12:12:59PM +0100, Jakub Jelinek wrote:
> So, the problem was that in 2 spots I was comparing TYPE_SIZE of large/huge
> BITINT_TYPEs to determine if it can be handled cheaply.
> On x86_64 with limb_mode == abi_limb_mode (both DImode) that works fine,
> if TYPE_SIZE is equal,
On Fri, Jan 12, 2024 at 07:40:19AM +, waffl3x wrote:
> Bootstrapped and tested on x86_64-linux with no regressions.
>
> I'm still getting used to things so let me know if the change log
> entries are excessive, thanks.
> From 9dc168e7bcbbd7d515fa28cb9cae28ec113fae0f Mon Sep 17 00:00:00 2001
1. Introduce vector regmove new tune info.
2. Adjust scalar_to_vec cost in add_stmt_cost.
We will get optimal codegen after this patch with -march=rv64gcv_zvl256b:
lui a5,%hi(a)
li a4,19
sb a4,%lo(a)(a5)
li a0,0
ret
Tested on both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113349
Andrew Pinski changed:
What|Removed |Added
Keywords||c++-lambda,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113349
Bug ID: 113349
Summary: internal compiler error: in tsubst
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
On Fri, 12 Jan 2024, Tamar Christina wrote:
> Hi All,
>
> This replaces two more usages of single_exit that I had missed before.
> They both seem to happen when we re-use the ifcvt scalar loop for versioning.
>
> The condition in versioning is the same as the one for when we don't re-use
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113137
--- Comment #14 from David Binderman ---
(In reply to Tamar Christina from comment #13)
> Patch submitted
Two weeks have elapsed and the patch doesn't seem to appear in git.
Is it perhaps stuck somewhere ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113126
Bug 113126 depends on bug 113344, which changed state.
Bug 113344 Summary: [14 regression] gcc.dg/pr15784-1.c fails after
r14-7139-g897b95a12b7fe5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113344
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113344
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113344
--- Comment #5 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:160799b366c33246ca16b84020ec49c3feabb0a3
commit r14-7170-g160799b366c33246ca16b84020ec49c3feabb0a3
Author: Richard Biener
Date:
On GENERIC tcc_comparison can have int type so restrict the PR113126
fix to vector types.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR middle-end/113344
* match.pd ((double)float CMP (double)float -> float CMP float):
Perform result type check only for
Hi, Richard.
I tried hard in RISC-V backend. I found to fix the case with
-march=rv64gcv_zvl4096b can not be without vec_to_scalar count.
Is there an approach that we can count vec_to_scalar cost without this piece
code in middle-end ?
/* ??? Enable for loop costing as well. */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113255
--- Comment #11 from Richard Biener ---
diff --git a/gcc/alias.cc b/gcc/alias.cc
index b2ec4806d22..0150dd699db 100644
--- a/gcc/alias.cc
+++ b/gcc/alias.cc
@@ -2272,6 +2272,8 @@ static bool
base_alias_check (rtx x, rtx x_base, rtx y, rtx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112301
--- Comment #8 from Andrew Pinski ---
(In reply to Alexander Grund from comment #4)
> Thank you! Will there be backports for 12.x?
>
> The current patch is conflicting due to "c++: enable NRVO from inner block
> [PR51571]" and while it seems
Hi All,
This replaces two more usages of single_exit that I had missed before.
They both seem to happen when we re-use the ifcvt scalar loop for versioning.
The condition in versioning is the same as the one for when we don't re-use the
scalar loop.
I hit these during an LTO enabled bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113347
Richard Biener changed:
What|Removed |Added
Known to fail||12.3.1, 13.2.1
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112301
--- Comment #7 from Richard Biener ---
This caused PR113347 (did you forget to mark the bug fixed?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113347
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113347
Fabian Vogt changed:
What|Removed |Added
CC||fab...@ritter-vogt.de
--- Comment #4
On Fri, Jan 12, 2024 at 7:15 AM Feng Xue OS wrote:
>
> Add a depth parameter to limit recursion of vec_slp_has_scalar_use.
OK.
> Feng
> ---
>
> .../gcc.target/aarch64/bb-slp-pr113091.c | 22 ++
> gcc/tree-vect-slp.cc | 207 ++
> 2 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #9
On Fri, Jan 12, 2024 at 3:15 AM HAO CHEN GUI wrote:
>
> Hi Richard,
>Thanks so much for your comments.
>
>
> >> patch.diff
> >> diff --git a/gcc/config/rs6000/rs6000-string.cc
> >> b/gcc/config/rs6000/rs6000-string.cc
> >> index 7f777666ba9..4c9b2cbeefc 100644
> >> ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113348
Bug ID: 113348
Summary: ice when calling xobj member function without an
object in an xobj member function
Product: gcc
Version: 14.0
Status: UNCONFIRMED
301 - 337 of 337 matches
Mail list logo
