Re: Where to place warning about non-optimized tail and sibling calls

On 8/1/23 6:08 PM, David Malcolm wrote: FWIW I added it to support Scheme from libgccjit; Do you know of any Scheme using libgccjit? BTW, I tried to build mainline with --enable-coverage to see which code is executed with -foptimize-sibling-calls, but bootstrap fails with /home/lucier/progr

Re: Where to place warning about non-optimized tail and sibling calls

On 8/1/23 6:08 PM, David Malcolm wrote: Or from libgccjit. FWIW I added it to support Scheme from libgccjit; see this patch kit: https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01287.html Perhaps there's a case for a frontend attribute for this. Dave Thanks. I thought a front-end warning mi

Re: Where to place warning about non-optimized tail and sibling calls

On 8/1/23 12:51 PM, Paul Koning wrote: How is it possible to write valid C that is correct only if some optimization is done? Perhaps "incorrect" was the wrong word. If sibling-call optimization is not done, then perhaps the program will blow out the stack, which would not happen if the opt

Where to place warning about non-optimized tail and sibling calls

The Gambit Scheme->C compiler has an option to generate more efficient code if it knows that all tail and sibling calls in the generated C code will be optimized. If gcc does not, however, optimize a tail or sibling call, the generated C code may be incorrect (depending on circumstances). So

Warning for converting (possibly) negative float/double to unsigned int

Perhaps this question is appropriate for the gcc mail list. Converting a float/double to unsigned int is undefined if the result would be negative when converted to a signed int. x86-64 and arm treat this condition differently---x86-64 returns a value whose bit pattern is the same as the bit

Would like to make one version of is_too_expensive in gcse.c and cprop.c

The routines declared as static bool is_too_expensive (const char *pass) in both cprop.c and gcse.c are identical except for two comment lines. I'd like to modify is_too_expensive, which implied to me that there should be only one copy of the routine. Would it be reasonable to add an extern

Compile and run time comparison of every gcc release since 2.95

Marc Feeley, the author of the Gambit Scheme compiler and interpreter, has measured the time to "make" the current version of Gambit, and then to run an application in the Gambit interpreter, for every release of gcc since gcc-2.95. For each version of gcc, Feeley built Gambit in each of two way

Re: Where does the time go?

On my codes, pre-RA instruction scheduling on X86-64 (a) improves run times by roughly 10%, and (b) costs a lot of compile time. The -fscheduling option didn't seem to be on in your time tests (I think it's not on by default on that architecture at -O2). Brad

Re: Why no strings in error messages?

On Wed, 2009-08-26 at 17:12 -0700, Ian Lance Taylor wrote: > If you are getting that kind of speedup (which I personally did not > expect) then this is clearly worth pursuing. It should be possible to > make it work at least in 64-bit mode. I recommend that you file a bug > report or two for cas

Re: Why no strings in error messages?

On Wed, 2009-08-26 at 20:38 +0200, Paolo Bonzini wrote: > > > When I worked at AMD, I was starting to suspect that it may be more > > beneficial > > to re-enable the first schedule insns pass if you were compiling in 64-bit > > mode, since you have more registers available, and the new registers

Why no strings in error messages?

I've never seen the answer to the following question: Why do some versions of gcc that I build not have string substitutions in error messages? I get things like this: [luc...@lambda-head lib]$ /pkgs/gcc-mainline/bin/gcc -mcpu=970 -m64 - fschedule-insns -Wno-unused -O1 -fno-math-errno -fsc

Re: Bootstrap failure configuring in-tree gmp in mainline

On Jul 25, 2009, at 12:54 PM, Paolo Bonzini wrote: Am i missing something? No, it is a bug due to the build-with-C++ patches. Please file a PR and, in the meanwhile, try --enable-stage1-languages=c,c++ or -- enable-build-with-cxx. I filed PR40950 for this. I also filed PR40968 for a

Re: Bootstrap failure configuring in-tree gmp in mainline

On Jul 25, 2009, at 2:16 PM, Bradley Lucier wrote: On Jul 25, 2009, at 12:54 PM, Paolo Bonzini wrote: Am i missing something? No, it is a bug due to the build-with-C++ patches. Please file a PR and, in the meanwhile, try --enable-stage1-languages=c,c++ That seemed to work, thanks

Re: Bootstrap failure configuring in-tree gmp in mainline

On Jul 25, 2009, at 12:54 PM, Paolo Bonzini wrote: Am i missing something? No, it is a bug due to the build-with-C++ patches. Please file a PR and, in the meanwhile, try --enable-stage1-languages=c,c++ That seemed to work, thanks, bootstrap has gotten past my old problem. or --enable-b

Re: Bootstrap failure configuring in-tree gmp in mainline

Thanks for your reply. On Jul 25, 2009, at 7:18 AM, Ralf Wildenhues wrote: Does /home/lucier/programs/gcc/objdirs/mainline/./prev-gcc/g++ exist, No. and if yes, is it a functioning executable? If it doesn't exist, that looks like the toplevel logic for which languages to build still has a

Bootstrap failure configuring in-tree gmp in mainline

After configuring Target: x86_64-unknown-linux-gnu gcc version 4.5.0 20090715 (experimental) [trunk revision 149654] (GCC) with ../../mainline/configure --enable-checking=release --prefix=/pkgs/gcc-mainline-mem-stats --enable-languages=c --enable-gather-detailed-mem-stats I get the bootstrap

Measuring FSF gcc from 4.1.2 to today on various benchmarks.

I've put at http://www.math.purdue.edu/~lucier/bugzilla/9/ some compile-time and run-time statistics related to PR 39157 and PR 33928 and compile times and run times for the programs in the Gambit Scheme benchmark suite. The statistics are for 4.1.2 release, 4.2.4 release, 4.3.3 release, 4.4.1 2

Re: GCC 4.4.0 Status Report (2008-11-17)

There has been some discussion here of GCC's reputation and of how to classify bugs. This bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 has gradually morphed from a compile-time issue to a space issue; if it's not fixed for 4.4 (and it appears that it will not be fixed in that tim

Re: Should 27_io/ios_base/storage/2.cc be XFAILed on powerpc64-apple-darwin9?

On Thu, Nov 20, 2008 at 11:17:52AM +0100, Paolo Carlini wrote: Hi, Should this be XFAILed on powerpc64-apple-darwin9? A patch doing that is essentially preapproved if you can confirm that in the meanwhile the malloc bug (Radar 3884894) has been fixed for i386-apple-darwin and not for powerpc

Should 27_io/ios_base/storage/2.cc be XFAILed on powerpc64-apple-darwin9?

I'm getting the following failure on powerpc64-apple-darwin9.5.0: Setting LD_LIBRARY_PATH to :/Users/lucier/programs/gcc/objdirs/ mainline/gcc:/Users/lucier/programs/gcc/objdirs/mainline/powerpc64- apple-darwin9.5.0/./libstdc++-v3/src/.libs::/Users/lucier/programs/gcc/ objdirs/mainline/gcc:/Us

Mainline bootstrap failure on powerpc64-darwin, but looks generic

I'm just not having any luck bootstrapping this thing ... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37639

Re: Can gcc 4.3.1 handle big function definitions?

Klaus: Perhaps your problem is related to PR 26854: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 See in particular comment 70, which has some statistics. If you're building your own gcc, configure gcc with --enable-gather- detailed-mem-stats and compile your program with -ftime-report -f

4.3.0 manual vs changes.html

The web page http://gcc.gnu.org/gcc-4.3/changes.html states that "The -ftree-vectorize option is now on by default under - O3.", but on http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Optimize-Options.html -ftree-vectorize is not listed as one of the options enabled by -O3. Is the first stateme

Re: Activate -mrecip with -ffast-math?

On Jun 18, 2007, at 2:27 PM, Bradley Lucier wrote: But even if sqrt is corrected for 0.0 * inf, there would still be a lot of problems with the combinations of NR-enhanced rsqrt and rcp. Consider for example: 1.0/sqrt(a/b) alias rsqrt(a/b) Having a=0, b != 0, the result is inf. As

Re: Activate -mrecip with -ffast-math?

On Jun 18, 2007, at 2:14 PM, Uros Bizjak wrote: tbp wrote: For example, when doing 1/x and sqrt(x) via reciprocal + NR, you first get an inf from said reciprocal which then turns to a NaN in the NR stage but if you correct it by, say, doing a comparison to 0 and a 'and'. That's what ICC us

Re: How do you get the benefit of -fstrict-aliasing?

On Apr 21, 2007, at 6:01 PM, Bradley Lucier wrote: So I'm wondering whether certain options have to be included on the command line to get the benefits of -fstrict-aliasing. I've thought about this question a bit more, so maybe I can make it less content-free. The C code ge

Re: Effects of newly introduced -mpcX 80387 precision flag

On May 3, 2007, at 3:29 PM, Uros Bizjak wrote: Bradley Lucier wrote: What about "significant loss of accuracy" as these options probably won't cause a nuclear reactor meltdown ;) Well, I did some googling, and the technical term I was thinking of was "catastrophic ca

Re: Effects of newly introduced -mpcX 80387 precision flag

On May 3, 2007, at 2:45 PM, Uros Bizjak wrote: Bradley Lucier wrote: On May 3, 2007, at 11:11 AM, Uros Bizjak wrote: Could you please post a patch with suggested wording about this option (I was trying to write something similar to the warning that icc has in its documentation about

Re: Effects of newly introduced -mpcX 80387 precision flag

On May 3, 2007, at 11:11 AM, Uros Bizjak wrote: Could you please post a patch with suggested wording about this option (I was trying to write something similar to the warning that icc has in its documentation about precision settings). How about this? It perhaps reflects my own biases, bu

Re: Effects of newly introduced -mpcX 80387 precision flag

On Apr 29, 2007, at 1:01 PM, Tim Prince wrote: [EMAIL PROTECTED] wrote: I just (re-)discovered these tables giving maximum known errors in some libm functions when extended precision is enabled: http://people.inf.ethz.ch/gonnet/FPAccuracy/linux/summary.html and when the precision of the man

Re: Effects of newly introduced -mpcX 80387 precision flag

Richard Henderson wrote: On Tue, Apr 03, 2007 at 10:56:42AM +0200, Uros Bizjak wrote: > ... Note that a change of default precision control may > affect the results returned by some of the mathematical functions. > > to the documentation to warn users about this fact. Eh. It can seriously bre

How do you get the benefit of -fstrict-aliasing?

I've decided to try to contribute modifications to the the C code that is generated by the Gambit Scheme->C compiler so that (a) it doesn't have any aliasing violations and (b) more aliasing distinctions can be made (the car and cdr of a pair don't overlap with the entries of a vector, etc.

Re: Status of PR21561

On Apr 15, 2007, at 6:37 PM, Andrew Pinski wrote: On 4/15/07, Bradley Lucier <[EMAIL PROTECTED]> wrote: If you try ../gcc-4.1.2/configure; make bootstrap on a powerpc-darwin G4 system, then the bootstrap will fail because the process builds 64-bit multilibs and tries to execute a p

Status of PR21561

If you try ../gcc-4.1.2/configure; make bootstrap on a powerpc-darwin G4 system, then the bootstrap will fail because the process builds 64-bit multilibs and tries to execute a program with "xgcc -m64'. In May 2005, PR 21561 reported this same problem on 32-bit x86 solaris; the workaroun

Re: Integer overflow in operator new

Robert Dewar wrote: I have always been told that -ftrapv is nowhere near fully working or reliable (I think Eric is the source of that advice). Is this just a rumor, or are there data that backs this up. (That - fwrapv doesn't work, not that Dewar was always told that it doesn't work.) B

Re: gfortran testsuite failures with 4.3.0 on powerpc64-apple-darwin8.8.0

On Dec 8, 2006, at 1:43 AM, Andrew Pinski wrote: In case anyone does not know yet, the warning is the same as PR 29779. I don't remember if this was mentioned or not. Thank you very much for that info. That is indeed the problem with these test cases, as can be seen if I specify a 64-bit C

Re: gfortran testsuite failures with 4.3.0 on powerpc64-apple-darwin8.8.0

After 0. Making Jack's suggested changes to prune.exp (even though they didn't catch any new linker messages); 1. Configuring and making with /bin/rm -rf *; env CC=/pkgs/gcc-4.2.0-64/bin/gcc ../configure -- build=powerpc64-apple-darwin8.8.0 --host=powerpc64-apple-darwin8.8.0 --target=po

Re: gfortran testsuite failures with 4.3.0 on powerpc64-apple-darwin8.8.0

On Dec 6, 2006, at 2:18 AM, Steve Kargl wrote: On Dec 6, 2006, at 1:33 AM, Steve Kargl wrote: So when was the last good bootstrap? I last bootstrapped and regtested this configuration here http://www.math.purdue.edu/~lucier/gcc/test-results/ 4_3_0_2006-11-11.gz The results appear roug

Re: gfortran testsuite failures with 4.3.0 on powerpc64-apple-darwin8.8.0

On Dec 6, 2006, at 1:33 AM, Steve Kargl wrote: So when was the last good bootstrap? I last bootstrapped and regtested this configuration here http://www.math.purdue.edu/~lucier/gcc/test-results/4_3_0_2006-11-11.gz The results appear roughly similar. (This is a recent architecture triple.

gfortran testsuite failures with 4.3.0 on powerpc64-apple-darwin8.8.0

I'm getting several thousand gfortran testsuite errors with messages like: FAIL: gfortran.dg/PR19754_2.f90 -O3 -fomit-frame-pointer -funroll- all-loops -finline-functions (test for excess errors) Excess errors: /Users/gcc-test/programs/gcc/mainline/gcc/testsuite/gfortran.dg/ PR19754_2.f90:

Re: compiling very large functions

The gcc developers have been very cooperative over the years in working to solve problems that I've had in compiling large machine- generated programs. For example, when gcse was disabled for large flow flow graphs in 2000, the warn_disabled_optimization flag was added at my suggestion. As

Large memory requirements for 4.2 and 4.3

For many years, the default gcc compile options for C code generated by Gambit, the Scheme->C compiler, were very simple (-O1 -fschedule- insns2 -fno-math-errno -fno-trapping-math) and I didn't have problems with gcc's space requirements to compile those files. (I often ran into complexity

Re: Darwin as primary platform

On Oct 4, 2006, at 1:57 PM, Eric Christopher wrote: FWIW I think a 64-bit native version might be nice as a separate target, but I've been told there's no real advantage there either on ppc. Perhaps I'm misunderstanding your comment, but with a 64-bit gcc you can compile machine-generate

Re: Darwin as primary platform

On Sep 22, 2006, at 9:20 PM, Eric Christopher wrote: Bradley Lucier wrote: Right now, it seems that one may not be able to build a 64-bit version of the compiler itself You may or may not have noticed that there are no 64-bit native targets for darwin. I just looked at http

Re: Darwin as primary platform

Right now, it seems that one may not be able to build a 64-bit version of the compiler itself, on either either x86-64 or ppc64, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28994 I notice that because some of my (automatically generated) C programs, with certain compiler options, require

Re: regress and -m64

On Aug 30, 2006, at 9:55 PM, Jack Howarth wrote: Try building some of the g++ testcases manually and see what the errors are. Perhaps this is a problem: grep 'Symbol not found' g++.log | sort | uniq -c 1254 dyld: Symbol not found: ___dso_handle

Re: regress and -m64

After some discussion with Jack Howarth, I have found that the gfortran and libgomp executable tests on powerpc-apple-darwin8.7.0 (at least) do not link the correct, just-built-using-"make bootstrap", libraries until those libraries have first been installed in $prefix/lib/... I filed a b

Re: regress and -m64

On Aug 28, 2006, at 12:10 PM, Jack Howarth wrote: Why don't you try a normal multi-lib build without any extra flags. What extra flags? The configure command is ../configure --prefix=/pkgs/gcc-mainline --with-gmp=/opt/local/ -- with-mpfr=/opt/local/ which is totally generic (one need

Re: regress and -m64

When I run bootstrap and "make check", I check the -m64 option (only). Check gcc-testresults. Currently, the results don't look very good. Maybe I'm doing something wrong. Brad

Suggestion for logging changes on Bugzilla

I just did a search on "My bugs" and found that one of them, 22118, had a title that I didn't recognize. I then remembered that the title had been changed from my original description; ordinarily there is not an entry in a bugzilla record noting that a title has in fact been changed. I w

Re: 4.2 hasn't bootstrapped on powerpc-apple-darwin G5 machine for a very long time

On May 3, 2006, at 7:50 PM, David Fang wrote: Bradley Lucier writes: Brad> 4.2 hasn't bootstrapped on powerpc-apple-darwin G5 machine for a very Brad> long time. I'm seeing the same problem as Brad> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27121 Brad> It woul

Re: 4.2 hasn't bootstrapped on powerpc-apple-darwin G5 machine for a very long time

On May 3, 2006, at 7:50 PM, David Fang wrote: FWIW, the 20060415 mainline (4.2) snapshot bootstrapped for me, using odcctools-20060413 (odcctools-590.36od13). This machine is a dual G5 (ppc970) using OS X 10.3.9, and Apple's gcc-3.3 (build 1640). However, before building, I patched the follow

4.2 hasn't bootstrapped on powerpc-apple-darwin G5 machine for a very long time

4.2 hasn't bootstrapped on powerpc-apple-darwin G5 machine for a very long time. I'm seeing the same problem as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27121 It would be nice if this were remedied. I do try to test gcc versions before release. Brad

Possible configure problem in mainline?

I'm trying to build a 64-bit mainline compiler on powerpc-darwin; I want gcc to generate 32-bit binaries by default, I just want cc1, etc., to be 64-bit binaries so I can compile large files. This works in 4.1, but not on mainline. This is reported at http://gcc.gnu.org/bugzilla/show_bug.cg

Re: Results for 4.2.0 20060320 (experimental) testsuite on powerpc-apple-darwin8.5.0 (-m64 results)

On Mar 21, 2006, at 11:39 PM, Shantonu Sen wrote: On Mar 21, 2006, at 12:34 PM, Bradley Lucier wrote: I'm curious about whether any of the changes recently proposed to clean up the x86-darwin port can be applied to the 64-bit PowerPC darwin compiler; Like what? I haven't r

Results for 4.2.0 20060320 (experimental) testsuite on powerpc-apple-darwin8.5.0 (-m64 results)

64-bit powerpc-darwin results be found here: http://www.math.purdue.edu/~lucier/gcc/test-results/4_2-2006-03-20.gz The mail-report-with-warnings.log file is again too large to be accepted by the gcc-testresults mail list after quite a few weeks when it was only about 125K long. I'm curious

Re: Imported GNU Classpath 0.90

Please let us know ([EMAIL PROTECTED]) if there are any issues with the new import. It has been tested on x86, x86-64 and ppc-32 on GNU/Linux and sun-sparc-solaris8 multilib and darwin-pcc 32-bit. But more testing is helpful (it also includes an update to the fdlibm library). I don't know if it

Re: Results for 4.1.0 20060117 (prerelease) testsuite on powerpc-apple-darwin8.4.0 (-m64 results)

On Jan 23, 2006, at 8:07 PM, Shantonu Sen wrote: I've posted a new version of odcctools (based on Apple's cctools and ld64 source) which should fix a few thousand of the failures. Instructions are at: This is based on ccto

Results for 4.1.0 20060117 (prerelease) testsuite on powerpc-apple-darwin8.4.0 (-m64 results)

http://www.math.purdue.edu/~lucier/gcc/test-results/4_1-2006-01-17.gz (Too large to be accepted here.) So I have a question. I've installed the latest Xcode release, or, at least I think I did: [lindv2:gcc/4.1/objdir64] lucier% gcc -v Using built-in specs. Target: powerpc-apple-darwin8 Conf

Re: svn access on RHEL 4.0

On Jan 8, 2006, at 7:19 PM, Daniel Berlin wrote: On Sun, 2006-01-08 at 18:05 -0600, Bradley Lucier wrote: OK, here are some details. Our server is a dual UltraSparc running Solaris 10 attached to the SAN. Working client situation: subversion 1.3.0 on Sparc Solaris 9, not using Berkeley DB

Re: svn access on RHEL 4.0

On Jan 8, 2006, at 9:12 AM, Daniel Berlin wrote: Try removing the offending directory (gcc/testsuite/gcc.dg/ special) and run svn cleanup again, updating the tree afterwards. If you didn't have any local changes in that directory you should not lose anything. If the problem persists th

Re: svn access on RHEL 4.0

On Jan 8, 2006, at 9:04 AM, Andreas Schwab wrote: Try removing the offending directory (gcc/testsuite/gcc.dg/special) and run svn cleanup again, updating the tree afterwards. If you didn't have any local changes in that directory you should not lose anything. If the problem persists the

svn access on RHEL 4.0

I'm having all kinds of trouble running svn on my RHEL 4.0 system. A typical example of what's happening is: euler-62% svn cleanup svn: XML parser failed in 'gcc/testsuite/gcc.dg/special' I first got that message when I tried contrib/gcc_update after doing a svn checkout. Now I just get

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

On Dec 16, 2005, at 8:25 PM, Eric Christopher wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082 Unfortunately, even with my Apple Developer account I can't seem to figure out how to look up radar reports that I haven't submitted. I took a look at the radar. Says, effectively, that

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

On Dec 16, 2005, at 6:23 PM, Mike Stump wrote: On Jun 20, 2005, at 2:41 PM, Bradley Lucier wrote: I can't seem to build any 64-bit shared library on powerpc-apple- darwin8.1.0, although I can now run the test suite more effectively; see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=

4.1: Many 64-bit failures on powerpc-apple-darwin8.3.0

I bootstrapped and regtested 4.1 on powerpc-apple-darwin8.3.0 and there were so many errors with -mcpu=970 -m64 that the gcc mail daemon wouldn't accept the summary. So I put it at http://www.math.purdue.edu/~lucier/gcc/test-results/4_1-12-06-2005.gz The most serious problems seem to be in

PR 22082: Trouble linking with 64-bit libgcc on powerpc-darwin

Geoff Keating has made several changes to the darwin configuration files recently; I was thinking that while people are looking at these things, perhaps someone can say I'm doing something wrong in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22082 or whether further configuration changes are n

Can't turn off overflow_warning?

After examining the source and documentation, it appears to me that in 4.0.* and on mainline one cannot turn off the warning generated by overflow_warning, in, for example, [descartes:~] lucier% cat test.c #include int main() { if (1048256 * 1048256 < 0) printf("1"); else printf("

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

On Jun 16, 2005, at 3:06 PM, Mike Stump wrote: Actually, by try, I meant try your application. :-) I can't seem to build any 64-bit shared library on powerpc-apple- darwin8.1.0, although I can now run the test suite more effectively; see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22110

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

It seems that the libtool command line may be wrong. Here's a simple test. [descartes:~/programs] lucier% cat conftest.c int main2() { return 0;} [descartes:~/programs] lucier% gcc -m64 -mcpu=970 -o conftest -dynamiclib conftest.c -v -save-temps Using built-in specs. Target: powerpc-apple-d

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

On Jun 16, 2005, at 1:30 AM, Mike Stump wrote: Please try something like: ... and let me know if it works. Thank you, I will try it today. Last night I unconditionally allowed multilibs and configured with Compiler version: 4.1.0 20050615 (experimental) Platform: powerpc-apple-darwin8.1.0

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

On Jun 15, 2005, at 7:12 PM, Mike Stump wrote: On Wednesday, June 15, 2005, at 11:19 AM, Bradley Lucier wrote: I cannot build and use (link, etc.) 64-bit shared libraries on powerpc-apple-darwin8.1.0 with gcc version 4.0.1 20050615 > (prerelease). If you remove the # that comment out

Re: 4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

On Jun 15, 2005, at 1:26 PM, Andrew Pinski wrote: On Jun 15, 2005, at 2:19 PM, Bradley Lucier wrote: Mark: I cannot build and use (link, etc.) 64-bit shared libraries on powerpc-apple-darwin8.1.0 with gcc version 4.0.1 20050615 (prerelease). This is a regression from 4.0.0 on the

4.0.0->4.0.1 regression: Can't use 64-bit shared libs on powerpc-apple-darwin8.1.0

Mark: I cannot build and use (link, etc.) 64-bit shared libraries on powerpc-apple-darwin8.1.0 with gcc version 4.0.1 20050615 (prerelease). This is a regression from 4.0.0 on the same platform. I couldn't come up with a short example, sorry, but it is easy to reproduce if you have the r

Re: Is it possible to catch overflow in long long multiply ?

This is the wrong list to ask such a question, but I'll answer it anyway since the answer might be of general interest. There is a wonderful book "Hacker's Delight" by Henry S. Warren Jr., http://www.awprofessional.com/bookstore/product.asp? isbn=0201914654&redir=1&rl=1 In some ways it can

Re: Heads up: 4.0 libjava failures on powerpc-apple-darwin7.8.0

On Mar 25, 2005, at 1:22 PM, Tom Tromey wrote: "Brad" == Bradley Lucier <[EMAIL PROTECTED]> writes: Brad> http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01559.html I didn't see more recent results, but I suspect this problem has been fixed. It seems that the libjava te

Re: bootstrap error in 4.1 on sparc

On Mar 3, 2005, at 3:13 PM, Andrew Pinski wrote: Was this fixed with my/Roger's patch which went in this morning (EST)? No: stage1/xgcc -Bstage1/ -B/export/users/lucier/local/gcc-mainline/sparc-sun-solaris2.9/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prot

bootstrap error in 4.1 on sparc

With today's mainline I get stage1/xgcc -Bstage1/ -B/export/users/lucier/local/gcc-mainline/sparc-sun-solaris2.9/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Werror -fno-common

Will people install gfortran in 4.0? [was Re: Shipping gmp and mpfr with gcc-4.0?]

On Feb 19, 2005, at 11:18 AM, Eric Botcazou wrote: So now what? Not build shared libraries for gmp? Add /pkgs/gmp-4.1.4 to my LD_LIBRARY_PATH? The latter. Well, I can't really require people using the compiler to have /pkgs/gcc-4.0/lib, /pkgs/gcc-4.0/lib/sparcv9, *and* /pkgs/gmp-4.1.4 in their

Re: Shipping gmp and mpfr with gcc-4.0?

On Feb 16, 2005, at 2:13 AM, Eric Botcazou wrote: I tried this evening to install gmp-4.1.4 and mpfr-2.1.0 on my Solaris machines and I failed on the first try. (I think the default install for gmp on my machines is a 64-bit version, but the default for mpfr and gcc is 32-bit, so I'm going to have

Shipping gmp and mpfr with gcc-4.0?

Sorry if this has been answered before. I installed gmp and mpfr successfully on my Mac G5 and so I can test gfortran on my Mac. I tried this evening to install gmp-4.1.4 and mpfr-2.1.0 on my Solaris machines and I failed on the first try. (I think the default install for gmp on my machines is