On 07/23/2012 08:13 AM, Geert Bosch wrote:
> IIUC, all ports are supposed to implement the atomic built-ins. If they are
> not
> supported in hardware, there should be a library function for it that uses
> locking.
> The problem we're trying to address is builds failing because of undefined
> re
On Jul 23, 2012, at 11:21, Geert Bosch wrote:
> On Jul 23, 2012, at 10:45, Arnaud Charlet wrote:
>> No, as we agreed and discussed, the flag does NOT have to be defined for all
>> versions of system.ads, so this is a bug that needs to be fixed (precisely
>> for the issue raised here: we don't want
> Having a default can't work, as s-atopri.adb needs access to the flag.
> Only the front end itself can use a default, not the run time.
Well, this means the current design is broken and s-atopri.adb needs to
be modified.
As we discussed, we cannot assume that System.Support_Atomic_Primitives
ex
On Jul 23, 2012, at 10:45, Arnaud Charlet wrote:
> No, as we agreed and discussed, the flag does NOT have to be defined for all
> versions of system.ads, so this is a bug that needs to be fixed (precisely
> for the issue raised here: we don't want unknown or new ports to be broken
> by default).
>> FWIW, I checked the build transcript for the failed case:
>>
>> s-atopri.adb:40:10: "Support_Atomic_Primitives" is undefined (more
>> references follow)
>> make[8]: *** [s-atopri.o] Error 1
>>
>> cheers
>> Iain
>
> Just got the same error... investigating
Ah, so the issue is not in the compi
On Jul 23, 2012, at 10:24, Iain Sandoe wrote:
>> This patch implements a check in the runtime library that determines whether
>> the current target supports the atomic primitives up to 64 bits.
>
> If I understand the name of the flag, it looks like an "all or nothing" for
> atomic primitives?
On 07/23/2012 11:03 AM, Iain Sandoe wrote:
On 23 Jul 2012, at 15:57, Arnaud Charlet wrote:
That sounds wrong and isn't how other flags work.
Vincent, can you please double check exactly what's happening, and in particular
verify that a missing flag in system-.ads will NOT cause an error?
Also
On 23 Jul 2012, at 15:57, Arnaud Charlet wrote:
>> The swicth is defaulted to be False in Targparm.
>> However, as far as I understood in Targparm, the switch must be present in
>> all system.ads packages but I may be wrong.
>
> That sounds wrong and isn't how other flags work.
>
> Vincent, can
> The swicth is defaulted to be False in Targparm.
> However, as far as I understood in Targparm, the switch must be present in
> all system.ads packages but I may be wrong.
That sounds wrong and isn't how other flags work.
Vincent, can you please double check exactly what's happening, and in par
On 07/23/2012 10:43 AM, Arnaud Charlet wrote:
With the following, bootstrap completed on powerpc-apple-darwin9,
and
make check-ada shows no new fails.
Should I apply it?
Looks good to me, go ahead, although I'm a bit surprised that you got an
error,
can you clarify what error you got?
IIRC, tha
> >> Looks good to me, go ahead, although I'm a bit surprised that you got an
> >> error,
> >> can you clarify what error you got?
> >
> > IIRC, that the flag was undefined.
> > If it's important I can revert the fix in my local tree and re-build.
> > Iaim
> No need to do that. Indeed, the flag
> >> With the following, bootstrap completed on powerpc-apple-darwin9,
> >> and
> >> make check-ada shows no new fails.
> >> Should I apply it?
> >
> > Looks good to me, go ahead, although I'm a bit surprised that you got an
> > error,
> > can you clarify what error you got?
>
> IIRC, that the fl
On Jul 23, 2012, at 10:32, Iain Sandoe wrote:
>> Looks good to me, go ahead, although I'm a bit surprised that you got an
>> error,
>> can you clarify what error you got?
>
> IIRC, that the flag was undefined.
> If it's important I can revert the fix in my local tree and re-build.
> Iaim
No n
On 23 Jul 2012, at 15:27, Arnaud Charlet wrote:
>> With the following, bootstrap completed on powerpc-apple-darwin9, and
>> make check-ada shows no new fails.
>> Should I apply it?
>
> Looks good to me, go ahead, although I'm a bit surprised that you got an
> error,
> can you clarify what error
> > This patch implements a check in the runtime library that determines
> > whether
> > the current target supports the atomic primitives up to 64 bits.
>
> If I understand the name of the flag, it looks like an "all or nothing" for
> atomic primitives?
Right.
> is that a consequence of the lan
Hi Arnaud,
On 23 Jul 2012, at 09:02, Arnaud Charlet wrote:
> This patch implements a check in the runtime library that determines whether
> the current target supports the atomic primitives up to 64 bits.
If I understand the name of the flag, it looks like an "all or nothing" for
atomic primiti
> Hi Arnaud,
You removed Vincent who is the author of this patch, included here.
>> --- s-atopri.adb (revision 189768)
>> +++ s-atopri.adb (working copy)
>> @@ -31,6 +31,58 @@
>>
>> package body System.Atomic_Primitives is
>>
>> + --
>> + -- Lock_Free_Read_8 --
Hi Arnaud,
--- s-atopri.adb(revision 189768)
+++ s-atopri.adb(working copy)
@@ -31,6 +31,58 @@
package body System.Atomic_Primitives is
+ --
+ -- Lock_Free_Read_8 --
+ --
...
+ --
+ -- Lock_Free_Read_16
18 matches
Mail list logo
