The DECL_MD_FUNCTION_CODE added in r274404(PR 91421) by rsandifo requires that
DECL to be a BUILTIN_IN_MD class built-in, asserts will happen when lto
as the patch r274411(PR 91287) outputs some math function symbol to the object,
this patch will check function type before do builtin_md vectorize.
Jeff,
Please let me know if you agree/disagree and what I need to
do to advance this work:
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00643.html
Thanks
Martin
On 8/14/19 1:59 PM, Martin Sebor wrote:
On 8/13/19 4:46 PM, Jeff Law wrote:
On 8/13/19 3:43 PM, Martin Sebor wrote:
On 8/13/19
This PR complains that we are not handling the attribute deprecated on
namespaces. This has gotten more important now because of ranges-v3 which
renamed its "view" namespace to "views", following the PascalCase to snake_case
change, and "view" is now deprecated.
Unfortunately we can't just call
On Mon, Aug 12, 2019 at 8:21 PM Xiangdong JI wrote:
>
> The .go files generated during building gccgo seem to have a few constants
> with weird values, for example:
>
> // sysinfo.go (on x86-64, latest gcc-9 trunk)
>
> const ___FLT128_MAX__ = 1.1
> const ___FLT32X_DENORM_MIN__ = 1.1
>
> as a
This Go patch implements shift by signed types. This is a new
language feature in Go 1.13
(https://tip.golang.org/doc/go1.13#language). Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Unfortunately this is another case where GMail spam detection
On 16/08/19 22:39 -0400, Ed Smith-Rowland via libstdc++ wrote:
The latest draft and I guess the above paper changed the macro names
for the C++20 constexpr lib featues.
__cpp_lib_constexpr_algorithms ->__cpp_lib_constexpr.
The __cpp_lib_constexpr macro is (now?) for a different feature.
The
On 8/20/19 3:14 PM, Jose E. Marchesi wrote:
>
> Hi Jeff.
>
> > This patch adds a port for the Linux kernel eBPF architecture to GCC.
> >
> > ChangeLog:
> >
> > * configure.ac: Support for bpf-*-* targets.
> > * configure: Regenerate.
> >
> >
* doc/doxygen/user.cfg.in (INPUT): Remove profile mode headers.
Committed to trunk.
commit 47af321610e47dfcf0179b71c50b0937ab0c19d9
Author: redi
Date: Tue Aug 20 21:35:55 2019 +
Do not try to process deleted headers with Doxygen
* doc/doxygen/user.cfg.in
* include/std/numeric (reduce): Fix Doxygen markup.
Committed to trunk.
commit eb08c33dadf6f53fa202aaddea5c68a01b83987a
Author: Jonathan Wakely
Date: Tue Aug 20 22:27:19 2019 +0100
Fix markdown in Doxygen comments for std::reduce
* include/std/numeric (reduce):
On Aug 20 2019, Steve Kargl wrote:
On Tue, Aug 20, 2019 at 09:56:27PM +0200, Thomas Koenig wrote:
I wrote:
> Committed as r274551.
Well, this revision appears to have woken quite a few bugs from their
slumber. While argument mismatch was always illegal, it seems to have
been a common idiom
Hi Jeff.
> This patch adds a port for the Linux kernel eBPF architecture to GCC.
>
> ChangeLog:
>
> * configure.ac: Support for bpf-*-* targets.
> * configure: Regenerate.
>
> contrib/ChangeLog:
>
> * config-list.mk (LIST): Disable go in bpf-*-*
Hello world,
here is the next installment of checking for mismatched calls,
this time for mismatching CALLs.
The solution is to build a separate namespace with procedure
arguments determined from the actual arguments the first time a
procedure is seen, and then compare it against that on
On Tue, Aug 20, 2019 at 09:56:27PM +0200, Thomas Koenig wrote:
> I wrote:
>
> > Committed as r274551.
>
> Well, this revision appears to have woken quite a few bugs from their
> slumber. While argument mismatch was always illegal, it seems to have
> been a common idiom at one time. And, like
On Tue, 20 Aug 2019, Jose E. Marchesi wrote:
> > On Thu, Aug 15, 2019 at 12:22:46AM +0200, Jose E. Marchesi wrote:
> > > --- a/configure
> > > +++ b/configure
> Yeah by mistake I used a Debian patched autoconf 2.96. Will regenerate
> using vanilla autoconf for subsequent versions of
I wrote:
Committed as r274551.
Well, this revision appears to have woken quite a few bugs from their
slumber. While argument mismatch was always illegal, it seems to have
been a common idiom at one time. And, like almost all bad habits of
the past, SPEC also has this (see PR 91473, where
On 8/16/19 6:59 PM, Jose E. Marchesi wrote:
> This patch adds a port for the Linux kernel eBPF architecture to GCC.
>
> ChangeLog:
>
> * configure.ac: Support for bpf-*-* targets.
> * configure: Regenerate.
>
> contrib/ChangeLog:
>
> * config-list.mk (LIST): Disable go in bpf-*-*
Hi,
The attached patch is a fix for PR88839 ported from sve-acle-branch.
OK to commit to trunk ?
Thanks,
Prathamesh
2019-08-21 Prathamesh Kulkarni
Richard Sandiford
PR target/88839
* config/aarch64/aarch64.c (aarch64_evpc_sel): New function.
This is a little corner case that I noticed in my rewrite of the RELOAD_REG
stuff for the future machine.
I was testing what registers were allowed in what registers for various systems
(power5 through power9 for big endian on both 32 & 64-bit systems, and
power8/power9 for little endian
On Tue, Aug 20, 2019 at 06:13:00PM +0200, Ilya Leoshkevich wrote:
> > Am 20.08.2019 um 17:50 schrieb Segher Boessenkool
> > :
> > There is currently no way to say (in trees or gimple or rtl) whether
> > comparisons are signaling ("ordered", generate a trap on an unordered
> > result). I am
> Am 20.08.2019 um 17:50 schrieb Segher Boessenkool
> :
>
> On Tue, Aug 20, 2019 at 11:18:38AM +0200, Ilya Leoshkevich wrote:
>> Currently it's not clear whether or not min, max and ltgt should raise
>> floating point exceptions when dealing with qNaNs.
>>
>> Right now a lot of code assumes
jose.march...@oracle.com (Jose E. Marchesi) writes:
> Hi Richard!
>
> Many thanks for the deep review. I'm addressing some of your questions
> below.
>
> > [...]
> > +/* Override options and do some other initialization. */
> > +
> > +static void
> > +bpf_option_override
> Am 20.08.2019 um 17:32 schrieb Segher Boessenkool
> :
>
> On Tue, Aug 20, 2019 at 05:19:46PM +0200, Ilya Leoshkevich wrote:
>>> Am 20.08.2019 um 17:04 schrieb Segher Boessenkool
>>> :
>>> The < and > operators separately already can cause exceptions, unless
>>> you use -fno-trapping-math, in
On 16/07/2019 13:58, Richard Sandiford wrote:
Christophe Lyon writes:
The FDPIC register is hard-coded to r9, as defined in the ABI.
We have to disable tailcall optimizations if we don't know if the
target function is in the same module. If not, we have to set r9 to
the value associated with
On Tue, Aug 20, 2019 at 11:18:38AM +0200, Ilya Leoshkevich wrote:
> Currently it's not clear whether or not min, max and ltgt should raise
> floating point exceptions when dealing with qNaNs.
>
> Right now a lot of code assumes that LTGT is signaling: in particular,
> it's generated for ((x < y)
Ah, yes that was unexpected...
Sorry for the breakage.
So this needs to be known_eq (STACK_POINTER_OFFSET, 0)
instead of STACK_POINTER_OFFSET == 0 obviously.
Should be fixed by this patch, which I am going to commit
as "obvious" in a moment unless someone objects.
Thanks
Bernd.
On 8/20/19
On Tue, Aug 20, 2019 at 05:19:46PM +0200, Ilya Leoshkevich wrote:
> > Am 20.08.2019 um 17:04 schrieb Segher Boessenkool
> > :
> > The < and > operators separately already can cause exceptions, unless
> > you use -fno-trapping-math, in which case you cannot have LTGT at all.
>
> Hmm, I've just
> Am 20.08.2019 um 17:04 schrieb Segher Boessenkool
> :
>
> On Tue, Aug 20, 2019 at 11:18:38AM +0200, Ilya Leoshkevich wrote:
>> Currently it's not clear whether or not min, max and ltgt should raise
>> floating point exceptions when dealing with qNaNs.
>>
>> Right now a lot of code assumes
On Tue, Aug 20, 2019 at 04:20:03PM +0200, Jose E. Marchesi wrote:
> > + (PLUS ADDR_BASE CONST_INT)
> > + (PLUS CONST_INT ADDR_BASE)
>
> The second one isn't canonical rtl, so you shouldn't (need to) handle it.
> Please raise a bug if you find a case where
On Tue, Aug 20, 2019 at 11:18:38AM +0200, Ilya Leoshkevich wrote:
> Currently it's not clear whether or not min, max and ltgt should raise
> floating point exceptions when dealing with qNaNs.
>
> Right now a lot of code assumes that LTGT is signaling: in particular,
> it's generated for ((x < y)
> > +/*** Order of Allocation of Registers. */
> > +
> > +/* We generally want to put call-clobbered registers ahead of
> > + call-saved ones. (IRA expects this.) */
> > +#define REG_ALLOC_ORDER\
> > + {0, 1, 2, 3, 4, 5, 6, 7,
> [...]
> +;; Division
> +(define_insn "div3"
> + [(set (match_operand:AM 0 "register_operand" "=r,r")
> +(div:AM (match_operand:AM 1 "register_operand" " 0,0")
> +(match_operand:AM 2 "reg_or_imm_operand" "r,I")))]
> + ""
> +
On Mon, Aug 19, 2019 at 08:57:22PM +0100, Richard Sandiford wrote:
> > +/*** Order of Allocation of Registers. */
> > +
> > +/* We generally want to put call-clobbered registers ahead of
> > + call-saved ones. (IRA expects this.) */
> > +#define REG_ALLOC_ORDER
On 2019-08-15 3:47 p.m., Bernd Edlinger wrote:
> 2019-08-15 Bernd Edlinger
>
> PR middle-end/89544
> * function.c (assign_parm_find_stack_rtl): Use larger alignment
> when possible.
This patch breaks build on hppa-unknown-linux-gnu:
Hi Richard!
Many thanks for the deep review. I'm addressing some of your questions
below.
> [...]
> +/* Override options and do some other initialization. */
> +
> +static void
> +bpf_option_override (void)
> +{
> + /* Set the default target kernel if no -mkernel
On Tue, Aug 20, 2019 at 10:37 AM Robin Dapp wrote:
>
> > So - which case is it? IIRC we want to handle small signed
> > constants but the code can end up unsigned. For the
> > above we could write (unsigned long)((int)a + 1 - 1) and thus
> > sign-extend? Or even avoid this if we know the
> I see. I guess dropping them if !virtual_method_call_p (at what point
> do we know?) would be a good thing. As well as encoding
> "types_same_for_odr" and obj_type_ref_class in a more direct manner.
> I guess in reality OBJ_TYPE_REF should be all info on the
> gimple_call rather than in a
On Mon, Aug 19, 2019 at 4:34 PM Jan Hubicka wrote:
>
> > On Fri, Aug 16, 2019 at 2:07 PM Jan Hubicka wrote:
> > >
> > > >
> > > > When we compare OBJ_TYPE_REF_TOKEN and OBJ_TYPE_REF_OBJECT
> > > > and they are equal, are there cases where types_same_for_odr returns
> > > > false?
> > >
> > >
Excessive use of __builtin_assume_aligned can cause missed optimizations
because those calls are propagation barriers. The following removes
those that are redundant and provide no extra information, on the
testcase allowng store-merging to apply.
Since the bit lattice and the const/copy
The following should fix PR37242.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2019-08-20 Richard Biener
PR tree-optimization/37242
* tree-ssa-sccvn.c (visit_nary_op): Also CSE (T)(a + b)
to (T)a + (T)b if we know that a + b does
Ilya Leoshkevich writes:
>> Am 20.08.2019 um 12:13 schrieb Richard Sandiford :
>>
>> Ilya Leoshkevich writes:
>>> z13 supports only non-signaling vector comparisons. This means we
>>> cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13.
>>> However, we cannot express this
> On Fri, Aug 16, 2019 at 10:53 AM Richard Biener
> wrote:
> >
> > On Fri, Aug 16, 2019 at 10:47 AM Richard Biener
> > wrote:
> > >
> > > On Thu, Aug 15, 2019 at 4:25 PM Jan Hubicka wrote:
> > > >
> > > > > On Thu, Aug 1, 2019 at 3:10 PM Martin Liška wrote:
> > > > > >
> > > > > > Hi.
> > > >
These are the libgomp patches (including testcases). Not much has
changed from last submission besides renaming to 'non-contiguous', etc. and
rebasing.
Thanks,
Chung-Lin
libgomp/
* target.c (struct gomp_ncarray_dim): New struct declaration.
(struct
These are the patches for gimplify, omp-low, and include/gomp-constants.h
On issue that Jakub raised in the last review email on omp-low changes [1],
was the use of DECL_IGNORED_P. Because the descriptor variables are created was
create_tmp_var_raw(), they already have DECL_IGNORED_P set, so
Hi Jakub, Thomas,
this is a re-submission of the patch-set from [1].
The usage of the term "dynamic arrays" didn't go well with Jakub the last time,
so this time I'm referring to this functionality as "non-contiguous arrays".
int *a[100], **b;
// re-constructs array slices on GPU and copies
> Am 20.08.2019 um 12:13 schrieb Richard Sandiford :
>
> Ilya Leoshkevich writes:
>> z13 supports only non-signaling vector comparisons. This means we
>> cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13.
>> However, we cannot express this restriction today: the code only checks
Ilya Leoshkevich writes:
> z13 supports only non-signaling vector comparisons. This means we
> cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13.
> However, we cannot express this restriction today: the code only checks
> whether vcond$a$b optab, which does not contain information
On Fri, Aug 16, 2019 at 10:53 AM Richard Biener
wrote:
>
> On Fri, Aug 16, 2019 at 10:47 AM Richard Biener
> wrote:
> >
> > On Thu, Aug 15, 2019 at 4:25 PM Jan Hubicka wrote:
> > >
> > > > On Thu, Aug 1, 2019 at 3:10 PM Martin Liška wrote:
> > > > >
> > > > > Hi.
> > > > >
> > > > > In LTO WPA
The compiler can now warn for out-of-order record representation
clauses. A warning is given if the order of component declarations,
component clauses, and bit-level layout do not all agree. The warning
is disabled by default, and may be enabled by the -gnatw_r switch.
Tested on
The compiler now generates faster code for functions that return
discriminated types in many cases where the size is known at compile
time.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-08-20 Bob Duff
gcc/ada/
* exp_ch6.adb (Needs_BIP_Alloc_Form): Call
This patch fixes a crash on an aspect specification for Storage_Size for
a type T when the expression for the aspect depends on attributes of a
previously declared type that is not frozen yet. The temporary
declaration that captures the value of the aspect must be part of the
actions attached to
The modification to round time up to even second was added decades ago.
It was done to avoid unneeded recompilations when the project was built
on non-FAT filesystems and then moved to FAT filesystems. Such a
situation is now very rare and does not deserve time distortion.
Tested on
The special expansion done in GNATprove mode should be adapted to slices
where the prefix has access type, like indexed expressions.
There is no impact on compilation.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-08-20 Yannick Moy
gcc/ada/
* exp_spark.adb
Routine Build_DIC_Procedure_Declaration appears to be heavily inspired
by Build_Invariant_Procedure_Declaration; they both wrap an expression
attached to a type inside an internal procedure. Initially none of them
were calling Set_Last_Entity.
For Build_Invariant_Procedure_Declaration this was
It's illegal to call a function with a result of an immutably limited
type inside a type conversion that's used in one of the special contexts
that allow such a function call by itself (see RM 7.5 (2.1-2.10)), such
as in the initialization expression of an object declaration. The
compiler was
The generated code has been improved so that aggregates with <> are more
efficient. No change in behavior; no test.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-08-20 Bob Duff
gcc/ada/
* exp_aggr.adb (Expand_Array_Aggregate): Use build-in-place in
the nonlimited
The Delete operations in the bounded ordered containers have been
substantially sped up. No change in semantics, so no test.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-08-20 Bob Duff
gcc/ada/
* libgnat/a-cborma.adb, libgnat/a-cborse.adb (Clear): Repeatedly
call
If the delta_aggregate feature is used, the -gnat2020 or -gnatX switch
must be given.
The following test must get an error if neither
-gnat2020 nor -gnatX is specified:
gcc -c delta_aggregate.ads -gnat2012
delta_aggregate.ads:4:18: delta_aggregate is an Ada 202x feature
This instructs -gnatR4 to also list the Etype of a user-declared record
subtype if it is compiler-generated, for example in:
package P is
type U_Arr is array (Integer range <>) of Character;
type Rec1 (D1, D2 : Integer) is record
C : U_Arr (D1 .. D2);
end record;
type Rec_N
When expanding a loop entry attribute for a while_loop we construct a
function that incorporates the expanded condition of the loop. The
itypes that may be generated in that expansion must carry the scope of
the constructed function for proper handling in the backend.
Tested on
If a variable has pragma Persistent_BSS, the compiler now automatically
suppresses implicit initializations caused by Initialize_Scalars and
Normalize_Scalars. Variables with Persistent_BSS cannot be initialized,
and previously a pragma Suppress_Initialization was required before the
pragma
Where possible GNAT will store the binary representation of a record
aggregate in memory for space and performance reasons. This
configuration pragma changes this behaviour so that record aggregates
are instead always converted into individual assignment statements.
The following package
This patch fixes a spurious visibility error on a dispatching call to
a subprogram with a classwide precondition, when the call qppears in
the same declarative part as the subprogram declaration itself.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-08-20 Ed Schonberg
gcc/ada/
This change is aimed at removing a couple of linear searches in the
units management code that can become problematic performance-wise when
the number of loaded units is in the several hundreds, which can happen
for large files even at -O0 without any inlining.
It introduces an auxiliary hash
Pragma Warning_As_Error now works for style warnings (messages that
start with "(style)", enabled by -gnaty) the same way it works for
regular warnings enabled by -gnatw.
The following test should fail to build with style checks:
gnat.adc:
pragma Warning_As_Error ("two spaces required");
The compiler usually warns on Unchecked_Conversion between types with
mismatched sizes. This warning is now extended to the case where the
target type is a zero-sized array.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-08-20 Bob Duff
gcc/ada/
* sem_ch13.adb
This patch makes the temp for initialization of an atomic variable be
constant.
No change in behavior; no test.
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-08-20 Bob Duff
gcc/ada/
* freeze.adb (Is_Atomic_VFA_Aggregate): Make the temp for
initialization of the
Years ago, we adapted Get_Kind_Of_Unit so that gnatprove could use it to
detect both bodies and specs of predefined units.
However, this wasn't really needed: gnatprove could simply reuse
Lib.In_Predefined_Unit and now it does. This patch simply reverts two
commits mentioned above.
No frontend
The patch gives an error message on "for T'Object_Size use 0;".
Tested on x86_64-pc-linux-gnu, committed on trunk
2019-08-20 Bob Duff
gcc/ada/
* sem_ch13.adb (Object_Size): Give an error for zero. It really
rubs me the wrong way that we don't honor "for T'Object_Size use
> On Thu, Aug 15, 2019 at 12:22:46AM +0200, Jose E. Marchesi wrote:
> > --- a/configure
> > +++ b/configure
> > @@ -754,6 +754,7 @@ infodir
> > docdir
> > oldincludedir
> > includedir
> > +runstatedir
> > localstatedir
> > sharedstatedir
> >
dg-torture.exp=inf-compare-1.c is failing, because (qNaN > +Inf)
comparison is compiled to CDB instruction, which does not signal an
invalid operation exception. KDB should have been used instead.
This patch introduces a new CCmode and a new pattern in order to
generate signaling instructions in
gcc/testsuite/ChangeLog:
2019-08-09 Ilya Leoshkevich
* gcc.target/s390/s390.exp: Enable Fortran tests.
* gcc.target/s390/zvector/autovec-double-quiet-eq.c: New test.
* gcc.target/s390/zvector/autovec-double-quiet-ge.c: New test.
*
s390.md uses a lot of near-identical expanders that perform dispatching
to other expanders based on operand types. Since the following patch
would require even more of these, avoid copy-pasting the code by
generating these expanders using an iterator.
gcc/ChangeLog:
2019-08-09 Ilya Leoshkevich
vec_unordered is vec_ordered plus a negation at the end.
Reuse vec_unordered logic.
gcc/ChangeLog:
2019-08-13 Ilya Leoshkevich
* config/s390/vector.md (vec_unordered): Call
gen_vec_ordered.
---
gcc/config/s390/vector.md | 14 +++---
1 file changed, 7 insertions(+), 7
Currently it's not clear whether or not min, max and ltgt should raise
floating point exceptions when dealing with qNaNs.
Right now a lot of code assumes that LTGT is signaling: in particular,
it's generated for ((x < y) || (x > y)), which is signaling. The
behavior of MIN/MAX is (intentionally?)
z13 supports only non-signaling vector comparisons. This means we
cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13. Notify
middle-end about this using vcond_supported_p hook.
gcc/ChangeLog:
2019-08-09 Ilya Leoshkevich
* config/s390/s390.c (s390_vcond_supported_p):
Currently gcc does not emit wf{c,k}* instructions when comparing long
double values. Middle-end actually adds them in the first place, but
then veclower pass replaces them with floating point register pair
operations, because the corresponding expander is missing.
gcc/ChangeLog:
2019-08-09
z13 supports only non-signaling vector comparisons. This means we
cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13.
However, we cannot express this restriction today: the code only checks
whether vcond$a$b optab, which does not contain information about the
operation.
Introduce a
Bootstrapped and regtested on x86_64-redhat-linux and
s390x-redhat-linux.
This patch series adds signaling FP comparison support (both scalar and
vector) to s390 backend.
The first patch documents the current behavior of MIN, MAX and LTGT
operations with respect to signaling.
The second patch
before reload if HARD_FRAME_POINTER_IS_ARG_POINTER.
2019-08-20 Eric Botcazou
* gcc.c-torture/execute/20190820-1.c: New test.
--
Eric BotcazouIndex: dse.c
===
--- dse.c (revision 274487)
+++ dse.c (working copy
On Tue, 20 Aug 2019, Uros Bizjak wrote:
> >> Uros noted that STV with !TImode isn't supposed to run before combine.
> >> The following adjusts things accordingly and now the pass runs twice
> >> for TARGET_64BIT. I've also adjusted another gpr->xmm move to
> >> use (vec_merge (vec_duplicate..))
> So - which case is it? IIRC we want to handle small signed
> constants but the code can end up unsigned. For the
> above we could write (unsigned long)((int)a + 1 - 1) and thus
> sign-extend? Or even avoid this if we know the range.
> That is, it becomes the first case again (operation
>> Uros noted that STV with !TImode isn't supposed to run before combine.
>> The following adjusts things accordingly and now the pass runs twice
>> for TARGET_64BIT. I've also adjusted another gpr->xmm move to
>> use (vec_merge (vec_duplicate..)) style rather than using a subreg.
>> This isn't
> -Original Message-
> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> Sent: Friday, August 16, 2019 11:07 PM
> To: H.J. Lu
> Cc: Cui, Lili ; Jeff Law ; GCC Patches
> ; Zhang, Annita ; Xiao,
> Wei3 ; Liu, Hongtao ; Wang,
> Hongyu ; Castillo, Jason M
>
> Subject: Re: Add TIGERLAKE and
On Tue, Aug 20, 2019 at 4:32 AM Martin Sebor wrote:
>
> On 8/19/19 8:10 AM, Richard Biener wrote:
> > On Sat, Aug 17, 2019 at 12:43 AM Martin Sebor wrote:
> >>
> >> With the recent enhancement to the strlen handling of multibyte
> >> stores the g++.dg/warn/Warray-bounds-4.C for zero-length
84 matches
Mail list logo
