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

sdfg.validate goes on infinite recursion with loopy sdfg #1562

Closed
tim0s opened this issue Apr 26, 2024 · 1 comment · Fixed by #1711
Closed

sdfg.validate goes on infinite recursion with loopy sdfg #1562

tim0s opened this issue Apr 26, 2024 · 1 comment · Fixed by #1711

Comments

@tim0s
Copy link
Contributor

tim0s commented Apr 26, 2024

Describe the bug

For certain (erroneous) SDFGs, sdfg.validate() does not thrown an exception, instead it crashes with a RecursionError.
This may be undesirable, since it is unclear to the user if the SDFG is erroneous or he should increase the stack size in order to be able to validate the SDFG.

To Reproduce

Run the following Python code:

import dace
sdfg = dace.SDFG("foo")
state = sdfg.add_state()
mentry_2, mexit_2 = state.add_map("map_2", dict(i="0:9"))
mentry_6, mexit_6 = state.add_map("map_6", dict(i="0:9"))
mentry_8, mexit_8 = state.add_map("map_8", dict(i="0:9"))
state.add_edge(mentry_8, "OUT_0", mentry_6, "IN_0", dace.Memlet(data="bla", subset='0:9'))
state.add_edge(mentry_6, "OUT_0", mentry_2, "IN_0", dace.Memlet(data="bla", subset='0:9'))
state.add_edge(mentry_2, "OUT_0", mentry_6, "IN_0", dace.Memlet(data="bla", subset='0:9'))
sdfg.validate()

Expected behavior
Either sdfg.validate() throws an exception telling me I formed a loop, or the last add_edge() throws an exception telling me I cannot add this edge because it would form a loop.

tbennun added a commit that referenced this issue Oct 29, 2024
@tbennun
Copy link
Collaborator

tbennun commented Oct 29, 2024

Fixed in #1711

@tbennun tbennun linked a pull request Oct 29, 2024 that will close this issue
10 tasks
tbennun added a commit that referenced this issue Oct 29, 2024
The PR adds a new syntax to support inline storage specification with
the `@` operator, supporting the following statements: `a = np.ones(M) @
dace.StorageType.CPU_ThreadLocal`.

This PR also fixes multiple minor issues in the Python frontend:
* `WarpTiling` did not respect sequential map schedules
* Non-sequence inputs for `numpy.fill` variants (e.g.,
`numpy.zeros(N)`)
* NumPy replacement syntax errors would sometimes not have source
information
* Fix type inference for nested scopes in Python frontend
* Dynamic thread block scheduling does not support multi-dimensional
maps
* Default schedule inference should use dynamic thread blocks if
they exist
* Type hints with storage type not being adhered to by the Python
frontend
* Validation issue #1562

The following changes were added as skipped tests and deferred to future PRs:
* Dynamic map range related issues: Fix deferred to #1696
* Dynamic thread block scheduling would not pass object to nested
functions: Fix deferred to future PR, see #1189 for more information
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants