https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #15 from Eric Botcazou ---
> 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.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #14 from Bernd Edlinger ---
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
experi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #13 from Bernd Edlinger ---
(In reply to char...@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 whi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #12 from 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
> 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #11 from Bernd Edlinger ---
(In reply to char...@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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #10 from 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, o
> 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 o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #9 from Bernd Edlinger ---
Created attachment 32065
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32065&action=edit
possible fix
well, I don't know if the Finalize method are supposed
to be called in a sequential manner, which G
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #8 from Bernd Edlinger ---
(In reply to Eric Botcazou from comment #7)
> > 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.
I added the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #7 from Eric Botcazou ---
> 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #6 from Bernd Edlinger ---
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
-- -- -- -- -- -- -- -- -- -- -- -- --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #5 from Mikael Pettersson ---
(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?
Si
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Eric Botcazou --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #3 from Mikael Pettersson ---
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
--- Comment #2 from Bernd Edlinger ---
it's a real hardware (Altera CyloneV SoC Eva-Board)
with dual core ARMv7
running linux and eglibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
17 matches
Mail list logo