Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]

On 19.09.22 22:50, Mikael Morin wrote: 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 t

RE: [PATCH] Enhance final_value_replacement_loop to handle bitop with an invariant induction.[PR105735]

Thanks a lot, pushed to trunk. > Hi Richard, > > Thanks again for your reviewing. > > > Yes, use else if for the bitwise induction. Can you also make the new > > case conditional on 'def' > > (the compute_overall_effect_of_inner_loop) being chrec_dont_know? If > > that call produced something

Re: [PATCH] Support 64-bit vectorization for single-precision floating rounding operation.

On Tue, Sep 20, 2022 at 4:15 AM liuhongt via Gcc-patches 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 >

Re: [PATCH v4] eliminate mutex in fast path of __register_frame

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

Re: [PATCH] [PR68097] frange::set_nonnegative should not contain -NAN.

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 nonnegati

Re: [PATCH] [PR68097] frange::set_nonnegative should not contain -NAN.

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, 'set_nonnegative'

Re: [PATCH] frange: flush denormals to zero for -funsafe-math-optimizations.

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 me

Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

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

Re: [PATCH] Fix incorrect handle in vectorizable_induction for mixed induction type.

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 inducti

Re: [PATCH] [x86]Don't optimize cmp mem, 0 to load mem, reg + test reg, reg

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 peepho

[PATCH] Fix incorrect handle in vectorizable_induction for mixed induction type.

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 the

Re: [PATCH] Support 64-bit vectorization for single-precision floating rounding operation.

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 > * config

[PATCH] Support 64-bit vectorization for single-precision floating rounding operation.

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): Ditt

[PATCH, rs6000] Eliminate TARGET_CTZ,TARGET_FCTIDZ,FCTIWUZ defines

[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 should

Re: [PATCH] RISC-V modified add3 for large stack frame optimization [PR105733]

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 > > https://github.com/riscv-admin/riscv-code-speed-optimization/blob

RE: [EXTERNAL] Re: [PING][PATCH] Add instruction level discriminator support.

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 instructio

Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]

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 ca

Proxy ping [PATCH] Fortran: Fix function attributes [PR100132]

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 regt

Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]

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

[r13-2722 Regression] FAIL: gfortran.dg/ieee/modes_1.f90 -Os (test for excess errors) on Linux/x86_64

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: gfortran.dg/i

Re: [PATCH] c: Stray inform note with -Waddress [PR106947]

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? > >

[PATCH] c: Stray inform note with -Waddress [PR106947]

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

Re: [PATCH] Fortran 2018 rounding modes changes

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 o

Re: [PATCH] Fortran 2018 rounding modes changes

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 IEEE_GET_ROUN

[PATCH] testsuite: Do not prefix linker script with "-Wl,"

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 --- gcc/testsuite/lib

Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

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 > >

[PATCH] testsuite: 'b' instruction can't do long enough jumps

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: /tmp/ccc

[PATCH] Avoid depending on destructor order

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 no

[PATCH] testsuite: Skip intrinsics test if arm

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: * g

Re: [PATCH] Fortran 2018 rounding modes changes

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 shoul

[PATCH, rs6000] Split TARGET_POWER8 from TARGET_DIRECT_MOVE [PR101865] (2/2)

[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. This

[PATCH] RISC-V modified add3 for large stack frame optimization [PR105733]

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 https://gcc.gnu.org/bugzilla/show_

[PATCH, rs6000] Tests of ARCH_PWR8 and -mno-vsx option. (1/2)

[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 com

Re: [PATCH] Fortran 2018 rounding modes changes

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 unu

Re: [PATCH v4] eliminate mutex in fast path of __register_frame

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 st

Re: [PATCH][RFH] Wire ranger into FRE

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 prese

Re: [patch, avr] Fix PR target/99184: Wrong cast from double to 16-bit and 32-bit ints.

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 targe

Re: [PATCH v4] eliminate mutex in fast path of __register_frame

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 generic

Re: [PATCH] [PR68097] frange::set_nonnegative should not contain -NAN.

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

Re: [PATCH v4] eliminate mutex in fast path of __register_frame

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++

[PATCH] c++: stream PACK_EXPANSION_EXTRA_ARGS [PR106761]

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 x

Re: [PATCH v4] eliminate mutex in fast path of __register_frame

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 som

Re: [PATCH] libgcc: Decrease size of _Unwind_FrameState and even more size of cleared area in uw_frame_state_for

* 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 benchmarke

Re: [PATCH] frange: flush denormals to zero for -funsafe-math-optimizations.

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 t

Re: [PATCH] [PR68097] frange::set_nonnegative should not contain -NAN.

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 retur

Re: [PATCH] frange: flush denormals to zero for -funsafe-math-optimizations.

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 t

Re: [PATCH] frange: flush denormals to zero for -funsafe-math-optimizations.

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 t

Re: [PATCH] [PR68097] frange::set_nonnegative should not contain -NAN.

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 agree

Re: [PATCH] Fortran 2018 rounding modes changes

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 écrit

[PATCH] c++, v2: Implement C++23 P1169R4 - static operator() [PR106651]

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 cand

Re: [PATCH] Fortran: add IEEE_MODES_TYPE, IEEE_GET_MODES and IEEE_SET_MODES

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

[PATCH][RFH] Wire ranger into FRE

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

Re: [PATCH] libgcc: Decrease size of _Unwind_FrameState and even more size of cleared area in uw_frame_state_for

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. Florian

Re: [PATCH] libgcc: Decrease size of _Unwind_FrameState and even more size of cleared area in uw_frame_state_for

* 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

Re: [PATCH] libgcc: Decrease size of _Unwind_FrameState and even more size of cleared area in uw_frame_state_for

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 offset

Re: [patch, avr] Fix PR target/99184: Wrong cast from double to 16-bit and 32-bit ints.

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 16-bi

Re: [PATCH] libgcc: Decrease size of _Unwind_FrameState and even more size of cleared area in uw_frame_state_for

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 >

Re: [patch, avr] Fix PR target/99184: Wrong cast from double to 16-bit and 32-bit ints.

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 libf7-asm.

Re: [PATCH] frange: flush denormals to zero for -funsafe-math-optimizations.

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 > > rang

Re: [PATCH] [PR68097] frange::set_nonnegative should not contain -NAN.

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 RE

[PATCH] [PR68097] frange::set_nonnegative should not contain -NAN.

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. (range_tests_

Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]

On Mon, Sep 19, 2022 at 9:31 AM Mikael Morin wrote: > > Le 18/09/2022 à 12:48, Richard Biener a écrit : > > > >> Does *(&a[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.

[PATCH] libgcc: Decrease size of _Unwind_FrameState and even more size of cleared area in uw_frame_state_for

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 h

Re: [patch, avr] Fix PR target/99184: Wrong cast from double to 16-bit and 32-bit ints.

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. Luc

Re: [PATCH] Improve sorry message for -fzero-call-used-regs

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 gcc/

Re: [PATCH] frange: flush denormals to zero for -funsafe-math-optimizations.

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 of

Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]

Le 18/09/2022 à 12:48, Richard Biener a écrit : Does *(&a[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. S

[PATCH] c++: Improve diagnostics about conflicting specifiers

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 la

Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]

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.