Hi!
If whitespace is an issue for some of you, why don't you fix this in a generic
way?
1. Identify all modules in which whitespace at the end of a line is a problem.
2. Identify all branches of these modules.
3. Identify all lines with the whitespace problem in all modules and branches.
4. Iden
On Thu, 2009-11-26 at 00:08 +0100, Richard Guenther wrote:
> On Thu, Nov 26, 2009 at 12:04 AM, Tom Tromey wrote:
> >> "Basile" == Basile STARYNKEVITCH writes:
> >
> > Basile> Of course, not every one has it (notably those working on non-linux
> > Basile> systems), but for those who have it,
On Wed, 2009-11-25 at 18:02 +0100, Michael Matz wrote:
> Hi,
>
> On Wed, 25 Nov 2009, Richard Guenther wrote:
>
> > > Remove trailing white spaces.
> > >
> > > WTF?
> > >
> > > Thankyouverymuch.
> > >
> > > This 1) wasn't posted or approved 2) is bad as it breaks svn blame
> > > 3) chokes all
On Wed, 2009-11-25 at 20:38 +0100, Richard Guenther wrote:
> If you can offer advice on how to teach quilt
> (which I belive uses patch) to ignore whitespace changes when
> applying patches then more power to you
QUILT_PATCH_OPTS="-l"
Hi all,
For a loop optimization at our backend (loop-pipelining) I would like to
move all the loop iv increment and loop condition calculation to the head of
a loop. This iv-acceleration should be visible at the final phase of the
compilation before the ASM code generation.
Currently, I did it
On Nov 27, 2009, yunfeng zhang wrote:
> The rsult is also same, you go too far.
If the g in the main program didn't preempt the definition in the
library, then something is amiss in your system.
> Here data in 0x1000 and its follower have an *exact* map to foo.so in
> disk, you need review my c
Richard Earnshaw wrote:
> On Wed, 2009-11-25 at 18:02 +0100, Michael Matz wrote:
>> Hi,
>>
>> On Wed, 25 Nov 2009, Richard Guenther wrote:
>>
Remove trailing white spaces.
WTF?
Thankyouverymuch.
This 1) wasn't posted or approved 2) is bad as it breaks svn blame
>>
Hi,
On Fri, 27 Nov 2009, Dave Korn wrote:
> > PLEASE DO NOT DO THIS.
>
> However I don't think it's going to happen,
Yes, it's probably not going to happen; neither the requested revert.
But now I at least know a strategy how to sneak in controversial patches.
> given that it's been a coup
Michael Matz wrote:
> Hi,
>
> On Fri, 27 Nov 2009, Dave Korn wrote:
>
>>> PLEASE DO NOT DO THIS.
>> However I don't think it's going to happen,
>
> Yes, it's probably not going to happen; neither the requested revert.
> But now I at least know a strategy how to sneak in controversial patches
yunfeng zhang writes:
> Sorry! I've made a mistake! But using LD_PRELOAD to force to reposition a
> variable/function from a module is violating software engineer. And the more
> important is, as the result, all user *all* pay the bill for this even they
> make sure they don't need the feature, s
On 11/27/2009 03:21 PM, Dave Korn wrote:
you and Paolo are pretty much the only
people who feel that it should have been backed out
Uh? I said that the repository should have been made readonly if there
was a concrete possibility of backing out the patch, be it with svn cp
(which we already
Quoting Michael Matz :
Yes, it's probably not going to happen; neither the requested revert.
But now I at least know a strategy how to sneak in controversial patches.
I don't think the patch was controversial in the changes it made to the
code per se, only in the side effects that its check in
Paolo Bonzini wrote:
> On 11/27/2009 03:21 PM, Dave Korn wrote:
>> you and Paolo are pretty much the only
>> people who feel that it should have been backed out
>
> Uh? I said that the repository should have been made readonly if there
> was a concrete possibility of backing out the patch, be it
Quoting Richard Earnshaw :
An SVN pre-commit filter (default on, disabled by SVN attribute if
needed) should instead just reject files that have trailing white space.
I think a better mechanism to deal with exceptions is to have a property
that describes the current misformatting (or unusual fo
On Fri, 2009-11-27 at 09:40 -0500, Joern Rennecke wrote:
> Quoting Richard Earnshaw :
> > An SVN pre-commit filter (default on, disabled by SVN attribute if
> > needed) should instead just reject files that have trailing white space.
>
> I think a better mechanism to deal with exceptions is to ha
On Fri, 27 Nov 2009, Richard Earnshaw wrote:
> On Fri, 2009-11-27 at 09:40 -0500, Joern Rennecke wrote:
> > Quoting Richard Earnshaw :
> > > An SVN pre-commit filter (default on, disabled by SVN attribute if
> > > needed) should instead just reject files that have trailing white space.
> >
> > I
I have received several requests for backporting the plugin
functionality into 4.4. I have now created a copy of gcc-4_4-branch
to backport all the mainline patches.
No new functionality will be accepted in the branch. Only the
functionality we have in mainline. I have committed the following
c
Hello,
In the MELT branch, the cc1 program has (sometimes) to run a C compiler (usually the same gcc in the common case of
host=build=target=linux x86-64) to compile the MELT generated C code (which could be latter dlopen-ed by that cc1). This
means that sometimes, gcc-melt runs cc1 which may r
Joern Rennecke wrote:
Quoting Basile STARYNKEVITCH :
But I don't understand much about gcc/configure.ac and I am extremely
scared to touch that file.
A very big thanks for answering.
There is an info page for autoconf. If you don't like
(to learn how to use) info, you can simply use
info au
* Basile STARYNKEVITCH wrote on Fri, Nov 27, 2009 at 05:57:02PM CET:
> Does anyone have hints on what kind of stuff I should add to have a
> makefile fragment like [a future file] gcc/melt-module.mk.in
> expanded into a melt-module.mk thru autoconf tricks?
Add
AC_CONFIG_FILES([melt-module.mk.in]
20 matches
Mail list logo
