Re: Backward Compatibility of RHEL Advanced Server and GCC
On Wed, Oct 29, 2008 at 6:19 AM, S. Suhasini <[EMAIL PROTECTED]> wrote: > We would like to know whether the new version of the software (compiled with > the new GCC) can be deployed and run on the older setup with RHEL AS 3 and > GCC 2.96. We need not compile again on the older setup. Will there be any > run-time libraries dependency? Would be very grateful if we get a response > for this query. It seems to me that this kind of question is best asked on a RedHat support list, not on a list where compiler development is discussed. FWIW, there is no "official" GCC 2.96, see http://gcc.gnu.org/gcc-2.96.html. Gr. Steven
Re: Continuous builder up
On Tue, Oct 28, 2008 at 8:02 PM, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > 2008/10/25 Daniel Berlin <[EMAIL PROTECTED]>: >> I have placed a continuous builder (IE it does one build per svn >> change) for GCC for x86_64 on an 8 core machine (nicely provided by >> Google), and it has results here: >> http://home.dberlin.org:8010/waterfall > > I think this is great and pretty! Would it be possible to keep a list > of the revisions that failed to build? That could be very useful for > reg-hunting. Could the system send an email to the author of the > revision that failed? > >> (I have not made it summarize the warnings yet, and these deliberately >> do not run the testsuite in order to keep up with the repository. I >> have more servers coming that will run builds that include running the >> testsuite). > > Well, it seems idle right now. And with the new parallel testsuite, it > shouldn't take so much time, so I think it could keep up with the > repository. It seems just a waste of resources to build once and then > build again somewhere else to run the testsuite. > >> In the next few days i will add a continuous builder for i686, as well >> as a server that accepts patches for testing on these platforms and >> spits back results in an hour or less, including the testsuite, so >> those who want to test things while continuing work can do so. > > Great. Although this does not seem such an important issue given the > existing Compile Farm. The compile farm requires a lot of manual work for people (SSH keys, etc) who just want to submit a small patch, whereas upload through a browser or email does not. I will probably even make it provide a debuggable binary and core file for crashes. > > On the other hand, I seriously miss the patch tracker and I think I > was not the only one and we have probably lost a few patches along the > way. Any plans to bring it back? No The patch tracker was an experiment in trying to see if it would improve the rate of patches falling through the cracks. It had the secondary effect of getting some other patches reviewed quicker in some cases, because of those who paid attention to it. In reality, it didn't improve the rate of patch dropping in the areas that we were dropping patches. It guess it turns out those people specifically in charge of those areas didn't care if a long list of patches on a web page pointed to them :) It did improve the rate of patch dropping among those who have limited time to wade through email, I think, but there are better ways to present that info (IE "i am Diego Novilllo, give me the list of patches on the mailing list i could look at") Given that it's main goal was a failure, I don't see why i would bring it back, at least in that form. OTOH, If you want just something to tell you, as an individual reviewer, what patches sent to the mailing list are still waiting for your review, or we want to see about a general code review system that works with email as well as web, i may take a gander.
Your Payment sent to you,
How are you today? I write to inform you that we have already sent you USD6000.00 dollars through Western union as we have been given the mandate to transfer your full compensation payment total sum of USD800,000.00 via western union by this governemnt.I was calling your telephone number to give you the information through phone but you did not pick up my calls throughout that yesterday even this morning.Now, I decided to email you the MTCN and sender name so that you will pick up this USD6000.00 to enable us send another USD6000.00 today as you know we will be sending you only USD6000.00 per day. Please pick up this information and run to western union to pick up the USD6000.00 and call me back to send you another payment today, My direct phone line is +229 93714494,Manager Mr Daniel Koman Email: ([EMAIL PROTECTED] ) call or email me once you picked up this USD6000.00 today. Here is the western union information to pick up the USD6000.00; MTCN : 622 155 4897 Sender's Name: PRINCE AJAA Text Question: HONEST Answer: TRUST Amount: USD 6000.00 I am waiting for your call once you pick up this USD6000.00, Please email me your direct telephone number because I need to be calling you once we send any payment for the informations. Thanks oceanic Bank Plc MrjOSN Eric
Re: Continuous builder up
2008/10/29 Daniel Berlin <[EMAIL PROTECTED]>: > The patch tracker was an experiment in trying to see if it would > improve the rate of patches falling through the cracks. > It had the secondary effect of getting some other patches reviewed > quicker in some cases, because of those who paid attention to it. I will add that it was very useful for tracking patches to PRs. > In reality, it didn't improve the rate of patch dropping in the areas > that we were dropping patches. It guess it turns out those people > specifically in charge of those areas didn't care if a long list of > patches on a web page pointed to them :) Well, those patches were in the list. With the patch tracker at least there is proof of which areas are dropping patches and probably need more reviewers. Otherwise the patches get silently lost. One of the reasons why sporadic contributors do not stick with us is that they feel ignored (or conversely that they do not have enough patience to ping 4 or 5 times). While the patch tracker was active, it also happened a few times that more veteran contributors sent some patch only to forget completely about it and never request a review. But such patches do not get lost in they are in the tracker. I agree that the patch tracker probably does not get more patches reviewed but it definitely gets less patches lost. > It did improve the rate of patch dropping among those who have limited > time to wade through email, I think, but there are better ways to > present that info (IE "i am Diego Novilllo, give me the list of > patches on the mailing list i could look at") Not the same at all. If you have some time to review a patch, you probably want to do it right now. Not send an email and wait for answers. Moreover, that mail could be also missed by the contributors. Finally, I think I have never seen anyone asking for patches to review. Never. But some people did wander through the patch tracker. A bi-weekly status report of the patch tracker sent to gcc-patches would definitively make the list of unreviewed patches more visible. I believe this may also be a problem for the continuous builder: If there is no visible feedback from it, that is, if one needs to actively check its status, then it is likely to be missed/neglected. Cheers, Manuel.
Re: Backward Compatibility of RHEL Advanced Server and GCC
Steven Bosscher wrote: On Wed, Oct 29, 2008 at 6:19 AM, S. Suhasini <[EMAIL PROTECTED]> wrote: We would like to know whether the new version of the software (compiled with the new GCC) can be deployed and run on the older setup with RHEL AS 3 and GCC 2.96. We need not compile again on the older setup. Will there be any run-time libraries dependency? Would be very grateful if we get a response for this query. It seems to me that this kind of question is best asked on a RedHat support list, not on a list where compiler development is discussed. FWIW, there is no "official" GCC 2.96, see http://gcc.gnu.org/gcc-2.96.html. This might be partially topical on the gcc-help list. If dynamic libraries are in use, there will be trouble.
Re: Continuous builder up
On Wed, Oct 29, 2008 at 9:16 AM, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > 2008/10/29 Daniel Berlin <[EMAIL PROTECTED]>: >> The patch tracker was an experiment in trying to see if it would >> improve the rate of patches falling through the cracks. >> It had the secondary effect of getting some other patches reviewed >> quicker in some cases, because of those who paid attention to it. > > I will add that it was very useful for tracking patches to PRs. > >> In reality, it didn't improve the rate of patch dropping in the areas >> that we were dropping patches. It guess it turns out those people >> specifically in charge of those areas didn't care if a long list of >> patches on a web page pointed to them :) > > Well, those patches were in the list. With the patch tracker at least > there is proof of which areas are dropping patches and probably need > more reviewers. Otherwise the patches get silently lost. One of the > reasons why sporadic contributors do not stick with us is that they > feel ignored (or conversely that they do not have enough patience to > ping 4 or 5 times). While the patch tracker was active, it also > happened a few times that more veteran contributors sent some patch > only to forget completely about it and never request a review. But > such patches do not get lost in they are in the tracker. > > I agree that the patch tracker probably does not get more patches > reviewed but it definitely gets less patches lost. But in the end, it didn't solve the underlying problem, so it didn't improve our rate of attrition of smaller contributors. > >> It did improve the rate of patch dropping among those who have limited >> time to wade through email, I think, but there are better ways to >> present that info (IE "i am Diego Novilllo, give me the list of >> patches on the mailing list i could look at") > > Not the same at all. If you have some time to review a patch, you > probably want to do it right now. Not send an email and wait for > answers. Moreover, that mail could be also missed by the contributors. > Finally, I think I have never seen anyone asking for patches to > review. Never. But some people did wander through the patch tracker. I think you misunderstood whatI meant. Basically you would enter your email address into the page, and it would figure out, based on it's internal list of maintenance areas and black magic, what patches are wiating around that you cold possibly review. It would not require sending an email, etc. It would effectively be "wandering through the patch tracker" except it would limit it's display to those things you could actually help with, instead of a list of 100 patches, most of which yo may not be able to do anything about. > > A bi-weekly status report of the patch tracker sent to gcc-patches > would definitively make the list of unreviewed patches more visible. I > believe this may also be a problem for the continuous builder: If > there is no visible feedback from it, that is, if one needs to > actively check its status, then it is likely to be missed/neglected. I did this for about 2 weeks, and was asked privately by a few to stop because they saw it as spam. At this point, I don't know what i can do that actually helps the problems we face as a community.
How to find out all the calling instance of a class member function?
Hi, Suppose I have a class B in namespace A, it has several overloaded member function doit. I'm wondering how to find all the lines where there is a statement that calls one particular overloaded doit member function? Is it possible to do so from g++ command line? Or I have to modify g++ to make it be able to do so? Thanks, Peng
Re: Continuous builder up
"Daniel Berlin" <[EMAIL PROTECTED]> writes: >> A bi-weekly status report of the patch tracker sent to gcc-patches >> would definitively make the list of unreviewed patches more visible. I >> believe this may also be a problem for the continuous builder: If >> there is no visible feedback from it, that is, if one needs to >> actively check its status, then it is likely to be missed/neglected. > > I did this for about 2 weeks, and was asked privately by a few to stop > because they saw it as spam. Sending those reports to the mailing list was always the main use I saw for the patch tracker. I'd like to open this issue up. Who would consider those reports to be spam? Who would be opposed to reinstating the patch tracker and having it send out notes about patches which have not been reviewed? Back at Cygnus I wrote a script which sent out a daily report for bugs which had not been fixed, and I think it was very helpful. A daily report is not appropriate here, but I think that a weekly report is. Ian
Register Allocation Question.
Hello Everyone, I have a question regarding the register allocation steps in GCC. I am creating an hypothetical example to make things easy. My processor has 2 set of register fiels with 1-16 in Class1 and 16-32 in class 2 Let's say I have an RTL X with destination register R1, But if I want to schedule this RTL to Class2. What can I do? I see that GCC doesn't change the register number if it already holds a hard-register. Any help is highly appreciated. Please CC me in your response since I am not a subscribed member. Thanks, Balaji V. Iyer. -- Balaji V. Iyer PhD Candidate, Center for Efficient, Scalable and Reliable Computing, Department of Electrical and Computer Engineering, North Carolina State University.
Re: Continuous builder up
2008/10/29 Daniel Berlin <[EMAIL PROTECTED]>: >> >> I agree that the patch tracker probably does not get more patches >> reviewed but it definitely gets less patches lost. > > But in the end, it didn't solve the underlying problem, so it didn't > improve our rate of attrition of smaller contributors. There are more important issues than getting your patch ignored that scare away smaller contributors. My point is that losing contributors is sad but losing patches is also sad. They are two related but different things and the patch tracker helped with the latter. > I think you misunderstood whatI meant. > Basically you would enter your email address into the page, and it > would figure out, based on it's internal list of maintenance areas and > black magic, what patches are wiating around that you cold possibly > review. > It would not require sending an email, etc. > It would effectively be "wandering through the patch tracker" except > it would limit it's display to those things you could actually help > with, instead of a list of 100 patches, most of which yo may not be > able to do anything about. Are you talking about something you are planning to implement? This seems a desirable feature of the tracker. However, having this does not invalidate the previous setup, which was useful for other cases I already mentioned. >> A bi-weekly status report of the patch tracker sent to gcc-patches >> would definitively make the list of unreviewed patches more visible. I >> believe this may also be a problem for the continuous builder: If >> there is no visible feedback from it, that is, if one needs to >> actively check its status, then it is likely to be missed/neglected. > > I did this for about 2 weeks, and was asked privately by a few to stop > because they saw it as spam. Really? That is very disturbing. I don't see how a bi-weekly ping could be more spam than the multiple individual 'pings' we currently request from contributors. Moreover, I fail to understand why, if you are a reviewer, wouldn't be interested in a list of unreviewed patches. Unless you don't want to be a reviewer, that is. > At this point, I don't know what i can do that actually helps the > problems we face as a community. I don't think that the patch tracker could solve all problems but it was a very nice and useful tool. Probably, there is not even a consensus about which are those problems. In my opinion, the talk Chris Lattner gave at Google [*] was right on many issues regarding the difficulties to contribute to GCC. Cheers, Manuel. [*] http://video.google.com/videoplay?docid=1921156852099786640#21m40s
r141295 and r141383 commits broke UTF-8 in gcc/ChangeLog
Hi! Nick/Vlad, could you please check your editors? Your recent r141295 and r141383 commits mangled many UTF-8 characters in gcc/ChangeLog. I've reverted those parts of your commits as r141428, just wouldn't like to do it too often. Thanks. Jakub
Re: Continuous builder up
On Wed, Oct 29, 2008 at 11:42 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > "Daniel Berlin" <[EMAIL PROTECTED]> writes: > >>> A bi-weekly status report of the patch tracker sent to gcc-patches >>> would definitively make the list of unreviewed patches more visible. I >>> believe this may also be a problem for the continuous builder: If >>> there is no visible feedback from it, that is, if one needs to >>> actively check its status, then it is likely to be missed/neglected. >> >> I did this for about 2 weeks, and was asked privately by a few to stop >> because they saw it as spam. > > Sending those reports to the mailing list was always the main use I > saw for the patch tracker. I'd like to open this issue up. Who would > consider those reports to be spam? Who would be opposed to > reinstating the patch tracker and having it send out notes about > patches which have not been reviewed? > > Back at Cygnus I wrote a script which sent out a daily report for bugs > which had not been fixed, and I think it was very helpful. A daily > report is not appropriate here, but I think that a weekly report is. I'm happy to reinstate the tracker for this purpose if i'm not going to get yelled at :)
RE: Continuous builder up
Ian Lance Taylor wrote on 29 October 2008 15:42: > "Daniel Berlin" <[EMAIL PROTECTED]> writes: > >>> A bi-weekly status report of the patch tracker sent to gcc-patches >>> would definitively make the list of unreviewed patches more visible. I >>> believe this may also be a problem for the continuous builder: If >>> there is no visible feedback from it, that is, if one needs to >>> actively check its status, then it is likely to be missed/neglected. >> >> I did this for about 2 weeks, and was asked privately by a few to stop >> because they saw it as spam. > > Sending those reports to the mailing list was always the main use I > saw for the patch tracker. I'd like to open this issue up. Who would > consider those reports to be spam? Who would be opposed to > reinstating the patch tracker and having it send out notes about > patches which have not been reviewed? I think it's not remotely spam - certainly not by any of the standard definitions of BI or UCE, and I think it's distorting the meaning of the word to call it spam, and more of a pejorative than a meaningful description. I also think it would be trivial to filter on subject or any number of other criteria for those who really didn't want to see it, and also that (given the volume of mail on the -patches list) not even worth the effort of ignoring or caring about for anyone who wasn't interested. One post amongst the thousand-or-so we get in an average week? Come on! As to the actual substance of the matter at hand: I thought the patch tracker was a boon. I would be very glad to see it brought back into service. The more automation we can use to help us overcome or mitigate our human failings, the better. cheers, DaveK -- Can't think of a witty .sigline today
Re: Continuous builder up
On Wed, Oct 29, 2008 at 8:42 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > "Daniel Berlin" <[EMAIL PROTECTED]> writes: > Back at Cygnus I wrote a script which sent out a daily report for bugs > which had not been fixed, and I think it was very helpful. A daily > report is not appropriate here, but I think that a weekly report is. There could be a way to do this via bugzilla if every patch gets a bug report and we have a whine setup for [EMAIL PROTECTED] I have a whine setup for myself already about the bugs that are assigned to me already. So the only thing left in my mind is having people use bugzilla or having a way that automatically sets up the keyword patch and the URL field for the bug reports. Thanks, Andrew Pinski
Re: Register Allocation Question.
> Let's say I have an RTL X with destination register R1, But if I > want to schedule this RTL to Class2. What can I do? I see that GCC > doesn't change the register number if it already holds a hard-register. Use constraints. They are described in md.texi.
gcc-4.2-20081029 is now available
Snapshot gcc-4.2-20081029 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20081029/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 141449 You'll find: gcc-4.2-20081029.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20081029.tar.bz2 C front end and core compiler gcc-ada-4.2-20081029.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20081029.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20081029.tar.bz2 C++ front end and runtime gcc-java-4.2-20081029.tar.bz2 Java front end and runtime gcc-objc-4.2-20081029.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20081029.tar.bz2The GCC testsuite Diffs from 4.2-20081022 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Continuous builder up
"Andrew Pinski" <[EMAIL PROTECTED]> writes: > On Wed, Oct 29, 2008 at 8:42 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: >> "Daniel Berlin" <[EMAIL PROTECTED]> writes: >> Back at Cygnus I wrote a script which sent out a daily report for bugs >> which had not been fixed, and I think it was very helpful. A daily >> report is not appropriate here, but I think that a weekly report is. > > There could be a way to do this via bugzilla if every patch gets a bug > report and we have a whine setup for [EMAIL PROTECTED] I have a whine > setup for myself already about the bugs that are assigned to me > already. > > So the only thing left in my mind is having people use bugzilla or > having a way that automatically sets up the keyword patch and the URL > field for the bug reports. It needs to be a summary report, not one message per patch. Does bugzilla have that capability? Ian
Re: Continuous builder up
On Wed, Oct 29, 2008 at 3:48 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > It needs to be a summary report, not one message per patch. Does > bugzilla have that capability? Yes, here is an example of the whine report (from yesterday): Click here to edit your whine schedule Assigned bugs ID Sev Pri HostTarget Build AssigneeStatus Resolution Summary 22154 normal P2 [EMAIL PROTECTED] ASSIGNED[DR 382] qualified names should allow typename keyword in front of it (even in non-templates) 22210 enhancement P2 [EMAIL PROTECTED] ASSIGNEDgfc_conv_array_initializer weirdness 23104 normal P4 [EMAIL PROTECTED] ASSIGNED[4.2/4.3/4.4 Regression] C does not reject the same function in two different TUs with -combine 23680 enhancement P2 [EMAIL PROTECTED] ASSIGNED@synchronized support is not in GNU runtime 23681 minor P2 [EMAIL PROTECTED] ASSIGNEDCLS_HAS_CXX_STRUCTORS is not supported with the GNU runtime 23709 minor P5 [EMAIL PROTECTED] NEW [4.2/4.3/4.4 Regression] error recovery is not smart enough 23983 enhancement P2 [EMAIL PROTECTED] ASSIGNEDthe altivec builtins should be marked as pure/const 24775 normal P3 [EMAIL PROTECTED] ASSIGNEDlibobjc should not include GCC's target headers 25359 normal P3 [EMAIL PROTECTED] ASSIGNEDsome objc.dg-struct-layout-encoding-1 failures 25547 minor P3 [EMAIL PROTECTED] ASSIGNED3 * dead data in compiler source code 25567 minor P3 [EMAIL PROTECTED] ASSIGNED4 * set but never used 27466 enhancement P3 [EMAIL PROTECTED] ASSIGNEDRFE: Support for libobjc equivalent of std::set_unexpected 28115 normal P3 [EMAIL PROTECTED] ASSIGNEDpossible bug in recog_memoized usage in rs6000.c?? 29589 normal P3 [EMAIL PROTECTED] ASSIGNEDincorrect conversion of (ior (ashiftrt (plus ...))) in combine.c 30164 normal P3 [EMAIL PROTECTED] ASSIGNEDGimplifier does not produce valid gimple for global_vectora = CONSTRUCTOR 30462 normal P3 [EMAIL PROTECTED] ASSIGNEDlibobjc public headers should be wrapped with #pragam visibilitity push(defualt)/pop 30930 normal P4 [EMAIL PROTECTED] ASSIGNED[4.3 Regression] vector can cause to create an extra variable, DECL_GIMPLE_REG_P not recomputed 32037 normal P3 [EMAIL PROTECTED] ASSIGNED--enable-objc-gc on OS X won't build 32107 enhancement P3 [EMAIL PROTECTED] ASSIGNEDbad codegen for vector initialization in Altivec 32110 enhancement P3 [EMAIL PROTECTED] ASSIGNEDvector "extract" and then vector "splat" is not optimized 33512 enhancement P3 [EMAIL PROTECTED] ASSIGNEDSimple bitwise simplification missed 35430 normal P2 [EMAIL PROTECTED] ASSIGNED[4.2/4.3/4.4 regression] ICE with complex arithmetic 35854 normal P4 [EMAIL PROTECTED] ASSIGNED[4.3/4.4 Regression] life passes dump option still documented 36143 normal P2 [EMAIL PROTECTED] ASSIGNED[4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C 36165 enhancement P3 [EMAIL PROTECTED] ASSIGNEDForeign exceptions for Objective-C and C++ are not tested 36431 normal P3 [EMAIL PROTECTED] ASSIGNEDThe C++ front-end produces some NOP_EXPR for vector types 36891 normal P2 [EMAIL PROTECTED] ASSIGNED[4.2/4.3 Regression] ICE with vector division and -ffast-math and LIM 37219 normal P2 [EMAIL PROTECTED] ASSIGNED[4.3 Regression] fwprop1 is broken for addresses 37263 normal P2 [EMAIL PROTECTED] ASSIGNED[4.3 Regression] extra code for doloop with unsigned 32bit types on LP64 37451 enhancement P3
