bogus .quad in i386/att.h

bogus .quad in i386/att.h

[Robert Lipe]

Jan, your commit that starts: 

Tue Oct  2 12:46:01 CEST 2001  Bo Thorsen     <bo@suse.co.uk>,
                               Andreas Jaeger <aj@suse.de>,
                               Jan Hubicka    <jh@suse.cz>

        * doc/invoke.texi (i386 Options): Document x86-64 options.
        (i386 and x86-64 Options): Rename i386 options section.


added an entry for ASM_QUAD in att.h.   But the ChangeLog does not
call out any change to att.h.

.quad is definitely not something supported by the AT&T-derived
assemblers.  Maybe it's a GAS thing and should be in gas.h.  Maybe it's
an x86-64 thing and should be in x86-64.h.  But att.h sure seems like
the wrong place for it.  This does show up as testsuite failures.

Can you please move this?

Thank you,
RJL

Re: bogus .quad in i386/att.h

[Richard Henderson]

On Wed, Oct 10, 2001 at 09:24:34PM +0200, Jan Hubicka wrote:
> Quite possibly. Sadly I can't undefine ASM_OUTPUT_DOUBLE_INT for 32bit
> target, so we need to come with way to output it properly, most probably
> by splitting the integer to two longs when 32bit target is present.

That would happen automatically if ASM_OUTPUT_DOUBLE_INT were
not present.

I think the best thing would be to pull the ASM_OUTPUT_<integer>
macros into the target structure, and allow them to return false
on failure.


r~

Re: bogus .quad in i386/att.h

[Jan Hubicka]

> > > > ..quad is definitely not something supported by the AT&T-derived
> > > > assemblers.  Maybe it's a GAS thing and should be in gas.h.  Maybe
> > > > it's
> >
> > The idea was that we need some ASM_QUAD definition in order to
> > compile w/o extra ifdef garbage around. 
> 
> And in general, I support that goal.
> 
> > The ASM_QUAD will be used only for 64bit compilation att.h looked
> 
> But this assertion is incorrect.  Right now I have too many trees ripped
> up to be able to tell you definitively _what_ it's used for, but my pet
> targets, which are definitely not x86-64 cognizant, were getting nailed
> by occurrences of '.quad' in the assembler output during testsuite runs.
Hmm, too bad :(
Can you send me the testcase?
> 
> Perhaps it's becuase you now defined ASM_OUTPUT_DOUBLE_INT so
> varasm.c:assemble_integer is using it behind your back to write things
> even when not TARGET_64BIT?
Quite possibly. Sadly I can't undefine ASM_OUTPUT_DOUBLE_INT for 32bit
target, so we need to come with way to output it properly, most probably
by splitting the integer to two longs when 32bit target is present.

I am offline for a week. Would be OK to prepare patch sometime next week?
Honza
> 
> RJL

Re: bogus .quad in i386/att.h

[Robert Lipe]

> > > ..quad is definitely not something supported by the AT&T-derived
> > > assemblers.  Maybe it's a GAS thing and should be in gas.h.  Maybe
> > > it's
>
> The idea was that we need some ASM_QUAD definition in order to
> compile w/o extra ifdef garbage around. 

And in general, I support that goal.

> The ASM_QUAD will be used only for 64bit compilation att.h looked

But this assertion is incorrect.  Right now I have too many trees ripped
up to be able to tell you definitively _what_ it's used for, but my pet
targets, which are definitely not x86-64 cognizant, were getting nailed
by occurrences of '.quad' in the assembler output during testsuite runs.

Perhaps it's becuase you now defined ASM_OUTPUT_DOUBLE_INT so
varasm.c:assemble_integer is using it behind your back to write things
even when not TARGET_64BIT?

RJL

Re: bogus .quad in i386/att.h

[Jan Hubicka]

> > ..quad is definitely not something supported by the AT&T-derived
> > assemblers.  Maybe it's a GAS thing and should be in gas.h.  Maybe it's
> > an x86-64 thing and should be in x86-64.h.  But att.h sure seems like
> > the wrong place for it.  This does show up as testsuite failures.
> >
> > Can you please move this?
> 
> I don't know why Jan re-introduced this, it wasn't in the last patch I sent 
> before going on vacation. I tested x86-64 compilation without the att.h patch 
> (which was included in the first time I sent the patch) and it seemed to 
> work. Jan can you comment on why you added it again?

The idea was that we need some ASM_QUAD definition in order to compile w/o
extra ifdef garbage around. The ASM_QUAD will be used only for 64bit compilation
att.h looked like right place to do, as all currently supported assemblers are
derivation of it and even when there isn't official att assembler for x86_64.

Honza

Re: bogus .quad in i386/att.h

[Bo Thorsen]

On Tirsdag 09 Oktober 2001 03:43, Billinghurst, David (CRTS) wrote:
> and it broke cygwin bootstrap
> http://gcc.gnu.org/ml/gcc-bugs/2001-10/msg00084.html
>
> -----Original Message-----
> From: Robert Lipe [ mailto:robertlipe@usa.net ]
> Sent: Tuesday, 9 October 2001 11:38
> To: gcc@gcc.gnu.org
> Cc: jh@suze.cz
> Subject: bogus .quad in i386/att.h
>
>
> Jan, your commit that starts:
>
> Tue Oct  2 12:46:01 CEST 2001  Bo Thorsen     <bo@suse.co.uk>,
>                                Andreas Jaeger <aj@suse.de>,
>                                Jan Hubicka    <jh@suse.cz>
>
>         * doc/invoke.texi (i386 Options): Document x86-64 options.
>         (i386 and x86-64 Options): Rename i386 options section.
>
>
> added an entry for ASM_QUAD in att.h.   But the ChangeLog does not
> call out any change to att.h.
>
> ..quad is definitely not something supported by the AT&T-derived
> assemblers.  Maybe it's a GAS thing and should be in gas.h.  Maybe it's
> an x86-64 thing and should be in x86-64.h.  But att.h sure seems like
> the wrong place for it.  This does show up as testsuite failures.
>
> Can you please move this?

I don't know why Jan re-introduced this, it wasn't in the last patch I sent 
before going on vacation. I tested x86-64 compilation without the att.h patch 
(which was included in the first time I sent the patch) and it seemed to 
work. Jan can you comment on why you added it again?

Bo.

Just as a reference, I'm appending the last patch I sent before being offline 
for the last two weeks.

2001-09-21  Bo Thorsen  <bo@suse.co.uk>

        * config/i386/linux64.h: New spec file for Linux x86-64 support.
        * config.gcc: Fix tm_file settings for x86-64.
        * config/i386/x86-64.h: New file with OS independent x86-64
        definitions.

Index: config.gcc
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config.gcc,v
retrieving revision 1.91
diff -u -r1.91 config.gcc
--- config.gcc   2001/09/18 21:51:52     1.91
+++ config.gcc   2001/09/21 14:04:13
@@ -222,6 +222,9 @@
 i[34567]86-*-*)
         cpu_type=i386
         ;;
+x86_64-*-*)
+        cpu_type=i386
+        ;;
 hppa*-*-* | parisc*-*-*)
         cpu_type=pa
         ;;
@@ -1132,6 +1135,17 @@
                         # aka GNU/Linux C library 6
         xmake_file=x-linux
         tm_file="i386/i386.h i386/att.h linux.h i386/linux.h"
+        tmake_file="t-slibgcc-elf-ver t-linux i386/t-crtstuff"
+        extra_parts="crtbegin.o crtbeginS.o crtend.o crtendS.o"
+        gnu_ld=yes
+        float_format=i386
+        if test x$enable_threads = xyes; then
+                thread_file='posix'
+        fi
+        ;;
+x86_64-*-linux*)
+        xmake_file=x-linux
+        tm_file="i386/x86-64.h i386/i386.h i386/att.h linux.h i386/linux64.h"
         tmake_file="t-slibgcc-elf-ver t-linux i386/t-crtstuff"
         extra_parts="crtbegin.o crtbeginS.o crtend.o crtendS.o"
         gnu_ld=yes
Index: config/i386/x86-64.h
===================================================================
RCS file: x86-64.h
diff -N x86-64.h
--- /dev/null    Tue May  5 13:32:27 1998
+++ x86-64.h     Fri Sep 21 07:04:13 2001
@@ -0,0 +1,43 @@
+/* OS independent definitions for AMD x86-64.
+   Copyright (C) 2000 Free Software Foundation, Inc.
+   Contributed by Bo Thorsen <bo@suse.de>.
+
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+#define TARGET_64BIT_DEFAULT
+#define NO_BUILTIN_PTRDIFF_TYPE
+#define TARGET_BI_ARCH
+#define NO_BUILTIN_SIZE_TYPE
+
+/* System V Release 4 uses DWARF debugging info.  Buf DWARF1 doesn't do
+   64-bit anything, so we use DWARF2.  */
+
+#undef DWARF2_DEBUGGING_INFO
+#undef DWARF_DEBUGGING_INFO
+#undef DBX_DEBUGGING_INFO
+#define DWARF2_DEBUGGING_INFO
+#define DBX_DEBUGGING_INFO
+#define DWARF2_FRAME_INFO (TARGET_64BIT && TARGET_UNWIND_INFO)
+#define DWARF2_UNWIND_INFO 1
+#define ASYNCHRONOUS_DWARF2_UNWIND_INFO (TARGET_64BIT && TARGET_UNWIND_INFO)
+/* Incorrectly autodetected in cross compilation.  */
+#undef HAVE_AS_DWARF2_DEBUG_LINE
+#define HAVE_AS_DWARF2_DEBUG_LINE
+
+#undef PREFERRED_DEBUGGING_TYPE
+#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG
Index: config/i386/linux64.h
===================================================================
RCS file: linux64.h
diff -N linux64.h
--- /dev/null    Tue May  5 13:32:27 1998
+++ linux64.h    Fri Sep 21 07:04:13 2001
@@ -0,0 +1,147 @@
+/* Definitions for AMD x86-64 running Linux-based GNU systems with ELF 
format.
+   Copyright (C) 2000 Free Software Foundation, Inc.
+   Contributed by Jan Hubicka <jh@suse.cz> based on linux.h.
+
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+#define LINUX_DEFAULT_ELF
+
+#undef QUAD_ASM_OP
+#define QUAD_ASM_OP                     "\t.quad\t"
+
+#undef TARGET_VERSION
+#define TARGET_VERSION fprintf (stderr, " (x86-64 Linux/ELF)");
+
+/* The svr4 ABI for the i386 says that records and unions are returned
+   in memory.  */
+#undef DEFAULT_PCC_STRUCT_RETURN
+#define DEFAULT_PCC_STRUCT_RETURN 1
+
+#undef ASM_COMMENT_START
+#define ASM_COMMENT_START "#"
+
+/* This is how to output an element of a case-vector that is relative.
+   This is only used for PIC code.  See comments by the `casesi' insn in
+   i386.md for an explanation of the expression this outputs. */
+#undef ASM_OUTPUT_ADDR_DIFF_ELT
+#define ASM_OUTPUT_ADDR_DIFF_ELT(FILE, BODY, VALUE, REL) \
+  if (TARGET_64BIT) \
+    fprintf (FILE, "\t.long %s%d-.+4+(.-%s%d)\n", LPREFIX, VALUE, LPREFIX, 
REL); \
+  else  \
+    fprintf (FILE, "\t.long _GLOBAL_OFFSET_TABLE_+[.-%s%d]\n", LPREFIX, 
VALUE)
+
+/* Indicate that jump tables go in the text section.  This is
+   necessary when compiling PIC code.  */
+#define JUMP_TABLES_IN_TEXT_SECTION (flag_pic && !TARGET_64BIT)
+
+#undef DBX_REGISTER_NUMBER
+#define DBX_REGISTER_NUMBER(n) \
+  (TARGET_64BIT ? dbx64_register_map[n] : svr4_dbx_register_map[n])
+
+/* Output assembler code to FILE to call the profiler.
+   To the best of my knowledge, no Linux libc has required the label
+   argument to mcount.  */
+
+#define NO_PROFILE_COUNTERS
+
+#undef FUNCTION_PROFILER
+#define FUNCTION_PROFILER(FILE, LABELNO)  \
+{                                                                       \
+  if (flag_pic)                                                              
   \
+    fprintf (FILE, "\tcall\t*mcount@GOT(%%ebx)\n");                        \
+  else                                                                  \
+    fprintf (FILE, "\tcall\tmcount\n");                                      
   \
+}
+
+#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
+#define WCHAR_TYPE "int"
+   
+#undef WCHAR_TYPE_SIZE
+#define WCHAR_TYPE_SIZE 32
+    
+#undef CPP_PREDEFINES
+#define CPP_PREDEFINES "-D__ELF__ -Dunix -Dlinux -Asystem(posix)"
+
+#undef CPP_SPEC
+#ifdef USE_GNULIBC_1
+#define CPP_SPEC "%(cpp_cpu) %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ 
-D__pic__} %{posix:-D_POSIX_SOURCE}"
+#else
+#define CPP_SPEC "%(cpp_cpu) %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ 
-D__pic__} %{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} 
%{!m32:-D__LONG_MAX__=9223372036854775807L}"
+#endif
+
+#undef CC1_SPEC
+#define CC1_SPEC "%(cc1_cpu) %{profile:-p}"
+
+/* Provide a LINK_SPEC appropriate for Linux.  Here we provide support
+   for the special GCC options -static and -shared, which allow us to
+   link things in one of these three modes by applying the appropriate
+   combinations of options at link-time. We like to support here for
+   as many of the other GNU linker options as possible. But I don't
+   have the time to search for those flags. I am sure how to add
+   support for -soname shared_object_name. H.J.
+
+   I took out %{v:%{!V:-V}}. It is too much :-(. They can use
+   -Wl,-V.
+
+   When the -shared link option is used a final link is not being
+   done.  */
+
+/* If ELF is the default format, we should not use /lib/elf. */
+
+#undef  LINK_SPEC
+#define LINK_SPEC "%{!m32:-m elf_x86_64} %{m32:-m elf_i386} 
%{shared:-shared} \
+  %{!shared: \
+    %{!ibcs: \
+      %{!static: \
+        %{rdynamic:-export-dynamic} \
+        %{!dynamic-linker:-dynamic-linker /lib/ld64.so.1}} \
+        %{static:-static}}}"
+
+#undef ASM_SPEC
+#define ASM_SPEC "%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} \
+ %{Wa,*:%*} %{m32:--32}"
+
+/* A C statement (sans semicolon) to output to the stdio stream
+   FILE the assembler definition of uninitialized global DECL named
+   NAME whose size is SIZE bytes and alignment is ALIGN bytes.
+   Try to use asm_output_aligned_bss to implement this macro.  */
+
+#define ASM_OUTPUT_ALIGNED_BSS(FILE, DECL, NAME, SIZE, ALIGN) \
+  asm_output_aligned_bss (FILE, DECL, NAME, SIZE, ALIGN)
+
+/* A C statement to output to the stdio stream FILE an assembler
+   command to advance the location counter to a multiple of 1<<LOG
+   bytes if it is within MAX_SKIP bytes.
+
+   This is used to align code labels according to Intel recommendations.  */
+
+#ifdef HAVE_GAS_MAX_SKIP_P2ALIGN
+#define ASM_OUTPUT_MAX_SKIP_ALIGN(FILE,LOG,MAX_SKIP)                    \
+  do {                                                                  \
+    if ((LOG) != 0) {                                                   \
+      if ((MAX_SKIP) == 0) fprintf ((FILE), "\t.p2align %d\n", (LOG));  \
+      else fprintf ((FILE), "\t.p2align %d,,%d\n", (LOG), (MAX_SKIP));  \
+    }                                                                   \
+  } while (0)
+#endif


-- 
     Bo Thorsen                 |   Praestevejen 4
     Free software developer    |   5290 Marslev
     SuSE Labs                  |   Denmark

Re: bogus .quad in i386/att.h

[Robert Lipe]

David> and it broke cygwin bootstrap 
David> http://gcc.gnu.org/ml/gcc-bugs/2001-10/msg00084.html

Good point.

Jan> I am not quite sure if it is cleaner to ifdef around each ASM_QUAD
Jan> use, or if we can just define ASM_QUAD to ".quad" everywhere...

Well, ".quad" is definitely not part of the standard AT&T assembler
syntax.   Elsewhere in the compiler, it already knows how to do this 
anyway.   Isn't that what UNALGINED_DOUBLE_INT_ASM_OP is about?   
Why invent something new here?

RJL


> 
> -----Original Message-----
> From: Robert Lipe [ mailto:robertlipe@usa.net ]
> Sent: Tuesday, 9 October 2001 11:38 
> To: gcc@gcc.gnu.org
> Cc: jh@suze.cz
> Subject: bogus .quad in i386/att.h
> 
> 
> Jan, your commit that starts: 
> 
> Tue Oct  2 12:46:01 CEST 2001  Bo Thorsen     <bo@suse.co.uk>,
>                                Andreas Jaeger <aj@suse.de>,
>                                Jan Hubicka    <jh@suse.cz>
> 
>         * doc/invoke.texi (i386 Options): Document x86-64 options.
>         (i386 and x86-64 Options): Rename i386 options section.
> 
> 
> added an entry for ASM_QUAD in att.h.   But the ChangeLog does not
> call out any change to att.h.
> 
> ..quad is definitely not something supported by the AT&T-derived
> assemblers.  Maybe it's a GAS thing and should be in gas.h.  Maybe it's
> an x86-64 thing and should be in x86-64.h.  But att.h sure seems like
> the wrong place for it.  This does show up as testsuite failures.
> 
> Can you please move this?
> 
> Thank you,
> RJL

RE: bogus .quad in i386/att.h

[Billinghurst, David (CRTS)]

and it broke cygwin bootstrap 
http://gcc.gnu.org/ml/gcc-bugs/2001-10/msg00084.html

-----Original Message-----
From: Robert Lipe [ mailto:robertlipe@usa.net ]
Sent: Tuesday, 9 October 2001 11:38 
To: gcc@gcc.gnu.org
Cc: jh@suze.cz
Subject: bogus .quad in i386/att.h


Jan, your commit that starts: 

Tue Oct  2 12:46:01 CEST 2001  Bo Thorsen     <bo@suse.co.uk>,
                               Andreas Jaeger <aj@suse.de>,
                               Jan Hubicka    <jh@suse.cz>

        * doc/invoke.texi (i386 Options): Document x86-64 options.
        (i386 and x86-64 Options): Rename i386 options section.


added an entry for ASM_QUAD in att.h.   But the ChangeLog does not
call out any change to att.h.

..quad is definitely not something supported by the AT&T-derived
assemblers.  Maybe it's a GAS thing and should be in gas.h.  Maybe it's
an x86-64 thing and should be in x86-64.h.  But att.h sure seems like
the wrong place for it.  This does show up as testsuite failures.

Can you please move this?

Thank you,
RJL