[Bug ada/60078] New: acats c761007 fails on ARM

[Bug ada/60078] New: acats c761007 fails on ARM

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078

            Bug ID: 60078
           Summary: acats c761007 fails on ARM
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ada
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bernd.edlinger at hotmail dot de

,.,. C761007 ACATS 2.5 14-02-05 11:14:25^M
---- C761007 Check that if a finalize procedure invoked by a transfer of^M
                control or selection of a terminate alternative attempts^M
                to propagate an exception, the exception is ignored, but^M
                any other finalizations due to be performed are^M
                performed.^M
   * C761007 Asynchronously aborted operation Expecting: GHIJ Got:^M
                GGHIJ.^M
**** C761007 FAILED ****************************.^M
FAIL:   c761007


root@socfpga_cyclone5:/home/ed/gnu/arm-linux-gnueabihf/bin# ./gcc -v
Using built-in specs.
COLLECT_GCC=./gcc
COLLECT_LTO_WRAPPER=/home/ed/gnu/arm-linux-gnueabihf/libexec/gcc/armv7l-unknown-linux-gnueabihf/4.9.0/lto-wrapper
Target: armv7l-unknown-linux-gnueabihf
Configured with: ../gcc-4.9-20140202/configure
--prefix=/home/ed/gnu/arm-linux-gnueabihf
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go --with-arch=armv7-a
--with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
Thread model: posix
gcc version 4.9.0 20140202 (experimental) (GCC)

[Bug ada/60078] acats c761007 fails on ARM

[mikpelinux at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078

--- Comment #3 from Mikael Pettersson <mikpelinux at gmail dot com> ---
This passes for me on armv5tel-linux-gnueabi with gcc trunk/4.8/4.7, on real HW
(Kirkwood), glibc-2.17, linux-3.13 kernel.

[Bug ada/60078] acats c761007 fails on ARM

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> This passes for me on armv5tel-linux-gnueabi with gcc trunk/4.8/4.7, on real
> HW (Kirkwood), glibc-2.17, linux-3.13 kernel.

Single or multi core?

[Bug ada/60078] acats c761007 fails on ARM

[mikpelinux at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078

--- Comment #5 from Mikael Pettersson <mikpelinux at gmail dot com> ---
(In reply to Eric Botcazou from comment #4)
> > This passes for me on armv5tel-linux-gnueabi with gcc trunk/4.8/4.7, on real
> > HW (Kirkwood), glibc-2.17, linux-3.13 kernel.
> 
> Single or multi core?

Single core, alas.

[Bug ada/60078] acats c761007 fails on ARM

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078

--- Comment #6 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Eric,

could it be that the Finalize procedure is missing some sort of spin lock?



ed@w-ed:~/gnu/gcc-build/gcc/testsuite/ada/acats/tests/c7/c761007$ cat
c761007_0.adb

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

with TCTouch;
package body C761007_0 is

  procedure Finalize( I : in out Internal ) is
    Previous_Side_Effect : Boolean := False;
  begin
    -- look to see if this character has been finalized yet
    for SEI in 1..Side_Effect_Finger loop
      Previous_Side_Effect := Previous_Side_Effect
                              or Side_Effect(Side_Effect_Finger) = I.Effect;
    end loop;

    delay 0.01; -- <= additional delay here

    -- if not, then tack it on to the string, and touch the character
    if not Previous_Side_Effect then
      Side_Effect_Finger := Side_Effect_Finger +1;
      Side_Effect(Side_Effect_Finger) := I.Effect;
      TCTouch.Touch(I.Effect);
    end if;

  end Finalize;

end C761007_0;
ed@w-ed:~/gnu/gcc-build/gcc/testsuite/ada/acats/tests/c7/c761007$ ./c761007 

,.,. C761007 ACATS 2.5 14-02-06 10:05:45
---- C761007 Check that if a finalize procedure invoked by a transfer of
                control or selection of a terminate alternative attempts
                to propagate an exception, the exception is ignored, but
                any other finalizations due to be performed are
                performed.
   * C761007 Asynchronously aborted operation Expecting: GHIJ Got:
                GHHIJ.
**** C761007 FAILED ****************************.

[Bug ada/60078] acats c761007 fails on ARM

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078

--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> could it be that the Finalize procedure is missing some sort of spin lock?

There are already explicit delays in the test, so very likely not.

Re: [Bug ada/60078] acats c761007 fails on ARM

[Arnaud Charlet]

> well, I don't know if the Finalize method are supposed
> to be called in a sequential manner, which GNAT does obviously not
> guarantee.
> But how about this, for a fix?

That can't be a fix, only a workaround hiding a potential issue.

Your patch is completely changing the semantic and purpose of the test, which
is basically equivalent to removing the test altogether.

Furthermore, you can't put a delay statement inside
a protected procedure, it's a potentially blocking operation.

Arno

[Bug ada/60078] acats c761007 fails on ARM

[charlet at adacore dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078

--- Comment #10 from charlet at adacore dot com <charlet at adacore dot com> ---
> well, I don't know if the Finalize method are supposed
> to be called in a sequential manner, which GNAT does obviously not
> guarantee.
> But how about this, for a fix?

That can't be a fix, only a workaround hiding a potential issue.

Your patch is completely changing the semantic and purpose of the test, which
is basically equivalent to removing the test altogether.

Furthermore, you can't put a delay statement inside
a protected procedure, it's a potentially blocking operation.

Arno

[Bug ada/60078] acats c761007 fails on ARM

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078

--- Comment #11 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to charlet@adacore.com from comment #10)
> > well, I don't know if the Finalize method are supposed
> > to be called in a sequential manner, which GNAT does obviously not
> > guarantee.
> > But how about this, for a fix?
> 
> That can't be a fix, only a workaround hiding a potential issue.
> 
> Your patch is completely changing the semantic and purpose of the test, which
> is basically equivalent to removing the test altogether.
> 
> Furthermore, you can't put a delay statement inside
> a protected procedure, it's a potentially blocking operation.
> 
> Arno

Hmm, thanks.

of course the delay was only meant to bring it to the point.

And it generates a warning when it is in a protected block, I know.

The point is, even with a short delay here the test should pass,
right?

What is the test supposed to do?

could you explain, why the test fails when the delay is added to the
unmodified test case?

Re: [Bug ada/60078] acats c761007 fails on ARM

[Arnaud Charlet]

> What is the test supposed to do?

Looks at the top of c761007.a, you'll find answers to this question.

> could you explain, why the test fails when the delay is added to the
> unmodified test case?

Sorry, I'm not following you here, I do not know which delay you would
add where (and why).

Arno

[Bug ada/60078] acats c761007 fails on ARM

[charlet at adacore dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078

--- Comment #12 from charlet at adacore dot com <charlet at adacore dot com> ---
> What is the test supposed to do?

Looks at the top of c761007.a, you'll find answers to this question.

> could you explain, why the test fails when the delay is added to the
> unmodified test case?

Sorry, I'm not following you here, I do not know which delay you would
add where (and why).

Arno

[Bug ada/60078] acats c761007 fails on ARM

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078

--- Comment #13 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to charlet@adacore.com from comment #12)
> > could you explain, why the test fails when the delay is added to the
> > unmodified test case?
> 
> Sorry, I'm not following you here, I do not know which delay you would
> add where (and why).
> 
> Arno

I am here, because this test seems to fail on a Dual-Core ARM
running Linux version 3.7.0.

What it looks like for me, is this is executed on two cores in parallel:

   -- look to see if this character has been finalized yet
    for SEI in 1..Side_Effect_Finger loop
      Previous_Side_Effect := Previous_Side_Effect
                              or Side_Effect(Side_Effect_Finger) = I.Effect;
    end loop;

    -- if not, then tack it on to the string, and touch the character
    if not Previous_Side_Effect then
      Side_Effect_Finger := Side_Effect_Finger +1;
      Side_Effect(Side_Effect_Finger) := I.Effect;
      TCTouch.Touch(I.Effect);
    end if;

and both try to add "G" to Side_Effect. Both execute the for loop,
and both don't see each other, thus Previous_Side_Effect := False.
Then both enter the if statement, and end up with GGHIJ => test FAILED.

To make it reproducible, I added a delay 0.01 between for and if statement
and this made the test fail every time, even on X86_64.

If the test is OK as it is, then it is probably the responsibility
of the runtime to ony execute one Finalize method at the time?

So is it a bug in the Test Case or in the GNAT or on my hardware?


Bernd.

[Bug ada/60078] acats c761007 fails on ARM

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078

--- Comment #14 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Well,

that happened only once. and the problem did never ever repeat.
But my gut feeling is still that there is a race conditition.

However I have been recently working on TSAN a bit, and I have an
experimental tsan version that I played with.  Initially
it ICE'd on Ada's VIEW_CONVERT_EXPRs, but when I fixed that I got:


gnatmake -g -fsanitize=thread c761007

./c761007 

,.,. C761007 ACATS 2.5 15-01-01 15:29:05
---- C761007 Check that if a finalize procedure invoked by a transfer of
                control or selection of a terminate alternative attempts
                to propagate an exception, the exception is ignored, but
                any other finalizations due to be performed are
                performed.
==================
WARNING: ThreadSanitizer: data race (pid=27044)
  Read of size 4 at 0x000000657764 by thread T5:
    #0 c761007_1__finalize /home/ed/gnu/gcc-test/c761007_1.adb:10
(c761007+0x00000040c749)
    #1 c761007_1__containerDF <null> (c761007+0x00000040bc3b)
    #2 c761007_2__prot_w_fin_objVDF <null> (c761007+0x000000404364)
    #3 c761007__subtest_3__check_atc_operation___finalizer.5515 <null>
(c761007+0x00000040efd2)
    #4 c761007__subtest_3__check_atc_operation.5508 <null>
(c761007+0x00000040f1ec)
    #5 c761007__subtest_3__subtest_3_taskTKB.5506 <null>
(c761007+0x00000040f5de)
    #6 system__tasking__stages__task_wrapper
/home/ed/gnu/gcc-build/gcc/ada/rts/s-tassta.adb:1262 (c761007+0x000000418800)

  Previous write of size 4 at 0x000000657764 by thread T6:
    #0 c761007_1__finalize /home/ed/gnu/gcc-test/c761007_1.adb:17
(c761007+0x00000040c859)
    #1 c761007_1__containerDF <null> (c761007+0x00000040bc3b)
    #2 c761007_2__prot_w_fin_objVDF <null> (c761007+0x000000404364)
    #3 c761007__subtest_3__subtest_3_taskTK__nestingTK___finalizer.5573 <null>
(c761007+0x00000040f854)
    #4 c761007__subtest_3__subtest_3_taskTK__nestingTKB.5565 <null>
(c761007+0x00000040fa2a)
    #5 system__tasking__stages__task_wrapper
/home/ed/gnu/gcc-build/gcc/ada/rts/s-tassta.adb:1262 (c761007+0x000000418800)

  Location is global 'c761007_1__side_effect_finger' of size 4 at
0x000000657764 (c761007+0x000000657764)

  Thread T5 'subtest_3_task' (tid=27050, running) created by main thread at:
    #0 pthread_create
../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:895
(libtsan.so.0+0x0000000272f4)
    #1 system__task_primitives__operations__create_task
/home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:1016 (c761007+0x000000411d72)
    #2 _ada_c761007 /home/ed/gnu/gcc-test/c761007.adb:228
(c761007+0x00000040d551)
    #3 main /home/ed/gnu/gcc-test/b~c761007.adb:331 (c761007+0x0000004042e4)

  Thread T6 'nesting' (tid=27051, running) created by thread T5 at:
    #0 pthread_create
../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:895
(libtsan.so.0+0x0000000272f4)
    #1 system__task_primitives__operations__create_task
/home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:1016 (c761007+0x000000411d72)
    #2 system__tasking__stages__task_wrapper
/home/ed/gnu/gcc-build/gcc/ada/rts/s-tassta.adb:1262 (c761007+0x000000418800)

SUMMARY: ThreadSanitizer: data race /home/ed/gnu/gcc-test/c761007_1.adb:10
c761007_1__finalize
==================
==================
WARNING: ThreadSanitizer: data race (pid=27044)
  Read of size 1 at 0x00000065a343 by thread T5:
    #0 c761007_1__finalize /home/ed/gnu/gcc-test/c761007_1.adb:12
(c761007+0x00000040c7d4)
    #1 c761007_1__containerDF <null> (c761007+0x00000040bc3b)
    #2 c761007_2__prot_w_fin_objVDF <null> (c761007+0x000000404364)
    #3 c761007__subtest_3__check_atc_operation___finalizer.5515 <null>
(c761007+0x00000040efd2)
    #4 c761007__subtest_3__check_atc_operation.5508 <null>
(c761007+0x00000040f1ec)
    #5 c761007__subtest_3__subtest_3_taskTKB.5506 <null>
(c761007+0x00000040f5de)
    #6 system__tasking__stages__task_wrapper
/home/ed/gnu/gcc-build/gcc/ada/rts/s-tassta.adb:1262 (c761007+0x000000418800)

  Previous write of size 1 at 0x00000065a343 by thread T6:
    #0 c761007_1__finalize /home/ed/gnu/gcc-test/c761007_1.adb:18
(c761007+0x00000040c902)
    #1 c761007_1__containerDF <null> (c761007+0x00000040bc3b)
    #2 c761007_2__prot_w_fin_objVDF <null> (c761007+0x000000404364)
    #3 c761007__subtest_3__subtest_3_taskTK__nestingTK___finalizer.5573 <null>
(c761007+0x00000040f854)
    #4 c761007__subtest_3__subtest_3_taskTK__nestingTKB.5565 <null>
(c761007+0x00000040fa2a)
    #5 system__tasking__stages__task_wrapper
/home/ed/gnu/gcc-build/gcc/ada/rts/s-tassta.adb:1262 (c761007+0x000000418800)

  Location is global 'c761007_1__side_effect' of size 80 at 0x00000065a340
(c761007+0x00000065a343)

  Thread T5 'subtest_3_task' (tid=27050, running) created by main thread at:
    #0 pthread_create
../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:895
(libtsan.so.0+0x0000000272f4)
    #1 system__task_primitives__operations__create_task
/home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:1016 (c761007+0x000000411d72)
    #2 _ada_c761007 /home/ed/gnu/gcc-test/c761007.adb:228
(c761007+0x00000040d551)
    #3 main /home/ed/gnu/gcc-test/b~c761007.adb:331 (c761007+0x0000004042e4)

  Thread T6 'nesting' (tid=27051, running) created by thread T5 at:
    #0 pthread_create
../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:895
(libtsan.so.0+0x0000000272f4)
    #1 system__task_primitives__operations__create_task
/home/ed/gnu/gcc-build/gcc/ada/rts/s-taprop.adb:1016 (c761007+0x000000411d72)
    #2 system__tasking__stages__task_wrapper
/home/ed/gnu/gcc-build/gcc/ada/rts/s-tassta.adb:1262 (c761007+0x000000418800)

SUMMARY: ThreadSanitizer: data race /home/ed/gnu/gcc-test/c761007_1.adb:12
c761007_1__finalize
==================
==== C761007 PASSED ============================.
ThreadSanitizer: reported 2 warnings

[Bug ada/60078] acats c761007 fails on ARM

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078

--- Comment #15 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> that happened only once. and the problem did never ever repeat.
> But my gut feeling is still that there is a race conditition.

Yes, I agree that the usage of Side_Effect_Finger looks suspicious here.

> However I have been recently working on TSAN a bit, and I have an
> experimental tsan version that I played with.  Initially
> it ICE'd on Ada's VIEW_CONVERT_EXPRs, but when I fixed that I got:

"data races" (unprotected concurrent accesses) are allowed in Ada if the object
is declared as atomic, in which case GNAT generates synchronization directives.