Re: [PATCH][RFC] tree-optimization/100499 - multiple_of_p bad behavior wrt niter analysis
On Thu, Jul 22, 2021 at 6:41 PM Richard Biener wrote:
>
> This avoids using multiple_of_p in niter analysis when its behavior
Hmm, but this patch actually introduces one more call to
multiple_of_p, also it doesn't touch the below use:
if (niter->control.no_overflow && multiple_of_p (type, c, s))
{
niter->niter = fold_build2 (FLOOR_DIV_EXPR, niter_type, c, s);
return true;
}
> to assume the tested expression does not invoke integer overflow
> produces wrong niter analysis results. For the cases multiple_of_p
> handles power-of-two values of bottom look safe which should also be
> the majority of cases we care about in addition to the constant case
> now handled explicitely.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> I'm unsure how important a "perfect" solution is (rewriting
> multiple_of_p), and wonder whether this solution is preferable
I am still for this approach now, it only needs to be conservative,
rather than perfect, especially if there are not many breakages with a
conservative version multiple_of_p?
> for now (and especially for branches). I've not yet tried
> to sanitize multiple_of_p plus use range info to prove
> no-overflow where TYPE_OVERFLOW_UNDEFINED doesn't tell us
> immediately.
>
> 2021-07-22 Richard Biener
>
> PR tree-optimization/100499
> * tree-ssa-loop-niter.c (number_of_iterations_ne): Restrict
> multiple_of_p queries to power-of-two bottoms, handle
> the all constant case inline.
>
> * gcc.dg/torture/pr100499-1.c: New testcase.
> * gcc.dg/torture/pr100499-2.c: Likewise.
> ---
> gcc/testsuite/gcc.dg/torture/pr100499-1.c | 28 +++
> gcc/testsuite/gcc.dg/torture/pr100499-2.c | 16 +
> gcc/tree-ssa-loop-niter.c | 8 ++-
> 3 files changed, 51 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.dg/torture/pr100499-1.c
> create mode 100644 gcc/testsuite/gcc.dg/torture/pr100499-2.c
>
> diff --git a/gcc/testsuite/gcc.dg/torture/pr100499-1.c
> b/gcc/testsuite/gcc.dg/torture/pr100499-1.c
> new file mode 100644
> index 000..97ab6051554
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr100499-1.c
> @@ -0,0 +1,28 @@
> +/* { dg-do run } */
> +/* { dg-require-effective-target int32plus } */
> +
> +typedef __UINT16_TYPE__ uint16_t;
> +static uint16_t g_2823 = 0xEC75L;
> +static uint16_t g_116 = 0xBC07L;
> +
> +static uint16_t
> +safe_mul_func_uint16_t_u_u(uint16_t ui1, uint16_t ui2)
> +{
> + return ((unsigned int)ui1) * ((unsigned int)ui2);
> +}
> +
> +int main (int argc, char* argv[])
> +{
> + uint16_t l_2815 = 65535UL;
> + uint16_t *l_2821 = _116;
> + uint16_t *l_2822 = _2823;
> +
> +lbl_2826:
> + l_2815 &= 0x9DEF1EAEL;
> + if (+(safe_mul_func_uint16_t_u_u(((*l_2821) = l_2815), (--(*l_2822)
> +goto lbl_2826;
> +
> + if (g_2823 != 32768)
> +__builtin_abort ();
> + return 0;
> +}
> diff --git a/gcc/testsuite/gcc.dg/torture/pr100499-2.c
> b/gcc/testsuite/gcc.dg/torture/pr100499-2.c
> new file mode 100644
> index 000..999f931806a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/torture/pr100499-2.c
> @@ -0,0 +1,16 @@
> +/* { dg-do run } */
> +
> +unsigned char ag = 55;
> +unsigned i;
> +int main()
> +{
> + unsigned char c;
> + unsigned char a = ag;
> +d:
> + c = a-- * 52;
> + if (c)
> +goto d;
> + if (a != 255)
> +__builtin_abort ();
> + return 0;
> +}
> diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c
> index 1b5605c26b8..c6b953c5316 100644
> --- a/gcc/tree-ssa-loop-niter.c
> +++ b/gcc/tree-ssa-loop-niter.c
> @@ -1050,7 +1050,13 @@ number_of_iterations_ne (class loop *loop, tree type,
> affine_iv *iv,
> Note, for NE_EXPR, base equals to FINAL is a special case, in
> which the loop exits immediately, and the iv does not overflow. */
>if (!niter->control.no_overflow
> - && (integer_onep (s) || multiple_of_p (type, c, s)))
> + && (integer_onep (s)
> + || (poly_int_tree_p (c)
> + && multiple_p (wi::to_poly_widest (c), wi::to_poly_widest (s)))
> + /* ??? multiple_of_p assumes the expression 'c' does not overflow
> +but that cannot be guaranteed, so we restrict 's' to power of
> +two values where that should not be an issue. See PR100499. */
> + || (integer_pow2p (s) && multiple_of_p (type, c, s
> {
>tree t, cond, new_c, relaxed_cond = boolean_false_node;
I (to be blamed) added this part of code to special handle cases like
pr34114, now I feel it's in the wrong direction. Ideally this part of
code is unnecessary and conditions will be (it is now) incorporated
into niter->assumptions which should be simplified to 1/0
correspondingly. The only problem is that assumptions are not
appropriately simplified.
Is it possible to incorporate a more powerful solver (like Z3) in GCC
for such cases, e.g., assumption simplification, multiple_of_p, etc..
Oh, we don't do SCEV analysis
Re: PING^1 [PATCH v2] x86: Check AVX512 without mask instructions
On Wed, Jul 14, 2021 at 8:27 PM H.J. Lu wrote:
>
> On Fri, Jun 25, 2021 at 5:39 AM H.J. Lu wrote:
> >
> > On Fri, Jun 25, 2021 at 12:50 AM Uros Bizjak wrote:
> > >
> > > On Fri, Jun 25, 2021 at 4:51 AM Hongtao Liu wrote:
> > > >
> > > > On Fri, Jun 25, 2021 at 12:13 AM Uros Bizjak via Gcc-patches
> > > > wrote:
> > > > >
> > > > > On Thu, Jun 24, 2021 at 2:12 PM H.J. Lu wrote:
> > > > > >
> > > > > > CPUID functions are used to detect CPU features. If vector ISAs
> > > > > > are enabled, compiler is free to use them in these functions. Add
> > > > > > __attribute__ ((target("general-regs-only"))) to CPUID functions
> > > > > > to avoid vector instructions.
> > > > >
> > > > > These functions are intended to be inlined, so how does target
> > > > > attribute affect inlining?
> > > > I guess w/ -O0. they may not be inlined, that's why H.J adds those
> > > > attributes to those functions.
> > >
> > > The problem is not with these functions, but with surrounding checks
> > > for cpuid features. These checks are implemented with logic
> > > instructions, and nothing prevents RA from allocating mask registers,
> > > and consequently mask insn is emitted. Regarding mentioned functions,
> > > cpuid insn pattern has four GPR single-reg constraints, so mask
> > > registers can't be allocated here.
> > >
> > > > pr96814.dump:
> > > > 0804aa40 :
> > > > 804aa40: 8d 4c 24 04 lea0x4(%esp),%ecx
> > > > ...
> > > > 804aa63: 6a 07push $0x7
> > > > 804aa65: e8 e0 e7 ff ffcall 804924a <__get_cpuid_count>
> > > >
> > > > Also we need to add a target attribute to avx512f_os_support (), and
> > > > that would be enough to fix the AVX512 part.
> > > >
> > > > Moreover, all check functions in below files may also need to deal with:
> > > > adx-check.h
> > > > aes-avx-check.h
> > > > aes-check.h
> > > > amx-check.h
> > > > attr-nocf-check-1a.c
> > > > attr-nocf-check-3a.c
> > > > avx2-check.h
> > > > avx2-vpop-check.h
> > > > avx512bw-check.h
> > > > avx512-check.h
> > > > avx512dq-check.h
> > > > avx512er-check.h
> > > > avx512f-check.h
> > > > avx512vl-check.h
> > > > avx-check.h
> > > > bmi2-check.h
> > > > bmi-check.h
> > > > cf_check-1.c
> > > > cf_check-2.c
> > > > cf_check-3.c
> > > > cf_check-4.c
> > > > cf_check-5.c
> > > > f16c-check.h
> > > > fma4-check.h
> > > > fma-check.h
> > > > isa-check.h
> > > > lzcnt-check.h
> > > > m128-check.h
> > > > m256-check.h
> > > > m512-check.h
> > > > mmx-3dnow-check.h
> > > > mmx-check.h
> > > > pclmul-avx-check.h
> > > > pclmul-check.h
> > > > pr39315-check.c
> > > > rtm-check.h
> > > > sha-check.h
> > > > spellcheck-options-1.c
> > > > spellcheck-options-2.c
> > > > spellcheck-options-3.c
> > > > spellcheck-options-4.c
> > > > spellcheck-options-5.c
> > > > sse2-check.h
> > > > sse3-check.h
> > > > sse4_1-check.h
> > > > sse4_2-check.h
> > > > sse4a-check.h
> > > > sse-check.h
> > > > ssse3-check.h
> > > > stack-check-11.c
> > > > stack-check-12.c
> > > > stack-check-17.c
> > > > stack-check-18.c
> > > > stack-check-19.c
> > > > xop-check.h
> > >
> > > True, but this would just paper over the real problem. Now, it is
> > > expected that the user decorates the function that checks CPUID
> > > features with the target attribute. I'm not sure if this is OK.
vmovw is enabled by AVX512FP16, and compile cpuid check function w/
avx512fp16 may result in SIGILL on non-avx512fp16 target(though, we
didn't get a testcase yet).
Would that be a sufficient reason to disable avx512 for cpuid check?
> > >
> > > Uros.
> >
> > CPUID functions are used to detect CPU features. If mask instructions
> > are enabled, compiler is free to use them in these functions. Disable
> > AVX512F in AVX512 check with target pragma to avoid mask instructions.
> >
> > OK for master?
> >
>
> PING:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573717.html
>
>
> --
> H.J.
--
BR,
Hongtao
Re: [PATCH 44/62] AVX512FP16: Add scalar/vector bitwise operations, including
On Fri, Jul 23, 2021 at 1:13 PM Hongtao Liu wrote:
>
> On Thu, Jul 1, 2021 at 2:18 PM liuhongt wrote:
> >
> > From: "H.J. Lu"
> >
> > 1. FP16 vector xor/ior/and/andnot/abs/neg
> > 2. FP16 scalar abs/neg/copysign/xorsign
> >
> > gcc/ChangeLog:
> >
> > * config/i386/i386-expand.c (ix86_expand_fp_absneg_operator):
> > Handle HFmode.
> > (ix86_expand_copysign): Ditto.
> > (ix86_expand_xorsign): Ditto.
> > * config/i386/i386.c (ix86_build_const_vector): Handle HF vector
> > modes.
> > (ix86_build_signbit_mask): Ditto.
> > (ix86_can_change_mode_class): Ditto.
> > * config/i386/i386.md (SSEMODEF): Add HF mode.
> > (ssevecmodef): Ditto.
> > (2): Use MODEFH.
> > (*2_1): Ditto.
> > (define_split): Ditto.
> > (xorsign3): Ditto.
> > (@xorsign3_1): Ditto.
> As mentioned by uros, l think these also better have separate patterns for hf.
I realized there're parameters names in define_insn and
define_insn_and_split, and they will be called by xorsign/copysign
functions in i386-expand.c, for simplicity i'd like to keep the
macroization of HF patterns in this patch.
> > * config/i386/sse.md (VFB): New mode iterator.
> > (VFB_128_256): Ditto.
> > (VFB_512): Ditto.
> > (sseintvecmode2): Support HF vector mode.
> > (2): Use new mode iterator.
> > (*2): Ditto.
> > (copysign3): Ditto.
> > (xorsign3): Ditto.
> > (3): Ditto.
> > (3): Ditto.
> > (_andnot3): Adjust for HF vector mode.
> > (_andnot3): Ditto.
> > (*3): Ditto.
> > (*3): Ditto.
> > ---
> > gcc/config/i386/i386-expand.c | 12 +++-
> > gcc/config/i386/i386.c| 12 +++-
> > gcc/config/i386/i386.md | 40 ++-
> > gcc/config/i386/sse.md| 128 --
> > 4 files changed, 118 insertions(+), 74 deletions(-)
> >
> > diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
> > index 9233c6cd1e8..006f4bec8db 100644
> > --- a/gcc/config/i386/i386-expand.c
> > +++ b/gcc/config/i386/i386-expand.c
> > @@ -1781,6 +1781,8 @@ ix86_expand_fp_absneg_operator (enum rtx_code code,
> > machine_mode mode,
> > vmode = V4SFmode;
> >else if (mode == DFmode)
> > vmode = V2DFmode;
> > + else if (mode == HFmode)
> > + vmode = V8HFmode;
> > }
> >
> >dst = operands[0];
> > @@ -1918,7 +1920,9 @@ ix86_expand_copysign (rtx operands[])
> >
> >mode = GET_MODE (dest);
> >
> > - if (mode == SFmode)
> > + if (mode == HFmode)
> > +vmode = V8HFmode;
> > + else if (mode == SFmode)
> > vmode = V4SFmode;
> >else if (mode == DFmode)
> > vmode = V2DFmode;
> > @@ -1934,7 +1938,7 @@ ix86_expand_copysign (rtx operands[])
> >if (real_isneg (CONST_DOUBLE_REAL_VALUE (op0)))
> > op0 = simplify_unary_operation (ABS, mode, op0, mode);
> >
> > - if (mode == SFmode || mode == DFmode)
> > + if (mode == HFmode || mode == SFmode || mode == DFmode)
> > {
> > if (op0 == CONST0_RTX (mode))
> > op0 = CONST0_RTX (vmode);
> > @@ -2073,7 +2077,9 @@ ix86_expand_xorsign (rtx operands[])
> >
> >mode = GET_MODE (dest);
> >
> > - if (mode == SFmode)
> > + if (mode == HFmode)
> > +vmode = V8HFmode;
> > + else if (mode == SFmode)
> > vmode = V4SFmode;
> >else if (mode == DFmode)
> > vmode = V2DFmode;
> > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> > index dc0d440061b..17e1b5ea874 100644
> > --- a/gcc/config/i386/i386.c
> > +++ b/gcc/config/i386/i386.c
> > @@ -15374,6 +15374,9 @@ ix86_build_const_vector (machine_mode mode, bool
> > vect, rtx value)
> > case E_V2DImode:
> >gcc_assert (vect);
> >/* FALLTHRU */
> > +case E_V8HFmode:
> > +case E_V16HFmode:
> > +case E_V32HFmode:
> > case E_V16SFmode:
> > case E_V8SFmode:
> > case E_V4SFmode:
> > @@ -15412,6 +15415,13 @@ ix86_build_signbit_mask (machine_mode mode, bool
> > vect, bool invert)
> >
> >switch (mode)
> > {
> > +case E_V8HFmode:
> > +case E_V16HFmode:
> > +case E_V32HFmode:
> > + vec_mode = mode;
> > + imode = HImode;
> > + break;
> > +
> > case E_V16SImode:
> > case E_V16SFmode:
> > case E_V8SImode:
> > @@ -19198,7 +19208,7 @@ ix86_can_change_mode_class (machine_mode from,
> > machine_mode to,
> > disallow a change to these modes, reload will assume it's ok to
> > drop the subreg from (subreg:SI (reg:HI 100) 0). This affects
> > the vec_dupv4hi pattern. */
> > - if (GET_MODE_SIZE (from) < 4)
> > + if (GET_MODE_SIZE (from) < 4 && from != E_HFmode)
> > return false;
> > }
> >
> > diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> > index 014aba187e1..a85c23d74f1 100644
> > --- a/gcc/config/i386/i386.md
> > +++ b/gcc/config/i386/i386.md
> > @@ -1233,9
Re: 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch
On Sat, Jul 24, 2021 at 12:30 AM Jeff Law via Gcc-patches wrote: > > > > On 7/14/2021 3:14 AM, bin.cheng via Gcc-patches wrote: > > Hi, > > I ran into a wrong code bug in code with deep template instantiation when > > working on sdx::simd. > > The root cause as described in commit summary is we skip prologue insns in > > init_alias_analysis. > > This simple patch fixes the issue, however, it's hard to reduce a case > > because of heavy use of > > templates. > > Bootstrap and test on x86_64, is it OK? > It's a clear correctness improvement, but what's unclear to me is why > we'd want to skip them in the epilogue either. I can only guess, there is nothing to initialize epilogue for because no code follows. Thanks, bin > > Jeff
[PATCH v2, Fortran] TS 29113 testsuite
Here is an updated version of my TS29113 testsuite. The last version I posted became kind of bit-rotten after Tobias's commit "Fortran: Fix bind(C) character length checks" for PR92842, which changed the wording of the error message that I'd been catching with dg-bogus in many places. I've also merged some bug fixes to the test cases (most of which I'd already posted in conjunction with other patches to fix the associated library function bugs), and updated all the ISO_Fortran_binding.h #includes on the theory that I will iron out the remaining include-path problem with my patch series for PR101305 and get that committed before some consensus is reached on what to do about this patch. With this version I'm now getting 263 XFAILs per multilib on x86. With the bug fix patches I have already posted that are still awaiting review/committal, 42 of those go away. And this approved but not-yet-committed patch from Jose https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572725.html fixes 6 more. Reducing the exact number of XFAILs probably doesn't matter to the meta-discussion about whether it is OK to commit a pile of tests with so many things XFAILed, but passing around updated patches like this is about the only way to keep a working version of the testsuite handy to anyone besides me who might want to help fix some of these bugs and to make sure we aren't introducing regressions. :-( -Sandra ts29113-jul25.patch.gz Description: application/gzip
Re: [patch][version5]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc
> On Jul 25, 2021, at 10:59 AM, Qing Zhao via Gcc-patches > wrote: > > Hi, > > This is the 5th version of the patch for the new security feature for GCC. > > I have tested it with bootstrap on both x86 and aarch64, regression testing > on both x86 and aarch64. > Also compile and run CPU2017, without any issue. NOTE here, for CPU2017 -ftrivial-auto-var-init=pattern, I opened bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586 And then the compilation and running of CPU2017 is done with my 5th patch + the patch provided from Jakub for PR101586. Qing > Please take a look and let me know your comments and suggestions. > > thanks. > > Qing > > **Compare with the 4th version, the following are the major changes: > > 1. delete the code for handling "grp_to_be_debug_replaced" since they are not > needed per Martin Jambor's suggestion. > 2. for Pattern init, call __builtin_clear_padding after the call to > .DEFERRED_INIT to initialize the paddings to zeroes; > 3. for partially or fully initialized auto variables, call > __builtin_clear_padding before the real initialization to initialize >the paddings to zeroes. > 4. Update the documentation with padding initialization to zeroes. > 5. in order to reuse __builtin_clear_padding for auto init purpose, add one > more dummy argument to indiciate whether it's for auto init or not, > if for auto init, do not emit error messages to avoid confusing users. > 6. Add new testing cases to verify padding initializations. > 7. rename some of the old testing cases to make the file name reflecting the > testing purpose per Kees Cook's suggestions. > > **Please see version 4 at: > https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574642.html > > **ChangeLog is: > gcc/ChangeLog: > > 2021-07-23 qing zhao > >* builtins.c (expand_builtin_memset): Make external visible. >* builtins.h (expand_builtin_memset): Declare extern. >* common.opt (ftrivial-auto-var-init=): New option. >* doc/extend.texi: Document the uninitialized attribute. >* doc/invoke.texi: Document -ftrivial-auto-var-init. >* flag-types.h (enum auto_init_type): New enumerated type >auto_init_type. >* gimple-fold.c (clear_padding_type): Add one new parameter. >(clear_padding_union): Likewise. >(clear_padding_emit_loop): Likewise. >(clear_type_padding_in_mask): Likewise. >(gimple_fold_builtin_clear_padding): Handle this new parameter. >* gimplify.c (gimple_add_init_for_auto_var): New function. >(maybe_with_size_expr): Forword declaration. >(build_deferred_init): New function. >(gimple_add_padding_init_for_auto_var): New function. >(gimplify_decl_expr): Add initialization to automatic variables per >users' requests. >(gimplify_call_expr): Add one new parameter for call to >__builtin_clear_padding. >(gimplify_modify_expr_rhs): Add padding initialization before >gimplify_init_constructor. >* internal-fn.c (INIT_PATTERN_VALUE): New macro. >(expand_DEFERRED_INIT): New function. >* internal-fn.def (DEFERRED_INIT): New internal function. >* tree-cfg.c (verify_gimple_call): Verify calls to .DEFERRED_INIT. >* tree-sra.c (generate_subtree_deferred_init): New function. >(sra_modify_deferred_init): Likewise. >(sra_modify_function_body): Handle calls to DEFERRED_INIT specially. >* tree-ssa-structalias.c (find_func_aliases_for_call): Likewise. >* tree-ssa-uninit.c (warn_uninit): Handle calls to DEFERRED_INIT >specially. >(check_defs): Likewise. >(warn_uninitialized_vars): Likewise. >* tree-ssa.c (ssa_undefined_value_p): Likewise. > > gcc/c-family/ChangeLog: > > 2021-07-23 qing zhao > >* c-attribs.c (handle_uninitialized_attribute): New function. >(c_common_attribute_table): Add "uninitialized" attribute. > > gcc/testsuite/ChangeLog: > > > 2021-07-23 qing zhao > >* c-c++-common/auto-init-1.c: New test. >* c-c++-common/auto-init-10.c: New test. >* c-c++-common/auto-init-11.c: New test. >* c-c++-common/auto-init-12.c: New test. >* c-c++-common/auto-init-13.c: New test. >* c-c++-common/auto-init-14.c: New test. >* c-c++-common/auto-init-15.c: New test. >* c-c++-common/auto-init-16.c: New test. >* c-c++-common/auto-init-2.c: New test. >* c-c++-common/auto-init-3.c: New test. >* c-c++-common/auto-init-4.c: New test. >* c-c++-common/auto-init-5.c: New test. >* c-c++-common/auto-init-6.c: New test. >* c-c++-common/auto-init-7.c: New test. >* c-c++-common/auto-init-8.c: New test. >* c-c++-common/auto-init-9.c: New test. >* c-c++-common/auto-init-esra.c: New test. >* c-c++-common/auto-init-padding-1.c: New test. >*
[PATCH] incorrect arguments designated in -Wnonnull for arrays
Two arguments are switched for -Wnonnull when
warning about array parameters with bounds > 0
and which are NULL.
This patch corrects the mistake.
Martin
2021-07-25 Martin Uecker
gcc/
* calls.c (maybe_warn_rdwr_sizes): Correct argument
numbers in warning that were switched.
gcc/testsuite/
* gcc.dg/Wnonnull-4.c: Correct argument numbers in warnings.
diff --git a/gcc/calls.c b/gcc/calls.c
index d2413a280cf..c54c57206c7 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -2128,8 +2128,8 @@ maybe_warn_rdwr_sizes (rdwr_map *rwm, tree fndecl, tree
fntype, tree exp)
"array %s is null but "
"the corresponding bound argument "
"%i value is %s",
- sizidx + 1, argtypestr.c_str (),
- ptridx + 1, sizstr))
+ ptridx + 1, argtypestr.c_str (),
+ sizidx + 1, sizstr))
arg_warned = OPT_Wnonnull;
}
else if (warning_at (loc, OPT_Wnonnull,
diff --git a/gcc/testsuite/gcc.dg/Wnonnull-4.c
b/gcc/testsuite/gcc.dg/Wnonnull-4.c
index 180a40d4606..2c1c45a9856 100644
--- a/gcc/testsuite/gcc.dg/Wnonnull-4.c
+++ b/gcc/testsuite/gcc.dg/Wnonnull-4.c
@@ -27,9 +27,9 @@ void test_fca_n (int r_m1)
T ( 0);
// Verify positive bounds.
- T ( 1); // { dg-warning "argument 1 of variable length array
'char\\\[n]' is null but
the corresponding bound argument 2 value is 1" }
- T ( 9); // { dg-warning "argument 1 of variable length array
'char\\\[n]' is null but
the corresponding bound argument 2 value is 9" }
- T (max); // { dg-warning "argument 1 of variable length array
'char\\\[n]' is null but
the corresponding bound argument 2 value is \\d+" }
+ T ( 1); // { dg-warning "argument 2 of variable length array
'char\\\[n]' is null but
the corresponding bound argument 1 value is 1" }
+ T ( 9); // { dg-warning "argument 2 of variable length array
'char\\\[n]' is null but
the corresponding bound argument 1 value is 9" }
+ T (max); // { dg-warning "argument 2 of variable length array
'char\\\[n]' is null but
the corresponding bound argument 1 value is \\d+" }
}
@@ -55,9 +55,9 @@ void test_fsa_x_n (int r_m1)
T ( 0);
// Verify positive bounds.
- T ( 1); // { dg-warning "argument 1 of variable length array
'short int\\\[]\\\[n]' is
null but the corresponding bound argument 2 value is 1" }
- T ( 9); // { dg-warning "argument 1 of variable length array
'short int\\\[]\\\[n]' is
null but the corresponding bound argument 2 value is 9" }
- T (max); // { dg-warning "argument 1 of variable length array
'short int\\\[]\\\[n]' is
null but the corresponding bound argument 2 value is \\d+" }
+ T ( 1); // { dg-warning "argument 2 of variable length array
'short int\\\[]\\\[n]' is
null but the corresponding bound argument 1 value is 1" }
+ T ( 9); // { dg-warning "argument 2 of variable length array
'short int\\\[]\\\[n]' is
null but the corresponding bound argument 1 value is 9" }
+ T (max); // { dg-warning "argument 2 of variable length array
'short int\\\[]\\\[n]' is
null but the corresponding bound argument 1 value is \\d+" }
}
@@ -83,9 +83,9 @@ void test_fia_1_n (int r_m1)
T ( 0);
// Verify positive bounds.
- T ( 1); // { dg-warning "argument 1 of variable length array
'int\\\[1]\\\[n]' is null
but the corresponding bound argument 2 value is 1" }
- T ( 9); // { dg-warning "argument 1 of variable length array
'int\\\[1]\\\[n]' is null
but the corresponding bound argument 2 value is 9" }
- T (max); // { dg-warning "argument 1 of variable length array
'int\\\[1]\\\[n]' is null
but the corresponding bound argument 2 value is \\d+" }
+ T ( 1); // { dg-warning "argument 2 of variable length array
'int\\\[1]\\\[n]' is null
but the corresponding bound argument 1 value is 1" }
+ T ( 9); // { dg-warning "argument 2 of variable length array
'int\\\[1]\\\[n]' is null
but the corresponding bound argument 1 value is 9" }
+ T (max); // { dg-warning "argument 2 of variable length array
'int\\\[1]\\\[n]' is null
but the corresponding bound argument 1 value is \\d+" }
}
@@ -111,9 +111,9 @@ void test_fla_3_n (int r_m1)
T ( 0);
// Verify positive bounds.
- T ( 1); // { dg-warning "argument 1 of variable length array 'long
int\\\[3]\\\[n]' is
null but the corresponding bound argument 2 value is 1" }
- T ( 9); // { dg-warning "argument 1 of variable length array 'long
int\\\[3]\\\[n]' is
null but the corresponding bound argument 2 value is 9" }
- T (max); // { dg-warning "argument 1 of variable length array 'long
int\\\[3]\\\[n]' is
null but the corresponding bound argument 2 value is \\d+" }
+ T (
Re: [PATCH] Analyzer: Refactor callstring to work with pairs of supernodes.
On Sun, 25 Jul 2021 at 16:03, Ankur Saini via Gcc-patches
wrote:
>
> Here is the new patch after fixing all the issues pointed out in the previous
> version.
Just a nitpick:
+/* call_string::element_t's inequality operator. */
+bool
+call_string::element_t::operator!= (const call_string::element_t ) const
+{
+ if (m_caller != other.m_caller || m_callee != other.m_callee)
+return true;
+ return false;
+}
Since you define operator== above, perhaps just implement operator != as:
return !(*this == other) ?
Thanks,
Prathamesh
>
>
>
> —
>
> Question :
>
> 1. The mail id I am using here to send the patch (
> arsenic.second...@gmail.com ) and the mail id in the patch (
> arse...@sourceware.org ) are different from one and other, will this affect
> the process in any ways ?
>
>
> Thanks
> - Ankur
Re: [PATCH] Analyzer: Refactor callstring to work with pairs of supernodes.
Here is the new patch after fixing all the issues pointed out in the previous version. call_string.patch Description: Binary data — Question : 1. The mail id I am using here to send the patch ( arsenic.second...@gmail.com ) and the mail id in the patch ( arse...@sourceware.org ) are different from one and other, will this affect the process in any ways ? Thanks - Ankur
