On 8/17/22 13:50, Stefan Schulze Frielinghaus wrote:
> For a parameter with BLKmode we cannot use REG_NREGS in order to
> determine the number of consecutive registers. Streamlined this with
> the implementation of s390_function_arg.
>
> Fix some indentation whitespace, too.
>
> Assuming bootstr
On 10/19/22 08:22, Robin Dapp wrote:
> Hi,
>
> since r13-2746 we hit an ICE when bootstrapping with -m31 and
> --enable-checking=all.
>
> ../../../../libgfortran/ieee/ieee_helper.c: In function
> 'ieee_class_helper_16':
> ../../../../libgfortran/ieee/ieee_helper.c:77:3: internal compiler
> error:
Hi,
since r13-2746 we hit an ICE when bootstrapping with -m31 and
--enable-checking=all.
../../../../libgfortran/ieee/ieee_helper.c: In function
'ieee_class_helper_16':
../../../../libgfortran/ieee/ieee_helper.c:77:3: internal compiler
error: RTL check: expected code 'reg', have 'subreg' in rhs_r
Hi,
Here is the update patch that align the implementation to AVX-VNNI,
and corrects some spelling error for AVX512IFMA pattern.
Bootstrapped/regtested on x86_64-pc-linux-gnu and sde. Ok for trunk?
gcc/
* common/config/i386/i386-common.cc
(OPTION_MASK_ISA_AVXIFMA_SET, OPTION_MAS
On Wed, Oct 19, 2022 at 1:25 AM liuhongt wrote:
>
> Fix unexpected non-canon form from gimple vector selector.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/107271
> * config/i386/i386-expand.cc (ix86_vec_perm_index_c
Hi,
Currently effective target vect_long_long doesn't have
power specific check, I think it's an oversight. This
is to add the support which checks for has_arch_pwr8,
since we set rs6000_vector_unit[V2DImode] as:
(TARGET_P8_VECTOR) ? VECTOR_P8_VECTOR : VECTOR_NONE;
it means its full support s
Hi,
As PR107240 shows, when both the value to be shifted and the
count used for shifting are constants, it doesn't actually
requires a target to support vector shift operations.
This patch is to try fold_build2 for the generation of the
shifted value first, if it's folded, the shift is gone,
othe
Hi!
on 2022/10/19 00:52, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Oct 18, 2022 at 10:17:30AM -0500, will schmidt wrote:
>> On Mon, 2022-10-17 at 13:08 -0500, Segher Boessenkool wrote:
>>> It did not happen in GCC 9 obviously. Do you want to take a
>>> shot? It
>>> doesn't have to be all at o
On Tue, Oct 18, 2022 at 5:18 PM Haochen Jiang via Gcc-patches
wrote:
>
> Hi all,
>
> We would like to add one more patch to enhance the codegen with avxvnniint8.
> Also renamed two awkward named mode_attr to make them more aligned with
> others.
>
> Regtested on x86_64-pc-linux-gnu. Ok for trunk?
On Tue, Oct 18, 2022 at 5:13 PM Haochen Jiang via Gcc-patches
wrote:
>
> From: Kong Lingling
>
> Hi all,
>
> This is our v2 patch on AVX-VNNI-INT8. This main change in this patch is to
> rename the previous UNSPEC_VPMADDxxx things to new vnni style.
>
> Ok for trunk?
The patch LGTM, but please le
On Tue, Oct 18, 2022 at 02:08:40PM +, Joseph Myers wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/c2x-enum-1.c
> @@ -0,0 +1,104 @@
> +/* Test C2x enumerations with values not representable in int. */
> +/* { dg-do compile } */
> +/* { dg-options "-std=c2x -pedantic-errors" } */
> +
> +/*
On Wed, Oct 19, 2022 at 7:49 AM H.J. Lu wrote:
>
> On Tue, Oct 18, 2022 at 4:25 PM liuhongt wrote:
> >
> > Fix unexpected non-canon form from gimple vector selector.
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> > Ok for trunk?
> >
> > gcc/ChangeLog:
> >
> > PR targe
On Tue, Oct 18, 2022 at 4:25 PM liuhongt wrote:
>
> Fix unexpected non-canon form from gimple vector selector.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/107271
> * config/i386/i386-expand.cc (ix86_vec_perm_index_c
As noted in bug 101764, a declaration "enum tag;" is invalid in
standard C after a definition, as well as when no definition is
visible; we had a pedwarn-if-pedantic for the forward declaration
case, but were missing one for the other case. Add that missing
diagnostic (if pedantic only).
(These d
Fix unexpected non-canon form from gimple vector selector.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR target/107271
* config/i386/i386-expand.cc (ix86_vec_perm_index_canon): New.
(expand_vec_perm_shufps_shufps): Call
When a GTY'ed struct is streamed to PCH, any plain char* pointers it contains
(whether they live in GC-controlled memory or not) will be marked for PCH
output by the routine gt_pch_note_object in ggc-common.cc. This routine
special-cases plain char* strings, and in particular it uses strlen() to ge
On 10/18/22 16:40, Indu Bhagat wrote:
Hi Guillermo,
Hi Indu,
On 10/14/22 8:55 PM, Guillermo E. Martinez wrote:
Hello,
The following is patch v3 to update BTF/CTF backend supporting
BTF_KIND_ENUM64 type. Changes from v2:
+ Add a new `dtd_enum_unsigned' field in `ctf_dtdef' to indicat
Hi Guillermo,
On 10/14/22 8:55 PM, Guillermo E. Martinez wrote:
Hello,
The following is patch v3 to update BTF/CTF backend supporting
BTF_KIND_ENUM64 type. Changes from v2:
+ Add a new `dtd_enum_unsigned' field in `ctf_dtdef' to indicate
signedness of the enum type.
+ Fix endianness
On 10/17/22 11:44, Jakub Jelinek via Gcc-patches wrote:
Added 2 tests for nested assumptions (one with a simple assumption
nested in complex one, one with side-effects one nested in complex one).
So far lightly tested, will test fully overnight.
2022-10-17 Jakub Jelinek
OK, new prototype upd
I intended to add the updated patch but forgot, so here it is...
Am 18.10.22 um 22:41 schrieb Harald Anlauf via Fortran:
Dear all,
Jose posted a patch here that was never reviewed:
https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html
I could not find any issues with his patch, it w
Dear all,
Jose posted a patch here that was never reviewed:
https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html
I could not find any issues with his patch, it works as advertised
and fixes the reported problem.
As his testcases did not reliably fail without the patch but rather
rando
Found when playing around with reverse offload once I used 'omp target
parallel'.
The other issue showed up when running the testsuite (which is done with -O2).
In all cases, the ICE is in expand_GOMP_TARGET_REV of this IFN, which should
be unreachable
Note: ENABLE_OFFLOADING inside the compile
On Tue, 18 Oct 2022, Patrick Palka wrote:
> For an enum declaration, has_definition returns true iff its TYPE_VALUES
> field is non-empty. But this will wrongly return false for an enum that's
> defined to have no enumerators as in the below testcase.
>
> This patch fixes has_definition for such
On Fri, 14 Oct 2022, Richard Biener wrote:
> On Thu, Oct 13, 2022 at 5:40 PM Patrick Palka via Gcc-patches
> wrote:
> >
> > Here during stream in we end up having created a type variant for the enum
> > before we read the enum's definition, and thus the variant inherited stale
> > TYPE_VALUES and
For an enum declaration, has_definition returns true iff its TYPE_VALUES
field is non-empty. But this will wrongly return false for an enum that's
defined to have no enumerators as in the below testcase.
This patch fixes has_definition for such enums by checking OPAQUE_ENUM_P
instead, which shoul
We currently stream TYPE_MIN/MAX_VALUE of an enum only if the enum is
defined rather than just declared. But that seems inconsistent with
what start_enum does, which always sets TYPE_MIN/MAX_VALUE on the
ENUMERAL_TYPE (via copy_type_enum) even for an opaque enum that lacks a
definition.
This patc
-Wuseless-cast (not part of -Wall/-Wextra) warns here:
struct S { };
void g (S&&);
void f (S&& arg)
{
g (S(arg)); // warning: useless cast to type 'struct S'
}
which is wrong: the code will not compile without the cast because
"arg" is an lvalue which cannot bind to S&&.
I'd like t
On Tue, 18 Oct 2022 08:57:37 PDT (-0700), j...@ventanamicro.com wrote:
Just a couple more comments in-line.
On 10/18/22 09:18, Manolis Tsamis wrote:
+/* Implement TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS. */
+
+static sbitmap
+riscv_get_separate_components (void)
+{
+ HOST_WIDE_INT offse
Thank you very much for the detailed review.
On Tue, Oct 18, 2022 at 10:24:23AM -0400, Jason Merrill wrote:
> On 10/18/22 03:37, Paul Iannetta wrote:
> > On Fri, Oct 14, 2022 at 11:19:50AM -0400, Jason Merrill wrote:
> > > On 10/13/22 17:57, Paul Iannetta wrote:
> > > > On Thu, Oct 13, 2022 at 03:
Hi!
On Tue, Oct 18, 2022 at 10:17:30AM -0500, will schmidt wrote:
> On Mon, 2022-10-17 at 13:08 -0500, Segher Boessenkool wrote:
> > It did not happen in GCC 9 obviously. Do you want to take a
> > shot? It
> > doesn't have to be all at once, it's probably best if not even -- as
> > I
> > wrote i
Just a couple more comments in-line.
On 10/18/22 09:18, Manolis Tsamis wrote:
+/* Implement TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS. */
+
+static sbitmap
+riscv_get_separate_components (void)
+{
+ HOST_WIDE_INT offset;
+ sbitmap components = sbitmap_alloc (FIRST_PSEUDO_REGISTER);
+ bi
On Sun, Oct 2, 2022 at 11:32 PM Palmer Dabbelt wrote:
>
> On Tue, 06 Sep 2022 03:39:02 PDT (-0700), manolis.tsa...@vrull.eu wrote:
> > This commit implements the target macros (TARGET_SHRINK_WRAP_*) that
> > enable separate shrink wrapping for function prologues/epilogues in
> > RISC-V.
> >
> > Te
On Mon, 2022-10-17 at 13:08 -0500, Segher Boessenkool wrote:
> On Mon, Sep 19, 2022 at 11:13:20AM -0500, will schmidt wrote:
> > 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
This commit implements the target macros (TARGET_SHRINK_WRAP_*) that
enable separate shrink wrapping for function prologues/epilogues in
RISC-V.
Tested against SPEC CPU 2017, this change always has a net-positive
effect on the dynamic instruction count. See the following table for
the breakdown o
On Linux/x86_64,
46a8e017d048ec3271bbb898942e3b166c4e8ff3 is the first bad commit
commit 46a8e017d048ec3271bbb898942e3b166c4e8ff3
Author: Richard Biener
Date: Thu Oct 6 13:56:09 2022 +0200
Vectorization of first-order recurrences
caused
FAIL: libgomp.c++/loop-13.C (internal compiler erro
On Tue, 18 Oct 2022 16:46:07 +0200
Thomas Schwinge wrote:
> Hi Julian!
>
> On 2022-10-14T13:38:56+, Julian Brown
> wrote:
> ..., but to my surprised, that did fire in one occasion:
>
> > --- a/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90
> > +++ b/libgomp/testsuite/libgomp.o
Hi Julian!
On 2022-10-14T13:38:56+, Julian Brown wrote:
> This patch prevents compiler-generated artificial variables from being
> treated as privatization candidates for OpenACC.
>
> The rationale is that e.g. "gang-private" variables actually must be
> shared by each worker and vector spawn
On Tue, Oct 18, 2022 at 04:14:53PM +0200, Florian Weimer wrote:
> * Jakub Jelinek:
>
> > On Tue, Oct 18, 2022 at 04:06:17PM +0200, Florian Weimer wrote:
> >> By the way, the stack direction test currently gives incorrect results
> >> on x86-64 due to -O2 and address comparison of unrelated objects
On 10/18/22 03:37, Paul Iannetta wrote:
On Fri, Oct 14, 2022 at 11:19:50AM -0400, Jason Merrill wrote:
On 10/13/22 17:57, Paul Iannetta wrote:
On Thu, Oct 13, 2022 at 03:41:16PM -0400, Jason Merrill wrote:
On 10/13/22 12:02, Paul Iannetta wrote:
On Thu, Oct 13, 2022 at 11:47:42AM -0400, Jason
On 10/18/22 10:13, Patrick Palka wrote:
This fixes the below testcase in which we neglect to stream the default
argument for T only because the subsequent parameter U doesn't also have
a default argument.
ok
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
PR c++/105045
* Jakub Jelinek:
> On Tue, Oct 18, 2022 at 04:06:17PM +0200, Florian Weimer wrote:
>> By the way, the stack direction test currently gives incorrect results
>> on x86-64 due to -O2 and address comparison of unrelated objects. I
>> assume this doesn't matter because we don't use it on compilers th
On Tue, Oct 18, 2022 at 04:10:43PM +0200, Florian Weimer wrote:
> libiberty/
>
> * acinclude.m4 (ac_cv_func_strncmp_works): Add missing
> int return type and parameter list to the definition of main.
> Include and for prototypes.
> (ac_cv_c_stack_direction): Add missing
>
This fixes the below testcase in which we neglect to stream the default
argument for T only because the subsequent parameter U doesn't also have
a default argument.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
PR c++/105045
gcc/cp/ChangeLog:
* module.cc (trees_out
libiberty/
* acinclude.m4 (ac_cv_func_strncmp_works): Add missing
int return type and parameter list to the definition of main.
Include and for prototypes.
(ac_cv_c_stack_direction): Add missing
int return type and parameter list to the definitions of
On Tue, Oct 18, 2022 at 04:06:17PM +0200, Florian Weimer wrote:
> By the way, the stack direction test currently gives incorrect results
> on x86-64 due to -O2 and address comparison of unrelated objects. I
> assume this doesn't matter because we don't use it on compilers that
> support alloca nat
C2x has two enhancements to enumerations: allowing enumerations whose
values do not all fit in int (similar to an existing extension), and
allowing an underlying type to be specified (as in C++). This patch
implements the first of those enhancements.
Apart from adjusting diagnostics to reflect th
* Jakub Jelinek:
> On Tue, Oct 18, 2022 at 12:05:49PM +0200, Florian Weimer via Gcc-patches
> wrote:
>> libiberty/
>>
>> * acinclude.m4 (check for working strncmp): Add missing
>> int return type and parameter list to the definition of main.
>> Include for string functions. Avoi
Hi,
PR 107206 is fallout from the fix to PR 92706 where we started
propagating accesses across assignments also from LHS to RHS of
assignments so that we would not do harmful total scalarization of the
aggregates on the RHS.
But this can lead to new scalarization of these aggregates and in the
te
On Tue, Oct 18, 2022 at 12:05:49PM +0200, Florian Weimer via Gcc-patches wrote:
> libiberty/
>
> * acinclude.m4 (check for working strncmp): Add missing
> int return type and parameter list to the definition of main.
> Include for string functions. Avoid calling
> undecla
On Tue, Oct 18, 2022 at 11:39:25AM +0200, Florian Weimer via Gcc-patches wrote:
> libsanitizer/
>
> * configure.ac (check for necessary platform features):
I'd use (sanitizer_supported) or (SANITIZER_SUPPORTED) above instead,
that is what is what is being determined by the test.
> In
On Thu, Oct 13, 2022 at 13:08:46 -0400, David Malcolm wrote:
> On Mon, 2022-10-10 at 16:21 -0400, Jason Merrill wrote:
> > David Malcolm would probably know best about JSON wrangling.
>
> Unfortunately our JSON output doesn't make any guarantees about the
> ordering of keys within an object, so th
On Tue, Oct 11, 2022 at 07:42:43 -0400, Ben Boeckel wrote:
> On Mon, Oct 10, 2022 at 17:04:09 -0400, Jason Merrill wrote:
> > Can we share utf8 parsing code with decode_utf8_char in pretty-print.cc?
>
> I can look at factoring that out. I'll have to decode its logic to see
> how much overlap there
Hi Suwa-san,
v2 fixes the regressions caused by ICEs, but not the runtime failures.
On Mon, Oct 17, 2022 at 8:14 PM Max Filippov wrote:
> On Mon, Oct 17, 2022 at 7:57 PM Takayuki 'January June' Suwa
> wrote:
> > On 2022/10/16 14:03, Max Filippov wrote:
> > > There's also the following runtime f
On Mon, 17 Oct 2022 at 21:09, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK, thanks.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (stride_view): Define.
> (stride_view::_Iterator): Define.
> (views::__detail:
On Tue, Oct 18, 2022 at 12:15:08PM +0100, Jonathan Wakely via Gcc-patches wrote:
> ping...
>
> On 21/09/22 10:39 +0100, Jonathan Wakely wrote:
> > Finding the docs for the GCC-specific diagnostic formats isn't easy.
> > This might help.
> >
> > OK for wwwdocs?
>
> -- >8 --
>
> htdocs/codingcon
On Tue, Oct 18, 2022 at 01:01:14PM +0200, Ulrich Drepper via Gcc-patches wrote:
> This is of course not a new problem in general. GNU make has for a long
> time support for order-only prerequisites. With those one can exactly
> express what is needed:
>
> ifeq ($(ENABLE_MAINTAINER_RULES), true)
ping...
On 21/09/22 10:39 +0100, Jonathan Wakely wrote:
Finding the docs for the GCC-specific diagnostic formats isn't easy.
This might help.
OK for wwwdocs?
-- >8 --
htdocs/codingconventions.html | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/htdocs/codingconventions
On 10/18/22 13:01, Ulrich Drepper via Gcc-patches wrote:
> On Tue, Oct 18, 2022 at 2:56 AM Jason Merrill wrote:
>
>> That makes sense; the file could say something to that effect.
>
>
> I did that.
>
>
>
>> Or the
>> CSV file could live in the library directory, or a third directory.
>
>
On Tue, Oct 18, 2022 at 2:56 AM Jason Merrill wrote:
> That makes sense; the file could say something to that effect.
I did that.
> Or the
> CSV file could live in the library directory, or a third directory.
The reasoning is that with the file living in the cp subdir we don't have
the s
The following fixes the VEC_PERM_EXPR placement when the latch
definition is a PHI node.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/107302
* tree-vect-loop.cc (vectorizable_recurrence): Fix vec_perm
placement for a PHI latch def.
This patch adds support for non-constant component offsets in "map"
clauses for OpenMP (and the equivalants for OpenACC), which are not able
to be sorted into order at compile time. Normally struct accesses in
such clauses are gathered together and sorted into increasing address
order after a "GOM
This patch trivially adds braces and reindents the
OMP_CLAUSE_TO/OMP_CLAUSE_FROM/OMP_CLAUSE__CACHE_ stanza in
c_finish_omp_clause and finish_omp_clause, in preparation for the
following patch (to clarify the diff a little).
2022-09-13 Julian Brown
gcc/c/
* c-typeck.cc (c_finish_omp_cla
Implementing the "omp declare mapper" functionality, I noticed some
cases where handling of derived type members that are pointers doesn't
seem to be quite right. At present, a type such as this:
type T
integer, pointer, dimension(:) :: arrptr
end type T
type(T) :: tvar
[...]
!$omp ta
This is a new version of the previously-posted series:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603103.html
This version rearranges the patches so the already-approved first two
patches come first -- albeit with some XFAILs -- and alters how Fortran
array-descriptor mappings work
On 18/10/2022 02:17, Hans-Peter Nilsson wrote:
> On Wed, 12 Oct 2022, Jørgen Kvalsvik via Gcc-patches wrote:
>> This patch adds support in gcc+gcov for modified condition/decision
>> coverage (MC/DC) with the -fprofile-conditions flag.
>
> I'd love improvements in this area.
>
> But this is a ser
libiberty/
* acinclude.m4 (check for working strncmp): Add missing
int return type and parameter list to the definition of main.
Include for string functions. Avoid calling
undeclared exit function.
(stack direction for C alloca): Avoid calling undeclared
libsanitizer/
* configure.ac (check for necessary platform features):
Include for syscall prototype.
* configure: Regenerate.
---
libsanitizer/configure| 5 +++--
libsanitizer/configure.ac | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/libsan
Hi Richard,
This is my new patch and changes the warning message on aarch64/arm.
Ok for trunk?
BRs,
Haochen
gcc/ChangeLog:
* builtins.cc (expand_builtin_prefetch): Handle the fourth parameter in
expand function.
* config/aarch64/aarch64-sve.md: Add default parameter val
On Mon, Oct 17, 2022 at 09:22:23AM +0200, Richard Biener wrote:
> On Fri, Oct 14, 2022 at 4:18 PM Paul Iannetta via Gcc-patches
> wrote:
> >
> > On Wed, Oct 12, 2022 at 01:18:19AM +0200, Paul Iannetta wrote:
> > > On Mon, Oct 10, 2022 at 11:07:06PM +, Joseph Myers wrote:
> > > > On Mon, 10 Oct
On Mon, 17 Oct 2022 at 17:26, Jakub Jelinek wrote:
>
> Hi!
>
> On Mon, Oct 17, 2022 at 02:07:00PM +0100, Jonathan Wakely wrote:
> > Yes, that's now https://cplusplus.github.io/LWG/issue3790
> > The current proposed resolution is to just restore the C++20 functions
> > and not provide anything for
Hi all,
We would like to add one more patch to enhance the codegen with avxvnniint8.
Also renamed two awkward named mode_attr to make them more aligned with others.
Regtested on x86_64-pc-linux-gnu. Ok for trunk?
BRs,
Haochen
gcc/ChangeLog:
* config/i386/sse.md (ssedvecmode): Rename fr
From: Kong Lingling
Hi all,
This is our v2 patch on AVX-VNNI-INT8. This main change in this patch is to
rename the previous UNSPEC_VPMADDxxx things to new vnni style.
Ok for trunk?
BRs,
Haochen
gcc/ChangeLog
* common/config/i386/cpuinfo.h (get_available_features): Detect
avxv
On Tue, 18 Oct 2022, Andre Vieira (lists) wrote:
> The ifcvt dead code elimination code was not built to deal with inline
> assembly, as loops with such would never be if-converted in the past since
> we can't do data-reference analysis on them and vectorization would eventually
> fail.
> For this
The ifcvt dead code elimination code was not built to deal with inline
assembly, as loops with such would never be if-converted in the past since
we can't do data-reference analysis on them and vectorization would
eventually fail.
For this reason we now also do not lower bitfields if the data-ref
Path isolation failed to do that.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/107301
* gimple-ssa-isolate-paths.cc (handle_return_addr_local_phi_arg):
Check whether we can duplicate the block.
(find_implicit_erroneous_behavior)
On Fri, Oct 14, 2022 at 11:19:50AM -0400, Jason Merrill wrote:
> On 10/13/22 17:57, Paul Iannetta wrote:
> > On Thu, Oct 13, 2022 at 03:41:16PM -0400, Jason Merrill wrote:
> > > On 10/13/22 12:02, Paul Iannetta wrote:
> > > > On Thu, Oct 13, 2022 at 11:47:42AM -0400, Jason Merrill wrote:
> > > > >
On Mon, 17 Oct 2022, Jakub Jelinek wrote:
> Hi!
>
> On Mon, Oct 17, 2022 at 06:55:40AM +, Richard Biener wrote:
> > > That is what I wrote in the patch description as alternative:
> > > "with the condition wrapped into a GIMPLE_BIND (I admit the above isn't
> > > extra clean but it is just so
77 matches
Mail list logo
