The combine pass is trying to combine:
Trying 16, 22, 21 -> 23:
16: r104:QI=flags:CCNO>0
22: {r120:QI=r104:QI^0x1;clobber flags:CC;}
REG_UNUSED flags:CC
21: r119:QI=flags:CCNO<=0
REG_DEAD flags:CCNO
23: {r110:QI=r119:QI|r120:QI;clobber flags:CC;}
REG_DEAD r120:QI
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, February 26, 2025 1:52 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: RE: [3/3 PATCH v3]middle-end: delay checking for alignment to load
> [PR118464]
>
> On Wed, 26 Feb 2025, Tamar Christina wrote:
>
On Wed, Feb 26, 2025 at 01:34:04PM +0100, Richard Biener wrote:
> > It wants to have a MEM which overlaps anything below the stack.
> > So, uses for stack grows down and non-biased stack sp - PTRDIFF_MAX with
> > PTRDIFF_MAX MEM_SIZE as an approximation to that.
>
> I see. Wouldn't setting MEM_OF
On 26/02/2025 16:22, Jonathan Wakely wrote:
Clang 17/18 rejects 'constexpr' on non-template functions that use
(non-constexpr) placement new but accepts it on templates (silently
dropping constexpr at instantiation time):https://godbolt.org/z/Tqnvc1f1W
So it seems Clang 17/18 behavior is consiste
Hi Yuriy:
V2 is LGTM, thanks :)
On Wed, Feb 26, 2025 at 3:06 AM Yuriy Kolerov
wrote:
>
> Hi Jeff,
>
> That check is performed in a lambda function:
>
> {"zce", "zcf",
>[] (const riscv_subset_list *subset_list) -> bool
>{
> return subset_list->xlen () == 32 && subset_list->lookup (
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Yet another problem that started with r15-6052, compile time evaluation of
prvalues.
cp_fold_r/TARGET_EXPR sees:
TARGET_EXPR >>>
so when we call maybe_constant_init, the object we're initializing is D.2701,
and the ini
Tested on x86_64-pc-linxu-gnu, pushed to trunk as obvious.
-- >8 --
PR libstdc++/118083
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h
(ranges::__access::__possibly_const_range): Mention LWG 4027.
---
libstdc++-v3/include/bits/ranges_base.h | 2 ++
1 file changed,
On Wed, 26 Feb 2025 at 15:06, Patrick Palka wrote:
>
> On Tue, 25 Feb 2025, Jonathan Wakely wrote:
>
> > On Thu, 20 Feb 2025 at 16:23, Patrick Palka wrote:
> > >
> > > On Sun, 16 Feb 2025, Giuseppe D'Angelo wrote:
> > >
> > > > Hello,
> > > >
> > > > the attached patch implements the C++26 papers
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, February 26, 2025 12:30 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [3/3 PATCH v3]middle-end: delay checking for alignment to load
> [PR118464]
>
> On Tue, 25 Feb 2025, Tamar Christina wrote:
>
On Wed, 26 Feb 2025, Uros Bizjak wrote:
> The combine pass is trying to combine:
>
> Trying 16, 22, 21 -> 23:
>16: r104:QI=flags:CCNO>0
>22: {r120:QI=r104:QI^0x1;clobber flags:CC;}
> REG_UNUSED flags:CC
>21: r119:QI=flags:CCNO<=0
> REG_DEAD flags:CCNO
>23: {r110:QI=r11
On 2/21/25 6:05 AM, Nathaniel Shead wrote:
After seeing PR c++/118964 I'm coming back around to this [1] patch
series, since it appears that this can cause errors on otherwise valid
code by instantiations coming into module purview that reference
TU-local entities.
[1]: https://gcc.gnu.org/piper
> > >
> > > No, I don't think so. The code that eventually performs a
> > > contiguous sub-group access directly should never extend
> > > the load beyond GROUP_SIZE - or should be gated on the DR
> > > not executed speculatively. That is, we should "fix" this
> > > elsewhere.
> > >
> >
> > It do
Hello,
On 25/02/2025 23:46, Jonathan Wakely wrote:
Maybe we can get away with unconditionally declaring this
_GLIBCXX26_CONSTEXPR? If the compiler doesn't support constexpr
placement new then the 'constexpr' would be silently dropped at
instantiation time. This would be in line with C++23 P244
On Mon, Feb 24, 2025 at 10:46 AM Richard Biener
wrote:
> /* Otherwise, if this register is used by I3, then this register
> now dies here, so we must put a REG_DEAD note here unless there
> is one already. */
> else if (reg_referenced_p (XEXP (note,
On Wed, Feb 26, 2025 at 07:55:28AM -0500, David Malcolm wrote:
> BTW, Qing Zhao's patch kit
> "[PATCH v4 0/3][RFC]Provide more contexts for -Warray-bounds and -
> Wstringop-* warning messages"
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673474.html
I'm not sure we want that, that is
On Wed, 26 Feb 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Wednesday, February 26, 2025 12:30 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd
> > Subject: Re: [3/3 PATCH v3]middle-end: delay checking for alignment to load
> > [PR
On Wed, Feb 26, 2025 at 3:01 PM Jakub Jelinek wrote:
>
> On Wed, Feb 26, 2025 at 07:55:28AM -0500, David Malcolm wrote:
> > BTW, Qing Zhao's patch kit
> > "[PATCH v4 0/3][RFC]Provide more contexts for -Warray-bounds and -
> > Wstringop-* warning messages"
> > https://gcc.gnu.org/pipermail/gcc-pa
On Wed, 26 Feb 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Wednesday, February 26, 2025 1:52 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd
> > Subject: RE: [3/3 PATCH v3]middle-end: delay checking for alignment to load
> > [PR1
On Tue, 25 Feb 2025, Jonathan Wakely wrote:
> On Thu, 20 Feb 2025 at 16:23, Patrick Palka wrote:
> >
> > On Sun, 16 Feb 2025, Giuseppe D'Angelo wrote:
> >
> > > Hello,
> > >
> > > the attached patch implements the C++26 papers that add `constexpr` to the
> > > specialized memory algorithms (the u
On 26/02/2025 15:59, Jakub Jelinek wrote:
> Hi!
>
> The linaro CI found my PR119002 patch broke bootstrap on arm.
> Seems the problem is that it has incorrect REVERSE_CONDITION macro
> definition.
> All other target's REVERSE_CONDITION definitions and the default one
> just use the macro's argumen
Thanks Robin.
- IMHO we need to check both series for overflow, if step2 overflows in the
smaller type isn't the result equally wrong?
The series2 will shift right before IOR, thus the overflow bits never effect
on the final result.
For example, the series2 will be similar as below after shift
Hi!
The linaro CI found my PR119002 patch broke bootstrap on arm.
Seems the problem is that it has incorrect REVERSE_CONDITION macro
definition.
All other target's REVERSE_CONDITION definitions and the default one
just use the macro's arguments, while arm.h definition uses the MODE
argument but us
On Wed, 26 Feb 2025 at 20:53, Thomas Schwinge wrote:
>
> Hi Jonathan!
>
> Sorry for not providing more context initially.
>
> On 2025-02-26T10:50:11+, Jonathan Wakely wrote:
> > On Wed, 26 Feb 2025 at 10:47, Jonathan Wakely wrote:
> >> On Wed, 26 Feb 2025 at 10:19, Thomas Schwinge wrote:
> >
> Hmm, I think it's the other way around and it is being shifted left. In that
> case we're only keeping the lower bits and the "overflow bits" don't matter.
> That means we should indeed be OK here.
Yes, will add some comments here for series2.
> I guess the worst that can happen theoretical
This attached patch is intended to clarify the '-x' option using '-x
f77' as an example. I was not sure who should review.
Tested by inspecting the generated info file from make info.
OK for trunk and backport to 14?
Regards,
Jerry
Author: Jerry DeLisle
Date: Wed Feb 26 17:26:26 2025 -080
> -Original Message-
> From: Jiang, Haochen
> Sent: Wednesday, February 26, 2025 4:18 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com
> Subject: [PATCH] i386: Treat Granite Rapids/Granite Rapids-D/Diamond Rapids
> similar as Sapphire Rapids in x86-tune.def
>
> H
On Wed, 26 Feb 2025, Jakub Jelinek wrote:
> In any case, the following patch has been bootstrapped/regtested on
> x86_64-linux and i686-linux, ok for trunk? Or something else?
>
> 2025-02-26 Jakub Jelinek
>
> PR c/114870
> * ginclude/stddef.h (__STDC_VERSION_STDDEF_H__, unreachab
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119021
The patch was successfully tested and bootstrapped on x86-64.
commit 7ce3a8e872d945d537a7e7ba1bd3f45b1cf9a6d2
Author: Vladimir N. Makarov
Date: Wed Feb 26 11:28:08 2025 -0500
[PR119021][LRA]: Fix rtl correctn
On 26/02/2025 16:33, Giuseppe D'Angelo wrote:
Whops, sorry, missed this sub-thread (while replying to the other one).
Change of plans then, I'll amend and remove the ad-hoc constexpr macro.
Done, v3 attached.
Thanks,
--
Giuseppe D'Angelo
From de3751a38330f508be9f08b77136a31481018828 Mon Sep 1
On Wed, 26 Feb 2025, Jakub Jelinek wrote:
> Hi!
>
> r15-209 allowed flexible array members inside of unions, but as the
> following testcase shows, not everything has been adjusted for that.
> Unlike structures, in unions flexible array member (as an extension)
> can be any of the members, not ju
Hi Andre,
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Looks good to me.
Thanks for the patch!
Best regards
Thomas
Hi Jonathan!
Sorry for not providing more context initially.
On 2025-02-26T10:50:11+, Jonathan Wakely wrote:
> On Wed, 26 Feb 2025 at 10:47, Jonathan Wakely wrote:
>> On Wed, 26 Feb 2025 at 10:19, Thomas Schwinge wrote:
>> > In particular, 'GLIBCXX_ENABLE_CXX_FLAGS' shouldn't overwrite
>>
Hi all,
Since GNR, GNR-D, DMR are both P-core based, we should treat them
just like SPR in tuning for now.
Ok for trunk and backport to GCC13/14 for GNR/GNR-D part?
Thx,
Haochen
gcc/ChangeLog:
* config/i386/x86-tune.def
(X86_TUNE_DEST_FALSE_DEP_FOR_GLC): Add GNR, GNR-D, DMR.
On Tue, Feb 25, 2025 at 9:19 PM Jason Merrill wrote:
>
> r10-11132 uses C++11 default member initializers, which breaks bootstrapping
> with a C++98 compiler.
It's probably more interesting to add a note to gcc-10/changes.html as
caveat for the
10.5 minor release.
> gcc/ChangeLog:
>
> *
Hi Jerry,
thanks for the review. Committed as gcc-15-7712-g751b37047b2.
Thanks again,
Andre
On Tue, 25 Feb 2025 09:49:29 -0800
Jerry D wrote:
> On 2/25/25 9:18 AM, Andre Vehreschild wrote:
> > Hi all,
> >
> > for some recreation after all the coarray stuff, I found this pr cc'ed to
> >
On Wed, Feb 26, 2025 at 10:45:37AM +0100, Richard Biener wrote:
> OK
Unfortunately I've only bootstrapped/regtested it with normal checking.
Testing it with --enable-checking=release now shows that this patch just
moved the FAILs to a different symbol. And note that isn't even a LTO
build.
The f
On Feb 18, 2025, Richard Sandiford wrote:
> Thanks for doing this. How about also replacing all uses of:
>([check_effective_target_x86])
> with:
>[check_effective_target_x86]
> OK with that change if there are no objections within 24 hours.
Sure, thanks for the review and for the su
Thomas Schwinge writes:
> In particular, 'GLIBCXX_ENABLE_CXX_FLAGS' shouldn't overwrite
> 'EXTRA_CXX_FLAGS'
> (and prepend any additional '--enable-cxx-flags=[...]').
Why 'CXX_FLAGS' spelling (which is unusual) rather than 'CXXFLAG-- ah, I
see we have a load of EXTRA_CXXFLAGS, and then a lot of
On Wed, 26 Feb 2025 at 10:19, Thomas Schwinge wrote:
>
> In particular, 'GLIBCXX_ENABLE_CXX_FLAGS' shouldn't overwrite
> 'EXTRA_CXX_FLAGS'
> (and prepend any additional '--enable-cxx-flags=[...]').
This seems good, but why prepend instead of append here?
If there are important flags passed down f
On Wed, 26 Feb 2025 at 10:47, Jonathan Wakely wrote:
>
> On Wed, 26 Feb 2025 at 10:19, Thomas Schwinge wrote:
> >
> > In particular, 'GLIBCXX_ENABLE_CXX_FLAGS' shouldn't overwrite
> > 'EXTRA_CXX_FLAGS'
> > (and prepend any additional '--enable-cxx-flags=[...]').
>
> This seems good, but why prepe
On Wed, Feb 26, 2025 at 11:38 AM Jakub Jelinek wrote:
>
> On Wed, Feb 26, 2025 at 10:45:37AM +0100, Richard Biener wrote:
> > OK
>
> Unfortunately I've only bootstrapped/regtested it with normal checking.
> Testing it with --enable-checking=release now shows that this patch just
> moved the FAILs
On Tue, 11 Feb 2025, Richard Biener wrote:
> On Mon, 10 Feb 2025, Richard Biener wrote:
>
> > On Mon, 10 Feb 2025, Richard Biener wrote:
> >
> > > The following addresses the fact that we keep an excessive amount of
> > > redundant DEBUG BEGIN_STMTs - in the testcase it sums up to 99.999%
> > >
On Wed, Feb 26, 2025 at 10:58:26AM +0100, Richard Biener wrote:
> > This PR is about ubsan error on the c - cx1 + cy1 evaluation in the first
> > hunk.
> >
> > The following patch hopefully fixes that by doing the additions/subtractions
> > in poly_uint64 rather than poly_int64. Or shall we inste
On Wed, Feb 26, 2025 at 12:36:15PM +0100, Richard Biener wrote:
> > Bootstrapped and tested on x86_64-unknown-linux-gnu without
> > regressions this time.
> >
> > Alex, is this OK for trunk?
>
> Ping.
I'd really like to hear from Alex on this one.
Jakub
Update according to the amendment made for GCC 4.0.0 with commit
b11a9d5f3f90 back in 2004:
(mips_arg_info): Don't allow fpr_p to affect the register or
stack alignment. Remove o64 silliness.
Retain the description of the former semantics for reference.
---
htdocs/projects/mipso
Hi!
Various plugin tests fail with --enable-checking=release, because the
num_events and num_threads methods of simple_diagnostic_path are only used
inside of #if CHECKING_P code inside of GCC proper and then tested inside of
some plugin tests. So, with --enable-checking=yes they are compiled int
Hi!
The stddef.h header for C23 defines __STDC_VERSION_STDDEF_H__ and
unreachable macros multiple times in some cases.
The header doesn't have normal multiple inclusion guard, because it supports
for glibc inclusion with __need_{size_t,wchar_t,ptrdiff_t,wint_t,NULL}.
While the definition of __STDC
Hi!
r15-209 allowed flexible array members inside of unions, but as the
following testcase shows, not everything has been adjusted for that.
Unlike structures, in unions flexible array member (as an extension)
can be any of the members, not just the last one, as in union all
members are effectivel
The build_target_option_node() function may return a cached node when
fndecl having the same effective global_options. Therefore, freeing
memory used in target nodes can lead to a use-after-free issue, as a
target node may be shared by multiple fndecl.
This issue occurs in gcc.target/riscv/target-a
Hi!
This PR is about ubsan error on the c - cx1 + cy1 evaluation in the first
hunk.
The following patch hopefully fixes that by doing the additions/subtractions
in poly_uint64 rather than poly_int64. Or shall we instead perform it in
offset_int and watch for overflows and punt somehow for those?
Hi all,
here is my shot on fixing this PR. The issue is, that when checking if the tree
to associate to is a pointer, gfortran does not respect void* aka c_ptr
correctly. On the tree level this can be done by checking the compatibility of
the data pointed to. If not, then just add an address op.
On Wed, 26 Feb 2025, Jakub Jelinek wrote:
> Hi!
>
> This PR is about ubsan error on the c - cx1 + cy1 evaluation in the first
> hunk.
>
> The following patch hopefully fixes that by doing the additions/subtractions
> in poly_uint64 rather than poly_int64. Or shall we instead perform it in
> off
On Wed, Feb 26, 2025 at 10:27 AM Jakub Jelinek wrote:
>
> Hi!
>
> Various plugin tests fail with --enable-checking=release, because the
> num_events and num_threads methods of simple_diagnostic_path are only used
> inside of #if CHECKING_P code inside of GCC proper and then tested inside of
> some
In particular, 'GLIBCXX_ENABLE_CXX_FLAGS' shouldn't overwrite 'EXTRA_CXX_FLAGS'
(and prepend any additional '--enable-cxx-flags=[...]').
libstdc++-v3/
* acinclude.m4 (GLIBCXX_ENABLE_CXX_FLAGS): Prepend any additional
flags to 'EXTRA_CXX_FLAGS'.
* configure: Regenera
On Feb 24, 2025, Mike Stump wrote:
> I thought I saw one more needing review.
Thanks, Richard Sandiford reviewed it.
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/676031.html
--
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co
On Tue, 25 Feb 2025, Tamar Christina wrote:
> Hi All,
>
> This fixes two PRs on Early break vectorization by delaying the safety checks
> to
> vectorizable_load when the VF, VMAT and vectype are all known.
>
> This patch does add two new restrictions:
>
> 1. On LOAD_LANES targets, where the bu
On Wed, Feb 26, 2025 at 12:22:10PM +0100, Richard Biener wrote:
> On Wed, Feb 26, 2025 at 11:38 AM Jakub Jelinek wrote:
> >
> > On Wed, Feb 26, 2025 at 10:45:37AM +0100, Richard Biener wrote:
> > > OK
> >
> > Unfortunately I've only bootstrapped/regtested it with normal checking.
> > Testing it wi
Hello,
On Tue, Feb 25 2025, Jakub Jelinek wrote:
> On Tue, Feb 25, 2025 at 04:48:37PM +0100, Martin Jambor wrote:
>> --- /dev/null
>> +++ b/gcc/testsuite/g++.dg/lto/pr118785_0.C
>> @@ -0,0 +1,14 @@
>> +// { dg-lto-do link }
>> +// { dg-require-effective-target fpic }x
>
> Not a review, just a nit,
On Wed, 26 Feb 2025, Jakub Jelinek wrote:
> On Wed, Feb 26, 2025 at 10:58:26AM +0100, Richard Biener wrote:
> > > This PR is about ubsan error on the c - cx1 + cy1 evaluation in the first
> > > hunk.
> > >
> > > The following patch hopefully fixes that by doing the
> > > additions/subtractions
>
On Wed, 2025-02-26 at 09:44 +0100, Jakub Jelinek wrote:
> Hi!
>
> Various plugin tests fail with --enable-checking=release, because the
> num_events and num_threads methods of simple_diagnostic_path are only
> used
> inside of #if CHECKING_P code inside of GCC proper and then tested
> inside of
>
* Alexandre Oliva:
> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> index 28338324f0724..d44c2e8cbe6a1 100644
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -2798,6 +2798,9 @@ Target supports the execution of @code{user_msr}
> instructions.
> @item vec
On Wed, Feb 26, 2025 at 1:13 PM Jakub Jelinek wrote:
>
> On Wed, Feb 26, 2025 at 12:22:10PM +0100, Richard Biener wrote:
> > On Wed, Feb 26, 2025 at 11:38 AM Jakub Jelinek wrote:
> > >
> > > On Wed, Feb 26, 2025 at 10:45:37AM +0100, Richard Biener wrote:
> > > > OK
> > >
> > > Unfortunately I've
If you mean the last branch of interleave, I think it is safe because it
leverage the
merge to generate the result, instead of IOR. Only the IOR for final result have
this issue.
Yep, I meant checking overflow before the initial if
if (known_ge (step1, 0) && known_ge (step2, 0)
> and basically adding a new clause here. That would make us fall back to the
> merge scheme in case of overflow instead of making the other scheme more
> complicated.
Oh, I see, that make sense to me, given current implementation of
expand_const_vector is complicated, let me update in v4.
Pa
Hi!
During reading of this file I've noticed a typo in the comment, which
this patch fixes.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
as obvious.
2025-02-27 Jakub Jelinek
* gimple-range-phi.cc (phi_analyzer::process_phi): Fix comment typo,
dpoe
65 matches
Mail list logo
