Re: gcc trunk vs python

Michael, If I build python 2.4.3 with the default compiler flags under gcc trunk on MacOS X 10.4.7, I get the following... Python 2.4.3 (#1, Aug 23 2006, 17:39:08) [GCC 4.2.0 20060822 (experimental)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import s

Re: test for excess errors

Janis, Thanks for the pointers. Adding the following patch --- gcc-4.2-20060822/gcc/testsuite/lib/prune.exp.org2006-08-23 18:33:56.0 -0400 +++ gcc-4.2-20060822/gcc/testsuite/lib/prune.exp2006-08-23 18:41:28.0 -0400 @@ -43,6 +43,7 @@ regsub -all "(^|\n)\[^\

Re: Darwin -m64 results

Mike, I managed to suppress the linker warnings which occur with "-m64 -g" with COMMON blocks by applying the following patch... --- gcc-4.2-20060822/gcc/testsuite/lib/prune.exp.org2006-08-23 18:33:56.0 -0400 +++ gcc-4.2-20060822/gcc/testsuite/lib/prune.exp2006-08-23 18:

Re: gcc trunk vs python

Michael, I submitted a bug report to the python developers. Do you have a suggestion on how... /* (-sys.maxint-1)/-1 is the only overflow case. */ if (y == -1 && x < 0 && x == -x) return DIVMOD_OVERFLOW; ...should be reworked? Since I am tickling the bug at the

Re: gcc trunk vs python

Andrew, Thanks. The change... --- Python-2.4.3/Objects/intobject.c.org2006-08-23 23:49:33.0 -0400 +++ Python-2.4.3/Objects/intobject.c2006-08-23 23:52:01.0 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the

make check glitch

I have been able to use the command... make -k check RUNTESTFLAGS='--target_board "unix{,-m64}"' to check my multilib gcc trunk build on Darwin ppc from within the darwin_objdir/gcc directory of the build tree. However this doesn't seem to allow both the -m32 and -m64 testsuite runs for the o

re: make check glitch

I should add that I see the same problem if I execute... make -k check RUNTESTFLAGS='--target_board "unix{,-m32}"' ...from the toplevel of the linux_obj directory on gcc trunk built on a x86_64 Fedora Core 5 machine. The behavior is the same as on darwin. If I execute the above command from t

Re: test for excess errors

Mike, I just created PR28837 with the patch to prune.exp that prunes the ld64 warnings. I have only tested this with the core gcc at the moment because I can't get... make -k check RUNTESTFLAGS='--target_board "unix{,-m64}"' ...to work from the toplevel of the darwin_obj directory... http://g

Re: test for excess errors

Janis, THANKS! Using either... make -k check RUNTESTFLAGS="--target_board=unix'{-m32,}'" or make -k check RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'" ..works from the toplevel directory (at least for x86_64 on Fedora Core 5...I'll try darwin when I get home to my G5). Jac

Re: make check glitch

Steve, The problem is entirely due to the absence of an equal sign between --target_board and 'unix{-m32,}'. I looked through the gcc documentation for any mentions of --target_board and every example I found used an equals sign after --target_board. However, I don't think this is explicitly me

libstdc++, -m64 and can't find atom for N_GSYM stabs

Geoff, It appears that this issue with the ld64 link issuing warnings of "can't find atom for N_GSYM stabs" is not specific to gfortran. I finally figured out the correct syntax to run a complete make check so that the libraries as well as gcc are checked. FYI, the trick is to use the equal sign

Re: libstdc++, -m64 and can't find atom for N_GSYM stabs

Eric, So far the smallest test case I can come up with reproduces the "can't find atom for N_GSYM stabs" ld64 linker warning in Darwin is... #include #include // uneq_allocator as a non-empty allocator. void test01() { bool test __attribute__((unused)) = true; using namespace std; typ

fp-int-convert-timode, TImode and Darwin

I recently discovered an apparent latent bug in float to integer conversion which is exposed on Darwin PPC by addition of Geoff Keating's proposed TImode support patch... http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00581.html With this patch in place, the 64-bit testsuite results show that t

Re: fp-int-convert-timode, TImode and Darwin

Eric, Does that imply that the TImode patch is a must have for Darwin x86_64 in the gcc 4.2 release? If so you might try to convince Geoff that it really should go into gcc trunk before the branch occurs. Frankly I was aghast to discover yesterday that the folks doing the Irix port managed to ge

Re: fp-int-convert-timode, TImode and Darwin

Eric, It would be rather unfortunate if Darwin x86_64 support didn't go in (as long as it doesn't destabilize the Darwin ppc port). Currently we in the fink project are already living with bastardized gcc 4.2 prereleases in order to have any Macintel support. I had hoped we could latch onto the

Re: libstdc++, -m64 and can't find atom for N_GSYM stabs

Eric, I just reran "make -k check RUNTESTFLAGS='--target_board "unix{-m64}"'" in the darwin_objdir/powerpc-apple-darwin8/libstdc++-v3 directory after applying the following patch to suppress the "can't find atom for N_GSYM stabs" ld64 linker warnings... --- gcc-4.2-20060825/libstdc++-v3/test

Re: gcc trunk vs python

Would any of the gcc developers care to drop by the python-dev mailing list and give the author of python an answer? http://mail.python.org/pipermail/python-dev/2006-August/068482.html On 8/26/06, Jack Howarth wrote

Re: [Python-Dev] gcc 4.2 exposes signed integer overflows

Dan, Thanks for the detailed reply on the python-dev mailing list. I had a feeling we would run into resistance on this (otherwise these issues would have been already fixed). That's why discussions like the "gcc trunk vs python" thread can be useful even though they are off-topic to the list. O

regress and -m64

Can one of you remind me who we need to lobby at Apple to change the 'make check' on the regress testing server to... make -k check RUNTESTFLAGS='--target_board="unix{,-m64}"' Since you are already building gcc with multilib support, it makes little sense to not do so. Especially considering

Re: regress and -m64

Brad, Why don't you try a normal multi-lib build without any extra flags. At the moment, considering how much noise is on the testsuite results on Darwin due to this linker warnings, I don't think its really helpful to bother exploring corner cases of building gcc trunk with unique flags. Make s

Re: regress and -m64

Brad, I was confusing your use of -mcpu=970 in the make check with the build flags...sorry. You might stop using that flag for now until you get a baseline of how many additional failures seen in -m64 compared to -m32 are not due to the linker warnings (after you apply the TImode patch). I'll l

Re: regress and -m64

Mike, Do you know if regress is used for anything other than building and checking gcc? Also is it a dual G5 by any chance? I ask because it is unclear if regress is doing a 'make -k -j 2 check' or not? Might that not increase the rate of testing on regress? I haven't tried that myself because I

Re: regress and -m64

Mike, Well then alternatively, might not 'make -j 2' increase the rate at which gcc is built on regress? Or doesn't Darwin support parallel builds? If we can't speed up the testing then we could at least speed up the build process to free up time for -m64. After all, we are already building -m6

Re: regress and -m64

Mike, Now I totally confused. Are you saying that '-j 2' only speeds up testing but not builds? In one sentence you say it won't speed things up and in the next you say of course it speeds things up. Which is it? Jack On Aug 28, 2006, at 3:32 PM, Jac

Re: regress and -m64

Mike, Okay. How about this. Have regress set to at least do a -m64 make check once a week. At least that would show some interest in the status of gcc at 64-bit. It is baffling to most people how we can make any progress on such issues if the status isn't sampled at least once every blue moon.

Re: regress and -m64

Mike, Sure. I am actually doing a build right now to demonstrate the baseline we have for c, c++, and fortran with just the TImode patch and the prune.exp patches I use. Hmm, regress is a G4...surely you can find a G5 laying around Apple to replace it with since PowerPC is so passe there (grin).

Re: regress and -m64

I've posted the results of last night's build of gcc trunk on my dual G5 using Geoff's TImode patch and changes to prune.exp to suppress the failures from the ld64 linker warnings. Jack

linkage gcc.misc-tests

Eric, Does the following test fail for you under your x86_64 patch set for Macintel? Running /sw/src/fink.build/gcc4-4.1.999-20060828/gcc-4.2-20060828/gcc/testsuite/gcc.misc-tests/linkage.exp ... Executing on host: /sw/src/fink.build/gcc4-4.1.999-20060828/darwin_objdir/gcc/xgcc -B/sw/src/fi

RE: linkage gcc.misc-tests

Geoff, Isn't the gcc.misc-tests/linkage.c failing just because we don't have an entry in linkage.exp that defines the native flags for Darwin? Also, this test look pretty dicey in that it uses... catch { exec cc -c $native_cflags "$srcdir/$subdir/linkage-y.c" >&/dev/null } and...

Re: regress and -m64

Bradley, Something still is as astray with your build configuration. Look at my last set of results. http://gcc.gnu.org/ml/gcc-testresults/2006-08/msg01333.html I only have 28 unexpected failures for g++ at -m64 and you have 1350. Likewise for libstdc++ at -m64, I only have 6 unexpected fail

gcc.target/powerpc vs -m64

Geoff, I am assuming that quite a few of the remaining regressions at -m64 on Darwin PPC with your TImode patch applied will be resolved when Eric posts his x86_64 patches. However there are a few in gcc.target/powerpc which likely won't be addressed by those patches. I am seeing the following t

Re: regress and -m64

Brad, You build system certainly has issues. Why don't you strip down your .cshrc or .bashrc to a completely empty file, open a new terminal session so none of the previous .cshrc settings are in effect and rebuild gcc trunk. Also, I am assuming you are running MacOS X 10.4 and have at least Xco

Re: regress and -m64

Brad, If you google "dyld: Symbol not found: ___dso_handle", you'll come up with the following messages... http://gcc.gnu.org/ml/gcc/2006-03/msg00712.html http://gcc.gnu.org/ml/gcc/2006-03/msg00718.html http://gcc.gnu.org/ml/gcc/2006-03/msg00735.html So it certainly sounds like your cctools i

regress changes?

Geoff, What happened to regress to allow it to suddenly do make checks at every svn revision? I assume it isn't a measly G4 anymore (grin). If you have that many clock cycles to do builds and make checks every revision how about adding in -m64 make checks now? Jack

RE: call dsymutil on darwin when compiling and linking in single step

Geoff, Does the patch you propose in... http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00057.html eliminate the "can't find atom for N_GSYM stabs" warnings in ld64? I ask because you that... This is necessary since otherwise the debugger expects to find the DWARF information in the .o file, but

Re: GCJ on Darwin/i386 patches

It is probably too late to get this resolved before gcc trunk branches but we have an outstanding patch for building gcj on Darwin/386 awaiting on Sandro Tolaini's paperwork being processed. He told me that he scanned the form back to [EMAIL PROTECTED] but still hasn't heard back yet. The refer

libgfortran build broken on Darwin ppc

I don't know if this is related to Eric's checkins tonight but I can no longer build libgfortran on Darwin PPC. The build fails at... /bin/sh ./libtool --mode=compile /sw/src/fink.build/gcc4-4.1.999-20060908/darwin _objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.999-20060908/darwin_objdir/./g

RE: libgfortran build broken on Darwin ppc

To correct the typo in the last message, I am now rebuilding without the reduced TImode patch to confirm it is not at fault. As I said, since the build craps out in the 32-bit sections, I doubt it is the source of the libgfortran build failure. Jack

RE: libgfortran build broken on Darwin ppc

I should add that the last good build I have is from last night at revision r116774. Jack

RE: libgfortran build broken on Darwin ppc

Okay. The problem with the libgfortran build failing is unrelated to the remaining sections of the TImode patch. I see the same failure with an unpatched version of current gcc trunk. Time to file a PR. Jack ps I am currently building (for the last couple of days) with --disable-boo

multiple definitions of symbol _locale_charset

I notice a warning in the Darwin PPC build of gcc trunk against libiconv 1.10. There appears to be a duplicate symbol for _locale_charset in both ./../intl/libintl.a(localcharset.o) and /sw/lib/libiconv.dylib(localcharset.o). Shouldn't the presence of duplicate symbols in the linkage of cc1plu

Re: multiple definitions of symbol _locale_charset

Andrew, Thanks for the hint. I make the patch as being only... === --- intl/localcharset.c (revision 116795) +++ intl/localcharset.c (working copy) @@ -23,6 +23,13 @@ # include #endif +#if !HAVE_ICONV + +/* Provide our varian

Re: multiple definitions of symbol _locale_charset

Andrew, Doesn't the proposed patch to intl/localcharset.c pretty much fall under the obvious rule? Jack

RE: libgfortran build broken on Darwin ppc

My original attempt to build gcc trunk yesterday used the cctools from Xcode 2.3 and produced the failure... /bin/sh ./libtool --mode=compile /sw/src/fink.build/gcc4-4.1.999-20060908/darwin _objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.999-20060908/darwin_objdir/./gc c/ -B/sw/lib/gcc4/powerp

Re: libgfortran build broken on Darwin ppc

Eric, One last question. Is it correct to assume that when the newer cctools with the literal16 support becomes available, things like 'integer(16)' will become available in gfortran for darwin? Jack

long-long-cst1.c regression

Has anyone else noticed that the testcase long-long-cst1.c has started to fail on both powerpc-apple-darwin8.5.0 and on other ppc targets like powerpc64-unknown-linux-gnu? It appears to be still passing as of r116775 and to be failing as of r116778. Jack

Re: long-long-cst1.c regression

Andrew, Odd. When I do 'svn log', the entry for r116777 doesn't show a testcase being added. Oh, well. Jack

Re: libgfortran build broken on Darwin ppc

Eric, You definitely want the autoconf patch added in otherwise builds of libgfortran will crash when older cctools are used (like Xcode 2.3). I'll try a build of current gcc trunk with your new darwin.c correction but without the autoconf patch to see if all the literal16 support exists in Xco

Re: libgfortran build broken on Darwin ppc

Geoff, If the autoconf patch isn't going in to gcc trunk, would someone at Apple please nudge the folks who maintain www.opensource.apple.com to post the Xcode Tools 2.4 source code release? Either than or post a new cctools based off the same to the gcc ftp site. We really need to be able to cr

new libjava regression on darwin

Geoff, Did you notice that a new libjava regression occured today on Darwin apparently after revision 116838 but by revision 116843? The testcase... FAIL: Thread_Sleep -O3 -findirect-dispatch output - bytecode->native test now fails. Could this be related to your change... ---

debugging tmpdir-gcc.dg-struct-layout-1 failures

On Darwin PPC at -m64, we are seeing a slew of failures in the tmpdir-gcc.dg-struct-layout-1 tests... FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-s

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

Jakub, I don't believe I'm using ALT_CC_UNDER_TEST or ALT_CC_UNDER_TEST. However I do have to explicitly pass -m64 so that I test that compile flag at the same time I pass -DDBG. I haven't been able to puzzle out an invocation of make check that does that. If I use... make -k check-gcc RUNTESTF

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

Jakub, Okay. I managed to get the testcase built but -DDBG at -m64 by just changing the ifdef for DBDG to an ifndef in the header. The results on Darwin PPC are as follows... fail 94.72 FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute ...which in testsuite/

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

One other note about the tmpdir-gcc.dg-struct-layout-1 failures. I wonder if they could be another manifestation of the latent bug in float to integer conversion which I described in http://gcc.gnu.org/ml/gcc/2006-08/msg00500.html? Jack

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

Eric, Do you see the same set of failures... > FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o > execute > FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o > execute > FAIL: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_t

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

Eric, Yesterday's gcc trunk (with the residual TImode patch) shows the following gcc testsuite failures at -m64... FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmp

svn problems?

Has anyone else had problems accessing the svn server today for gcc? I tried from home and work today. In both cases, the 'svn update' never produces any updates of new files or completes. Jack

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

Jakub, I would like to create a test case for a couple of the failures I see in gcc.dg-struct-layout-1 on Darwin PPC -m64 so I can submit a PR for this one. I have been able to find all of the lines in the generated testcase for the failed tests... http://gcc.gnu.org/ml/gcc/2006-09/msg00211.html

Re: debugging tmpdir-gcc.dg-struct-layout-1 failures

Eric, I filed a PR29090 for the gcc.dg-struct-layout-1 failure of T(94,struct atal16{}a;,) ...out of the set of failures I see. I noticed that in the assembly from struct-layout-1_y.s, the follow occurs... .comm _a94,1 .stabs "a94:G(0,1)=ar(0,2)[EMAIL PROTECTED];r(0,2);0;01777

20020103-1.c XPASS on Darwin

Geoff, Are we now passing gcc.dg/20020103-1.c on Darwin due to the newer cctools in Xcode 2.4? I ask because I'm going to prepare patches tonight to eliminate some of the XPASS results in the libstdc++ testsuite tonight and post them to gcc-patches. If the newer Xcode is the origin of the new g

Is PR21674 really fixed for gcc 4.2?

I noticed that at least on Darwin PPC -m32 and -m64 we have been passing the test cases... XPASS: 21_strings/basic_string/element_access/char/21674.cc execution test XPASS: 21_strings/basic_string/element_access/wchar_t/21674.cc execution test in the libstdc++ testsuite. From what I see in bug

cast to pointer from integer of different size

Geoff, Is this a potential problem in the compilation of libgcj on Darwin PPC at -m64? I am seeing the following warning... /sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/./gcc/ -B/sw/lib/gcc4/powerpc-apple-darwin8/

cast to pointer from integer of different size again

Geoff, We seem to have the same issue in libffi when compiled on Darwin PPC at -m64... /sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/./gcc/ -B/sw/lib/gcc4/powerpc-apple-darwin8/bin/ -B/sw/lib/gcc4/powerpc-apple-d

Re: Building gfortran with gcc-4.2-20060906 also freezes

I don't recall the exact problem Chir was having but I would mention that on fink for MacOS X 10.4, we package our gmp 4.2.1 using a build with the following patch... http://swox.com/list-archives/gmp-discuss/2006-May/002333.html http://swox.com/list-archives/gmp-discuss/2006-May/002344.html M

Darwin doesn't install libgcjgc from boehm-gc

Has anyone noticed that on Darwin PPC we are building the shared library libgcjgc.1.0.2.dylib in the boehm-gc subdirectory but it never is installed? Isn't this a bug? Jack

objc linkage problems on Darwin PPC with -m64

I finally got around to building and testing the objc support in gcc on Darwin PPC at -m64. The results aren't good with 634 additional failures compared to the 10 at -m32. These seem to be linkage issues of the form below as shown in... http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00844

RE: objc linkage problems on Darwin PPC with -m64

Another observation regarding the previous failure I reported in the objc testsuite. If I manually execute... /sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/gcc/ /sw/src/fink.build/gcc4-4.1.-20060915/gcc-4.2-2006

Why test objc at -m64 for Darwin8?

Shouldn't we have something in gcc/testsuite/lib/objc*.exp to short-circuit out of running any of those -m64 testsuites for Darwin8 and earlier? If we won't have 64-bit objc runtimes in Darwin until Leopard, it seems rather pointless to test -m64 for objc at all, no? Also, I am baffled as to how

gcj install glitch

I am seeing a problem with gcc trunk in the 'make install' when java support is built on Darwin PPC. The failure is... Making install in classpath Making install in lib true top_builddir=.. top_srcdir=../../../../../../gcc-4.2-20060916/libjava/classpath /bin/sh ./gen-classlist.sh standard Addi

Re: Is PR21674 really fixed for gcc 4.2?

Benjamin, So does the fact that 21_strings/basic_string/element_access/char/21674.cc and 21_strings/basic_string/element_access/wchar_t/21674.cc now XPASS merit a PR? What sort of debug information should I provide. I've never filed a bug report on a test that is supposed to fail before so I'm a

XPASS: gfortran.dg/vect/vect-5.f90 on PPC64

Does anyone know if the fact that the gfortran.dg test case vect/vect-5.f90 is now showing a XPASS on indicates a regression? All three dg-final options that are marked to fail at lp64 now pass. Running target unix/-m64 XPASS: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times vectorized 2 l

Re: XPASS: gfortran.dg/vect/vect-5.f90 on PPC64

Dorit, I only have access to Darwin PPC at -m64 and x86_64. However I have only been directly testing Darwin PPC at -m64 and relying on the gcc-testresults mailing list archive for the rest of the architectures. Perhaps someone else here can provide a dump file generated by -fdump-tree-vect-det

Re: XPASS: gfortran.dg/vect/vect-5.f90 on PPC64

Opps. I meant... Index: vect-5.f90 === --- vect-5.f90 (revision 117033) +++ vect-5.f90 (working copy) @@ -35,7 +35,7 @@ stop end -! { dg-final { scan-tree-dump-times "vectorized 2 loops" 1 "vect" { xfail { lp64

how to combine make check options?

Is it possible to combine different options together when running the testsuite? For example I can run... make check-objc RUNTESTFLAGS="--target_board=unix/-fgnu-runtime" and make check-objc RUNTESTFLAGS='--target_board="unix{,-m64}"' However I don't see how to combine this so that both -m3

libffi on Darwin PPC at -m64

Has anyone ever run the libffi testsuite when built at -m64 on Darwin PPC? It appears that every single test fails at -m64 on execution. Jack

re: libffi on Darwin PPC at -m64

Okay, I mispoke...not every test fails on Darwin PPC at -m64... === libffi Summary for unix/-m32 === # of expected passes1068 # of expected failures 8 # of unsupported tests 8 === libffi Summary for unix/-m64 === # of expected pa

Re: libffi on Darwin PPC at -m64

Andreas, Okay. Is it acceptable to open a PR on that issue as a placekeeper for Darwin PPC64 support? Jack

re: GCC 4.3 Platform List

Mark, Since Apple is committed (at least in their advertising) to provide 64-bit development tools for both PPC and Intel in Leopard, it would seem a tad premature to downgrade the powerpc-apple-darwin in favor of i686-apple-darwin for 4.3. Why not just upgrade i686-apple-darwin to a secondary

Re: GCC 4.2 Status Report (2006-09-21)

Mark, I just posted two small patches which together complete the fix for PR26792. This knocks one blocking PR1 off the list. Jack http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00906.html http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00908.html

cast to pointer from integer of different size

Andrew, I've been trying to get a handle on why the line... frame = (StackFrame *)stack_start; in gcc/boehm-gc/darwin_stop_world.c only generates the warning... ../../../../gcc-4.2-20060920/boehm-gc/darwin_stop_world.c:76: warning: cast to pointer from integer of different size when co

Re: cast to pointer from integer of different size

Peter, Wouldn't we want something like... Index: darwin_stop_world.c === --- darwin_stop_world.c (revision 117133) +++ darwin_stop_world.c (working copy) @@ -61,7 +61,11 @@ typedef struct StackFrame { unsigned longsaved

Re: cast to pointer from integer of different size

Peter, Looking at the libffi/src/powerpc/ffi.c file, I assume that I should have the same... *next_arg++ = (unsigned long)(char *)ecif->rvalue; in ffi_darwin.c instead of the current... *next_arg++ = (unsigned)(char *)ecif->rvalue; Does that sound right? If so, I'll file a PR for this

Re: cast to pointer from integer of different size

Peter, Okay so what we need is... Index: ffi_darwin.c === --- ffi_darwin.c(revision 117142) +++ ffi_darwin.c(working copy) @@ -94,7 +94,7 @@ /* 'next_arg' grows up as we put parameters in it. */ - unsigned

Re: cast to pointer from integer of different size

Peter, I should have added that when I last tested libffi at -m64 on Darwin PPC and saw roughly half of the tests fail... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29152 ...it seemed that the failures were all in the dg-output tests. Hopefully this fix will have some positive results in the

Re: Darwin as primary platform

Geoff, How would the powerpc-darwin -m64 support and x86_64 fit into this scheme? Would they be considered variants of the powerpc-darwin and i386-darwin architectures and thus primary platforms as well? Or would they be secondary platforms? With Apple's 64-bit commitment in Leopard, they shoul

'argz_next__' discards qualifiers from pointer target type

While reviewing my gcc trunk build log on Darwin PPC, I noticed the following... /sw/src/fink.build/gcc4-4.1.-20060928/darwin_objdir/./prev-gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.-20060928/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc4/powerpc-apple-darwin8/bin / -c -I/sw/include -g -O2 -md

dereferencing type-punned pointer will break strict-aliasing rules

Has anyone noticed that we are breaking the strict-aliasing ruls in natVMVirtualMachine.cc? /sw/src/fink.build/gcc4-4.1.-20060928/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc4-4.1.-20060928/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc 4-4.1.-200609

fix for l10nflist.c?

The following changes eliminate the warnings when l10nflist.c is compiled... --- /Users/howarth/gcc/intl/l10nflist.c 2006-08-13 14:29:20.0 -0400 +++ l10nflist.c 2006-09-30 17:24:19.0 -0400 @@ -139,12 +139,12 @@ #endif /* !_LIBC && !HAVE___ARGZ_STRINGIFY */ #if !defined _LIB

unwind-dw2-fde-darwin.c

I'm a little confused by the current usage of getsectdatafromheader_64 in unwind-dw2-fde-darwin.c on Darwin PPC. I see a build warning of... /sw/src/fink.build/gcc4-4.1.-20060928/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.-20060928/darwin_objdir/./gcc/ -B/sw/lib/gcc4/powe

Darwin libgcj linkage issue

I noticed that on Darwin PPC we get warnings of the form... symbol _fabsf used from dynamic library /usr/lib/libm.dylib(fabs.o) not from earlier dynamic library /sw/lib/gcc4/lib/libgcj.8.dylib(sf_fabs.o) symbol _fabs used from dynamic library /usr/lib/libm.dylib(fabs.o) not from earlier dynam

Re: Darwin libgcj linkage issue

Andrew, I could be wrong here but if you really intend to avoid using the system version of those math calls, the appropriate thing to do is to rename them in java as local versions (eg java_sf_fabsf, etc). Jack

unwind-dw2-fde-darwin.c changes

Geoff, Can you explain why we don't have... Index: unwind-dw2-fde-darwin.c === --- unwind-dw2-fde-darwin.c (revision 117350) +++ unwind-dw2-fde-darwin.c (working copy) @@ -61,7 +61,7 @@ struct mach_header; struct mach_hea

Darwin PPC 64 objc improvements

Geoff and Mike, These results are preliminary because they aren't from a complete rebuild of gcc trunk, but from a previous bootstrap with the my proposed fix to unwind-dw2-fde-darwin.c applied http://gcc.gnu.org/ml/gcc/2006-10/msg00018.html however a... make -k check RUNTESTFLAGS="--tar

unwind-dw2-fde-darwin.c corrections

Geoff, I made one typo in my original proposed patch for unwind-dw2-fde-darwin.c. It should be... Index: unwind-dw2-fde-darwin.c === --- unwind-dw2-fde-darwin.c (revision 117350) +++ unwind-dw2-fde-darwin.c (working copy)

Re: unwind-dw2-fde-darwin.c corrections

Geoff, So should we have... #ifdef __ppc__ fde = getsectdatafromheader (image->mh, "__DATA", "__eh_frame", &sz); #endif #ifdef __ppc64__ fde = getsectdatafromheader_64 ((struct mach_header_64 *)image->mh, "__DATA", "__eh_frame", &sz); #endif or does the check for __DATA eh frames have

Re: unwind-dw2-fde-darwin.c corrections

Geoff, Well removing the portions of my previous patch which weren't being used, the effective change that I had (which eliminated the failures under MacOS X 10.4.8 with the -m64 objc testsuite) was... diff -uNr gcc-4.2-20061002/gcc/unwind-dw2-fde-darwin.c gcc-4.2-20061002.allocatable_unwind-d

Re: Darwin PPC 64 objc improvements

Mike, So everyone here sees these, as I sent you in a private email, I think I've puzzled out what happened here. The objc failures I have been seeing are an artifact of the make check exp scripts when using... make -k check RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'" which is what I norm

Re: Darwin as primary platform

David, I should probably point out that a lot of those bug reports are mine and refer to the test failures in the Darwin PPC at -m64. These are all recent bug reports of which a quite a few may actually be issues with cctools. So I wouldn't really use those a metric A more valid concern may b

testsuite exp programming issue

I am trying to adjust the current gcc/gcc/testsuite/lib/objc.exp to allow it to build against the gnu-objc runtime library in the case of -m64 compiles on Darwin8. Unfortunately, I've hit a brick wall in terms of catching the instance of '-m64' being passed to the compiler flags. Normally I do

Re: testsuite exp programming issue

Andrew, I'll double check but I don't think the testcases which use -fnext-runtime were failing when I had these changes hardwired in for -m64. The reason is that the -fgnu-runtime appears on the cflags and gets overridden when a specific testcase appends -fnext-runtime because that appears last

<    1   2   3   4   5   6   >