From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28326 invoked by alias); 31 Jan 2015 11:17:15 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 28310 invoked by uid 89); 31 Jan 2015 11:17:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 X-HELO: out1134-243.mail.aliyun.com Received: from out1134-243.mail.aliyun.com (HELO out1134-243.mail.aliyun.com) (42.120.134.243) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 31 Jan 2015 11:17:08 +0000 X-Alimail-AntiSpam:AC=CONTINUE;BC=0.07442721|-1;FP=0|0|0|0|0|-1|-1|-1;HT=r41g03013;MF=gang.chen@sunrus.com.cn;PH=DS;RN=6;RT=6;SR=0; Received: from ShengShiZhuChengdeMacBook-Pro.local(mailfrom:gang.chen@sunrus.com.cn ip:223.72.65.73) by smtp.aliyun-inc.com(10.147.34.64); Sat, 31 Jan 2015 19:16:55 +0800 Message-ID: <54CCBB78.6020408@sunrus.com.cn> Date: Sat, 31 Jan 2015 11:17:00 -0000 From: Chen Gang S User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Mike Stump CC: Chris Metcalf , walt@tilera.com, Jeff Law , gcc-help , Michael Eager Subject: Re: [Consult] tile: How to construct testsuite for tile architecture without hardware. References: <54BA30F3.4080202@sunrus.com.cn> <54BD2C5E.1070804@ezchip.com> <54BDB71D.90703@sunrus.com.cn> <54C39ECA.3000603@sunrus.com.cn> <54CC0C79.1070007@sunrus.com.cn> <54CC6D9B.30106@sunrus.com.cn> In-Reply-To: <54CC6D9B.30106@sunrus.com.cn> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SW-Source: 2015-01/txt/msg00172.txt.bz2 On 1/31/15 13:52, Chen Gang S wrote: > On 1/31/15 07:00, Mike Stump wrote: >> On Jan 30, 2015, at 2:58 PM, Chen Gang S wrote: >>> After finish analyzing the related warnings for tile, for me, they are >>> neither tile's issues nor gcc common implementation issues: >> >> ? They all look like they can be fixed in the port. >> >> Why not use :P? From i386: >> >> ;; This mode iterator allows :P to be used for patterns that operate on >> ;; pointer-sized quantities. Exactly one of the two alternatives will match. >> (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) >> >> (define_insn "*tls_global_dynamic_64_" >> [(set (match_operand:P 0 "register_operand" "=a") >> (call:P >> (mem:QI (match_operand 2 "constant_call_address_operand" "Bz")) >> (match_operand 3))) >> (unspec:P [(match_operand 1 "tls_symbolic_operand")] >> UNSPEC_TLS_GD)] >> “TARGET_64BIT" >> > > OK, thanks I shall try, hope I can finish within today (this month). After try, it will report compiling error, the related information is below: Modification: diff --git a/gcc/config/tilegx/tilegx.md b/gcc/config/tilegx/tilegx.md index 7ece171..fb9c097 100644 --- a/gcc/config/tilegx/tilegx.md +++ b/gcc/config/tilegx/tilegx.md @@ -281,6 +281,8 @@ (define_mode_iterator FI48MODE [SF DF SI DI]) (define_mode_iterator VEC48MODE [V8QI V4HI]) (define_mode_iterator VEC248MODE [V8QI V4HI V2SI]) +(define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode") + (HI "Pmode == HImode") (QI "Pmode == QImode")]) (define_mode_attr n [(QI "1") (HI "2") (SI "4") (DI "") (V8QI "1") (V4HI "2") (V2SI "4")]) @@ -2625,7 +2627,7 @@ [(set_attr "type" "X1")]) (define_insn "indirect_jump" - [(set (pc) (match_operand 0 "pointer_operand" "rO"))] + [(set (pc) (match_operand:P 0 "pointer_operand" "rO"))] "" "jr\t%r0" [(set_attr "type" "Y1")]) The related error: g++ -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Ic -I../../gcc-tile-new/gcc -I../../gcc-tile-new/gcc/c -I../../gcc-tile-new/gcc/../include -I../../gcc-tile-new/gcc/../libcpp/include -I../../gcc-tile-new/gcc/../libdecnumber -I../../gcc-tile-new/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-tile-new/gcc/../libbacktrace -o c/c-lang.o -MT c/c-lang.o -MMD -MP -MF c/.deps/c-lang.TPo ../../gcc-tile-new/gcc/c/c-lang.c In file included from ./tm.h:30:0, from ../../gcc-tile-new/gcc/c/c-lang.c:24: ./insn-flags.h:114:0: warning: "HAVE_indirect_jump" redefined #define HAVE_indirect_jump (Pmode == DImode) ^ ./insn-flags.h:113:0: note: this is the location of the previous definition #define HAVE_indirect_jump (Pmode == SImode) ^ ./insn-flags.h:796:58: error: ‘rtx_def* gen_indirect_jump(rtx)’ was declared ‘extern’ and later ‘static’ [-fpermissive] static inline rtx gen_indirect_jump (rtx); ^ ./insn-flags.h:795:19: note: previous declaration of ‘rtx_def* gen_indirect_jump(rtx)’ extern rtx gen_indirect_jump (rtx); ^ ./insn-flags.h: In function ‘rtx_def* gen_indirect_jump(rtx)’: ./insn-flags.h:804:1: error: redefinition of ‘rtx_def* gen_indirect_jump(rtx)’ gen_indirect_jump(rtx ARG_UNUSED (a)) ^ ./insn-flags.h:798:1: note: ‘rtx_def* gen_indirect_jump(rtx)’ previously defined here gen_indirect_jump(rtx ARG_UNUSED (a)) ^ Do we need additional limitition/completement to follow with the related define_insn? And if we can really let pointer_operand has type, I guess, we also need remove the related tile code in "gcc/config/tilegx/tilegx.c" (original code assumed that pointer_operand is VOIDmode): 3604 /* pointer_operand and pmode_register_operand operands do 3605 not specify a mode, so use the operand's mode instead 3606 (which should always be right by the time we get here, 3607 except for constants, which are VOIDmode). */ 3608 if (opmode == VOIDmode) 3609 { 3610 machine_mode m = GET_MODE (op[opnum]); 3611 gcc_assert (m == Pmode || m == VOIDmode); 3612 opmode = Pmode; 3613 } Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed