Re: Host/Target confusion in Dwarf output
> This means that the largest int on the host must be at least half the > size of the largest int on the target. Hence, building 64-bit target > compilers on 32-bit host systems has never been a problem. I'm not sure I'd go as far as saying "has never been a problem". It's "mostly worked", but did have optimization losses and various minor issues from time to time. There was enough of a problem that (before the days when we switched to HOST_WIDE_INT being "long long") I wanted to be sure that I used a 64-bit host since I needed to build 64-bit targets.
Re: Host/Target confusion in Dwarf output
Jim Wilson wrote: This does mean that you can't build a 128-bit target compiler on a 32-bit host, but that hasn't been a problem yet. And now that we allow HOST_WIDE_INT to be defined as long long, this shouldn't be a problem any more either. A 32-bit host with 2 long longs gets us up to 128-bit constants. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Host/Target confusion in Dwarf output
Michael Eager wrote: Is it guaranteed to hold all target integer sizes? How does this work for 32-bit hosts and 64-bit targets? RTL and tree constants were defined from the beginning as two HOST_WIDE_INTs. This was necessary to bootstrap long long support on 32-bit systems before most compilers had long long support. This means that the largest int on the host must be at least half the size of the largest int on the target. Hence, building 64-bit target compilers on 32-bit host systems has never been a problem. We have never supported 16-bit hosts from the beginning, so that is no problem. This does mean that you can't build a 128-bit target compiler on a 32-bit host, but that hasn't been a problem yet. This restriction by the way is one of the reasons why long long is 64-bits on 64-bit targets, because the 32-bit hosts used to build the initial 64-bit cross compilers could not support 128-bit integer constants. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Host/Target confusion in Dwarf output
On 7/12/07, Michael Eager <[EMAIL PROTECTED]> wrote: Eric Botcazou wrote: >> How does this work for 32-bit hosts and 64-bit targets? > > Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT. Meaning that I can't build gcc-ppc64 on an IA32 host? No, he said they require a 64 bit HOST_WIDE_INT. Anything with a 64 bit integer can have a 64 bit HOST_WIDE_INT. Yuck! So much for cross-platform tools. Patches welcome --Dan
Re: Host/Target confusion in Dwarf output
On 7/12/07, Michael Eager <[EMAIL PROTECTED]> wrote: Meaning that I can't build gcc-ppc64 on an IA32 host? HUH? Yes you can, HWI is a64bit integer type there (aka long long). -- Pinski
Re: Host/Target confusion in Dwarf output
Eric Botcazou wrote: How does this work for 32-bit hosts and 64-bit targets? Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT. Meaning that I can't build gcc-ppc64 on an IA32 host? Yuck! So much for cross-platform tools. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Host/Target confusion in Dwarf output
> Sorry: I guess my information is dated. What changed so that it's now > required? I presume the reasons you gave + the usual nasty bugs prompted someone to decide that it was not worth the troubles after all. -- Eric Botcazou
Re: Host/Target confusion in Dwarf output
> > They don't REQUIRE it, but just miss a lot of optimization if that isn't > > the case (since things that would otherwise be CONST_INT will now be > > CONST_DOUBLE and folding will be harder). > > # need_64bit_hwint Set to yes if HOST_WIDE_INT must be 64 bits wide > # for this target. This is true iff this target > # supports "long" or "wchar_t" wider than 32 bits. Sorry: I guess my information is dated. What changed so that it's now required?
Re: Host/Target confusion in Dwarf output
> They don't REQUIRE it, but just miss a lot of optimization if that isn't > the case (since things that would otherwise be CONST_INT will now be > CONST_DOUBLE and folding will be harder). # need_64bit_hwint Set to yes if HOST_WIDE_INT must be 64 bits wide # for this target. This is true iff this target # supports "long" or "wchar_t" wider than 32 bits. alpha*-*-*) cpu_type=alpha need_64bit_hwint=yes ;; x86_64-*-*) cpu_type=i386 extra_headers="mmintrin.h mm3dnow.h xmmintrin.h emmintrin.h pmmintrin.h tmmintrin.h ammintrin.h smmintrin.h nmmintrin.h" need_64bit_hwint=yes ;; ia64-*-*) extra_headers=ia64intrin.h need_64bit_hwint=yes ;; mips*-*-*) cpu_type=mips need_64bit_hwint=yes ;; powerpc*-*-*) cpu_type=rs6000 extra_headers="ppc-asm.h altivec.h spe.h" need_64bit_hwint=yes case x$with_cpu in xpowerpc64|xdefault64|x6[23]0|x970|xG5|xpower[3456]|xpower6x|xrs64a) cpu_is_64bit=yes ;; esac ;; rs6000*-*-*) need_64bit_hwint=yes ;; sparc64*-*-*) cpu_type=sparc need_64bit_hwint=yes ;; spu*-*-*) cpu_type=spu need_64bit_hwint=yes ;; s390*-*-*) cpu_type=s390 need_64bit_hwint=yes ;; sh[123456789lbe]*-*-*) cpu_type=sh need_64bit_hwint=yes ;; -- Eric Botcazou
Re: Host/Target confusion in Dwarf output
> > How does this work for 32-bit hosts and 64-bit targets? > > Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT. They don't REQUIRE it, but just miss a lot of optimization if that isn't the case (since things that would otherwise be CONST_INT will now be CONST_DOUBLE and folding will be harder).
Re: Host/Target confusion in Dwarf output
> How does this work for 32-bit hosts and 64-bit targets? Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT. -- Eric Botcazou
Re: Host/Target confusion in Dwarf output
> HOST_WIDE_INT is the wide integer type used throughout the compiler. I haven't looked at the definition. Is it guaranteed to hold all target integer sizes? No. How does this work for 32-bit hosts and 64-bit targets? Often we use "long long" for HOST_WIDE_INT, but in other cases, the answer is "not as well as we might like".
Re: Host/Target confusion in Dwarf output
Eric Botcazou wrote: Why would the RTL represent target CONST_INT as HOST_WIDE_INT? HOST_WIDE_INT is the wide integer type used throughout the compiler. I haven't looked at the definition. Is it guaranteed to hold all target integer sizes? How does this work for 32-bit hosts and 64-bit targets? -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Host/Target confusion in Dwarf output
> Why would the RTL represent target CONST_INT as HOST_WIDE_INT? HOST_WIDE_INT is the wide integer type used throughout the compiler. -- Eric Botcazou
Re: Host/Target confusion in Dwarf output
Mike Stump wrote: On Jul 12, 2007, at 9:23 AM, Michael Eager wrote: I was looking through dwarf2out.c, tracking down the cause for different assembly code being generated when gcc was run on 32-bit and 64-bit hosts. When QAing, it is very useful to be able to compare two .s files. This means that we should strive for them being bit identical. Does that mean we should do tons of work to make that happen, no, or waste tons of compile time to make that happen, no. But, if at all possible and reasonable to do, we should do it. For the harder cases, just think of a long term strategy to make it work, and try and socialize that direction to go in. Agreed. I probably wouldn't have noticed the differences if they didn't cause the compile to fail. If the differences were benign, as I first though, I probably would have shrugged, said "that's not good", and continued on. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Host/Target confusion in Dwarf output
Ian Lance Taylor wrote: Michael Eager <[EMAIL PROTECTED]> writes: It seems to me that the same assembly code should be generated independent of whether gcc is run on a 32-bit or 64-bit host and all of these HOST_* tests should actually be target domain parameters, like BITS_PER_WORD. It is sad but true that there are various cases in gcc which differ based on the size of an integer on the host. So far as I know none of them amount to bugs, but as you've seen they do lead to different code generation. The most obvious difference here is that CONST_INTs in RTL are stored as HOST_WIDE_INTs. And it is that difference which are you seeing, propagated into the debug code. In this case, the difference is not trivial. On a 64-bit host, gcc generates code that the assembler rejects and, if I recall correctly, DWARF_FORM_8 which is not supported by the target binutils. That latter may be a binutils defect. Either way, it counts as a bug if the compile doesn't finish. Why would the RTL represent target CONST_INT as HOST_WIDE_INT? Confusion between host and target? I think that in general it would be good to fix these issues, so that we generate the same assembler code for a given target from any host. The cases to really think through in detail are a 32-bit host and a 64-bit target. I don't have that combination, that could be problematic. With the current definition of RTL, I don't think you can fix dwarf2out.c independently of fixing other parts of the compiler. But, if I am wrong in that, go for it. Jeez, I hope that's not the case. I don't want to start fixing a small problem in DWARF output and end up re-architecting the RTL. (I'm exaggerating, but only a little). -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Host/Target confusion in Dwarf output
On Jul 12, 2007, at 9:23 AM, Michael Eager wrote: I was looking through dwarf2out.c, tracking down the cause for different assembly code being generated when gcc was run on 32-bit and 64-bit hosts. When QAing, it is very useful to be able to compare two .s files. This means that we should strive for them being bit identical. Does that mean we should do tons of work to make that happen, no, or waste tons of compile time to make that happen, no. But, if at all possible and reasonable to do, we should do it. For the harder cases, just think of a long term strategy to make it work, and try and socialize that direction to go in.
Re: Host/Target confusion in Dwarf output
Michael Eager <[EMAIL PROTECTED]> writes: > I was looking through dwarf2out.c, tracking down the > cause for different assembly code being generated > when gcc was run on 32-bit and 64-bit hosts. > > In dwarf2out.c, there are several places where decisions > about what to generate in the .s file are based on > HOST_BITS_PER_WIDE_INT or HOST_BITS_PER_WIDE_LONG or > similar. For example, when generating a long long value, > on a 32-bit host, the *target* assembly code will contain > two .4byte ops, while on a 64-bit host, a single .8byte > op is generated. There are a number of other differences. > > The assembler for a 32-bit target might not have a .8byte > operator. So, when run on a 32-bit host, everything is OK. > On a 64-bit host, the assembly fails. > > It seems to me that the same assembly code should be generated > independent of whether gcc is run on a 32-bit or 64-bit > host and all of these HOST_* tests should actually be > target domain parameters, like BITS_PER_WORD. It is sad but true that there are various cases in gcc which differ based on the size of an integer on the host. So far as I know none of them amount to bugs, but as you've seen they do lead to different code generation. The most obvious difference here is that CONST_INTs in RTL are stored as HOST_WIDE_INTs. And it is that difference which are you seeing, propagated into the debug code. I think that in general it would be good to fix these issues, so that we generate the same assembler code for a given target from any host. The cases to really think through in detail are a 32-bit host and a 64-bit target. With the current definition of RTL, I don't think you can fix dwarf2out.c independently of fixing other parts of the compiler. But, if I am wrong in that, go for it. Ian
RE: Host/Target confusion in Dwarf output
On 12 July 2007 17:51, Andrew Pinski wrote: > On 7/12/07, Dave Korn <[EMAIL PROTECTED]> wrote: >> On 12 July 2007 17:23, Michael Eager wrote: >> >> Sounds right to me. Basing codegen decisions on HOST_ is just plain >> wrong and has been an ongoing source of bugs down the years. > > Except in this case, the code gen is the same, just the assembly file > is different. I don't think comparing two assembly files is a good > test, comparing two object files is different and should be the same > between the two compilers. I think it's not clearly defined: it's one of the goals for gcc to produce the same "output" when compiling a given source with a given set of flags regardless of any of the properties of the host, but I don't think it's specified whether "output" means the assembler source output by gcc itself, or the object filess that are, after all, technically the outputs of gas, not gcc Also, wasn't this part of a problem just a little while ago when 64-bit arithmetic was introduced in gas? I have this memory there was an issue when each of the 32-bit words that make up a 64-bit pair got sign-promoted independently and then something went wrong, or at any rate went differently from when there was a single .8byte value. I'll go see if I can find it in the archives. cheers, DaveK -- Can't think of a witty .sigline today
Re: Host/Target confusion in Dwarf output
On 7/12/07, Dave Korn <[EMAIL PROTECTED]> wrote: On 12 July 2007 17:23, Michael Eager wrote: Sounds right to me. Basing codegen decisions on HOST_ is just plain wrong and has been an ongoing source of bugs down the years. Except in this case, the code gen is the same, just the assembly file is different. I don't think comparing two assembly files is a good test, comparing two object files is different and should be the same between the two compilers. -- Pinski
RE: Host/Target confusion in Dwarf output
On 12 July 2007 17:23, Michael Eager wrote: > I was looking through dwarf2out.c, tracking down the > cause for different assembly code being generated > when gcc was run on 32-bit and 64-bit hosts. > > In dwarf2out.c, there are several places where decisions > about what to generate in the .s file are based on > HOST_BITS_PER_WIDE_INT or HOST_BITS_PER_WIDE_LONG or > similar. For example, when generating a long long value, > on a 32-bit host, the *target* assembly code will contain > two .4byte ops, while on a 64-bit host, a single .8byte > op is generated. There are a number of other differences. > > The assembler for a 32-bit target might not have a .8byte > operator. So, when run on a 32-bit host, everything is OK. > On a 64-bit host, the assembly fails. > > It seems to me that the same assembly code should be generated > independent of whether gcc is run on a 32-bit or 64-bit > host and all of these HOST_* tests should actually be > target domain parameters, like BITS_PER_WORD. > > Comments? Sounds right to me. Basing codegen decisions on HOST_ is just plain wrong and has been an ongoing source of bugs down the years. cheers, DaveK -- Can't think of a witty .sigline today
