On 19/09/2022 17:33, Thomas Neumann wrote:
Can you try if the patch below fixes the problem? It keeps the data
structures alive at shutdown, though, which will probably make some leak
detectors unhappy.
Alternatively we could simply remove the gcc_assert (ob) in line 285 of
that file. As far
On Mon, Sep 19, 2022 at 3:42 PM Richard Biener
wrote:
>
> On Mon, Sep 19, 2022 at 2:52 PM Aldy Hernandez wrote:
> >
> > On Mon, Sep 19, 2022 at 10:14 AM Richard Biener
> > wrote:
> > >
> > > On Mon, Sep 19, 2022 at 9:59 AM Aldy Hernandez wrote:
> > > >
> > > > ISTM that a specifically
On Mon, Sep 19, 2022 at 4:04 PM Michael Matz wrote:
>
> Hello,
>
> On Mon, 19 Sep 2022, Richard Biener via Gcc-patches wrote:
>
> > > but I guess it's good we do the right thing for correctness sake, and
> > > if it ever gets used by someone else.
> > >
> > > >
> > > > That said,
On Mon, Sep 19, 2022 at 3:45 PM Richard Biener
wrote:
>
> On Mon, Sep 19, 2022 at 3:04 PM Aldy Hernandez wrote:
> >
> > On Mon, Sep 19, 2022 at 9:37 AM Richard Biener
> > wrote:
> > >
> > > On Sat, Sep 17, 2022 at 10:25 AM Aldy Hernandez via Gcc-patches
> > > wrote:
> > > >
> > > > Jakub has
On Mon, Sep 12, 2022 at 4:06 PM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> The following patch implements the compiler part of C++23
> P1467R9 - Extended floating-point types and standard names compiler part
> by introducing _Float{16,32,64,128} as keywords and builtin types
> like they are
On Tue, Sep 20, 2022 at 10:23 AM liuhongt wrote:
>
> The codes in vectorizable_induction for slp_node assume all phi_info
> have same induction type(vect_step_op_add), but since we support
> nonlinear induction, it could be wrong handled.
> So the patch return false when slp_node has mixed
On Fri, Sep 16, 2022 at 9:38 PM Alexander Monakov via Gcc-patches
wrote:
>
> On Fri, 16 Sep 2022, Uros Bizjak via Gcc-patches wrote:
>
> > On Fri, Sep 16, 2022 at 3:32 AM Jeff Law via Gcc-patches
> > wrote:
> > >
> > >
> > > On 9/15/22 19:06, liuhongt via Gcc-patches wrote:
> > > > There's
The codes in vectorizable_induction for slp_node assume all phi_info
have same induction type(vect_step_op_add), but since we support
nonlinear induction, it could be wrong handled.
So the patch return false when slp_node has mixed induction type.
Note codes in other place will still vectorize
On Tue, Sep 20, 2022 at 10:14 AM liuhongt wrote:
>
> Here's list the patch supported.
> rint/nearbyint/ceil/floor/trunc/lrint/lceil/lfloor/round/lround.
>
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/106910
> *
Here's list the patch supported.
rint/nearbyint/ceil/floor/trunc/lrint/lceil/lfloor/round/lround.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}
Ok for trunk?
gcc/ChangeLog:
PR target/106910
* config/i386/mmx.md (nearbyintv2sf2): New expander.
(rintv2sf2):
[PATCH, rs6000] Eliminate TARGET_CTZ,TARGET_FCTIDZ,FCTIWUZ defines
Hi,
This is the first of a batch of changes that eliminate a number
of define TARGET_foo entries we have collected over time.
TARGET_CTZ is defined as TARGET_MODULO, and has a low number
of uses. References to TARGET_CTZ
Could you provide some data including code size and performance? add is
frequently used patten, so we should more careful when changing that.
Kevin Lee 於 2022年9月19日 週一，18:07寫道：
> Hello GCC,
> Started from Jim Wilson's patch in
>
>
Hi Jason,
Do you have any more feedback for this patch?
Thanks,
Eugene
-Original Message-
From: Eugene Rozenfeld
Sent: Thursday, September 08, 2022 5:46 PM
To: Jason Merrill ; gcc-patches@gcc.gnu.org
Cc: Andi Kleen ; Jan Hubicka
Subject: RE: [EXTERNAL] Re: [PING][PATCH] Add
Le 19/09/2022 à 21:46, Harald Anlauf a écrit :
Am 18.09.22 um 22:55 schrieb Mikael Morin:
Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
Assumed shape will be on the easy side,
while assumed size likely needs to be excluded for clobbering.
Isn’t it the converse that is true?
Assumed shape
Dear all,
the following patch was submitted by Jose but never reviewed:
https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html
Before, we didn't set function attributes properly when
passing polymorphic pointers, which could lead to
mis-optimization.
The patch is technically fine and
Am 18.09.22 um 22:55 schrieb Mikael Morin:
Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
Assumed shape will be on the easy side,
while assumed size likely needs to be excluded for clobbering.
Isn’t it the converse that is true?
Assumed shape can be non-contiguous so have to be excluded, but
On Linux/x86_64,
de40fab2f32b03c3d8f69f72c7f1e38694f93d35 is the first bad commit
commit de40fab2f32b03c3d8f69f72c7f1e38694f93d35
Author: Francois-Xavier Coudert
Date: Sun Sep 4 18:24:23 2022 +0200
Fortran: add IEEE_MODES_TYPE, IEEE_GET_MODES and IEEE_SET_MODES
caused
FAIL:
On Mon, Sep 19, 2022 at 02:25:59PM -0400, Marek Polacek via Gcc-patches wrote:
> A trivial fix for maybe_warn_for_null_address where we print an
> inform note without first checking the return value of a warning
> call.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/12?
>
>
A trivial fix for maybe_warn_for_null_address where we print an
inform note without first checking the return value of a warning
call.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/12?
PR c/106947
gcc/c/ChangeLog:
* c-typeck.cc (maybe_warn_for_null_address): Don't
Hi,
> Hmm, not really convinced, but that's a possible interpretation, I guess.
It seems to me to be in line with the handling of all other IEEE intrinsics:
the user is responsible for querying support before calling any relevant
routine. I admit that there is no explicit language in the case
Le 19/09/2022 à 18:17, FX a écrit :
Hi,
2. Add the optional RADIX argument to IEEE_SET_ROUNDING_MODE and
IEEE_GET_ROUNDING_MODE. It is unused for now, because we do not support
floating-point radices other than 2.
If we accept the argument, we have to support it somehow.
So for
The linker script should not be prefixed with "-Wl," - it's not an
input file and does not interfere with the new dump output filename
strategy.
gcc/testsuite/ChangeLog:
* lib/gcc-defs.exp: Do not prefix linker script with "-Wl,".
Signed-off-by: Torbjörn SVENSSON
---
On Sat, Sep 17, 2022 at 10:58:54AM +0200, Jason Merrill wrote:
> > I thought it is fairly important because __float128 has been around in GCC
> > for 19 years already. To be precise, I think e.g. for x86_64 GCC 3.4
> > introduced it, but mangling was implemented only in GCC 4.1 (2006), before
>
After moving the testglue in commit 9d503515cee, the jump to exit and
abort is too far for the 'b' instruction on Cortex-M0. As most of the
C code would generate a 'bl' instruction instead of a 'b'
instruction, lets do the same for the inline assembler.
The error seen without this patch:
In some scenarios (e.g., when mixing gcc and clang code), it can
happen that frames are deregistered after the lookup structure
has already been destroyed. That in itself would be fine, but
it triggers an assert in __deregister_frame_info_bases that
expects to find the frame.
To avoid that, we
In the test case, it's clearly written that intrinsics is not
implemented on arm*. A simple xfail does not help since there are
link error and that would cause an UNRESOLVED testcase rather than
XFAIL.
By chaning to dg-skip-if, the entire test case is omitted.
gcc/testsuite/ChangeLog:
*
Hi,
>> 2. Add the optional RADIX argument to IEEE_SET_ROUNDING_MODE and
>> IEEE_GET_ROUNDING_MODE. It is unused for now, because we do not support
>> floating-point radices other than 2.
> If we accept the argument, we have to support it somehow.
> So for IEEE_GET_ROUNDING_MODE (*, 10), we
[PATCH, rs6000] Split TARGET_POWER8 from TARGET_DIRECT_MOVE [PR101865]
Hi,
The _ARCH_PWR8 define is conditional on TARGET_DIRECT_MOVE,
and can be disabled by dependent options when it should not be.
This manifests in the issue seen in PR101865 where -mno-vsx
mistakenly disables _ARCH_PWR8.
Hello GCC,
Started from Jim Wilson's patch in
https://github.com/riscv-admin/riscv-code-speed-optimization/blob/main/projects/gcc-optimizations.adoc
for the large stack frame optimization problem, this augmented patch
generates less instructions for cases such as
[PATCH, rs6000] Tests of ARCH_PWR8 and -mno-vsx option.
Hi,
This adds an assortment of tests to exercise the -mno-vsx option and
confirm the impacts on the ARCH_PWR8 define.
These are based on and inspired by PR 101865, which
reports that _ARCH_PWR8 is disabled when -mno-vsx
is passed on the
Hello,
I'm coming (late) to this.
Le 31/08/2022 à 20:29, FX via Fortran a écrit :
This adds new F2018 features, that are not really enabled (because their
runtime support is optional).
(...)
2. Add the optional RADIX argument to IEEE_SET_ROUNDING_MODE and
IEEE_GET_ROUNDING_MODE. It is
At least when building LibreOffice with Clang (16 trunk) with ASan and
UBsan enabled against libstdc++ (with --gcc-toolchain and
LD_LIBRARY_PATH to pick up a libstdc++ trunk build including this change
at build and run-time), at least one of the LibreOffice tests executed
during the build
Yeah, currently the internal cache isnt really wired into the
fold_using_range as its is suppose to be a consistent internal state.
so its not currently expecting to work in a situation here what it
thinks is global state might change.
I figured I better go back and watch your entire VN
On Mon, 19 Sept 2022 at 10:06, Richard Biener wrote:
>
> On Mon, Sep 19, 2022 at 10:57 AM Georg Johann Lay wrote:
> >
> >
> >
> > Am 19.09.22 um 09:51 schrieb Richard Biener:
> > > On Sun, Sep 18, 2022 at 7:40 PM Georg Johann Lay wrote:
> > >>
> > >> Hello,
> > >>
> > >> this patch fixed PR
On 19/09/2022 15:55, Thomas Neumann wrote:
Apparently a registered frame is not found when deregistering, which
triggers an assert. I will debug this. Could you send me a script or a
description on how to reproduce the issue?
Thanks a lot! I'm in the process of checking whether a more
Hello,
On Mon, 19 Sep 2022, Richard Biener via Gcc-patches wrote:
> > but I guess it's good we do the right thing for correctness sake, and
> > if it ever gets used by someone else.
> >
> > >
> > > That said, 'set_nonnegative' could be interpreted to be without
> > > NaNs?
> >
> > Sounds good to
I haven't debugged this in any way, nor checked whether it only impacts
exactly my below scenario, but noticed the following:
At least when building LibreOffice with Clang (16 trunk) with ASan and
UBsan enabled against libstdc++ (with --gcc-toolchain and
LD_LIBRARY_PATH to pick up a libstdc++
It looks like some xtreme-header-* tests are failing after the libstdc++
change r13-2158-g02f6b405f0e9dc ultimately because we're neglecting
to stream PACK_EXPANSION_EXTRA_ARGS, which leads to false equivalences
of different partial instantiations of _TupleConstraints::__constructible.
Tested on
On 16/09/2022 12:19, Thomas Neumann via Gcc-patches wrote:
The __register_frame/__deregister_frame functions are used to register
unwinding frames from JITed code in a sorted list. That list itself
is protected by object_mutex, which leads to terrible performance
in multi-threaded code and is
* Jakub Jelinek:
> On Mon, Sep 19, 2022 at 11:25:13AM +0200, Florian Weimer wrote:
>> * Jakub Jelinek:
>>
>> > The disadvantage of the patch is that touching reg[x].loc and how[x]
>> > now means 2 cachelines rather than one as before, and I admit beyond
>> > bootstrap/regtest I haven't
On Mon, Sep 19, 2022 at 3:04 PM Aldy Hernandez wrote:
>
> On Mon, Sep 19, 2022 at 9:37 AM Richard Biener
> wrote:
> >
> > On Sat, Sep 17, 2022 at 10:25 AM Aldy Hernandez via Gcc-patches
> > wrote:
> > >
> > > Jakub has mentioned that for -funsafe-math-optimizations we may flush
> > > denormals
On Mon, Sep 19, 2022 at 2:52 PM Aldy Hernandez wrote:
>
> On Mon, Sep 19, 2022 at 10:14 AM Richard Biener
> wrote:
> >
> > On Mon, Sep 19, 2022 at 9:59 AM Aldy Hernandez wrote:
> > >
> > > ISTM that a specifically nonnegative range should not contain -NAN,
> > > otherwise signbit_p() would
On Mon, Sep 19, 2022 at 3:04 PM Aldy Hernandez wrote:
>
> On Mon, Sep 19, 2022 at 9:37 AM Richard Biener
> wrote:
> >
> > On Sat, Sep 17, 2022 at 10:25 AM Aldy Hernandez via Gcc-patches
> > wrote:
> > >
> > > Jakub has mentioned that for -funsafe-math-optimizations we may flush
> > > denormals
On Mon, Sep 19, 2022 at 9:37 AM Richard Biener
wrote:
>
> On Sat, Sep 17, 2022 at 10:25 AM Aldy Hernandez via Gcc-patches
> wrote:
> >
> > Jakub has mentioned that for -funsafe-math-optimizations we may flush
> > denormals to zero, in which case we need to be careful to extend the
> > ranges to
On Mon, Sep 19, 2022 at 10:14 AM Richard Biener
wrote:
>
> On Mon, Sep 19, 2022 at 9:59 AM Aldy Hernandez wrote:
> >
> > ISTM that a specifically nonnegative range should not contain -NAN,
> > otherwise signbit_p() would return false, because we'd be unsure of the
> > sign.
> >
> > Do y'all
Committed as
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4637a1d293c978816ad622ba33e3a32a78640edd
FX
> Le 10 sept. 2022 à 12:21, FX a écrit :
>
> ping
> (with fix for the typo Bernhard noticed)
>
> <0001-Fortran-F2018-rounding-modes-changes.patch>
>
>> Le 31 août 2022 à 20:29, FX a
Hi!
On Sat, Sep 17, 2022 at 01:30:08PM +0200, Jason Merrill wrote:
Below is an updated patch on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601788.html
patch.
> Ah, OK. I don't think you need to check for C++23 or CALL_EXPR at all, just
> CONVERSION_RANK of the other
Hi Mikael,
> Looks good, thanks.
Thank you for your reviews. This patch is committed to trunk:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4637a1d293c978816ad622ba33e3a32a78640edd
FX
The following is an attempt to utilize ranger for simplification
of conditionals during value-numbering. It fails the added
testcase because it seems the fur source is only involved when
processing the stmt to be folded but not when filling the cache
of ranges on the operand use->def chain.
When
On Mon, Sep 19, 2022 at 11:25:13AM +0200, Florian Weimer wrote:
> * Jakub Jelinek:
>
> > The disadvantage of the patch is that touching reg[x].loc and how[x]
> > now means 2 cachelines rather than one as before, and I admit beyond
> > bootstrap/regtest I haven't benchmarked it in any way.
* Jakub Jelinek:
> The disadvantage of the patch is that touching reg[x].loc and how[x]
> now means 2 cachelines rather than one as before, and I admit beyond
> bootstrap/regtest I haven't benchmarked it in any way. Florian, could
> you retry whatever you measured to get at the 40% of time spent
On Mon, Sep 19, 2022 at 10:57:25AM +0200, Richard Biener wrote:
> For even more uglification and avoiding of the cache effect mentioned below
> we could squeeze the 4 bits into the union members, at least on 64bit
> platforms
> (probably not on 32bit ones) ...
Maybe, but it would limit the
On Mon, Sep 19, 2022 at 10:57 AM Georg Johann Lay wrote:
>
>
>
> Am 19.09.22 um 09:51 schrieb Richard Biener:
> > On Sun, Sep 18, 2022 at 7:40 PM Georg Johann Lay wrote:
> >>
> >> Hello,
> >>
> >> this patch fixed PR target/99184 which incorrectly rounded during 64-bit
> >> (long) double to
On Mon, Sep 19, 2022 at 9:59 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> The following patch implements something that has Florian found as
> low hanging fruit in our unwinder and has been discussed in the
> https://gcc.gnu.org/wiki/cauldron2022#cauldron2022talks.inprocess_unwinding_bof
>
Am 19.09.22 um 09:51 schrieb Richard Biener:
On Sun, Sep 18, 2022 at 7:40 PM Georg Johann Lay wrote:
Hello,
this patch fixed PR target/99184 which incorrectly rounded during 64-bit
(long) double to 16-bit and 32-bit integers.
The patch just removes the respective roundings from
On Mon, Sep 19, 2022 at 09:37:22AM +0200, Richard Biener wrote:
> On Sat, Sep 17, 2022 at 10:25 AM Aldy Hernandez via Gcc-patches
> wrote:
> >
> > Jakub has mentioned that for -funsafe-math-optimizations we may flush
> > denormals to zero, in which case we need to be careful to extend the
> >
On Mon, Sep 19, 2022 at 9:59 AM Aldy Hernandez wrote:
>
> ISTM that a specifically nonnegative range should not contain -NAN,
> otherwise signbit_p() would return false, because we'd be unsure of the
> sign.
>
> Do y'all agree?
what tree_expr_nonnegative_p actually means isn't 100% clear. For
ISTM that a specifically nonnegative range should not contain -NAN,
otherwise signbit_p() would return false, because we'd be unsure of the
sign.
Do y'all agree?
PR 68097/tree-optimization
gcc/ChangeLog:
* value-range.cc (frange::set_nonnegative): Set +NAN.
On Mon, Sep 19, 2022 at 9:31 AM Mikael Morin wrote:
>
> Le 18/09/2022 à 12:48, Richard Biener a écrit :
> >
> >> Does *([1]) count as a pointer dereference?
> >
> > Yes, technically.
> >
> >> Even in the original dump it is already simplified to a straight a[1].
> >
> > But this not anymore.
Hi!
The following patch implements something that has Florian found as
low hanging fruit in our unwinder and has been discussed in the
https://gcc.gnu.org/wiki/cauldron2022#cauldron2022talks.inprocess_unwinding_bof
talk.
_Unwind_FrameState type seems to be (unlike the pre-GCC 3 frame_state
which
On Sun, Sep 18, 2022 at 7:40 PM Georg Johann Lay wrote:
>
> Hello,
>
> this patch fixed PR target/99184 which incorrectly rounded during 64-bit
> (long) double to 16-bit and 32-bit integers.
>
> The patch just removes the respective roundings from
> libf7-asm.sx::to_integer and ::to_unsigned.
On Sun, Sep 18, 2022 at 11:09 AM Torbjörn SVENSSON via Gcc-patches
wrote:
>
> When the -fzero-call-used-regs command line option is used with an
> unsupported value, indicate that it's a value problem instead of an
> option problem.
>
> Without the patch, the error is:
> In file included from
On Sat, Sep 17, 2022 at 10:25 AM Aldy Hernandez via Gcc-patches
wrote:
>
> Jakub has mentioned that for -funsafe-math-optimizations we may flush
> denormals to zero, in which case we need to be careful to extend the
> ranges to the appropriate zero. This patch does exactly that. For a
> range
Le 18/09/2022 à 12:48, Richard Biener a écrit :
Does *([1]) count as a pointer dereference?
Yes, technically.
Even in the original dump it is already simplified to a straight a[1].
But this not anymore. The check can probably be relaxed, it stems from the
dual purpose of CLOBBER.
So
Hi!
On Sat, Sep 17, 2022 at 01:23:59AM +0200, Jason Merrill wrote:
> I wonder why we don't give an error when setting the
> conflicting_specifiers_p flag in cp_parser_set_storage_class? We should be
> able to give a better diagnostic at that point.
I didn't have time to update the whole patch
Le 18/09/2022 à 22:55, Mikael Morin a écrit :
Assumed shape can be non-contiguous so have to be excluded,
Thinking about it again, assumed shape are probably acceptable, but
there should be a check for contiguousness on the actual argument.
* gcc/genrecog.cc (print_nonbool_test): Fix type error of
SUBREG_BYTE
---
gcc/genrecog.cc | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/genrecog.cc b/gcc/genrecog.cc
index 77f8fb97853..319e437e334 100644
--- a/gcc/genrecog.cc
+++ b/gcc/genrecog.cc
@@ -4619,6 +4619,7 @@
67 matches
Mail list logo
