From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1895 invoked by alias); 3 Jun 2003 16:17:05 -0000 Mailing-List: contact overseers-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: , Sender: overseers-owner@sources.redhat.com Received: (qmail 1840 invoked by uid 0); 3 Jun 2003 16:17:04 -0000 Resent-Message-ID: <20030603161704.1839.qmail@sources.redhat.com> Received: (qmail 29751 invoked from network); 3 Jun 2003 16:15:15 -0000 Received: from unknown (HELO ns2.uk.superh.com) (193.128.105.170) by sources.redhat.com with SMTP; 3 Jun 2003 16:15:15 -0000 Received: from sh-uk-ex01.uk.w2k.superh.com (sh-uk-ex01 [192.168.16.17]) by ns2.uk.superh.com (8.11.6+Sun/8.11.6) with ESMTP id h53GCQb10927; Tue, 3 Jun 2003 17:12:26 +0100 (BST) Received: from superh.com ([192.168.16.50]) by sh-uk-ex01.uk.w2k.superh.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Jun 2003 17:15:29 +0100 Message-ID: <3EDCC989.2F21DDDA@superh.com> Date: Wed, 04 Jun 2003 04:30:00 -0000 From: Joern Rennecke Organization: SuperH UK Ltd. X-Accept-Language: en MIME-Version: 1.0 To: overseers@sources.redhat.com Subject: [Fwd: failure notice] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jun 2003 16:15:29.0748 (UTC) FILETIME=[59D1C940:01C329EB] Resent-From: root@sourceware.org Resent-Date: Tue, 3 Jun 2003 16:17:04 +0000 X-SW-Source: 2003-q2/txt/msg00221.txt.bz2 I keep getting failure messages for this specific mail which I sent to the gcc list some time ago. It appears that some list relay or news gateway tries to sumbit the message back to the list. -------- Original Message -------- Received: from sh-us-ex01.us.w2k.superh.com ([192.168.4.40]) by sh-uk-ex01.uk.w2k.superh.com with Microsoft SMTPSVC(5.0.2195.5329);Tue, 3 Jun 2003 16:29:29 +0100 Received: from smtp.superh.com ([65.219.1.204]) by sh-us-ex01.us.w2k.superh.com with Microsoft SMTPSVC(5.0.2195.5329);Tue, 3 Jun 2003 08:29:28 -0700 Received: from sources.redhat.com (sources.redhat.com [66.187.233.205])by smtp.superh.com (Switch-2.2.0/Switch-2.2.0) with SMTP id h53F9TD20949for ; Tue, 3 Jun 2003 08:09:29 -0700 (PDT) Message-Id: <200306031509.h53F9TD20949@smtp.superh.com> Received: (qmail 29824 invoked for bounce); 3 Jun 2003 15:28:44 -0000 Date: 3 Jun 2003 15:28:44 -0000 From: MAILER-DAEMON@sources.redhat.com To: joern.rennecke@superh.com Subject: failure notice Return-Path: <> X-OriginalArrivalTime: 03 Jun 2003 15:29:28.0217 (UTC) FILETIME=[EBD19890:01C329E4] Hi. This is the qmail-send program at sources.redhat.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : ezmlm-send: fatal: message already has a Mailing-List header (maybe I should be a sublist) (#5.7.2) --- Below this line is a copy of the message. Return-Path: Received: (qmail 28142 invoked from network); 3 Jun 2003 15:28:15 -0000 Received: from unknown (HELO mike.corpex.com) (195.167.169.39) by sources.redhat.com with SMTP; 3 Jun 2003 15:28:15 -0000 Received: from mike by mike.corpex.com with local (Exim 3.36 #1 (Debian)) id 19ND0I-0002QQ-00 for ; Tue, 03 Jun 2003 15:43:10 +0100 Received: (qmail 13588 invoked by uid 0); 27 May 2003 19:19:25 -0000 MBOX-Line: From gcc.gnu.org!gcc-return-74852-james=westongold.com Tue May 27 20:19:25 2003 remote from mail Received: from smtp-relay.corpex.com([195.167.168.36]) (7369 bytes) by mail.corpex.com via smail with P:esmtp/R:bind_hosts/T:smtp-filter (sender: ) id for ; Tue, 27 May 2003 19:29:42 +0100 (BST) (Smail-3.2.0.105 1999-Mar-3 #3 built 1999-Mar-26) Received: from qmail.corpex.net ([195.167.168.40]) by smtp-relay.corpex.com with smtp (Exim 3.35 #1 (Debian)) id 19Kj5W-0004PP-00 for ; Tue, 27 May 2003 19:22:18 +0100 Received: (qmail 53981 invoked by uid 1009); 22 May 2003 16:47:24 -0000 Delivered-To: james@westongold.com Received: (qmail 53971 invoked by uid 1009); 22 May 2003 16:47:24 -0000 Received: from sources.redhat.com (66.187.233.205) by delivery1.corpex.net with SMTP; 22 May 2003 16:47:24 -0000 Received: (qmail 5278 invoked by alias); 22 May 2003 16:45:06 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Delivered-To: mailing list gcc@gcc.gnu.org Received: (qmail 5011 invoked from network); 22 May 2003 16:44:58 -0000 Received: from unknown (HELO ns2.uk.superh.com) (193.128.105.170) by sources.redhat.com with SMTP; 22 May 2003 16:44:58 -0000 Received: from sh-uk-ex01.uk.w2k.superh.com (sh-uk-ex01 [192.168.16.17]) by ns2.uk.superh.com (8.11.6+Sun/8.11.6) with ESMTP id h4MGgjb05868 for ; Thu, 22 May 2003 17:42:47 +0100 (BST) Received: from superh.com ([192.168.16.50]) by sh-uk-ex01.uk.w2k.superh.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 May 2003 17:45:15 +0100 Message-ID: <3ECCFE86.D0C37D89@superh.com> Date: Thu, 22 May 2003 17:44:54 +0100 From: Joern Rennecke Organization: SuperH UK Ltd. X-Accept-Language: en MIME-Version: 1.0 To: gcc@gcc.gnu.org Subject: RFC: address operand predicates other than address_operand? Content-Type: multipart/mixed; boundary="------------93061F5FE477CE79FB375027" X-OriginalArrivalTime: 22 May 2003 16:45:15.0783 (UTC) FILETIME=[856C1970:01C32081] This is a multi-part message in MIME format. --------------93061F5FE477CE79FB375027 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think it would make sense to have predicates that already enforce some of the restrictions that an EXTRA_ADDRESS_CONSTRAINT places on address. So, we could either have a target macro that describes a list of address operand predicates, or one that recognizes address operand predicates, or have a convention for predicate names that are generally recognized as address operand predicates. Note that such a new target macro would not be in the way of run-time switching the target, as it is used to generate the recognizer, which is inherently target-specific, and would have to be switched anyway. OTOH, having a convention for predicate names seems simpler both in implementation and in making for more uniform target descriptions. We could just say that every predicate that contains the substring "address_opeerand" is an address_operand predicate. This is pretty easy to implement, as the attached patch shows. If there is agreement that this is the way to go, I'll write up a ChangeLog entry and documentation patch for it. -- -------------------------- SuperH (UK) Ltd. 2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX T:+44 1454 465658 --------------93061F5FE477CE79FB375027 Content-Type: text/plain; charset=us-ascii; name="address-operand-patch-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="address-operand-patch-2" Index: genrecog.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/genrecog.c,v retrieving revision 1.125 diff -p -r1.125 genrecog.c *** genrecog.c 17 May 2003 01:40:41 -0000 1.125 --- genrecog.c 22 May 2003 16:32:25 -0000 *************** validate_pattern (pattern, insn, set, se *** 623,629 **** && allows_non_const && ! special_mode_pred && pred_name[0] != '\0' ! && strcmp (pred_name, "address_operand") != 0 && strstr (c_test, "operands") == NULL && ! (set && GET_CODE (set) == SET --- 623,629 ---- && allows_non_const && ! special_mode_pred && pred_name[0] != '\0' ! && strstr (pred_name, "address_operand") == NULL && strstr (c_test, "operands") == NULL && ! (set && GET_CODE (set) == SET *************** validate_pattern (pattern, insn, set, se *** 667,673 **** /* The mode of an ADDRESS_OPERAND is the mode of the memory reference, not the mode of the address. */ if (GET_CODE (src) == MATCH_OPERAND ! && ! strcmp (XSTR (src, 1), "address_operand")) ; /* The operands of a SET must have the same mode unless one --- 667,673 ---- /* The mode of an ADDRESS_OPERAND is the mode of the memory reference, not the mode of the address. */ if (GET_CODE (src) == MATCH_OPERAND ! && strstr (XSTR (src, 1), "address_operand") == NULL) ; /* The operands of a SET must have the same mode unless one *************** add_to_sequence (pattern, last, position *** 868,876 **** If we know that the predicate does not allow CONST_INT, we know that the only way the predicate can match is if ! the modes match (here we use the kludge of relying on the ! fact that "address_operand" accepts CONST_INT; otherwise, ! it would have to be a special case), so we can test the mode (but we need not). This fact should considerably simplify the generated code. */ --- 868,876 ---- If we know that the predicate does not allow CONST_INT, we know that the only way the predicate can match is if ! the modes match (here we used to use the kludge of relying ! on "address_operand" accepting CONST_INT, but that is not ! true for all architectures), so we can test the mode (but we need not). This fact should considerably simplify the generated code. */ *************** add_to_sequence (pattern, last, position *** 900,906 **** } /* Can't enforce a mode if we allow const_int. */ ! if (allows_const_int) mode = VOIDmode; /* Accept the operand, ie. record it in `operands'. */ --- 900,908 ---- } /* Can't enforce a mode if we allow const_int. */ ! if (allows_const_int ! || (GET_CODE (pattern) == MATCH_OPERAND ! && strstr (XSTR (pattern, 1), "address_operand") != NULL)) mode = VOIDmode; /* Accept the operand, ie. record it in `operands'. */ *************** maybe_both_true_2 (d1, d2) *** 1111,1117 **** mode of the memory, not the operand. It can only be used for testing the predicate, so we must ignore it here. */ ! && strcmp (d1->u.pred.name, "address_operand") != 0) return 0; } /* Don't check two predicate modes here, because if both predicates --- 1113,1119 ---- mode of the memory, not the operand. It can only be used for testing the predicate, so we must ignore it here. */ ! && strstr (d1->u.pred.name, "address_operand") == NULL) return 0; } /* Don't check two predicate modes here, because if both predicates --------------93061F5FE477CE79FB375027--