only looks back one statement. This can be
fixed to look back
until we get an statement that may clobber the reference. If we get a phi
node, then we don't do
anything.
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/118947
gcc/ChangeLog:
* gimp
The case here is we have:
```
char buf[32] = {};
void* ret = aaa();
__builtin_memcpy(ret, buf, 32);
```
And buf does not escape. But we don't prop the zeroing from buf to the memcpy
statement
because optimize_memcpy_to_memset only looks back one statement. This can be
fixed to
imagemagick.
This patch sets the cost back to 3. Next stage1 we can untie addss from the
other operations
and set it correctly.
bootstrapped/regtested x86_64-linux and also benchmarked on SPEC2k17
gcc/ChangeLog:
PR target/119298
* config/i386/x86-tune-costs.h (znver5_cost): Set ADDSS
Backport a few of my patches from the trunk to GCC 14 release branch.
These all have been sitting on the trunk for some time now so it was time
to backport them before a release.
Andrew Pinski (6):
phiopt: Fix VCE moving by rewriting it into cast [PR116098]
aarch64: Fix early ra for -fno-delet
remove them in this patch.
Unlike AVX10.2 options, AVX10.1 options has been there in a major
release, so we have to raise a deprecate warning in GCC 15 and remove
them in GCC 16. At the same time, to align with avx10.2 options, we will
add just removed avx10.1 option back with warning to mention its
On Thu, Mar 6, 2025 at 6:37 AM Jonathan Wakely wrote:
>
> The recently-approved Standard Library Hardening proposal (P3471R4)
> gives pop_front and pop_back member functions hardened preconditions,
> but std::list was missing assertions on them. Our other sequence
> containers do have assertions o
The recently-approved Standard Library Hardening proposal (P3471R4)
gives pop_front and pop_back member functions hardened preconditions,
but std::list was missing assertions on them. Our other sequence
containers do have assertions on those members.
libstdc++-v3/ChangeLog:
* include/bits
Update
commit dd6247cb8fc11a15e23e949092f89d24ff329209
Author: H.J. Lu
Date: Fri Jan 31 12:29:04 2025 +0800
x86: Handle TARGET_INDIRECT_BRANCH_REGISTER for -fno-plt
to change "if (TARGET_X32 ...)" back to "else if (TARGET_X32 ...)".
PR target/118713
* config
assignment in the called procedure.
The proposal is to simply not generate the unpacking / copying-back code
if the actual argument has the PARAMETER attribute. Non-conforming code
should rather be either detected at compile-time (which we do to a
reasonable extent), or we might add (in the future) new
ent in the called procedure.
>
> The proposal is to simply not generate the unpacking / copying-back code
> if the actual argument has the PARAMETER attribute. Non-conforming code
> should rather be either detected at compile-time (which we do to a
> reasonable extent), or we might add (in
.
The proposal is to simply not generate the unpacking / copying-back code
if the actual argument has the PARAMETER attribute. Non-conforming code
should rather be either detected at compile-time (which we do to a
reasonable extent), or we might add (in the future) new checking code
that detects
d: Rewrite add_scope_conflicts_2 to use
> > cache and look back further [PR111422]
> >
> > On Sat, Nov 16, 2024 at 5:25 AM Andrew Pinski
> > wrote:
> > >
> > > After fixing loop-im to do the correct overflow rewriting
> > > for pointer ty
> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, December 31, 2024 1:04 PM
> To: Richard Biener ; Andrew Pinski
>
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH v2 2/3] cfgexpand: Rewrite add_scope_conflicts_2 to use
> cache and loo
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, November 20, 2024 11:28 AM
> To: Andrew Pinski
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH v2 2/3] cfgexpand: Rewrite add_scope_conflicts_2 to use
> cache and look back further [PR111422]
>
&
On 12/14/24 5:16 PM, Jakub Jelinek wrote:
Hi!
The following patch implements what I've mentioned in the 64-bit
location_t thread.
struct tree_exp had unsigned condition_uid member added for something
rarely used (-fcondition-coverage) and even there used only on very small
subset of trees onl
Hi!
The following patch implements what I've mentioned in the 64-bit
location_t thread.
struct tree_exp had unsigned condition_uid member added for something
rarely used (-fcondition-coverage) and even there used only on very small
subset of trees only for the duration of the gimplification.
The
---
htdocs/gcc-15/changes.html | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 80604ab8..6c9ebaac 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -29,7 +29,9 @@ a work-in-progress.
C
On Sat, Nov 16, 2024 at 5:25 AM Andrew Pinski wrote:
>
> After fixing loop-im to do the correct overflow rewriting
> for pointer types too. We end up with code like:
> ```
> _9 = (unsigned long) &g;
> _84 = _9 + 18446744073709551615;
> _11 = _42 + _84;
> _44 = (signed char *) _11;
> ...
> *_44 = 1
it is to be handled by the back-end.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/exp_aggr.adb | 71
1 file changed, 25 insertions(+), 46 deletions(-)
diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb
index c34df840401
After fixing loop-im to do the correct overflow rewriting
for pointer types too. We end up with code like:
```
_9 = (unsigned long) &g;
_84 = _9 + 18446744073709551615;
_11 = _42 + _84;
_44 = (signed char *) _11;
...
*_44 = 10;
g ={v} {CLOBBER(eos)};
...
n[0] = &f;
*_44 = 8;
g ={v} {CLOBBER(eos)};
body Sem_Ch3 is
Rewrite (Object_Definition (N), New_Occurrence_Of (Act_T, Loc));
Freeze_Before (N, Act_T);
- elsif Nkind (E) = N_Function_Call
-and then Constant_Present (N)
-and then Has_Unconstrained_Elements (Etype (E))
- then
- -- The back
On Sat, Nov 2, 2024 at 4:10 PM Andrew Pinski wrote:
>
> Sometimes we get back a full ssa name when looking up the comparison of the
> GIMPLE_COND
> rather than a predicate. We then want to lookup the `val != 0` for the
> predicate.
>
> Note this might happen with other bo
Sometimes we get back a full ssa name when looking up the comparison of the
GIMPLE_COND
rather than a predicate. We then want to lookup the `val != 0` for the
predicate.
Note this might happen with other boolean assignments and COND_EXPR but I am
not sure
if it is as important; I have not
target/i386/mvc10.c fails with -fPIE on ia32 because we omit the
> @PLT mark when calling an alias to an indirect function. Such aliases
> aren't marked as ifunc_resolvers in the cgraph, so the test that would
> have forced the PLT call fails.
> I've arranged for ifunc_resolver
From: Bob Duff
Temporarily disable the warning, because it breaks
SPARK continuous builder
gcc/ada/ChangeLog:
* sem_ch10.adb (Analyze_With_Clause): Temporarily disable warning.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/sem_ch10.adb | 3 ++-
1 file changed, 2 ins
Sorry I had missed calling the test case itself, so fixed that up,
rebased on master and committed.
->8--
Don't bail out early if the offset to a pointer in __builtin_object_size
is a variable, return the wholesize instead since that is a better
fallback for maximum estimate. This should
From: Mikael Morin
Bootstrapped and regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Evaluate the BACK argument of MINLOC/MAXLOC once before the
scalarization loops in the case where the DIM argument is present.
This is a follow-up to r15-1
On Fri, Sep 20, 2024 at 12:40:29PM -0400, Siddhesh Poyarekar wrote:
> Don't bail out early if the offset to a pointer in __builtin_object_size
> is a variable, return the wholesize instead since that is a better
> fallback for maximum estimate. This should keep checks in place for
> fortified func
Don't bail out early if the offset to a pointer in __builtin_object_size
is a variable, return the wholesize instead since that is a better
fallback for maximum estimate. This should keep checks in place for
fortified functions to constrain overflows to at lesat some extent.
gcc/ChangeLog:
gcc.dg/vect/vect-pr111779.c is a case where non-SLP manages to vectorize
using VMAT_ELEMENTWISE but SLP currently refuses because doing a regular
access with permutes would cause excess vector loads with at most one
element used. The following makes us fall back to elementwise accesses
for that
ed_can_use_partial_vectors_p
-= LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo);
-
/* We don't expect to have to roll back to anything other than an empty
set of rgroups. */
gcc_assert (LOOP_VINFO_MASKS (loop_vinfo).is_empty ());
- /* This is the point where we can re-s
AN_USE_PARTIAL_VECTORS_P (loop_vinfo);
-
/* We don't expect to have to roll back to anything other than an empty
set of rgroups. */
gcc_assert (LOOP_VINFO_MASKS (loop_vinfo).is_empty ());
- /* This is the point where we can re-start analysis with SLP forced off. */
-start_over
mode fixed. */
+ if (applying_suggested_uf)
return ok;
/* If there are reduction chains re-trying will fail anyway. */
@@ -3268,8 +3268,9 @@ again:
dump_printf_loc (MSG_NOTE, vect_location,
"re-trying with SLP disabled\n");
- /* Roll bac
h! It's good to see so much progress...
Best regards
Thomas
Thanks to you and Bernhard.
This is what I'm going to push.From 40122a405386a8b67c11bbaad523ffce5c1c7855 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Fri, 2 Aug 2024 14:24:34 +0200
Subject: [PATCH] fortran: Supp
Hi Mikael,
+ gcc_assert (backexpr->expr_type == EXPR_VARIABLE);
drop it, downgrade to checking, or is it worth?
Whether it is worth it, I don't know; it's protecting the access to
backexpr->symtree a few lines down, idependently of the implementation
of maybe_absent_optional_variable.
From: Arnaud Charlet
gcc/ada/
* bindgen.adb (Gen_Main): Put back support for -G
* bindusg.adb (Display): Put back line for -G
* opt.ads (CCG_Mode): Update doc
* switch-b.adb (Scan_Binder_Switches): Put back support for -G
Tested on x86_64-pc-linux-gnu, committed
On 27 July 2024 21:11:19 CEST, Mikael Morin wrote:
>Le 27/07/2024 à 19:23, rep.dot@gmail.com a écrit :
>> On 22 July 2024 20:53:18 CEST, Mikael Morin wrote:
>>> From: Mikael Morin
>>>
>>> Hello,
>>>
>>> this fixes a null pointer der
Le 27/07/2024 à 19:23, rep.dot@gmail.com a écrit :
On 22 July 2024 20:53:18 CEST, Mikael Morin wrote:
From: Mikael Morin
Hello,
this fixes a null pointer dereference with absent optional dummy passed
as BACK argument of MINLOC/MAXLOC.
Tested for regression on x86_64-linux.
OK for
On 22 July 2024 20:53:18 CEST, Mikael Morin wrote:
>From: Mikael Morin
>
>Hello,
>
>this fixes a null pointer dereference with absent optional dummy passed
>as BACK argument of MINLOC/MAXLOC.
>
>Tested for regression on x86_64-linux.
>OK for master?
>
>-- >8
From: Mikael Morin
Hello,
this fixes a null pointer dereference with absent optional dummy passed
as BACK argument of MINLOC/MAXLOC.
Tested for regression on x86_64-linux.
OK for master?
-- >8 --
Protect the evaluation of BACK with a check that the reference is non-null
in case
d catch, thanks.
Thanks for the patch!
Thanks for the review.
Harald
-- 8< --
Move the evaluation of the BACK argument out of the loop in the inline
code
generated for MINLOC or MAXLOC. For that, add a new (scalar) element
associated with BACK to the scalarization loop chain, eval
ks for the patch!
Harald
-- 8< --
Move the evaluation of the BACK argument out of the loop in the inline code
generated for MINLOC or MAXLOC. For that, add a new (scalar) element
associated with BACK to the scalarization loop chain, evaluate the argument
with the context of that element
From: Mikael Morin
Hello,
I discovered this while testing the inline MINLOC/MAXLOC (aka PR90608) patches.
Regression tested on x86_64-linux.
OK for master?
-- 8< --
Move the evaluation of the BACK argument out of the loop in the inline code
generated for MINLOC or MAXLOC. For that, add a
On Wed, Jun 26, 2024 at 09:03:26AM +, Kyrylo Tkachov wrote:
> Hi Andrew,
>
> I’ve tested the fix for PR 115618 from your commit r14-6612-g8d30107455f230
> on the GCC 13 branch.
> I’d like to back port it to that branch.
> Is there any problem with that I should be awar
On Thu, Jun 27, 2024 at 10:30 AM liuhongt wrote:
>
> gcc/ChangeLog
In PR115659 Kewen notes that ISEL (and possibly folding) could do a
better job with
these. In addition to the mentioned issues we can also try whether the target
can handle an alternate mask mode. So instead of gating with
gcc/ChangeLog
PR target/115517
* config/i386/sse.md
(*_cvtmask2_not): New pre_reload
splitter.
(*_cvtmask2_not): Ditto.
(*avx2_pcmp3_6): Ditto.
(*avx2_pcmp3_7): Ditto.
---
gcc/config/i386/sse.md | 97 ++
Hi Andrew,
I’ve tested the fix for PR 115618 from your commit r14-6612-g8d30107455f230 on
the GCC 13 branch.
I’d like to back port it to that branch.
Is there any problem with that I should be aware of?
It applies cleanly and tests fine.
Thanks,
Kyrill
From: Piotr Trojanek
Code cleanup; semantics is unaffected.
gcc/ada/
* exp_put_image.adb (Build_Record_Put_Image_Procedure): Remove
useless conversions.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/exp_put_image.adb | 6 ++
1 file changed, 2 insertions(
We have a sanity check in the irange storage code to make sure that
reading back a cache entry we have just written to yields exactly the
same range. There's no need to do this only for integers. This patch
moves the code to a more generic place.
However, doing so tickles a latent bug i
Thank you for the patch review! I'm including below the updated version.
I pushed this, thanks.
R.
--
Thiago
From 78e70788da5ed849d7828b0219d3aa8955ad0fea Mon Sep 17 00:00:00 2001
From: Thiago Jung Bauermann
Date: Sat, 13 Jan 2024 14:28:07 -0300
Subject: [PATCH v2] testsuite: Turn erro
If that works, ok with that change.
I took the opportunity to request commit access to the GCC repo so that
I can commit the patch myself. Sorry for the delay. I'll commit it as
soon as I get it.
Thank you for the patch review! I'm including below the updated version.
--
Thiago
>From 7
On 13/01/2024 20:46, Thiago Jung Bauermann wrote:
> Since commit 2c3db94d9fd ("c: Turn int-conversion warnings into
> permerrors") the test fails with errors such as:
>
> FAIL: gcc.target/arm/acle/cde-mve-error-2.c -O0 (test for errors, line
> 32)
> FAIL: gcc.target/arm/acle/cde-mve-error
> "Jeff" == Jeff Law writes:
>> I don't know how to fix this.
Jeff> Me neither, but I can suggest a hacky workaround.
FTR, I asked Jakub on irc and he fixed it, so thankfully I didn't have
to resort to the hack :-)
thanks,
Tom
On Wed, Feb 28, 2024 at 5:35 PM Tom Tromey wrote:
>
> > "Andrew" == Andrew Pinski writes:
>
> Andrew> I don't know how to update the script server side after it is
> Andrew> committed in git. the checker script is located in git though:
>
> Thanks, I didn't realize it was there.
>
> Could you
> "Andrew" == Andrew Pinski writes:
Andrew> I don't know how to update the script server side after it is
Andrew> committed in git. the checker script is located in git though:
Thanks, I didn't realize it was there.
Could you check in your patch?
IMO it seems obvious.
Tom
ERR: invalid PR component in subject: "Fix PR libcc1/113977"
> >
> > I guess this script isn't in sync with the components in bugzilla.
> >
> > I don't know how to fix this.
> Me neither, but I can suggest a hacky workaround. Change the component
>
n bugzilla.
I don't know how to fix this.
Me neither, but I can suggest a hacky workaround. Change the component
in bugzilla to something the pre-commit hooks understand, push the fix,
then change the component back a little while later and adjust the
ChangeLog after it gets generated overnight. Ugly as sin.
jeff
> "Jeff" == Jeff Law writes:
Jeff> Given this is all libcc1 related and thus primarily of interest to
Jeff> gdb, if you're happy with it, then it's OK for the trunk.
Thank you.
I could not push this because:
remote: *** ChangeLog format failed:
remote: *** ERR: invalid PR component in subj
27;s not run at all, it's
also clear that removing it doesn't cause any regressions in gdb.
However, rather than remove it, this patch changes it to handle
ERROR_MARK better, and then to fall back to the v0 code if the new
code fails to find the type it's lookin
ear that removing it doesn't cause any regressions in gdb.
However, rather than remove it, this patch changes it to handle
ERROR_MARK better, and then to fall back to the v0 code if the new
code fails to find the type it's looking for.
2024-02-26 Tom Tromey
* libcc1plugin.cc (saf
Hi!
On 2018-12-12T11:52:52+, Andrew Stubbs wrote:
> This patch contains the major part of the GCN back-end. [...]
> --- /dev/null
> +++ b/gcc/config/gcn/gcn.c
> +void
> +gcn_hsa_declare_function_name (FILE *file, const char *name, tree)
> +{
> + /* Determine count o
Hi!
On 2018-12-12T11:52:52+, Andrew Stubbs wrote:
> This patch contains the major part of the GCN back-end. [...]
> --- /dev/null
> +++ b/gcc/config/gcn/gcn.h
> +#define FIRST_SGPR_REG 0
> +#define SGPR_REGNO(N)((N)+FIRST_SGPR_REG)
> +#de
Since commit 2c3db94d9fd ("c: Turn int-conversion warnings into
permerrors") the test fails with errors such as:
FAIL: gcc.target/arm/acle/cde-mve-error-2.c -O0 (test for errors, line 32)
FAIL: gcc.target/arm/acle/cde-mve-error-2.c -O0 (test for errors, line 33)
FAIL: gcc.target/arm/
Hi,
I noticed that commit r14-6192 can't help PR112606 #c3 as
it only takes care of SF/DF but TF/KF can still suffer the
issue. Similar to commit r14-6192, this patch is to take
care of copysign3 with IEEE128 as well.
Bootstrapped and regtested on powerpc64-linux-gnu P8/P9
and powerpc64le-linux-
few operations as possible for a canonical form (-abs (x)
> is 2 GIMPLE statements, copysign (x, -1) is just one), I must say
> I don't really like that being done on RTL as well (or at least
> not canonicalizing (COPYSIGN x, negative) back to (NEG (ABS x))),
> because on most targe
nce it matches the GIMPLE
> goal of as few operations as possible for a canonical form (-abs (x)
> is 2 GIMPLE statements, copysign (x, -1) is just one), I must say
> I don't really like that being done on RTL as well (or at least
> not canonicalizing (COPYSIGN x, negative) back to (N
> -Original Message-
> From: Jakub Jelinek
> Sent: Monday, November 27, 2023 8:13 AM
> To: Tamar Christina
> Cc: Xi Ruoyao ; Segher Boessenkool
> ; David Edelsohn ; gcc-
> patc...@gcc.gnu.org; Andrew Pinski
> Subject: Re: [PATCH] rs6000: Canonicalize copysign (x,
On Mon, Nov 27, 2023 at 07:55:52AM +, Tamar Christina wrote:
> > For POPCOUNT I've introduced recently a way to provide custom expand_*
> > function and decide there what optimizations to use, even when it otherwise
> > is an integral unary optab ifn.
> >
>
> Oh that sounds interesting, do yo
> On Sat, Nov 25, 2023 at 12:03:56PM +, Tamar Christina wrote:
> > For the C99 versions of copysign, expand_COPYSIGN has optimized
> expansions inplace.
> > One of the hooks there forces it to abs/neg. There is also code in
> > place for if the target prefers integer expansion over floating p
On Sat, Nov 25, 2023 at 12:03:56PM +, Tamar Christina wrote:
> For the C99 versions of copysign, expand_COPYSIGN has optimized expansions
> inplace.
> One of the hooks there forces it to abs/neg. There is also code in place
> for if the target
> prefers integer expansion over floating point
> -Original Message-
> From: Xi Ruoyao
> Sent: Saturday, November 25, 2023 10:43 AM
> To: Jakub Jelinek ; Segher Boessenkool
> ; David Edelsohn
> Cc: gcc-patches@gcc.gnu.org; Tamar Christina ;
> Andrew Pinski
> Subject: Re: [PATCH] rs6000: Canonicalize copysign
as possible for a canonical form (-abs (x)
> is 2 GIMPLE statements, copysign (x, -1) is just one), I must say
> I don't really like that being done on RTL as well (or at least
> not canonicalizing (COPYSIGN x, negative) back to (NEG (ABS x))),
> because on most targets most of flo
, copysign (x, -1) is just one), I must say
I don't really like that being done on RTL as well (or at least
not canonicalizing (COPYSIGN x, negative) back to (NEG (ABS x))),
because on most targets most of floating point constants need to be loaded
from memory, there are a few exceptions but -1 is
orced the PLT call fails.
I've arranged for ifunc_resolver to be back-propagated to aliases, and
relaxed the test that required the ifunc attribute to be attached to
directly the decl, rather than taken from an aliased decl, when the
ifunc_resolver bit is set.
Regstrapped on x86_64-linux-gnu, a
On Wed, 4 Oct 2023 at 02:49, Hans-Peter Nilsson wrote:
> (Just before sending, I noticed you replied off-list; I
> won't add back gcc-patches to cc here myself, but please
> feel free to do it, if you choose to reply.)
>
Sorry, it was a typo of mine, I meant to reply to the
> From: Christophe Lyon
> Date: Tue, 3 Oct 2023 15:20:39 +0200
> The patch passed almost all our CI configurations, except arm-eabi when
> testing with
> -mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=auto
> where is causes these failures:
> FAIL: 29_atomics/atomic_flag/clear/1.
Hi!
On Tue, 26 Sept 2023 at 16:34, Hans-Peter Nilsson wrote:
> Tested cris-elf, native x86_64-pc-linux-gnu and arm-eabi.
>
> For arm-eabi, notably lacking any atomic support for the
> default multilib, with --target_board=arm-sim it regressed
> 29_atomics/atomic_flag/cons/value_init.cc with the
On 9/26/23 08:34, Hans-Peter Nilsson wrote:
Tested cris-elf, native x86_64-pc-linux-gnu and arm-eabi.
For arm-eabi, notably lacking any atomic support for the
default multilib, with --target_board=arm-sim it regressed
29_atomics/atomic_flag/cons/value_init.cc with the expected
linker failure
Tested cris-elf, native x86_64-pc-linux-gnu and arm-eabi.
For arm-eabi, notably lacking any atomic support for the
default multilib, with --target_board=arm-sim it regressed
29_atomics/atomic_flag/cons/value_init.cc with the expected
linker failure due to lack of __atomic_test_and_set - which
is a
nd problem with Fortran literals and -fpic.
+ Fix x86 back end problem with Fortran literals and -fpic.
Fix some of the problems with negative subscripts for g77 on
alphas.
Fixes for Fortran builds on cygwin32/mingw32.
diff --git a/htdocs/egcs-1.1/features.html b/htdoc
; bootstrap/82856 has been added. gcc/doc/install.texi has been updated
> to mention the new versions required.
..., but not removed the Perl "5.6.25" 5.26 requirement. OK to push the
attached "Back to requiring "Perl version 5.6.1 (or later)" [PR82856]"?
(L
gcc/ChangeLog:
PR target/109328
* config/riscv/t-riscv: Add missing dependencies.
Co-authored-by: Andrew Pinski
---
gcc/config/riscv/t-riscv | 43
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git a/gcc/config/riscv/t-riscv b/
Hi Mikael,
Am 29.01.23 um 17:21 schrieb Mikael Morin:
Hello,
this is a fix for a gcc-12 ICE regression.
This ICE rings a bell to me, and I think the change by Tobias which
triggers it only uncovers a bug that can also happen independently in
other cases.
The problem is resolution of maxloc exp
?From e61e2a51e1859f884125670010337f34265997b8 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Sun, 29 Jan 2023 14:38:08 +0100
Subject: [PATCH] fortran: Set name for *LOC default BACK argument [PR108450]
This change fixes an ICE caused by the double resolution of MINLOC,
MAXLOC and FINDLOC expressions which
From: Eric Botcazou
This needs to be done for all expressions with class-wide type.
gcc/ada/
* exp_ch3.adb (Make_Allocator_For_Return): Put back an interface
conversion for expressions with non-interface class-wide type.
Tested on x86_64-pc-linux-gnu, committed on master
When CPLUSPLUS_CPP_SPEC is set to a string literal it is not possible to
modify it through external spec files by renaming the original cpp spec
and replacing it because the compiler cpp_spec will still point to the
original, renamed cpp spec. Not defining CPLUSPLUS_CPP_SPEC makes gcc.cc
fall back
When reading back from the global store, we must clear the NAN bit if
necessary. The reason it's not happening is because the constructor
sets a NAN by default (when HONOR_NANS). We must be careful to clear
the NAN bit if the original range didn't have a NAN.
I have commented the rea
4705.
> > Since GCC 4.8.6 doesn't support constexpr, we should change it back to
> > CONSTEXPR.
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv-vector-builtins-bases.cc: Change constexpr back
> > to CONSTEXPR.
> > * config/riscv/riscv
On Fri, Oct 28, 2022, 08:49 Richard Biener
wrote:
> On Fri, Oct 28, 2022 at 12:45 AM Jeff Law wrote:
> >
> >
> > On 10/25/22 15:01, Aldy Hernandez via Gcc-patches wrote:
> > > [Richi/Jakub/FP experts, does this sound like the right solution, or
> am I
> > > missing some subtle IPA/inlining issue
On Fri, Oct 28, 2022 at 8:48 AM Richard Biener
wrote:
>
> On Fri, Oct 28, 2022 at 12:45 AM Jeff Law wrote:
> >
> >
> > On 10/25/22 15:01, Aldy Hernandez via Gcc-patches wrote:
> > > [Richi/Jakub/FP experts, does this sound like the right solution, or am I
> > > missing some subtle IPA/inlining is
On Fri, Oct 28, 2022 at 12:45 AM Jeff Law wrote:
>
>
> On 10/25/22 15:01, Aldy Hernandez via Gcc-patches wrote:
> > [Richi/Jakub/FP experts, does this sound like the right solution, or am I
> > missing some subtle IPA/inlining issue?]
> >
> > The problem here is that we're inlining a global range
On 10/27/22 08:41, juzhe.zh...@rivai.ai wrote:
From: Ju-Zhe Zhong
According to
https://github.com/gcc-mirror/gcc/commit/f95d3d5de72a1c43e8d529bad3ef59afc3214705.
Since GCC 4.8.6 doesn't support constexpr, we should change it back to
CONSTEXPR.
gcc/ChangeLog:
* config/riscv/
On 10/25/22 15:01, Aldy Hernandez via Gcc-patches wrote:
[Richi/Jakub/FP experts, does this sound like the right solution, or am I
missing some subtle IPA/inlining issue?]
The problem here is that we're inlining a global range with NANs into
a function that has been tagged with __attribute__((
From: Ju-Zhe Zhong
According to
https://github.com/gcc-mirror/gcc/commit/f95d3d5de72a1c43e8d529bad3ef59afc3214705.
Since GCC 4.8.6 doesn't support constexpr, we should change it back to
CONSTEXPR.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc: Change constexpr ba
OR_NANS, but we must
> + // make sure to set the NAN sign if known.
> + if (HONOR_NANS (type) && (m_pos_nan ^ m_neg_nan) == 1)
> +r.update_nan (m_neg_nan);
> }
>
> bool
> --
> 2.37.3
>
From 89eaccbc4b1e5ff7fea2eb4e3fb5870c6ca4160b Mon Sep 17 00:00:00 2001
Fro
[Richi/Jakub/FP experts, does this sound like the right solution, or am I
missing some subtle IPA/inlining issue?]
The problem here is that we're inlining a global range with NANs into
a function that has been tagged with __attribute__((optimize
("-ffinite-math-only"))). As the global range is co
As a side-effect, graphds_scc constructs a vector in which all
nodes in an SCC are listed consecutively. This can be useful
information, so that the patch adds an optional pass-back parameter
for it. The interface is similar to the one for graphds_dfs.
gcc/
* graphds.cc (graphds_scc
Tested powerpc64le-linux, pushed to trunk. Worth backporting.
-- >8 --
Currently we fail to notice integer overflow when parsing a
back-reference expression, or when converting the parsed result from
long to int. This changes the result to be int, so no conversion is
needed, and uses
;>> wrote:
>>>
>>>
>>>
>>>> On May 10, 2022, at 1:12 AM, Richard Biener wrote:
>>>>
>>>> On Mon, 9 May 2022, Uros Bizjak wrote:
>>>>
>>>>> On Mon, May 9, 2022 at 5:44 PM Qing Zhao wrote:
>>&g
>> On Mon, May 9, 2022 at 5:44 PM Qing Zhao wrote:
> >>>>
> >>>> Another question:
> >>>>
> >>>> I think that this patch might need to be back ported to Gcc12 and GCC11.
> >>>>
> >>>> What?s your opini
1 - 100 of 652 matches
Mail list logo
