Re: why multiple libiberty directories
On Mon, 1 Mar 2010, Jack Howarth wrote: Somehow the recursive make is broken for libiberty and is silently using the system compiler. Jack I believe this is PR29404. IIRC, in addition to libiberty, other recursive make checks fail too due to using the system (stage1) compiler. --Kaveh
Re: printf enhancement
On Fri, 22 Jan 2010, Piotr Wyderski wrote: Paolo Carlini wrote: The C library, to which library printf belongs, is not part of the GCC project. In that case it certainly isn't a GCC issue. Assuming this feature is accepted in glibc, you'll want to update GCC's -Wformat flag.
Package hosting sites for MPC
If anyone would like to obtain MPC from a pre-built package, there is a page on the MPC website listing known providers for various OSes. http://www.multiprecision.org/index.php?prog=mpcpage=packages It's still missing several of our important platforms, including solaris, aix and hpux. If you can convince your favorite package site (e.g. blastwave.org or hpux.connect.org.uk) to offer binaries for these systems, please do and notify the MPC mailing list (not me) about it here: http://lists.gforge.inria.fr/mailman/listinfo/mpc-discuss Thanks, --Kaveh -- Kaveh R. Ghazi
Re: MPC required in one week.
From: Michael Witten mfwit...@gmail.com On Mon, Nov 30, 2009 at 12:04 AM, Kaveh R. GHAZI gh...@caip.rutgers.edu wrote: The patch which makes the MPC library a hard requirement for GCC bootstrapping has been approved today. Out of curiosity and ignorance: Why, specifically, is MPC going to be a hard requirement? Some of the benefits are noted here: http://gcc.gnu.org/gcc-4.5/changes.html#mpcopts
Re: Reminder: Stage3 ends Nov 30th
On Sun, 29 Nov 2009, Richard Guenther wrote: This is a remainder to not catch you in surprise when we announce the end of stage 3. Starting Dec 1st the trunk will go into regression and documentation fixes only mode (thus, same rules apply as for a release branch). When the release criteria are fulfilled (mainly zero P1 regressions) we will branch, do a release candidate and open trunk for the next stage 1. It is very unlikely that this happens before mid January. I'm having trouble getting the MPC cutover patch reviewed by a build maintainer. http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00731.html Since PR40302 was marked by you as a regression to ensure it gets done, may I assume that this and the approved cleanups can go in during stage4 once someone looks at the configure bits? Thanks, --Kaveh
MPC required in one week.
The patch which makes the MPC library a hard requirement for GCC bootstrapping has been approved today. As promised, I'll wait one week before applying it to give everyone a chance to install MPC on their systems. You can download mpc-0.8 from either of these two locations: ftp://gcc.gnu.org/pub/gcc/infrastructure/mpc-0.8.tar.gz http://www.multiprecision.org/mpc/download/mpc-0.8.tar.gz The current GCC infrastructure supports both in-tree builds as well as the expected --with-mpc= configure flag. If you're installing MPC in a non-standard directory, I recommend building it with --disable-shared to avoid needing to set LD_LIBRARY_PATH when running GCC. (The same issue arises with gmp/mpfr.) Of course, let me know of any problems. --Kaveh
Re: WTF?
On Wed, 25 Nov 2009, Richard Guenther wrote: That's not an option. That would basically tell you that you can get away with breaking the rules if you just take the blame. And I just checked and none of my 12 local patches I queued for stage1 apply anymore. And as usual there are big hunks that now are broken. And patch doesn't have an option to ignore whitespace changes. The patch HJ installed is 100% useless and so should be reverted in some way or another. I think we need to take a deep breath and relax. First of all, HJ didn't need approval for this patch. Whether it's useful or not, it aligns with our stated coding standards and it clearly qualifies as obvious under the Free for all category in our checkin policies. Second, stage3 is probably the best time for such a patch. Third, it's possible HJ *did* post it to gcc-patches, and it bounced because of the size. Let's give him the benefit of the doubt and hear what he has to say before anyone goes postal over this. Finally, we have a process for reverting a patch. If anyone wants to revert some part, it needs to be followed. Otherwise *that* would be breaking the rules... --Kaveh
Re: WTF?
From: Dave Korn dave.korn.cyg...@googlemail.com But does it, though? From http://gcc.gnu.org/svnwrite.html: Free for all The following changes can be made by everyone with SVN write access: Fixes for obvious typos in ChangeLog files, docs, web pages, comments and similar stuff. Just check in the fix and copy it to gcc-patches. We don't want to get overly anal-retentive about checkin policies. Incorrect whitespace is a typo. I.e. an error in typed material.
Re: WTF?
From: Richard Guenther rguent...@suse.de The change certainly didn't fall under the obvious rule because of its size. One might argue that 'and similar stuff' covers coding-style changes, but here again I'd fear of a certain kind of people going wild and follow the coding-style by word rather than existing practice in GCC or even the code around their changes. So, I would say even obvious patches should be posted for review with the usual (but not documented) will checkin tomorrow if there are no complaints style disclaimer. Given its size, I agree that would have been the sensible thing to do.
Re: [annoyed grunt]?
From: Dave Korn dave.korn.cyg...@googlemail.com Agreed, but what I'm not at all certain is whether it counts as *in* ChangeLog files, docs, web pages, comments and similar stuff, specifically when it's at the end of a line of functional C code in a source file. Since whitespace in C has no syntactic effect, certainly these changes qualify under and similar stuff.
Re: WTF?
From: Richard Kenner ken...@vlsi1.ultra.nyu.edu I suspect the web page in question needs to be updated to more accurately reflect current standard practice. It appears wrong to me on more counts than just this one (my understanding has always been that no approval is needed to fix typos, whether in code or comments, but this page says only the latter). I agree the wording could be better. Unlike HJ's patch, many so-called obvious checkins actually have code-gen consequences. (Gasp!) Okay, okay, those tend to be one-liners. ;-) --Kaveh
Re: GNU MPFR 2.4.2 Release Candidate 3
On Wed, 25 Nov 2009, Vincent Lefevre wrote: The release of GNU MPFR 2.4.2 (andouillette sauce moutarde patch level 2) is imminent. I tested mpfr-2.4.2rc3 on sparc-sun-solaris2.9 in 32 and 64 bit modes. I compiled with both gcc-3.4.6 and Sun C 5.5. All four configurations built and passed make check. Great job! (I used gmp-4.3.1 in all cases.) Thanks, --Kaveh
Re: Updating Primary and Secondary platform list for gcc-4.5 ???
From: Mark Mitchell m...@codesourcery.com Richard Guenther wrote: If config.gcc handles both triples the same (*-*-solaris2.10 and *-*-solaris2.11) then we can consider both at the same level. Indeed. Furthermore, we certainly wouldn't want to break support for Solaris 2.10 at this point, so having 2.10 listed seems to make sense to me. Agreed. I guess my remaining questions are for AIX and mipsisa64-elf. Can someone please confirm that mipsisa64-elf is a cross-compile-only target and therefore not relevant for host-based MPC portability testing? And do we want to update aix5.2 to aix5.3 in our platforms list? Thanks, --Kaveh
Re: Updating Primary and Secondary platform list for gcc-4.5 ???
From: David Edelsohn dje@gmail.com On Thu, Nov 12, 2009 at 10:00 AM, Kaveh R. Ghazi gh...@caip.rutgers.edu wrote: And do we want to update aix5.2 to aix5.3 in our platforms list? AIX should be updated to 5.3 or 6.1. David For the last two months or so, the AIX reports I see are mostly (all?) for 5.3, so I suggest we use that version. --Kaveh
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
From: David Edelsohn dje@gmail.com On Tue, Nov 10, 2009 at 1:16 AM, Kaveh R. GHAZI gh...@caip.rutgers.edu wrote: So IIUC, David is setting SHELL=/path/to/bash first, then running configure, then getting an error. This happens because configure tests that bash understands +=, but libtool is run with (presumably) /bin/sh and doesn't understand += right? If so, then if one doesn't set SHELL (or CONFIG_SHELL?) on AIX, everything should work fine building MPC, right? Basically, but using /bin/sh on AIX causes other problems. David Ok great, since Paolo fixed the libtool problem upstream I'll consider this issue closed. Could you please provide the testing details so we can note it in the MPC platforms page? I.e. target triplet plus gcc/gmp/mpfr versions. Or just confirm they are the same as the report you gave for the previous MPC release noted here: http://gcc.gnu.org/ml/gcc/2009-09/msg00203.html Thanks, --Kaveh
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
On Mon, 9 Nov 2009, Paolo Bonzini wrote: On 11/09/2009 06:33 AM, Kaveh R. Ghazi wrote: From: David Edelsohn dje@gmail.com AIX Shell is KSH. The problem is shell append += and libtool not running with the same shell used by configure. Hm, the mpc configure script actually has a check for shell +=, and on my solaris box it correctly detects that it doesn't work. checking whether the shell understands +=... no Presumably on solaris then += isn't used. I wonder what does configure say here for AIX and why does it attempt to use it? As David said, the problem is using the same shell in configure and libtool. I think I fixed this upstream (just as a consequence of cleanups). Paolo So IIUC, David is setting SHELL=/path/to/bash first, then running configure, then getting an error. This happens because configure tests that bash understands +=, but libtool is run with (presumably) /bin/sh and doesn't understand += right? If so, then if one doesn't set SHELL (or CONFIG_SHELL?) on AIX, everything should work fine building MPC, right? --Kaveh
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
On Mon, 9 Nov 2009, Paolo Bonzini wrote: On 11/08/2009 10:29 PM, David Edelsohn wrote: The problem is shell append += and libtool not running with the same shell used by configure. What version of libtool is used by mpc? Libtool HEAD could fix this bug. Paolo (GNU libtool) 2.2.6 Debian-2.2.6a-4
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
From: David Edelsohn dje@gmail.com AIX Shell is KSH. The problem is shell append += and libtool not running with the same shell used by configure. Hm, the mpc configure script actually has a check for shell +=, and on my solaris box it correctly detects that it doesn't work. checking whether the shell understands +=... no Presumably on solaris then += isn't used. I wonder what does configure say here for AIX and why does it attempt to use it? After my intervention: $ make check === All 57 tests passed === Thanks for the report. Do you consider this issue closed or would you like to pursue it further? --Kaveh
Updating Primary and Secondary platform list for gcc-4.5 ???
I was looking through the gcc-4.5 primary and secondary platform list to ensure we have coverage for MPC testing. It occurs to me that some of the OS versions are outdated. I've included the list from the page http://gcc.gnu.org/gcc-4.5/criteria.html Should we update: 1. solaris2.10 - 2.11 2. hpux11.11 - ??? 3. aix5.2 - 5.3 For the purposes of MPC testing I also want to know: 1. Is mipsisa64-elf cross-config only? I.e. MPC portability testing is only relevant to the host platform where GCC is run. So we don't have to worry about this one? 2. i386-unknown-freebsd and i686-apple-darwin are generic, but config.guess will supply specific version numbers. What version should MPC be shown to work on? Any one of them would do? 3. For freebsd and darwin, do we want to include specific version numbers for our platform list, or leave them generic? Thanks, --Kaveh Primary Platform List arm-eabi i386-unknown-freebsd i686-pc-linux-gnu mipsisa64-elf powerpc64-unknown-linux-gnu sparc-sun-solaris2.10 x86_64-unknown-linux-gnu Secondary Platform List hppa2.0w-hp-hpux11.11 powerpc-ibm-aix5.2.0.0 i686-apple-darwin i686-pc-cygwin i686-mingw32 ia64-unknown-linux-gnu s390-linux-gnu
Re: MPC version 0.8 released!
Kaveh R. GHAZI gh...@caip.rutgers.edu writes: Please test this version and report back in this thread (not to me privately) the results of make check. Also include your target triplet, and the versions of your compiler, gmp and mpfr. Wow we've gotten a lot of results, thanks everyone! But we're still missing a few of the GCC primary and secondary platforms for the mpc-0.8 final release. Some of you provided results for the missing systems either for the mpc-0.8dev prerelease or a previous full release. I would very much appreciate it if you would try out the latest package. The platforms still needed for mpc-0.8 release testing are: i386-unknown-freebsd (have results for mpc-0.8dev) i686-pc-cygwin (have results for mpc-0.8dev) hppa2.0w-hp-hpux11.11 (have results for mpc-0.8dev) i686-apple-darwin (have results for mpc-0.7) powerpc-ibm-aix5.3.0.0 (have results for mpc-0.7) i686-mingw32 (have results for mpc-0.7) Thanks! --Kaveh -- Kaveh R. Ghazi
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
From: David Edelsohn dje@gmail.com MPC-0.8 build fails on AIX due to libtool. The changes to libtool between MPC-0.7 and MPC-0.8 rely on Bash-specific features. Manually editing libtool to use Bash allowed the build to succeed. Hi David, Can you please be more specific about this problem? I've seen several build reports on non-gnu systems that don't use bash as the default shell, including my own solaris2.9 box. None of them fail on bash-isms. So I'm curious what the actual failure is on AIX. The more recent libtool was suggested to avoid some issues on darwin, so I prefer not to opt for a downgrade if at all possible. If there is some non-portable shell construct, we should file a bug report with the libtool maintainers. Another option in the mean time is that if ksh or some other shell supplied by default works on AIX we could recommend using that via CONFIG_SHELL. What do you suggest as possible ways forward? Thanks, --Kaveh
Re: MPC version 0.8 released!
From: Dennis Clarke dcla...@blastwave.org target GCC GMP MPFR sparc-sun-solaris2.11 4.1.1 4.2.1 2.3.2 i386-pc-solaris2.10 4.1.1 4.2.1 2.3.2 mips-sgi-irix6.5 3.4.5 4.3.0 2.3.2 alpha-dec-osf4.0f 3.4.4 4.2.1 2.3.2 All tests passed everywhere. what about sparc-sun-solaris2.10 ? sparc-sun-solaris2.9 and 2.8 ? I've done sparc-sun-solaris2.9, it passed. See: http://lists.gforge.inria.fr/pipermail/mpc-discuss/2009-November/000608.html Since sparc-sun-solaris2.10 is our official primary platform solaris for gcc-4.5, it would be nice to have that checked as well. http://gcc.gnu.org/gcc-4.5/criteria.html Though I don't foresee any problems, if either of you have that box and can find time to run the test and report back, I would very much appreciate it. Thanks, --Kaveh
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
From: Gerald Pfeifer ger...@pfeifer.com === All 57 tests passed === i386-unknown-freebsd7.2 gcc version 4.2.1 20070719 [FreeBSD] mpfr-2.4.1_1 (FWIW, on FreeBSD I have made MPC a hard requirement for the GCC 4.5 port already. I assume the next steps on your side are waiting for the official releaes of MPC 0.8 and then making that a requirement for our configure scripts?) Yes. There remains a few cleanups (see PR40302), but the heavy lifting is all done. --Kaveh
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
From: Ed Smith-Rowland 3dw...@verizon.net I'm on MacOSX 10.3 MacOSX:~/Tarballs/mpc-0.8-dev ed$ gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1671) The -Werror kills it. Once I deleted -Werror out of the makefiles... === All 57 tests passed === I don't know how you would tweak the configure to kill this -Werror for mac but that would do it. The -Werror flag will not be used in the final release, so it should work for you. Thanks for testing. --Kaveh
MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
A prerelease tarball of the upcoming mpc-0.8 is available here: http://www.multiprecision.org/mpc/download/mpc-0.8-dev.tar.gz This release is feature complete with respect to C99 and GCC's needs. So I expect to make this version be the one made mandatory for the gcc-4.5 release. If there are any remaining bugs especially portability problems to GCC's primary or secondary platforms, I'd like to get those reported and fixed before this release is final. Please test this MPC package and report back the results of running make check along with your target triplet, the compiler version you used, and the versions of gmp/mpfr used to compile it. You do not necessarily need to bootstrap mainline GCC with this MPC, but if you have the spare time and cycles it would be nice too. Thanks, --Kaveh -- Kaveh R. Ghazi gh...@caip.rutgers.edu
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
From: David Fang f...@csl.cornell.edu On powerpc-apple-darwin8: gmp: 4.3.1 mpfr: 2.4.1 % gcc -v Using built-in specs. Target: powerpc-apple-darwin8 Configured with: /var/tmp/gcc/gcc-5370~2/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5370) CPU: dual G4, powerpc 7400 === All 57 tests passed === Thanks!
Re: MPC 0.8 prerelease tarball (last release before MPC is mandatory!)
From: Allan McRae al...@archlinux.org Nothing exotic: i686-pc-linux-gnu x86_64-unknown-linux-gnu Both: === All 57 tests passed === gcc-4.4.2 mpfr-2.4.1 gmp-4.3.1 Also fine on i686-pc-linux-gnu with gcc-4.5-20091008 Allan Thanks!
Re: Testsuite regular expression question
On Mon, 26 Oct 2009, Steve Ellcey wrote:
I have tried:
/* { dg-final { scan-assembler-times (byte|data1).*?0x3.*? DW_AT_inline 3 }
} */
/* { dg-final { scan-assembler-times (byte\|data1).*?0x3.*? DW_AT_inline 3
} } */
/* { dg-final { scan-assembler-times \(byte\|data1\).*?0x3.*? DW_AT_inline
3 } } */
And various other escapes, parenthesis, etc but cannot get any of them
to work. Does anyone know what this RE should look like to allow 'byte'
or 'data1' in the string? It seems to break as soon as I introduce
parenthesis anywhere in the RE.
I think you need two backslashes escaping the paren and maybe one before
the pipe. I'm not sure about the \| vs | though, give the double escape
paren a try both ways. You can see some examples via:
find gcc/testsuite | xargs grep 'scan-assembler-times.*[(|]'
--Kaveh
Re: Outdated comment in real.c (was: constant folding)
On Fri, 25 Sep 2009, Vincent Lefevre wrote: [Cc to the gcc mailing-list] On 2009-09-25 02:18:55 +0200, Vincent Lefevre wrote: Also, as EXP_BITS is the full (biased) exponent size, it seems that the real.c comment is buggy (27 - 26). Looking at the history: -#define EXP_BITS (32 - 5) +#define EXP_BITS (32 - 6) The following change fixes the comment. Tested with make on x86_64-unknown-linux-gnu. I'll install this as obvious tomorrow if nobody comments on the patch. --Kaveh 2009-09-28 Kaveh R. Ghazi gh...@caip.rutgers.edu * real.c: Fix comment to reflect actual exponent size. diff -rup orig/egcc-SVN20090928/gcc/real.c egcc-SVN20090928/gcc/real.c --- orig/egcc-SVN20090928/gcc/real.c2009-09-18 02:00:54.0 +0200 +++ egcc-SVN20090928/gcc/real.c 2009-09-28 18:06:06.0 +0200 @@ -57,7 +57,7 @@ Both of these requirements are easily satisfied. The largest target significand is 113 bits; we store at least 160. The smallest - denormal number fits in 17 exponent bits; we store 27. + denormal number fits in 17 exponent bits; we store 26. Note that the decimal string conversion routines are sensitive to rounding errors. Since the raw arithmetic routines do not themselves
MPC 0.7 officially released, please test and report your results!
Hi,
mpc-0.7 now has been released, you can get the package here:
http://www.multiprecision.org/index.php?prog=mpcpage=download
Here's the official announcement:
http://lists.gforge.inria.fr/pipermail/mpc-discuss/2009-September/000554.html
Of particular interest in this release are bugfixes, especially for
complex division, and the introduction of mpc_pow used for folding
cpow{,f,l} inside GCC.
Note the complex arc functions are still missing and are now projected
to be available in a future release, probably 0.8.
Please download, compile and run make check for this release and post
your results as well your target triplet and the versions of your
compiler, gmp and mpfr. All platform results are welcome, but I am
especially interested in GCC's primary and secondary platform list.
Thanks,
--Kaveh
Re: Call for testers: MPC 0.7 prerelease tarball
From: Dave Korn dave.korn.cyg...@googlemail.com Dave Korn wrote: Attached allowed it to build, And with that patch: === All 45 tests passed === Thanks Dave! This MPC release may happen early next week. Anyone else have success results, problems or portability patches? --Kaveh
Call for testers: MPC 0.7 prerelease tarball
Hello, A prerelease tarball of the upcoming MPC 0.7 is available here: http://www.multiprecision.org/mpc/download/mpc-0.7-dev.tar.gz Please help test it for portability and bugs by downloading and compiling it on systems you have access to. I'd like a report to contain your target triplet and the versions of your compiler, GMP and MPFR used when building MPC. Also please include your results from make check. You can report your results here in this thread or on the MPC mailing list: http://lists.gforge.inria.fr/mailman/listinfo/mpc-discuss Note I encourage reports of all platforms on which GCC bootstraps, but I'm especially interested in the GCC primary and secondary list from our release criteria listed here: http://gcc.gnu.org/gcc-4.5/criteria.html As previously discussed, MPC will become a mandatory library for building GCC prior to the 4.5 release, so your help in ensuring a smooth transition is greatly appreciated. Thanks, --Kaveh -- Kaveh R. Ghazi
Re: Status of LTO merge to mainline
On Tue, 7 Jul 2009, Diego Novillo wrote: 4- Test on primary and secondary platforms. What is the current suggested list of platforms? http://gcc.gnu.org/gcc-4.5/criteria.html
Re: Should -Wjump-misses-init be in -Wall?
On Sat, 20 Jun 2009, Ian Lance Taylor wrote: That said, I'm perfectly amenable to moving the new warning to -Wextra or just turning it on only with -Wc++-compat. I don't personally care that much, actually. I also agree with Robert's comments that all warnings are about valid C, with -Wall we diagnose what we subjectively feel is dubious coding practice. Not everyone will agree with what -Wall contains, that's not a reason to freeze it. Furthermore I am not impressed by a total of four warnings between binutils and GCC. Those are large packages and not necessarily representative of the average package among a gnu/linux distro. Now if someone does a test and shows that building the world exposes hundreds or even dozens of these warnings, **and** none of them are actual bugs, then I would reevaluate my opinion. Finally, the compromise fallback position should be to move it to -W/-Wextra (like -Wsign-compare in the past). As a dubious coding practice, I don't think we should banish it to only -Wc++-compat. --Kaveh
Re: What is -3.I (as opposed to 0-3.I) supposed evaluate to?
From: Joseph S. Myers jos...@codesourcery.com On Mon, 8 Jun 2009, Kaveh R. Ghazi wrote: Perhaps the only safe way to create the value, even in the presence of rounding mode changes, is to use conj(3.I) ? Setting the __real__ and __imag__ parts of a temporary variable should always be reliable for making a complex number out of arbitrary real and imaginary parts. Well yes, but I meant for compile-time expressions that are exposed to fold even at -O0. (Recall that I'm writing testcases for the MPC stuff.) I'm not 100% confident that the temporary variable will always fold and it's too verbose when repeatedly used in a testcase. With conj, the builtin will always fold 3.I and won't do anything unexpected with rounding modes. I was just wondering why -3.I was evaluating differently than 0-3.I and whether it was a bug. Your explanation was very useful. Thanks, --Kaveh
Re: Bootstrap failures on solaris
On Tue, 9 Jun 2009, Art Haas wrote: Hi. I've had no luck with recent bootstraps on both i386-pc-solaris2.10 and sparc-sun-solaris2.10. The error messages below are from builds performed after updating my repo this morning. i386-pc-solaris: cc1: warnings being treated as errors /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c: In function 'loop_prefetch_arrays': /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c:1589:7: error: format '%ld' expects type 'long int', but argument 5 has type 'long long int' make[3]: *** [tree-ssa-loop-prefetch.o] Error 1 make[3]: *** Waiting for unfinished jobs The above should be easy to fix using HOST_WIDE_INT_PRINT_DEC instead of %ld. You'll have to pry apart the format string and insert the macro via compile-time string contatenation. See other uses for examples. --Kaveh
Re: Using MPC Library with GCC
From: Allan McRae al...@archlinux.org
I have noticed that mpc is not automatically detected even when
installed in the standard library path (with gcc-4.5-20090604). This
means that building with mpc always requires using the
--with-mpc-lib=/usr/lib flag.
This is fixed by adjusting configure{.ac} to have:
mpclibs=-lmpc
See: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00615.html
What is -3.I (as opposed to 0-3.I) supposed evaluate to?
If I write a complex double constant -3.I (as opposed to 0-3.I), what is
it supposed to evaluate to? This program:
#include stdio.h
int main(void)
{
const __complex double C1 = (-3.I);
const __complex double C2 = (0-3.I);
printf (%f %f\n, __real__ C1, __imag__ (C1));
printf (%f %f\n, __real__ C2, __imag__ (C2));
return 0;
}
when compiled with gcc-4.1.2 (and mainline) yields:
-0.00 -3.00
0.00 -3.00
Note the sign difference in the real part.
When I compile it with g++-4.1.2, I get:
compl.c: In function 'int main()':
compl.c:5: error: wrong type argument to unary minus
Is this supposed to happen or is it a bug in complex number parsing?
(Sorry if this is a gcc-help question.)
Thanks,
--Kaveh
Re: What is -3.I (as opposed to 0-3.I) supposed evaluate to?
From: Joseph S. Myers jos...@codesourcery.com On Mon, 8 Jun 2009, Kaveh R. GHAZI wrote: If I write a complex double constant -3.I (as opposed to 0-3.I), what is it supposed to evaluate to? This program: Because GCC does not implement imaginary types, this applies unary minus to 0.0+3.0I. Whereas 0-3.I means 0.0 - (0.0+3.0I), a mixed real/complex operation, the real part of whose result is 0.0 except when rounding towards negative infinity when it is -0.0. There are lots of tests in gcc.dg/torture/complex-sign*. Okay thanks. Perhaps the only safe way to create the value, even in the presence of rounding mode changes, is to use conj(3.I) ? --Kaveh
Re: Using MPC Library with GCC
On Wed, 13 May 2009, Mark Mitchell wrote: Kaveh R. GHAZI wrote: 1. Consider MPC as an optional library now, install all the code and make it hard-required only when all the complex math functions are made available in a future released version of the library or sometime in stage3, whichever is first. I think this is the best option. Please make sure to open a P1 PR for 4.5.0 indicating that we should throw the hard-requirement switch. The last patch to enable use of MPC in GCC was reviewed today and installed. I'm sure other updates will come, but the base functionality is now there. I've opened PR 40302 as you requested (and assigned myself). Thanks, --Kaveh
Re: Build of gcc 4.4.0 on Solaris 10 Sparc ok, most tests failed.
On Thu, 14 May 2009, Eric Botcazou wrote: The build went through without any error, but most of the tests failed in make check. unexpected failures = 6472 and passed = 52. Try with make -k check and no -j, parallel testing is broken on Solaris. Eric Botcazou To clarify, is it make -l # that fails or make -j # on Solaris? Parallel testing with -j# used to work fine, but admitedly its been a long while since I lost my solaris box... (I don't know if the load avg based mechanism for -l ever worked.) Is there a PR number? Thanks, --Kaveh
Re: Using MPC Library with GCC
On Tue, 5 May 2009, Mark Mitchell wrote: I personally think relying on MPC is a reasonable choice, given the fact that (as you say) the language specifications do in some cases require support for these kinds of manipulations of complex numbers at compile-time. In the past, however, other people have had objections. I'd like to give them more time (let's say one more week) to comment. If that week passes without negative comment, let's start coordinating how to move forward with it. Okay, nobody spoke up so let's proceed. The remaining issue is how and when to arrange for the MPC dependency to be activated. I think the consensus was to make MPC a hard-requirement. However I'd also like to make the pain of getting the appropriate library version to occur only once for GCC developers (or at most once per GCC release cycle). The current release mpc-0.6 has most but not all of the c99 complex functions finished. The remaining ones are supposed to be done in a couple of months. That should be in time for the 4.5 release, if not I'll go with whatever we have and get the remainder for gcc-4.6. We did something similar for MPFR functions (like lgamma) that became available in later versions of that library. Here are options on how to proceed: 1. Consider MPC as an optional library now, install all the code and make it hard-required only when all the complex math functions are made available in a future released version of the library or sometime in stage3, whichever is first. 2. Hard-require mpc-0.6 now and hard require later versions when the remaining functions are done. Requires at least two installs of MPC by everyone, possibly more. 3. Hard-require mpc-0.6 now, future complex functions could be wrapped by #ifdef MPC_VERSION = foo. We did this with MPFR functions for a while until we eventually upgraded to later versions and got rid of the conditionals. I prefer option 1 since it allows me to commit the majority of the patches and get wider testing now without creating the installation pain more than once. Option 2 is fine with me but will make other developers complain more. Option 3 has the disadvantage that some optimizations will depend on the version of MPC installed. We have historical precedent for that with MPFR but people expresed that they don't like it. I like this one the least. Thoughts? --Kaveh
Re: Using MPC Library with GCC
On Tue, 28 Apr 2009, Kaveh R. Ghazi wrote: From: Mark Mitchell m...@codesourcery.com That is not a decision, however, on whether using MPC is or is not a good idea. There have been objections raised to MPC, on the grounds that it may not build on all host systems, or that the costs it brings in terms of complexity of building GCC outweigh its benefits. We should reach consensus on those issues before making a decision about whether to depend upon it. Thanks Mark. Although I personally felt that the GPLv3-compatible license terms were sufficient from a legal and policy perspective, it's good to clarify this officially for future circumstances as well as retroactively for the libraries we already depend on. Also I agree that the remainder of the discussion (i.e. whether it's a good idea in this particular case) should be conducted in the public forum and that's what I asked for in my proposal to the SC. So to address the remaining concerns, ... I didn't hear back from anyone opposing (or supporting!) MPC. Does that mean it's no longer controversial? Hopefully I've addressed the outstanding issues raised. http://gcc.gnu.org/ml/gcc/2009-04/msg00741.html --Kaveh
Re: Problems with in-tree host libraries (gmp, ppl, etc)
On Sat, 2 May 2009, Anthony Green wrote:
The top level configury suggests that you can simply drop gmp, ppl, etc
into the top level source dir and they will get configured and used.
Does this really work?
It is supposed to. I haven't worked on or tested the ppl machinery so I
don't know what shape it is in.
Index: Makefile.def
===
--- Makefile.def(revision 146995)
+++ Makefile.def(working copy)
@@ -60,7 +60,7 @@
host_modules= { module= gawk; };
host_modules= { module= gettext; };
host_modules= { module= gmp; lib_path=.libs; bootstrap=true;
- extra_configure_flags='--disable-shared';
+ extra_configure_flags='--disable-shared --enable-cxx';
no_install= true;
host=none-${host_vendor}-${host_os};
target=none-${host_vendor}-${host_os}; };
I would only pass in this flag if ppl is being used. Look at what I did
with extra_mpfr_configure_flags in the top level directory. You can use a
similar mechanism to have a flag passed in to the gmp build conditionally.
Even then, the ppl configury isn't detecting the gmp we just built. It
seems as though we should install gmp in a local temporary install tree
and point ppl at that. See below for a trace of the ppl configury as it
attempts to detect an in-tree gmp (after applying the patch above).
AG
I don't know if ppl was ever setup to detect/use an in-tree gmp. It would
need to be able to specify --with-gmp-build= or something equivalent to
get the header and library from a build tree rather than an install tree.
They're laid out slightly differently.
--Kaveh
Re: gcc-in-cxx update / multi-targeted gcc
On Wed, 29 Apr 2009, Joseph S. Myers wrote: On Wed, 29 Apr 2009, Richard Earnshaw wrote: If you are building a non-C front end without bootstrapping you need at least 2.95: To build all languages in a cross-compiler or other configuration where 3-stage bootstrap is not performed, you need to start with an existing GCC binary (version 2.95 or later) because source code for language frontends other than C might use GCC extensions. STRICT_WARN (i.e. -pedantic) was added to all the frontends (except Ada) many years ago. So this comment about use of extensions requiring gcc-2.95 might be obsolete. I suspect you may be able to cross-build all of non-ada GCC with any ISO C compiler right now (I haven't tried it though since I don't have access to an appropriate system.) --Kaveh
Re: Using MPC Library with GCC
From: Mark Mitchell m...@codesourcery.com That is not a decision, however, on whether using MPC is or is not a good idea. There have been objections raised to MPC, on the grounds that it may not build on all host systems, or that the costs it brings in terms of complexity of building GCC outweigh its benefits. We should reach consensus on those issues before making a decision about whether to depend upon it. Thanks Mark. Although I personally felt that the GPLv3-compatible license terms were sufficient from a legal and policy perspective, it's good to clarify this officially for future circumstances as well as retroactively for the libraries we already depend on. Also I agree that the remainder of the discussion (i.e. whether it's a good idea in this particular case) should be conducted in the public forum and that's what I asked for in my proposal to the SC. So to address the remaining concerns, I'll first note that the portability issue has been dealt with. The MPC developers adopted GCC's primary and secondary platform list to aid in the integration with GCC. Thanks to the participation of many developers on this list, MPC version 0.6 has been tested successfully on all of them as well as a long list of tertiary systems. One or two minor nits arose in mpc-0.6 however they are in parts of the library that I don't use inside GCC and anyway will be fixed in the forthcoming mpc-0.6.1. See: http://www.multiprecision.org/index.php?prog=mpcpage=platforms The second issue related to cost MPC brings vs benefits. To fully explore this you have to compare it to the cost of not using MPC. If we don't use MPC, the fortran maintainers will have to replicate much of MPC's functionality to support intrinsics. It's already partially implemented for the easy cases so far but several harder bits remain. When I compare the fortran implementation with the MPC copies, the MPC versions include extra code to ensure last-bit accuracy whereas the fortran cases don't. IMHO we should leave these special math cases to experts in the field instead of rolling our own versions of this code. The second cost of not using MPC means that we'll have to fix bugs in the middle end ourselves in the folding of complex expressions. Again, we're not best equipped to understand the corner cases of this and why duplicate code that's already out there? After that, the optimizations I provided for complex builtins becomes gravy, and that doesn't even begin to explore future uses of MPC that I haven't thought of yet. Sure, if you don't use complex numbers in your code you probably won't care about this and everything becomes a cost. But since complex numbers are part of the languages specs, we need to deal with it. So from a code-duplication standpoint, from a language conformance standpoint, from a bugfix standpoint, and finally from an optimization standpoint, all of these would be a win. The downside is that you have to build and install MPC one time, or unpack it in your GCC source dir since I provided support for in-tree building. Either way, it's not that hard. :-) --Kaveh
Re: testsuite fixes for small doubles
On Thu, 23 Apr 2009, DJ Delorie wrote:
+# Return 1 if the target supports double larger than float,
+# 0 otherwise.
+
+proc check_effective_target_large_double { } {
+return [check_no_compiler_messages large_double object {
+ int dummy[sizeof(double) sizeof(float) ? 1 : -1];
+}]
Isn't that comparison reversed?
Re: Question about top-level configure code and in-tree builds
From: Ben Elliston b...@au1.ibm.com On Fri, 2009-04-10 at 23:56 -0400, Kaveh R. GHAZI wrote: Ah, but cake is only easy when someone else bakes it. :-) While you're baking, Kaveh :-) could you see if your patch could also fix: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34818 Thanks, Ben I don't think they're related. The original bug I investigated is only exposed when combining in-tree builds of either gmp or mpfr, with specifying out-of-tree location for the other of the two libraries. This new PR appears to be caused by having an old mpfr in the same directory as the gmp specified by --with-gmp and trying to specify a new mpfr location via --with-mpfr as well. So you get two copies of mpfr in your -I search path and in this particular case the old one gets picked by chance. Fixing it would break the reverse case of having two gmp libraries. I am inclined to declare this to be user error. --Kaveh
Question about top-level configure code and in-tree builds
I'm seeing an issue with the top level configure code. Looking at it requires juggling m4, guile, shell and make syntax in one's head, I'm having some trouble so I'm seeking some assistance. I'm running into the actual problem when I'm integrating the mpc library with GCC and testing in-tree building scenarios, but the issue can be seen by examining the current gmp/mpfr in-tree builds as well. So I'll stick to that in my explanation. Imagine the following scenario: 1. You're building gcc. 2. You have gmp installed in a location requiring --with-gmp=foo. 3. You do not have mpfr installed, so you unpack it in your source tree and expect it to be built during bootstrap using the gmp you specified in step 2. Now e.g. you're passing --with-gmp=/opt/cfarm/gmp-4.2.4 to configure. Inside Makefile.def the mpfr in-tree build code also adds --with-gmp-build=PATH_TO_IN_TREE_GMP to your configure (via extra_configure_flags) assuming that if you're building mpfr in-tree that you are also building gmp in-tree. But we are not. So when mpfr is built in-tree you get two different locations for gmp passed to it. Depending on how mpfr's configure argument processing code is written, it might be forgiving and pass two -I/-L flags during the build. Or as is the actual case with mpfr, one might override the other and you hope the one you want gets used. By chance it works today because of the flag processing order in mpfr's configure. However this seems extremely fragile and is a latent bug IMHO. What I would like to see is that the extra_configure_flags for mpfr actually check whether gmp is being built in-tree before passing --with-gmp-build=foo to mpfr's configure. But I don't get how to do that. If the mpfr case could be fixed, I could then copy the mechanism into my patch for adding mpc. Any assistance would be greatly appreciated. Thanks, --Kaveh
Re: Question about top-level configure code and in-tree builds
On Fri, 10 Apr 2009, Ian Lance Taylor wrote: Add a new shell variable in configure.ac extra_mpfr_configure_args. Set it to what you want to pass to the mpfr configure. Call AC_SUBST(extra_mpfr_configure_args). In Makefile.in add a line EXTRA_MPFR_CONFIGURE_ARGS = @extra_mpfr_configure_a...@. In Makefile.def change the host_modules entry for module=mpfr to replace --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp with $(EXTRA_MPFR_CONFIGURE_ARGS). Run autoconf and autogen. Easy as cake. Ah, but cake is only easy when someone else bakes it. :-) Anyway, thanks for the laser-like specific answer, that was extremely helpful. I'm testing a patch, but I have two notes to run by you. 1. You mentioned adding EXTRA_MPFR_CONFIGURE_ARGS to Makefile.in. (I think you mean Makefile.tpl, cause Makefile.in is generated?) Anyway, I managed to avoid adding the intermediate make variable and just put @extra_mpfr_configure_args@ in the module=mpfr entry and it worked. Is there some stylistic or syntactic reason to use the intermediate variable? It doesn't seem to be done 100% consistently. 2. In my previous message I said that mpfr worked by chance and the bug was latent but the situation fragile. That is true for mpfr-2.3.2. However the mpfr-2.4.1 tarball hard-errors on a double --with-gmp*, apparently by design. E.g. this is from building an unpatched gcc with in-tree mpfr-2.4.1 plus the configure flag --with-gmp=/opt/... configure: error: Do not use --with-gmp-build and other --with-gmp options simultaneously. See `config.log' for more details. make[1]: *** [configure-mpfr] Error 1 So IMHO when I finish testing we should install the patch on all active branches to forestall any issues when people upgrade to the later mpfr releases. Regards, --Kaveh
Re: Call for testers: MPC-0.6 released
From: Kaveh R. Ghazi gh...@caip.rutgers.edu I've been relaying the messages, (but I haven't seen the MPC webpage updated to reflect this yet). Okay it's updated, we've got a pretty comprehensive list of platforms. http://www.multiprecision.org/index.php?prog=mpcpage=platforms Thanks everyone for your test results! I think we're just missing AIX5.2. Ralf you did that last time for the svn tarball. Would you please repeat your testing with mpc-0.6? Thanks, --Kaveh
Re: Call for testers: MPC-0.6 released
From: Gerald Pfeifer ger...@pfeifer.com On Sat, 4 Apr 2009, Andreas Tobler wrote: I've cc'ed others who have access to the platforms in question based on GCC test results. Please help if you can. - powerpc-apple-darwin9.6.0 gcc-4.5.0 gmp-4.2.2 mpfr-2.3.1 ok. - sparc-sun-solaris2.10 gcc-4.4 gmp-4.2.2 mpfr-2.3.1 ok - i686-apple-darwin9 gcc-4.0.1 gmp-4.2.2 mpfr-2.3.1 ok - x86_64-apple-darwin9 gcc-4.5.0 gmp-4.2.2 mpfr-2.3.1 ok Open: hppa2.0w-hp-hpux11.11 and x86_64-xxx-freebsd8, will follow tomorrow. - powerpc-unknown-freebsd8 gcc-4.2.1 gmp-4.2.4 mpfr-2.4.1 ok - sparc64-unknown-freebsd8 gcc-4.2.1 gmp-4.2.4 mpfr-2.4.1 ok - x86_64-unknown-freebsd8 gcc-4.2.1 gmp-4.2.4 mpfr-2.4.1 ok - hppa2.0w-hp-hpux11.11 gcc-4.3.1 gmp-4.2.2 mpfr-2.3.1 ok - hppa64-hp-hpux11.11 gcc-4.1.1 gmp-4.2.2 mpfr-2.3.1 ok That's all. Cool, thanks. Kaveh, are you going to relay these to the MPC developers, or should we do this to get FreeBSD (and the others) covered? Gerald I've been relaying the messages, (but I haven't seen the MPC webpage updated to reflect this yet). --Kaveh
Re: Call for testers: MPC-0.6 released
From: Marc Glisse marc.gli...@normalesup.org This could be related to a call to sprintf(str,...,str,...), which according to the doc is undefined behaviour. Doc? I don't see it in the man page. Got a url?
Re: Call for testers: MPC-0.6 released
From: Jakub Jelinek ja...@redhat.com man 3p sprintf says: If copying takes place between objects that overlap as a result of a call to sprintf() or snprintf(), the results are undefined. ISO C99 7.19.6.6 has similar wording: If copying takes place between objects that overlap, the behavior is undefined. Jakub Thanks for the details. (BTW, there's no 3p section on my linux box, and man 3 sprintf doesn't mention the undefined-ness. So thanks for the C99 reference.) --Kaveh
Re: Call for testers: MPC-0.6 released
From: Janis Johnson janis...@us.ibm.com I get the failure Richard mentioned when I use -D_FORTIFY_SOURCE=2 -fstack-protector but no failures without those options. This is on powerpc64-linux (but defaulting to -m32) with: RHEL 5.3 GCC 4.3.2 GMP 4.2.4 MPFR 2.4.1 MPC 0.6 Okay the -D_FORTIFY_SOURCE=2 bug has been fixed in svn. I don't think that affects any platform besides linux when using that macro. So we can proceed with testing mpc-0.6 on other platforms. We still need to complete the primary/secondary list missing from this link for mpc-0.6: http://www.multiprecision.org/mpc/index.php?content=platforms I.e. we need (primaries) x86-freebsd, x86-darwin, sparc-solaris2.10 and (secondaries) hppa-hpux11, ppc-aix5.2, ppc-darwin, x86-mingw32 and s390-linux-gnu. If you supplied the relevant testing for the prerelease tarball svn459, if you would be so kind as to repeat the testing with the official mpc-0.6 release I would greatly appreciate it. (Thanks Ralf!) Get it here: http://www.multiprecision.org/mpc/ And report your results along with the versions of target triplet/compiler/gmp/mpfr that you used. I've cc'ed others who have access to the platforms in question based on GCC test results. Please help if you can. Thanks, --Kaveh
Call for testers: MPC-0.6 released
Thanks to everyone who tested the prerelease snashot of MPC. The maintainers have now released mpc-0.6 which incorporates hopefully everyone's feedback and testing results. http://lists.gforge.inria.fr/pipermail/mpc-discuss/2009-April/000176.html The MPC developers have made a concerted effort to align their supported platforms list with that of GCC. So hopefully all the primary and secondary GCC release criteria platforms now work out of the box. Please get the tarball and report test results to the mpc forum. http://www.multiprecision.org/mpc/index.php?content=platforms The MPC developers have commited to making a quick 0.6.1 release that addresses any remaining problems on platforms important to GCC. I'm especially interested in seeing test results for non-linux-gnu, though any test results are appreciated especially if your platform is on the GCC criteria list. http://gcc.gnu.org/gcc-4.5/criteria.html Thanks, --Kaveh -- Kaveh R. Ghazi
Re: Call for testers: MPC-0.6 released
From: Richard Guenther richard.guent...@gmail.com
I get 1 failure on linux-{i586,x86_64,ppc,ppc64,ia64,s390,s390x}
platforms:
inp_str.c:131: MPC assertion failed: n == nread
/bin/sh: line 4: 2347 Aborted (core dumped) ${dir}$tst
FAIL: tio_str
Richard.
Thanks for the thorough testing!
I don't get this testsuite failure in the compile farm on e.g. gcc14
(x86_64-linux-gnu) and I assume neither did any of the MPC developers on
their personal dev boxes. So let's try and narrow down the difference in
your environment.
Can you please tell me the versions you used for gcc, gmp, mpfr and the
linux distro?
For reference I used gcc-4.1.2, gmp-4.2.2, mpfr-2.3.2 and Debian GNU/Linux:
Linux gcc14 2.6.18-6-vserver-amd64 #1 SMP Fri Dec 12 06:15:44 UTC 2008
x86_64 GNU/Linux
Thanks,
--Kaveh
Re: Call for testers: MPC-0.6 released
From: Richard Guenther richard.guent...@gmail.com I tested on openSUSE Factory which currently has gcc 4.3.3, gmp 4.2.3, mpfr 2.4.1 and some pre-2.10 glibc. I tried with vanilla mpfr-2.4.1 and gmp-4.2.3, and mpc still passed all it's tests on gcc14. Would it be fair to suspect something in your prerelease glibc? Can you please help track it down? Thanks, --Kaveh
Re: Call for testers: MPC-0.6 released
From: Janis Johnson janis...@us.ibm.com Same behavior with openSUSE 11.1 (glibc 2.9, gcc 4.3.2, gmp 4.2.3, mpfr 2.3.2). Note that I build with -D_FORTIFY_SOURCE=2 -fstack-protector. I get the failure Richard mentioned when I use -D_FORTIFY_SOURCE=2 -fstack-protector but no failures without those options. This is on powerpc64-linux (but defaulting to -m32) with: RHEL 5.3 GCC 4.3.2 GMP 4.2.4 MPFR 2.4.1 MPC 0.6 I don't normally use those options. Janis Ah, that helps. I was able to reproduce the failure using just -D_FORTIFY_SOURCE=2. However when I used both -D_FORTIFY_SOURCE=2 *and* -fstack-protector the error went away again. I'm using gcc-4.1.2 if that matters, perhaps there's a bug in -fstack-protector in that version that masks this. Anyway, thanks both of you for helping to track it down. I'll forward this along to the MPC maintainers. --Kaveh
Minimum GMP/MPFR version bumps for GCC-4.5
Hi, I'd like to open the issue of minimum GMP/MPFR versions for gcc-4.5. We currently require gmp-4.1 and mpfr-2.3.0 to build GCC. Part of my motivation is that MPC requires more recent versions of these packages. But also older GMP/MPFR have known bugs and I'd like to encourage upgrading to less ancient versions. E.g. on x86_64-unknown-linux-gnu, you can't even build gmp-4.1.1, it gets some kids of assembler error midway through. So I'd like to bump the minimum required GMP version to 4.2. According to the datestamps in http://ftp.gnu.org/gnu/gmp/ the 4.2.0 package has been out since at least March 2006. It usually takes a year to release GCC so by the time gcc-4.5 is out, gmp-4.2.x will have been available for four years. I'd like to bump MPFR from 2.3.0 to 2.3.1. There are several bugs in the 2.3.0 release that are exposed by the way MPC uses MPFR. Upgrading to version 2.3.1 fixes these issues. MPFR 2.3.0 was released in sept 2007, the 2.3.1 release was available 5 months later in Jan 2008. So by the time gcc-4.5 is out, it will have been released for at least two years. If there are no objections, I'll create a patch. Thanks, --Kaveh -- Kaveh R. Ghazi
Re: Minimum GMP/MPFR version bumps for GCC-4.5
From: Steven Bosscher stevenb@gmail.com On Thu, Mar 26, 2009 at 10:39 PM, Kaveh R. Ghazi gh...@caip.rutgers.edu wrote: If there are no objections, I'll create a patch. P... for those of us who just install the latest-and-greatest fedora/suse/ubuntu/... once and don't change installations for two or three years (stable machine, etc.) it becomes increasingly harder to install all required libraries to build GCC... Since GMP-4.2 is three years old, I had hoped it wouldn't be controversial. I can see more of a case for mpfr-2.3.1 being too recent, but it's really just a micro version bump over what we require now. I just checked and ubuntu (v8.10) seems to offer gmp-4.2.2 and mpfr-2.3.2 through it's package manager. What versions of GMP/MPFR do you get on your typical development box and how old are your distros? Is this really necessary? Do those bugs you speak about actually cause trouble for GCC if you make it use MPC (which I'm also not too happy about, fwiw)? I don't know if you can expose these particular bugs through GCC. The issue is that you can definitely see them in MPC through MPC testsuite failures if you e.g. build MPC with mpfr-2.3.0. So MPC has a minimum MPFR version requirement that it checks for during it's own configure time. I don't think it's fair to ask MPC to lower its configure checks for building if real bugs show up in their testsuite. We could keep lower GMP/MPFR version requirements in GCC, but if we hard-require MPC then it's kind of moot cause you'd have to get/build MPC somehow. I'm still open to making MPC optional for a transition period. But others have argued for making it hard-required. There are certainly valid reasons both ways IMHO. But I think that's something for another thread. My hope is that these version upgrades are reasonably simple. --Kaveh
Re: Call for MPC complex math library GCC testers on various platforms
On Wed, 18 Mar 2009, Ralf Wildenhues wrote: I tried to send the message below to the list, without subscribing. It was thus rejected. I then tried to send it to you off-list, which your mail server doesn't like either, due to unblock.secureserver.net. Would you please forward it for me? I have no intention to subscribe to yet another mailing list, nor to debug mail server issues from my provider, if they want feedback then they should *please* setup gmane.org or another gateway. Thanks, and sorry everyone else for bothering you, Ralf Ralf, thanks for your help, I forwarded your report. The MPC developers have kindly adjusted their mailing list to allow unsubscribed people to post. So if anyone was reluctant to join their list, you can now send your results without worrying. http://lists.gforge.inria.fr/pipermail/mpc-discuss/2009-March/000104.html Thanks, --Kaveh
Re: recent regression on darwin
On Thu, 12 Mar 2009, H.J. Lu wrote: Executing on host: /sw/src/fink.build/gcc44-4.3.999-20090312/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20090312/darwin_objdir/gcc/ /sw/src/fink.build/gcc44-4.3.999-20090312/gcc-4.4 -20090312/gcc/testsuite/gcc.dg/asm-b.c -O1 -lm -m32 -o ./asm-b.exe (timeout = 300) /sw/src/fink.build/gcc44-4.3.999-20090312/gcc-4.4-20090312/gcc/testsuite/gcc.dg/asm-b.c:27:bad register name `%sil' /sw/src/fink.build/gcc44-4.3.999-20090312/gcc-4.4-20090312/gcc/testsuite/gcc.dg/asm-b.c:27:`%si' not allowed with `movb' compiler exited with status 1 output is: It is Darwin specific. Linux is OK. Please find out which revision causes it. H.J. Actually x86-linux -m32 *with pic* does fail. Anytime you have a darwin error you cannot reproduce on linux, try adding -fpic as it often shows up that way. See: http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg01362.html --Kaveh
Re: The gcc-in-cxx branch now completes bootstrap
On Fri, 6 Mar 2009, Ian Lance Taylor wrote: I'm happy to report that the gcc-in-cxx branch can now bootstrap. That is, the code in gcc proper can now be compiled with a C++ compiler. Great work, thanks! I'm curious whether there are any detectable differences in the resulting compiler when built with g++ rather than gcc. E.g. testsuite regressions, changes in the speed or size of cc1, etc. Also, is cc1 linked with libstdc++.so ? Stuff like that. Would you please consider checking this? Thanks, --Kaveh -- Kaveh R. Ghazi gh...@caip.rutgers.edu
Re: libiberty testsuite builds with wrong compiler
On Mon, 23 Feb 2009, Paolo Bonzini wrote: Jack Howarth wrote: The same issue in the libiberty testsuite run can be seen with the Apple regress server log at http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip. If you search for test-demangle, you will find... I'm sure there is a bugzilla entry for that. Paolo PR29404 --Kaveh
Re: Creating imaginary inf/nan in GCC
From: Richard Guenther richard.guent...@gmail.com Thanks, I do want to test the middle-end. However I need to do more than just create the complex expression. I also have to pass it to a builtin that evaluates using MPC like __builtin_csin(). The fortran frontend evaluates complex transcendentals in fortran/simplify.c, not in the middle-end. So it wouldn't test what I want AFAICT. It's not a big deal, the nan cases are error paths that should *avoid* folding via MPC. If you go through memory the compiler should promote that to a register and constant propagate the result, isn't that enough? All the previous tests of this nature were in gcc.dg/torture/builtin-math-*.c and are done at all opt levels including -O0. I think your suggestion works, but only when optimizing. Also, I think it doesn't work with -fdump-tree-original, I'd have to inspect a different dump file. (Any thoughts on which one?) The obsessive part of my brain wants to keep everything the same as the other tests. :-) But I suppose it would work, I just have to tweek it with these things in mind. --Kaveh
Re: Creating imaginary inf/nan in GCC
From: Joseph S. Myers jos...@codesourcery.com On Thu, 29 Jan 2009, Kaveh R. GHAZI wrote: I don't think these results are a bug, rather it's just an artifact of the way complex multiplcation is done and having these special values in See bug 24581. Some aspects are a bug (GCC doesn't handle mixed real/complex arithmetic the way it should), some are the lack of imaginary types (though the only use of imaginary types I know of is this one for building up constants, and no-one on the Power ABI working group could find any implementation for Power Architecture that actually supports imaginary types). Thanks for the PR pointer. I'm going to ask the obvious question, if there's an obvious answer please excuse me. :-) Would it be sufficient and correct to treat (0.0 + I) * y as a special case for MULT_EXPR and just swap the real and imaginary parts of y in the result? --Kaveh
Re: Creating imaginary inf/nan in GCC
From: Tobias Burnus bur...@net-b.de Hi Kaveh, Kaveh R. GHAZI wrote: I'm trying to create complex number expressions that contain inf or nan in the imaginary part. I.e. (0 + inf I) or (0 + nan I). If it does not need to be C (e.g. to try MPC in the middle end), you could use Fortran: ! compile with gfortran -fno-range-check complex :: z z = cmplx(0.0, 0.0/0.0) print *, z end Tobias Thanks, I do want to test the middle-end. However I need to do more than just create the complex expression. I also have to pass it to a builtin that evaluates using MPC like __builtin_csin(). The fortran frontend evaluates complex transcendentals in fortran/simplify.c, not in the middle-end. So it wouldn't test what I want AFAICT. It's not a big deal, the nan cases are error paths that should *avoid* folding via MPC. Regards, --Kaveh
Creating imaginary inf/nan in GCC
Hi, I'm trying to create complex number expressions that contain inf or nan in the imaginary part. I.e. (0 + inf I) or (0 + nan I). However when I write (_builtin_nan() * 1.0i) I get (nan + nan I). For (__builtin_inf() * 1.0i) I get (nan + inf I). I don't think these results are a bug, rather it's just an artifact of the way complex multiplcation is done and having these special values in there. I had a similar problem getting negative zeros in the imaginary part, but I solved that using conj(0.0) and conj(-0.0). I don't think conj helps for inf/nan though. I know I can simply use a complex variable and set the real/imag parts separately, but I want a constant expression which I can pass as an argument to a builtin complex math function for writing testcases that fold (or not) and compile-time. Is there a way to get an imaginary inf or nan expression without having the real part get changed? Thanks, --Kaveh -- Kaveh R. Ghazi gh...@caip.rutgers.edu
Re: Serious code generation/optimisation bug (I think)
On Tue, 27 Jan 2009, James Dennett wrote: On Mon, Jan 26, 2009 at 11:52 PM, zol...@bendor.com.au wrote: I was debugging a function and by inserting the debug statement crashed the system. Some investigation revealed that gcc 4.3.2 arm-eabi (compiled from sources) with -O2 under some circumstances assumes that if a pointer is dereferenced, it can not be NULL therefore explicite tests against NULL can be later eliminated. That's an optimization permitted by the language standard, but possibly unhelpful on your particular target. It is a case of a more general situation: the compiler can assume that code containing undefined behavior (such as a null-pointer dereference) is not executed, or equivalently that a condition that would lead to the execution of UB is always false. I don't know how much work it would be to disable this optimization in gcc. -- James Try -fno-delete-null-pointer-checks. --Kaveh
Re: Xtensa port maintainer
On Mon, 5 Jan 2009, Sterling Augustine wrote: Could I ping on the issue described below? Bob can no longer maintain the Xtensa port for GCC, and I don't think he is even reading the GCC mailing list any more. For the forseeable future, I am responsible for the Xtensa port of GCC here at Tensilica. What should I do to move the process forward? Thanks, Sterling Sorry I missed this back when it was originally posted, and the other SC members likely did also. I'll try and get you going. There are several steps to moving the process forward. They generally need to be done in the order I'm presenting them. 1. The first thing that you need to ensure gets done is copyright assignment papers for your contributions to GCC. Your employer will need to also assign its rights. (One or both of these may already be done). See here for legal and other contribution guidelines: http://gcc.gnu.org/contribute.html 2. Next you need to get write-after-approval access. More info here: http://gcc.gnu.org/svnwrite.html 3. After familiarizing yourself with the above and fulfilling the legal requirements, you can then fill out this form to get access. I guess you can use Bob as the reference who approved it: http://sourceware.org/cgi-bin/pdw/ps_form.cgi 4. Once these are done, the steering committee may decide to grant you maintainership. We generally prefer to see one submit a few patches and see how well they work together with other developers. However since Bob recommended you, the port is unmaintained at the moment and your maintainership perview would be localized to the xtensa subdir it may be possible to expedite this. Let me know the status of the above issues and I will forward your proposal to the SC. Regards, --Kaveh -- Kaveh R. Ghazi gh...@caip.rutgers.edu
Re: MPFR-2.4.0 Release Candidate
From: Vincent Lefevre vincent+...@vinc17.org On 2008-12-13 01:46:21 -0500, Kaveh R. GHAZI wrote: Changes from version 2.3.2 to version 2.4.0: [...] - Bug fixes. Are there any MPFR bugs fixed in 2.4.0 that can be exposed through the limited way GCC uses MPFR? The announce was incorrect. It should have said: Changes from versions 2.3.* to version 2.4.0: like in the NEWS file. AFAIK, I backported all the bug fixes to the 2.3 branch for the 2.3.2 version. I still need to publish a patch on the web page for https://gforge.inria.fr/tracker/index.php?func=detailaid=6604group_id=136atid=619 (corresponding to r5664), but I don't know if GCC is affected by this bug. GCC does not currenlty use mpfr_strtofr, which is mentioned in the above bug. So I'll assume upgrading from 2.3.2 to 2.4.0 fixes no GCC-relevant MPFR bugs, and therefore no upgrade to the GCC docs for which minimum MPFR version to use is necessary. Regards, --Kaveh
Re: MPFR-2.4.0 Release Candidate
On Fri, 12 Dec 2008, Vincent Lefevre wrote: The release of MPFR 2.4.0 (andouillette sauce moutarde) is imminent. Please help to make this release as good as possible by downloading and testing this release candidate: Changes from version 2.3.2 to version 2.4.0: [...] - Bug fixes. Vincent, Are there any MPFR bugs fixed in 2.4.0 that can be exposed through the limited way GCC uses MPFR? Thanks, --Kaveh -- Kaveh R. Ghazi gh...@caip.rutgers.edu
Graphite merge regressed PR 35107 ?
PR 35107 appears to have regressed on mainline. It was originally fixed on the trunk and 4.3 back in February: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35107 http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00187.html The summary is that gmp and mpfr and unnecessarily linked into all executables (e.g. xgcc, gcov) whereas they should only be used for programs that are linked with libbackend.a like cc1. It matters when gmp/mpfr are shared libs. There's no reason to slow down the startup of all programs we provide by dynamically loading these libraries. During the graphite merge, $GMPLIBS was added back to the generic $LIBS variable and gets linked into everything. Is this really necessary? http://gcc.gnu.org/viewcvs/trunk/gcc/Makefile.in?r1=139854r2=139893 If it's not necessary, IMHO this should be fixed again before we branch 4.4. I think CLOOGLIBS and PPLLIBS need to be moved to the right places, but I don't have those libraries to test it myself. Since it would touch all the places my original patch did, perhaps it would be best to create a BACKENDLIBS and/or BACKENDDEPS variable and hook GMPLIBS, CLOOGLIBS and PPLLIBS in there. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Graphite merge regressed PR 35107 ?
PR 35107 appears to have regressed on mainline. It was originally fixed on the trunk and 4.3 back in February: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35107 http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00187.html The summary is that gmp and mpfr and unnecessarily linked into all executables (e.g. xgcc, gcov) whereas they should only be used for programs that are linked with libbackend.a like cc1. It matters when gmp/mpfr are shared libs. There's no reason to slow down the startup of all programs we provide by dynamically loading these libraries. During the graphite merge, $GMPLIBS was added back to the generic $LIBS variable and gets linked into everything. Is this really necessary? http://gcc.gnu.org/viewcvs/trunk/gcc/Makefile.in?r1=139854r2=139893 If it's not necessary, IMHO this should be fixed again before we branch 4.4. I think CLOOGLIBS and PPLLIBS need to be moved to the right places, but I don't have those libraries to test it myself. Since it would touch all the places my original patch did, perhaps it would be best to create a BACKENDLIBS and/or BACKENDDEPS variable and hook GMPLIBS, CLOOGLIBS and PPLLIBS in there. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
From: Geoff Keating [EMAIL PROTECTED]
I found that simply building MPFR in a non-default location (configure
--prefix make) and then pointing GCC at it with --with-mpfr, as in
the installation instructions, causes the bootstrap to fail when first
running xgcc, because xgcc can't find the built MPFR dynamic library.
First I'd like to thank you for running your regression tester, and I'm
sorry this upgrade cause you so much difficulty.
The issue you describe is PR 21547.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21547
It's important IMHO to point out that this issue is not confined to MPFR.
While MPFR's more stringent version requirements expose the problem more
often, you'll find the same issue with GMP as well if you compile and
install your own copy of that library in a non-default location.
Basically, the problem is that the bootstrap process doesn't encode
the -rpath during the link process of cc1. Doing this in a portable fashion
and resolving the PR requires linking cc1 et al. with libtool. I don't have
any experience with libtool myself. However since we use it elsewhere in
GCC, it may be easy to incorporate.
(Any libtool experts available to help out, or at least talk us through the
process?)
If this is what users (or even developers) of GCC are supposed to be
doing, I'd suggest more documentation on what to do and how to do it.
I think the steps you (or your assistant) went through was unfortunately
unnecessarily complicated. The solution I use is to build MPFR and/or GMP
using --disable-shared. Then you can install them anywhere you like, pass
the location with --with-{mpfr,gmp} to GCC and since only the static library
is available everything links and runs fine.
Do you think putting this recommendation in the docs somewhere would have
been useful to you in this situation? If so, I would be happy to prepare a
patch.
Regards,
--Kaveh
Re: [PATCH]: GMP/MPFR in-tree build instructions [Was: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)]
From: Tobias Schlüter [EMAIL PROTECTED]
[EMAIL PROTECTED] and @option{--with-gmp-include}. Alternatively,
+if a GMP source ditribution is found in a subdirectory of you GCC
+sources named @file{gmp}, it will be built together with [EMAIL PROTECTED]
+Library is not installed in your default library search path. See also
[EMAIL PROTECTED] and @option{--with-mpfr-include}.
+Alternatively, if a MPFR source ditribution is found in a subdirectory
+of you GCC sources named @file{mpfr}, it will be built together with
[EMAIL PROTECTED]
Typos:
s/ditribution/distribution/
s/you GCC sources/your GCC sources/
Both occur twice.
--Kaveh
Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)
From: Adrian Bunk [EMAIL PROTECTED] On Sat, Oct 04, 2008 at 09:33:48PM -0400, Kaveh R. GHAZI wrote: Since we're in stage3, I'm raising the issue of the MPFR version we require for GCC, just as in last year's stage3 for gcc-4.3: http://gcc.gnu.org/ml/gcc/2007-12/msg00298.html I'd like to increase the minimum MPFR version to 2.3.0, (which has been released since Aug 2007). The recommended version of MPFR can be bumped to the latest which is 2.3.2. ... Considering that your patch removes the conditionals on MPFR versions from the code (good!), is there any reason for gcc to keep this unusual minimum/recommended split in the requirement? Either 2.3.0 is good enough, or 2.3.2 contains some critical fix and should be the minimum version. The last time this came up, the consensus was that we should not hard fail the configure script even if the user would then be missing some mpfr bugfix in the latest/greatest release. That's why we have the minimum/recommended split. But I see no reason not to encourage people and/or make them aware of the need to upgrade if they are so inclined. Whether a particular fix is critical can be in the eye of the beholder. --Kaveh
Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)
From: Richard Guenther [EMAIL PROTECTED] On Sun, Oct 5, 2008 at 3:33 AM, Kaveh R. GHAZI [EMAIL PROTECTED] wrote: Okay for mainline? Ok if there are no objections within the week. Thanks, Richard. Great, thanks. Can I get an explicit ack from a fortran maintainer as well? Regards, --Kaveh
[PATCH]: bump minimum MPFR version, (includes some fortran bits)
Since we're in stage3, I'm raising the issue of the MPFR version we
require for GCC, just as in last year's stage3 for gcc-4.3:
http://gcc.gnu.org/ml/gcc/2007-12/msg00298.html
I'd like to increase the minimum MPFR version to 2.3.0, (which has been
released since Aug 2007). The recommended version of MPFR can be bumped
to the latest which is 2.3.2.
Doing this will allow me to remove several MPFR cpp conditionals in the
middle-end as well as in the fortran frontend. It also helps for future
work I plan to do with folding c99 complex number math functions, as that
work will require mpfr-2.3.0.
Patch bootstrapped on x86_64-unknown-linux-gnu using mpfr-2.3.2, no
regresions. I also configured with mpfr-2.2.0 to ensure that GCC still
fails the relevant checks with older versions of mpfr.
If approved, I'll again wait a week before installing so people can
upgrade their regtesters if necessary.
Okay for mainline?
Thanks,
--Kaveh
2008-10-04 Kaveh R. Ghazi [EMAIL PROTECTED]
* configure.ac (MPFR check): Bump minimum version to 2.3.0 and
recommended version to 2.3.2.
* builtins.c: Remove MPFR_VERSION_NUM(2,3,0) conditionals.
* doc/install.texi: Bump recommended MPFR to 2.3.2.
* configure: Regenerate.
fortran:
* simplify.c: Remove MPFR_VERSION_NUM(2,3,0) conditionals.
diff -rup orig/egcc-SVN20081001/configure.ac egcc-SVN20081001/configure.ac
--- orig/egcc-SVN20081001/configure.ac 2008-09-06 02:00:10.0 +0200
+++ egcc-SVN20081001/configure.ac 2008-10-04 20:19:15.0 +0200
@@ -1267,11 +1267,11 @@ if test -d ${srcdir}/gcc test x$have
if test x$have_gmp = xyes; then
saved_LIBS=$LIBS
LIBS=$LIBS $gmplibs
-dnl MPFR 2.2.1 is acceptable, but MPFR 2.3.0 is better.
+dnl MPFR 2.3.0 is acceptable, but MPFR 2.3.2 is better.
AC_MSG_CHECKING([for correct version of mpfr.h])
AC_TRY_LINK([#include gmp.h
#include mpfr.h],[
-#if MPFR_VERSION MPFR_VERSION_NUM(2,2,1)
+#if MPFR_VERSION MPFR_VERSION_NUM(2,3,0)
choke me
#endif
mpfr_t n;
@@ -1284,7 +1284,7 @@ if test -d ${srcdir}/gcc test x$have
mpfr_subnormalize (x, t, GMP_RNDN);
], [AC_TRY_LINK([#include gmp.h
#include mpfr.h],[
-#if MPFR_VERSION MPFR_VERSION_NUM(2,3,0)
+#if MPFR_VERSION MPFR_VERSION_NUM(2,3,2)
choke me
#endif
mpfr_t n; mpfr_init(n);
@@ -1295,7 +1295,7 @@ if test -d ${srcdir}/gcc test x$have
CFLAGS=$saved_CFLAGS
if test x$have_gmp != xyes; then
-AC_MSG_ERROR([Building GCC requires GMP 4.1+ and MPFR 2.3.0+.
+AC_MSG_ERROR([Building GCC requires GMP 4.1+ and MPFR 2.3.2+.
Try the --with-gmp and/or --with-mpfr options to specify their locations.
Copies of these libraries' source code can be found at their respective
hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
diff -rup orig/egcc-SVN20081001/gcc/builtins.c egcc-SVN20081001/gcc/builtins.c
--- orig/egcc-SVN20081001/gcc/builtins.c2008-08-30 02:00:13.0
+0200
+++ egcc-SVN20081001/gcc/builtins.c 2008-10-04 20:22:06.0 +0200
@@ -231,13 +231,11 @@ static tree do_mpfr_arg2 (tree, tree, tr
static tree do_mpfr_arg3 (tree, tree, tree, tree,
int (*)(mpfr_ptr, mpfr_srcptr, mpfr_srcptr,
mpfr_srcptr, mp_rnd_t));
static tree do_mpfr_sincos (tree, tree, tree);
-#if MPFR_VERSION = MPFR_VERSION_NUM(2,3,0)
static tree do_mpfr_bessel_n (tree, tree, tree,
int (*)(mpfr_ptr, long, mpfr_srcptr, mp_rnd_t),
const REAL_VALUE_TYPE *, bool);
static tree do_mpfr_remquo (tree, tree, tree);
static tree do_mpfr_lgamma_r (tree, tree, tree);
-#endif
/* Return true if NODE should be considered for inline expansion regardless
of the optimization level. This means whenever a function is invoked with
@@ -10112,7 +10110,6 @@ fold_builtin_1 (tree fndecl, tree arg0,
dconstm1, NULL, false);
break;
-#if MPFR_VERSION = MPFR_VERSION_NUM(2,3,0)
CASE_FLT_FN (BUILT_IN_J0):
if (validate_arg (arg0, REAL_TYPE))
return do_mpfr_arg1 (arg0, type, mpfr_j0,
@@ -10136,7 +10133,6 @@ fold_builtin_1 (tree fndecl, tree arg0,
return do_mpfr_arg1 (arg0, type, mpfr_y1,
dconst0, NULL, false);
break;
-#endif
CASE_FLT_FN (BUILT_IN_NAN):
case BUILT_IN_NAND32:
@@ -10252,7 +10248,6 @@ fold_builtin_2 (tree fndecl, tree arg0,
switch (fcode)
{
-#if MPFR_VERSION = MPFR_VERSION_NUM(2,3,0)
CASE_FLT_FN (BUILT_IN_JN):
if (validate_arg (arg0, INTEGER_TYPE)
validate_arg (arg1, REAL_TYPE))
@@ -10279,7 +10274,6 @@ fold_builtin_2 (tree fndecl, tree arg0,
validate_arg(arg1, POINTER_TYPE))
return do_mpfr_lgamma_r (arg0, arg1, type);
break;
-#endif
CASE_FLT_FN (BUILT_IN_ATAN2):
if (validate_arg (arg0, REAL_TYPE)
@@ -10436,14 +10430,12 @@ fold_builtin_3 (tree
Re: Adding to G++: Adding a warning on throwing unspecified exceptions.
On Sun, 21 Sep 2008, NightStrike wrote: On Sun, Sep 21, 2008 at 12:36 PM, Brian Dessent [EMAIL PROTECTED] wrote: Simon Hill wrote: http://gcc.gnu.org/onlinedocs/gccint/index.html. (Of course I was horrified to see it's not written in C++, and it's loaded with macros --- why??). You seem to refer to g++ as if it's a separate program from gcc but it's really not. All of the middle- and back-end code is shared between the language front-ends, so if you introduce C++ there you now require a pre-existing C++ bootstrap compiler even for people that have no interest or need for C++ language support and are only building a C (or Fortran or Java or Ada) compiler. A lot of people have a problem with I think java requires c++. It does, but only to build the target libraries, not to bootstrap. It uses the just-built G++ to do that. Ada is the only frontend right now where you need a pre-existing compiler other than C to *bootstrap* it.
Re: Anyone/anything still using CVS on gcc.gnu.org?
From: Dave Korn [EMAIL PROTECTED] Hear, hear. The name of the list is an arbitrary label, not instructions on what kind of client to use to access the repository; why, just for the sake of making it correct in some non-functional sense of the word should everyone in the world have to adjust their whitelists/forwards/spamfilters/webarchives/etc.? There should be a fairly clear benefit before asking all those people to do all that work. Jeez, I didn't realize people felt so viscerally against this. I thought the impact on users would be small. I.e. I'm curious who actually subscribes to the gcc-cvs list. Is it a large list? (I don't know.) I don't think humans post to it either, it only gets machine generated messages from checkins. So it's not like address books would have to be updated. (Personally I only access it from the website if I'm looking for something specific). But seems like you think I'm wrong on how difficult this change would be for users. Okay, no big deal. A comment on the webpage I mentioned could be another way to address my point about the name being misleading...
Re: Anyone/anything still using CVS on gcc.gnu.org?
On Sun, 20 Jul 2008, Gerald Pfeifer wrote: Except for wwwdocs, that is? As I mentioned before, I'd love to get wwwdocs converted to SVN, and in the course of this I noticed some historic configurations which I believe aren't be used any more and haven't, for years. Unless I hear to the contrary, I plan on removing these with the patch below in a couple of days. When looking at it, please keep in mind that this affects our CVS repository only, not SVN! Gerald The mailing list webpage still refers to CVS: http://gcc.gnu.org/lists.html Can we rename these lists (perhaps preserving an alias for the old names) so that they reflect reality? I would suggest NOT using svn in the list name in case we switch version control software yet again, however unlikely doing so may be today. E.g. gcc-cvs - gcc-checkins, (or similar) etc. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Anyone/anything still using CVS on gcc.gnu.org?
On Sun, 20 Jul 2008, Richard Guenther wrote: The mailing list webpage still refers to CVS: http://gcc.gnu.org/lists.html Can we rename these lists (perhaps preserving an alias for the old names) so that they reflect reality? I don't see a reason to rename the list. Richard. We don't use cvs, so [EMAIL PROTECTED] is misleading. --Kaveh
Re: C++ Warnings on trunk
On Tue, 8 Jul 2008, Andreas Schwab wrote: Kaveh Ghazi [EMAIL PROTECTED] writes: Right, here's the original link where I mention it: http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01658.html This involves a cast from one type to another through a void*. I haven't been able to convince myself that this is completely safe. If someone understands why the code is violating type-safety intentionally and can explain why it's always safe, I would be happy to insert the appropriate cast and fix it. The two types bitmap_element and bitmap_head share a common initial sequence, and when following through -heads only the first pointer is ever used. If you define a union type containing the two structs and make it visible at any point using that cast that would make it completely safe to the letter of the standard (6.5.2.3#5). Andreas. Thanks for the explanation. However I don't understand why these conditions make it safe. First, while these two structs share an initial sequence of members, they don't seem to mean the same thing, i.e. they are of type bitmap_element and named next/prev vs first/current. Second, we can't guarantee that only the first pointer is ever used because in both cases the bitmap object escapes back out of the function and we have no control over how it's handled. It seems to me that the union trick is just a way to violate type-safety without seeing any warnings, same as casting to void* was. :-) Needless to say, I don't understand this (IMHO convoluted) part of the bitmap implementation. So I'd rather leave it to someone who does. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: C++ Warnings on trunk
From: NightStrike [EMAIL PROTECTED] On 7/8/08, Ian Lance Taylor [EMAIL PROTECTED] wrote: NightStrike [EMAIL PROTECTED] writes: I was under the impression that these would be cleaned up before the -W options were applied to the trunk. It's pretty hard to clean up all the warnings for every possible target. Also these are only warnings--this code is not compiled with -Werror. In this case, I argue that this code is always compiled with a C compiler, and should never be compiled by a C++ compiler. Therefore, I believe it is wrong for this code to be compiled with the -Wc++-compat warning enabled. This should be fixed somewhere in the configure script and/or Makefile. Is someone currently taking care of that? Yeah, it's on my list.
Re: (new) Failure building GFortran (Cygwin)
On Tue, 8 Jul 2008, Angelo Graziosi wrote:
--- gcc-4.4-20080704.orig/gcc/ggc-page.c 2008-06-29 06:39:16.0 +0200
+++ gcc-4.4-20080704/gcc/ggc-page.c 2008-07-05 12:00:20.90625 +0200
@@ -799,7 +799,7 @@
alloc_size = GGC_QUIRE_SIZE * G.pagesize;
else
alloc_size = entry_size + G.pagesize - 1;
- allocation = xmalloc (alloc_size);
+ allocation = XNEWVEC (char, alloc_size);
page = (char *) (((size_t) allocation + G.pagesize - 1)
-G.pagesize);
head_slop = page - allocation;
@@ -842,7 +842,7 @@
struct page_entry *e, *f = G.free_pages;
for (a = enda - G.pagesize; a != page; a -= G.pagesize)
{
- e = xcalloc (1, page_entry_size);
+ e = XCNEWVAR (struct page_entry, page_entry_size);
e-order = order;
e-bytes = G.pagesize;
e-page = a;
FWIW, this looks correct to me. (However I can't approve it).
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Bootstrap failures due to C++ warnings with --enable-gather-detailed-memory-stats
On Thu, 3 Jul 2008, Kaveh R. GHAZI wrote: On Thu, 3 Jul 2008, Diego Novillo wrote: Can you suggest a few things to try? E.g. I did --with-gc=zone and a couple of errors cropped up. If there are other configurations that come to mind, let me know. I had these in mind: --disable-checking --enable-checking=all,valgrind (you got time to go on holiday with this one) --enable-coverage Diego. I tried --disable-checking and --enable-coverage, no problems bootstrap completed. Using --with-gc=zone had some warnings which are fixed below. I'll try extra --enable-checking options overnight. So I tried --enable-checking=all,valgrind and it died in stage2 running genautomata. Plus it took a hideously long time even on an 8x cpu box just to get that far. Then I tried a --disable-bootstrap configuration using a regular recent mainline build in CC just to see the warnings. That died in the same place. When I switched to gcc-4.3 in CC then I could at least make the entire directory once to see the warnings. There was only one additional warning in this configuration. Tested via make gcc.o on x86_64-unknown-linux-gnu configured with --disable-bootstrap --enable-checking=all,valgrind. The one warning was eliminated. Okay for mainline? Thanks, --Kaveh 2008-07-07 Kaveh R. Ghazi [EMAIL PROTECTED] * gcc.c (execute): Fix -Wc++-compat warning. --- orig/egcc-SVN20080706/gcc/gcc.c 2008-06-27 18:58:34.0 +0200 +++ egcc-SVN20080704/gcc/gcc.c 2008-07-06 08:43:30.0 +0200 @@ -2973,7 +2973,7 @@ execute (void) for (argc = 0; commands[i].argv[argc] != NULL; argc++) ; - argv = alloca ((argc + 3) * sizeof (char *)); + argv = XALLOCAVEC (const char *, argc + 3); argv[0] = VALGRIND_PATH; argv[1] = -q;
Re: Bootstrap failures due to C++ warnings with --enable-gather-detailed-memory-stats
On Thu, 3 Jul 2008, Diego Novillo wrote: I wonder if other major configuration modes may also trigger warnings (e.g., --disable-checking). I tried --enable-checking=release and that works fine. Diego. Based on history there's a good chance they'll each have a few minor nits. Can you suggest a few things to try? E.g. I did --with-gc=zone and a couple of errors cropped up. If there are other configurations that come to mind, let me know. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Bootstrap failures due to C++ warnings with --enable-gather-detailed-memory-stats
On Thu, 3 Jul 2008, Diego Novillo wrote:
Can you suggest a few things to try? E.g. I did --with-gc=zone and a
couple of errors cropped up. If there are other configurations that come
to mind, let me know.
I had these in mind:
--disable-checking
--enable-checking=all,valgrind (you got time to go on holiday with this one)
--enable-coverage
Diego.
I tried --disable-checking and --enable-coverage, no problems bootstrap
completed. Using --with-gc=zone had some warnings which are fixed below.
I'll try extra --enable-checking options overnight.
Meantime, patch below bootstrapped with --with-gc=zone on
x86_64-unknown-linux-gnu. Okay for mainline?
Thanks,
--Kaveh
2008-07-04 Kaveh R. Ghazi [EMAIL PROTECTED]
* ggc-zone.c (lookup_page_table_if_allocated,
set_page_table_entry, zone_find_object_size, alloc_small_page,
alloc_large_page, ggc_free, gt_ggc_m_S, ggc_marked_p, init_ggc,
new_ggc_zone, init_ggc_pch, ggc_pch_this_base, ggc_pch_read): Fix
-Wc++-compat and/or -Wcast-qual warnings.
diff -rup orig/egcc-SVN20080703/gcc/ggc-zone.c egcc-SVN20080703/gcc/ggc-zone.c
--- orig/egcc-SVN20080703/gcc/ggc-zone.c2008-06-07 02:00:13.0
+0200
+++ egcc-SVN20080703/gcc/ggc-zone.c 2008-07-04 01:32:40.0 +0200
@@ -541,7 +541,7 @@ lookup_page_table_if_allocated (const vo
return NULL;
/* We might have a page entry which does not correspond exactly to a
system page. */
- if (base[L1][L2] (char *) p base[L1][L2]-page)
+ if (base[L1][L2] (const char *) p base[L1][L2]-page)
return NULL;
return base[L1][L2];
@@ -566,7 +566,7 @@ set_page_table_entry (void *p, page_entr
goto found;
/* Not found -- allocate a new table. */
- table = xcalloc (1, sizeof(*table));
+ table = XCNEW (struct page_table_chain);
table-next = G.lookup;
table-high_bits = high_bits;
G.lookup = table;
@@ -579,7 +579,7 @@ found:
L2 = LOOKUP_L2 (p);
if (base[L1] == NULL)
-base[L1] = xcalloc (PAGE_L2_SIZE, sizeof (page_entry *));
+base[L1] = XCNEWVEC (page_entry *, PAGE_L2_SIZE);
base[L1][L2] = entry;
}
@@ -715,7 +715,7 @@ zone_find_object_size (struct small_page
unsigned int start_word = zone_get_object_alloc_word (object_midptr);
unsigned int start_bit = zone_get_object_alloc_bit (object_midptr);
size_t max_size = (page-common.page + SMALL_PAGE_SIZE
-- (char *) object);
+- (const char *) object);
return zone_object_size_1 (page-alloc_bits, start_word, start_bit,
max_size);
@@ -898,7 +898,7 @@ alloc_small_page (struct alloc_zone *zon
memory order. */
for (i = G.quire_size - 1; i = 1; i--)
{
- e = xcalloc (1, G.small_page_overhead);
+ e = XCNEWVAR (struct small_page_entry, G.small_page_overhead);
e-common.page = page + (i GGC_PAGE_SHIFT);
e-common.zone = zone;
e-next = f;
@@ -908,7 +908,7 @@ alloc_small_page (struct alloc_zone *zon
zone-free_pages = f;
- entry = xcalloc (1, G.small_page_overhead);
+ entry = XCNEWVAR (struct small_page_entry, G.small_page_overhead);
entry-common.page = page;
entry-common.zone = zone;
set_page_table_entry (page, entry-common);
@@ -935,7 +935,7 @@ alloc_large_page (size_t size, struct al
size_t needed_size;
needed_size = size + sizeof (struct large_page_entry);
- page = xmalloc (needed_size);
+ page = XNEWVAR (char, needed_size);
entry = (struct large_page_entry *) page;
@@ -1439,7 +1439,7 @@ ggc_free (void *p)
/* Add the chunk to the free list. We don't bother with coalescing,
since we are likely to want a chunk of this size again. */
- free_chunk (p, size, page-zone);
+ free_chunk ((char *)p, size, page-zone);
}
}
@@ -1494,7 +1494,7 @@ gt_ggc_m_S (const void *p)
a STRING_CST. */
gcc_assert (offset == offsetof (struct tree_string, str));
p = ((const char *) p) - offset;
- gt_ggc_mx_lang_tree_node ((void *) p);
+ gt_ggc_mx_lang_tree_node (CONST_CAST(void *, p));
return;
}
@@ -1560,7 +1560,7 @@ int
ggc_marked_p (const void *p)
{
struct page_entry *page;
- const char *ptr = p;
+ const char *ptr = (const char *) p;
page = zone_get_object_page (p);
@@ -1686,7 +1686,7 @@ init_ggc (void)
if (GGC_PAGE_SIZE == G.pagesize)
{
/* We have a good page, might as well hold onto it... */
- e = xcalloc (1, G.small_page_overhead);
+ e = XCNEWVAR (struct small_page_entry, G.small_page_overhead);
e-common.page = p;
e-common.zone = main_zone;
e-next = main_zone.free_pages;
@@ -1714,7 +1714,7 @@ new_ggc_zone_1 (struct alloc_zone *new_z
struct alloc_zone *
new_ggc_zone (const char * name)
{
- struct alloc_zone *new_zone = xcalloc (1, sizeof (struct alloc_zone));
+ struct alloc_zone *new_zone = XCNEW (struct
Re: GCC 4.3.2 Status Report (2008-06-22)
On Sun, 22 Jun 2008, Joseph S. Myers wrote: Status == The GCC 4.3 branch is open for commits under normal release branch rules. The 4.3.2 release is expected around 2008-08-06. Quality Data Priority# Change from Last Report --- --- P1 8 +- 0 P2112 - 2 P3 2 +- 0 --- --- Total 122 - 2 I'd like to see PR bootstrap/33304 fixed for gcc-4.3.2. It's a bootstrap problem on solaris2 using sun's cc. Patches have been posted to fix it and I included links for them in the PR. However they haven't been approved for mainline yet. I think we have enough time between now and the Aug 6th gcc-4.3.2 release date to get them in the trunk and 4.3.x branch. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Should we remove java from the default bootstrap languages?
On Sat, 21 Jun 2008, Andrew Haley wrote: Steven Bosscher wrote: On Sat, Jun 21, 2008 at 12:41 AM, Kaveh R. Ghazi [EMAIL PROTECTED] wrote: Fundamentally, our philosophy has been to catch errors *before* they get into the repository. Sure one day of breaking the trunk isn't so bad, but when it breaks it affects hundreds of developers and it adds up. But, for languages that are not enabled by default, no-one is directly affected except the people who might have caused the breakage, and the people who are working on the broken part of the compiler. They are directly affected by these errors, but they don't know: the middle-end bugs revealed by the libjava build and testing are real bugs in other languages too, they're just not detected by bootstrap test. Andrew. Andrew, I think you hit the heart of this argument. The current bootstrap and testsuite doesn't ensure complete code coverage testing for GCC. Having more languages, libraries and their associated testsuites uncovers more bugs that would otherwise go undetected and remain hidden in the core middle-end. These hidden bugs could possible be triggered in C, C++ and/or fortran, but our current testsuite may not trigger them by chance whereas java or objc++ or whatever else we include might expose them during bootstrap. The argument for switching off java (that it takes too long) could be applied to C++ as well. The libstdc++ testsuite takes longer for me than the java one. But I don't recommend eliminating that either. How widespread a language is used is not the determining factor in whether we should activate it by default. Many people have vouched for the fact that java exposes middle-end bugs not uncovered by the other languages. That is where the worth of including it is found. IMHO, having more languages and testsuites in the bootstrap process enhances the quality of GCC. I sympathize with the problems of regtest duration. I believe some of this could be addressed through making things run in parallel better. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Should we remove java from the default bootstrap languages?
On Fri, 20 Jun 2008, Tom Tromey wrote: Andrew My suggestion is that we build jc1 but not libgcj by default. Andrew HOWEVER, we build libgcj on the autobuilders and make very sure that Andrew if anyone breaks the libgcj build they have to fix their breakage, Andrew even tho it's not part of the default build. That will prevent most Andrew of the bitrot while we figure out how to go forward. Good idea. Maybe instead of removing libgcj from the default builds, we can just say that maintainers can --disable-libjava for regression testing purposes. This would make testers continue to test libgcj by default. Tom Ugh, I think this is a terrible idea. It took me all of zero days to find an example of libjava breaking when someone didn't test it: http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01351.html If we make not testing java an actual policy, you can expect much more breakage. Things that aren't tested suffer bitrot, plain and simple. That aside, our current policy already allows e.g. not testing java if your change is to a part of the compiler that can't possible affect it. E.g. changing the fortran or ada frontends doesn't affect java. But IMHO we shouldn't relax the testing rules for the overlapping parts if we want to keep our bits all working nicely. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Should we remove java from the default bootstrap languages?
On Fri, 20 Jun 2008, Diego Novillo wrote: On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI [EMAIL PROTECTED] wrote: That aside, our current policy already allows e.g. not testing java if your change is to a part of the compiler that can't possible affect it. I didn't make it completely clear, but my suggestion was mostly to help us middle/back-end hackers. Diego. Yeah, that's what worries me, all roads lead through the middle-end. :-) --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Should we remove java from the default bootstrap languages?
From: Joe Buck [EMAIL PROTECTED] On Fri, Jun 20, 2008 at 05:16:41PM -0400, Kaveh R. GHAZI wrote: On Fri, 20 Jun 2008, Diego Novillo wrote: On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI [EMAIL PROTECTED] wrote: That aside, our current policy already allows e.g. not testing java if your change is to a part of the compiler that can't possible affect it. I didn't make it completely clear, but my suggestion was mostly to help us middle/back-end hackers. Diego. Yeah, that's what worries me, all roads lead through the middle-end. :-) But if I understood the proposal correctly, auto-testers (as well as Java developers) would continue to test Java on a daily basis, and anyone submitting a patch that caused breakage would be responsible for fixing the damage or reverting. If problems are always detected within one day, the opportunities for rot are limited. Fundamentally, our philosophy has been to catch errors *before* they get into the repository. Sure one day of breaking the trunk isn't so bad, but when it breaks it affects hundreds of developers and it adds up. Everyone separately either stops and waits, or tracks down which patch it was and reverts it so they can continue working. Either way lots of time is wasted, and this serves as a counter argument against the time spent testing patches with java enabled. I suspect some people run their tests overnight, in that case it doesn't matter if the regtest takes 2 hours or 5. Either way the results will be waiting for you in the morning. I don't like the idea of taking java out, but if we do I suggest we swap in objc++. That would only add 42 seconds to the bootstrap and test process. :-) http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01763.html --Kaveh
Re: gcc-in-cxx branch created
On Wed, 18 Jun 2008, Doug Gregor wrote: On Wed, Jun 18, 2008 at 2:01 AM, Ian Lance Taylor [EMAIL PROTECTED] wrote: As I promised at the summit today, I have created the branch gcc-in-cxx (I originally said gcc-in-c++, but I decided that it was better to avoid possible meta-characters). The goal of this branch is to develop a version of gcc which is compiled with C++. Here are my presentation slides in PDF format: http://airs.com/ian/cxx-slides.pdf . I, personally, think this would be a great step forward from a maintainability perspective, especially if we use those C++ features that can help eliminate many of the macros we currently have in GCC. Agreed, this is a terrific idea. The first step seems to be to make sure that GCC compiles as C++ now (I know there's been work in this direction), and for us to make sure that this property is maintained in the mainline compiler. The C++ front end would be a good place to start moving toward C++. - Doug I read through your slides and I'm interested in contributing. I didn't see the presentation itself so I don't know if this suggestion is redundant. However I believe some work could be done (maybe even on mainline) to activate -Wc++-compat during bootstrap as a warning only, (not an error). E.g.: #pragma GCC diagnostic warning -Wc++-compat This would help clean up some of the easy stuff and make the branch diffs much smaller. We could also extend -Wc++-compat to warn about more things, using C++ reserved keywords like class in C comes to mind. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: gcc-in-cxx branch created
On Thu, 19 Jun 2008, Kaveh R. GHAZI wrote: [...] I believe some work could be done (maybe even on mainline) to activate -Wc++-compat during bootstrap as a warning only, (not an error). E.g.: #pragma GCC diagnostic warning -Wc++-compat This would help clean up some of the easy stuff and make the branch diffs much smaller. Some stats, I ran a quick make including the above #pragma in system.h, I get 1089 new warnings. Running this grep pipe on the output file: grep 'request for implicit conversion' output|sed 's%[^/]*\.[chl]:.*%%'|sort |uniq -c yields: 6 754 ../../egcc-SVN20080619/gcc/ 231 ../../egcc-SVN20080619/gcc/fortran/ 72 ../../egcc-SVN20080619/gcc/java/ 26 ../../egcc-SVN20080619/gcc/objc/ The blank 6 are from insn-automata.c, which has no path prefix and gets nulled out by my shellism. There are no warnings from the C++ dir because someone already cleaned it up and added -Wc++-compat, likewise for libiberty. (Who did that, Gaby?) These are mechanical and can be fixed with simple casts. Again, IMHO these non-controversial patches should go straight into mainline. Once done we can -Werror this warning and avoid regressions. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: gcc-in-cxx branch created
On Thu, 19 Jun 2008, Gabriel Dos Reis wrote: Main offenders (last time I checked) seem be to (1) middle end and back end files who play `enum inheritance' tricks. (2) use of C++ keywords as variable names. (3) implicit conversion from void* to T* -- but we should have ver few of those now, because I did eliminate those I was aware of Um, no. I see 1089 warnings of type #3. :-/ (4) minor: some differences in `const' semantics. -Wc++-compat needs to be augmented to check for C++ keywords (a deficiency in current implementation). Yes, PR21759. Will you be able to work on that? (Or at least, list in the PR what the reserved keywords are in case someone else wants to?) I'm `on the road' and my laptop is a `windows only' box. These are mechanical and can be fixed with simple casts. Again, IMHO these non-controversial patches should go straight into mainline. Once done we can -Werror this warning and avoid regressions. Strongly agree. Would you mind submitting the patch for activation of -Wc++-compat? Done. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: gcc-in-cxx branch created
On Thu, 19 Jun 2008, Ian Lance Taylor wrote: These are mechanical and can be fixed with simple casts. Again, IMHO these non-controversial patches should go straight into mainline. Once done we can -Werror this warning and avoid regressions. Yes, I agree. Ian Okay, the patch to activate -Wc++-compat is installed on mainline. I'd like to clean up some of the new warnings, but it sounds like you've got some of this already done behind the scenes. E.g.: http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01264.html I'd like to avoid stomping on each other and duplicating work. Can you tell me what you've already done and/or plan to do? Also from a workflow perspective, if I fix the void*-T* warnings from -Wc++-compat, I'd like to just put them on mainline first and let you merge it to the branch rather than the reverse. Mainline is blathering lots of new warnings right now and I'd like to address those quickly. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: gcc-in-cxx branch created
On Thu, 19 Jun 2008, Ian Lance Taylor wrote: Kaveh R. GHAZI [EMAIL PROTECTED] writes: I'd like to avoid stomping on each other and duplicating work. Can you tell me what you've already done and/or plan to do? I have a bunch of patches, but as far as getting them into mainline I'm limited by the time it takes to run a bootstrap and test run (I'm at the summit and am just working on my laptop). Right now I am testing the appended patch for mainline; that should clear up a lot of enum warnings. I recommend applying this patch to your working directory, and look at the warnings that remain. Other than that, everything I've done is minor stuff like the message to which you refer. I don't know how to avoid duplicating work at that level. If you want to pick a set of files to start with, that works for me. Okay, looks like you have the enum problem under control. I'm attacking the void*-T* problem on mainline. So far I've got most of the java directory, the objc directory and a few top level files (gcc.c, collect2.c, tlink.c) done and it's undergoing regtesting. I'll install as obvious on mainline since it's just casting and/or using the libiberty C++ macros created explicitly for this purpose. I'll do fortran next, then some top level files. I'll post in this thread which ones so we don't overlap. Please do the same. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
