Re: mismatched parentheses in reload1.c

[Andreas Jaeger]

Jan Hubicka <[EMAIL PROTECTED]> writes:

>> 
>>   else if (rld[r].out_reg == 0
>>&& rld[r].in != 0
>>&& ((REG_P (rld[r].in)
>> && REGNO (rld[r].in) >= FIRST_PSEUDO_REGISTER
>> && !REGNO_REG_SET_P (®_has_output_reload,
>>  REGNO (rld[r].in))
>>|| (REG_P (rld[r].in_reg)
>>&& !REGNO_REG_SET_P (®_has_output_reload,
>> REGNO (rld[r].in)
>>&& ! reg_set_p (rld[r].reg_rtx, PATTERN (insn)))
>> 
> Sadly there is yet another typo in this particular change (I didn't
> noticed even after proofreading the patch again after Paolo's original
> mail).  It is causing the enable checking bootstrap fialures.

Yes, the bootstrap failure is fixed now for me,

Andreas
-- 
 Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


pgpAPIXJsBi9Q.pgp
Description: PGP signature

Re: REG_OK_STRICT and EXTRA_CONSTRAINT

[Hans-Peter Nilsson]

On Fri, 25 Aug 2006, Paolo Bonzini wrote:
> After I'm done with the base_reg_class changes, I will try
> modifying address_operand to be something along the lines of your U
> constraint:

Yeah, that does sound like the real bug; nothing should be using
non-strict checking after reload as address_operand seems to do.

> This will also affect the 'p' constraint, and in the end address your
> "FIXME: This is arguably a bug in gcc."

Wow, I had that?  I didn't think of looking at its *use*
yesterday... been away from gcc for a while.

>  Of course, again, this is
> subject to testing.

I haven't everything set up for testing, but will try your
change when that happens (no less than a week from now).

> Thanks to Zack for discussing this on IRC and hypothesizing that this
> may be a real bug in GCC.

And thanks to you for looking into this!

brgds, H-P

Backend for PicoBlaze

[Armin Vogl]

Hello,

I would like to ask if it would be possible to write a gcc backend for the
Xilinx PicoBlaze soft processor.

If you never heard about it, please look here:

http://www.xilinx.com/ipcenter/processor_central/picoblaze/picoblaze_user_resources.htm

As I have never programmed anything like a compiler and am
not familiar with gcc, I would like to ask how much time it would
need to implement a backend. Is it realistic to do it myself or is
there a place to request the addition of a backend.

Is it realistic for somebody with zero gcc experience to implement a backend
in a reasonable time (whatever that may mean :) ?

Or maybe I have to hope that some of you guys are implementing it. As 
PicoBlaze is

an open source soft processor, it would fit to gcc quite well, or ?

If you get 100 such requests per month or if this completely off topic here, 
I

appologize in advance.

Armin

Re: make check glitch

[Steve Ellcey]

> > From: [EMAIL PROTECTED] (Jack Howarth)
> > MIME-Version: 1.0
> > 
> > make -k check RUNTESTFLAGS='--target_board "unix{,-m64}"'
> > 
> > I run the same command from the toplevel of the darwin_objdir
> > directory, the make check bails out with...
> 
> It works for me on RHEL 4 U4:
> 
> http://gcc.gnu.org/ml/gcc-testresults/2006-08/msg01064.html
> 
> I am using RUNTESTFLAGS=--target_board 'unix{-m32,}'.
> 
> 
> H.J.

I run in 32 and 64 bit modes on IA64 HP-UX and I once changed from
"--target_board 'unix{-mlp64,-milp32}" to "--target_board
'unix{,-mlp64}" and had problems.  I notice that HJ's example
has the -m32 in the first position, not the last.

Jack, does it work for you if you use "unix{-m64,}" instead of
"unix{,-m64}"?

Steve Ellcey
[EMAIL PROTECTED]

Re: Backend for PicoBlaze

[Ian Lance Taylor]

"Armin Vogl" <[EMAIL PROTECTED]> writes:

> I would like to ask if it would be possible to write a gcc backend for the
> Xilinx PicoBlaze soft processor.

Porting gcc to an 8-bit microcontroller is not completely impossible,
but it is not easy.  gcc was written to generate code for 32-bit
processors, and tends to get in a register crunch on very small
processors.  While I didn't look at the PicoBlaze docs at all, small
processors also tend to have specialized addressing modes which tend
to confuse gcc.  Fixing these problems in a gcc port tends to put you
into the most complex part of the compiler, which is reload.

> As I have never programmed anything like a compiler and am
> not familiar with gcc, I would like to ask how much time it would
> need to implement a backend. Is it realistic to do it myself or is
> there a place to request the addition of a backend.
> 
> Is it realistic for somebody with zero gcc experience to implement a backend
> in a reasonable time (whatever that may mean :) ?

It's obviously hard to say.  There is fairly decent documentation and
there are plenty of existing examples.  One advantage of a small
processor is that there isn't all that much to implement--it's mostly
debugging.  An excellent programmer could probably get up to speed and
do the backend port in a few months.  (For comparison, I've written a
few gcc backend ports already, and last year I did a port to a 16-bit
microcontroller in less than a month, but the chip had the advantage
of having 16 registers and only one addressing mode (register
indirect)).

There is no place to request a backend port, other than the e-mail you
sent.  Most such requests go unanswered.  A backend port is hard
enough that most people wouldn't do one without a good reason.

Ian

Re: make check glitch

[Jack Howarth]

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 mentioned as a requirement. It might be worth filing a PR
related to this issue. Either the equals sign is required (and the
documentation needs to be explicit on this point) or some sections
of the testsuite is broken in the absence of the equals sign.
Jack

How to use "nothing" in pipeline description?

[H. J. Lu]

If an instruction has latency 3 and throughput 1, should I write it as

(define_insn_reservation "simple" 3
  (eq_attr "memory" "none")
  "p0")

or

(define_insn_reservation "simple" 3
  (eq_attr "memory" "none")
  "p0,nothing*2")

Are they equivalent? What happens when there are fewer reservation
cycles than default latency?

Thanks.


H.J.

Re: Backend for PicoBlaze

[Armin Vogl]

Thanks for answering. I already feared that it wouldn't be trivial after
reading through the documentation ... I think a PicoBlaze backend
would be very intersting for the soft processor community.

Armin


There is no place to request a backend port, other than the e-mail you
sent.  Most such requests go unanswered.  A backend port is hard
enough that most people wouldn't do one without a good reason.

Ian

4.2 regression: gcc 4.2 revision 116385 miscompiles fma3d in SPEC CPU 2K

[H. J. Lu]

fma3d in SPEC CPU 2K failed with revision 116385 on x86 and x86-64. 
revision 116362 is OK. Has anyone else seen it? 


H.J.

Re: Backend for PicoBlaze

[Rask Ingemann Lambertsen]

On Fri, Aug 25, 2006 at 06:06:47PM +0200, Armin Vogl wrote:
> Hello,
> 
> I would like to ask if it would be possible to write a gcc backend for the
> Xilinx PicoBlaze soft processor.

   I'll make a few comments about it.

1. 8-bit wide registers (and ALU).

   GCC can generate disappointingly poor code for programs which deal with
data types larger than a register.

2. 16 general purpose registers.

   Normally, 16 registers would be considered enough, but when they are only
8 bits each, and the PicoBlaze is a load-store architechture, adding two
64-bit values would take all your registers, so if you want to support e.g.
64-bit C "long long int", it could become "interesting".

3. Register classes.

  It looks like you will only have NO_REGS and ALL_REGS, with GENERAL_REGS
being identical to ALL_REGS except for the condition code register. That's
the ideal situation for GCC.

4. Stack and argument passing.

   PicoBlaze has an internal call/return stack which can't be used for
passing arguments. How will the STACK_POINTER_REGNUM macro and the
"push" instruction pattern be specified?

5. Addressing modes.

  Very simple. An address is taken from a register or an immediate. As an
"interesting" feature, function address can only be immediate values. I.e.
jump tables and function pointers can't be used. Note that the GCC Internals
documentation, says (in the section "Standard Pattern Names For
Generation"):

`indirect_jump'

An instruction to jump to an address which is operand zero.  This
pattern name is mandatory on all machines.

I don't see how it can be supported. But most programs don't need it.

6. Comparisons and condition codes.

  PicoBlaze only supports unsigned comparison. Extra instructions are needed
for signed comparison. Because of this, comparison instructions can't be
output until it is known how the comparison result is used. Delayed output
of the comparison is only a minor problem and some of GCC's existing targets
already do that.

> As I have never programmed anything like a compiler and am
> not familiar with gcc, I would like to ask how much time it would
> need to implement a backend. Is it realistic to do it myself or is
> there a place to request the addition of a backend.

I think it is realistic to get a PicoBlaze backend to the point where it
generates correct code in a month or two. Making it generate good code could
take several months. With "good code", I mean not significantly worse than
that generated by a human.

I suggest that before you do anything else, you figure out how to pass
arguments to functions and figure out an instruction sequence which performs
signed comparison.

The PicoBlaze has a program storage of at most 1024 instructions and a data
storage of 64 bytes. Is it really necessary and useful to port GCC to such a
target?

-- 
Rask Ingemann Lambertsen

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

[Jack Howarth]

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 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 of the 'test for excess errors' type. Sure
enough if you examine them you these are identical to those in the
-m64 libgfortran build...

Executing on host: 
/sw/src/fink.build/gcc4-4.1.999-20060825/darwin_objdir/./gcc/g++ -shared-libgcc 
-B/sw/src/fink.build/gcc4-4.1.999-20060825/darwin_objdir/./gcc -nostdinc++ 
-L/sw/src/f
ink.build/gcc4-4.1.999-20060825/darwin_objdir/powerpc-apple-darwin8/ppc64/libstdc++-v3/src
 
-L/sw/src/fink.build/gcc4-4.1.999-20060825/darwin_objdir/powerpc-apple-darwin8/ppc64/libstdc++
-v3/src/.libs -B/sw/lib/gcc4/powerpc-apple-darwin8/bin/ 
-B/sw/lib/gcc4/powerpc-apple-darwin8/lib/ -isystem 
/sw/lib/gcc4/powerpc-apple-darwin8/include -isystem /sw/lib/gcc4/powerpc-apple
-darwin8/sys-include -m64 -g -O2 -D_GLIBCXX_ASSERT -ffunction-sections 
-fdata-sections -fmessage-length=0 -g -O2 -DLOCALEDIR="." -nostdinc++ 
-I/sw/src/fink.build/gcc4-4.1.999-20060825/d
arwin_objdir/powerpc-apple-darwin8/ppc64/libstdc++-v3/include/powerpc-apple-darwin8
 
-I/sw/src/fink.build/gcc4-4.1.999-20060825/darwin_objdir/powerpc-apple-darwin8/ppc64/libstdc++-v3/inc
lude 
-I/sw/src/fink.build/gcc4-4.1.999-20060825/gcc-4.2-20060825/libstdc++-v3/libsupc++
 
-I/sw/src/fink.build/gcc4-4.1.999-20060825/gcc-4.2-20060825/libstdc++-v3/include/backward
 -I/sw/s
rc/fink.build/gcc4-4.1.999-20060825/gcc-4.2-20060825/libstdc++-v3/testsuite/util
 testsuite_abi.o testsuite_allocator.o testsuite_character.o testsuite_hooks.o 
twister_rand_gen.o verifie
d_cmd_line_input.o prog_bar.o dbg_ex_allocator_base.o elapsed_timer.o 
/sw/src/fink.build/gcc4-4.1.999-20060825/gcc-4.2-20060825/libstdc++-v3/testsuite/23_containers/deque/modifiers/swap
/2.cc-multiply_defined suppress -include bits/stdtr1c++.h  -lm   -m64 -o 
./2.exe(timeout = 600)
can't find atom for N_GSYM stabs alloc_map:G(0,60) in /var/tmp//ccauYkmP.o
output is:
can't find atom for N_GSYM stabs alloc_map:G(0,60) in /var/tmp//ccauYkmP.o

FAIL: 23_containers/deque/modifiers/swap/2.cc (test for excess errors)

So I think the linker guys really should look into this as c++ IS a core 
langauge for Apple.
FYI
   Jack

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

[Eric Christopher]

Jack Howarth wrote:

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 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 out of the office due to 
other reasons. I will be looking at it shortly, especially as I've got 
x86_64 patches. :)


-eric

Re: Backend for PicoBlaze

[Mike Stump]

On Aug 25, 2006, at 2:59 PM, Rask Ingemann Lambertsen wrote:

`indirect_jump'

An instruction to jump to an address which is operand zero.  This
pattern name is mandatory on all machines.

I don't see how it can be supported. But most programs don't need it.


Well, the usual way would be to compute the value into a register and  
then store it into .+n and have a call 0 follow that code and then,  
presto, you get a call n...  if data and instructions are not  
separated and instruction memory is writable.  Threading code doesn't  
`work' necessarily, but, that probably isn't an issue on such machines.

gcc-4.1-20060825 is now available

[gccadmin]

Snapshot gcc-4.1-20060825 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060825/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch 
revision 116441

You'll find:

gcc-4.1-20060825.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20060825.tar.bz2 C front end and core compiler

gcc-ada-4.1-20060825.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20060825.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20060825.tar.bz2  C++ front end and runtime

gcc-java-4.1-20060825.tar.bz2 Java front end and runtime

gcc-objc-4.1-20060825.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20060825.tar.bz2The GCC testsuite

Diffs from 4.1-20060818 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Backend for PicoBlaze

[Armin Vogl]

I suggest that before you do anything else, you figure out how to pass
arguments to functions and figure out an instruction sequence which 
performs

signed comparison.


Thaks for your comments. I start to think it is actally more complicated 
that
I had first thought. I must admit that I currently don't fully understand 
all of

your comments, but I am sure that this will get better when I read the
documentation a few times ...

The PicoBlaze has a program storage of at most 1024 instructions and a 
data
storage of 64 bytes. Is it really necessary and useful to port GCC to such 
a

target?


Good question :) On a medium sized FPGA there could run more than 10 
instances
of PicoBlaze doing different stuff. Though the code for one core may be only 
little,

the total amount of code could be quite large.

Somebody is currently developing a c-compiler for the PicoBlaze, but it does 
not
seem to be open source and if I would write my code in C, then I need a 
reliable

tool chain.

It could still be overkill to write a backend for this kind of core I must 
admit. The
reason why I ask is, that I need to decide what is more time consuming. 
Writing the

backend, or doing everything in machine language...And of course I wanted to
know if some of you are already working with PicoBlaze but have decided not
to write a backend and what the reasons are.

Armin

Re: 4.2 regression: gcc 4.2 revision 116385 miscompiles fma3d in SPEC CPU 2K

[H. J. Lu]

On Fri, Aug 25, 2006 at 01:51:26PM -0700, H. J. Lu wrote:
> fma3d in SPEC CPU 2K failed with revision 116385 on x86 and x86-64. 
> revision 116362 is OK. Has anyone else seen it? 
> 

Never mind. I have an old library.


H.J.

Re: How to use "nothing" in pipeline description?

[Vladimir N. Makarov]

H. J. Lu wrote:


If an instruction has latency 3 and throughput 1, should I write it as

(define_insn_reservation "simple" 3
 (eq_attr "memory" "none")
 "p0")

or

(define_insn_reservation "simple" 3
 (eq_attr "memory" "none")
 "p0,nothing*2")

Are they equivalent?


Yes.


What happens when there are fewer reservation
cycles than default latency?

 

They are different things.  Latency is used for finding data ready 
delays (priorities used to order insns according their critical path 
length).  When input data are ready for an insn, the reservations are 
checked to find that there are enough functional units to execute the 
insn.  So there is no correlation between latency time and reservations 
with the compiler point of view.


Frequently, reservation is shorter than the latency because after a few 
cycles there will be never reservation hazards because further execution 
is fully pipelined (in other words we always have enough functional 
units for the further execution).  In this case we can omit reservation 
of the corresponding functional units.  Latency time less than the 
reservation length is also permitted but usually it has no sense 
(although we can describe all execution pipeline stages like prefetching 
and decoding.  Latency times usually are given only for actual operation 
execution without such stages).


Vlad

Re: Backend for PicoBlaze

[Ian Lance Taylor]

Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:

> 4. Stack and argument passing.
> 
>PicoBlaze has an internal call/return stack which can't be used for
> passing arguments. How will the STACK_POINTER_REGNUM macro and the
> "push" instruction pattern be specified?

For STACK_POINTER_REGNUM you just pick one of the general purpose
registers and don't use it for anything else.  You don't have to
define the push instructions, so you don't.  Instead you define
ACCUMULATE_OUTGOING_ARGS.  If you want some registers to be callee
saved, which you probably do, then you hand generate the prologue and
epilogue instructions; with the limited address space, you will
probably want to jump to a library routine to do it.

>   Very simple. An address is taken from a register or an immediate. As an
> "interesting" feature, function address can only be immediate values. I.e.
> jump tables and function pointers can't be used. Note that the GCC Internals
> documentation, says (in the section "Standard Pattern Names For
> Generation"):

Processors without jump to register indirect suck.  If instructions
and data are in the same address space, you can use self-modifying
code.  Making that both thread-safe and small is a pain, but you
probably don't have to worry about threads.

> The PicoBlaze has a program storage of at most 1024 instructions and a data
> storage of 64 bytes. Is it really necessary and useful to port GCC to such a
> target?

1024 instructions?  That is small.

Ian

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

[Jack Howarth]

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;

  typedef __gnu_test::uneq_allocator my_alloc;
  typedef deque my_deque;

  my_deque::size_type size01;

  my_alloc alloc01(1);

  my_deque deq01(alloc01);

}

int main()
{
  test01();
  return 0;
}

...using the testsuite_hooks.h and testsuite_allocator.h headers from
gcc/libstdc++-v3/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

fp-int-convert-timode, TImode and Darwin

[Jack Howarth]

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 the
fp-int-convert-timode testcase fails at all optimization levels. Interestingly
the failures are not due to the long or long double sections of the testcase
but rather the float section. I was able to reduce this to smaller testcase
by reducing the fp-int-convert-timode testcase to calls to...

TEST_I_F(TItype, UTItype, float, FLT_MANT_DIG)

which then only calls one of the six possible failing tests...

  TEST_I_F_VAL (I, F, HVAL0S (P, I) + 1, P_OK (P, I));  

This shortened testcase when processed with -E in gcc can be
recasted as the expanded macros in the following testcase...

#include 
#include 

extern void abort (void);
extern void exit (int);
typedef int TItype __attribute__ ((mode (TI)));
typedef unsigned int UTItype __attribute__ ((mode (TI)));

int
main (void)
{
  do {
  do {
  static volatile TItype ivin, ivout;
  static volatile float fv1, fv2;
  ivin = ((TItype)(((24) >= sizeof(TItype) * 8 - 1) ? (TItype)1 : 
(((TItype)1 << (sizeof(TItype) * 8 - 2)) + ((TItype)1 << (sizeof(TItype) * 8 - 
2 - 24 + 1);
  fv1 = ((TItype)(((24) >= sizeof(TItype) * 8 - 1) ? (TItype)1 : 
(((TItype)1 << (sizeof(TItype) * 8 - 2)) + ((TItype)1 << (sizeof(TItype) * 8 - 
2 - 24 + 1);
  fv2 = ivin; ivout = fv2;
  if (ivin != ((TItype)(((24) >= sizeof(TItype) * 8 - 1) ? (TItype)1 : 
(((TItype)1 << (sizeof(TItype) * 8 - 2)) + ((TItype)1 << (sizeof(TItype) * 8 - 
2 - 24 + 1) || 24) >= sizeof(TItype) * 8)) && ivout != ivin) || 24) 
>= sizeof(TItype) * 8)) && ivout != ((TItype)(((24) >= sizeof(TItype) * 8 - 1) 
? (TItype)1 : (((TItype)1 << (sizeof(TItype) * 8 - 2)) + ((TItype)1 << 
(sizeof(TItype) * 8 - 2 - 24 + 1)) || fv1 != ((TItype)(((24) >= 
sizeof(TItype) * 8 - 1) ? (TItype)1 : (((TItype)1 << (sizeof(TItype) * 8 - 2)) 
+ ((TItype)1 << (sizeof(TItype) * 8 - 2 - 24 + 1) || fv2 != ((TItype)(((24) 
>= sizeof(TItype) * 8 - 1) ? (TItype)1 : (((TItype)1 << (sizeof(TItype) * 8 - 
2)) + ((TItype)1 << (sizeof(TItype) * 8 - 2 - 24 + 1) || fv1 != fv2) 
printf("fv1 %f fv2 %f ivin %d ivout %d\n",fv1,fv2,(int)ivin,(int)ivout);
 } while (0);
  } while (0);
  exit (0);
}

...where I have replaced the abort() call with a printf() on Darwin. This test 
compiled
as 'gcc -O3 -g -m64' produces the following output when executed on a G5...

fv1 85070601871439417691678863831567695872.00 fv2 
85070591730234615865843651857942052864.00 ivin 1 ivout 0

which compares to the correct result obtained on Linux x86_64 (with the 
printf() placed after the if statement of
course) of...

fv1 85070601871439417691678863831567695872.00 fv2 
85070601871439417691678863831567695872.00 ivin 1 ivout 0

So the problem on Darwin seems to be with conversion of the float results to 
integer results.
Geoff has said he has done all he intends to with TImode for now so perhaps 
someone else more
interested might take a look at this bug (which may well be independent of, but 
exposed by the
TImode support).
Jack

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

[Eric Christopher]

So the problem on Darwin seems to be with conversion of the float results to 
integer results.
Geoff has said he has done all he intends to with TImode for now so perhaps 
someone else more
interested might take a look at this bug (which may well be independent of, but 
exposed by the
TImode support).


FWIW this works for me with the TImode patch that Geoff posted (that I 
need for x86_64 anyhow)...


-eric

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

[Jack Howarth]

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 get
TImode into gcc trunk last spring and we are going to be
waiting until gcc 4.3.
   Jack
ps I know Andrew will object that Darwin x86_64 isn't
a secondary target, but perhaps he might agree that since
the current gcc trunk's generating non-existant symbol
references when long long math is used on Darwin PPC
that it fixes a bug rather than represents an enhancement.

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

[Eric Christopher]

Jack Howarth wrote:

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 get
TImode into gcc trunk last spring and we are going to be
waiting until gcc 4.3.


Yes, it's a necessary part of the x86_64 work - the question is whether 
or not x86_64-darwin might go in for 4.2 at all.


-eric

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

[Jack Howarth]

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 official gcc 4.2 release.
However, if the x86_64 support is put off, I can easily see
a push for gcc 4.3 snapshots in fink (yuck).
  Jack