Re: [PATCH] PR optimization/11980: Fix strcat builtin on x86_64.

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

> Shouldn't x86_64-*-freebsd* be fixed (instead of this or primarily,
> in addition to this patch)?
> Using unsigned int size_t on x86_64 is a bug I'd say.
> x86_64-*-linux* certainly correctly uses long unsigned int:
> i386/x86-64.h:#undef SIZE_TYPE
> i386/x86-64.h:#define SIZE_TYPE (TARGET_64BIT ? "long unsigned int" : "unsigned int")

> x86_64-*-freebsd* overrides this later on in i386/freebsd.h
> (similarly PTRDIFF_TYPE).

> Also, WCHAR_TYPE* needs double checking (from what I can see,
> x86_64.h will define WCHAR_TYPE to int, yet WCHAR_TYPE_SIZE (defined
> to 32 by x86_64.h) is then redefined to BITS_PER_WORD in freebsd.h.

Agreed.  Thank you for conducting this analysis Jakub.  Yikes!
(...checking...) The system compiler on FreeBSD/x86-64 is configured
as you suggest it should on both counts (i.e. not as it is in the FSF
tree).  It has been so configured since June 21, 2002.  Sorry, this is
a port which is not used by me nor tested and reported in any
automatic fashion which would catch it.

Roger and PR reporter (Dara?), David O'Brien indeed sent me the patch
required in May but it was dropped from the FSF tree.  I don't know
how that happened but please forgive me for any pain that I caused.
David and I are actually in the middle of a resync process (since the
OS imported 3.3.x from FSF a while back and, unrelated to this issue,
since there were generic changes to various system conventions visible
to gcc).  For the record, we do attempt to keep the following
logically equivalent (and, if possible, also "textually equivalent"):

:pserver:anoncvs@anoncvs.freebsd.org:/home/ncvs/ src/contrib/gcc/config (main)
:pserver:anoncvs@gcc.gnu.org:/cvs/gcc/ gcc/gcc/config (main/active branches)

However, patches sometimes get into one tree without the other and
there is a time lag.  Oddly enough, i386/freebsd.h contains the
largest diff at the moment of any FreeBSD arch, which conspired to
make this issue invisible during my recent spot check...

As committed to mainline, as obvious.  Could someone that can actually
test it in branch context on the affected hardware, please do so?  If
it indeed fixes the regression as predicted, then install it under
this quoted rule (or report back to me, if you rather I do it):

	Fix regression from "gcc derived from earlier FSF src release
	configured as the system compiler".

Regards,
Loren

2003-09-03  David O'Brien  <obrien@FreeBSD.org>

	optimization/11980
	* config/i386/freebsd.h (SIZE_TYPE): Support TARGET_64BIT.
	(PTRDIFF_TYPE): Likewise.
	(WCHAR_TYPE_SIZE): Likewise.

Index: config/i386/freebsd.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/i386/freebsd.h,v
retrieving revision 1.38
diff -c -r1.38 freebsd.h
*** config/i386/freebsd.h	20 Aug 2003 22:00:26 -0000	1.38
--- config/i386/freebsd.h	4 Sep 2003 03:22:06 -0000
***************
*** 50,62 ****
  /* Make gcc agree with <machine/ansi.h>.  */
  
  #undef  SIZE_TYPE
! #define SIZE_TYPE "unsigned int"
   
  #undef  PTRDIFF_TYPE
! #define PTRDIFF_TYPE "int"
    
  #undef  WCHAR_TYPE_SIZE
! #define WCHAR_TYPE_SIZE BITS_PER_WORD
      
  /* Provide a STARTFILE_SPEC appropriate for FreeBSD.  Here we add
     the magical crtbegin.o file (see crtstuff.c) which provides part 
--- 50,62 ----
  /* Make gcc agree with <machine/ansi.h>.  */
  
  #undef  SIZE_TYPE
! #define SIZE_TYPE	(TARGET_64BIT ? "long unsigned int" : "unsigned int")
   
  #undef  PTRDIFF_TYPE
! #define PTRDIFF_TYPE	(TARGET_64BIT ? "long int" : "int")
    
  #undef  WCHAR_TYPE_SIZE
! #define WCHAR_TYPE_SIZE	(TARGET_64BIT ? 32 : BITS_PER_WORD)
      
  /* Provide a STARTFILE_SPEC appropriate for FreeBSD.  Here we add
     the magical crtbegin.o file (see crtstuff.c) which provides part