Re: struggling with make inside GCC MELT
2012/1/10 Ian Lance Taylor : > Stamp files in make work like this: > > FILE: STAMP-FILE; @true > STAMP-FILE: DEPENDENCIES > commands to create FILE.tmp > move-if-change FILE.tmp FILE > touch $@ > > What this says is: if any of DEPENDENCIES change, then run the commands > to create FILE.tmp. The move-if-change shell script then compares > FILE.tmp and FILE; if they are different, it moves FILE.tmp to FILE, > updating the timestamp. If they are not different, FILE is left > unchanged, with the same timestamp. > > The effect is that anything which depends on FILE is only rebuilt if the > contents of FILE changes. Hmm, will it work to just write as FILE: DEPENDENCIES commands to create FILE.tmp move-if-change FILE.tmp FILE > Note that everything I show above is required. A naive approach would > omit the "; @true" but it is necessary. > > Ian Then what the role here "; @true" play? I'm still confused by the usage. Thanks for explanation. Mingjie
Re: struggling with make inside GCC MELT
On 11 January 2012 09:08, Mingjie Xing wrote: > 2012/1/10 Ian Lance Taylor : >> Stamp files in make work like this: >> >> FILE: STAMP-FILE; @true >> STAMP-FILE: DEPENDENCIES >> commands to create FILE.tmp >> move-if-change FILE.tmp FILE >> touch $@ >> >> What this says is: if any of DEPENDENCIES change, then run the commands >> to create FILE.tmp. The move-if-change shell script then compares >> FILE.tmp and FILE; if they are different, it moves FILE.tmp to FILE, >> updating the timestamp. If they are not different, FILE is left >> unchanged, with the same timestamp. >> >> The effect is that anything which depends on FILE is only rebuilt if the >> contents of FILE changes. > > Hmm, will it work to just write as > > FILE: DEPENDENCIES > commands to create FILE.tmp > move-if-change FILE.tmp FILE No, this isn't the same. With your rule above, if FILE is not replaced then its timestamp will not be updated, so every time you run make it will notice the dependencies have changed and recreate FILE.tmp, but not update FILE. That does lots of unnecessary work. Using the stampfile ensures you only generate FILE.tmp once, when the dependencies have first changed, then update the timestamp of the stampfile to mark FILE as up to date. >> Note that everything I show above is required. A naive approach would >> omit the "; @true" but it is necessary. >> >> Ian > > Then what the role here "; @true" play? I'm still confused by the usage. If you don't have a recipe for the FILE target then make might try to use an implicit recipe for the file type, so you need a "do nothing" recipe. 'true' is a shell command that does nothing and returns true. @ prevents the command being echoed. So "updating" the FILE target happens whenever the stampfile changes, but the recipe is a no-op. I'm not sure why "@true" is needed, as I think GNU make allows simply ";" for an empty recipe, maybe Ian can explain that part.
GCC mirror
Hello, I've just set up a new GCC mirror. Information is as follows: URL: http://www.netgull.com/gcc/ Frequency:once a day Location:San Jose, California, United States, North America Contact: ad...@netgull.com Please, add my GCC mirror to your mirror list; for any further clarification don't hesitate to contact me. Kind regards
Re: struggling with make inside GCC MELT
Jonathan Wakely writes: > I'm not sure why "@true" is needed, as I think GNU make allows simply > ";" for an empty recipe, maybe Ian can explain that part. The rules I described work for all versions of make. It's quite possible that with GNU make the "@true" is unnecessary. Ian
Re: struggling with make inside GCC MELT
On 11 January 2012 14:49, Ian Lance Taylor wrote: > Jonathan Wakely writes: > >> I'm not sure why "@true" is needed, as I think GNU make allows simply >> ";" for an empty recipe, maybe Ian can explain that part. > > The rules I described work for all versions of make. It's quite Thanks, I wondered if that was the reason. > possible that with GNU make the "@true" is unnecessary. Yep: http://www.gnu.org/software/make/manual/make.html#Empty-Recipes
Re: IRA issue with shuffle copies...
On 01/10/2012 12:55 PM, Peter Bergner wrote: On Tue, 2012-01-10 at 12:20 -0500, Vladimir Makarov wrote: Do we really need or want to create shuffle copies for insns that do not have a two operand constraint? Yes, I think so. As I remember I did some benchmarking and it gave some "order" in hard register assignments and improved code slightly (at least for SPEC2000) even for 3-ops insn architectures. Ok, I'll have someone on my team kick off this patch on ppc, but it would be nice if someone else could do the runs on x86/x86_64 or other cpus that might be affected that we don't have access to. There is no visible effect of the patch on SPECFP2000 performance and size (the size increase is only about 0.02%) for x86 and x86-64. The patch does worsen performance of SPECINT2000 on x86 (about 0.5%) and x86-64 (about 0.3%). x86-64 SPECINT200 code size increase is about 0.05% and there is no visible change in code size on x86. So I'd say the patch does not work for x86/x86-64.
Re: Go in gcc 4.7
> The Go language is closing in what we are calling Go version 1. This > will be a long-term stable release of Go, with no language or library > API changes. Go 1 is described here: > > https://docs.google.com/a/google.com/document/pub?id=1ny8uI-_BHrDCZv_zNBSthNKAMX_fR_0dc6epA6lztRE per that doc : The Go 1 release will be available in source and binary form for at least these platforms: FreeBSD 7+: amd64, 386 Linux 2.6+: amd64, 386, arm OS X (Snow Leopard + Lion): amd64, 386 Windows (2000 + later): amd64, 386 Therefore not on Solaris 10 or even a baseline Solaris 8 at all. That seems to be an issue given this : People should be able to write Go programs and expect that they will continue to compile and run without change, on a timescale of years. In keeping with the spirit of that vision what are the issues that block a port to Solaris today? Are there specific bugids I can look at ? Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: Go in gcc 4.7
Re "go" for Solaris I see this : http://code.google.com/p/gofrontend/issues/detail?id=6 Not sure what the status in the mainline is but I am willing to do a checkout and build and see what goes wrong. I have 4.6.2 well done on Sparc Solaris 8 and that seems like a good place to start. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: Go in gcc 4.7
Dennis Clarke writes: > The Go 1 release will be available in source and binary form for at least > these platforms: > > FreeBSD 7+: amd64, 386 > Linux 2.6+: amd64, 386, arm > OS X (Snow Leopard + Lion): amd64, 386 > Windows (2000 + later): amd64, 386 > > Therefore not on Solaris 10 or even a baseline Solaris 8 at all. > > That seems to be an issue given this : > > People should be able to write Go programs and expect > that they will continue to compile and run without > change, on a timescale of years. > > In keeping with the spirit of that vision what are the issues that block a > port to Solaris today? Are there specific bugids I can look at ? There are two different Go compilers. The list of systems on which the Go release will be available is for the other Go compiler, not gccgo. The gccgo compiler will be part of gcc releases as usual. The gccgo compiler has worked on Solaris in the past; current mainline is reportedly not working on Solaris, but I intend to fix that if nobody beats me to it. The other Go compiler has not been ported to Solaris. There is no major obstacle; somebody just had to do the work. The ports to FreeBSD and Windows were contributed from outside the core Go team, and I hope that someday somebody will contribute a Solaris port as well. > Re "go" for Solaris I see this : > > http://code.google.com/p/gofrontend/issues/detail?id=6 > > Not sure what the status in the mainline is but I am willing to do a checkout > and build and see what goes wrong. I have 4.6.2 well done on Sparc Solaris 8 > and that seems like a good place to start. That problem is fixed on mainline though not on the gccgo branch. If you are interested in working on gccgo on Solaris, which I think would be great, please work on mainline, not 4.6. Mainline is significantly different. Also Rainer Orth has done a great deal of work on Go on Solaris. Ian
Re: Difficulty matching machine description to target - any way to specify a minimum register width ?
Thanks Richard, The penny dropped when I read your comment about the % operator. item (2) send me back to the gcc internals document (again !) and I had the problem sorted in about half an hour. Thanks again, Paul. On 06/01/12 08:23, Richard Henderson wrote: On 01/05/2012 10:33 PM, Paul S wrote: (define_insn "addqi3i" [(set (match_operand:HI 0 "register_operand" "=r") (plus:HI (match_operand:HI 1 "register_operand" "%0") (sign_extend:HI (match_operand:QI 2 "memory_operand" "m"] Two things are wrong with this pattern: (1) % is incorrect because the operands are not the same mode. That's probably the root cause of all your failures. (2) Embedded operands are canonically first in commutative operands. So this should be [(set (match_operand:HI 0 "register_operand" "=r") (plus:HI (sign_extend:HI (match_operand:QI 1 "memory_operand" "m")) (match_operand:HI 2 "register_operand" "0")))] r~
