From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14688 invoked by alias); 20 Aug 2009 17:07:59 -0000 Received: (qmail 14677 invoked by uid 22791); 20 Aug 2009 17:07:58 -0000 X-SWARE-Spam-Status: No, hits=-0.2 required=5.0 tests=AWL,BAYES_00,DNS_FROM_RFC_BOGUSMX,FB_WORD1_END_DOLLAR X-Spam-Check-By: sourceware.org Received: from sebabeach.org (HELO sebabeach.org) (64.165.110.50) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 Aug 2009 17:07:49 +0000 Received: from sspiff.sspiff.org (seba.sebabeach.org [10.8.159.10]) by sebabeach.org (Postfix) with ESMTP id 3E7F06E3D0; Thu, 20 Aug 2009 10:07:47 -0700 (PDT) Message-ID: <4A8D82E2.3090805@sebabeach.org> Date: Thu, 20 Aug 2009 17:07:00 -0000 From: Doug Evans User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Dave Korn CC: cgen@sourceware.org Subject: Re: "make gas-test" broken? References: <4A6B1A40.1020405@gmail.com> <4A8AD9F7.30605@sebabeach.org> <4A8B77A1.8020501@gmail.com> In-Reply-To: <4A8B77A1.8020501@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org X-SW-Source: 2009-q3/txt/msg00061.txt.bz2 Dave Korn wrote: > Doug Evans wrote: > >> btw, here's how I'm testing gas-test. >> >> bash$ cd src/cgen >> bash$ guile >> guile> (load "dev.scm") >> guile> (load-gtest) >> guile> (cload #:arch "../cpu/m32r.cpu") ; replace with path to your cpu >> file of course >> guile> (cgen-build.sh) >> guile> (cgen-all-insn.exp) >> >> That should run without any errors. >> > > Hmm. Not for me it doesn't: cgen-build.sh give me: > > >> Backtrace: >> In ./gas-test.scm: >> 57: 0* [list-ref ((a0 0) (a1 1)) {3}] >> 57: 1* [car ... >> 57: 2* [->string ... >> 52: {3}* [string-append "" "" ... >> In unknown file: >> ?: 4* [# {3}] >> In ./gas-test.scm: >> 51: 5 [map # (0 {3} 2 1 1 1 2 0)] >> ... >> In ./cos.scm: >> 1106: 6 (if class-desc.meth (apply (cdr class-desc.meth) (cons # args)) ...) >> 1104: 7 (let* ((class-desc.meth #)) (if class-desc.meth (apply # #) ...)) >> In ./gas-test.scm: >> 132: 8 [send #(#("object" # h-accums ...) (# #f # ...)) test-data ...] >> In unknown file: >> ?: 9 [# #(#("object" # accs ...) (# #f # ...)) 8] >> In ./cos.scm: >> 1107: 10 [apply # (#(#("object" # accs ...) (# #f # ...) >> ) 8)] >> 1106: 11 (if class-desc.meth (apply (cdr class-desc.meth) (cons # args)) ...) >> 1104: 12 (let* ((class-desc.meth #)) (if class-desc.meth (apply # #) ...)) >> In ./gas-test.scm: >> 140: 13 [send #(#("object" # accs ...) (# #f # ...)) test-data ...] >> 172: 14* [operand-test-data #(#("object" # accs ...) (# #f # ...)) 8] >> In unknown file: >> ?: 15* [# #(#("object" # accs ...) (# #f # ...))] >> In ./gas-test.scm: >> 172: 16* [map # (#(# #) #(# #))] >> 172: 17 (let ((test-data #) (len #)) (cond (# #) (else #))) >> 204: 18* [build-test-set (#(# #) #(# #)) 8] >> 202: 19* (let* (# # #) (string-map # test-set)) >> 198: 20 [string-append "\x09.text >> " "\x09.global " ... ... >> 285: 21* [gen-gas-test #(#("object" # mvfachi-a "mvfachi-a" ...) (# #f # #f ... >> ))] >> In unknown file: >> ?: 22* [# #(#("object" # mvfachi-a ...) (# #f # ...))] >> ?: 23* [map # (#(# #) #(# #) #(# #) #(# #) ...)] >> ?: 24 [map] >> In ./utils.scm: >> 100: 25* [apply # (# (# # # # ...)) >> ] >> 100: 26 [apply # ... >> In ./gas-test.scm: >> 284: 27* [string-map # (#(# #) #(# #) #(# #) #(# #) ...)] >> 229: 28 [string-append "#/bin/sh >> # Generate test result data for " m32r ... ... >> In standard input: >> 4: 29* [cgen-build.sh] >> >> ./gas-test.scm:57:29: In procedure list-ref in expression (list-ref test-cases n >> ): >> ./gas-test.scm:57:29: Argument 2 out of range: 3 >> ABORT: (out-of-range) >> guile> >> Ya, that's the problem I was referring to in http://sourceware.org/ml/cgen/2009-q3/msg00056.html. I've changed method test-data of class to flag a warning and compensate. It's not ideal, technically wrong, but for right now I don't mind in this particular case. > > And my own target seems to fall at the first hurdle: > > >> Backtrace: >> In ./gas-test.scm: >> 229: 0 [string-append "#/bin/sh >> # Generate test result data for " ...] >> In standard input: >> 4: 1* [cgen-build.sh] >> >> ./gas-test.scm:229:3: In procedure string-append in expression (string-append "# >> /bin/sh >> # Generate test result data for " (current-arch-name) ...): >> ./gas-test.scm:229:3: Wrong type (expecting string): foobararch >> ABORT: (wrong-type-arg) >> guile> >> > > ... where 'foobararch' is the name attribute from my define-arch: > > >> (define-arch >> (name "foobararch") >> (comment "Example") >> (default-alignment aligned) >> (insn-lsb0? #t) >> (machs foobar24) >> (isas foobarisa) >> ) >> > > It doesn't make any difference whether or not I quote 'foobararch' in that > definition. > Ya, this is a change in Guile's behaviour (circa 1.4?). string-append use to accept symbols, it no longer does. Most of cgen has been updated, alas gas-test.scm wasn't - I've fixed it, give it another try. > What can I do next to find out why the m32r regeneration doesn't work for > me? I'm using Guile 1.8.2 (on Cygwin) and I updated cgen from CVS earlier > today; I have no significant local diffs, just this in Makefile.am/in: > > -ARCHFILE = $(srcroot)/cpu/$(ARCH).cpu > +ARCHFILE = $(word 1,$(wildcard $(srcroot)/cpu/$(ARCH).cpu > $(srcroot)/cgen/cpu/$(ARCH).cpu)) > > and this in mode.scm: > > (dfm 'HI "16 bit int" '() 'INT 16 2 "int" "'x'" #f #f #f) > + (dfm 'TQI "24 bit int" '() 'INT 24 3 "int" "'x'" #f #f #f) > (dfm 'SI "32 bit int" '() 'INT 32 4 "int" "'x'" #f #f #f) > (dfm 'DI "64 bit int" '(FN-SUPPORT) 'INT 64 8 "" "'D'" #f #f #f) > > @@ -517,6 +518,8 @@ Define a mode, all arguments specified. > 8 1 "unsigned int" "'x'" (mode:lookup 'QI) #f #f) > (dfm 'UHI "16 bit unsigned int" '() 'UINT > 16 2 "unsigned int" "'x'" (mode:lookup 'HI) #f #f) > + (dfm 'UTQI "24 bit unsigned int" '() 'UINT > + 24 3 "unsigned int" "'x'" (mode:lookup 'TQI) #f #f) > > ... neither of which I'd expect to cause this kind of problem. I guess I'll > try it on a linux vm tomorrow morning and see what happens there. > > cheers, > DaveK > >