On 04/06/11 10:29, Michael Matz wrote:
Hi,
On Mon, 4 Apr 2011, Aldy Hernandez wrote:
(5) Do we agree that all such cpus use a byte-granular modification mask?
Now, as of (0) I might agree to disregard the original Alpha, but as the
embedded world moves to SMP I'm not sure we can disregard
Hi,
On Mon, 4 Apr 2011, Aldy Hernandez wrote:
>
> > > (5) Do we agree that all such cpus use a byte-granular modification mask?
>
> > Now, as of (0) I might agree to disregard the original Alpha, but as the
> > embedded world moves to SMP I'm not sure we can disregard
> > non-cache coherent NUM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 01:56, Richard Guenther wrote:
> But well, I guess the thing I don't like about the standard is that it makes
> people that have started to be somewhat aware about threading issues
> _less_ aware of them by providing some "false" safety to
(5) Do we agree that all such cpus use a byte-granular modification mask?
Now, as of (0) I might agree to disregard the original Alpha, but as the
embedded world moves to SMP I'm not sure we can disregard
non-cache coherent NUMA setups or even CPUs without a byte store.
As per 5, it doesn't
But well, I guess the thing I don't like about the standard is that it makes
people that have started to be somewhat aware about threading issues
_less_ aware of them by providing some "false" safety to them. It
really smells like a standard designed for a very high-level language
where people
On Fri, Apr 1, 2011 at 6:24 PM, Richard Henderson wrote:
> On 03/31/2011 08:28 AM, Richard Guenther wrote:
Well, I'm not sure that strict-align targets that provide byte access do
not simply hide the issue inside the CPU (thus, perform the
read-modify-write
there and do not gu
On Fri, Apr 1, 2011 at 9:24 AM, Richard Henderson wrote:
> (1) Do we agree that all such cpus have user-level store insns with byte
> granularity. Honestly the only non-microcontroler I ever heard of
> without this was the original Alpha. Which is excluded per (0).
And SPU which is exclud
On 03/31/2011 08:28 AM, Richard Guenther wrote:
>>> Well, I'm not sure that strict-align targets that provide byte access do
>>> not simply hide the issue inside the CPU (thus, perform the
>>> read-modify-write
>>> there and do not guarantee any atomicity unless you ask for it).
>> Certainly some
On Thu, Mar 31, 2011 at 4:47 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/30/11 08:19, Richard Guenther wrote:
>
>>
>> Well, I'm not sure that strict-align targets that provide byte access do
>> not simply hide the issue inside the CPU (thus, perform the read-mod
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/30/11 08:19, Richard Guenther wrote:
>
> Well, I'm not sure that strict-align targets that provide byte access do
> not simply hide the issue inside the CPU (thus, perform the read-modify-write
> there and do not guarantee any atomicity unless
On Mar 30, 2011, at 7:40 AM, Richard Guenther wrote:
>> Is forcing word-alignment too big of a hammer, or will the users for these
>> architectures be content with having no support for the C++0x memory model?
>
> I think a memory model that cannot be reasonably (read: also fast) implemented
> on
On Wed, Mar 30, 2011 at 4:26 PM, Aldy Hernandez wrote:
>
>>> So... do you have any important targets in mind, because I don't see this
>>> being a problem for most targets? As can be expected, I am only
>>> interested
>>> in x86*, powerpc*, and s390, especially since a cursory glance on other
>>>
So... do you have any important targets in mind, because I don't see this
being a problem for most targets? As can be expected, I am only interested
in x86*, powerpc*, and s390, especially since a cursory glance on other
important targets didn't exhibit any problems. However, given my target
b
Hi,
On Wed, 30 Mar 2011, Aldy Hernandez wrote:
>
> > The memory model is not implementable on strict-alignment targets
> > that do not have a byte store operation. But we previously said that ;)
>
> Yes. I think we should issue an error when we have such a target and the user
> tries -fmemory
On Wed, Mar 30, 2011 at 4:11 PM, Aldy Hernandez wrote:
>
>> The memory model is not implementable on strict-alignment targets
>> that do not have a byte store operation. But we previously said that ;)
>
> Yes. I think we should issue an error when we have such a target and the
> user tries -fmem
The memory model is not implementable on strict-alignment targets
that do not have a byte store operation. But we previously said that ;)
Yes. I think we should issue an error when we have such a target and
the user tries -fmemory-model=c++0x. However, how many strict-alignment
targets ar
On Tue, Mar 29, 2011 at 7:00 PM, Aldy Hernandez wrote:
> [Language lawyers, please correct me if I have mis-interpreted the upcoming
> standard in any way.]
>
> In the C++ memory model, contiguous bitfields comprise a single memory
> location, so it's fair game to bit twiddle them when setting the
[Language lawyers, please correct me if I have mis-interpreted the
upcoming standard in any way.]
In the C++ memory model, contiguous bitfields comprise a single memory
location, so it's fair game to bit twiddle them when setting them. For
example:
struct {
unsigned
18 matches
Mail list logo
