[r14-3823 Regression] FAIL: c-c++-common/analyzer/compound-assignment-1.c -std=c++98 (test for warnings, line 72) on Linux/x86_64

[r14-3823 Regression] FAIL: c-c++-common/analyzer/compound-assignment-1.c -std=c++98 (test for warnings, line 72) on Linux/x86_64

[Jiang, Haochen]

On Linux/x86_64,

50b5199cff690891726877e1c00ac53dfb7cc1c8 is the first bad commit
commit 50b5199cff690891726877e1c00ac53dfb7cc1c8
Author: benjamin priour <vultkayn@gcc.gnu.org>
Date:   Sat Sep 9 18:03:56 2023 +0200

    analyzer: Move gcc.dg/analyzer tests to c-c++-common (2) [PR96395]

caused

FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++14 (test for excess errors)
FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++14  (test for warnings, line 72)
FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++17 (test for excess errors)
FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++17  (test for warnings, line 72)
FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++20 (test for excess errors)
FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++20  (test for warnings, line 72)
FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++98 (test for excess errors)
FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++98  (test for warnings, line 72)

with GCC configured with

../../gcc/configure --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-3823/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl --enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check RUNTESTFLAGS="analyzer.exp=c-c++-common/analyzer/compound-assignment-1.c --target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="analyzer.exp=c-c++-common/analyzer/compound-assignment-1.c --target_board='unix{-m32\ -march=cascadelake}'"

(If you met problems with cascadelake related, disabling AVX512F in command line might save that.)
(However, please make sure that there is no potential problems with AVX512.)

Re: [r14-3823 Regression] FAIL: c-c++-common/analyzer/compound-assignment-1.c -std=c++98 (test for warnings, line 72) on Linux/x86_64

[Benjamin Priour]

[-- Attachment #1: Type: text/plain, Size: 2450 bytes --]

Hi,
Thanks for the report,

After investigation it seems the location of the new dejagnu directive for
C++ differs depending on the configuration.
The expected warning is still emitted, but its location differ slightly.
I expect it to be not an issue per se of the analyzer, but a divergence in
the FE between the two configurations.

Need further investigation.

Best,
Benjamin.

On Mon, Sep 11, 2023 at 10:03 AM Jiang, Haochen <haochen.jiang@intel.com>
wrote:

> On Linux/x86_64,
>
> 50b5199cff690891726877e1c00ac53dfb7cc1c8 is the first bad commit
> commit 50b5199cff690891726877e1c00ac53dfb7cc1c8
> Author: benjamin priour <vultkayn@gcc.gnu.org>
> Date:   Sat Sep 9 18:03:56 2023 +0200
>
>     analyzer: Move gcc.dg/analyzer tests to c-c++-common (2) [PR96395]
>
> caused
>
> FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++14 (test for
> excess errors)
> FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++14  (test for
> warnings, line 72)
> FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++17 (test for
> excess errors)
> FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++17  (test for
> warnings, line 72)
> FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++20 (test for
> excess errors)
> FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++20  (test for
> warnings, line 72)
> FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++98 (test for
> excess errors)
> FAIL: c-c++-common/analyzer/compound-assignment-1.c  -std=c++98  (test for
> warnings, line 72)
>
> with GCC configured with
>
> ../../gcc/configure
> --prefix=/export/users/haochenj/src/gcc-bisect/master/master/r14-3823/usr
> --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
> --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet
> --without-isl --enable-libmpx x86_64-linux --disable-bootstrap
>
> To reproduce:
>
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="analyzer.exp=c-c++-common/analyzer/compound-assignment-1.c
> --target_board='unix{-m32}'"
> $ cd {build_dir}/gcc && make check
> RUNTESTFLAGS="analyzer.exp=c-c++-common/analyzer/compound-assignment-1.c
> --target_board='unix{-m32\ -march=cascadelake}'"
>
> (If you met problems with cascadelake related, disabling AVX512F in
> command line might save that.)
> (However, please make sure that there is no potential problems with
> AVX512.)
>

Re: [r14-3823 Regression] FAIL: c-c++-common/analyzer/compound-assignment-1.c -std=c++98 (test for warnings, line 72) on Linux/x86_64

[Jakub Jelinek]

On Mon, Sep 11, 2023 at 07:27:57PM +0200, Benjamin Priour via Gcc-patches wrote:
> Thanks for the report,
> 
> After investigation it seems the location of the new dejagnu directive for
> C++ differs depending on the configuration.
> The expected warning is still emitted, but its location differ slightly.
> I expect it to be not an issue per se of the analyzer, but a divergence in
> the FE between the two configurations.

I think the divergence is whether called_by_test_5b returns the struct
in registers or in memory.  If in memory (like in the x86_64 -m32 case), we have
  [compound-assignment-1.c:71:21] D.3191 = called_by_test_5b (); [return slot optimization]
  [compound-assignment-1.c:71:21 discrim 1] D.3191 ={v} {CLOBBER(eol)};
  [compound-assignment-1.c:72:1] return;
in the IL, while if in registers (like x86_64 -m64 case), just
  [compound-assignment-1.c:71:21] D.3591 = called_by_test_5b ();
  [compound-assignment-1.c:72:1] return;

If you just want to avoid the differences, putting } on the same line as the
call might be a usable workaround for that.

	Jakub

[PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377]

[Jakub Jelinek]

On Mon, Sep 11, 2023 at 11:11:30PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Sep 11, 2023 at 07:27:57PM +0200, Benjamin Priour via Gcc-patches wrote:
> > Thanks for the report,
> > 
> > After investigation it seems the location of the new dejagnu directive for
> > C++ differs depending on the configuration.
> > The expected warning is still emitted, but its location differ slightly.
> > I expect it to be not an issue per se of the analyzer, but a divergence in
> > the FE between the two configurations.
> 
> I think the divergence is whether called_by_test_5b returns the struct
> in registers or in memory.  If in memory (like in the x86_64 -m32 case), we have
>   [compound-assignment-1.c:71:21] D.3191 = called_by_test_5b (); [return slot optimization]
>   [compound-assignment-1.c:71:21 discrim 1] D.3191 ={v} {CLOBBER(eol)};
>   [compound-assignment-1.c:72:1] return;
> in the IL, while if in registers (like x86_64 -m64 case), just
>   [compound-assignment-1.c:71:21] D.3591 = called_by_test_5b ();
>   [compound-assignment-1.c:72:1] return;
> 
> If you just want to avoid the differences, putting } on the same line as the
> call might be a usable workaround for that.

Here is the workaround in patch form.  Tested on x86_64-linux -m32/-m64, ok
for trunk?

2023-09-12  Jakub Jelinek  <jakub@redhat.com>

	PR testsuite/111377
	* c-c++-common/analyzer/compound-assignment-1.c (test_5b): Move
	closing } to the same line as the call to work-around differences in
	diagnostics line.

--- gcc/testsuite/c-c++-common/analyzer/compound-assignment-1.c.jj	2023-09-11 11:05:47.523727789 +0200
+++ gcc/testsuite/c-c++-common/analyzer/compound-assignment-1.c	2023-09-12 08:58:52.854231161 +0200
@@ -68,5 +68,8 @@ called_by_test_5b (void)
 
 void test_5b (void)
 {
-  called_by_test_5b ();
-} /* { dg-warning "leak of '<anonymous>.ptr_wrapper::ptr'" "" { target c++ } } */
+  called_by_test_5b (); }
+/* { dg-warning "leak of '<anonymous>.ptr_wrapper::ptr'" "" { target c++ } .-1 } */
+/* The closing } above is intentionally on the same line as the call, because
+   otherwise the exact line of the diagnostics depends on whether the
+   called_by_test_5b () call satisfies aggregate_value_p or not.  */


	Jakub

Re: [PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377]

[David Malcolm]

On Tue, 2023-09-12 at 09:02 +0200, Jakub Jelinek wrote:
> On Mon, Sep 11, 2023 at 11:11:30PM +0200, Jakub Jelinek via Gcc-
> patches wrote:
> > On Mon, Sep 11, 2023 at 07:27:57PM +0200, Benjamin Priour via Gcc-
> > patches wrote:
> > > Thanks for the report,
> > > 
> > > After investigation it seems the location of the new dejagnu
> > > directive for
> > > C++ differs depending on the configuration.
> > > The expected warning is still emitted, but its location differ
> > > slightly.
> > > I expect it to be not an issue per se of the analyzer, but a
> > > divergence in
> > > the FE between the two configurations.
> > 
> > I think the divergence is whether called_by_test_5b returns the
> > struct
> > in registers or in memory.  If in memory (like in the x86_64 -m32
> > case), we have
> >   [compound-assignment-1.c:71:21] D.3191 = called_by_test_5b ();
> > [return slot optimization]
> >   [compound-assignment-1.c:71:21 discrim 1] D.3191 ={v}
> > {CLOBBER(eol)};
> >   [compound-assignment-1.c:72:1] return;
> > in the IL, while if in registers (like x86_64 -m64 case), just
> >   [compound-assignment-1.c:71:21] D.3591 = called_by_test_5b ();
> >   [compound-assignment-1.c:72:1] return;
> > 
> > If you just want to avoid the differences, putting } on the same
> > line as the
> > call might be a usable workaround for that.
> 
> Here is the workaround in patch form.  Tested on x86_64-linux -m32/-
> m64, ok
> for trunk?

Yes, thanks!

Dave

> 
> 2023-09-12  Jakub Jelinek  <jakub@redhat.com>
> 
>         PR testsuite/111377
>         * c-c++-common/analyzer/compound-assignment-1.c (test_5b):
> Move
>         closing } to the same line as the call to work-around
> differences in
>         diagnostics line.
> 
> --- gcc/testsuite/c-c++-common/analyzer/compound-assignment-
> 1.c.jj      2023-09-11 11:05:47.523727789 +0200
> +++ gcc/testsuite/c-c++-common/analyzer/compound-assignment-1.c 2023-
> 09-12 08:58:52.854231161 +0200
> @@ -68,5 +68,8 @@ called_by_test_5b (void)
>  
>  void test_5b (void)
>  {
> -  called_by_test_5b ();
> -} /* { dg-warning "leak of '<anonymous>.ptr_wrapper::ptr'" "" {
> target c++ } } */
> +  called_by_test_5b (); }
> +/* { dg-warning "leak of '<anonymous>.ptr_wrapper::ptr'" "" { target
> c++ } .-1 } */
> +/* The closing } above is intentionally on the same line as the
> call, because
> +   otherwise the exact line of the diagnostics depends on whether
> the
> +   called_by_test_5b () call satisfies aggregate_value_p or not.  */
> 
> 
>         Jakub
> 

Patch ping: [PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377]

[Jakub Jelinek]

Hi!

On Tue, Sep 12, 2023 at 09:02:55AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Sep 11, 2023 at 11:11:30PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Mon, Sep 11, 2023 at 07:27:57PM +0200, Benjamin Priour via Gcc-patches wrote:
> > > Thanks for the report,
> > > 
> > > After investigation it seems the location of the new dejagnu directive for
> > > C++ differs depending on the configuration.
> > > The expected warning is still emitted, but its location differ slightly.
> > > I expect it to be not an issue per se of the analyzer, but a divergence in
> > > the FE between the two configurations.
> > 
> > I think the divergence is whether called_by_test_5b returns the struct
> > in registers or in memory.  If in memory (like in the x86_64 -m32 case), we have
> >   [compound-assignment-1.c:71:21] D.3191 = called_by_test_5b (); [return slot optimization]
> >   [compound-assignment-1.c:71:21 discrim 1] D.3191 ={v} {CLOBBER(eol)};
> >   [compound-assignment-1.c:72:1] return;
> > in the IL, while if in registers (like x86_64 -m64 case), just
> >   [compound-assignment-1.c:71:21] D.3591 = called_by_test_5b ();
> >   [compound-assignment-1.c:72:1] return;
> > 
> > If you just want to avoid the differences, putting } on the same line as the
> > call might be a usable workaround for that.
> 
> Here is the workaround in patch form.  Tested on x86_64-linux -m32/-m64, ok
> for trunk?

I'd like to ping this patch.

> 2023-09-12  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR testsuite/111377
> 	* c-c++-common/analyzer/compound-assignment-1.c (test_5b): Move
> 	closing } to the same line as the call to work-around differences in
> 	diagnostics line.
> 
> --- gcc/testsuite/c-c++-common/analyzer/compound-assignment-1.c.jj	2023-09-11 11:05:47.523727789 +0200
> +++ gcc/testsuite/c-c++-common/analyzer/compound-assignment-1.c	2023-09-12 08:58:52.854231161 +0200
> @@ -68,5 +68,8 @@ called_by_test_5b (void)
>  
>  void test_5b (void)
>  {
> -  called_by_test_5b ();
> -} /* { dg-warning "leak of '<anonymous>.ptr_wrapper::ptr'" "" { target c++ } } */
> +  called_by_test_5b (); }
> +/* { dg-warning "leak of '<anonymous>.ptr_wrapper::ptr'" "" { target c++ } .-1 } */
> +/* The closing } above is intentionally on the same line as the call, because
> +   otherwise the exact line of the diagnostics depends on whether the
> +   called_by_test_5b () call satisfies aggregate_value_p or not.  */
> 
> 
> 	Jakub

	Jakub

Re: Patch ping: [PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377]

[David Malcolm]

On Tue, 2023-09-19 at 09:20 +0200, Jakub Jelinek wrote:
> Hi!
> 
> On Tue, Sep 12, 2023 at 09:02:55AM +0200, Jakub Jelinek via Gcc-
> patches wrote:
> > On Mon, Sep 11, 2023 at 11:11:30PM +0200, Jakub Jelinek via Gcc-
> > patches wrote:
> > > On Mon, Sep 11, 2023 at 07:27:57PM +0200, Benjamin Priour via
> > > Gcc-patches wrote:
> > > > Thanks for the report,
> > > > 
> > > > After investigation it seems the location of the new dejagnu
> > > > directive for
> > > > C++ differs depending on the configuration.
> > > > The expected warning is still emitted, but its location differ
> > > > slightly.
> > > > I expect it to be not an issue per se of the analyzer, but a
> > > > divergence in
> > > > the FE between the two configurations.
> > > 
> > > I think the divergence is whether called_by_test_5b returns the
> > > struct
> > > in registers or in memory.  If in memory (like in the x86_64 -m32
> > > case), we have
> > >   [compound-assignment-1.c:71:21] D.3191 = called_by_test_5b ();
> > > [return slot optimization]
> > >   [compound-assignment-1.c:71:21 discrim 1] D.3191 ={v}
> > > {CLOBBER(eol)};
> > >   [compound-assignment-1.c:72:1] return;
> > > in the IL, while if in registers (like x86_64 -m64 case), just
> > >   [compound-assignment-1.c:71:21] D.3591 = called_by_test_5b ();
> > >   [compound-assignment-1.c:72:1] return;
> > > 
> > > If you just want to avoid the differences, putting } on the same
> > > line as the
> > > call might be a usable workaround for that.
> > 
> > Here is the workaround in patch form.  Tested on x86_64-linux -
> > m32/-m64, ok
> > for trunk?
> 
> I'd like to ping this patch.

OK

Dave

> 
> > 2023-09-12  Jakub Jelinek  <jakub@redhat.com>
> > 
> >         PR testsuite/111377
> >         * c-c++-common/analyzer/compound-assignment-1.c (test_5b):
> > Move
> >         closing } to the same line as the call to work-around
> > differences in
> >         diagnostics line.
> > 
> > --- gcc/testsuite/c-c++-common/analyzer/compound-assignment-
> > 1.c.jj      2023-09-11 11:05:47.523727789 +0200
> > +++ gcc/testsuite/c-c++-common/analyzer/compound-assignment-
> > 1.c 2023-09-12 08:58:52.854231161 +0200
> > @@ -68,5 +68,8 @@ called_by_test_5b (void)
> >  
> >  void test_5b (void)
> >  {
> > -  called_by_test_5b ();
> > -} /* { dg-warning "leak of '<anonymous>.ptr_wrapper::ptr'" "" {
> > target c++ } } */
> > +  called_by_test_5b (); }
> > +/* { dg-warning "leak of '<anonymous>.ptr_wrapper::ptr'" "" {
> > target c++ } .-1 } */
> > +/* The closing } above is intentionally on the same line as the
> > call, because
> > +   otherwise the exact line of the diagnostics depends on whether
> > the
> > +   called_by_test_5b () call satisfies aggregate_value_p or not. 
> > */
> > 
> > 
> >         Jakub
> 
>         Jakub
>