From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <amacleod@redhat.com>
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [216.205.24.124])
 by sourceware.org (Postfix) with ESMTP id 4A7C73857C75
 for <gcc@gcc.gnu.org>; Fri, 12 Feb 2021 22:15:14 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4A7C73857C75
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-557-8HYOS-O7Nt-07WhERvaMwA-1; Fri, 12 Feb 2021 17:15:12 -0500
X-MC-Unique: 8HYOS-O7Nt-07WhERvaMwA-1
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com
 [10.5.11.22])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 877E1100CC84
 for <gcc@gcc.gnu.org>; Fri, 12 Feb 2021 22:15:11 +0000 (UTC)
Received: from [10.10.112.19] (ovpn-112-19.rdu2.redhat.com [10.10.112.19])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 3FE2D10016FE
 for <gcc@gcc.gnu.org>; Fri, 12 Feb 2021 22:15:11 +0000 (UTC)
To: GCC <gcc@gcc.gnu.org>
From: Andrew MacLeod <amacleod@redhat.com>
Subject: bug in DSE?
Message-ID: <cbff990c-97c5-2109-353c-3bffebd0d83b@redhat.com>
Date: Fri, 12 Feb 2021 17:15:10 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.4.0
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH,
 DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW,
 RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gcc@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc mailing list <gcc.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <mailto:gcc-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Feb 2021 22:15:16 -0000

I dont't want to immediately open a PR,  so I'll just ask about 
testsuite/gcc.dg/pr83609.c.

the compilation string  is
   -O2 -fno-tree-forwprop -fno-tree-ccp -fno-tree-fre -fno-tree-pre 
-fno-code-hoisting

Which passes as is.

if I however add   -fno-tree-vrp   as well, then it looks like dead 
store maybe does something wong...

with EVRP running, we translate function foo() from


complex float foo ()
{
   complex float c;
   complex float * c.0_1;
   complex float _4;

   <bb 2> :
   c.0_1 = &c;
   MEM[(long long unsigned int *)c.0_1] = 1311768467463790320;
   _4 = c;
   c ={v} {CLOBBER};
   return _4;

}
to

   complex float c;
   complex float _4;

   <bb 2> :
   MEM[(long long unsigned int *)&c] = 1311768467463790320;
   _4 = c;
   c ={v} {CLOBBER};
   return _4;

and everything works fine.

If we don't do EVRP, then DSE takes the original, and reports:

   Deleted dead store: MEM[(long long unsigned int *)c.0_1] = 
1311768467463790320;

transforming it to:

complex float foo ()
{
   complex float c;
   complex float * c.0_1;
   complex float _4;

   <bb 2> :
   c.0_1 = &c;
   _4 = c;
   c ={v} {CLOBBER};
   return _4;

}

That doesn't seem right?

and the place where it is inlined in main() becomes
  <bb 2> :
   _4 = c_11(D);
   _10 = _4;
   _1 = _10;
   u$c_9 = _1;
   _2 = VIEW_CONVERT_EXPR<long long unsigned int>(u$c_9);
   if (_2 != 1311768467463790320)


I not really sure exactly what is going on...  but I do know that the 
testcase aborts() if we turn off VRP :-P

Andrew