Re: Patch ping: [PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377]
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
> >
> > 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 '.ptr_wrapper::ptr'" "" {
> > target c++ } } */
> > + called_by_test_5b (); }
> > +/* { dg-warning "leak of '.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
>
Patch ping: [PATCH] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377]
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
>
> 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 '.ptr_wrapper::ptr'" "" { target c++ }
> } */
> + called_by_test_5b (); }
> +/* { dg-warning "leak of '.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] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377]
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
>
> 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 '.ptr_wrapper::ptr'" "" {
> target c++ } } */
> + called_by_test_5b (); }
> +/* { dg-warning "leak of '.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] testsuite work-around compound-assignment-1.c C++ failures on various targets [PR111377]
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
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 '.ptr_wrapper::ptr'" "" { target c++ } }
*/
+ called_by_test_5b (); }
+/* { dg-warning "leak of '.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
