* [r14-3823 Regression] FAIL: c-c++-common/analyzer/compound-assignment-1.c -std=c++98 (test for warnings, line 72) on Linux/x86_64 [not found] <202309092344.389NiSeQ3407880@shliclel4214.sh.intel.com> @ 2023-09-11 8:03 ` Jiang, Haochen 2023-09-11 17:27 ` Benjamin Priour 0 siblings, 1 reply; 7+ messages in thread From: Jiang, Haochen @ 2023-09-11 8:03 UTC (permalink / raw) To: vultkayn, gcc-regression, gcc-patches, 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.) ^ permalink raw reply [flat|nested] 7+ messages in thread
* 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 2023-09-11 8:03 ` [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 @ 2023-09-11 17:27 ` Benjamin Priour 2023-09-11 21:11 ` Jakub Jelinek 0 siblings, 1 reply; 7+ messages in thread From: Benjamin Priour @ 2023-09-11 17:27 UTC (permalink / raw) To: Jiang, Haochen; +Cc: vultkayn, gcc-regression, gcc-patches [-- 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.) > ^ permalink raw reply [flat|nested] 7+ messages in thread
* 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 2023-09-11 17:27 ` Benjamin Priour @ 2023-09-11 21:11 ` Jakub Jelinek 2023-09-12 7:02 ` [PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377] Jakub Jelinek 0 siblings, 1 reply; 7+ messages in thread From: Jakub Jelinek @ 2023-09-11 21:11 UTC (permalink / raw) To: Benjamin Priour; +Cc: Jiang, Haochen, vultkayn, gcc-regression, gcc-patches 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377] 2023-09-11 21:11 ` Jakub Jelinek @ 2023-09-12 7:02 ` Jakub Jelinek 2023-09-13 21:58 ` David Malcolm 2023-09-19 7:20 ` Patch ping: " Jakub Jelinek 0 siblings, 2 replies; 7+ messages in thread From: Jakub Jelinek @ 2023-09-12 7:02 UTC (permalink / raw) To: Benjamin Priour, David Malcolm; +Cc: gcc-patches 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377] 2023-09-12 7:02 ` [PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377] Jakub Jelinek @ 2023-09-13 21:58 ` David Malcolm 2023-09-19 7:20 ` Patch ping: " Jakub Jelinek 1 sibling, 0 replies; 7+ messages in thread From: David Malcolm @ 2023-09-13 21:58 UTC (permalink / raw) To: Jakub Jelinek, Benjamin Priour; +Cc: gcc-patches 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Patch ping: [PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377] 2023-09-12 7:02 ` [PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377] Jakub Jelinek 2023-09-13 21:58 ` David Malcolm @ 2023-09-19 7:20 ` Jakub Jelinek 2023-09-19 14:47 ` David Malcolm 1 sibling, 1 reply; 7+ messages in thread From: Jakub Jelinek @ 2023-09-19 7:20 UTC (permalink / raw) To: Benjamin Priour, David Malcolm; +Cc: gcc-patches 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Patch ping: [PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377] 2023-09-19 7:20 ` Patch ping: " Jakub Jelinek @ 2023-09-19 14:47 ` David Malcolm 0 siblings, 0 replies; 7+ messages in thread From: David Malcolm @ 2023-09-19 14:47 UTC (permalink / raw) To: Jakub Jelinek, Benjamin Priour; +Cc: gcc-patches 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-09-19 14:47 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <202309092344.389NiSeQ3407880@shliclel4214.sh.intel.com>
2023-09-11 8:03 ` [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
2023-09-11 17:27 ` Benjamin Priour
2023-09-11 21:11 ` Jakub Jelinek
2023-09-12 7:02 ` [PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377] Jakub Jelinek
2023-09-13 21:58 ` David Malcolm
2023-09-19 7:20 ` Patch ping: " Jakub Jelinek
2023-09-19 14:47 ` David Malcolm
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).