Re: Compiling with -m64 using attribute interrupt emits IRET not IRETQ

On Thu, Jan 28, 2016 at 11:06 AM, Wink Saville wrote: > Thanks. How are you testing? > > * { dg-do compile } */ /* { dg-options "-O2 -Wall -g" } */ void __attribute__((interrupt)) fn (void *frame) { } /* { dg-final { scan-assembler-not "add(l|q)\[\\t \]*\\$\[0-9\]*,\[\\t \]*%\[re\]?sp" } } */ /

Re: Compiling with -m64 using attribute interrupt emits IRET not IRETQ

On Thu, Jan 28, 2016 at 10:26 AM, H.J. Lu wrote: > On Thu, Jan 28, 2016 at 9:06 AM, Wink Saville wrote: >> I using hjl/interrupt/gcc-5-branch and my program is crashing when I >> issue an INT xx. The problem appears to me to be that using >> __attribute__ ((interrupt)) causes the a IRET to be emi

Re: Compiling with -m64 using attribute interrupt emits IRET not IRETQ

On Thu, Jan 28, 2016 at 9:06 AM, Wink Saville wrote: > I using hjl/interrupt/gcc-5-branch and my program is crashing when I > issue an INT xx. The problem appears to me to be that using > __attribute__ ((interrupt)) causes the a IRET to be emitted when an > IRETQ should be emitted. Below is my tri

Compiling with -m64 using attribute interrupt emits IRET not IRETQ

intr_frame* frame) { } void main(void) { } $ x86_64-unknown-elf-gcc -c main.c -o main.o -m64 $ x86_64-unknown-elf-objdump -d main.o main.o: file format elf64-x86-64 Disassembly of section .text: : 0: 55 push %rbp 1: 48 89 e5 mov%rsp

tmpdir-gcc.dg-struct-layout-1 failures at -m64 on powerpc

Janis, Do you have any idea why powerpc-apple-darwin9 would be seeing the tmpdir-gcc.dg-struct-layout-1 execution failures that I reported in PR's 39912, 39913, 39915, 39916, 39917, 39918, 39919, 39920 and 39921 but not on powerpc64-*-linux? Could this be specific to -fPIC? Jack

Re: [Ada] strange errors with make check -j2 --target_board=\{-m32,-m64\}

th make check -j2 > > --target_board=\{-m32,-m64\}. > > > > Executing on host: /home/manuel/test/139674M/build/gcc/gnatmake > > -I/home/manuel/test/139674M/build/gcc/ada/rts > > --GCC=/home/manuel/test/139674M/build/gcc/xgcc --GNATBIND=\ > > /home/manuel/test/13967

Re: [Ada] strange errors with make check -j2 --target_board=\{-m32,-m64\}

On Thu, Aug 28, 2008 at 12:36 PM, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > Dear all, > > I get the following errors when running the GNAT testsuite on > x86_64-unknown-linux-gnu with make check -j2 > --target_board=\{-m32,-m64\}. > > Executing on host: /home/ma

[Ada] strange errors with make check -j2 --target_board=\{-m32,-m64\}

Dear all, I get the following errors when running the GNAT testsuite on x86_64-unknown-linux-gnu with make check -j2 --target_board=\{-m32,-m64\}. Executing on host: /home/manuel/test/139674M/build/gcc/gnatmake -I/home/manuel/test/139674M/build/gcc/ada/rts --GCC=/home/manuel/test/139674M/build

Re: [libstdc++] testsuite failures on sparc biarch using -m64: tr1_impl/boost_shared_ptr.h error:

On 04/02/2008, Christian Joensson <[EMAIL PROTECTED]> wrote: > > > > > > Thanks for the logs, I don't have any way to test on that platform > > > unfortunately, but it seems that the symlinks for the new shared_ptr > > > headers are missing. I think that would happen if you hadn't done a > > > cle

Re: [libstdc++] testsuite failures on sparc biarch using -m64: tr1_impl/boost_shared_ptr.h error:

2008/1/28, Christian Joensson <[EMAIL PROTECTED]>: > 2008/1/26, Jonathan Wakely <[EMAIL PROTECTED]>: > > On 22/01/2008, Christian Joensson wrote: > > > 2008/1/21, Jonathan Wakely > > > > My first guess would be that you've somehow got the C++0x and TR1 > > > > versions of boost_sp_shared_count.h mi

Re: [libstdc++] testsuite failures on sparc biarch using -m64: tr1_impl/boost_shared_ptr.h error:

2008/1/26, Jonathan Wakely <[EMAIL PROTECTED]>: > On 22/01/2008, Christian Joensson wrote: > > 2008/1/21, Jonathan Wakely > > > My first guess would be that you've somehow got the C++0x and TR1 > > > versions of boost_sp_shared_count.h mixed up and you're including the > > > wrong one. > > > > well

Re: [libstdc++] testsuite failures on sparc biarch using -m64: tr1_impl/boost_shared_ptr.h error:

On 22/01/2008, Christian Joensson wrote: > 2008/1/21, Jonathan Wakely > > My first guess would be that you've somehow got the C++0x and TR1 > > versions of boost_sp_shared_count.h mixed up and you're including the > > wrong one. > > well, the testsuite results are posted at, e.g., > > http://gcc.gn

Re: [libstdc++] testsuite failures on sparc biarch using -m64: tr1_impl/boost_shared_ptr.h error:

On 21/01/2008, Paolo Carlini <[EMAIL PROTECTED]> wrote: > Christian Joensson wrote: > > Now, is there some funny stuff going on here that I simply miss or is > > this what to expect currently? > > > I would suggest compiling the testcase outside the testsuite and having > a look to the pre-processe

Re: [libstdc++] testsuite failures on sparc biarch using -m64: tr1_impl/boost_shared_ptr.h error:

Christian Joensson wrote: > Now, is there some funny stuff going on here that I simply miss or is > this what to expect currently? > I would suggest compiling the testcase outside the testsuite and having a look to the pre-processed output. On all the other targets I have available things are fi

[libstdc++] testsuite failures on sparc biarch using -m64: tr1_impl/boost_shared_ptr.h error:

For some time now, I've been getting libstdc++ testsuite failures on my sparc biarch system running the libstdc++ testsuite with -m64. A lot of these failures seems to me to have in common the following failure, that only shows up using -m64, not running in default, ie, 32 bit mode: /usr/

10 to 20% speedup with -m64 on Intel Core2Duo

Some time ago I had a look at pr30388 and got the following results: g77 -O2 g95 -O2 gfc -O2 gfc -m64 -O2 MFLOPS: 10631061 8581129 ref. g77-19% +6% Since the evening is quite calm I decided to check if

Re: vect failures at -m64 on darwin

> Jack Howarth has reported vect failures at -m64 on darwin with gfortran: > > http://gcc.gnu.org/ml/fortran/2007-08/msg00041.html > > I see the same kind of failures with gcc 4.3.0 revision 127178: > My guess is it's related to the recent patch that does not allow peelin

vect failures at -m64 on darwin

Jack Howarth has reported vect failures at -m64 on darwin with gfortran: http://gcc.gnu.org/ml/fortran/2007-08/msg00041.html I see the same kind of failures with gcc 4.3.0 revision 127178: FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c scan-tree-dump-times vectorization not profitable 1

Re: libffi on Darwin PPC at -m64

> "Jack" == Jack Howarth <[EMAIL PROTECTED]> writes: Jack>Okay. Is it acceptable to open a PR on that Jack> issue as a placekeeper for Darwin PPC64 support? Yes, thanks. Tom

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: libffi on Darwin PPC at -m64

Jack Howarth wrote: 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 Sigh, I can't resist! There is _NO_ 64-bit libffi port for darwin ppc.

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

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: Why test objc at -m64 for Darwin8?

On Sep 16, 2006, at 10:18 AM, Jack Howarth wrote: 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? Sure. Bonus points for letting the GNU runtime based tests run (if that makes sense).

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 baf

RE: objc linkage problems on Darwin PPC with -m64

-20060915/gcc/testsuite/objc/execute/exceptions/catchall-1.m -w -O0 -fobjc-exceptions /sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/powerpc-apple-darwin8/ppc64/libobjc/.libs/libobjc-gnu.2.0.0.dylib -lm -m64 -o catchall-1.x0 Undefined symbols: _objc_exception_try_exit, referenced from

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/20

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

Eric Christopher <[EMAIL PROTECTED]> writes: >> Once the noise from those linker warnings is removed from the libstdc++-v3 >> testsuite >> results at -m64 on Darwin PPC, we find that the failures drop from 54 to >> just 6. So >> we actually only have fo

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

Once the noise from those linker warnings is removed from the libstdc++-v3 testsuite results at -m64 on Darwin PPC, we find that the failures drop from 54 to just 6. So we actually only have four additional libstdc++-v3 testsuite failures at -m64 compared to -m32. These are... FAIL: 21_strings

Re: gcc.target/powerpc vs -m64

FAIL: gcc.target/powerpc/ppc-and-1.c scan-assembler rlwinm [0-9]+, [0-9]+,0,0,30 FAIL: gcc.target/powerpc/ppc-and-1.c scan-assembler rlwinm [0-9]+, [0-9]+,0,29,30 FAIL: gcc.target/powerpc/ppc-negeq0-1.c scan-assembler-not cntlzw are a tad confusing because if I do... gcc-4 -O2 -m64 -S -c ppc

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

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

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

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 foll

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

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

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

Re: regress and -m64

). Jack ps I'll start a make check for both -m32/-m64 and post it as soon as its done.

Re: regress and -m64

On Aug 28, 2006, at 5:08 PM, Jack Howarth wrote: Okay. How about this. Have regress set to at least do a -m64 make check once a week. I think it is a G4, so testing G5 code-gen might have to wait until the G5 emulator is done. :-) Can you contribute G5 results once a week? At least that

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

Re: regress and -m64

On Aug 28, 2006, at 3:57 PM, Jack Howarth wrote: > If we can't speed up the testing ? -j2 makes testing go faster as well. Sigh, I misstated that one. My comment in that case was about the general case. I meant to say that -j2 is as applicable to testing as it is to buil

Re: regress and -m64

it up. > Or doesn't Darwin support parallel builds? Yes, of course it does. > If we can't speed up the testing ? -j2 makes testing go faster as well. > then we could at least speed up the build process to free up time > for -m64.

Re: regress and -m64

. Or doesn't Darwin support parallel builds? Yes, of course it does. If we can't speed up the testing ? -j2 makes testing go faster as well. then we could at least speed up the build process to free up time for -m64.

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

Re: regress and -m64

On Aug 28, 2006, at 1:20 PM, Jack Howarth wrote: Might that not increase the rate of testing on regress? Sorry, nope.

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

dered building/testing non-default things, and has generally shied away from non-default things. Bear in mind, the addition of -m64 comes at the cost of being able to test less often. He isn't the only one known to contribute test results on darwin however. I'd cert

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&#x

Re: regress and -m64

the command... make -k check RUNTESTFLAGS='--target_board="unix{,-m64}"' my make check is make -k -j 8 check RUNTESTFLAGS="--target_board 'unix{-mcpu=970/-m64}'" I don't see any reason to check the 32-bit stuff that the regression checker checks at least once a day. Brad

Re: regress and -m64

rovide the TImode symbols for its long long math operations. This will eliminate about 800 failures from the gfortran testsuite. You need the patches above for ignoring the linker warnings from ld64 to eliminate the remaining 40 some false failures from the gfortran testsuite. The same is true for l

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

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

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 w

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

/testsuite/util. Compiling this with... g++-4 -O3 -g -m64 -I. test.cc can't find atom for N_GSYM stabs alloc_map:G(0,3) in /var/tmp//ccPQUmeQ.o ...produces the warning. It's easier to reproduce in gfortran since all you need is to declare a COMMON block. Jack

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

FYI, the trick is to use the equal sign after the --target-board option... make -k check RUNTESTFLAGS='--target_board="unix{,-m64}"' So I think the linker guys really should look into this as c++ IS a core langauge for Apple. I've been following your mail, but have been

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

o use the equal sign after the --target-board option... make -k check RUNTESTFLAGS='--target_board="unix{,-m64}"' I noticed that I had 2 unexpected failures in the libstdc++ testsuite at -m32 but 54 unexpected failures in the libstdc++ testsuite at -m64 almost all of which were o

Re: Darwin -m64 results

On Aug 23, 2006, at 4:57 PM, Jack Howarth wrote: ...which is quite nice since it is the same number of failures as with -m32 with three additional unexpected passes. Excellent. Nice to hear. What I found was that I could set a breakpoint at assign.f90:1 but when I tried to run the program

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

Re: Darwin -m64 results

Mike, Actually, while building tonight's svn pull, I noticed that the linker warnings have actually been present during the linkage of libgfortran.dylib for the -m64 part of the multilib build... /bin/sh ./libtool --mode=link /sw/src/fink.build/gcc4-4.1.999-20060821/darwin_objdir/

Re: Darwin -m64 results

Re: Darwin -m64 results

On Aug 21, 2006, at 6:34 AM, Jack Howarth wrote: I just wanted to be clear that you believe only the line... + .stabs "i:G(0,3)",32,0,4,0 in that .s file is incorrect I never said that, let me refer you to my previous email for what I said. I did say that it was causing the problem.

Re: Darwin -m64 results

Mike, As I mentioned before, the simple test case of... program test integer i end shows the following change in its .s file when the "common i" is added... --- assign.s.nocommon 2006-08-19 10:45:59.0 -0400 +++ assign.s2006-08-19 10:46:19.0 -0400 @@ -1

Re: Darwin -m64 results

On Aug 19, 2006, at 7:58 AM, Jack Howarth wrote: ...so even if "i" were being optimized away only ld64 seems to care. Yes. The ld 32-bit linker remains silent on the issue. Yes.

Re: Darwin -m64 results

On Aug 19, 2006, at 7:50 AM, Jack Howarth wrote: I don't believe that this warning with "-O3 -m64 -g" is due to the fortran compiler optimizing away the storage. DId you read my previous emails on this topic? If not, please see it, if you have, please read it again. I t

Re: Darwin -m64 results

Mike, One other observation. The only differences in the .s output for compiling... program test integer i common i end ...with -m32 and -m64 is... --- assign_m32.s2006-08-19 10:53:33.0 -0400 +++ assign_m64.s2006-08-19 10:53:59.0 -0400

Re: Darwin -m64 results

Mike, I don't believe that this warning with "-O3 -m64 -g" is due to the fortran compiler optimizing away the storage. If I compile... program test integer i,j common i do j = 1,100 i=i+1 end do end I still see the warning "

Re: Darwin -m64 results

On Aug 17, 2006, at 5:43 PM, Mike Stump wrote: On Aug 17, 2006, at 4:26 PM, Jack Howarth wrote: I assume the linker is choking on the line... .stabs "i:G(0,3)",32,0,4,0 ...right? Yes. The linker is complaining that there is no _i in the program. If you add one, it would have wor

Re: Darwin -m64 results

On Aug 17, 2006, at 4:26 PM, Jack Howarth wrote: I assume the linker is choking on the line... .stabs "i:G(0,3)",32,0,4,0 ...right? Yes. The linker is complaining that there is no _i in the program. If you add one, it would have worked. I'm asking our linker and debugger peopl

Re: Darwin -m64 results

FX, That was spot on. If I reduce the test case down to... ! { dg-do run } ! Program to test ASSIGNing a label to common variable. PR18827. program test integer i common i end I still get the linkage error... gfortran -O3 -g -m64 assign.f90 can't find atom for N

Re: Darwin -m64 results

The bug hits about 38 other test in gfortran. These include... FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/assign.f90 -O3 -g (test for excess errors) [...SNIP...] Just in case, you can detect any sort of pattern from that set of tests

Re: [4.1/4.2 regression]: Gcc -m64 -m32 passes --32 --64 to assembler

> > On Sat, Apr 22, 2006 at 01:56:21AM +0200, Andi Kleen wrote: > > > Since they are assembly codes, it sounds like a gcc driver issue to me. > > > > Might be. The way the assembly is built is a bit funky because it's a > > shared library. > > It is a gcc bug > > http://gcc.gnu.org/bugzilla/sh

[4.1/4.2 regression]: Gcc -m64 -m32 passes --32 --64 to assembler

On Sat, Apr 22, 2006 at 01:56:21AM +0200, Andi Kleen wrote: > > Since they are assembly codes, it sounds like a gcc driver issue to me. > > Might be. The way the assembly is built is a bit funky because it's a > shared library. It is a gcc bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27253

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 really seen many

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

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 really seen many cleanups that were x86/darwin- specific I'm gett

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: Results for 4.1.0 20060117 (prerelease) testsuite on powerpc-apple-darwin8.4.0 (-m64 results)

I'm not recommending anything, I'm trying to help you verify whether GCC's testsuite is failing because of testsuite bugs, gcc bugs, tools bugs, or OS bugs. This should help you focus on the legitimate problems with gcc. In this case, the thousands of failures were an interaction between

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

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

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 cctools-590.18 and ld64-26.0.81, which should be subst

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

and I was hoping that this might clear up a significant fraction of the 7,000+ 64-bit testsuite failures for 4.1 on powerpc-apple- darwin8.4.0. But it appears this hasn't happened yet. Does anyone wish to try yet again to drive it into my thick skull what goals gcc 4.1 has on powerpc-appl

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: FAIL: gcc.dg/sparc-frame-1.c (test for excess errors) with -m64 on sparc/sparc64 linux...

> Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc > -B/usr/local/src/trunk/objdir/gcc/ > /usr/local/src/trunk/gcc/gcc/testsuite/gcc.dg/sparc-frame-1.c -O -g > -fno-show-column -S -m64 -o sparc-frame-1.s(timeout = 1200) > /usr/local/src/trunk/gcc/gcc/testsuite/gcc.dg/

FAIL: gcc.dg/sparc-frame-1.c (test for excess errors) with -m64 on sparc/sparc64 linux...

Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc/ /usr/local/src/trunk/gcc/gcc/testsuite/gcc.dg/sparc-frame-1.c -O -g -fno-show-column -S -m64 -o sparc-frame-1.s(timeout = 1200) /usr/local/src/trunk/gcc/gcc/testsuite/gcc.dg/sparc-frame-1.c: In

Re: m64

ji an wrote: > when I input the command line: >>g++ -m64 -o test test.cc > error message was output: > /tmp/ccyjpGIh.o(.text+0x900): In function `main': > : relocation truncated to fit: R_X86_64_32 This kind of question is more appropriate for gcc-help. The gcc list is

m64

Hello, can anyone tell me how to use option -m64 in g++ (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.1)? when I input the command line: >g++ -m64 -o test test.cc error message was output: /tmp/ccyjpGIh.o(.text+0x900): In function `main': : relocation truncated to fit: R_X86_64_32 . .