On 11/08/15 09:41, Suzuki K. Poulose wrote:
> The REVIDR has to be used in conjunction with the MIDR to make real sense.
Sure, of course.
> We cannot guarantee that the REVIDR that we read (would) belong to the CPU
> where MIDR would have been read (unless the process is pinned) and hence the
> u
On 08/10/2015 06:36 PM, Suzuki K. Poulose wrote:
> On 10/08/15 17:06, Catalin Marinas wrote:
>> Hi Suzuki,
>>
>> On Fri, Jul 24, 2015 at 10:43:47AM +0100, Suzuki K. Poulose wrote:
>>> From: "Suzuki K. Poulose"
>>>
>>> Documentation of the infrastructure
>>>
>>> Signed-off-by: Suzuki K. Poulose
>>
On 05/20/2015 04:46 PM, Will Deacon wrote:
> I'm not sure... you'd require the compiler to perform static analysis of
> loops to determine the state of the machine when they exit (if they exit!)
> in order to show whether or not a dependency is carried to subsequent
> operations. If it can't prove
Linus Torvalds writes:
>
>
> On Sun, 4 Nov 2007, Bart Van Assche wrote:
> >
> > Has it already been decided who will do this audit, and when this
> > audit will happen ? Has a target date been set when this audit
> > should be complete, or is the completion of this audit a
> > requiremen
Bart Van Assche writes:
> On 10/30/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
> > David Schwartz writes:
> > >
> > > Can we get some kind of consensus that 'optimizations' that add
> > > writes to any object that the programmer might
David Schwartz writes:
>
> > Well, yeah. I know what you mean. However, at this moment, some
> > gcc developers are trying really hard not to be total d*ckheads
> > about this issue, but get gcc fixed. Give us a chance.
>
> Can we get some kind of consensus that 'optimizations' that add
Bart Van Assche writes:
> Andrew, do you know whether gcc currently contains any optimization
> that interchanges the order of accesses to non-volatile variables
> and function calls ?
It sure does.
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4
Linus Torvalds writes:
> So my basic worry about gcc is in fact none of the individual
> technical problems themselves - those can be fixed. No, the problem
> I've seen in gcc is that _some_ of the developers seem to be total
> d*ckheads when it comes to "language definition", and seem to thi
[ I had to resend this message. Sorry if you received two copies. ]
Nick Piggin writes:
> Can you retain cc list, please?
>
> On Friday 26 October 2007 07:42, David Schwartz wrote:
> >I asked a collection of knowledgeable people I know about the
> > issue. The consensus is that the opt
Nick Piggin writes:
> Can you retain cc list, please?
>
> On Friday 26 October 2007 07:42, David Schwartz wrote:
> >I asked a collection of knowledgeable people I know about the
> > issue. The consensus is that the optimization is not permitted in
> > POSIX code but that it is permitted
I'm having a little difficulty understanding what this is for. Is it
that gcc's builtin memcpy expander generates bad code, or that older
versions of gcc generate bad code, or what? gcc generates too much
code?
Andrew.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
11 matches
Mail list logo
