Re: 4.3.0-rc1 available
Hello Guillermo, * Guillermo Ballester Valor wrote on Fri, Feb 22, 2008 at 11:51:53PM CET: > El Friday 22 February 2008 20:21:36 Paweł Sikora escribió: > > > > as far i can see you're trying to build libgcj multilib (32/64-bits) > > on x86_64 only enviroment. please try --disable-libjava-multilib option > > with this (or equivalent) patch: > > http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/gcc4-libjava-multilib.patch > >?rev=HEAD > it seems that to build in openSUSE x86_64 we need hacks and patches. Well, I guess you can also globally --disable-multilib. For that, I don't think you need a patch. > I patched the source > > [EMAIL PROTECTED]:/tmp/gcc-4.3.0-RC-20080222> patch -p1 > libjava/configure.ac /tmp/downloads/multilib.patch > patching file libjava/configure.ac > Hunk #1 succeeded at 82 with fuzz 2 (offset -2 lines). > > And configured with the suggested option After the patch, you need to also regenerate the libjava/configure script. Do this by having Autoconf 2.59 installed (and found in $PATH), enter the libjava source directory, and run autoconf. > ../gcc-4.3.0-RC-20080222/configure --disable-libjava-multilib > > And again it failed in same place :( That's expected if the changes from libjava/configure.ac have not propagated into libjava/configure. I suppose a third way to fix the build would be to install a 32bit libjack. Hope that helps. Cheers, Ralf
Re: Rant about ChangeLog entries and commit messages - better to do something than just complain
On the principle that it's better to do something than just complain... I monitored the time I spent looking for the emails associated with a given patch and I found it takes high single digit minutes to find them. Sometimes you can't find them (which takes a lot longer). I do this a lot. I wrote a little proof-of-concept script to take the mailing list archives and the ChangeLog files and annotate the ChangeLog files with the URLs of the probable email containing the patch. Sample output is here (annotation of the current ChangeLog file). http://cobolforgcc.cvs.sourceforge.net/cobolforgcc/gcc/gcc/gcb/gcc_ChangeLog.txt?revision=1.1&view=markup Or http://tinyurl.com/2v824o Or http://preview.tinyurl.com/2v824o The program is here (not much internal documentation at all). Testing has been limited - in any case, with processing of text written by people, perfection is not possible. http://cobolforgcc.cvs.sourceforge.net/cobolforgcc/gcc/gcc/gcb/gcc_mailscan.rb?revision=1.1&view=markup Or http://tinyurl.com/2yem2u Or http://preview.tinyurl.com/2yem2u It runs in about 25 minutes on my system and uses a few hundred MB of storage. Things I learned: 1. There is a lot of data. It's a good thing Ruby 1.9 is a lot faster than Ruby 1.8. There are over 100 ChangeLog files in the GCC source, with over 600,000 lines in total. The gcc patches mailing list archives are over 2 GB in size, and take a considerable time to download. 2. Most patches to ChangeLog have an identifiable email in the archive. Things get spotty with branches in some cases, also as you go back in time, and also there is a large gap in the email archives from a while back. 3. I think this may be a useful thing. If a place could be found to put the 30MB of files I would be happy to maintain them on a weekly basis or so. Alternatively I could update the ChangeLog files themselves but I have reason to suspect that may not be popular. If nothing else happens I will keep it up-to-date for my own use. Tim Josling On Tue, 2007-12-04 at 08:05 -0500, Richard Kenner wrote: > > I didn't say you cannot or should not use these tools. But a good comment > > on a piece of code sure beats a good commit message, which must be looked > > at > > separately, and can be fragmented over multiple commits, etc. > > I don't see one as "beating" the other because they have very different > purposes. Sometimes you need one and sometimes you need the other. > > The purpose of COMMENTS is to help somebody understand the code as it > stands at some point in time. In most cases, that means saying WHAT the > code does and WHY (at some level) it does what it does. Once in a while, > it also means saying why it DOESN'T do something, for example, if it might > appear that there's a simpler way of doing what the code is doing now but > it doesn't work for some subtle reason. But it's NOT appropriate to put > into comments the historical remark that this code used to have a typo > which caused a miscompilation at some specific place. However, the commit > log IS the place for that sort of note. > > My view is that, in general, the comments are usually the most appropriate > place to put information about how the code currently works and the commit > log is generally the best place for information that contrasts how the code > currently works with how it used to work and provides the motivation for > making the change. But there are exceptions to both of those generalizations.
[patch,target] Fix ppc-darwin issue with long double intrinsics (PR25477)
Thanks to Andrew's code, Mike's and Geoff's comments in the PR, help
from Uros, Paolo and Jack, and Dominique's machine for testing, here
is a patch for fixing this PR. It has three independent parts, joined
together because I regtested them together:
1. the target part, in gcc/config/darwin* and gcc/config/rs6000,
that takes care of setting correct assembler names for the builtins,
if needed
2. the Fortran front-end part, bordering on obvious, that makes
cpow{f,,l} builtins instead of simply considering them library
functions (otherwise, they don't benefit from the patch above)
3. the Fortran testsuite part, splitting testing of ERF/ERFC from
large_real_kind_2.F90 into its separate test case, which still fails
on Darwin at -O0 because Apple's PowerPC erfl() and ercl() are plain
useless.
The patch was bootstrapped on powerpc-apple-darwin9.2.0 with C and
Fortran, and regtested with both -m32 and -m64 for these same
languages. OK for trunk? (I need a Darwin maintainer approval for the
target stuff, and a Fortran maintainer for Fortran parts.)
FX
--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
darwin-longdouble-4.ChangeLog
Description: Binary data
darwin-longdouble-4.diff
Description: Binary data
Re: [patch,target] Fix ppc-darwin issue with long double intrinsics (PR25477)
FX Coudert wrote:
Thanks to Andrew's code, Mike's and Geoff's comments in the PR, help
from Uros, Paolo and Jack, and Dominique's machine for testing, here is
a patch for fixing this PR. It has three independent parts, joined
together because I regtested them together:
1. the target part, in gcc/config/darwin* and gcc/config/rs6000, that
takes care of setting correct assembler names for the builtins, if needed
2. the Fortran front-end part, bordering on obvious, that makes
cpow{f,,l} builtins instead of simply considering them library functions
(otherwise, they don't benefit from the patch above)
3. the Fortran testsuite part, splitting testing of ERF/ERFC from
large_real_kind_2.F90 into its separate test case, which still fails on
Darwin at -O0 because Apple's PowerPC erfl() and ercl() are plain useless.
The patch was bootstrapped on powerpc-apple-darwin9.2.0 with C and
Fortran, and regtested with both -m32 and -m64 for these same languages.
OK for trunk? (I need a Darwin maintainer approval for the target stuff,
and a Fortran maintainer for Fortran parts.)
Fortran parts are OK. As an aside, this should also allow gfortran to
constant fold cpow* calls.
--
Janne Blomqvist
Re: Rant about ChangeLog entries and commit messages - better to do something than just complain
On Sat, 2008-02-23 at 20:52 +1100, Tim Josling wrote: > 3. I think this may be a useful thing. If a place could be found to put > the 30MB of files I would be happy to maintain them on a weekly basis or > so. Alternatively I could update the ChangeLog files themselves but I > have reason to suspect that may not be popular. > > If nothing else happens I will keep it up-to-date for my own use. Hi, The GCC Compile Farm can host your scripts, download/processing crontab and publish the results on a web site. Instructions on how to apply for a ssh account and misc information about the current farm status are here: http://gcc.gnu.org/wiki/CompileFarm I installed ruby from debian etch on gcc12: [EMAIL PROTECTED]:~$ ruby --version ruby 1.8.5 (2006-08-25) [x86_64-linux] If you need something else (missing packages, web page, etc...), the ticket tracker is on gna.org: https://gna.org/projects/gcc-cfarm/ Hope this helps, Laurent
Re: gcc 4.2.3 and MMX to mem move oddity
Prakash Punnoor wrote: Why is movaps (SSE, floating point data) instead of movdqa (SSE2. integer data) used as store? Bug or feature? Even with -O0 compiled it is used. Testing further: The -march=k8 seems to cause this. Leaving it out, movdqa is used, so I guess it is a feature. This is a feature, X86_TUNE_SSE_TYPELESS_STORES. It is faster on K8. Regarding MMX stuff, I have just committed the patch to 4.4 that should fix your (and similar) problems. Unfortunatelly, it won't be backported, as this is kind of tricky register allocator fine-tuning. Uros.
Re: Rant about ChangeLog entries and commit messages - better to do something than just complain
On Sat, Feb 23, 2008 at 08:52:41PM +1100, Tim Josling wrote: > I wrote a little proof-of-concept script to take the mailing list > archives and the ChangeLog files and annotate the ChangeLog files with > the URLs of the probable email containing the patch. This is really awesome. Thank you! I hope we can get these hosted and maybe hyperlinked somewhere on a permanent basis. -- Daniel Jacobowitz CodeSourcery
What kernel, glibc version and/or configure flags for clean testsuite results on i686/x86_64?
So I'm noticing I get several failures on i686-unknown-linux-gnu and x86_64-unknown-linux-gnu that some other people aren't seeing. On x86_64 I get lots of failures from libmudflap. http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01577.html These results are don't have them: http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01569.html On i686 I get errors from gcc.dg/vect/vect-117.c on mainline and 4.3: http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01579.html I also gets lots of mudflap errors again. On i686 on the 4.2 branch, I get gcc.target/i386/sse-18.c: http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01527.html Plus more mudflap and a few libffi errors: I'm wondering if there is a certain patch level for the kernel, glibc that I need, or certain configure flags are necessary. On i686 I get this from uname -a: Linux gcc03 2.6.12-10-686-smp #1 SMP Fri Nov 18 12:27:41 UTC 2005 i686 GNU/Linux on x86_64 I get: Linux gcc12 2.6.18-4-vserver-amd64 #1 SMP Fri May 4 01:21:52 UTC 2007 x86_64 GNU/Linux Any help would be appreciated. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Rant about ChangeLog entries and commit messages - better to do something than just complain
On Sat, Feb 23, 2008 at 10:53:53AM -0500, Daniel Jacobowitz wrote: > On Sat, Feb 23, 2008 at 08:52:41PM +1100, Tim Josling wrote: > > I wrote a little proof-of-concept script to take the mailing list > > archives and the ChangeLog files and annotate the ChangeLog files with > > the URLs of the probable email containing the patch. > > This is really awesome. Thank you! I hope we can get these hosted > and maybe hyperlinked somewhere on a permanent basis. Agreed. Even nicer would be if the ChangeLogs in the repository were just updated with this. -Andi
Re: What kernel, glibc version and/or configure flags for clean testsuite results on i686/x86_64?
"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes: > So I'm noticing I get several failures on i686-unknown-linux-gnu and > x86_64-unknown-linux-gnu that some other people aren't seeing. > > On x86_64 I get lots of failures from libmudflap. > http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01577.html > > These results are don't have them: > http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01569.html This is my openSUSE 10.3 system with kernel 2.6.22 and glibc 2.6.1. configure options are shown at the end of the report. Andreas -- Andreas Jaeger, Director Platform / openSUSE, [EMAIL PROTECTED] SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpu6kASuHJT2.pgp Description: PGP signature
Re: 4.3.0-rc1 available
Hello Ralf, El Saturday 23 February 2008 08:33:34 Ralf Wildenhues escribió: > Hello Guillermo, > > * Guillermo Ballester Valor wrote on Fri, Feb 22, 2008 at 11:51:53PM CET: > > El Friday 22 February 2008 20:21:36 Paweł Sikora escribió: > > > as far i can see you're trying to build libgcj multilib (32/64-bits) > > > on x86_64 only enviroment. please try --disable-libjava-multilib option > > > with this (or equivalent) patch: > > > http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/gcc4-libjava-multilib.p > > >atch ?rev=HEAD > > > > it seems that to build in openSUSE x86_64 we need hacks and patches. > > Well, I guess you can also globally --disable-multilib. For that, I > don't think you need a patch. I tried it, and works! > > > I patched the source > > > > [EMAIL PROTECTED]:/tmp/gcc-4.3.0-RC-20080222> patch -p1 > > libjava/configure.ac /tmp/downloads/multilib.patch > > patching file libjava/configure.ac > > Hunk #1 succeeded at 82 with fuzz 2 (offset -2 lines). > > > > And configured with the suggested option > > After the patch, you need to also regenerate the libjava/configure > script. Do this by having Autoconf 2.59 installed (and found in $PATH), > enter the libjava source directory, and run autoconf. You are right, I guess I was needing more coffee. :-) > > > ../gcc-4.3.0-RC-20080222/configure --disable-libjava-multilib > > > > And again it failed in same place :( > > That's expected if the changes from libjava/configure.ac have not > propagated into libjava/configure. > > I suppose a third way to fix the build would be to install a 32bit > libjack. > > Hope that helps. Thank you very much!. Have a nice weekend Guillermo > > Cheers, > Ralf -- Guillermo Ballester Valor [EMAIL PROTECTED] http://www.oxixares.com/~gbv Ogijares, Granada - SPAIN
Re: GTY as attributes
Taras Glek wrote:
Would you consider restructuring GTY markers to be more like GCC
attributes?
It could have some advantages, but if I understand what you mean it
would make sense only on platforms where GCC is compiled by itself. I
believe that (perhaps unfortunately) the rule is that GCC should be
compilable by any ISO-C conformant compiler.
I'm writing code to generate code to convert GCC trees to
JavaScript objects for my GCC plugin. Clearly this is similar to what
gengtype does. However, I would like to reuse GTY markers without using
the gengtype parser. Since I already use the GCC asts, it would be handy
if GTYs were just gnu attributes.
I think it was also be beneficial to do GTYs as gcc attributes for
consistency instead of having yet another language extension.
So far I've defined GTY as
#define GTY(x) __attribute__((user (#x)))
Which appears to work for most cases except for numerous cases of
typedef struct Name GTY(()) {
};
These would parse fine as attributes if they were more like
typedef struct GTY(()) Name {
};
Maybe you might patch gengtype to accept such a change, and be able to
parse the above? Then you only have to (trivially) patch all the files
so that typedef struct Name GTY(()) is changed to
typedef struct GTY(()) Name
Would you be willing to accept such a change?
Another possible benefit of raising GTYs to attribute status would be
that other projects could do compile-time reflection similar to what GCC
does in a semi-formal way.
This would be interesting (including for my MELT branch)
A more disruptive technique would be to have all the data defined with
GTY described (perhaps more precisely) elsewhere. I mean to have all the
GGC handled data described -probably in a different syntax- elsewhere,
and having all the struct and GGC routines generated otherwise.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [patch,target] Fix ppc-darwin issue with long double intrinsics (PR25477)
On Feb 23, 2008, at 2:57 AM, FX Coudert wrote: 1. the target part, in gcc/config/darwin* and gcc/config/rs6000, that takes care of setting correct assembler names for the builtins, if needed The patch was bootstrapped on powerpc-apple-darwin9.2.0 with C and Fortran, and regtested with both -m32 and -m64 for these same languages. OK for trunk? Clean beautiful code, hardly needs a review in my book. :-) Ok. I did notice that: nanl strtold are missing. In addition, there are some lessor functions like err, errc, errx, strtold_l, swprintf, vfwscanf missing. I assume this is due to no builtins for them or Fortran not using them. If Ada or other non-C languages might, might make sense to add them too. Thanks.
[Ada] gnat.dg/socket[12].adb test duplicates?
Hi Arnaud,
gnat.dg/socket1.adb and socket2.adb are identical AFAICT, is there a
special reason to have both? I couldn't find a ChangeLog entry for these
tests.
Thanks in advance,
Laurent
--- ../gcc-4.3.0-RC-20080222/gcc/testsuite/gnat.dg/socket2.adb 2007-06-14
11:24:07.0 +0200
+++ ../gcc-4.3.0-RC-20080222/gcc/testsuite/gnat.dg/socket1.adb 2007-06-06
12:54:25.0 +0200
@@ -1,7 +1,7 @@
--- { dg-do run }
+-- { dg-do run }
with GNAT.Sockets; use GNAT.Sockets;
-procedure socket2 is
+procedure socket1 is
X : Character;
begin
X := 'x';
@@ -11,4 +11,4 @@
begin
null;
end;
-end socket2;
+end socket1;
Re: [patch,target] Fix ppc-darwin issue with long double intrinsics (PR25477)
nanl strtold are missing. In addition, there are some lessor functions like err, errc, errx, strtold_l, swprintf, vfwscanf missing. I assume this is due to no builtins for them or Fortran not using them. If Ada or other non-C languages might, might make sense to add them too. I've not limited myself to builtins used by Fortran, but tried to provide a complete list (Fortran only uses math builtins and memory (de)allocation functions). The missing functions are those for which there is currently no definition in builtins.def: that also includes strtold. The issue with nanl() is more complex. It is in the list of functions that need to be fixed: $ nm -arch ppc /usr/lib/libSystem.dylib | grep _nanl U _nanl$LDBL128 90178f20 T _nanl$LDBL128 901791a0 T _nanl 90179190 T _nanl$LDBL64 taigne ~ $ nm -arch ppc64 /usr/lib/libSystem.dylib | grep _nanl 00161290 T _nanl 00161090 T _nanl$LDBL128 00161280 T _nanl$LDBL64 but in Andrew's and Jack's patch, it is excluded with the following comment: + /*darwin_patch_builtin (BUILT_IN_NANL);*/ /* Broken for now since it +is defined as DEF_GCC_BUILTIN when it is also a C99 function. */ Because my gfortran time right now is limited, I have decided against trying to get it into the patch. I'll note that fact into the PR after committing the patch, and maybe someone (or myself) can try later on to determine what needs to be done. For now, it's of limited importance, because it's not among the builtins used in Fortran. Thanks for the review and comments, FX -- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/
Re: [Ada] gnat.dg/socket[12].adb test duplicates?
> gnat.dg/socket1.adb and socket2.adb are identical AFAICT, is there a > special reason to have both? Probably none. Feel free to remove one of them. Arno
Re: [patch,target] Fix ppc-darwin issue with long double intrinsics (PR25477)
On Sat, 23 Feb 2008, FX Coudert wrote: > > + /*darwin_patch_builtin (BUILT_IN_NANL);*/ /* Broken for now since it > > +is defined as DEF_GCC_BUILTIN when it is also a C99 function. */ Note that this (builtin nan*) is bug 19984, which explains the history behind the use of DEF_GCC_BUILTIN. -- Joseph S. Myers [EMAIL PROTECTED]
Re: 4.3.0-rc1 available
Jakub Jelinek redhat.com> writes: > > GCC 4.3.0 release candidate 1 is now available at: > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.0-RC-20080222/ > > Please test the tarballs there and report any problems to Bugzilla. CC me > on the bugs if you believe they are regressions from previous releases > severe enough that they should block the 4.3.0 release. > > just one thing on the side, the md5 file for this release is screwed. it only contains : c3b774a3b42a1b3b780ad48aa2d2132a gcc-4.3.0-RC-20080222.tar.gz and it doesn t match with the checksums i got (tried the package from several mirrors, they all gave me : 03ab7ccd9f976588070c8707ccb670f3 gcc-4.3.0-RC-20080222.tar.gz )
Fix C++0x regressions for gcc-4.3
Hi, I'd like to know if C++0x regressions are being addressed for gcc-4.3 release. I'm saying that because of bug "Compiling error with variadic template with fixed parameter with default type." (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35297) is rather annoying for those who are already using C++0x new features. Regards, Rodolfo Lima.
Re: Fix C++0x regressions for gcc-4.3
On Sat, Feb 23, 2008 at 5:48 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > Hi, I'd like to know if C++0x regressions are being addressed for > gcc-4.3 release. I'm saying that because of bug > "Compiling error with variadic template with fixed parameter with > default type." (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35297) is > rather annoying for those who are already using C++0x new features. This is not a regression. -- Pinski
How to Avoid Executing a Front End's testsuite
I've been working at getting Tim Josling's cobol to work as a front end. I've found how to tell GCC not to consider cobol an 'all' (default) language, but I haven't figured out how to keep other cobol targets from being activated. For example, I do a plain ../gcc_src/configure make bootstrap and the default languages get built. (without cobol). Then when I do make check the system tries to do execute the cobol testsuite (with errors of course since there is no cobol compiler). I've looked at the GCC Internals but see no help there. How do I fix the GCC build/configure system for this situation? Thanks. -Tom Tom Browder Niceville, Florida USA
Re: Fix C++0x regressions for gcc-4.3
On Sat, Feb 23, 2008 at 5:48 PM, Rodolfo Lima <[EMAIL PROTECTED]> wrote: > > Hi, I'd like to know if C++0x regressions are being addressed for > > gcc-4.3 release. I'm saying that because of bug > > "Compiling error with variadic template with fixed parameter with > > default type." (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35297) is > > rather annoying for those who are already using C++0x new features. On Sat, Feb 23, 2008 at 05:50:46PM -0800, Andrew Pinski wrote: > This is not a regression. There is no such thing as a "C++0x regression", since (very limited and experimental) C++0x support is brand new in 4.3, and 4.3.0 hasn't been released yet. A regression is something that worked correctly in a previously released version of GCC, but that doesn't work now.
