0006646: Extremely long compile times and/or compiler hanging on relatively trivial sized program.

(0012488)
gasche (administrator)
2014-11-05 18:16
edited on: 2014-11-05 18:18

Indeed, it looks like you hit an infinite loop (or at least severely exponential blowup) in the pattern-matching compiler.

I was able to make compilation terminate by turning variables you have in this clause starting line 94 into constructor names. For example you have a variable 'viewref' in the faulty pattern, while other clauses match on a constructor Viewref (and the body of the clause does not use a 'viewref' variable). I assumed this may be a programming error and uppercased all variables that looked liked constructor. This gives the following pattern:

  | ITEM2(Instance, TLIST [ID instid],
            TLIST [ITEM2(Viewref,
                 TLIST [ID netlist],
                 TLIST [ITEM2(Cellref,
                          TLIST [ID cellid],
                          TLIST [ITEM(Libraryref,
                              TLIST [ID libid])])]);
            ITEM2(Property, TLIST [ID xstlib],
                    TLIST [ITEM2(bool1,
                         TLIST [],
                         TLIST [ITEM(True, TLIST [])]);
                    ITEM(Owner, TLIST [str])])]) ->
    (!instance_handler2) instid cellid libid

For which compilation terminates.

(0012489)
jrrk101 (reporter)
2014-11-05 18:22

You are correct. My bad, as the Americans say. I don't suppose a warning message could be added to the compiler when this situation occurs, it's possible other inexperienced programmers could come across the same situation.

(0012490)
jrrk101 (reporter)
2014-11-05 18:23

Update: The incorrect version does not hang, it terminates after 17.5 minutes.

(0012491)
gasche (administrator)
2014-11-05 18:38

The case is not yet closed: the blowup of compilation time is still the sign of a probable bug in the compiler. Even if it only applies to a slightly-buggy version of your code, it's still very useful that you reported it; thanks!

(0012493)
maranget (manager)
2014-11-07 15:17

I will correct this blowup, which occurs in
the pattern-matching compiler.

--Luc

(0012495)
maranget (manager)
2014-11-07 15:20

I have fixed this blowup, which occured in the pattern-matching compiler.

--Luc

Issue History
Date Modified	Username	Field	Change
2014-11-05 17:59	jrrk101	New Issue
2014-11-05 17:59	jrrk101	File Added: bug1.tgz
2014-11-05 18:16	gasche	Note Added: 0012488
2014-11-05 18:18	gasche	Note Edited: 0012488	View Revisions
2014-11-05 18:22	jrrk101	Note Added: 0012489
2014-11-05 18:23	jrrk101	Note Added: 0012490
2014-11-05 18:38	gasche	Note Added: 0012491
2014-11-07 15:17	maranget	Note Added: 0012493
2014-11-07 15:19	maranget	Note Added: 0012494
2014-11-07 15:19	maranget	Note Deleted: 0012494
2014-11-07 15:20	maranget	Note Added: 0012495
2014-11-07 15:20	maranget	Assigned To	=> maranget
2014-11-07 15:20	maranget	Status	new => resolved
2014-11-07 15:20	maranget	Resolution	open => fixed
2014-11-07 15:20	maranget	Fixed in Version	=> 4.03.0+dev / +beta1
2014-11-25 14:21	frisch	Relationship added	related to 0006674
2016-12-07 11:36	xleroy	Status	resolved => closed
2017-02-23 16:36	doligez	Category	OCaml general => -OCaml general
2017-03-03 17:55	doligez	Category	-OCaml general => -(deprecated) general
2017-03-03 18:01	doligez	Category	-(deprecated) general => ~deprecated (was: OCaml general)
2017-03-06 17:04	doligez	Category	~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)

Notes
(0012488) gasche (administrator) 2014-11-05 18:16 edited on: 2014-11-05 18:18	Indeed, it looks like you hit an infinite loop (or at least severely exponential blowup) in the pattern-matching compiler. I was able to make compilation terminate by turning variables you have in this clause starting line 94 into constructor names. For example you have a variable 'viewref' in the faulty pattern, while other clauses match on a constructor Viewref (and the body of the clause does not use a 'viewref' variable). I assumed this may be a programming error and uppercased all variables that looked liked constructor. This gives the following pattern: \| ITEM2(Instance, TLIST [ID instid], TLIST [ITEM2(Viewref, TLIST [ID netlist], TLIST [ITEM2(Cellref, TLIST [ID cellid], TLIST [ITEM(Libraryref, TLIST [ID libid])])]); ITEM2(Property, TLIST [ID xstlib], TLIST [ITEM2(bool1, TLIST [], TLIST [ITEM(True, TLIST [])]); ITEM(Owner, TLIST [str])])]) -> (!instance_handler2) instid cellid libid For which compilation terminates.

(0012489) jrrk101 (reporter) 2014-11-05 18:22	You are correct. My bad, as the Americans say. I don't suppose a warning message could be added to the compiler when this situation occurs, it's possible other inexperienced programmers could come across the same situation.

(0012490) jrrk101 (reporter) 2014-11-05 18:23	Update: The incorrect version does not hang, it terminates after 17.5 minutes.

(0012491) gasche (administrator) 2014-11-05 18:38	The case is not yet closed: the blowup of compilation time is still the sign of a probable bug in the compiler. Even if it only applies to a slightly-buggy version of your code, it's still very useful that you reported it; thanks!

(0012493) maranget (manager) 2014-11-07 15:17	I will correct this blowup, which occurs in the pattern-matching compiler. --Luc

(0012495) maranget (manager) 2014-11-07 15:20	I have fixed this blowup, which occured in the pattern-matching compiler. --Luc