Could you please fix up whitespace in the patch, at least leading tabs
and trailing whitespace?
On the patch it is easy to do, something like:
sed 's/^+\([\t]*\) \{64\}/+\1\t\t\t\t\t\t\t\t/;s/^+\([\t]*\)
\{32\}/+\1\t\t\t\t/;s/^+\([\t]*\) \{16\}/+\1\t\t/;s/^+\([\t]*\)
\{8\}/+\1\t/;s/^+\(.*[^[:b
On Thu, 3 Nov 2011, Aldy Hernandez wrote:
> What I'd like to know is why I am constantly being asked for more stuff on the
> transactional memory branch, whereas the memory model stuff got approved
> without even asking for a complete diff (and I know what I'm being asked for,
> cause I'm doing bo
We want to look at proper patch submissions not at websites that change
from time to time. I really don't know what you take issue with, or where
the difficulty is. patch submission via gcc-patches@ is a requirement
since forever, not something arbitrarily imposed on specifically you to
annoy
Hi,
On Thu, 3 Nov 2011, Aldy Hernandez wrote:
> What Richi is complaining about is something that got fixed yesterday
> and is no longer in the branch, and can easily be fixed by hitting
> reload on his browser.
We want to look at proper patch submissions not at websites that change
from time
Hi,
On Thu, 3 Nov 2011, Aldy Hernandez wrote:
> > re-generates gcc/c-opts.c which was moved to gcc/c-family. I suppose
> > sth was screwed up during some trunk->branch merge. Please review the
> > patches yourself and look for these issues and fix them.
>
> Again, can you please hit reload o
Aldy, what folks are asking for is reasonably contained patches from
the branch that can be reviewed. Ideally they could be installed
independently, but it's not strictly necessary.
I already did so:
compiler/
libitm/
libstdc++-v3/
misc/
toplevel/
The ChangeLog's are at the top. The testsu
> Again, can you please hit reload on your browser?
I have it too.
--
Eric Botcazou
Hi,
On Thu, 3 Nov 2011, Aldy Hernandez wrote:
> Have you not seen the last 3 years of patches to gcc-patches? They're
> prefixed by [trans-mem]. Perhaps you're filtering them out.
That's not how things are supposed to be, sorry. The private branches
don't require reviews, and hence also won
Index: gcc/c-opts.c
===
--- gcc/c-opts.c(.../trunk) (revision 0)
+++ gcc/c-opts.c(.../branches/transactional-memory) (revision
180773)
@@ -0,0 +1,1773 @@
+/* C/ObjC/C++ command line option handling.
+ Copy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/03/11 10:14, Richard Guenther wrote:
>
> Reviewable branch merge patch(es). You can't expect everyone to
> follow all development branches that may or may not end up being
> merged.
Precisely.
Aldy, what folks are asking for is reasonably co
On Thu, Nov 3, 2011 at 5:16 PM, Aldy Hernandez wrote:
>
>>> Reviewable patches as in what goes in gcc-patches? Or do you want
>>> something
>>> else?
>>
>> Reviewable branch merge patch(es). You can't expect everyone to
>> follow all development branches that may or may not end up being merged.
Reviewable patches as in what goes in gcc-patches? Or do you want something
else?
Reviewable branch merge patch(es). You can't expect everyone to
follow all development branches that may or may not end up being merged.
Is what I posted not in a way that can be reviewed? Did you download
On Thu, Nov 3, 2011 at 5:09 PM, Aldy Hernandez wrote:
>
>> Have you ever posted the patch, or only made it available via the website?
>
> Have you not seen the last 3 years of patches to gcc-patches? They're
> prefixed by [trans-mem]. Perhaps you're filtering them out.
>
>> Just scanning
>> http
Have you ever posted the patch, or only made it available via the website?
Have you not seen the last 3 years of patches to gcc-patches? They're
prefixed by [trans-mem]. Perhaps you're filtering them out.
Just scanning
http://quesejoda.com/redhat/tm-branch-diffs-from-trunk-at-180744/comp
Hi,
On Thu, 3 Nov 2011, Aldy Hernandez wrote:
> > We don't want to do such large changes on the trunk and really the
> > amount of whitespace issues in the patch is huge. The script changes
> > only leading and trailing whitespace, so it shouldn't make any
> > difference to code generation, an
Could you please fix up whitespace in the patch, at least leading tabs
and trailing whitespace?
On the patch it is easy to do, something like:
sed 's/^+\([\t]*\) \{64\}/+\1\t\t\t\t\t\t\t\t/;s/^+\([\t]*\)
\{32\}/+\1\t\t\t\t/;s/^+\([\t]*\) \{16\}/+\1\t\t/;s/^+\([\t]*\)
\{8\}/+\1\t/;s/^+\(.*[^[:b
Is this necessary for the entire patch, or just the parts that touch
existing parts of the toolchain. For example, do you want me to run
this on libitm/, etc? I'm really trying to minimize changes (even
whitespace stuff) at the last minute, but if you think it's
imperative, I will do so.
Wel
On Thu, Nov 03, 2011 at 09:05:49AM -0500, Aldy Hernandez wrote:
> >Could you please fix up whitespace in the patch, at least leading tabs
> >and trailing whitespace?
> >On the patch it is easy to do, something like:
> >sed 's/^+\([\t]*\) \{64\}/+\1\t\t\t\t\t\t\t\t/;s/^+\([\t]*\)
> >\{32\}/+\1\t\t\
On Wed, Nov 02, 2011 at 12:05:43PM -0500, Aldy Hernandez wrote:
>
> >I remember at least seeing middle-end pieces in alias analysis.
>
> Yes, but they're mechanical changes. Do you mean these?:
>
> @@ -1182,6 +1182,8 @@ ref_maybe_used_by_call_p_1 (gimple call,
> case BUILT_IN_MEMPCPY:
>
I remember at least seeing middle-end pieces in alias analysis.
Yes, but they're mechanical changes. Do you mean these?:
@@ -1182,6 +1182,8 @@ ref_maybe_used_by_call_p_1 (gimple call,
case BUILT_IN_MEMPCPY:
case BUILT_IN_STPCPY:
case BUILT_IN_STPNCPY:
+case BU
I'd like to see some breakdown into subsystem patches. Can someone provide
those together with changelog entries?
I am doing another merge from trunk->branch, and will post a series of
patches by subsystem. I will do so after the merge is complete and tested.
On Tue, Nov 1, 2011 at 5:59 PM, David Edelsohn wrote:
> On Tue, Nov 1, 2011 at 5:49 AM, Richard Guenther
> wrote:
>
>> Given that you only recently merged with trunk again are you really
>> sure this is a great
>> idea at this point in time? Does the GCC 4.7 user community benefit from
>> this
Have you looked at those diffs, there's a fair amount of unrelated
Will clean up.
crud in there... It might help to break the blob into more easily
understood hunks for actual submissions. ie, runtime bits (libitm),
changes to existing runtime stuff, compiler proper, testsuite bits, etc.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/01/11 12:44, Aldy Hernandez wrote:
>
>> Aldy, Richard, is there a patchset or master patch I could read?
>
> I have made current diff as of today:
>
> http://quesejoda.com/tm-branch-latest.bz2
Umm,
Have you looked at those diffs, there's a f
On 11-11-01 14:44 , Aldy Hernandez wrote:
Aldy, Richard, is there a patchset or master patch I could read?
I have made current diff as of today:
http://quesejoda.com/tm-branch-latest.bz2
Thanks.
Diego.
Aldy, Richard, is there a patchset or master patch I could read?
I have made current diff as of today:
http://quesejoda.com/tm-branch-latest.bz2
Richard who? There are two Richards in this thread, and they seem to
have opposing views.
I am confused by the multiple levels of quotes I think (the feature
in mailers of easily allowing you to include an entire earlier thread
is evil! :-)
Anyway, I support merging this in ...
Diego.
On Tue, Nov 1, 2011 at 17:19, Robert Dewar wrote:
> On 11/1/2011 12:59 PM, David Edelsohn wrote:
>>
>> On Tue, Nov 1, 2011 at 5:49 AM, Richard Guenther
>> wrote:
>>
>>> Given that you only recently merged with trunk again are you really
>>> sure this is a great
>>> idea at this point in time? D
On 11/1/2011 12:59 PM, David Edelsohn wrote:
On Tue, Nov 1, 2011 at 5:49 AM, Richard Guenther
wrote:
Given that you only recently merged with trunk again are you really
sure this is a great
idea at this point in time? Does the GCC 4.7 user community benefit from this
in any way (or rather ho
On Tue, Nov 1, 2011 at 5:49 AM, Richard Guenther
wrote:
> Given that you only recently merged with trunk again are you really
> sure this is a great
> idea at this point in time? Does the GCC 4.7 user community benefit from this
> in any way (or rather how much percentage of it)?
GCC has a hist
On 11-11-01 11:23 , Jeff Law wrote:
This stuff is fairly isolated in terms of what it touches and I'm sure
if anything goes wrong, Aldy, Richard& Torvald will be available to
fix it.
The request to merge came in before the end of stage1, I don't see a
reason to delay things another 6-9 months.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/01/11 03:49, Richard Guenther wrote:
>
> Given that you only recently merged with trunk again are you
> really sure this is a great idea at this point in time? Does the
> GCC 4.7 user community benefit from this in any way (or rather how
> muc
On 11/01/2011 01:52 PM, Torvald Riegel wrote:
> Yes, we think so. Transactional Memory (TM) is a very easy-to-use
> synchronization mechanism, which does not burden the programmer with
> having to consider issues such as deadlocks or having to rely on
> conventions regarding which locks cover which
On Tue, 2011-11-01 at 10:49 +0100, Richard Guenther wrote:
> On Mon, Oct 31, 2011 at 11:33 PM, Aldy Hernandez wrote:
> > This is somewhat of a me-too message for the transactional-memory work. We
> > would also like it to be considered for merging with mainline before the end
> > of stage1.
[sni
On Mon, Oct 31, 2011 at 11:33 PM, Aldy Hernandez wrote:
> This is somewhat of a me-too message for the transactional-memory work. We
> would also like it to be considered for merging with mainline before the end
> of stage1.
>
> We have a kept a wiki here:
>
> http://gcc.gnu.org/wiki/Transactiona
This is somewhat of a me-too message for the transactional-memory work.
We would also like it to be considered for merging with mainline
before the end of stage1.
We have a kept a wiki here:
http://gcc.gnu.org/wiki/TransactionalMemory
What it is
==
From the wiki...
Transactional me
36 matches
Mail list logo
