RE: GCC 4.1.0 Released
When -mtune=generic was added, it was expected that it would go into the 4.2 GCC release, since it clearly missed the 4.1 window for new features. As desirable for both AMD and Intel that the new behavior be propagated, I feel like Mark that it should wait for GCC 4.2, since it clearly is a new feature. However, if it does go in, it will be for the good, but I'm not pressing for it. Note, in this case, I am not officially speaking for AMD (though I have taken part in discussions on our side about adding the generic tuning feature). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Mitchell Sent: Wednesday, March 01, 2006 8:22 PM To: H. J. Lu Cc: Steven Bosscher; [EMAIL PROTECTED]; Richard Guenther; gcc@gcc.gnu.org Subject: Re: GCC 4.1.0 Released H. J. Lu wrote: You are comparing apply with orange. If a user uses -O2, he/she will see much more than that. We can argue about that, but I don't think so. I'm comparing a user can achieve without the patch with the performance they can achieve with the patch. On all chips, for all time, users have been expected to specify their target CPU in order to get good performance. It's swell that GCC 4.2 will work better by default on IA32, but that's not a compelling argument for a backport. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
RE: GCC 4.1.0 Released
Florian, * H. J. Lu: Here are diffs of SPEC CPU 2K between before and after with gcc 4.1 using -O2 -ffast-math on Nocona: And what about Opterons? IOW, how generic is the optimization? The generic code generation should cost a small compromise in performance relative to native code generation (e.g., -mtune=opteron on Opteron), but without affecting performance significantly on other processors (e.g., -mtune=nocona on Opteron). The goal of -mtune=generic is that it's better than the latter case albeit slightly slower than the former case. And, yes, AMD co-developped the -mtune=generic patch. HTH -- ___ Evandro Menezes AMD Austin, TX
Re: GCC 4.1.0 Released
* H. J. Lu: Here are diffs of SPEC CPU 2K between before and after with gcc 4.1 using -O2 -ffast-math on Nocona: And what about Opterons? IOW, how generic is the optimization?
Re: GCC 4.1.0 Released
On 2006-03-01 14:51:45 -0800, H. J. Lu wrote: Here are diffs of -O2 -mtune=nocona -ffast-math vs -O2 -mtune=generic -ffast-math on Nocona: [...] Optimization is much less important than correct results. From this point of view, I don't think that using an option known to produce incorrect results (-ffast-math) is a good idea to decide whether a patch should be applied or not (without mentioning the other reasons given in the thread...). -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Re: GCC 4.1.0 Released
Roman Belenov wrote: David Edelsohn [EMAIL PROTECTED] writes: Upgrading GNU tar to 1.15.1 fixed the problem for me. So what is the actual requirement - 1.14 or 1.14 or above ? The latter. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
re: GCC 4.1.0 Released
Mark wrote: 1. GNU TAR 1.14 is required to unpack the source releases. Other versions of tar are likely to report errors or silently unpack the file incorrectly. Now hold on there, bubaloo. I thought the warnings from older versions of tar were benign. The warnings I'm seeing from tar-1.13.19 are tar: pax_global_header: Unknown file type 'g', extracted as normal file Searching for this error message, I find a quote from Linus Torvalds, (http://lkml.org/lkml/2005/6/18/5): Yes, git creates tar-archives that use the extended pax headers, and I think you need tar-1.14 to fully understand them. They should not hurt (apart from the warning) on older versions of tar. The extended header just contains a hidden comment record that tells the git commit ID that was used to generate the tar-tree. Because it's extracted as a regular file (instead of tar knowing that it's a comment header), you will now have a file called pax_global_header that has the contents 52 comment=9ee1c939d1cb936b1f98e8d81aeffab57bae46ab in it (where 9ee1c939d1cb936b1f98e8d81aeffab57bae46ab is the git SHA1 name of the Linux-2.6.12 commit). So it's not entirely harmless in that it causes a bogus file to be created, but it's not like it's a huge problem either, and that bogus file actually does contain real information (although it's not useful unless you're a git user). So perhaps the release notes should say 1. GNU TAR 1.14 is recommended to unpack the source releases. Other versions of tar may issue the warning tar: pax_global_header: Unknown file type 'g', extracted as normal file and/or silently create spurious files named 'pax_global_header'. These are artifacts reflecting the fact that the tarballs were created with git. Or something like that. Or is tar-1.14 really required? That would be highly annoying. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: GCC 4.1.0 Released
On 3/1/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote: 1. GNU TAR 1.14 is required to unpack the source releases. Other versions of tar are likely to report errors or silently unpack the file incorrectly. The problem has nothing to do with warnings from tar, which are neither errors nor silent failures. I believe a file either got skipped or unpacked with the wrong name. Egads. Can you point me to more info? I've been building with older versions of tar without any problem beyond the warnings. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 10:10:39AM -0800, Dan Kegel wrote: On 3/1/06, Daniel Jacobowitz [EMAIL PROTECTED] wrote: 1. GNU TAR 1.14 is required to unpack the source releases. Other versions of tar are likely to report errors or silently unpack the file incorrectly. The problem has nothing to do with warnings from tar, which are neither errors nor silent failures. I believe a file either got skipped or unpacked with the wrong name. Egads. Can you point me to more info? I've been building with older versions of tar without any problem beyond the warnings. I don't know where the report was. I think it was on this list in the last week or two. -- Daniel Jacobowitz CodeSourcery
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 08:24:18AM -0800, Mark Mitchell wrote: 1. GNU TAR 1.14 is required to unpack the source releases. Other versions of tar are likely to report errors or silently unpack the file incorrectly. Red Hat EL3 comes with tar 1.13.25 (though since the RPM package on the machine I used is 1.13.25-13, it's likely that Red Hat has applied some fixes to get up to rev 13). I unpacked gcc-4.1.0.tar.bz2 with both the Red Hat tar package and with the newest FSF tar (version 1.15.1). There were no warning messages, and diff -r reports that the two tars produce identical files. What is the basis for the report that older tars don't work?
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 08:24:18AM -0800, Mark Mitchell wrote: GCC 4.1.0 has been released. It is great. Is 4.1 branch open now? I'd like to back port the x86 -mtune=generic patch: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01436.html to 4.1.1. Thanks. H.J.
Re: GCC 4.1.0 Released
On Wednesday 01 March 2006 21:14, H. J. Lu wrote: Is 4.1 branch open now? I'd like to back port the x86 -mtune=generic patch: Isn't that totally inappropriate for a release branch? Gr. Steven
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 09:42:19PM +0100, Richard Guenther wrote: On 3/1/06, H. J. Lu [EMAIL PROTECTED] wrote: On Wed, Mar 01, 2006 at 09:21:19PM +0100, Steven Bosscher wrote: On Wednesday 01 March 2006 21:14, H. J. Lu wrote: Is 4.1 branch open now? I'd like to back port the x86 -mtune=generic patch: Isn't that totally inappropriate for a release branch? What is it inappropriate about? It's a new feature and not a fix for a regression. - totally inappropriate. It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2. I can't recommond gcc 4.1 to most people using IA32/x86-64. This change is specific to the IA32/x86-64 backend and won't affect any other targets. H.J.
Re: GCC 4.1.0 Released
On Wednesday 01 March 2006 21:49, H. J. Lu wrote: It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2. Oh, really? Where are the numbers you have to support this, may I say, unlikely claim? It seemed to me that the patch you propose does not help that much at all. At least, if it does then that was not clear from the initial postings for the trunk, where except for Nocona it was a wash. I can't recommond gcc 4.1 to most people using IA32/x86-64. You'd have to recommend ICC anyway :-P GCC 4.1 works a lot better for me on my AMD64 box than any previous GCC (except for the usual compile time regressions). so I _would_ recommend it to, well, everyone! This change is specific to the IA32/x86-64 backend and won't affect any other targets. Hmm... I thought Mark's message was pretty clear: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00060.html To quote: The GCC 4.1 branch is now open, under the usual branch rules: fixes for regressions only. Those are just the same rules that gcc has had for release branches since forever. I think everyone understands that you, with an Intel cap on, have to care more about Nocona than about GCC stability in general. But that doesn't mean that the rules that apply to everyone else should not apply to you. Your patch implements a new feature. New features usually don't fix regression. So your patch should be considered for GCC 4.1 IMHO. Gr. Steven
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote: On Wednesday 01 March 2006 21:49, H. J. Lu wrote: It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2. Oh, really? Where are the numbers you have to support this, may I say, unlikely claim? Here are diffs of SPEC CPU 2K between before and after with gcc 4.1 using -O2 -ffast-math on Nocona: 164.gzip2.50% 175.vpr 1.55% 176.gcc -0.33% 181.mcf 0.85% 186.crafty 0.06% 197.parser 0.62% 252.eon 8.58% 253.perlbmk 2.75% 254.gap 0.66% 255.vortex 7.59% 256.bzip2 4.45% 300.twolf 21.11% SPECint_base20004.04% 168.wupwise 39.10% 171.swim38.88% 172.mgrid 61.64% 173.applu 37.62% 177.mesa3.12% 178.galgel 27.13% 179.art 18.98% 183.equake 26.67% 187.facerec 0.35% 188.ammp36.78% 189.lucas 3.52% 191.fma3d 42.71% 200.sixtrack116.13% 301.apsi32.75% SPECfp_base2000 32.18% This change is specific to the IA32/x86-64 backend and won't affect any other targets. Hmm... I thought Mark's message was pretty clear: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00060.html To quote: The GCC 4.1 branch is now open, under the usual branch rules: fixes for regressions only. The exception is the rule. We have done so on gcc 3.4 branch: http://gcc.gnu.org/ml/gcc-cvs/2004-04/msg00775.html H.J.
Re: GCC 4.1.0 Released
On 3/1/06, H. J. Lu [EMAIL PROTECTED] wrote: On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote: On Wednesday 01 March 2006 21:49, H. J. Lu wrote: It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2. Oh, really? Where are the numbers you have to support this, may I say, unlikely claim? Here are diffs of SPEC CPU 2K between before and after with gcc 4.1 using -O2 -ffast-math on Nocona: Please post more meaningful numbers, like a comparison to -mtune=nocona, not whatever you used (the old default is i386 or i586). Richard.
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 10:43:40PM +0100, Richard Guenther wrote: On 3/1/06, H. J. Lu [EMAIL PROTECTED] wrote: On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote: On Wednesday 01 March 2006 21:49, H. J. Lu wrote: It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2. Oh, really? Where are the numbers you have to support this, may I say, unlikely claim? Here are diffs of SPEC CPU 2K between before and after with gcc 4.1 using -O2 -ffast-math on Nocona: Please post more meaningful numbers, like a comparison to -mtune=nocona, not whatever you used (the old default is i386 or i586). That is the whole point: I'd like to back port the -mtune=generic change to 4.1 branch. There are so many different IA32/x86-64 processors. The default optimization is more useful than -mtune=xxx. The new default (-mtune=generic) is much better than the old one for the current IA32/x86-64 processors. H.J.
Re: GCC 4.1.0 Released
That is the whole point: I'd like to back port the -mtune=generic change to 4.1 branch. There are so many different IA32/x86-64 processors. The default optimization is more useful than -mtune=xxx. The new default (-mtune=generic) is much better than the old one for the current IA32/x86-64 processors. You are missing the whole point about a release branch though. Yes there have been exceptions in the past to the policy but they should not be taken for granted. GCC is growing up as a real professional compiler which means no new features in minor revisions aka bug fixes releases. Yes there are a few exception but others and I feel this is not an example of one of the exception at least at this point in time. One of the reasons why people are against this patch is because one it touches the most popular target which means it could unstablize it. Two there are still known regressions with this patch. PR 26146 for an example. Thanks, Andrew Pinski
Re: GCC 4.1.0 Released
H. J. Lu wrote: Here are diffs of SPEC CPU 2K between before and after with gcc 4.1 using -O2 -ffast-math on Nocona: Steven's right; this is clearly a new feature. HJ's also right; we've made exceptions before. Like Steven, I would like to see what the difference is between -mtune=generic and -mtune=nocona. If there is not much difference, then that's an argument against a backport; just tell users to add -mtune=nocona. It's up to architecture maintainers to get defaults set well for their systems in advance of releases. I'd also like to hear from our IA32 maintainers. I'm going to set the bar here relatively high on several grounds: 1. I've just been reminded, once again, of the dangers of safe patches; c.f., the Alpha OSF threads patch for 4.1.0 which turned out to break NetBSD. (Fortunately, that configuration was badly enough broken before the patch that I don't think any terribly serious damage was done; 4.1.1 will presumably have Roger's patches which fix all of that.) I'm in no way criticizing Roger, and it was I who approved the patch; however, the key point is that danger lurks everywhere. 2. IA32 is one of, if not the, most popular GCC architectures. On the one hand, yes, that argues for making it perform well there; on the other, it also argues very strongly for stability. Effectively changing the default optimization behavior on a release branch substantially invalidates previous validation done on that branch. 3. Slippery slope. Every time I bend the rules, I get criticized for bending the rules, and I get besieged by people who want other rules bent, and then I get criticized for bending rule X for person A, but not rule Y for person B. I've got a thick skin, and I feel omfortable exercising my own non-algorithmic discretion to do what I believe is the right thing. But, I will also be sensitive to the developer community's desire for predictability of decision-making. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1.0 Released
Joe Buck wrote: What is the basis for the report that older tars don't work? This posting: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01861.html It may certainly be the case that some patched version of tar on RHEL works fine (one would indeed hope and expect that distributors are adding value in precisely such ways!) but it's better to be safe than sorry, and I didn't have the resources to verify exactly which versions might or might not work. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 02:24:58PM -0800, Mark Mitchell wrote: Joe Buck wrote: What is the basis for the report that older tars don't work? This posting: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01861.html It may certainly be the case that some patched version of tar on RHEL works fine (one would indeed hope and expect that distributors are adding value in precisely such ways!) but it's better to be safe than sorry, and I didn't have the resources to verify exactly which versions might or might not work. I just repeated the test with the FSF 1.13 release. Again, no complaints and diff -r matches what 1.15.1 gives. I suppose I could repeat the test with the gcc 4.1 RC1 tarball, where David E. saw a problem.
Re: GCC 4.1.0 Released
On Wednesday 01 March 2006 22:06, Steven Bosscher wrote: Your patch implements a new feature. New features usually don't fix regression. So your patch should be considered for GCC 4.1 IMHO. I mean should not, obviously. Gr. Steven
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 02:19:47PM -0800, Mark Mitchell wrote: H. J. Lu wrote: Here are diffs of SPEC CPU 2K between before and after with gcc 4.1 using -O2 -ffast-math on Nocona: Steven's right; this is clearly a new feature. HJ's also right; we've made exceptions before. Like Steven, I would like to see what the difference is between -mtune=generic and -mtune=nocona. If there is not much difference, then Here are diffs of -O2 -mtune=nocona -ffast-math vs -O2 -mtune=generic -ffast-math on Nocona: 164.gzip1.30% 175.vpr -0.29% 176.gcc -4.04% 181.mcf 0.74% 186.crafty 1.65% 197.parser -0.10% 252.eon -0.38% 253.perlbmk 5.25% 254.gap 0.93% 255.vortex 1.54% 256.bzip2 0.72% 300.twolf 9.70% SPECint_base20001.31% 168.wupwise 2.49% 171.swim-0.55% 172.mgrid 6.46% 173.applu 0.65% 177.mesa2.56% 178.galgel 0.14% 179.art 1.79% 183.equake 0.79% 187.facerec -0.07% 188.ammp4.86% 189.lucas 1.21% 191.fma3d 1.08% 200.sixtrack0.00% 301.apsi1.21% SPECfp_base2000 1.62% I'd like to see the default -O2 generate decent code for Nocona. It is independent of improviong -mtune=nocona for Nocona. that's an argument against a backport; just tell users to add -mtune=nocona. It's up to architecture maintainers to get defaults set well for their systems in advance of releases. I'd also like to hear from our IA32 maintainers. My IA32 numbers show that -mtune=generic gives the better SPEC CPU 2K -O2 numbers on Dothan, Yonah, Northwood and Yonah than the previous -O2 option. 2. IA32 is one of, if not the, most popular GCC architectures. On the one hand, yes, that argues for making it perform well there; on the other, it also argues very strongly for stability. Effectively changing the default optimization behavior on a release branch substantially invalidates previous validation done on that branch. The last thing I want to see is the instability on IA32. I can't guarantee it won't happen. But I will do my best to fix it if the backported patch is the cause. H.J.
Re: GCC 4.1.0 Released
On Wednesday 01 March 2006 23:51, H. J. Lu wrote: I'd like to see the default -O2 generate decent code for Nocona. But then, you did so too months ago, when the GCC 4.1 development cycle was still in stage1/stage2. Nocona has been around for a very long time already (I have a Prescott-T myself which is going to celebrate its second birthday soon), so you've had plenty of time to make -O2 produce decent code for Nocona, really. You just didn't do that. What's that what my professor always said... Ah yes, Poor planning by you does not constitute an emergency for me. The last thing I want to see is the instability on IA32. I can't guarantee it won't happen. But I will do my best to fix it if the backported patch is the cause. You still have to fix a few open regressions against 4.2 caused by this patch, and 4.2 has not even received as much testing as 4.1 so it is almost certain that there are going to be more bugs that your patch causes or will expose. Gr. Steven
Re: GCC 4.1.0 Released
H. J. Lu wrote: Here are diffs of -O2 -mtune=nocona -ffast-math vs -O2 -mtune=generic -ffast-math on Nocona: A 1.5% performance improvement, while certainly significant for some users, is not worth taking any serious risks on a release branch. The purpose of bug-fix releases on the release branch is to correct regressions. The goal is that (a) any happy user of 4.1.0 can upgrade to 4.1.1, and (b) that users presently stuck with older releases because of regressions in 4.1.0 can upgrade to 4.1.1. In other words, the goal is to shift the userbase forward to 4.1.x -- not to improve the experience of people already using 4.1.0. My IA32 numbers show that -mtune=generic gives the better SPEC CPU 2K -O2 numbers on Dothan, Yonah, Northwood and Yonah than the previous -O2 option. Yes, I understand. I hope that 4.2 will in fact have quite a few improvements on quite a few architectures of at least this magnitude! However, we're not going to backport them all to 4.1. The last thing I want to see is the instability on IA32. I can't guarantee it won't happen. But I will do my best to fix it if the backported patch is the cause. The first step is to address regressions on the mainline. I have not myself verified the claim, but there has been a suggestion that there is at least one open regression due to the patch. If there are any known regressions from the patch, it's certainly not eligible for a backport. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 03:06:46PM -0800, Mark Mitchell wrote: H. J. Lu wrote: Here are diffs of -O2 -mtune=nocona -ffast-math vs -O2 -mtune=generic -ffast-math on Nocona: A 1.5% performance improvement, while certainly significant for some users, is not worth taking any serious risks on a release branch. The You are comparing apply with orange. If a user uses -O2, he/she will see much more than that. The first step is to address regressions on the mainline. I have not myself verified the claim, but there has been a suggestion that there is at least one open regression due to the patch. If there are any known regressions from the patch, it's certainly not eligible for a backport. I am only aware of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26146 and I have a patch. BTW, I don't think it is a real regression, just a latent bug. I doubt # configure i[456]86-pc-solaris2.10 # onfigure --with-cpu=i[3456]86 i386-pc-solaris2.10 had ever worked. In any case, please CC me any -mtune=generic patch. H.J.
Re: GCC 4.1.0 Released
On Wed, Mar 01, 2006 at 04:05:16PM -0800, H. J. Lu wrote: On Wed, Mar 01, 2006 at 03:06:46PM -0800, Mark Mitchell wrote: H. J. Lu wrote: Here are diffs of -O2 -mtune=nocona -ffast-math vs -O2 -mtune=generic -ffast-math on Nocona: A 1.5% performance improvement, while certainly significant for some users, is not worth taking any serious risks on a release branch. The You are comparing apply with orange. If a user uses -O2, he/she will see much more than that. I meant to say comparing apple with orange. The first step is to address regressions on the mainline. I have not myself verified the claim, but there has been a suggestion that there is at least one open regression due to the patch. If there are any known regressions from the patch, it's certainly not eligible for a backport. I am only aware of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26146 and I have a patch. BTW, I don't think it is a real regression, just a latent bug. I doubt # configure i[456]86-pc-solaris2.10 # onfigure --with-cpu=i[3456]86 i386-pc-solaris2.10 had ever worked. In any case, please CC me any -mtune=generic patch. Let me rephrase, please CC me any -mtune=generic related bugs. H.J.
Re: GCC 4.1.0 Released
H. J. Lu wrote: You are comparing apply with orange. If a user uses -O2, he/she will see much more than that. We can argue about that, but I don't think so. I'm comparing a user can achieve without the patch with the performance they can achieve with the patch. On all chips, for all time, users have been expected to specify their target CPU in order to get good performance. It's swell that GCC 4.2 will work better by default on IA32, but that's not a compelling argument for a backport. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1.0 Released
On 03/01/06 17:51, H. J. Lu wrote: SPECint_base2000 1.31% SPECfp_base2000 1.62% All these numbers are within the usual SPEC noise. Not Worth It.
Re: GCC 4.1.0 Released
Dan Kegel writes: The problem has nothing to do with warnings from tar, which are neither errors nor silent failures. I believe a file either got skipped or unpacked with the wrong name. Dan Egads. Can you point me to more info? I've been building with older Dan versions of tar without any problem beyond the warnings. The problem I experienced was a missing last character of some very long filenames when untarring. Some C++ header files with .hpp prefix were untarred as .hp. Listing the files in the tarball displayed the same filename truncation. Upgrading GNU tar to 1.15.1 fixed the problem for me. David
Re: GCC 4.1.0 Released
David Edelsohn [EMAIL PROTECTED] writes: Upgrading GNU tar to 1.15.1 fixed the problem for me. So what is the actual requirement - 1.14 or 1.14 or above ? -- With regards, Roman.
