Re: GCC 4.3.3 Status Report (2009-01-17), branch frozen for release
Richard, I would like to revert the cause of the regression reported yesterday in http://gcc.gnu.org/ml/fortran/2009-01/msg00197.html - I'll do it in the next hour, if that is alright? Cheers Paul On Sat, Jan 17, 2009 at 12:03 AM, Richard Guenther wrote: > > It's not my turn to send a status report, but as I plan doing a release > candidate for GCC 4.3.3 soon I thought a status report for that would > be in order. > > Status > == > > The GCC 4.3 branch is now frozen in preparation for a release candidate > for the GCC 4.3.3 release. When the branch is unfrozen again I will > send a message stating so. All checkins to the branch require approval > by a release manager now. > > There is a single regression that shows up as P1, but as it is not > a regression on the branch (but from the tree-ssa merge) it does not > block the GCC 4.3.3 release (but the bug priority is considered the priority > for the newest release the bug is a regression for). > > I am not aware of any issues blocking an immediate release of GCC 4.3.3. > Please make me aware of such issues by replying to this mail and/or > by CCing me on bugzillas that are regressions on the GCC 4.3 branch > but are not marked as such (a regression on the GCC 4.3 branch is a > bug with a testcase that worked in a previous GCC 4.3 based release > but fails on the top of the GCC 4.3 branch). > > > Quality Data > > > Priority # Change from Last Report > --- --- > P11 - 4 > P2 137 + 7 > P32 - 1 > --- --- > Total 140 + 2 > > > The next status report will be sent by me. > > Richard. > -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
New mirror
Hello, we decided to run new GCC mirror in Bulgaria. Here are the details. Country: Bulgaria City: Sofia Bandwidth: 2 gbps aggregated link to the Bulgarian Peering, 500 mbps international Contact: i...@onlinedirect.bg URL: http://gcc.igor.onlinedirect.bg/ FTP: ftp://gcc.igor.onlinedirect.bg/others/gcc/ 1000 connections limit. Gets synced every 6 hours. Best regards
Re: GCC 4.3.3 Status Report (2009-01-17), branch frozen for release
> Richard, > > I would like to revert the cause of the regression reported yesterday > in http://gcc.gnu.org/ml/fortran/2009-01/msg00197.html - I'll do it in > the next hour, if that is alright? > > Cheers > > Paul Duly reverted on trunk and 4.3. Paul
I'm Telling a Friend - YOU!...
Dear Dahir-Duale-Abdi, I Just found this great website: http://www.extremewebsitetraffic.com Guaranteed quality traffic - check them out! Regards, YOUR NAME NOTICE: this message was sent to you by a friend using our tell a friend form.
Traffic/Hits Information
The link below is used to track your hits we are going to send you... track your hits: http://www.extremewebsitetraffic.com/hits.php/QHXFHBT.php * your hits are currently pending validation by the site admin, once we manually verify your entry you will start receiving traffic to your site and the stats link above will then start displaying the traffic you receive. Site Admin ExtremeWebsiteTraffic.com note: this is an automated notification message, no need to reply.
Affiliate Account Information
Below is your affiliate information, please save: - Username: Abdi.Dahirduale Password: daahir987 Your Affiliate Link: http://www.extremewebsitetraffic.com/r.php/Abdi.Dahirduale.php - Affiliate Login: http://www.extremewebsitetraffic.com/affiliates/login.php Site Admin ExtremeWebsiteTraffic.com note: this is an automated notification message, no need to reply.
Validate Your Email Address
Below is your affiliate email address validation code: Code: NQZ8XLMVXM Go here for instant validation: http://www.extremewebsitetraffic.com/affiliates/validate.php Site Admin ExtremeWebsiteTraffic.com note: this is an automated notification message, no need to reply.
GCC 4.3.3 Release Candidate available from gcc.gnu.org
A release candidate for GCC 4.3.3 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.3-RC-20090117/ and shortly its mirrors. It has been generated from SVN revision 143460. The branch is still frozen and all checkins until after the final release of GCC 4.3.3 require explicit RM approval. Thanks, Richard.
Activate your Email Subscription to: AdBrite Blog
Hello there, You recently requested an email subscription to the AdBrite Blog. We can't wait to send the updates you want via email, so please click the following link to activate your subscription immediately: http://www.feedburner.com/fb/a/emailconfirm?k=ZBvYTFHDxU&i=23278330 (If the link above does not appear clickable or does not open a browser window when you click it, copy it and paste it into your web browser's Location bar.)
Download link for 200 Master Resell Rights Products
Hi Dahir-duale Here is download link for 200 Master Resell Rights Products http://www.resellrightspack.com Enjoy Here For Your Success Cody Moya Xodo Inc, 549 A Pompton Ave, STE# 176, Cedar Grove, NJ 07009, USA To unsubscribe or change subscriber options visit: http://www.aweber.com/z/r/?zKycnKwctMwcTKysjCzstGa0zJxMTMxs
Traffic/Hits Information
The link below is used to track your hits we are going to send you... track your hits: http://www.extremewebsitetraffic.com/hits.php/6GUE8XU.php * your hits are currently pending validation by the site admin, once we manually verify your entry you will start receiving traffic to your site and the stats link above will then start displaying the traffic you receive. Site Admin ExtremeWebsiteTraffic.com note: this is an automated notification message, no need to reply.
Re: Useless option parsing code in genautomata.c ?
OK, I got it. ^_^ I should specify these options through (automata_option options) in md. //I tried to use those options in command line like "genautomata -v foo.md", which was not supported Thanks very much. Best, Jim On 1/16/09, Ben Elliston wrote: >> Now I just set v_flag to 1 manually in code to get the output, but I >> don't think it is a correct way. >> Anyone could tell me the correct way to output automata description, >> or help me to confirm this bug? > > I don't think there is a bug. What do you have in your define_automaton > directive? Note that `-' is not required for these options. > > Ben > >
Re: Extremewebsitetraffic.com
Hello, We got three emails from you with three different sites. How may we help you? Thanks, Ewt. Team
Re: GCC 4.3.3 Status Report (2009-01-17), branch frozen for release
On Sat, 17 Jan 2009, Richard Guenther wrote: > It's not my turn to send a status report, but as I plan doing a release > candidate for GCC 4.3.3 soon I thought a status report for that would > be in order. Sorry Richard, I didn't see this until too late. I committed three PA changes this morning, the first being fairly important. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: GCC 4.3.3 Status Report (2009-01-17), branch frozen for release
On Sat, 17 Jan 2009, John David Anglin wrote: > On Sat, 17 Jan 2009, Richard Guenther wrote: > > > It's not my turn to send a status report, but as I plan doing a release > > candidate for GCC 4.3.3 soon I thought a status report for that would > > be in order. > > Sorry Richard, I didn't see this until too late. I committed three > PA changes this morning, the first being fairly important. If you are fine with these not being in the release-candidate but only in the final release then I don't mind. Richard.
Re: GCC 4.3.3 Status Report (2009-01-17), branch frozen for
> If you are fine with these not being in the release-candidate but > only in the final release then I don't mind. That's fine. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: GCC 4.4.0 Status Report (2009-01-06)
[Cc list trimmed] Richard Guenther wrote: > Status > == > > The trunk remains Stage 4, so only fixes for regressions (and changes > to documentation) are allowed. Hello Richard, There are a number of bootstrap failures on the cygwin platform, which I am currently fixing at full tilt. See PRs: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38903 for which I have submitted one patch so far: http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00896.html and am working on a second now for PR37660. There is also a problem that is not a regression but a non-conformance issue in a new feature; the shared libgcc DLL built on Cygwin does not adhere to the naming conventions for the platform. See PR: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38904 for which I will also shortly submit a patch, to be applied optionally on top of the 37660 fix. If I understand rightly, it is the case that target maintainers are allowed some leeway in what to accept during stage 4, in which case I would like to appeal for consideration of my patch to resolve this issue to be included before 4.4, so that we don't have to suffer an ABI break by waiting for 4.5 to fix it. This patch will also touch one part of the global build machinery, mkmap-flat.awk, and although it only touches an if() clause that is strictly target-specific, a build maintainer would have to give approval as well. I notice we're starting to reach the < 100 open PRs point, although there are still a few P1s, so do you think I'll have another two or three days before you start looking at freezing for branching? cheers, DaveK
putting operands in MEM even with register_operand predicate
Hi, I have a rule in machine descriptor: (define_insn "fract2" [(set (match_operand:FIXED1 0 "register_operand" "") (fract_convert:FIXED1 (match_operand:FIXED2 1 "register_operand" "")))] "" "* return fract_out (insn, operands, 1, NULL);" [(set_attr "cc" "clobber")]) Basically it generates instructions for fixed point conversions, but I found that in certain very unlikely cases, sometimes it calls fract_out where one of the operands is in MEM and is not a register. This caused my function to output incorrect assembly which could not be assembled. I found that I can fix this problem by adding "=r" and "r" as follows: (define_insn "fract2" [(set (match_operand:FIXED1 0 "register_operand" "=r") (fract_convert:FIXED1 (match_operand:FIXED2 1 "register_operand" "r")))] "" "* return fract_out (insn, operands, 1, NULL);" [(set_attr "cc" "clobber")]) So I'm trying to understand this since I thought register_operand was supposed to make things be in a register... I'm sure this is easy to explain. Eventually I need to output instructions so one or the other operands is allowed to be in MEM for efficiency reasons, but I want to understand this first. Thanks, Sean
Re: putting operands in MEM even with register_operand predicate
"Sean D'Epagnier" writes: > I have a rule in machine descriptor: > > (define_insn "fract2" > [(set (match_operand:FIXED1 0 "register_operand" "") > (fract_convert:FIXED1 (match_operand:FIXED2 1 > "register_operand" "")))] > "" > "* return fract_out (insn, operands, 1, NULL);" > [(set_attr "cc" "clobber")]) > > Basically it generates instructions for fixed point conversions, but I > found that in certain very unlikely cases, sometimes it calls > fract_out where one of the operands is in MEM and is not a register. > This caused my function to output incorrect assembly which could not > be assembled. > > I found that I can fix this problem by adding "=r" and "r" as follows: > > (define_insn "fract2" > [(set (match_operand:FIXED1 0 "register_operand" "=r") > (fract_convert:FIXED1 (match_operand:FIXED2 1 > "register_operand" "r")))] > "" > "* return fract_out (insn, operands, 1, NULL);" > [(set_attr "cc" "clobber")]) > > > So I'm trying to understand this since I thought register_operand was > supposed to make things be in a register... I'm sure this is easy to > explain. Eventually I need to output instructions so one or the > other operands is allowed to be in MEM for efficiency reasons, but I > want to understand this first. The predicates, like register_operand, are applied when an insn is recognized. An insn which does not meet those predicates is not recognized. However, before register allocation, the insn will be recognized with pseudo-registers. The register allocator may be unable to allocate the pseudo register to a real register. That will change the insn from using a REG to using a MEM. After the register allocator, the reload phase is responsible for making sure that all registers meet their constraints, like "r". If there are no constraints, the reload phase won't do anything, and the insn will continue to use a MEM. The reload phase uses constraints rather than predicates because the constraints are more specific, and because they tell reload what to do. If reload checked the predicate, and the predicate failed, reload would have no idea what to do. Constraints are associated with specific register classes, as well as general constraints like "m" or "g". When reload sees a constraint which is a register class and an operand which is not in a register, or is in a register in a class which does not match the constraint, then reload finds a register in that class, spilling if necessary, and introduces instructions to move the operand into an appropriate register. Ian
