Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extremely long compile times and/or compiler hanging on relatively trivial sized program. #6646

Closed
vicuna opened this Issue Nov 5, 2014 · 6 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link
Collaborator

vicuna commented Nov 5, 2014

Original bug ID: 6646
Reporter: jrrk101
Assigned to: @maranget
Status: closed (set by @xavierleroy on 2016-12-07T10:36:59Z)
Resolution: fixed
Priority: normal
Severity: major
Platform: x86_64
OS: centos
OS Version: 6.5 final
Version: 4.02.1
Fixed in version: 4.03.0+dev / +beta1
Category: ~DO NOT USE (was: OCaml general)
Related to: #6674
Monitored by: @gasche jmeber

Bug description

The addition or deletion of a single line in a match clause makes the difference between compiling in around one second and compilation taking minutes or perhaps hanging for ever. Also occurs in 3.12.1 and on OSX.

Steps to reproduce

detach attached file as bug1.tgz
tar xzf bug1.tgz
cd edif_parser
make

Additional information

The removal of the line starting at line 94 in sparse.ml allows the compilation to complete. No workaround was found. Enjoy Bonfire Night all OCaml hackers in the UK...

File attachments

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Nov 5, 2014

Comment author: @gasche

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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Nov 5, 2014

Comment author: jrrk101

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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Nov 5, 2014

Comment author: jrrk101

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

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Nov 5, 2014

Comment author: @gasche

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!

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Nov 7, 2014

Comment author: @maranget

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

--Luc

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Nov 7, 2014

Comment author: @maranget

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

--Luc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.