On 8 June 2010 05:42, Basile Starynkevitch wrote:
> On Mon, 2010-06-07 at 15:05 -0600, Jeff Law wrote:
>> On 06/07/10 14:31, Ian Lance Taylor wrote:
>> > The gcc project currently has a problem: when people who are not
>> > regular gcc developers send in a patch, those patches often get
>> > droppe
Hi all,
I've committed the gc-improv code to trunk. The testsuite is still
running, however bootstrap went fine on x86_64/linux. Due to nature of
the changes, any problems should show up as bootstrap compile errors
and on x86_64/linux I don't expect them.
The problems are more (although IMHO not
> Reading gcc-cvs, or ChangeLogs, or other things like that is just way
> too much time.
What about writing a small script that parses the main ChangeLogs? They are
supposed to be uniformly formatted. And ping messages shouldn't contain all
the junk of previous messages, just the ChangeLog (an
On 06/08/2010 06:42 AM, Basile Starynkevitch wrote:
On Mon, 2010-06-07 at 15:05 -0600, Jeff Law wrote:
So perhaps the thing to do is somehow separate patches from regular
contributors and irregular contributors. A relatively easy way to do
this would be for a regular contributor to include a ke
On 8 June 2010 07:43, Chiheng Xu wrote:
> On Tue, Jun 8, 2010 at 9:14 AM, Ben White wrote:
>> Would a modestly modified copy of Bugzilla be workable for that something?
>> I.E. Patchzilla?
>
> Think about mercurial or git. Every one can commit on his/her own
> local repository, and "publish" his
On 8 June 2010 10:43, Paolo Bonzini wrote:
> On 06/08/2010 06:42 AM, Basile Starynkevitch wrote:
>>
>> On Mon, 2010-06-07 at 15:05 -0600, Jeff Law wrote:
>>>
>>> So perhaps the thing to do is somehow separate patches from regular
>>> contributors and irregular contributors. A relatively easy way
On 8 June 2010 11:17, Manuel López-Ibáñez wrote:
> On 8 June 2010 10:43, Paolo Bonzini wrote:
>> On 06/08/2010 06:42 AM, Basile Starynkevitch wrote:
>>>
>>> On Mon, 2010-06-07 at 15:05 -0600, Jeff Law wrote:
So perhaps the thing to do is somehow separate patches from regular
contri
Hi,
We have been implementing GCC port for a new target.
The FRAME_POINTER_REGNUM is defined a pseudo register in header file.
I am using the following macros in header file to eliminate the pseudo
arg pointer and frame pointer.
However, there are some instances of frame pointer in the assembly c
On x86_64/linux, the merge does not cause any new testsuite
regressions, except the fact that two new testcases were added during
the freeze:
gfortran.dg/proc_ptr_27.f90
g++.dg/cpp0x/decltype23.C
So now I am more or less done with testing, and I am waiting for any
complaints :)
--
Laurynas
On 7 June 2010 22:43, Ian Lance Taylor wrote:
>
> The patch tracker (http://gcc.gnu.org/wiki/GCC_Patch_Tracking) is not
> currently operating.
>
> Would anybody like to volunteer to get it working again?
I'm not volunteering, but I might look into it one day. I already
have too little spare time
Hi,
Sorry for coming back to this issue after a while. I am still puzzled
by this. The following are two test files:
a.c
#include
#include
extern int foo(int);
void bar()
{
printf("bar\n");
}
extern int src[], dst[];
int vv;
int main()
{
int ret;
vv = 12;
ret = foo(20);
On Tue, Jun 8, 2010 at 3:01 PM, Bingfeng Mei wrote:
> Hi,
> Sorry for coming back to this issue after a while. I am still puzzled
> by this. The following are two test files:
>
> a.c
>
> #include
> #include
> extern int foo(int);
> void bar()
> {
> printf("bar\n");
> }
> extern int src[], dst[]
I'm currently working on an update of the patch for PR42843, and I wonder
what best to do about the symbol plugin_is_GPL_compatible.
Although gcc doesn't currently mangle global variables, a future version of
gcc - or any other build compiler - might add mangling.
If I add:
#ifdef __cplusplus
e
On Tue, Jun 08, 2010 at 09:48:15AM -0400, Joern Rennecke wrote:
> I'm currently working on an update of the patch for PR42843, and I wonder
> what best to do about the symbol plugin_is_GPL_compatible.
>
> extern int plugin_is_GPL_compatible;
>
> However, it would mean that plugin_is_GPL_compatib
Thanks. But why "v" is linked correctly here? Shouldn't it
be treated as static with -fwhole-program?
Bingfeng
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 08 June 2010 14:10
> To: Bingfeng Mei
> Cc: Jan Hubicka; gcc@gcc.gnu.org; Cary Cou
On Tue, Jun 8, 2010 at 4:15 PM, Bingfeng Mei wrote:
> Thanks. But why "v" is linked correctly here? Shouldn't it
> be treated as static with -fwhole-program?
Works for me without the linker plugin as well:
> gcc-4.5 -O2 -o t t1.o t2.o -flto -fwhole-program -B
> /abuild/rguenther/trunk-g/gcc
Quoting Laurynas Biveinis :
I forgot in my previous e-mail the actual diff and the ChangeLogs of
the gc-improv merge, attaching now.
Your gcc/gcc/cp/ChangeLog entry starts with 'Likewise.'
Yes, this is also what I saw without plugin. I just wonder why "v"
is linked with plugin if resolution file is not used to eliminate need
of externally_visible attribute here.
Thanks,
Bingfeng
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 0
On Tue, Jun 8, 2010 at 4:22 PM, Bingfeng Mei wrote:
> Yes, this is also what I saw without plugin. I just wonder why "v"
> is linked with plugin if resolution file is not used to eliminate need
> of externally_visible attribute here.
Probably because of the same linker-plugin bug that causes
On Tue, Jun 8, 2010 at 3:53 AM, Eric Botcazou wrote:
>> Reading gcc-cvs, or ChangeLogs, or other things like that is just way
>> too much time.
>
> What about writing a small script that parses the main ChangeLogs? They are
> supposed to be uniformly formatted. And ping messages shouldn't contai
Joern Rennecke wrote:
> #ifdef __cplusplus
> extern "C" {
> #endif
> extern int plugin_is_GPL_compatible;
> #ifdef __cplusplus
> }
> #endif
I think that's a good idea; I don't think that at this point we've made
any plugin compatibility guarantees. (In the future, I think we should
-- but only w
On Mon, Jun 7, 2010 at 8:34 PM, Paolo Carlini wrote:
> On 06/08/2010 02:20 AM, Manuel López-Ibáńez wrote:
>> Perhaps NightStrike can fine-tune his approach.
> By the way, I wonder how many contributors can even think taking
> seriously a message coming from "NightStrike". Not me, for sure...
>
> P
2010/6/8 Joern Rennecke :
> Quoting Laurynas Biveinis :
>
>> I forgot in my previous e-mail the actual diff and the ChangeLogs of
>> the gc-improv merge, attaching now.
>
> Your gcc/gcc/cp/ChangeLog entry starts with 'Likewise.'
I have noticed it before the actual commit, the committed version is
I first installed gcc 4.5.0 on my Powerpc dual 970 machine with no
configuration options. That was successful, but the long long feature was
not enabled. Then I re-installed gcc 4.5.0 with this gcc v output:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/powerpc-
On 06/08/10 09:01, NightStrike wrote:
On Mon, Jun 7, 2010 at 8:34 PM, Paolo Carlini wrote:
On 06/08/2010 02:20 AM, Manuel López-Ibáńez wrote:
Perhaps NightStrike can fine-tune his approach.
By the way, I wonder how many contributors can even think taking
seriously a message
Hi all,
Jeremy has set up a Patchwork instance for us at
http://patchwork.ozlabs.org/project/gcc/list/ .
It is feeding from gcc-patches; the plan is to make it
automatically recognise what patches went into the tree,
probably by snooping the gcc-cvs list.
You can also manually change patch s
On Tue, Jun 8, 2010 at 11:21 AM, Jeff Law wrote:
> On 06/08/10 09:01, NightStrike wrote:
>>
>> On Mon, Jun 7, 2010 at 8:34 PM, Paolo Carlini
>> wrote:
>>
>>>
>>> On 06/08/2010 02:20 AM, Manuel López-Ibáńez wrote:
>>>
Perhaps NightStrike can fine-tune his approach.
>>>
>>> By the wa
On Mon, Jun 7, 2010 at 10:43 PM, Chiheng Xu wrote:
> On Tue, Jun 8, 2010 at 9:14 AM, Ben White wrote:
>> Would a modestly modified copy of Bugzilla be workable for that something?
>> I.E. Patchzilla?
>
> Think about mercurial or git. Every one can commit on his/her own
> local repository, and "p
On 8 June 2010 17:42, H.J. Lu wrote:
>
> git is an excellent tool to create and share patches. Maybe we should
> have an open gcc git mirror with gitweb and every contributor can create
> his/her own branches and publish them.
http://gcc.gnu.org/wiki/GitMirror
I don't see how such a thing solves
Hi,
I am forwarding to you a mail that I sent to the uClibc mailing list as
I think it is actually a compiler issue. Please see below for the
original. Any tips would be greatly appreciated.
/Jonas
Forwarded Message
From: jonas at southpole dot se
To: ucl...@uclibc.org
Subject:
On 06/08/2010 05:42 PM, H.J. Lu wrote:
>> Think about mercurial or git. Every one can commit on his/her own
>> local repository, and "publish" his/her repository. [...]
>
> git is an excellent tool to create and share patches. Maybe we should
> have an open gcc git mirror with gitweb and every c
> Are you volunteering to write that small script?
If nothing better comes out, why not, but resurrecting the Patch Tracker seems
to be a more appealing idea.
--
Eric Botcazou
On Tue, 2010-06-08 at 09:21 -0600, Jeff Law wrote:
> >
> > Look, you don't want me to be here... fine. I get it. Enough is
> > enough already. Technical disagreements are one thing. Personal
> > attacks on me are just juvenile.
> >
> I don't see this as a personal attack.
>
> Like Paolo, I
On 06/08/2010 08:40 PM, Basile Starynkevitch wrote:
> There is no personal attack involved.
For sure. Sorry if my quick remark could be interpreted in another way.
Paolo.
On Tue, 2010-06-08 at 11:18 +0200, Manuel López-Ibáñez wrote:
> >>
> >> I don't understand. WAA rights definitely allow you to shepherd and commit
> >> patches from people without svn access, even for patches you can't approve.
> >
> > And basile (and other WAA contributors), this would a nice
> >
On 06/08/2010 09:21 PM, Basile Starynkevitch wrote:
On Tue, 2010-06-08 at 11:18 +0200, Manuel López-Ibáñez wrote:
I don't understand. WAA rights definitely allow you to shepherd and commit
patches from people without svn access, even for patches you can't approve.
And basile (and other WAA c
"Naveen H. S" writes:
> The FRAME_POINTER_REGNUM is defined a pseudo register in header file.
> I am using the following macros in header file to eliminate the pseudo
> arg pointer and frame pointer.
> However, there are some instances of frame pointer in the assembly code.
> #define ELIMINABLE
"Segher Boessenkool" writes:
> Jeremy has set up a Patchwork instance for us at
>
>http://patchwork.ozlabs.org/project/gcc/list/ .
>
> It is feeding from gcc-patches; the plan is to make it
> automatically recognise what patches went into the tree,
> probably by snooping the gcc-cvs list.
>
>
Jonas Bonn writes:
> I am forwarding to you a mail that I sent to the uClibc mailing list as
> I think it is actually a compiler issue. Please see below for the
> original. Any tips would be greatly appreciated.
This message would be more appropriate for the mailing list
gcc-h...@gcc.gnu.org.
>> It is feeding from gcc-patches; the plan is to make it
>> automatically recognise what patches went into the tree,
>> probably by snooping the gcc-cvs list.
> This is quite interesting, thanks for setting it up.
All kudos go to Jeremy, I merely try to push people :-)
> I can see already that
On 08/06/2010 20:31, Paolo Bonzini wrote:
> Here are a few of the people with access to the copyright list: me, Ian,
> Benjamin Koznik, David Edelsohn, Andreas Schwab, Joseph Myers, Ralf
> Wildenhues. This is not a complete list, just people that I remember.
I also have access and am happy to
Snapshot gcc-4.4-20100608 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100608/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 6/8/10, NightStrike wrote:
> Are you volunteering to write that small script?
DUnno, are you volunteering to write that small script?
You're the only one here actually volunteering a forwardgoing
commitment of their time here to improve GCC's development in this
way, it seems (and mostly just
Hi Ian,
> I can see already that to be useful for gcc today it will need some
> curating. E.g., http://patchwork.ozlabs.org/patch/54974/ is both 1)
> committed; 2) on a branch. This one
> http://patchwork.ozlabs.org/patch/54958/ is committed to trunk.
There are a number of ways to keep the patc
On Tue, Jun 8, 2010 at 11:55 PM, Tobias Burnus wrote:
> On 06/08/2010 05:42 PM, H.J. Lu wrote:
>>> Think about mercurial or git. Every one can commit on his/her own
>>> local repository, and "publish" his/her repository. [...]
>>
>> git is an excellent tool to create and share patches. Maybe we
On Tue, Jun 8, 2010 at 7:03 PM, Martin Guy wrote:
> On 6/8/10, NightStrike wrote:
>> Are you volunteering to write that small script?
>
> DUnno, are you volunteering to write that small script?
Sorry, no :(
> You're the only one here actually volunteering a forwardgoing
> commitment of their ti
On 06/08/2010 10:37 PM, Ian Lance Taylor wrote:
Are there ways that we can adjust our e-mail messages to make this
work better?
Two things: 1) we should make the [bracket] prefixes more standard for
patches destined to feature branches; 2) we should likely not send
multiple patches in one ema
47 matches
Mail list logo
