Re: Rant about ChangeLog entries and commit messages
On Sat, 2007-12-15 at 20:54 -0200, Alexandre Oliva wrote: > On Dec 3, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote: > > > In my view, ChangeLog is mostly "write-only" from a developer's > > perspective. It's a document that the GNU project requires us to > produce > > for > > ... a good example of compliance with the GPL: > > 5. Conveying Modified Source Versions. > > a) The work must carry prominent notices stating that you modified > it, and giving a relevant date. > (Minor quibble) As copyright owner of GCC, the FSF is not bound by the conditions of the licence it grants in the same way as licencees are bound. So I don't think this provision in itself would mandate that those who have copyright assignments to the FSF record their changes. I don't hear anyone arguing that people should not record what they changes and when. The question is whether it is sufficient. I just started using git locally, and I keep thinking it would be really great to have something like "git blame" for gcc. The command "git blame" gives you a listing of who changed each line of the file and when, and also gives the commit id. From that all can be revealed. > > FWIW, I've used ChangeLogs to find problems a number of times in my 14 > years of work in GCC, and I find them very useful. When I need more > details, web-searching for the author of the patch and some relevant > keywords in the ChangeLog will often point at the relevant e-mail, so > burdening people with adding a direct URL seems pointless to me. It's > pessimizing the common case for a small optimization in far less > common cases. > This may possibly work when the mailing list entries exist and are accessible. However they are only available AFAIK from 1998. GCC has been going for 2-3 times as long as that. And there is at least one significant gap: February 2004 up to and including this message http://gcc.gnu.org/ml/gcc-patches/2004-02/msg02288.html. In my experience, when documentation is not stored with the source code, it often gets lost. When a person is offline the mailing list htmls are not available. I have an idea to resolve this that I am working on... more in due course if it comes to anything. Tim Josling
Re: Rant about ChangeLog entries and commit messages
On Dec 25, 2007 1:57 PM, Tim Josling <[EMAIL PROTECTED]> wrote: > On Sat, 2007-12-15 at 20:54 -0200, Alexandre Oliva wrote: > > On Dec 3, 2007, [EMAIL PROTECTED] (Richard Kenner) wrote: > > > > > In my view, ChangeLog is mostly "write-only" from a developer's > > > perspective. It's a document that the GNU project requires us to > > produce > > > for > > > > ... a good example of compliance with the GPL: > > > > 5. Conveying Modified Source Versions. > > > > a) The work must carry prominent notices stating that you modified > > it, and giving a relevant date. > > > > (Minor quibble) As copyright owner of GCC, the FSF is not bound by the > conditions of the licence it grants in the same way as licencees are > bound. So I don't think this provision in itself would mandate that > those who have copyright assignments to the FSF record their changes. > > I don't hear anyone arguing that people should not record what they > changes and when. The question is whether it is sufficient. > > I just started using git locally, and I keep thinking it would be really > great to have something like "git blame" for gcc. svn already has blame :)
Re: [lto] preliminary SPECint benchmark numbers
Here is mine benchmarking of the current LTO branch on 2.66Ghz Core2 under RHEL 5 in 64- and 32-bits mode. The vortex violates type aliasing rules, therefore it should be compiled with -fno-strict-aliasing. Perlbmk crashed in tree.c::build2_stat in 32-bits mode when LTO used. LTO currently generates wrong code for 176.gcc. I've also checked Specfp2000 benchmarks written in C. In brief, o the code size (text segment) with LTO is much smaller (2.7% and 2.4% for SpecInt and 0.16% and 0.6% for SpecFp correspondingly in 64- and 32-bit mode). That is very promising. o the compilation is 2 times slower with LTO. o The generated code is slower 3.6% and 2.2% for SPECint2000 and SpecFp2000 in 64-bit mode. It is also 6.7% slower for SpecInt2000 in 32-bit mode. But SpecFp2000 in 32-bit mode code generated with LTO is 20% faster! It is because art is almost 2.5 times faster with LTO. The more details can be found below. --64-bit mode base: -O2 -mtune=generic peak: -O2 -mtune=generic -flto base peak 164.gzip 1363* 1340* 175.vpr 1600* 1571* 176.gcc X X 181.mcf 1658* 1531* 186.crafty2576* 2569* 197.parser1269* 1158* 252.eon X X 253.perlbmk 2546* 2373* 254.gap 1987* 1965* 255.vortex2259* 2208* 256.bzip2 1874* 1721* 300.twolf 2548* 2627* SPECin2000 mean 1910 1841-3.6% Compilation time of SPECInt2000 (except for eon and gcc): base: 65.02user 6.25system 1:15.41elapsed 94%CPU peak: 130.62user 9.68system 2:45.20elapsed 84%CPU basepeak 168.wupwiseX X 171.swim X X 172.mgrid X X 173.applu X X 177.mesa 2426* 2314* 178.galgel X X 179.art6276* 5519* 183.equake 1826* 1808* 187.facerecX X 188.ammp 1770* 1666* 189.lucas X X 191.fma3d X X 200.sixtrack X X 301.apsi X X SPECfp_base2000 26492491-2.2% Compilation time of SPECFp2000 (only mesa, art, equake ammp): 17.32user 1.74system 0:20.42elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k 35.52user 2.88system 0:42.86elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k text segment: CINT2000- -6.144% 38962 36568 164.gzip -3.500% 147426 142266 175.vpr -4.313% 12613 12069 181.mcf -2.544% 172319 167935 186.crafty -5.566% 108797 102741 197.parser -5.436% 575443 544160 253.perlbmk -5.214% 494375 468599 254.gap -5.617% 556589 525325 255.vortex -3.209% 32532 31488 256.bzip2 1.132% 198639 200887 300.twolf Average = -2.69418% CFP2000- -5.093% 522117 495526 177.mesa 2.542% 16362 16778 179.art 2.745% 19778 20321 183.equake -2.919% 142532 138372 188.ammp Average = -0.160212% --32-bit mode base: -m32 -O2 -mtune=generic peak: -m32 -O2 -mtune=generic -flto basepeak 164.gzip 1261*1125* 175.vpr 1603*1483* 176.gcc XX 181.mcf 3057*2801* 186.crafty 1764*1691* 197.parser 1397*1224* 252.eon XX 253.perlbmk XX 254.gap 1981*1778* 255.vortex 2013*1914* 256.bzip21666*1580* 300.twolf2376*2484* SPECint2000mean 1839 1716 -6.7% Compilation time of SPECInt2000 (except for eon, gcc, and perlbmk): 49.36user 5.13system 0:58.57elapsed 93%CPU (0avgtext+0avgdata 0maxresident)k 99.32user 7.90system 1:56.63elapsed 91%CPU (0avgtext+0avgdata 0maxresident)k basepeak 168.wupwise X X 171.swim X X 172.mgridX X 173.appluX X 177.mesa 1362* 1325* 178.galgel X X 179.art 2786* 6197* 183.equake 1784* 1772* 187.facerec X X 188.ammp 1144* 1102* 189.lucasX X 191.fma3dX X 200.sixtrack X X 301.apsi X X SPECfp2000 mean 16682001 +20% Compilation time of SPECFp2000 (only m
Re: [lto] preliminary SPECint benchmark numbers
On Dec 25, 2007, at 5:02 PM, Vladimir N. Makarov wrote: Here is mine benchmarking of the current LTO branch on 2.66Ghz Core2 under RHEL 5 in 64- and 32-bits mode. The vortex violates type aliasing rules, therefore it should be compiled with -fno-strict-aliasing. Perlbmk crashed in tree.c::build2_stat in 32-bits mode when LTO used. LTO currently generates wrong code for 176.gcc. I've also checked Specfp2000 benchmarks written in C. In brief, o the code size (text segment) with LTO is much smaller (2.7% and 2.4% for SpecInt and 0.16% and 0.6% for SpecFp correspondingly in 64- and 32-bit mode). That is very promising. o the compilation is 2 times slower with LTO. o The generated code is slower 3.6% and 2.2% for SPECint2000 and SpecFp2000 in 64-bit mode. It is also 6.7% slower for SpecInt2000 in 32-bit mode. But SpecFp2000 in 32-bit mode code generated with LTO is 20% faster! It is because art is almost 2.5 times faster with LTO. Wow, nice numbers! Is it possible to compare this to -combine, or does -combine work anymore? In theory, lto and IMA should yield the same codegen, lto should just be usable with normal makefiles. -Chris
Re: Rant about ChangeLog entries and commit messages
> (Minor quibble) As copyright owner of GCC, the FSF is not bound by the > conditions of the licence it grants in the same way as licencees are > bound. So I don't think this provision in itself would mandate that > those who have copyright assignments to the FSF record their changes. I was hoping nobody would notice that. ;-) > I don't hear anyone arguing that people should not record what they > changes and when. The question is whether it is sufficient. I think we all agree that it isn't, but figuring out where and what to put elsewhere has been tricky.
Re: Rant about ChangeLog entries and commit messages
Richard Kenner wrote: (Minor quibble) As copyright owner of GCC, the FSF is not bound by the conditions of the licence it grants in the same way as licencees are bound. So I don't think this provision in itself would mandate that those who have copyright assignments to the FSF record their changes. I was hoping nobody would notice that. ;-) Actually I think this is wrong, the FSF holds the copyright by virtue of a copyright assignment which contains the guarantee that the software will be distributed under the GPL (at least that's my recollection of the assignment document).
Re: Rant about ChangeLog entries and commit messages
> >> (Minor quibble) As copyright owner of GCC, the FSF is not bound by the > >> conditions of the licence it grants in the same way as licencees are > >> bound. So I don't think this provision in itself would mandate that > >> those who have copyright assignments to the FSF record their changes. > > > > I was hoping nobody would notice that. ;-) > > > Actually I think this is wrong, the FSF holds the copyright by virtue of > a copyright assignment which contains the guarantee that the software > will be distributed under the GPL (at least that's my recollection of the > assignment document). That part's true, but the cited part of the GPL applies only to somebody who makes a *modification* to the work of the copyright holder and redistributes that work. Such a condition doesn't apply to the FSF, who *is* the copyright holder.
Re: Rant about ChangeLog entries and commit messages
On Dec 25, 2007, Tim Josling <[EMAIL PROTECTED]> wrote: > On Sat, 2007-12-15 at 20:54 -0200, Alexandre Oliva wrote: >> ... a good example of compliance with the GPL: >> 5. Conveying Modified Source Versions. >> >> a) The work must carry prominent notices stating that you modified >> it, and giving a relevant date. > (Minor quibble) As copyright owner of GCC, the FSF is not bound by the > conditions of the licence it grants in the same way as licencees are > bound. Of course. That's exactly why I wrote "good example". It wouldn't be nice if the FSF itself didn't set the example for others who modify the code to follow. On top of that, I believe whoever modifies the code and publishes the modification, even if just to contribute it to the FSF, is bound by the terms of the GPL, and terefore the code modification carry the required prominent notices. Of course the FSF, being copyright holder, could choose to throw them all away. > This may possibly work when the mailing list entries exist and are > accessible. True, off-line access to resources that are on-line only or even permanently inaccessible doesn't work. Been there, done that, it's a pain to deal with lack of information. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
How to describe a FMAC insn
Hi, Could someone give some hints of how to describe a FMAC (float mult and add) insn in machine description, it matches d = b*c+a, which is a four operands float instrution. With a glimp through the array optabs[] in genopinit.c, it seems no OP handler could match FMAC operation? And I found a function gen_add_mult() in loops.c, but it also seems not very helpful. And another my question is, the element of optabs[] are arrays indexed by machine code, for example, add_optab[] indexed by SI, DI, QI, FI machine mode, not by number of operands, it seems it only matches 3 operands add operation,if I want to add a four operands add operation, what should I do? Qing
Re: How to describe a FMAC insn
Qing Wei wrote: > Could someone give some hints of how to describe a FMAC (float mult and > add) insn in machine description, it matches d = b*c+a, which is a four > operands float instrution. There are plenty of examples in ia64.md and rs6000.md.
