From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id 53DB33858C55; Mon, 25 Apr 2022 20:35:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 53DB33858C55 Received: by mail-ed1-x529.google.com with SMTP id z99so19871807ede.5; Mon, 25 Apr 2022 13:35:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:references :message-id:mime-version:content-transfer-encoding; bh=gaJLe2aMV1qUyyYPg2xQZKu6487LSj0604OPSv7+Rf8=; b=UemSEEErgMqF0HAyXGYcIIP2QYkCwcZe1LKen1KrwZFwSq6NAhqjU2OBjURZDsCJEA Fj4zi3htieyfKze2ucxnGTTs/RhXkd+tSShi0R0vz6yyeVlP8eXcR5fWto6EYQK3I3iA TpZtbsuFmXir960UHfNpDVDJZs5bTF7E9Fb+vMTLyd0nWNJZAHkhAmfqdICMVOyK4HOu YMTYymeoGWaMVMyM6Gh7vQfl9qgUQzQzowTc9a03+XHcDsQbQoookQfCmq/qCNwXCJpz K8wggsBGUBHI8u8LI4wbIUWkgf6wpTxqreyQ6cEO4QjB6lYCJngWHjno4ZvYeBG/IVaz nEsA== X-Gm-Message-State: AOAM531B59oTOjqg9GxLNqZXXkkQ5KiNPQEVSWcN0IXQWa8lTk3iMtAH XTs/AAg46PND0R1fMAvSA7w= X-Google-Smtp-Source: ABdhPJyonyMnxU8z3u7Uc2bdUlYfQod+iwkBvyQqnuidJS4lZLpqFUu07HKmOo2wYYunDQJxu6DVZw== X-Received: by 2002:a05:6402:528c:b0:425:ab33:7b6b with SMTP id en12-20020a056402528c00b00425ab337b6bmr20914393edb.49.1650918950643; Mon, 25 Apr 2022 13:35:50 -0700 (PDT) Received: from ?IPv6:::1? ([2001:4bb8:10e:c639::18e0:677c]) by smtp.gmail.com with ESMTPSA id mf1-20020a170906cb8100b006f378365a5esm2710607ejb.116.2022.04.25.13.35.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Apr 2022 13:35:50 -0700 (PDT) Date: Mon, 25 Apr 2022 22:35:44 +0200 From: Bernhard Reutner-Fischer To: Jakub Jelinek , Jakub Jelinek via Fortran , Mikael Morin CC: gcc-patches , gfortran Subject: =?UTF-8?Q?Re=3A_=5Bpushed=5D_testsuite=3A=C2=A0add_additional_?= =?UTF-8?Q?option_to_force_DSE_execution_=5BPR103662=5D?= In-Reply-To: References: <8541b594-57c9-f6aa-7164-3918abe67a8f@orange.fr> <88c39110-ff0f-d06b-b331-133cb5213c67@gmx.de> <5d85fc5c-8e06-8568-43e5-6b9273f86a76@orange.fr> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2022 20:35:54 -0000 On 25 April 2022 14:12:30 CEST, Jakub Jelinek via Fortran wrote: >On Mon, Apr 25, 2022 at 01:38:25PM +0200, Mikael Morin wrote: >> I have just pushed the attached fix for two UNRESOLVED checks at -O0=C2= =A0that I >> hadn=E2=80=99t seen=2E > >I don't like forcing of DSE in -O0 compilation, wouldn't it be better >to just not check the dse dump at -O0 like in the following patch? As Mikael already said, that's preferable indeed=2E > >Even better would be to check that the z=2E_data =3D stores are both pres= ent >in *=2Eoptimized dump, but that doesn't really work at -O2 or above becau= se >we inline the functions and optimize it completely away (both the stores >and corresponding reads)=2E > >The first hunk is needed so that __OPTIMIZE__ effective target works in >Fortran testsuite, otherwise one gets a pedantic error and __OPTIMIZE__ >is considered not to match at all=2E > >2022-04-25 Jakub Jelinek > > PR fortran/103662 > * lib/target-supports=2Eexp (check_effective_target___OPTIMIZE__): Add > a var definition to avoid pedwarn about empty translation unit=2E > * gfortran=2Edg/unlimited_polymorphic_3=2Ef03: Remove -ftree-dse from > dg-additional-options, guard scan-tree-dump-not directives on > __OPTIMIZE__ target=2E > >--- gcc/testsuite/lib/target-supports=2Eexp=2Ejj 2022-04-22 13:36:56=2E15= 0960826 +0200 >+++ gcc/testsuite/lib/target-supports=2Eexp 2022-04-25 14:06:21=2E6205374= 83 +0200 >@@ -11770,6 +11770,7 @@ proc check_effective_target___OPTIMIZE__ > #ifndef __OPTIMIZE__ > # error nein Hmz=2E I _think_ that was /me and reading it again now, we should should n= ot bluntly say nein but more something like unwilling to ignore __OPTIMIZE__, dude or anything more descriptive and universally understandably I assume=2E > #endif >+ int optimize; a plain ; won't cut it=2E int dummy, maybe though=2E There is probably a l= ot more of these, aren't there? thanks, > } [current_compiler_flags]] > } >=20 >--- gcc/testsuite/gfortran=2Edg/unlimited_polymorphic_3=2Ef03=2Ejj 2022-0= 4-25 13:54:38=2E320309119 +0200 >+++ gcc/testsuite/gfortran=2Edg/unlimited_polymorphic_3=2Ef03 2022-04-25 = 14:04:01=2E346486431 +0200 >@@ -1,5 +1,5 @@ > ! { dg-do run } >-! { dg-additional-options "-ftree-dse -fdump-tree-dse-details" } >+! { dg-additional-options "-fdump-tree-dse-details" } > ! > ! Check that pointer assignments allowed by F2003:C717 > ! work and check null initialization of CLASS(*) pointers=2E >@@ -71,5 +71,5 @@ end subroutine foo_sq > ! We used to produce multiple independant types for the unlimited polymo= rphic > ! descriptors (types for class(*)) which caused stores to them to be see= n as > ! useless=2E >-! { dg-final { scan-tree-dump-not "Deleted dead store: z=2E_data =3D &w"= "dse1" } } >-! { dg-final { scan-tree-dump-not "Deleted dead store: z=2E_data =3D &x"= "dse1" } } >+! { dg-final { scan-tree-dump-not "Deleted dead store: z=2E_data =3D &w"= "dse1" { target __OPTIMIZE__ } } } >+! { dg-final { scan-tree-dump-not "Deleted dead store: z=2E_data =3D &x"= "dse1" { target __OPTIMIZE__ } } } > > > Jakub >