on 2022/9/2 11:23, HAO CHEN GUI wrote:
> Hi Kewen,
>
> On 1/9/2022 下午 5:34, Kewen.Lin wrote:
>> Thanks for the updated patch!
>>
>> I just found that it seems all the three test cases suffer the empty
>> TU error issue from those has_arch* effective target checks?
>>
>> If yes, it looks we don't
Hi Jeff,
Thanks for the patch, some comments on nits are inline.
on 2022/9/1 11:24, Jiufu Guo wrote:
> Hi,
>
> As mentioned in PR106550, since pli could support 34bits immediate, we could
> use less instructions(3insn would be ok) to build 64bits constant with pli.
>
> For example, for
Hi Segher,
Thanks for your review comments. I will refine it according to
your comments.
On 2/9/2022 上午 12:07, Segher Boessenkool wrote:
>> +/* { dg-do compile { target { ! has_arch_pwr9 } } } */
> Please keep dg-do first thing in the file.
Could you inform me if it's a must to put dg-do in the
Segher Boessenkool writes:
> Hi!
>
> On Thu, Sep 01, 2022 at 11:24:07AM +0800, Jiufu Guo wrote:
>> Currently, these two splitters (touched in this patch) are using predicate
>> `int_reg_operand_not_pseudo`, then they work in split2 pass after RA in
>> most times, and can not run before RA.
>>
On Fri, 2022-09-02 at 11:12 +0800, Huacai Chen wrote:
> On Thu, Sep 1, 2022 at 6:56 PM Xi Ruoyao wrote:
> >
> > We'd like to introduce a new codegen option to align with the old
> > "-Wa,-mla-global-with-pcrel" and avoid a performance & size
> > regression
> > building the Linux kernel with
Hi Kewen,
On 1/9/2022 下午 5:34, Kewen.Lin wrote:
> Thanks for the updated patch!
>
> I just found that it seems all the three test cases suffer the empty
> TU error issue from those has_arch* effective target checks?
>
> If yes, it looks we don't need to bother this once patch [1] gets
> landed?
Hi, Ruoyao,
On Thu, Sep 1, 2022 at 6:56 PM Xi Ruoyao wrote:
>
> We'd like to introduce a new codegen option to align with the old
> "-Wa,-mla-global-with-pcrel" and avoid a performance & size regression
> building the Linux kernel with new-reloc toolchain. And it should be
> also useful for
Hi Segher,
on 2022/9/1 23:04, Segher Boessenkool wrote:
> On Thu, Sep 01, 2022 at 05:05:44PM +0800, Kewen.Lin wrote:
>>> On Wed, Aug 31, 2022 at 05:33:28PM +0800, Kewen.Lin wrote:
>>> *Should* -mpowerpc64 be disabled by -m32?
>>
>> I think the reason to disable -mpowerpc64 at -m32 is that we
Hi Segher,
on 2022/9/1 22:57, Segher Boessenkool wrote:
> On Thu, Sep 01, 2022 at 04:57:59PM +0800, Kewen.Lin wrote:
>> on 2022/8/31 22:13, Peter Bergner wrote:
>>> On 8/31/22 4:33 AM, Kewen.Lin wrote:
@@ -1,7 +1,8 @@
/* { dg-do compile { target { powerpc*-*-* } } } */
/* {
Hi!
On Tue, Aug 30, 2022 at 05:44:26PM +0800, Jiufu Guo wrote:
> There are two splitters, both are calling rs6000_emit_set_const to emit
> instructions for constant building.
> One splitter checks `const_int_operand`, this splitter is always used.
> Another spitter checks
Sorry for the delay in getting to this.
I am currently working on moving the bulk of the atomic wait implementation
into the .so. I'd like to get that work to a stable state before revisiting
this patch, but obviously if we want this to make it into GCC13, it needs
to happen sooner rather than
Hi!
On Thu, Sep 01, 2022 at 11:24:07AM +0800, Jiufu Guo wrote:
> Currently, these two splitters (touched in this patch) are using predicate
> `int_reg_operand_not_pseudo`, then they work in split2 pass after RA in
> most times, and can not run before RA.
>
> It would not be a bad idea to allow
Jason,
I made another small change in addressing your feedback (attached).
Thanks,
Eugene
-Original Message-
From: Gcc-patches On
Behalf Of Eugene Rozenfeld via Gcc-patches
Sent: Thursday, September 01, 2022 1:49 PM
To: Jason Merrill ; gcc-patches@gcc.gnu.org
Cc: Andi Kleen ; Jan
On Thu, Sep 1, 2022 at 11:23 AM Uros Bizjak via Gcc-patches
wrote:
>
> The conversion of a move pattern where both operands are AX_REG
> should be prevented.
>
> 2022-09-01 Uroš Bizjak
>
> gcc/ChangeLog:
>
> PR target/106707
> * config/i386/i386.md (moves to/from AX_REG into xchg
Hi!
This patch is a clear improvement :-)
On Thu, Sep 01, 2022 at 11:24:00AM +0800, Jiufu Guo wrote:
> As mentioned in PR106550, since pli could support 34bits immediate, we could
> use less instructions(3insn would be ok) to build 64bits constant with pli.
> For example, for constant
On 9/1/2022 1:12 PM, Joseph Myers wrote:
C2x has completely removed unprototyped functions, so that () now
means the same as (void) in both function declarations and
definitions, where previously that change had been made for
definitions only. Implement this accordingly.
This is a change
Hi All,
This fixes the bootstrap failure on AArch64 following -Werror=format by
correcting the print format modifiers in the backend.
Bootstrapped on aarch64-none-linux-gnu and no issues.
Committed as obvious.
Thanks,
Tamar
gcc/ChangeLog:
PR other/106782
*
Attached patch adds __builtin_iseqsig() to the middle-end and C family
front-ends.
Testing does not currently check whether the signaling part works, because with
optimisation is actually does not (preexisting compiler bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805)
Bootstrapped and
Jason,
Thank you for your review. You are correct, we only need to check
has_discriminator for the statement that's on the same line.
I updated the patch (attached).
Thanks,
Eugene
-Original Message-
From: Jason Merrill
Sent: Thursday, August 18, 2022 6:55 PM
To: Eugene Rozenfeld ;
On Thu, Sep 01, 2022 at 03:00:28PM -0400, Jason Merrill wrote:
> > Apparently clang uses -Wunicode option to cover these, but unfortunately
> > they don't bother to document it (nor almost any other warning option),
> > so it is unclear what else exactly it covers. Plus a question is how
> > we
This declaration was added in r260905 but the function was never
defined.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* cp-tree.h (maybe_strip_ref_conversion): Remove.
---
gcc/cp/cp-tree.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/cp/cp-tree.h
The eBPF loader expects to find BTF_KIND_VAR records for references to
extern const void symbols. We were mistakenly identifing these as
unsupported types, and as a result skipping emitting VAR records for
them.
Tested on bpf-unknown-none and x86_64, no known regressions.
OK?
Thanks.
Tested x86_64-linux, pushed to trunk.
-- >8 --
Clang doesn't yet implement the C++20 change that makes 'typename'
optional here.
libstdc++-v3/ChangeLog:
* include/std/ranges (adjacent_transform_view::_Iterator): Add
typename keyword before dependent qualified-id.
---
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
Define partial specializations of std::decay and its __decay_selector
helper so that remove_reference, is_array and is_function are not
instantiated for every type, and remove_extent is not instantiated for
arrays.
libstdc++-v3/ChangeLog:
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
We only use the __is_referenceable helper in three places now:
add_pointer, add_lvalue_reference, and add_rvalue_reference. But lots of
other traits depend on add_[lr]value_reference, and decay depends on
add_pointer, so removing the
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This avoids having to instantiate a class template when we can detect
the true cases easily with a partial specialization.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_lvalue_reference_v)
(is_rvalue_reference_v,
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
We can replace some class template helpers with alias templates, which
are cheaper to instantiate.
For example, replace the __is_copy_constructible_impl class template
with an alias template that uses just evaluates the __is_constructible
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This avoids having to instantiate a class template that just uses the
same built-in anyway.
None of the corresponding class templates have any type-completeness
static assertions, so we're not losing any diagnostics by using the
built-ins
C2x has completely removed unprototyped functions, so that () now
means the same as (void) in both function declarations and
definitions, where previously that change had been made for
definitions only. Implement this accordingly.
This is a change where GNU/Linux distribution builders might wish
On 9/1/22 07:14, Jakub Jelinek wrote:
On Wed, Aug 31, 2022 at 12:14:22PM -0400, Jason Merrill wrote:
On 8/31/22 11:07, Jakub Jelinek wrote:
On Wed, Aug 31, 2022 at 10:52:49AM -0400, Jason Merrill wrote:
It could be more explicit, but I think we can assume that from the existing
wording; it
On 8/31/22 17:15, Patrick Palka wrote:
This introduces an early exit test to most_specialized_partial_spec for
the common case where we have no partial specializations, which allows
us to avoid some unnecessary work. In passing, clean the function up a
bit.
Bootstrapped and regtested on
On Thu, Sep 1, 2022 at 6:41 PM Joseph Myers wrote:
>
> On Thu, 1 Sep 2022, Aldy Hernandez via Gcc-patches wrote:
>
> > Now that we keep track of the signbit, we can use it to fold
> > __builtin_signbit.
> >
> > I am assuming I don't have try too hard to get the actual signbit
> > number and 1
The conversion of a move pattern where both operands are AX_REG
should be prevented.
2022-09-01 Uroš Bizjak
gcc/ChangeLog:
PR target/106707
* config/i386/i386.md (moves to/from AX_REG into xchg peephole2):
Do not convert a move pattern where both operands are AX_REG.
This is kinda obvious.
OK?
gcc/ChangeLog:
* builtins.cc (fold_builtin_inf): Convert use of real_info to dconstinf.
(fold_builtin_fpclassify): Same.
* fold-const-call.cc (fold_const_call_cc): Same.
* match.pd: Same.
* omp-low.cc (omp_reduction_init_op):
gcc/ChangeLog:
* range-op-float.cc (build_le): Convert to dconst*inf.
(build_ge): Same.
* value-range.cc (frange::set_signbit): Same.
(frange::normalize_kind): Same.
(range_tests_floats): Same.
* value-range.h (vrp_val_max): Same.
Hi,
Thanks for taking a look at my patch. I tested some combinations with
pure/noreturn attributes. gcc seems to ignore those attributes on multiversion
functions and generates sub-optimal assembly.
But I wasn't able to fix this by simply copying members like DECL_PURE_P. It's
pretty hard for
On Thu, 1 Sep 2022, Aldy Hernandez via Gcc-patches wrote:
> Now that we keep track of the signbit, we can use it to fold
> __builtin_signbit.
>
> I am assuming I don't have try too hard to get the actual signbit
> number and 1 will do. Especially, since we're inconsistent in trunk whether
> we
On Thu, Sep 01, 2022 at 01:30:18PM +0800, HAO CHEN GUI wrote:
> --- a/gcc/testsuite/gcc.target/powerpc/pr92398.p9+.c
> +++ b/gcc/testsuite/gcc.target/powerpc/pr92398.p9+.c
> @@ -1,6 +1,10 @@
> -/* { dg-do compile { target { lp64 && has_arch_pwr9 } } } */
> +/* { dg-do compile } */
> +/* {
On Thu, Sep 01, 2022 at 11:39:42PM +0800, Chung-Lin Tang wrote:
> our work on SPEChpc2021 benchmarks show that, after the fix for PR99555 was
> committed:
> [libgomp, nvptx] Fix hang in gomp_team_barrier_wait_end
>
Hi,
our work on SPEChpc2021 benchmarks show that, after the fix for PR99555 was
committed:
[libgomp, nvptx] Fix hang in gomp_team_barrier_wait_end
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=5ed77fb3ed1ee0289a0ec9499ef52b99b39421f1
while that patch fixed the hang, there were quite severe
On Thu, Sep 01, 2022 at 05:05:44PM +0800, Kewen.Lin wrote:
> > On Wed, Aug 31, 2022 at 05:33:28PM +0800, Kewen.Lin wrote:
> > *Should* -mpowerpc64 be disabled by -m32?
>
> I think the reason to disable -mpowerpc64 at -m32 is that we have
> -mpowerpc64 explicitly specified at -m64 (equivalent
On Thu, Sep 01, 2022 at 04:57:59PM +0800, Kewen.Lin wrote:
> on 2022/8/31 22:13, Peter Bergner wrote:
> > On 8/31/22 4:33 AM, Kewen.Lin wrote:
> >> @@ -1,7 +1,8 @@
> >> /* { dg-do compile { target { powerpc*-*-* } } } */
> >> /* { dg-skip-if "" { powerpc*-*-aix* } } */
> >> -/* { dg-options "-O2
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
PR c++/99968 is fixed since GCC 12.1 so we can remove the workaround.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_scoped_enum): Remove workaround.
---
libstdc++-v3/include/std/type_traits | 11 +--
1 file changed, 1
On Thu, Sep 01, 2022 at 04:28:56PM +0800, Kewen.Lin wrote:
> tree.def has some note about VIEW_CONVERT_EXPR, it quite matches what Segher
> replied.
> In my experience, VIEW_CONVERT_EXPR are used a lot for vector type conversion.
It is needed whenever vector types are not compatible otherwise.
On 9/1/2022 8:13 AM, Aldy Hernandez via Gcc-patches wrote:
We're starting to abuse the infinity endpoints in the frange code and
the associated range operators. Building infinities are rather cheap,
and we could even inline them, but I think it's best to just not
recalculate them all the
On 9/1/22 3:29 AM, Kewen.Lin wrote:
>> I have no idea why ptr_vector_*_type would behave differently here than
>> build_pointer_type (vector_*_type_node). Using the build_pointer_type()
>> fixed it for me, so that's why I went with it. :-) Maybe this is a bug
>> in lto???
>
> Thanks for your
We're starting to abuse the infinity endpoints in the frange code and
the associated range operators. Building infinities are rather cheap,
and we could even inline them, but I think it's best to just not
recalculate them all the time.
I see about 20 uses of real_inf in the source code, not
On 2022-08-31 3:21 a.m., Martin Liška wrote:
Sending v3 of the patch that includes John's comments.
Ready to be installed?
Okay.
Dave
--
John David Anglin dave.ang...@bell.net
Now that we have DFS_BACK_EDGE marks we can simply avoid walking
those instead of repeatedly looking for a cycle on the current chain.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* gimple-predicate-analysis.cc (compute_control_dep_chain):
Remove cycle detection,
The following hides some internal details of compute_control_dep_chain.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* gimple-predicate-analysis.cc (compute_control_dep_chain):
New wrapping overload.
(uninit_analysis::init_use_preds): Simplify.
While looking at the DWARF handling of char8_t I wondered why we weren't
setting TREE_STRING_FLAG on it. I hoped that setting that flag would be an
easy fix for PR102958, but it doesn't seem to be sufficicent. But it still
seems correct.
I also tried setting the flag on char16_t and char32_t,
Hello,
okay, I'll bite :) DBG_REGISTER_NUMBER? DEBUGGER_REGNO?
Ciao,
Michael.
Martin Liška writes:
> So please fix the crash I reported and I can convert GM2 texi manual.
will do,
regards,
Gaius
On Thu, Sep 1, 2022 at 12:06 PM Martin Liška wrote:
>
OK.
> gcc/ChangeLog:
>
> * config/pdp11/pdp11.h (PREFERRED_DEBUGGING_TYPE): Disable
> debugging format.
> ---
> gcc/config/pdp11/pdp11.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git
As discussed here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600656.html
This adds an frange property to keep track of the sign bit. We keep
it updated at all times, but we don't use it make any decisions when
!HONOR_SIGNED_ZEROS.
With this property we can now query the
Now that we keep track of the signbit, we can use it to fold __builtin_signbit.
I am assuming I don't have try too hard to get the actual signbit
number and 1 will do. Especially, since we're inconsistent in trunk whether
we fold the builtin or whether we calculate it at runtime.
abulafia:~$
On Wed, Aug 31, 2022 at 12:14:22PM -0400, Jason Merrill wrote:
> On 8/31/22 11:07, Jakub Jelinek wrote:
> > On Wed, Aug 31, 2022 at 10:52:49AM -0400, Jason Merrill wrote:
> > > It could be more explicit, but I think we can assume that from the
> > > existing
> > > wording; it says it designates
On Tue, 30 Aug 2022 at 18:14, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK
>
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (__detail::__unarize): Define.
> (adjacent_view::_Iterator): Befriend
On Mon, 29 Aug 2022 at 11:31, Gerald Pfeifer wrote:
>
> On Wed, 24 Aug 2022, Jonathan Wakely wrote:
> >> a broken link points to
> >>
> >> An introduction to GCC by Brian J. Gough.
> >> . http://www.network-theory.co.uk/gcc/intro/
> > There are much more recent archived copies like
> >
We'd like to introduce a new codegen option to align with the old
"-Wa,-mla-global-with-pcrel" and avoid a performance & size regression
building the Linux kernel with new-reloc toolchain. And it should be
also useful for building statically linked executables, firmwares (EDK2
for example), and
On Thu, 1 Sep 2022, Richard Sandiford wrote:
> This patch extends the SLP layout optimisation pass so that it
> tries to remove layout changes that are brought about by permutes
> of existing vectors. This fixes the bb-slp-pr54400.c regression on
> x86_64 and also means that we can remove the
This patch extends the SLP layout optimisation pass so that it
tries to remove layout changes that are brought about by permutes
of existing vectors. This fixes the bb-slp-pr54400.c regression on
x86_64 and also means that we can remove the permutes in cases like:
typedef float v4sf
On 8/31/22 17:49, Jeff Law wrote:
>
>
> On 8/22/2022 3:39 AM, Martin Liška wrote:
>> On 4/28/22 18:10, Jeff Law via Gcc-patches wrote:
>>> As I mentioned in the original thread, my change to pr94157_0 was an
>>> attempt to avoid these warnings by passing a magic flag to the linker. Of
>>>
gcc/ada/ChangeLog:
* sigtramp-vxworks-target.h: Rename DBX_REGISTER_NUMBER to
DEBUGGER_REGISTER_NUMBER.
gcc/ChangeLog:
* config/aarch64/aarch64-protos.h (aarch64_dbx_register_number):
Rename DBX_REGISTER_NUMBER to DEBUGGER_REGISTER_NUMBER.
gcc/ChangeLog:
* config/pdp11/pdp11.h (PREFERRED_DEBUGGING_TYPE): Disable
debugging format.
---
gcc/config/pdp11/pdp11.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/config/pdp11/pdp11.h b/gcc/config/pdp11/pdp11.h
index 55e0625e6ea..d783b36b652 100644
From eb9e8241d99145020ec5c050c918c1ad3abc2701 Mon Sep 17 00:00:00 2001
From: Frolov Daniil
Date: Thu, 1 Sep 2022 10:55:01 +0300
Subject: [PATCH] Support %b, %B for -Wformat-overflow (sprintf, snprintf)
gcc/ChangeLog:
* gimple-ssa-sprintf.cc (fmtresult::type_max_digits): Handle
base == 2.
Hi Haochen,
on 2022/9/1 13:30, HAO CHEN GUI wrote:
> Hi,
> This patch changes the sequence of test directives for 3 test cases.
> Originally, these 3 cases got failed or unsupported on some platforms, as
> their effective target checks depend on compiling options.
>
Thanks for the updated
Tested powerpc64le-linux, pushed to trunk.
This is the first in a series of patches to optimize compile time for
the contents of .
-- >8 --
Improve compile times by avoiding unnecessary class template
instantiations.
__is_array_known_bounds and __is_array_unknown_bounds can be defined
without
On Thu, Sep 01, 2022 at 09:05:41AM +, Richard Biener wrote:
> > As discussed on IRC, the r13-2299-g68c61c2daa1f bug only got missed
> > because dump_printf_loc had incorrect format attribute and therefore
> > almost no -Wformat=* checking was performed on it.
> > 3, 0 are suitable for function
Hi Segher and Peter,
Thanks a lot for your insightful comments on this.
I just read through all discussions and plan to give a
try as replied below.
on 2022/8/31 23:24, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 05:33:28PM +0800, Kewen.Lin wrote:
>> Test case bswap64-4.c suffers the
On Thu, 1 Sep 2022, Jakub Jelinek wrote:
> Hi!
>
> As discussed on IRC, the r13-2299-g68c61c2daa1f bug only got missed
> because dump_printf_loc had incorrect format attribute and therefore
> almost no -Wformat=* checking was performed on it.
> 3, 0 are suitable for function with (whatever,
on 2022/8/31 22:13, Peter Bergner wrote:
> On 8/31/22 4:33 AM, Kewen.Lin wrote:
>> @@ -1,7 +1,8 @@
>> /* { dg-do compile { target { powerpc*-*-* } } } */
>> /* { dg-skip-if "" { powerpc*-*-aix* } } */
>> -/* { dg-options "-O2 -mpowerpc64" } */
>> /* { dg-require-effective-target ilp32 } */
>>
>>> ...and of course, now I can't recreate that issue at all and the
>>> ptr_vector_*_type use work fine now. Strange! ...so ok, changed.
>>> Maybe the behavior changed since my PR106017 fix went in???
>>
>> That is my best guess as well. But, how did that help this test?
>
> It didn't. :-)
+ if (TREE_TYPE (TREE_TYPE (src_ptr)) != src_type)
>>>
>>> This line looks unexpected, the former is type char while the latter is
>>> type __vector_pair *.
>>>
>>> I guess you meant to compare the type of pointer type like:
>>>
>>>TREE_TYPE (TREE_TYPE (src_ptr)) != TREE_TYPE
Hi Segher & Peter,
Thanks for your reviews!
on 2022/8/31 23:12, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 05:33:21PM +0800, Kewen.Lin wrote:
>> It's meant to update "lxv" to "p?lxv" and should leave the
>> "lvx" unchanged. So this is to fix the typo accordingly.
>>
>> I'll push this
Hi!
As discussed on IRC, the r13-2299-g68c61c2daa1f bug only got missed
because dump_printf_loc had incorrect format attribute and therefore
almost no -Wformat=* checking was performed on it.
3, 0 are suitable for function with (whatever, whatever, const char *, va_list)
arguments, not for
gcc/ChangeLog:
* config/rs6000/rtems.h (CPP_OS_DEFAULT_SPEC): Define __PPC_VRSAVE__ if
-mvrsave is present.
* config/rs6000/t-rtems: Add -mvrsave multilib variants for
-mcpu=e6500.
---
gcc/config/rs6000/rtems.h | 3 ++-
gcc/config/rs6000/t-rtems | 5 +
2 files
I'm just shuffling the FP self tests here, with no change to existing
functionality.
If we agree that explicit NANs in the source code with !HONOR_NANS
should behave any differently, I'm happy to address whatever needs
fixing, but for now I'd like to unblock the !HONOR_NANS build systems.
I have
On Wed, Aug 31, 2022 at 11:00 PM Simon Rainer wrote:
>
> Hi,
>
> This patch fixes PR106627. I ran the i386.exp tests on my x86_64-linux-gnu
> machine with a fully bootstrapped checkout. I also tested manually that no
> exception handling code is generated if none of the function versions throws
On Wed, Aug 31, 2022 at 9:21 PM Iain Buclaw wrote:
>
> Excerpts from Joseph Myers's message of August 31, 2022 7:16 pm:
> > On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
> >
> >> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
> >> > On Fri, 26 Aug 2022, Richard Biener
On Wed, 31 Aug 2022, Kees Cook wrote:
> On Wed, Aug 31, 2022 at 08:35:12PM +, Qing Zhao wrote:
> > One of the major purposes of the new option -fstrict-flex-array is to
> > encourage standard conforming programming style.
> >
> > So, it might be reasonable to treat -fstrict-flex-array
81 matches
Mail list logo
