From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85467 invoked by alias); 13 Dec 2016 09:37:04 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 85442 invoked by uid 89); 13 Dec 2016 09:37:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=Georg-Johann, GeorgJohann, Lay, georg-johann X-HELO: mo4-p00-ob.smtp.rzone.de Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de) (81.169.146.161) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 13 Dec 2016 09:36:52 +0000 X-RZG-AUTH: :LXoWVUeid/7A29J/hMvvT3ol15ykJcYwR/bcHRirORRW3yMcVao= X-RZG-CLASS-ID: mo00 Received: from [192.168.0.123] (mail.hightec-rt.com [213.135.1.215]) by smtp.strato.de (RZmta 39.10 DYNA|AUTH) with ESMTPSA id t064e3sBD9ai4Av (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Tue, 13 Dec 2016 10:36:44 +0100 (CET) Subject: Ping #1: [patch,testsuite,avr]: Filter-out -mmcu= from options for tests that set -mmcu= To: Mike Stump References: Cc: gcc-patches , Denis Chertykov , Senthil Kumar Selvaraj , Pitchumani Sivanupandi From: Georg-Johann Lay Message-ID: <5ca8d3f1-3b6d-4784-7128-98a51430079e@gjlay.de> Date: Tue, 13 Dec 2016 09:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg01120.txt.bz2 Ping #1 As I explained below, the solution taken be arm (pruning output) does not work here. Johann On 02.12.2016 11:21, Georg-Johann Lay wrote: > On 01.12.2016 17:40, Mike Stump wrote: >> On Dec 1, 2016, at 3:54 AM, Georg-Johann Lay wrote: >>> >>> This patch moves the compile tests that have a hard coded -mmcu=MCU >>> in their dg-options to a new folder. >>> >>> The exp driver filters out -mmcu= from the command line options that >>> are provided by, say, board description files or --tool-opts. >>> >>> This is needed because otherwise conflicting -mmcu= will FAIL >>> respective test cases because of "specified option '-mmcu' more than >>> once" errors from avr-gcc. >>> >>> Ok for trunk? >> >> So, it would be nice if different ports can use roughly similar >> schemes to handle the same problems. I think arm is one of the more >> complex ports at this point in this regard with a lot of people and a >> lot of years time to contemplate and implement solutions to the >> problem. They in particular don't have to move test cases around to >> handle the difference like this, I think it would be best to avoid >> that requirement if possible. >> >> Glancing around, two starting points for how the arm achieves what it >> does: >> >> lappend dg_runtest_extra_prunes "warning: switch -m(cpu|arch)=.* >> conflicts with -m(cpu|arch)=.* switch" >> >> in arm.exp, and they use something like: >> >> /* { dg-require-effective-target arm_crypto_ok } >> */ >> |crypto-vsha256hq_u32.c:2:/* { dg-require-effective-target >> arm_crypto_ok } */ >> /* { dg-add-options arm_crypto } >> */ >> |crypto-vsha256su0q_u32.c:2:/* { dg-require-effective-target >> arm_crypto_ok } */ >> >> to validate the requirements of the test case, and to ensure that >> optional things are selected. Nice, simple, extensible, handles >> multilibs, dejagnu arguments and different cpu defaults as I recall. >> >> You won't need all the hair the arm folks have, but if you stub in >> support in that direction, you then have simple, easy expansion room >> to match all complexities that the arm folks have already hit and >> solved. > > I tried this approach, but it does not work as expected. > > Notice that avr-gcc throws an error if conflicting -mmcu options are > supplied. Pruning the output will make some tests "PASS", but the > compiler didn't actually do anything but producing an error message... > > And one test FAILs because it should produce some specific diagnostic, > but again the compiler just throws a different error, the output is > pruned and the expected message is missing, hence fail. > > Also one test case is for ATmega8, but you won't run the whole test > suite against ATmega8 because that device is too restricted to give > reasonable results... Hence for some tests -mmcu=atmega8 is added by hand. > > Johann > > > > >