On Wed, Feb 19, 2014 at 08:43:14PM -0800, Linus Torvalds wrote:
> On Wed, Feb 19, 2014 at 8:01 PM, Paul E. McKenney
> wrote:
> >
> > The control dependency should order subsequent stores, at least assuming
> > that "a" and "b" don't start off with identical stores that the compiler
> > could pull
On Thu, Feb 20, 2014 at 12:30:32AM -0800, Paul E. McKenney wrote:
> On Wed, Feb 19, 2014 at 08:43:14PM -0800, Linus Torvalds wrote:
[ . . . ]
> So, if you make one of two changes to your example, then I will agree
> with you. The first change is to have a real data dependency between
> the read
On Thu, Feb 20, 2014 at 2:16 AM, Jonathan Wakely wrote:
> On 13 February 2014 20:47, Patrick Palka wrote:
>> On a related note, would a patch to officially enable
>> -Wmissing-declarations in the build process be well regarded?
>
> What would be the advantage?
A missing declaration for an extern
On Wed, Feb 19, 2014 at 11:19 PM, Andrew Pinski wrote:
> On Wed, Feb 19, 2014 at 3:17 PM, Renato Golin wrote:
>> On 19 February 2014 11:58, Richard Sandiford
>> wrote:
>>> I agree that having an unrecognised asm shouldn't be a hard error until
>>> assembly time though. Saleem, is the problem th
On 20 February 2014 10:11, Ramana Radhakrishnan
wrote:
> The current behaviour is that when the compiler generates code for
> Thumb1 and Thumb2 we switch back to the appropriate state after inline
> assembler is emitted. We don't switch back to ARM state on the (fairly
> robust) assumption that mo
On Wed, 19 Feb 2014, Jan Hubicka wrote:
> > On Tue, 18 Feb 2014, Jan Hubicka wrote:
> >
> > > > > Non-ODR types born from other frontends will then need to be made to
> > > > > alias all the ODR variants that can be done by storing them into the
> > > > > current canonical type hash.
> > > > >
On 19/02/14 23:19, Andrew Pinski wrote:
> On Wed, Feb 19, 2014 at 3:17 PM, Renato Golin wrote:
>> On 19 February 2014 11:58, Richard Sandiford
>> wrote:
>>> I agree that having an unrecognised asm shouldn't be a hard error until
>>> assembly time though. Saleem, is the problem that this is being
Hi,
I am using sets of stl in gcc. I need to perform operations like set
union, set intersection and set difference for my analysis. These
functions are defined in the header . However, when I include
this header in my file, I get the following error:
/home/pritam/GCC_BUILDS/gcc_4.7/insta
On Thu, 20 Feb 2014, Pritam Gharat wrote:
I am using sets of stl in gcc. I need to perform operations like set
union, set intersection and set difference for my analysis. These functions
are defined in the header . However, when I include this header in
my file, I get the following error:
On 20 February 2014 10:02, Patrick Palka wrote:
> On Thu, Feb 20, 2014 at 2:16 AM, Jonathan Wakely
> wrote:
>> On 13 February 2014 20:47, Patrick Palka wrote:
>>> On a related note, would a patch to officially enable
>>> -Wmissing-declarations in the build process be well regarded?
>>
>> What wo
It worked. Thank You :-)
On Thursday 20 February 2014 06:03 PM, Marc Glisse wrote:
On Thu, 20 Feb 2014, Pritam Gharat wrote:
I am using sets of stl in gcc. I need to perform operations like
set union, set intersection and set difference for my analysis. These
functions are defined in the h
On Wed, Feb 19, 2014 at 11:26 PM, Renato Golin wrote:
> On 19 February 2014 23:19, Andrew Pinski wrote:
>> With the unified assembly format, you should not need those
>> .arm/.thumb and in fact emitting them can make things even worse.
>
> If only we could get rid or all pre-UAL inline assembly o
On 20 February 2014 12:59, Ramana Radhakrishnan
wrote:
> It's not really because GAS supports it, but there exists a large body
> of code out there which uses inline assembler with pre-UAL syntax. I'm
> not sure people will appreciate a blanket break in one version of the
> toolchain and especiall
On Thu, Feb 20, 2014 at 7:42 AM, Jonathan Wakely wrote:
> On 20 February 2014 10:02, Patrick Palka wrote:
>> On Thu, Feb 20, 2014 at 2:16 AM, Jonathan Wakely
>> wrote:
>>> On 13 February 2014 20:47, Patrick Palka wrote:
On a related note, would a patch to officially enable
-Wmissing-d
Hi,
I've uploaded a prebuilt arm cross compiler for Linux x86_64, built on
Debian Jessie, should work fine, crosses fingers :D
https://www.dropbox.com/s/273e1pbez0qgqkp/tinyada-arm-none-eabi-4.9.0-20140122.tbz
Thanks,
Luke.
On Thu, Feb 20, 2014 at 12:30 AM, Paul E. McKenney
wrote:
>>
>> So lets make this really simple: if you have a consume->cmp->read, is
>> the ordering of the two reads guaranteed?
>
> Not as far as I know. Also, as far as I know, there is no difference
> between consume and relaxed in the consume-
On Wed, 2014-02-19 at 16:53 -0800, Linus Torvalds wrote:
> On Tue, Feb 18, 2014 at 11:47 AM, Torvald Riegel wrote:
> > On Tue, 2014-02-18 at 09:44 -0800, Linus Torvalds wrote:
> >>
> >> Can you point to it? Because I can find a draft standard, and it sure
> >> as hell does *not* contain any clarit
On Wed, 2014-02-19 at 20:01 -0800, Paul E. McKenney wrote:
> On Wed, Feb 19, 2014 at 04:53:49PM -0800, Linus Torvalds wrote:
> > On Tue, Feb 18, 2014 at 11:47 AM, Torvald Riegel wrote:
> > > On Tue, 2014-02-18 at 09:44 -0800, Linus Torvalds wrote:
> > >>
> > >> Can you point to it? Because I can f
On Thu, Feb 20, 2014 at 9:14 AM, Torvald Riegel wrote:
>>
>> So the clarification is basically to the statement that the "if
>> (consume(p)) a" version *would* have an ordering guarantee between the
>> read of "p" and "a", but the "consume(p) ? a : b" would *not* have
>> such an ordering guarantee
On Wed, 2014-02-19 at 20:43 -0800, Linus Torvalds wrote:
[Paul has already answered many of your questions, and my reply to your
previous email should also answer some.]
> If the consumer of an atomic load isn't a pointer chasing operation,
> then the consume should be defined to be the same as a
On Thu, 2014-02-20 at 00:30 -0800, Paul E. McKenney wrote:
> Well, all the compilers currently convert consume to acquire, so you have
> your wish there. Of course, that also means that they generate actual
> unneeded memory-barrier instructions, which seems extremely sub-optimal
> to me.
GCC doe
Patrick Palka writes:
>> Maybe others will disagree and will think enabling
>> -Wmissing-declarations would be a useful change, but I don't see the
>> point.
>
> In my novice opinion, I think the flag helps keep source files tidy
> and modular, and their interfaces well-defined. Its biggest benef
On Thu, Feb 20, 2014 at 09:01:06AM -0800, Linus Torvalds wrote:
> On Thu, Feb 20, 2014 at 12:30 AM, Paul E. McKenney
> wrote:
> >>
> >> So lets make this really simple: if you have a consume->cmp->read, is
> >> the ordering of the two reads guaranteed?
> >
> > Not as far as I know. Also, as far a
On Thu, 2014-02-20 at 09:34 -0800, Linus Torvalds wrote:
> On Thu, Feb 20, 2014 at 9:14 AM, Torvald Riegel wrote:
> >>
> >> So the clarification is basically to the statement that the "if
> >> (consume(p)) a" version *would* have an ordering guarantee between the
> >> read of "p" and "a", but the
On 20 February 2014 15:31, Patrick Palka wrote:
> (I counted nearly 100 (non-debug)
> functions that could be made static in gcc, and 4 in libstdc++, by the
> way.)
Which were the four in libstdc++?
I only see __gslice_on_index and __concat_size_t.
On Thu, Feb 20, 2014 at 1:14 PM, Jonathan Wakely wrote:
> On 20 February 2014 15:31, Patrick Palka wrote:
>> (I counted nearly 100 (non-debug)
>> functions that could be made static in gcc, and 4 in libstdc++, by the
>> way.)
>
> Which were the four in libstdc++?
>
> I only see __gslice_on_index a
On Thu, Feb 20, 2014 at 06:26:08PM +0100, Torvald Riegel wrote:
> xagsmtp2.20140220172700.0...@vmsdvm4.vnet.ibm.com
> X-Xagent-Gateway: vmsdvm4.vnet.ibm.com (XAGSMTP2 at VMSDVM4)
>
> On Wed, 2014-02-19 at 20:01 -0800, Paul E. McKenney wrote:
> > On Wed, Feb 19, 2014 at 04:53:49PM -0800, Linus Torv
On 20 February 2014 18:16, Patrick Palka wrote:
> On Thu, Feb 20, 2014 at 1:14 PM, Jonathan Wakely
> wrote:
>> On 20 February 2014 15:31, Patrick Palka wrote:
>>> (I counted nearly 100 (non-debug)
>>> functions that could be made static in gcc, and 4 in libstdc++, by the
>>> way.)
>>
>> Which wer
On Thu, Feb 20, 2014 at 06:54:06PM +0100, Torvald Riegel wrote:
> xagsmtp4.20140220175519.1...@vmsdvm6.vnet.ibm.com
> X-Xagent-Gateway: vmsdvm6.vnet.ibm.com (XAGSMTP4 at VMSDVM6)
>
> On Thu, 2014-02-20 at 00:30 -0800, Paul E. McKenney wrote:
> > Well, all the compilers currently convert consume to
On Thu, 2014-02-20 at 09:01 -0800, Linus Torvalds wrote:
> On Thu, Feb 20, 2014 at 12:30 AM, Paul E. McKenney
> wrote:
> >>
> >> So lets make this really simple: if you have a consume->cmp->read, is
> >> the ordering of the two reads guaranteed?
> >
> > Not as far as I know. Also, as far as I kno
On Thu, Feb 20, 2014 at 9:49 AM, Torvald Riegel wrote:
>
> Yes, mo_consume is more tricky than mo_acquire.
>
> However, that has an advantage because you can avoid getting stronger
> barriers if you don't need them (ie, you can avoid the "auto-update to
> acquire" you seem to have in mind).
Oh, I
On Thu, Feb 20, 2014 at 09:34:57AM -0800, Linus Torvalds wrote:
> On Thu, Feb 20, 2014 at 9:14 AM, Torvald Riegel wrote:
> >>
> >> So the clarification is basically to the statement that the "if
> >> (consume(p)) a" version *would* have an ordering guarantee between the
> >> read of "p" and "a", b
On Thu, Feb 20, 2014 at 10:11 AM, Paul E. McKenney
wrote:
>
> You really need that "consume" to be "acquire".
So I think we now all agree that that is what the standard is saying.
And I'm saying that that is wrong, that the standard is badly written,
and should be fixed.
Because before the stan
On Thu, 2014-02-20 at 10:11 -0800, Paul E. McKenney wrote:
> But yes, the compiler guys would be extremely happy to simply drop
> memory_order_consume from the standard, as it is the memory order
> that they most love to hate.
>
> Getting them to agree to any sort of peep-hole optimization semanti
On Thu, 2014-02-20 at 10:32 -0800, Linus Torvalds wrote:
> On Thu, Feb 20, 2014 at 10:11 AM, Paul E. McKenney
> wrote:
> >
> > You really need that "consume" to be "acquire".
>
> So I think we now all agree that that is what the standard is saying.
Huh?
The standard says that there are two sep
On Thu, Feb 20, 2014 at 10:32:51AM -0800, Linus Torvalds wrote:
> On Thu, Feb 20, 2014 at 10:11 AM, Paul E. McKenney
> wrote:
> >
> > You really need that "consume" to be "acquire".
>
> So I think we now all agree that that is what the standard is saying.
>
> And I'm saying that that is wrong, t
On Thu, Feb 20, 2014 at 07:44:32PM +0100, Torvald Riegel wrote:
> xagsmtp3.20140220184514.1...@bldgate.vnet.ibm.com
> X-Xagent-Gateway: bldgate.vnet.ibm.com (XAGSMTP3 at BLDGATE)
>
> On Thu, 2014-02-20 at 10:11 -0800, Paul E. McKenney wrote:
> > But yes, the compiler guys would be extremely happy
On Thu, Feb 20, 2014 at 10:25 AM, Linus Torvalds
wrote:
>
> While in my *sane* model, where you can consume things even if they
> then result in control dependencies, there will still eventually be a
> "sync" instruction on powerpc (because you really need one between the
> load of 'initialized' a
On Thu, Feb 20, 2014 at 11:02 AM, Linus Torvalds
wrote:
>
> Again, the way I'd expect a compiler writer to actually *do* this is
> to just default to "ac
Oops, pressed send by mistake too early.
I was almost done:
I'd expect a compiler to just default to "acquire" semantics, but then
have a few
On Thu, Feb 20, 2014 at 10:53 AM, Torvald Riegel wrote:
> On Thu, 2014-02-20 at 10:32 -0800, Linus Torvalds wrote:
>> On Thu, Feb 20, 2014 at 10:11 AM, Paul E. McKenney
>> wrote:
>> >
>> > You really need that "consume" to be "acquire".
>>
>> So I think we now all agree that that is what the stan
On Thu, Feb 20, 2014 at 10:56 AM, Paul E. McKenney
wrote:
>
> The example gcc breakage was something like this:
>
> i = atomic_load(idx, memory_order_consume);
> x = array[0 + i - i];
>
> Then gcc optimized this to:
>
> i = atomic_load(idx, memory_order_consume);
>
On 02/15/2014 05:09 AM, Richard Biener wrote:
On Sat, 15 Feb 2014, Jan Hubicka wrote:
The code really seems to be adding only cases of zero sized classes.
zero-size as in with no fields? Then we can't do anything with such
classes and thus we don't need to record component aliases?
Right.
On 02/17/2014 03:55 PM, Jan Hubicka wrote:
I also think we want explicit representation of types known to be local to
compilation
unit - anonymous namespaces in C/C++, types defined within function bodies in C
and
god knows what in Ada/Fortran/Java.
In the C++ front end we set TREE_PUBLIC app
On Thu, Feb 20, 2014 at 11:45:29AM -0800, Linus Torvalds wrote:
> On Thu, Feb 20, 2014 at 10:56 AM, Paul E. McKenney
> wrote:
> >
> > The example gcc breakage was something like this:
> >
> > i = atomic_load(idx, memory_order_consume);
> > x = array[0 + i - i];
> >
> > Then gcc opt
Snapshot gcc-4.8-20140220 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140220/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, Feb 20, 2014 at 2:10 PM, Paul E. McKenney
wrote:
>
> Linus, given that you are calling me out for pushing "legalistic and bad"
> things, "syntactic bullshit", and playing "little games", I am forced
> to conclude that you have never attended any sort of standards-committee
> meeting. ;-)
46 matches
Mail list logo
