Bug 85600 - [9 Regression] CPU2006 471.omnetpp fails starting with r259771
Summary: [9 Regression] CPU2006 471.omnetpp fails starting with r259771
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 9.0
: P1 normal
Target Milestone: 9.0
Assignee: Jason Merrill
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2018-05-01 21:13 UTC by Pat Haugen
Modified: 2018-05-03 23:35 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work: 8.0
Known to fail: 9.0
Last reconfirmed: 2018-05-03 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pat Haugen 2018-05-01 21:13:28 UTC
Benchmark is failing at runtime, emitting following message at the end before exiting with rc=1.

** Event #0   T=0.0000000  ( 0.00s)
     Messages:  created: 77472
** Event #5000000   T=0.0868274600 ( 86ms)
     Messages:  created: 3949482
** Event #10000000   T=0.1605411650 (160ms)
     Messages:  created: 7854099
<!> Error in module largeNet.llanBB[48].bhost[3].mac: (cQueue)largeNet.llanBB[48].bhost[3].mac.class-members.outputBuffer: pop(): queue empty.

End run of OMNeT++
Comment 1 Andrew Pinski 2018-05-01 21:19:18 UTC
Does adding -fno-lifetime-dse help?  This could be a bug in the omnetpp sources ...
Comment 2 Pat Haugen 2018-05-01 21:35:33 UTC
(In reply to Andrew Pinski from comment #1)
> Does adding -fno-lifetime-dse help?  This could be a bug in the omnetpp
> sources ...

Nope, still fails.

471.omnetpp: copy 0 non-zero return code (exit code=1, signal=0)
Comment 3 Pat Haugen 2018-05-02 00:10:04 UTC
Benchmark fails same way with no optimization.
Comment 4 rdapp 2018-05-03 11:17:34 UTC
This also happens on s390x, even with -O0 and no new -march setting.

The following line in EtherMac.cc

 delete outputbuffer.pop()

actually emits two calls to

 cQueue::pop ().

On the second call, the queue is empty and the program terminates.

Already in the .original pass, a SAVE_EXPR that was there before is not present anymore:

if (SAVE_EXPR <cQueue::pop [..]

vs.

if (cQueue::pop [..]

r259771 removes two checks like this:

-      if (TREE_SIDE_EFFECTS (addr))          
-       addr = save_expr (addr);

Are they really redundant?
Comment 5 H.J. Lu 2018-05-03 11:38:57 UTC
Also failed on x86:

https://gcc.gnu.org/ml/gcc-testresults/2018-05/msg00217.html
Comment 6 rdapp 2018-05-03 11:42:46 UTC
This hunk causes the double pop():

@@ -4650,8 +4648,6 @@ build_delete (tree otype, tree addr, special_function_kind auto_delete,
                }
            }
        }
-      if (TREE_SIDE_EFFECTS (addr))
-       addr = save_expr (addr);
 
       /* Throw away const and volatile on target type of addr.  */
       addr = convert_force (build_pointer_type (type), addr, 0, complain);


addr has the side-effects bit set at that point.
Comment 7 sudi 2018-05-03 12:29:33 UTC
Also failing on aarch64 targets.
Comment 8 Jason Merrill 2018-05-03 23:35:37 UTC
Fixed.
Comment 9 Jason Merrill 2018-05-03 23:35:52 UTC
Author: jason
Date: Thu May  3 23:35:20 2018
New Revision: 259913

URL: https://gcc.gnu.org/viewcvs?rev=259913&root=gcc&view=rev
Log:
	PR c++/85600 - virtual delete failure.

	* init.c (build_delete): Always save_expr when deleting.

Added:
    trunk/gcc/testsuite/g++.dg/expr/delete2.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/init.c