Re: Ongoing bootstrap failures on ppc64 since 2007-07-02
On Fri, Jul 06, 2007 at 10:08:44AM -0700, Steve Kargl wrote: >On Fri, Jul 06, 2007 at 12:07:43PM -0400, Diego Novillo wrote: >Dorit has isolated the problem to the ISO C Binding import. See >for example > >http://gcc.gnu.org/ml/gcc/2007-07/msg00133.html > >AFAIK, ppc64 is the only target that is failing. I'll send you m68hc11 seems to also exhibit a problem around there, fwiw. Not sure if it is related. gcc.gnu.org/PR32262
Re: RFC: GIMPLE tuples. Design and implementation proposal
>2007/4/10, Diego Novillo <[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) >: >Following up on the recent discussion about GIMPLE tuples >(_http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html_ (http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html) ), we have summarized >our main ideas and implementation proposal in the attached document. > >This should be enough to get the implementation going, but there will be >many details that still need to be addressed. > >Thoughts/comments on the proposal? > >Thanks. I read your document _http://gcc.gnu.org/ml/gcc/2007-04/msg00290/tuples.pdf_ (http://gcc.gnu.org/ml/gcc/2007-04/msg00290/tuples.pdf) with great interest. This page _http://deputy.cs.berkeley.edu/_ (http://deputy.cs.berkeley.edu/) has a link to this document _http://hal.cs.berkeley.edu/cil/_ (http://hal.cs.berkeley.edu/cil/) which describes a means to obtain three-address code here _http://hal.cs.berkeley.edu/cil/ext.html#toc24_ (http://hal.cs.berkeley.edu/cil/ext.html#toc24) . If you ask nicely they would let you use CIL's code in GCC ;) . Rob
Re: Ongoing bootstrap failures on ppc64 since 2007-07-02
On Sat, Jul 07, 2007 at 12:45:59PM +0200, Bernhard Fischer wrote: > On Fri, Jul 06, 2007 at 10:08:44AM -0700, Steve Kargl wrote: > >On Fri, Jul 06, 2007 at 12:07:43PM -0400, Diego Novillo wrote: > > >Dorit has isolated the problem to the ISO C Binding import. See > >for example > > > >http://gcc.gnu.org/ml/gcc/2007-07/msg00133.html > > > >AFAIK, ppc64 is the only target that is failing. I'll send you > > m68hc11 seems to also exhibit a problem around there, fwiw. > Not sure if it is related. > gcc.gnu.org/PR32262 The ISO C binding patch, which has been implicated for the ppc64 problem, was committed on 2007-07-01. PR 32262 was filed on 2007-06-08. I doubt they are related. -- Steve
Re: Q: middle-end problem when variadic builtins promote float to double
On Fri, 6 Jul 2007, Joseph S. Myers wrote: > On Fri, 6 Jul 2007, Kaveh R. GHAZI wrote: > > > So how do we detect or work around this promotion issue and discriminate > > between the case where a float is promoted because of the variadic > > prototype vs a user supplied cast or other user code? > > I think we may need to tag these builtins in some way to indicate to the > front ends that arguments shouldn't be promoted. (With some other > builtins, such as __builtin_printf, the normal C promotion rules should be > applied.) Ok, how about e.g. __attribute__ ((__type_generic__)), which would only be allowed on variadic functions? In addition to the isnormal (etc) builtins, we probably want to mark "isless" and the other comparison builtins as well. Q: Do I have to worry about languages other than the C-family? Q: Do you recall where this promotion takes place? (You wrote the C-frontend, right? :-) ) Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
abs insn with QI and HI mode
Hi all, I have a problem with absm2 insn, my target machine can suppport abs operation with QImode, HImode and SImode. I give machine description in md file as below. (define_mode_macro SHQ [SI HI QI]) (define_insn "abs2" [(set (match_operand:SHQ 0 "register_operand" "=r") (abs:SHQ (match_operand:SHQ 1 "nonmemory_operand" "rM")))] "" "abs. out=%0, in=%1" [(set_attr "type" "mux") (set_attr "length" "1")]) When I compiled the c code as shown below: shirt int a, b; a=abs(b); note: a, b both globel variables The generated codes do the following operations: 1) extend variable a_HI (HImode) to temp variable SImode, and do abs operation with SImode operators. I find the gimple intermedia represention as shown below: D.1298 = a_HI[0]; D.1299 = (int) D.1298; D.1300 = ABS_EXPR ; D.1301 = (short int) D.1300; The unnecessary insns have been generated. It looks that ABS_EXPR only do SImode in the frontend. Could anyone know how to solve this problem? Thanks very much in advances Best regards Maggie
Re: Q: middle-end problem when variadic builtins promote float to double
On Sat, 7 Jul 2007, Kaveh R. GHAZI wrote: > Ok, how about e.g. __attribute__ ((__type_generic__)), which would only be > allowed on variadic functions? I don't think we want this available to user code, just to builtins, so a name such as "type generic" that can't be used as an identifier would be better (see "no vops" for an existing example). -- Joseph S. Myers [EMAIL PROTECTED]
Re: RFC: GIMPLE tuples. Design and implementation proposal
On 7/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >2007/4/10, Diego Novillo <[EMAIL PROTECTED] (mailto:[EMAIL PROTECTED]) >: >Following up on the recent discussion about GIMPLE tuples >(_http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html_ (http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html) ), we have summarized >our main ideas and implementation proposal in the attached document. > >This should be enough to get the implementation going, but there will be >many details that still need to be addressed. > >Thoughts/comments on the proposal? > >Thanks. I read your document _http://gcc.gnu.org/ml/gcc/2007-04/msg00290/tuples.pdf_ (http://gcc.gnu.org/ml/gcc/2007-04/msg00290/tuples.pdf) with great interest. This page _http://deputy.cs.berkeley.edu/_ (http://deputy.cs.berkeley.edu/) has a link to this document _http://hal.cs.berkeley.edu/cil/_ (http://hal.cs.berkeley.edu/cil/) which describes a means to obtain three-address code here _http://hal.cs.berkeley.edu/cil/ext.html#toc24_ (http://hal.cs.berkeley.edu/cil/ext.html#toc24) . If you ask nicely they would let you use CIL's code in GCC ;) . You know that CIL is written in OCAML, right?
gcc-4.3-20070707 is now available
Snapshot gcc-4.3-20070707 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070707/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 126448 You'll find: gcc-4.3-20070707.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070707.tar.bz2 C front end and core compiler gcc-ada-4.3-20070707.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070707.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070707.tar.bz2 C++ front end and runtime gcc-java-4.3-20070707.tar.bz2 Java front end and runtime gcc-objc-4.3-20070707.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070707.tar.bz2The GCC testsuite Diffs from 4.3-20070706 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: gcc-4.3-20070707 is now available
In case anyone wonders about this extra snapshot: both this week's, and last week's snapshot were broken in that a complete bootstrap failed even on i386, so I manually triggered another one. Gerald
Bootstrap failure on x86
Hi, My i686-pc-linux-gnu build fails with libtool: link: /exp/ldroot/dodes/i686-gcc-orig/gcc/gcj -B/exp/ldroot/dodes/i686-gcc-orig/i686-pc-linux-gnu/libjava/ -B/exp/ldroot/dodes/i686-gcc-orig/gcc/ -ffloat-store -fomit-frame-pointer -Usun -g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc -L/exp/ldroot/dodes/i686-gcc-orig/i686-pc-linux-gnu/libjava/.libs -L/exp/ldroot/dodes/i686-gcc-orig/i686-pc-linux-gnu/libjava ./.libs/libgcj.so -lpthread -lrt -ldl -Wl,-rpath -Wl,/usr/local/lib ./.libs/libgcj.so: undefined reference to `FFI_TYPE_DOUBLE' ./.libs/libgcj.so: undefined reference to `FFI_TYPE_SINT64' ./.libs/libgcj.so: undefined reference to `FFI_TYPE_LONGDOUBLE' ./.libs/libgcj.so: undefined reference to `FFI_TYPE_INT' ./.libs/libgcj.so: undefined reference to `FFI_TYPE_FLOAT' ... on revision 126435. Anyone else sees this failure? It looks cc1 -E -lang-asm outputs cmpl $FOO,%ecx instead of cmpl $3,%ecx for #define FOO 3 cmpl $FOO,%ecx Regards, kaz
Re: Q: middle-end problem when variadic builtins promote float to double
On Sat, 7 Jul 2007, Joseph S. Myers wrote: > On Sat, 7 Jul 2007, Kaveh R. GHAZI wrote: > > > Ok, how about e.g. __attribute__ ((__type_generic__)), which would only be > > allowed on variadic functions? > > I don't think we want this available to user code, just to builtins, so a > name such as "type generic" that can't be used as an identifier would be > better (see "no vops" for an existing example). Ok, here's a patch which adds the attribute named as you suggest and applies it to the relevant builtins. I'm stuck now on how and where we would intervene to honor it. I think we need to do it in c-decl.c: grokdeclarator(), where it says "promoted_type = c_type_promotes_to(type)" around line 4757. However I'm not sure if we have a handle on the function decl and it's attributes here to know when to do it. Some help would be appreciated. Thanks, --Kaveh diff -rup orig/egcc-SVN20070706/gcc/builtin-attrs.def egcc-SVN20070706/gcc/builtin-attrs.def --- orig/egcc-SVN20070706/gcc/builtin-attrs.def 2006-01-23 00:24:01.0 -0500 +++ egcc-SVN20070706/gcc/builtin-attrs.def 2007-07-07 17:25:40.785175001 -0400 @@ -94,6 +94,7 @@ DEF_ATTR_IDENT (ATTR_SCANF, "scanf") DEF_ATTR_IDENT (ATTR_SENTINEL, "sentinel") DEF_ATTR_IDENT (ATTR_STRFMON, "strfmon") DEF_ATTR_IDENT (ATTR_STRFTIME, "strftime") +DEF_ATTR_IDENT (ATTR_TYPEGENERIC, "type generic") DEF_ATTR_TREE_LIST (ATTR_NOVOPS_LIST, ATTR_NOVOPS, ATTR_NULL, ATTR_NULL) @@ -142,6 +143,9 @@ DEF_ATTR_TREE_LIST (ATTR_NOTHROW_NONNULL /* Nothrow const functions whose pointer parameter(s) are all nonnull. */ DEF_ATTR_TREE_LIST (ATTR_CONST_NOTHROW_NONNULL, ATTR_CONST, ATTR_NULL, \ ATTR_NOTHROW_NONNULL) +/* Nothrow const functions which are type-generic. */ +DEF_ATTR_TREE_LIST (ATTR_CONST_NOTHROW_TYPEGENERIC, ATTR_TYPEGENERIC, ATTR_NULL, \ + ATTR_CONST_NOTHROW_LIST) /* Nothrow pure functions whose pointer parameter(s) are all nonnull. */ DEF_ATTR_TREE_LIST (ATTR_PURE_NOTHROW_NONNULL, ATTR_PURE, ATTR_NULL, \ ATTR_NOTHROW_NONNULL) diff -rup orig/egcc-SVN20070706/gcc/builtins.def egcc-SVN20070706/gcc/builtins.def --- orig/egcc-SVN20070706/gcc/builtins.def 2007-05-17 23:03:49.0 -0400 +++ egcc-SVN20070706/gcc/builtins.def 2007-07-07 13:06:50.789804475 -0400 @@ -653,24 +653,24 @@ DEF_EXT_LIB_BUILTIN(BUILT_IN_FINITEL DEF_EXT_LIB_BUILTIN(BUILT_IN_FINITED32, "finited32", BT_FN_INT_DFLOAT32, ATTR_CONST_NOTHROW_LIST) DEF_EXT_LIB_BUILTIN(BUILT_IN_FINITED64, "finited64", BT_FN_INT_DFLOAT64, ATTR_CONST_NOTHROW_LIST) DEF_EXT_LIB_BUILTIN(BUILT_IN_FINITED128, "finited128", BT_FN_INT_DFLOAT128, ATTR_CONST_NOTHROW_LIST) -DEF_C99_C90RES_BUILTIN (BUILT_IN_ISINF, "isinf", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_LIST) +DEF_C99_C90RES_BUILTIN (BUILT_IN_ISINF, "isinf", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_TYPEGENERIC) DEF_EXT_LIB_BUILTIN(BUILT_IN_ISINFF, "isinff", BT_FN_INT_FLOAT, ATTR_CONST_NOTHROW_LIST) DEF_EXT_LIB_BUILTIN(BUILT_IN_ISINFL, "isinfl", BT_FN_INT_LONGDOUBLE, ATTR_CONST_NOTHROW_LIST) DEF_EXT_LIB_BUILTIN(BUILT_IN_ISINFD32, "isinfd32", BT_FN_INT_DFLOAT32, ATTR_CONST_NOTHROW_LIST) DEF_EXT_LIB_BUILTIN(BUILT_IN_ISINFD64, "isinfd64", BT_FN_INT_DFLOAT64, ATTR_CONST_NOTHROW_LIST) DEF_EXT_LIB_BUILTIN(BUILT_IN_ISINFD128, "isinfd128", BT_FN_INT_DFLOAT128, ATTR_CONST_NOTHROW_LIST) -DEF_C99_C90RES_BUILTIN (BUILT_IN_ISNAN, "isnan", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_LIST) +DEF_C99_C90RES_BUILTIN (BUILT_IN_ISNAN, "isnan", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_TYPEGENERIC) DEF_EXT_LIB_BUILTIN(BUILT_IN_ISNANF, "isnanf", BT_FN_INT_FLOAT, ATTR_CONST_NOTHROW_LIST) DEF_EXT_LIB_BUILTIN(BUILT_IN_ISNANL, "isnanl", BT_FN_INT_LONGDOUBLE, ATTR_CONST_NOTHROW_LIST) DEF_EXT_LIB_BUILTIN(BUILT_IN_ISNAND32, "isnand32", BT_FN_INT_DFLOAT32, ATTR_CONST_NOTHROW_LIST) DEF_EXT_LIB_BUILTIN(BUILT_IN_ISNAND64, "isnand64", BT_FN_INT_DFLOAT64, ATTR_CONST_NOTHROW_LIST) DEF_EXT_LIB_BUILTIN(BUILT_IN_ISNAND128, "isnand128", BT_FN_INT_DFLOAT128, ATTR_CONST_NOTHROW_LIST) -DEF_GCC_BUILTIN(BUILT_IN_ISGREATER, "isgreater", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_LIST) -DEF_GCC_BUILTIN(BUILT_IN_ISGREATEREQUAL, "isgreaterequal", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_LIST) -DEF_GCC_BUILTIN(BUILT_IN_ISLESS, "isless", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_LIST) -DEF_GCC_BUILTIN(BUILT_IN_ISLESSEQUAL, "islessequal", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_LIST) -DEF_GCC_BUILTIN(BUILT_IN_ISLESSGREATER, "islessgreater", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_LIST) -DEF_GCC_BUILTIN(BUILT_IN_ISUNORDERED, "isunordered", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_LIST) +DEF_GCC_BUILTIN(BUILT_IN_ISGREATER, "isgreater", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_TYPEGENERIC) +DEF_GCC_BUILTIN(BUILT_IN_ISGREATEREQUAL, "isgreaterequal", BT_FN_INT_VAR, ATTR_CONST_NOTHROW_TYPEGENERIC) +DEF_GCC_BUILTIN(BUILT_I
Re: Bootstrap failure on x86
On 7/7/07, Kaz Kojima <[EMAIL PROTECTED]> wrote: Hi, My i686-pc-linux-gnu build fails with libtool: link: /exp/ldroot/dodes/i686-gcc-orig/gcc/gcj -B/exp/ldroot/dodes/i686-gcc-orig/i686-pc-linux-gnu/libjava/ -B/exp/ldroot/dodes/i686-gcc-orig/gcc/ -ffloat-store -fomit-frame-pointer -Usun -g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc -L/exp/ldroot/dodes/i686-gcc-orig/i686-pc-linux-gnu/libjava/.libs -L/exp/ldroot/dodes/i686-gcc-orig/i686-pc-linux-gnu/libjava ./.libs/libgcj.so -lpthread -lrt -ldl -Wl,-rpath -Wl,/usr/local/lib ./.libs/libgcj.so: undefined reference to `FFI_TYPE_DOUBLE' ./.libs/libgcj.so: undefined reference to `FFI_TYPE_SINT64' ./.libs/libgcj.so: undefined reference to `FFI_TYPE_LONGDOUBLE' ./.libs/libgcj.so: undefined reference to `FFI_TYPE_INT' ./.libs/libgcj.so: undefined reference to `FFI_TYPE_FLOAT' ... on revision 126435. Anyone else sees this failure? Well this is obviously caused by: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00617.html This is not the first time this has happened. --Pinski
Re: Q: middle-end problem when variadic builtins promote float to double
On Sat, 7 Jul 2007, Kaveh R. GHAZI wrote: > Ok, here's a patch which adds the attribute named as you suggest and > applies it to the relevant builtins. I'm stuck now on how and where we > would intervene to honor it. I think we need to do it in c-decl.c: > grokdeclarator(), where it says "promoted_type = c_type_promotes_to(type)" > around line 4757. However I'm not sure if we have a handle on the No, that's something else entirely (a "float" old-style parameter declaration corresponds to a "double" argument in a prototype). It's convert_arguments that handles converting to prototype types and default argument promotions for arguments not covered by a prototype (including those in the ... of a variadic function). else if (TREE_CODE (TREE_TYPE (val)) == REAL_TYPE && (TYPE_PRECISION (TREE_TYPE (val)) < TYPE_PRECISION (double_type_node)) && !DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (val /* Convert `float' to `double'. */ argarray[parmnum] = convert (double_type_node, val); -- Joseph S. Myers [EMAIL PROTECTED]
Re: Bootstrap failure on x86
"Andrew Pinski" <[EMAIL PROTECTED]> wrote: >> on revision 126435. Anyone else sees this failure? > > Well this is obviously caused by: > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00617.html > > This is not the first time this has happened. I've confirmed that x86 bootstraps again with reverting that patch and filed this issue as PR 32670. Thanks! Regards, kaz
Re: Q: middle-end problem when variadic builtins promote float to double
On Sat, 7 Jul 2007, Joseph S. Myers wrote:
> No, that's something else entirely (a "float" old-style parameter
> declaration corresponds to a "double" argument in a prototype). It's
> convert_arguments that handles converting to prototype types and default
> argument promotions for arguments not covered by a prototype (including
> those in the ... of a variadic function).
>
> else if (TREE_CODE (TREE_TYPE (val)) == REAL_TYPE
>&& (TYPE_PRECISION (TREE_TYPE (val))
>< TYPE_PRECISION (double_type_node))
>&& !DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (val
> /* Convert `float' to `double'. */
> argarray[parmnum] = convert (double_type_node, val);
Ah perfect, thanks. I'm thinking something like what's below. I'll move
it over to gcc-patches and add a ChangeLog if it passes testing.
Thanks for your help!
--Kaveh
diff -rup orig/egcc-SVN20070706/gcc/c-typeck.c egcc-SVN20070706/gcc/c-typeck.c
--- orig/egcc-SVN20070706/gcc/c-typeck.c2007-06-30 23:02:59.0
-0400
+++ egcc-SVN20070706/gcc/c-typeck.c 2007-07-07 21:26:33.982197838 -0400
@@ -2394,6 +2394,8 @@ convert_arguments (int nargs, tree *arga
{
tree typetail, valtail;
int parmnum;
+ const bool type_generic =
+!!lookup_attribute ("type generic", TYPE_ATTRIBUTES(TREE_TYPE (fundecl)));
tree selector;
/* Change pointer to function to the function itself for
@@ -2585,8 +2587,13 @@ convert_arguments (int nargs, tree *arga
&& (TYPE_PRECISION (TREE_TYPE (val))
< TYPE_PRECISION (double_type_node))
&& !DECIMAL_FLOAT_MODE_P (TYPE_MODE (TREE_TYPE (val
- /* Convert `float' to `double'. */
- argarray[parmnum] = convert (double_type_node, val);
+{
+ /* Convert `float' to `double'. */
+ if (type_generic)
+ argarray[parmnum] = val;
+ else
+ argarray[parmnum] = convert (double_type_node, val);
+ }
else if ((invalid_func_diag =
targetm.calls.invalid_arg_for_unprototyped_fn (typelist,
fundecl, val)))
{
