* New port for TILEPro and TILE-Gx
@ 2011-10-15 10:49 Walter Lee
2011-10-15 10:51 ` [PATCH] New port for TILEPro and TILE-Gx 2/7: changes in contrib Walter Lee
` (7 more replies)
0 siblings, 8 replies; 23+ messages in thread
From: Walter Lee @ 2011-10-15 10:49 UTC (permalink / raw)
To: gcc-patches
On behalf of Tilera Corporation, I'd like to contribute gcc ports to two of its
families of architectures, the TILEPro architecture and the TILE-Gx
architecture. TILEPro is a VLIW architecture with 32-bit registers, 32-bit
address space, and 64-bit instructions. TILE-Gx is a VLIW architecture with
64-bit registers, 64-bit address space, and 64-bit instructions. Both
architectures have load-store architecture ISAs.
The linux kernels for both architectures are actively supported on kernel.org.
Ports of binutils for both architectures have been approved for inclusion in
2.22. We also have ports for libffi, glibc, and gdb that we plan to contribute
back.
More information on the architectures is available at
http://www.tilera.com/scm/docs/index.html.
I've run the gcc testsuites natively on both architectures, and can post such
results on gcc-testresults. I've also verified that both targets compile
successfully with contrib/config-list.mk.
Tilera has completed the copyright assignment forms from FSF for gcc.
I would be the maintainer for both ports.
I'll be submitting the port in seven parts shortly:
1/7 toplevel changes
2/7 changes in contrib
3/7 gcc port
4/7 libcpp port
5/7 libgcc port
6/7 libgomp port
7/7 wwwdocs changes
Please let me know if I'm missing anything.
Thanks,
Walter Lee
^ permalink raw reply [flat|nested] 23+ messages in thread* [PATCH] New port for TILEPro and TILE-Gx 2/7: changes in contrib 2011-10-15 10:49 New port for TILEPro and TILE-Gx Walter Lee @ 2011-10-15 10:51 ` Walter Lee 2011-10-20 17:11 ` Walter Lee 2011-10-15 10:51 ` [PATCH] New port for TILEPro and TILE-Gx 1/7: toplevel changes Walter Lee ` (6 subsequent siblings) 7 siblings, 1 reply; 23+ messages in thread From: Walter Lee @ 2011-10-15 10:51 UTC (permalink / raw) To: gcc-patches [-- Attachment #1: Type: text/plain, Size: 102 bytes --] Here are the contrib changes. * config-list.mk (tilegx-linux-gnu): Add. (tilepro-linux-gnu): Add. [-- Attachment #2: contrib.diff --] [-- Type: text/plain, Size: 897 bytes --] diff -r -u -p -N /home/packages/gcc-4.7.0-179959/contrib/config-list.mk ./contrib/config-list.mk --- /home/packages/gcc-4.7.0-179959/contrib/config-list.mk 2011-10-14 01:08:51.000000000 -0400 +++ ./contrib/config-list.mk 2011-10-14 18:14:11.064775000 -0400 @@ -59,7 +59,8 @@ LIST = alpha-linux-gnu alpha-freebsd6 al sparc-leon3-linux-gnuOPT-enable-target=all sparc-netbsdelf \ sparc64-sun-solaris2.10OPT-with-gnu-ldOPT-with-gnu-asOPT-enable-threads=posix \ sparc-wrs-vxworks sparc64-elf sparc64-rtems sparc64-linux sparc64-freebsd6 \ - sparc64-netbsd sparc64-openbsd spu-elf v850e-elf v850-elf vax-linux-gnu \ + sparc64-netbsd sparc64-openbsd spu-elf tilegx-linux-gnu tilepro-linux-gnu \ + v850e-elf v850-elf vax-linux-gnu \ vax-netbsdelf vax-openbsd x86_64-apple-darwin \ x86_64-pc-linux-gnuOPT-with-fpmath=avx \ x86_64-elfOPT-with-fpmath=sse x86_64-freebsd6 x86_64-netbsd \ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] New port for TILEPro and TILE-Gx 2/7: changes in contrib 2011-10-15 10:51 ` [PATCH] New port for TILEPro and TILE-Gx 2/7: changes in contrib Walter Lee @ 2011-10-20 17:11 ` Walter Lee 0 siblings, 0 replies; 23+ messages in thread From: Walter Lee @ 2011-10-20 17:11 UTC (permalink / raw) To: gcc-patches [-- Attachment #1: Type: text/plain, Size: 308 bytes --] Here is a resubmission of the contrib patch, adding the entries to gcc_update to handle the multiply tables. * config-list.mk (tilegx-linux-gnu): Add. (tilepro-linux-gnu): Add. * gcc_update (gcc/config/tilegx/mul-tables.c): New dependencies. (gcc/config/tilepro/mul-tables.c): New dependencies. [-- Attachment #2: contrib.diff --] [-- Type: text/plain, Size: 1802 bytes --] diff -r -u -p -N /home/packages/gcc-4.7.0-180241/contrib/config-list.mk ./contrib/config-list.mk --- /home/packages/gcc-4.7.0-180241/contrib/config-list.mk 2011-10-14 01:08:51.000000000 -0400 +++ ./contrib/config-list.mk 2011-10-20 10:23:51.331484000 -0400 @@ -59,7 +59,8 @@ LIST = alpha-linux-gnu alpha-freebsd6 al sparc-leon3-linux-gnuOPT-enable-target=all sparc-netbsdelf \ sparc64-sun-solaris2.10OPT-with-gnu-ldOPT-with-gnu-asOPT-enable-threads=posix \ sparc-wrs-vxworks sparc64-elf sparc64-rtems sparc64-linux sparc64-freebsd6 \ - sparc64-netbsd sparc64-openbsd spu-elf v850e-elf v850-elf vax-linux-gnu \ + sparc64-netbsd sparc64-openbsd spu-elf tilegx-linux-gnu tilepro-linux-gnu \ + v850e-elf v850-elf vax-linux-gnu \ vax-netbsdelf vax-openbsd x86_64-apple-darwin \ x86_64-pc-linux-gnuOPT-with-fpmath=avx \ x86_64-elfOPT-with-fpmath=sse x86_64-freebsd6 x86_64-netbsd \ diff -r -u -p -N /home/packages/gcc-4.7.0-180241/contrib/gcc_update ./contrib/gcc_update --- /home/packages/gcc-4.7.0-180241/contrib/gcc_update 2011-10-14 01:08:51.000000000 -0400 +++ ./contrib/gcc_update 2011-10-20 10:23:51.337478000 -0400 @@ -88,6 +88,8 @@ gcc/config/c6x/c6x-mult.md: gcc/config/c gcc/config/m68k/m68k-tables.opt: gcc/config/m68k/m68k-devices.def gcc/config/m68k/m68k-isas.def gcc/config/m68k/m68k-microarchs.def gcc/config/m68k/genopt.sh gcc/config/mips/mips-tables.opt: gcc/config/mips/mips-cpus.def gcc/config/mips/genopt.sh gcc/config/rs6000/rs6000-tables.opt: gcc/config/rs6000/rs6000-cpus.def gcc/config/rs6000/genopt.sh +gcc/config/tilegx/mul-tables.c: gcc/config/tilepro/gen-mul-tables.cc +gcc/config/tilepro/mul-tables.c: gcc/config/tilepro/gen-mul-tables.cc # And then, language-specific files gcc/cp/cfns.h: gcc/cp/cfns.gperf gcc/java/keyword.h: gcc/java/keyword.gperf ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH] New port for TILEPro and TILE-Gx 1/7: toplevel changes 2011-10-15 10:49 New port for TILEPro and TILE-Gx Walter Lee 2011-10-15 10:51 ` [PATCH] New port for TILEPro and TILE-Gx 2/7: changes in contrib Walter Lee @ 2011-10-15 10:51 ` Walter Lee 2011-10-15 11:09 ` [PATCH] New port for TILEPro and TILE-Gx 3/7: gcc port Walter Lee ` (5 subsequent siblings) 7 siblings, 0 replies; 23+ messages in thread From: Walter Lee @ 2011-10-15 10:51 UTC (permalink / raw) To: gcc-patches [-- Attachment #1: Type: text/plain, Size: 100 bytes --] Here are the toplevel changes. * MAINTAINERS (tilegx port): Add self. (tilepro port): Add self. [-- Attachment #2: TOP.diff --] [-- Type: text/plain, Size: 641 bytes --] diff -r -u -p -N /home/packages/gcc-4.7.0-179959/MAINTAINERS ./MAINTAINERS --- /home/packages/gcc-4.7.0-179959/MAINTAINERS 2011-10-14 01:12:54.000000000 -0400 +++ ./MAINTAINERS 2011-10-14 18:14:11.075846000 -0400 @@ -102,6 +102,8 @@ sparc port Eric Botcazou ebotcazou@lib spu port Trevor Smigiel trevor_smigiel@playstation.sony.com spu port David Edelsohn dje.gcc@gmail.com spu port Ulrich Weigand uweigand@de.ibm.com +tilegx port Walter Lee walt@tilera.com +tilepro port Walter Lee walt@tilera.com v850 port Nick Clifton nickc@redhat.com vax port Matt Thomas matt@3am-software.com x86-64 port Jan Hubicka jh@suse.cz ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH] New port for TILEPro and TILE-Gx 3/7: gcc port 2011-10-15 10:49 New port for TILEPro and TILE-Gx Walter Lee 2011-10-15 10:51 ` [PATCH] New port for TILEPro and TILE-Gx 2/7: changes in contrib Walter Lee 2011-10-15 10:51 ` [PATCH] New port for TILEPro and TILE-Gx 1/7: toplevel changes Walter Lee @ 2011-10-15 11:09 ` Walter Lee 2011-10-15 18:33 ` Joseph S. Myers 2011-10-15 11:36 ` [PATCH] New port for TILEPro and TILE-Gx 4/7: libcpp port Walter Lee ` (4 subsequent siblings) 7 siblings, 1 reply; 23+ messages in thread From: Walter Lee @ 2011-10-15 11:09 UTC (permalink / raw) To: gcc-patches [-- Attachment #1: Type: text/plain, Size: 2276 bytes --] Here is the gcc port. * config.gcc: Handle tilegx and tilepro. * configure.ac (gcc_cv_as_dwarf2_debug_line): Enable test for tilegx and tilepro. Add HAVE_AS_TLS check for tilegx and tilepro. * configure: Regenerate. * doc/contrib.texi: Add Mat Hostetter and self. * doc/extend.texi (TILE-Gx Built-in Functions): New node. Document instruction intrinsics and network accessing intrinsics. (TILEPro Built-in Functions): New node. Document instruction intrinsics and network accessing intrinsics. * doc/install.texi (Specific, tilegx-*-linux*): Document it. (Specific, tilepro-*-linux*): Likewise. * doc/invoke.texi (TILE-Gx Options): New section. (TILEPro Options): New section. * doc/md.texi (TILE-Gx): New section. (TILEPro): New section. * common/config/tilegx/tilegx-common.c: New file. * common/config/tilepro/tilepro-common.c: New file. * config/tilegx/constraints.md: New file. * config/tilegx/linux.h: New file. * config/tilegx/mul_tables.c: New file. * config/tilegx/predicates.md: New file. * config/tilegx/sync.md: New file. * config/tilegx/t-tilegx: New file. * config/tilegx/tilegx-builtins.h: New file. * config/tilegx/tilegx-c.c: New file. * config/tilegx/tilegx-generic.md: New file. * config/tilegx/tilegx-modes.def: New file. * config/tilegx/tilegx-multiply.h: New file. * config/tilegx/tilegx-protos.h: New file. * config/tilegx/tilegx.c: New file. * config/tilegx/tilegx.h: New file. * config/tilegx/tilegx.md: New file. * config/tilegx/tilegx.opt: New file. * config/tilepro/constraints.md: New file. * config/tilepro/linux.h: New file. * config/tilepro/mul_tables.c: New file. * config/tilepro/predicates.md: New file. * config/tilepro/t-tilepro: New file. * config/tilepro/tilepro-builtins.h: New file. * config/tilepro/tilepro-c.c: New file. * config/tilepro/tilepro-generic.md: New file. * config/tilepro/tilepro-modes.def: New file. * config/tilepro/tilepro-multiply.h: New file. * config/tilepro/tilepro-protos.h: New file. * config/tilepro/tilepro.c: New file. * config/tilepro/tilepro.h: New file. * config/tilepro/tilepro.md: New file. * config/tilepro/tilepro.opt: New file. Here is a change to a test to handle the new targets. * testsuite/gcc.dg/20020312-2.c: Add a condition for __tile__. [-- Attachment #2: gcc.diff.gz --] [-- Type: application/x-gzip, Size: 231637 bytes --] [-- Attachment #3: gcc_testsuite.diff --] [-- Type: text/plain, Size: 545 bytes --] diff -r -u -p -N /home/packages/gcc-4.7.0-179959/gcc/testsuite/gcc.dg/20020312-2.c ./gcc/testsuite/gcc.dg/20020312-2.c --- /home/packages/gcc-4.7.0-179959/gcc/testsuite/gcc.dg/20020312-2.c 2011-10-14 00:57:27.000000000 -0400 +++ ./gcc/testsuite/gcc.dg/20020312-2.c 2011-10-14 18:14:11.138743000 -0400 @@ -64,6 +64,8 @@ extern void abort (void); # define PIC_REG "12" #elif defined(__sparc__) # define PIC_REG "l7" +#elif defined(__tile__) +# define PIC_REG "r51" #elif defined(__TMS320C6X__) # define PIC_REG "B14" #elif defined(__v850) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] New port for TILEPro and TILE-Gx 3/7: gcc port 2011-10-15 11:09 ` [PATCH] New port for TILEPro and TILE-Gx 3/7: gcc port Walter Lee @ 2011-10-15 18:33 ` Joseph S. Myers 2011-10-20 16:40 ` Walter Lee 0 siblings, 1 reply; 23+ messages in thread From: Joseph S. Myers @ 2011-10-15 18:33 UTC (permalink / raw) To: Walter Lee; +Cc: gcc-patches All comments here refer to the first instance of an issue; many issues are shared between the two ports but are only mentioned once here. On Sat, 15 Oct 2011, Walter Lee wrote: > +#undef SYSROOT_SUFFIX_SPEC > +#define SYSROOT_SUFFIX_SPEC "%{mbme:/usr/lib/bme;mnewlib:/usr/lib/newlib}" > + > +#undef SYSROOT_HEADERS_SUFFIX_SPEC > +#define SYSROOT_HEADERS_SUFFIX_SPEC SYSROOT_SUFFIX_SPEC These specs seem rather unusual. Typically such specs would be generated depending on what multilibs were being built (see t-sysroot-suffix), and since a subdirectory sysroot itself contains directories such as usr/lib and usr/include, you would not expect a /usr/lib path within those specs. It appears from the documentation that these are options for alternative C libraries. There is an existing infrastructure for options for alternative C libraries used with the Linux kernel, with the -mbionic, -mglibc and -muclibc options all of which use Negative so that only the last one is considered for specs processing, all of which set a single variable and which affect the predefined macros, settings of TARGET_C99_FUNCTIONS and TARGET_HAS_SINCOS, etc.; you should integrate these options properly with that infrastructure. But I don't see any sign of multilib settings to cause GCC's libraries to be built for these variants - although libstdc++, for example, definitely depends on libc in various ways, so you certainly can't expect to be able to use a different libc without having a separate multilib for it. (I am presuming that these are for libraries used in userspace with the Linux kernel or as part of building the Linux kernel; if they aren't used with Linux at all then a separate -elf or -eabi target would be the normal approach.) > +#undef ASM_SPEC > +#define ASM_SPEC "%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} \ > + %{Wa,*:%*} %{m32:--32} %{m64:--64}" All of this apart from %{m32:--32} %{m64:--64} is obsolete. See a series of my patches that cleaned up obsolete pieces in specs. <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00189.html> for -Wa,; <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00192.html> for -n and -T; <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00195.html> for -v; <http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00893.html> for -Yd,; <http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00913.html> for -Ym,; <http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00914.html> for -Qn and -Qy. > + %{!dynamic-linker:-dynamic-linker \ %{!dynamic-linker:...} doesn't do what you think and is also obsolete; again see my patches (<http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00194.html> in this case). > +#undef STARTFILE_SPEC > +#define STARTFILE_SPEC "\ > + %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}} \ > + crti.o%s \ > + %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s} \ > + %{ffeedback-emit*:crtfbi.o%s}" There are no -ffeedback-emit* or -ffeedback-generate options in FSF GCC so there should be no specs referencing them. Without that, this looks identical to GNU_USER_TARGET_STARTFILE_SPEC in gnu-user.h so you shouldn't need to override that at all (but if you just need to add to it, then appeand to GNU_USER_TARGET_STARTFILE_SPEC rather than replicating its contents). > +#undef LIB_SPEC > +#define LIB_SPEC \ > + "%{ffeedback-generate*|ffeedback-emit*:-lgcov -linstr} \ > + %{pthread:-lpthread} \ > + %{shared:-lc} \ > + %{!shared:%{mieee-fp:-lieee} %{profile:-lc_p}%{!profile:-lc}}" You don't have a -mieee-fp option in your .opt file, so shouldn't have a spec for it. > +#undef MCOUNT_NAME > +#define MCOUNT_NAME "mcount" For a new target it seems much better to define your ABI to use a name in the reserved namespace for this - that is, starting with two underscores. > +/* For __clear_cache in libgcc2.c. */ > +#ifdef IN_LIBGCC2 > + > +#include <arch/icache.h> Where does this header come from? Linux kernel, glibc, somewhere else? In general you want to condition header includes on inhibit_libc to facilitate bootstrapping (including building a partial static libgcc) before the libc headers are installed, since configuring glibc to install its headers requires a working compiler to run configure tests. > diff -r -u -p -N /home/packages/gcc-4.7.0-179959/gcc/config/tilegx/mul_tables.c ./gcc/config/tilegx/mul_tables.c > --- /home/packages/gcc-4.7.0-179959/gcc/config/tilegx/mul_tables.c 1969-12-31 19:00:00.000000000 -0500 > +++ ./gcc/config/tilegx/mul_tables.c 2011-10-14 18:14:11.524757000 -0400 > @@ -0,0 +1,19853 @@ Are you really sure that this 19853-line file is source code - "the preferred form of the work for making modifications to it"? How was it written? If it was generated by a program, and modifying that program would be the preferred way of changing this file, then the genuine source code for that program needs to be included as well. The genuine source code may not be used at build time - the ARM port has various code generated by O'Caml generators, for example - but at least it needs to be documented how someone, using the shipped source code and free software implementations of any relevant languages, can regenerate the generated file exactly. And if the generation is easy and doesn't require unusual tools, the rules for doing so should go in the makefiles (if for whatever reason a generated file still needs shipping in the source tree, also update contrib/gcc_update to avoid accidental regeneration). > +tilegx-c.o: $(srcdir)/config/tilegx/tilegx-c.c \ > + $(CONFIG_H) $(SYSTEM_H) coretypes.h $(MACHMODE_H) \ > + $(TM_H) $(TM_P_H) $(CPPLIB_H) $(TREE_H) $(C_COMMON_H) > + $(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \ > + $(srcdir)/config/tilegx/tilegx-c.c > + > +mul_tables.o: $(srcdir)/config/tilegx/mul_tables.c \ > + $(CONFIG_H) $(SYSTEM_H) coretypes.h $(EXPR_H) $(OPTABS_H) \ > + $(srcdir)/config/tilegx/tilegx-multiply.h > + $(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \ > + $(srcdir)/config/tilegx/mul_tables.c When the compiler is built as C++, all source of the compiler should normally also be built as C++. That is, you should use $(COMPILER), not $(CC). You should also verify that if you build the compiler using a current trunk compiler as your starting point, it passes a --enable-werror-always build as both C and C++; if you have only tested with cross compiler builds rather than native bootstrap, those don't use -Werror by default, hence the need to test with --enable-werror-always and to use a recent trunk compiler as the starting point. > +#ifndef _TILEGX_MULTIPLY_H > +#define _TILEGX_MULTIPLY_H Header include guards in host-side code like this should not be in the reserved namespace; use e.g. GCC_TILEGX_MULTIPLY_H instead. > +#ifndef __TILEGX_PROTOS_H__ > +#define __TILEGX_PROTOS_H__ Likewise. > +#include "errors.h" errors.h is the header for cut-down diagnostic functions used in generator programs. Normal compiler code should use diagnostic-core.h instead. > +/* Implement TARGET_OPTION_OVERRIDE. */ > +static void > +tilegx_option_override (void) > +{ > + static const struct cpu_table { > + const char *const name; > + const enum processor_type processor; > + } cpu_table[] = { > + { "tilegx", PROCESSOR_TILEGX }, > + { NULL, PROCESSOR_MAX } > + }; > + const char *cpu_string; > + int i; > + > + /* Default to TILE-GX. */ > + cpu_string = tilegx_cpu_string; > + if (cpu_string == NULL) > + cpu_string = "tilegx"; > + > + for (i = 0; cpu_table[i].name; i++) > + if (!strcmp (cpu_string, cpu_table[i].name)) > + { > + tilegx_cpu = cpu_table[i].processor; > + break; > + } > + > + if (!cpu_table[i].name) > + error ("bad value %s for -mcpu switch", cpu_string); Is there a reason all this needs to use this hook rather than the generic .opt file Enum facility for options with enumerated arguments? > +/* Return the simd variant of the constant NUM of mode MODE, by > + replicating it to fill an interger of mode DImode. NUM is first > + truncated to fit in MODE. */ > +rtx > +tilegx_simd_int (rtx num, enum machine_mode mode) > +{ > + HOST_WIDE_INT n = 0; > + > + if (CONST_INT_P (num)) > + { > + n = INTVAL (num); > + } > + else > + { > + error ("Immediate operand to SIMD op not a constant."); > + } Error messages should not start with a capital letter or end with '.'. Is this a message about a bad argument to a built-in function, or something like that? If not (if no input should ever generate it), then I'd think it should be an internal error, not a normal one. But if it does come from built-in expansion then this point is probably too late to get a good diagnostic location; ideally you'd use error_at with a location derived from the relevant expression, and generate errors early enough for that to be possible. > + if (!(*insn_op->predicate) (op[opnum], insn_op->mode)) > + { > + /* We still failed to meet the predicate even after moving > + into a register. Assume we needed an immediate. */ > + error ("operand must be an immediate of the right size"); Here's another case where explicit locations would be better. You may at least be able to check EXPR_HAS_LOCATION (exp) and use the expression's location if so. > + output_operand_lossage ("Invalid operand for 'r' specifier."); Again, diagnostics should not start with an uppercase letter or end with a period. > +@smallexample > + > +unsigned long long __insn_op (...) > + > +@end smallexample > + > +Where ``op'' is the name of the instruction. Refer to the ISA manual > +for the complete list of instructions. Should use @var{op} in both the example and in the main text in place of ``op''. > +tilegx-*-linux*) > + tm_file="elfos.h gnu-user.h linux.h glibc-stdint.h tilegx/linux.h ${tm_file}" > + tmake_file="${tmake_file} tilegx/t-tilegx" > + extra_headers="tilegx-builtins.h tilegx-multiply.h" > + extra_objs="mul_tables.o" > + c_target_objs="tilegx-c.o" > + cxx_target_objs="tilegx-c.o" > + ;; > +tilepro-*-linux*) > + tm_file="elfos.h gnu-user.h linux.h glibc-stdint.h tilepro/linux.h ${tm_file}" > + tmake_file="${tmake_file} tilepro/t-tilepro" > + extra_headers="tilepro-builtins.h tilepro-multiply.h" extra_headers is for headers for the *target*, that should be installed with the compiler and should have the runtime library license exception, not for headers that are part of the compiler on the *host*. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] New port for TILEPro and TILE-Gx 3/7: gcc port 2011-10-15 18:33 ` Joseph S. Myers @ 2011-10-20 16:40 ` Walter Lee 2011-10-20 20:55 ` Joseph S. Myers 0 siblings, 1 reply; 23+ messages in thread From: Walter Lee @ 2011-10-20 16:40 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc-patches [-- Attachment #1: Type: text/plain, Size: 5075 bytes --] Hi Joseph, Thanks for the feedback. I am attaching a gcc patch that addresses most of the comments. Here are replies to a few of the comments: > > +#undef SYSROOT_SUFFIX_SPEC > > +#define SYSROOT_SUFFIX_SPEC "%{mbme:/usr/lib/bme;mnewlib:/usr/lib/newlib}" > > + > > +#undef SYSROOT_HEADERS_SUFFIX_SPEC > > +#define SYSROOT_HEADERS_SUFFIX_SPEC SYSROOT_SUFFIX_SPEC > > These specs seem rather unusual. Typically such specs would be generated > depending on what multilibs were being built (see t-sysroot-suffix), and > since a subdirectory sysroot itself contains directories such as usr/lib > and usr/include, you would not expect a /usr/lib path within those specs. I've reverted the SYSROOT changes to support -mbme and -mnewlib for now. > > +#undef MCOUNT_NAME > > +#define MCOUNT_NAME "mcount" > > For a new target it seems much better to define your ABI to use a name in > the reserved namespace for this - that is, starting with two underscores. I've changed it to use "_mcount" with one underscore. That seems to be what glibc support by default, and it's consistent with x86, and we'd prefer to be consistent with x86 whenever possible. > > +/* For __clear_cache in libgcc2.c. */ > > +#ifdef IN_LIBGCC2 > > + > > +#include <arch/icache.h> > > Where does this header come from? Linux kernel, glibc, somewhere else? > In general you want to condition header includes on inhibit_libc to > facilitate bootstrapping (including building a partial static libgcc) > before the libc headers are installed, since configuring glibc to install > its headers requires a working compiler to run configure tests. We plan to include this as part of the Linux kernel, as the kernel itself depends on it. > > diff -r -u -p -N /home/packages/gcc-4.7.0-179959/gcc/config/tilegx/mul_tables.c ./gcc/config/tilegx/mul_tables.c > > --- /home/packages/gcc-4.7.0-179959/gcc/config/tilegx/mul_tables.c 1969-12-31 19:00:00.000000000 -0500 > > +++ ./gcc/config/tilegx/mul_tables.c 2011-10-14 18:14:11.524757000 -0400 > > @@ -0,0 +1,19853 @@ > > Are you really sure that this 19853-line file is source code - "the > preferred form of the work for making modifications to it"? How was it > written? I've included the source code from which the tables are generated, and I've updated the makefiles with rules to generate the tables. The script takes a minute to run, so I'd prefer not to generate it for every build, so I've kept the generated taables as part of the patch and updated the gcc_update script accordingly. > You should also verify that if you build the compiler using a current > trunk compiler as your starting point, it passes a > --enable-werror-always build as both C and C++ I've verified this condition using the config-list.mk script. Thanks, Walter * config.gcc: Handle tilegx and tilepro. * configure.ac (gcc_cv_as_dwarf2_debug_line): Enable test for tilegx and tilepro. Add HAVE_AS_TLS check for tilegx and tilepro. * configure: Regenerate. * doc/contrib.texi: Add Mat Hostetter and self. * doc/extend.texi (TILE-Gx Built-in Functions): New node. Document instruction intrinsics and network accessing intrinsics. (TILEPro Built-in Functions): New node. Document instruction intrinsics and network accessing intrinsics. * doc/install.texi (Specific, tilegx-*-linux*): Document it. (Specific, tilepro-*-linux*): Likewise. * doc/invoke.texi (TILE-Gx Options): New section. (TILEPro Options): New section. * doc/md.texi (TILE-Gx): New section. (TILEPro): New section. * common/config/tilegx/tilegx-common.c: New file. * common/config/tilepro/tilepro-common.c: New file. * config/tilegx/constraints.md: New file. * config/tilegx/linux.h: New file. * config/tilegx/mul-tables.c: New file. * config/tilegx/predicates.md: New file. * config/tilegx/sync.md: New file. * config/tilegx/t-tilegx: New file. * config/tilegx/tilegx-builtins.h: New file. * config/tilegx/tilegx-c.c: New file. * config/tilegx/tilegx-generic.md: New file. * config/tilegx/tilegx-modes.def: New file. * config/tilegx/tilegx-multiply.h: New file. * config/tilegx/tilegx-protos.h: New file. * config/tilegx/tilegx.c: New file. * config/tilegx/tilegx.h: New file. * config/tilegx/tilegx.md: New file. * config/tilegx/tilegx.opt: New file. * config/tilepro/constraints.md: New file. * config/tilepro/gen-mul-tables.cc: New file. * config/tilepro/linux.h: New file. * config/tilepro/mul-tables.c: New file. * config/tilepro/predicates.md: New file. * config/tilepro/t-tilepro: New file. * config/tilepro/tilepro-builtins.h: New file. * config/tilepro/tilepro-c.c: New file. * config/tilepro/tilepro-generic.md: New file. * config/tilepro/tilepro-modes.def: New file. * config/tilepro/tilepro-multiply.h: New file. * config/tilepro/tilepro-protos.h: New file. * config/tilepro/tilepro.c: New file. * config/tilepro/tilepro.h: New file. * config/tilepro/tilepro.md: New file. * config/tilepro/tilepro.opt: New file. The gcc testsuite change is the same as before. * testsuite/gcc.dg/20020312-2.c: Add a condition for __tile__. [-- Attachment #2: gcc.diff.gz --] [-- Type: application/x-gzip, Size: 254624 bytes --] [-- Attachment #3: gcc_testsuite.diff --] [-- Type: text/plain, Size: 545 bytes --] diff -r -u -p -N /home/packages/gcc-4.7.0-180241/gcc/testsuite/gcc.dg/20020312-2.c ./gcc/testsuite/gcc.dg/20020312-2.c --- /home/packages/gcc-4.7.0-180241/gcc/testsuite/gcc.dg/20020312-2.c 2011-10-14 00:57:27.000000000 -0400 +++ ./gcc/testsuite/gcc.dg/20020312-2.c 2011-10-20 10:23:51.377473000 -0400 @@ -64,6 +64,8 @@ extern void abort (void); # define PIC_REG "12" #elif defined(__sparc__) # define PIC_REG "l7" +#elif defined(__tile__) +# define PIC_REG "r51" #elif defined(__TMS320C6X__) # define PIC_REG "B14" #elif defined(__v850) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] New port for TILEPro and TILE-Gx 3/7: gcc port 2011-10-20 16:40 ` Walter Lee @ 2011-10-20 20:55 ` Joseph S. Myers 2011-10-23 10:23 ` Walter Lee 0 siblings, 1 reply; 23+ messages in thread From: Joseph S. Myers @ 2011-10-20 20:55 UTC (permalink / raw) To: Walter Lee; +Cc: gcc-patches On Thu, 20 Oct 2011, Walter Lee wrote: > > > +#undef MCOUNT_NAME > > > +#define MCOUNT_NAME "mcount" > > > > For a new target it seems much better to define your ABI to use a name in > > the reserved namespace for this - that is, starting with two underscores. > > I've changed it to use "_mcount" with one underscore. That seems to be what > glibc support by default, and it's consistent with x86, and we'd prefer to be > consistent with x86 whenever possible. x86 also has a newer version __fentry__ with -mfentry. ARM has mcount and __gnu_mcount_nc. I don't think consistency with the old x86 _mcount is particularly desirable. > > > +/* For __clear_cache in libgcc2.c. */ > > > +#ifdef IN_LIBGCC2 > > > + > > > +#include <arch/icache.h> > > > > Where does this header come from? Linux kernel, glibc, somewhere else? > > In general you want to condition header includes on inhibit_libc to > > facilitate bootstrapping (including building a partial static libgcc) > > before the libc headers are installed, since configuring glibc to install > > its headers requires a working compiler to run configure tests. > > We plan to include this as part of the Linux kernel, as the kernel itself > depends on it. So "make headers_install" for your architectures will install this header under than name? -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] New port for TILEPro and TILE-Gx 3/7: gcc port 2011-10-20 20:55 ` Joseph S. Myers @ 2011-10-23 10:23 ` Walter Lee 0 siblings, 0 replies; 23+ messages in thread From: Walter Lee @ 2011-10-23 10:23 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc-patches [-- Attachment #1: Type: text/plain, Size: 2749 bytes --] On 10/20/2011 4:07 PM, Joseph S. Myers wrote: > x86 also has a newer version __fentry__ with -mfentry. ARM has mcount and > __gnu_mcount_nc. I don't think consistency with the old x86 _mcount is > particularly desirable. Ok attached is a new patch that uses "__mcount." >> We plan to include this as part of the Linux kernel, as the kernel itself >> depends on it. > > So "make headers_install" for your architectures will install this header > under than name? Yes. We've made that change in linux and will be pushing that change upstream shortly. Walter * config.gcc: Handle tilegx and tilepro. * configure.ac (gcc_cv_as_dwarf2_debug_line): Enable test for tilegx and tilepro. Add HAVE_AS_TLS check for tilegx and tilepro. * configure: Regenerate. * doc/contrib.texi: Add Mat Hostetter and self. * doc/extend.texi (TILE-Gx Built-in Functions): New node. Document instruction intrinsics and network accessing intrinsics. (TILEPro Built-in Functions): New node. Document instruction intrinsics and network accessing intrinsics. * doc/install.texi (Specific, tilegx-*-linux*): Document it. (Specific, tilepro-*-linux*): Likewise. * doc/invoke.texi (TILE-Gx Options): New section. (TILEPro Options): New section. * doc/md.texi (TILE-Gx): New section. (TILEPro): New section. * common/config/tilegx/tilegx-common.c: New file. * common/config/tilepro/tilepro-common.c: New file. * config/tilegx/constraints.md: New file. * config/tilegx/linux.h: New file. * config/tilegx/mul-tables.c: New file. * config/tilegx/predicates.md: New file. * config/tilegx/sync.md: New file. * config/tilegx/t-tilegx: New file. * config/tilegx/tilegx-builtins.h: New file. * config/tilegx/tilegx-c.c: New file. * config/tilegx/tilegx-generic.md: New file. * config/tilegx/tilegx-modes.def: New file. * config/tilegx/tilegx-multiply.h: New file. * config/tilegx/tilegx-protos.h: New file. * config/tilegx/tilegx.c: New file. * config/tilegx/tilegx.h: New file. * config/tilegx/tilegx.md: New file. * config/tilegx/tilegx.opt: New file. * config/tilepro/constraints.md: New file. * config/tilepro/gen-mul-tables.cc: New file. * config/tilepro/linux.h: New file. * config/tilepro/mul-tables.c: New file. * config/tilepro/predicates.md: New file. * config/tilepro/t-tilepro: New file. * config/tilepro/tilepro-builtins.h: New file. * config/tilepro/tilepro-c.c: New file. * config/tilepro/tilepro-generic.md: New file. * config/tilepro/tilepro-modes.def: New file. * config/tilepro/tilepro-multiply.h: New file. * config/tilepro/tilepro-protos.h: New file. * config/tilepro/tilepro.c: New file. * config/tilepro/tilepro.h: New file. * config/tilepro/tilepro.md: New file. * config/tilepro/tilepro.opt: New file. [-- Attachment #2: gcc.diff.gz --] [-- Type: application/x-gzip, Size: 254628 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH] New port for TILEPro and TILE-Gx 4/7: libcpp port 2011-10-15 10:49 New port for TILEPro and TILE-Gx Walter Lee ` (2 preceding siblings ...) 2011-10-15 11:09 ` [PATCH] New port for TILEPro and TILE-Gx 3/7: gcc port Walter Lee @ 2011-10-15 11:36 ` Walter Lee 2011-10-15 12:04 ` [PATCH] New port for TILEPro and TILE-Gx: 5/7 libgcc port Walter Lee ` (3 subsequent siblings) 7 siblings, 0 replies; 23+ messages in thread From: Walter Lee @ 2011-10-15 11:36 UTC (permalink / raw) To: gcc-patches [-- Attachment #1: Type: text/plain, Size: 114 bytes --] Here is the libcpp port. * configure.ac: Require 64-bit hwint for tilegx and tilepro. * configure: Regenerate. [-- Attachment #2: libcpp.diff --] [-- Type: text/plain, Size: 962 bytes --] diff -r -u -p -N /home/packages/gcc-4.7.0-179959/libcpp/configure ./libcpp/configure --- /home/packages/gcc-4.7.0-179959/libcpp/configure 2011-10-14 01:12:52.000000000 -0400 +++ ./libcpp/configure 2011-10-14 18:14:11.161721000 -0400 @@ -7320,7 +7320,8 @@ case $target in s390*-*-* | \ sparc*-*-* | \ spu-*-* | \ - sh[123456789lbe]*-*-* | sh-*-*) + sh[123456789lbe]*-*-* | sh-*-* | \ + tilegx-*-* | tilepro-*-* ) need_64bit_hwint=yes ;; *) need_64bit_hwint=no ;; diff -r -u -p -N /home/packages/gcc-4.7.0-179959/libcpp/configure.ac ./libcpp/configure.ac --- /home/packages/gcc-4.7.0-179959/libcpp/configure.ac 2011-10-14 01:12:52.000000000 -0400 +++ ./libcpp/configure.ac 2011-10-14 18:14:11.141771000 -0400 @@ -158,7 +158,8 @@ case $target in s390*-*-* | \ sparc*-*-* | \ spu-*-* | \ - sh[123456789lbe]*-*-* | sh-*-*) + sh[123456789lbe]*-*-* | sh-*-* | \ + tilegx-*-* | tilepro-*-* ) need_64bit_hwint=yes ;; *) need_64bit_hwint=no ;; ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH] New port for TILEPro and TILE-Gx: 5/7 libgcc port 2011-10-15 10:49 New port for TILEPro and TILE-Gx Walter Lee ` (3 preceding siblings ...) 2011-10-15 11:36 ` [PATCH] New port for TILEPro and TILE-Gx 4/7: libcpp port Walter Lee @ 2011-10-15 12:04 ` Walter Lee 2011-10-15 19:00 ` Joseph S. Myers 2011-10-15 13:31 ` [PATCH] New port for TILEPro and TILE-Gx: 6/7 libgomp port Walter Lee ` (2 subsequent siblings) 7 siblings, 1 reply; 23+ messages in thread From: Walter Lee @ 2011-10-15 12:04 UTC (permalink / raw) To: gcc-patches [-- Attachment #1: Type: text/plain, Size: 525 bytes --] Here is the libgcc port. * config.host: Handle tilegx and tilepro. * config/tilegx/t-tilegx: New file. * config/tilepro/atomic.c: New file. * config/tilepro/milieu.h: New file. * config/tilepro/softdivide.c: New file. * config/tilepro/softfloat.c: New file. * config/tilepro/softfloat.h: New file. * config/tilepro/softfloat_macros.h: New file. * config/tilepro/softfloat_specialize.h: New file. * config/tilepro/softmpy.S: New file. * config/tilepro/softtile.h: New file. * config/tilepro/t-tilepro: New file. [-- Attachment #2: libgcc.diff.gz --] [-- Type: application/x-gzip, Size: 26917 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] New port for TILEPro and TILE-Gx: 5/7 libgcc port 2011-10-15 12:04 ` [PATCH] New port for TILEPro and TILE-Gx: 5/7 libgcc port Walter Lee @ 2011-10-15 19:00 ` Joseph S. Myers 2011-10-20 17:29 ` Walter Lee 0 siblings, 1 reply; 23+ messages in thread From: Joseph S. Myers @ 2011-10-15 19:00 UTC (permalink / raw) To: Walter Lee; +Cc: gcc-patches On Sat, 15 Oct 2011, Walter Lee wrote: > +FPBIT_FUNCS := $(filter-out \ > + _addsub_sf _mul_sf _div_sf _negate_sf \ > + _eq_sf _ne_sf _le_sf _lt_sf _ge_sf _gt_sf \ > + _sf_to_di _sf_to_si _sf_to_udi _sf_do_usi \ > + _di_to_sf _si_to_sf _udi_to_sf _usi_to_sf, \ > + $(FPBIT_FUNCS)) > + > +DPBIT_FUNCS := $(filter-out \ > + _addsub_df _mul_df _div_df _negate_df \ > + _eq_df _ne_df _le_df _lt_df _ge_df _gt_df \ > + _df_to_di _df_to_si _df_to_udi _df_do_usi \ > + _di_to_df _si_to_df _udi_to_df _usi_to_df, \ > + $(DPBIT_FUNCS)) I'm not clear on quite why you are enabling fpbit at all if you then disable most of the functions from it. What functions do you actually still get from fpbit, how are they used and would it be better to have separate implementations of them? How does the implementation you have used compare in performance with (a) fpbit and (b) soft-fp? (If you have access to EEMBC, that's quite good as a benchmark of software floating-point performance; see the paper in the 2006 GCC Summit proceedings; other floating-point-heavy benchmarks could probably be used as well.) Since you have two architectures, one of which has both 32-bit and 64-bit variants, benchmarks should probably be given for all three cases. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] New port for TILEPro and TILE-Gx: 5/7 libgcc port 2011-10-15 19:00 ` Joseph S. Myers @ 2011-10-20 17:29 ` Walter Lee 2011-10-23 11:25 ` Walter Lee 0 siblings, 1 reply; 23+ messages in thread From: Walter Lee @ 2011-10-20 17:29 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc-patches [-- Attachment #1: Type: text/plain, Size: 674 bytes --] Here is a resubmission of the libgcc patch, using soft-fp as the floating point library. I plan to do the benchmarking between the implementations as suggested, but I'd like to decouple that from the initial submission. * config.host: Handle tilegx and tilepro. * config/tilegx/sfp-machine.h: New file. * config/tilegx/sfp-machine32.h: New file. * config/tilegx/sfp-machine64.h: New file. * config/tilegx/t-softfp: New file. * config/tilegx/t-tilegx: New file. * config/tilepro/atomic.c: New file. * config/tilepro/sfp-machine.h: New file. * config/tilepro/softdivide.c: New file. * config/tilepro/softmpy.S: New file. * config/tilepro/t-tilepro: New file. [-- Attachment #2: libgcc.diff.gz --] [-- Type: application/x-gzip, Size: 6338 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] New port for TILEPro and TILE-Gx: 5/7 libgcc port 2011-10-20 17:29 ` Walter Lee @ 2011-10-23 11:25 ` Walter Lee 0 siblings, 0 replies; 23+ messages in thread From: Walter Lee @ 2011-10-23 11:25 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc-patches [-- Attachment #1: Type: text/plain, Size: 623 bytes --] Here is a resubmission of the libgcc patch, removing the dependence on a header (arch/atomic.h) that's not installed by linux. Walter * config.host: Handle tilegx and tilepro. * config/tilegx/sfp-machine.h: New file. * config/tilegx/sfp-machine32.h: New file. * config/tilegx/sfp-machine64.h: New file. * config/tilegx/t-softfp: New file. * config/tilegx/t-tilegx: New file. * config/tilepro/atomic.c: New file. * config/tilepro/atomic.h: New file. * config/tilepro/sfp-machine.h: New file. * config/tilepro/softdivide.c: New file. * config/tilepro/softmpy.S: New file. * config/tilepro/t-tilepro: New file. [-- Attachment #2: libgcc.diff.gz --] [-- Type: application/x-gzip, Size: 11777 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH] New port for TILEPro and TILE-Gx: 6/7 libgomp port 2011-10-15 10:49 New port for TILEPro and TILE-Gx Walter Lee ` (4 preceding siblings ...) 2011-10-15 12:04 ` [PATCH] New port for TILEPro and TILE-Gx: 5/7 libgcc port Walter Lee @ 2011-10-15 13:31 ` Walter Lee 2011-10-15 14:25 ` [PATCH] New port for TILEPro and TILE-Gx: 7/7 wwwdocs changes Walter Lee 2011-10-30 17:14 ` [PING] New port for TILEPro and TILE-Gx Walter Lee 7 siblings, 0 replies; 23+ messages in thread From: Walter Lee @ 2011-10-15 13:31 UTC (permalink / raw) To: gcc-patches [-- Attachment #1: Type: text/plain, Size: 113 bytes --] Here is the libgomp port. * configure.tgt: Handle tilegx and tilepro. * config/linux/tile/futex.h: New file. [-- Attachment #2: libgomp.diff --] [-- Type: text/plain, Size: 3148 bytes --] diff -r -u -p -N /home/packages/gcc-4.7.0-179959/libgomp/config/linux/tile/futex.h ./libgomp/config/linux/tile/futex.h --- /home/packages/gcc-4.7.0-179959/libgomp/config/linux/tile/futex.h 1969-12-31 19:00:00.000000000 -0500 +++ ./libgomp/config/linux/tile/futex.h 2011-10-14 18:14:11.657740000 -0400 @@ -0,0 +1,73 @@ +/* Copyright (C) 2011 + Free Software Foundation, Inc. + Contributed by Walter Lee (walt@tilera.com) + + This file is part of the GNU OpenMP Library (libgomp). + + Libgomp 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 3, or (at your option) + any later version. + + Libgomp 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. + + Under Section 7 of GPL version 3, you are granted additional + permissions described in the GCC Runtime Library Exception, version + 3.1, as published by the Free Software Foundation. + + You should have received a copy of the GNU General Public License and + a copy of the GCC Runtime Library Exception along with this program; + see the files COPYING3 and COPYING.RUNTIME respectively. If not, see + <http://www.gnu.org/licenses/>. */ + +/* Provide target-specific access to the futex system call. */ + +#include <sys/syscall.h> +#include <linux/futex.h> + +static inline void +sys_futex0 (int *addr, int op, int val) +{ + long _sys_result; + long _clobber_r2, _clobber_r3, _clobber_r4, _clobber_r5, _clobber_r10; + int err; + + __asm__ __volatile__ ( + "swint1" + : "=R00" (_sys_result), "=R01" (err), "=R02" (_clobber_r2), + "=R03" (_clobber_r3), "=R04" (_clobber_r4), "=R05" (_clobber_r5), + "=R10" (_clobber_r10) + : "R10" (SYS_futex), "R00" (addr), "R01" (op), "R02" (val), + "R03" (0) + : "r6", "r7", + "r8", "r9", "r11", "r12", "r13", "r14", "r15", + "r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23", + "r24", "r25", "r26", "r27", "r28", "r29", "memory"); +} + +static inline void +futex_wait (int *addr, int val) +{ + sys_futex0 (addr, FUTEX_WAIT, val); +} + +static inline void +futex_wake (int *addr, int count) +{ + sys_futex0 (addr, FUTEX_WAKE, count); +} + +static inline void +cpu_relax (void) +{ + __asm volatile ("" : : : "memory"); +} + +static inline void +atomic_write_barrier (void) +{ + __sync_synchronize (); +} diff -r -u -p -N /home/packages/gcc-4.7.0-179959/libgomp/configure.tgt ./libgomp/configure.tgt --- /home/packages/gcc-4.7.0-179959/libgomp/configure.tgt 2011-10-14 00:46:46.000000000 -0400 +++ ./libgomp/configure.tgt 2011-10-14 18:14:11.167723000 -0400 @@ -51,6 +51,10 @@ if test $enable_linux_futex = yes; then config_path="linux/s390 linux posix" ;; + tile*-*-linux*) + config_path="linux/tile linux posix" + ;; + # Note that bare i386 is not included here. We need cmpxchg. i[456]86-*-linux*) config_path="linux/x86 linux posix" ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH] New port for TILEPro and TILE-Gx: 7/7 wwwdocs changes 2011-10-15 10:49 New port for TILEPro and TILE-Gx Walter Lee ` (5 preceding siblings ...) 2011-10-15 13:31 ` [PATCH] New port for TILEPro and TILE-Gx: 6/7 libgomp port Walter Lee @ 2011-10-15 14:25 ` Walter Lee 2011-10-16 18:51 ` Gerald Pfeifer 2011-10-30 17:14 ` [PING] New port for TILEPro and TILE-Gx Walter Lee 7 siblings, 1 reply; 23+ messages in thread From: Walter Lee @ 2011-10-15 14:25 UTC (permalink / raw) To: gcc-patches [-- Attachment #1: Type: text/plain, Size: 55 bytes --] Here are the wwwdocs changes, with the news date TBD. [-- Attachment #2: wwwdocs.diff --] [-- Type: text/plain, Size: 2063 bytes --] Index: backends.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v retrieving revision 1.41 diff -u -p -r1.41 backends.html --- backends.html 15 Jul 2011 09:48:14 -0000 1.41 +++ backends.html 15 Oct 2011 00:57:04 -0000 @@ -98,6 +98,8 @@ sh | Q CB qr da sparc | Q CB qr p da spu | ? Q *C p g bd stormy16 | ???L FIC D l p m a +tilegx | S Q C q p g bda e +tilepro | S F C p g bda e v850 | ?? FI cp gm d s vax | M? I cp a e xtensa | ? C p bd Index: index.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.814 diff -u -p -r1.814 index.html --- index.html 12 Oct 2011 04:48:22 -0000 1.814 +++ index.html 15 Oct 2011 00:57:04 -0000 @@ -53,6 +53,11 @@ mission statement</a>.</p> <dl class="news"> +<dt><span>TILE-Gx and TILEPro processor support</span> + <span class="date">[2011-??-??]</span></dt> +<dd>Ports for the TILE-Gx and TILEPro families of processors have been +contributed by Tilera.</dd> + <dt><span>OpenMP v3.1</span> <span class="date">[2011-08-02]</span></dt> <dd>An implementation of the <a Index: readings.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.215 diff -u -p -r1.215 readings.html --- readings.html 15 Jul 2011 09:48:15 -0000 1.215 +++ readings.html 15 Oct 2011 00:57:04 -0000 @@ -257,6 +257,16 @@ Intel®64 and IA-32 Architectures Sof <br />Acronym stands for: Scalable Processor ARChitecture </li> + <li>tilegx + <br />Manufacturer: Tilera + <br /><a href="http://www.tilera.com/scm/docs/index.html">Documentation</a> + </li> + + <li>tilepro + <br />Manufacturer: Tilera + <br /><a href="http://www.tilera.com/scm/docs/index.html">Documentation</a> + </li> + <li>v850 <br />Manufacturer: NEC </li> ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH] New port for TILEPro and TILE-Gx: 7/7 wwwdocs changes 2011-10-15 14:25 ` [PATCH] New port for TILEPro and TILE-Gx: 7/7 wwwdocs changes Walter Lee @ 2011-10-16 18:51 ` Gerald Pfeifer 0 siblings, 0 replies; 23+ messages in thread From: Gerald Pfeifer @ 2011-10-16 18:51 UTC (permalink / raw) To: Walter Lee; +Cc: gcc-patches [-- Attachment #1: Type: TEXT/PLAIN, Size: 164 bytes --] On Sat, 15 Oct 2011, Walter Lee wrote: > Here are the wwwdocs changes, with the news date TBD. This is approved (once the actual code has gone in). Thanks, Gerald [-- Attachment #2: Type: TEXT/PLAIN, Size: 2063 bytes --] Index: backends.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v retrieving revision 1.41 diff -u -p -r1.41 backends.html --- backends.html 15 Jul 2011 09:48:14 -0000 1.41 +++ backends.html 15 Oct 2011 00:57:04 -0000 @@ -98,6 +98,8 @@ sh | Q CB qr da sparc | Q CB qr p da spu | ? Q *C p g bd stormy16 | ???L FIC D l p m a +tilegx | S Q C q p g bda e +tilepro | S F C p g bda e v850 | ?? FI cp gm d s vax | M? I cp a e xtensa | ? C p bd Index: index.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.814 diff -u -p -r1.814 index.html --- index.html 12 Oct 2011 04:48:22 -0000 1.814 +++ index.html 15 Oct 2011 00:57:04 -0000 @@ -53,6 +53,11 @@ mission statement</a>.</p> <dl class="news"> +<dt><span>TILE-Gx and TILEPro processor support</span> + <span class="date">[2011-??-??]</span></dt> +<dd>Ports for the TILE-Gx and TILEPro families of processors have been +contributed by Tilera.</dd> + <dt><span>OpenMP v3.1</span> <span class="date">[2011-08-02]</span></dt> <dd>An implementation of the <a Index: readings.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.215 diff -u -p -r1.215 readings.html --- readings.html 15 Jul 2011 09:48:15 -0000 1.215 +++ readings.html 15 Oct 2011 00:57:04 -0000 @@ -257,6 +257,16 @@ Intel®64 and IA-32 Architectures Sof <br />Acronym stands for: Scalable Processor ARChitecture </li> + <li>tilegx + <br />Manufacturer: Tilera + <br /><a href="http://www.tilera.com/scm/docs/index.html">Documentation</a> + </li> + + <li>tilepro + <br />Manufacturer: Tilera + <br /><a href="http://www.tilera.com/scm/docs/index.html">Documentation</a> + </li> + <li>v850 <br />Manufacturer: NEC </li> ^ permalink raw reply [flat|nested] 23+ messages in thread
* [PING] New port for TILEPro and TILE-Gx 2011-10-15 10:49 New port for TILEPro and TILE-Gx Walter Lee ` (6 preceding siblings ...) 2011-10-15 14:25 ` [PATCH] New port for TILEPro and TILE-Gx: 7/7 wwwdocs changes Walter Lee @ 2011-10-30 17:14 ` Walter Lee 2011-11-07 17:03 ` [PING2] " Walter Lee 7 siblings, 1 reply; 23+ messages in thread From: Walter Lee @ 2011-10-30 17:14 UTC (permalink / raw) To: gcc-patches Ping? I believe I have addressed all the reviewer's (namely Joseph Myers') comments to date. Thanks, Walter Lee ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PING2] New port for TILEPro and TILE-Gx 2011-10-30 17:14 ` [PING] New port for TILEPro and TILE-Gx Walter Lee @ 2011-11-07 17:03 ` Walter Lee 2011-11-07 22:27 ` Richard Henderson 0 siblings, 1 reply; 23+ messages in thread From: Walter Lee @ 2011-11-07 17:03 UTC (permalink / raw) To: gcc-patches Seeking more feedback or status update. Thanks, Walter Lee On 10/30/2011 12:07 PM, Walter Lee wrote: > Ping? I believe I have addressed all the reviewer's (namely Joseph Myers') > comments to date. > > Thanks, > > Walter Lee ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PING2] New port for TILEPro and TILE-Gx 2011-11-07 17:03 ` [PING2] " Walter Lee @ 2011-11-07 22:27 ` Richard Henderson 2011-11-07 23:56 ` Walter Lee 0 siblings, 1 reply; 23+ messages in thread From: Richard Henderson @ 2011-11-07 22:27 UTC (permalink / raw) To: Walter Lee; +Cc: gcc-patches On 11/07/2011 08:59 AM, Walter Lee wrote: > Seeking more feedback or status update. > > Thanks, > > Walter Lee > > On 10/30/2011 12:07 PM, Walter Lee wrote: >> Ping? I believe I have addressed all the reviewer's (namely Joseph Myers') >> comments to date. I haven't seen a re-post since Joseph's review? If I've missed it, please give me urls into the gcc-patches archive. r~ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PING2] New port for TILEPro and TILE-Gx 2011-11-07 22:27 ` Richard Henderson @ 2011-11-07 23:56 ` Walter Lee 2011-11-08 19:47 ` [PING2] New port for TILEPro Richard Henderson 2011-11-08 21:30 ` [PING2] New port for ... TILE-Gx Richard Henderson 0 siblings, 2 replies; 23+ messages in thread From: Walter Lee @ 2011-11-07 23:56 UTC (permalink / raw) To: Richard Henderson; +Cc: gcc-patches On 11/7/2011 5:17 PM, Richard Henderson wrote: > I haven't seen a re-post since Joseph's review? > If I've missed it, please give me urls into the gcc-patches archive. contrib: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01881.html gcc: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01880.html http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02084.html libgcc: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01882.html http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02086.html Thanks, Walter Lee ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PING2] New port for TILEPro ... 2011-11-07 23:56 ` Walter Lee @ 2011-11-08 19:47 ` Richard Henderson 2011-11-08 21:30 ` [PING2] New port for ... TILE-Gx Richard Henderson 1 sibling, 0 replies; 23+ messages in thread From: Richard Henderson @ 2011-11-08 19:47 UTC (permalink / raw) To: Walter Lee; +Cc: gcc-patches On 11/07/2011 03:28 PM, Walter Lee wrote: > gcc: > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02084.html Well, I must say I'm a bit disappointed that the two ports are just dis-similar enough to not be merged. And failing that, I'd prefer to review them separately. Tilepro: > (UNSPEC_INSN_ADDB 1) > (UNSPEC_INSN_ADDBS_U 2) > (UNSPEC_INSN_ADDH 3) > (UNSPEC_INSN_ADDHS 4) > (UNSPEC_INSN_ADDIB 5) > (UNSPEC_INSN_ADDIH 6) All of these really ought to be re-written using proper rtl. For instance, > (define_insn "insn_addb" > [(set (match_operand:SI 0 "register_operand" "=r,r") > (unspec:SI [(match_operand:SI 1 "reg_or_0_operand" "%rO,rO") > (match_operand:SI 2 "reg_or_cint_operand" "N,rO")] > UNSPEC_INSN_ADDB))] > "" > "@ > addib\t%0, %r1, %j2 > addb\t%0, %r1, %r2" > [(set_attr "type" "X01,X01")]) ought to be (define_insn "addv4qi3" [(set (match_operand:V4QI 0 "register_operand" "=r,r") (plus:V4QI (match_operand:V4QI 1 "reg_or_0_operand" "%rO,rO") (match_operand:V4QI 2 "reg_or_cint_operand" "N,rO")))] ...) Similarly, addbs_u should be usaddv4qi3 using (us_plus:V4QI ...), addh should be (plus:V2HI ...), and so forth throughout most of the unspecs present in the file. As it is, you're making absolutely no use of the vectorizer. > (define_insn "*movqi_insn" > [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,r,r,m") > (match_operand:QI 1 "move_operand" "r,I,J,K,m,rO"))] > "(register_operand (operands[0], QImode) > || reg_or_0_operand (operands[1], QImode))" > "@ > move\t%0, %r1 > movei\t%0, %1 > moveli\t%0, %1 > auli\t%0, zero, %h1 Alternatives 1,2,3 are dead code -- there will never be a QImode constant in those ranges. Similarly for movhi_insn and alternative 3. > (define_insn_and_split "*movsi_big_immediate" > [(set (match_operand:SI 0 "register_operand" "=r") > (match_operand:SI 1 "immediate_operand" "i"))] > "! move_operand (operands[1], SImode)" > "#" > "&& 1" > [(const_int 0)] > { > tilepro_expand_set_const32 (operands[0], operands[1]); > DONE; > }) Why? Seems like the movsi expander would handle this. If you provide the pattern, it'll get used. Which will cause the rtl optimizers to undo this split any chance they get. > (define_expand "movdi" > [(set (match_operand:DI 0 "nonimmediate_operand" "") > (match_operand:DI 1 "general_operand" ""))] > "" > { > if (tilepro_expand_mov (DImode, operands)) > DONE; > }) > > (define_insn_and_split "*movdi_insn" > [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,m") > (match_operand:DI 1 "general_operand" "i,rO,rO"))] > "!MEM_P (operands[0]) || REG_P (operands[1])" > "#" > ; We need a temp reg for addr+4 for the store, so we can't do this late. > "!MEM_P (operands[0]) || can_create_pseudo_p()" > [(set (match_dup 2) (match_dup 3)) > (set (match_dup 4) (match_dup 5))] I strongly suggest that you drop this pattern and let the rtl optimizers split the multi-word move. > (define_insn "movstrictqi" > [(set (strict_low_part (match_operand:QI 0 "register_operand" "+r")) > (match_operand:QI 1 "reg_or_0_operand" "rO"))] > "" > "mm\t%r0, %r1, %r0, 0, 7" > [(set_attr "type" "X01")]) > > (define_insn "movstricthi" > [(set (strict_low_part (match_operand:HI 0 "register_operand" "+r")) > (match_operand:HI 1 "reg_or_0_operand" "rO"))] > "" > "mm\t%r0, %r1, %r0, 0, 15" > [(set_attr "type" "X01")]) Do you really get any advantage over a more canonical expansion of insv? Or, rather, an insv internal patterns such as (define_insn "*insv_0" [(set (zero_extract:SI (match_operand:SI 0 "register_operand" "+r") (const_int 2) (const_int 7)) (match_operand:SI 1 "register_operand" "r")))] "" "tblidxb0\t%0,%1 (define_insn "*insv_1" [(set (zero_extract:SI (match_operand:SI 0 "register_operand" "+r") (const_int 0) (match_operand:SI 1 "u5bit_cint_operand" "")) (match_operand:SI 2 "register_operand" "r")))] "" "mm\t%0,%0,%2,0,%1") (define_insn "*insv_2" [(set (zero_extract:SI (match_operand:SI 0 "register_operand" "+r") (match_operand:SI 1 "u5bit_cint_operand" "") (match_operand:SI 2 "u5bit_cint_operand" "")) (zero_extract:SI (match_operand:SI 3 "register_operand" "r") (match_dup 1) (match_dup 2)))] "" { operands[2] = GEN_INT (INTVAL (operands[1]) + INTVAL (operands[2])); return "mm\t%0,%0,%3,%1,%2"; }) You'll probably want to keep your existing "*mm" pattern, but these are things that the combine pass is likely to generate. > (define_insn_and_split "*addsi3_big_immediate" > [(set (match_operand:SI 0 "register_operand" "=r") > (plus:SI (match_operand:SI 1 "reg_or_0_operand" "%rO") > (match_operand:SI 2 "const_int_operand" "i")))] > "! add_operand (operands[2], SImode)" > "#" > "&& 1" > [(const_int 0)] > { > bool ok = tilepro_expand_addsi (operands[0], operands[1], operands[2]); > gcc_assert (ok); > DONE; > }) Similar question to movsi_big_immediate. > ;; Change a rotate right to a rotate left, since that's all we have. > (define_expand "rotrsi3" > [(set (match_operand:SI 0 "register_operand" "") > (rotate:SI (match_operand:SI 1 "reg_or_0_operand" "") > (match_operand:SI 2 "reg_or_u5bit_operand" "")))] > "" > " > if (CONST_INT_P (operands[2])) > { > operands[2] = GEN_INT ((-INTVAL (operands[2])) & 31); > } > else > { > /* No need to subtract from 32 since count taken mod 32 anyway. */ > rtx reg = gen_reg_rtx (SImode); > emit_insn (gen_negsi2 (reg, operands[2])); > operands[2] = reg; > } > ") optabs.c will do exactly this if the pattern is not present. Similarly for the DImode logicals (popcount, parity, etc). > (define_insn "*mnz_insn" > (define_insn "*mnz_insn_reverse" > (define_insn "*mz_insn" > (define_insn "*mz_insn_reverse" > (define_insn "mvnz_insn" > (define_insn "*mvnz_insn_reverse" All of these ought to be compressed into a single pattern. Otherwise reload won't get a chance to select the proper alternative all the time. (define_predicate "eqne_operator" (match_code "eq,ne")) (define_insn "*movcc" [(set (match_operand:SI 0 "register_operand" "=r, r, r, r") (if_then_else:SI (match_operator 4 "eqne_operator" [(match_operand:SI 1 "reg_or_0_operand" "rO,rO,rO,rO") (const_int 0)]) (match_operand:SI 2 "reg_or_0_operand" "rO, O,rO, 0") (match_operand:SI 3 "reg_or_0_operand" " O,rO, 0,rO")))] "" "@ m%c4 %0, %r1, %r2 m%C4 %0, %r1, %3 mv%c4 %0, %r1, %r2 mv%C4 %0, %r1, %r3 [(set_attr "type" "*,*,Y0,Y0")]) And print_operand handling %c as printing a condition (z, nz) and %C printing its inverse. > (define_insn "zero_extendqihi2" Should not be needed. > (define_insn "*lh" > (define_insn_and_split "*extendhisi2" These need to be combined in order for reload to do the right thing. Suppose some HImode variable is spilled to the stack. If you split the patterns, reload will perform a load then split to the two shifts. If you combine the patterns, reload will notice memory is an alternative and perform the LH right away. Similarly for extendqihi2. > ;; Divide stubs. These exist to work around a bug in expmed.c, which > ;; will not attempt to convert a divide by constant into a multiply > ;; unless there is a pattern for a divide of the same mode. If this is still present in mainline, please file a bug. > (define_insn "_return" > [(return) > (use (reg:SI 55))] > "reload_completed" > "jrp\tlr" > [(set_attr "type" "X1")]) Post merge, consider changing this to simple_return to enable shrink wrapping. This may also involve epilogue unwind fixups though. > (define_insn "add_small_got" > [(set (match_operand:SI 0 "register_operand" "=r") > (lo_sum:SI (match_operand:SI 1 "reg_or_0_operand" "rO") > (unspec:SI [(match_operand:SI 2 "symbolic_operand" "")] > UNSPEC_GOT_SYM)))] I strongly suggest that you wrap these unspecs in CONST, and handle them as appropriate in the previous HIGH/LO_SUM patterns, and in the print_operand cases. This goes for the TLS patterns as well. I'm surprised you don't support post_{inc,dec,modify} addressing modes, via the "add" set of memory instructions. Do they not really perform well on the architecture, or did the gcc version you started with not generate them well? I also don't see support for AND addresses, as for lw_na. And yet you seem to be using those addressing modes in tilepro_expand_unaligned_load. I can only assume these are failing validate_mem, and forcing the address into a register first? > tilepro_allocate_stack (rtx op0, rtx op1) Invalid rtl sharing in this function. > /* Mark all insns we just emitted as frame-related. */ > for (; last_insn != NULL_RTX; last_insn = next_insn (last_insn)) > RTX_FRAME_RELATED_P (last_insn) = 1; You can't do just this for the epilogue. You have to emit REG_CFA_RESTORE notes. I'd prefer to see all new ports use _only_ REG_CFA_* notes, and avoid REG_FRAME_RELATED_EXPR. I won't force this though. > /* We generate PC relative SYMBOL_REFs as an optimization, to avoid > going through the GOT when the symbol is local to the compilation > unit. But such a symbol requires that the common text_label that > we generate at the beginning of the function be in the same section > as the reference to the SYMBOL_REF. This may not be true if we > generate hot/cold sections. This function looks for such cases and > replaces such references with the longer sequence going through the GOT. Why not use gp-relative references? A small matter of extending the assembler with new relocations, perhaps. > fprintf (file, "\tlw r11, r10\n"); > fprintf (file, "\taddi r10, r10, 4\n"); > fprintf (file, "\tlw r10, r10\n"); I guess going back to the previous question, not lwadd r11, r10, 4 lw r10, r10 ? r~ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PING2] New port for ... TILE-Gx 2011-11-07 23:56 ` Walter Lee 2011-11-08 19:47 ` [PING2] New port for TILEPro Richard Henderson @ 2011-11-08 21:30 ` Richard Henderson 1 sibling, 0 replies; 23+ messages in thread From: Richard Henderson @ 2011-11-08 21:30 UTC (permalink / raw) To: Walter Lee; +Cc: gcc-patches On 11/07/2011 03:28 PM, Walter Lee wrote: > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02084.html TileGx: Almost all the same comments as for TilePro. I see that you've started some macroization of the port, but havn't completed it. E.g. sub<mode>3 vs addsi3+adddi3. > (define_expand "addsf3" Clever. I do wonder if it wouldn't be better to wait until after reload to split these though. > (define_insn "*and_0x00000000FFFFFFFF" > (define_insn "*and_0xFFFFFFFF00000000" These probably should be merged into the main AND pattern. But failing that, they're only applicable to DImode and needn't be macroized. > (define_expand "clzsi2" > [(set (match_dup 2) > (ashift:DI (match_operand:SI 1 "reg_or_0_operand" "") > (const_int 32))) > (set (subreg:DI (match_operand:SI 0 "register_operand" "") 0) > (clz:DI (match_dup 2)))] > "" Generic code can handle this. Likewise ctz, popcount, parity. > (define_insn "insn_cmpexch<four_if_si>" > (define_insn "insn_exch<four_if_si>" > (define_insn "insn_fetchadd<four_if_si>" > (define_insn "insn_fetchand<four_if_si>" > (define_insn "insn_fetchor<four_if_si>" Use the atomic_ names and interfaces. > #define LIBCALL_VALUE(MODE) gen_rtx_REG (MODE, 0) > #define FUNCTION_VALUE_REGNO_P(N) ((N) < TILEGX_NUM_RETURN_REGS) > #define FUNCTION_ARG_REGNO_P(N) ((N) < TILEGX_NUM_ARG_REGS) > #define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR) \ > #define GO_IF_MODE_DEPENDENT_ADDRESS(ADDR, LABEL) \ All of these are now target hooks. There may be more. > /* We represent all SI values as sign-extended DI values in > registers. */ > #define TRULY_NOOP_TRUNCATION(OUTPREC, INPREC) \ > ((INPREC) <= 32 || (OUTPREC) > 32) I think you should be *very* careful before you insist on this. Do you not have a memory mode that ignores the high bits for 32-bit pointers? From the description of "memoryReadWord", it does seem like you've got modes that pre-process input addresses. MIPS uses this because, techinically, the 32-bit operation insns produce undefined results when given inputs that are not sign-extended. I see no such restriction in the TileGx manual. At least in 64-bit pointer mode, I think you should drop this and make sure that you've got appropriate sign_extend patterns for all of the "x" insns. Similar to how x86_64 does for the zero_extend patterns. r~ ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2011-11-08 21:24 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-10-15 10:49 New port for TILEPro and TILE-Gx Walter Lee 2011-10-15 10:51 ` [PATCH] New port for TILEPro and TILE-Gx 2/7: changes in contrib Walter Lee 2011-10-20 17:11 ` Walter Lee 2011-10-15 10:51 ` [PATCH] New port for TILEPro and TILE-Gx 1/7: toplevel changes Walter Lee 2011-10-15 11:09 ` [PATCH] New port for TILEPro and TILE-Gx 3/7: gcc port Walter Lee 2011-10-15 18:33 ` Joseph S. Myers 2011-10-20 16:40 ` Walter Lee 2011-10-20 20:55 ` Joseph S. Myers 2011-10-23 10:23 ` Walter Lee 2011-10-15 11:36 ` [PATCH] New port for TILEPro and TILE-Gx 4/7: libcpp port Walter Lee 2011-10-15 12:04 ` [PATCH] New port for TILEPro and TILE-Gx: 5/7 libgcc port Walter Lee 2011-10-15 19:00 ` Joseph S. Myers 2011-10-20 17:29 ` Walter Lee 2011-10-23 11:25 ` Walter Lee 2011-10-15 13:31 ` [PATCH] New port for TILEPro and TILE-Gx: 6/7 libgomp port Walter Lee 2011-10-15 14:25 ` [PATCH] New port for TILEPro and TILE-Gx: 7/7 wwwdocs changes Walter Lee 2011-10-16 18:51 ` Gerald Pfeifer 2011-10-30 17:14 ` [PING] New port for TILEPro and TILE-Gx Walter Lee 2011-11-07 17:03 ` [PING2] " Walter Lee 2011-11-07 22:27 ` Richard Henderson 2011-11-07 23:56 ` Walter Lee 2011-11-08 19:47 ` [PING2] New port for TILEPro Richard Henderson 2011-11-08 21:30 ` [PING2] New port for ... TILE-Gx Richard Henderson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).