-
Notifications
You must be signed in to change notification settings - Fork 171
Fixed output through c_sym backend for test_gruntz.py #2441
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -415,11 +415,6 @@ class ASRToCVisitor : public BaseCCPPVisitor<ASRToCVisitor> | |||||
headers.insert("complex.h"); | ||||||
convert_variable_decl_util(v, is_array, declare_as_constant, use_ref, dummy, | ||||||
force_declare, force_declare_name, n_dims, m_dims, v_m_type, dims, sub); | ||||||
} else if (ASR::is_a<ASR::SymbolicExpression_t>(*v_m_type)) { | ||||||
headers.insert("symengine/cwrapper.h"); | ||||||
std::string type_name = "basic"; | ||||||
std::string v_m_name = v.m_name; | ||||||
sub = format_type_c("", type_name, v_m_name, use_ref, dummy); | ||||||
} else if (ASRUtils::is_logical(*v_m_type)) { | ||||||
convert_variable_decl_util(v, is_array, declare_as_constant, use_ref, dummy, | ||||||
force_declare, force_declare_name, n_dims, m_dims, v_m_type, dims, sub); | ||||||
|
@@ -529,7 +524,12 @@ class ASRToCVisitor : public BaseCCPPVisitor<ASRToCVisitor> | |||||
} else if (ASR::is_a<ASR::List_t>(*v_m_type)) { | ||||||
ASR::List_t* t = ASR::down_cast<ASR::List_t>(v_m_type); | ||||||
std::string list_type_c = c_ds_api->get_list_type(t); | ||||||
sub = format_type_c("", list_type_c, v.m_name, | ||||||
std::string name = v.m_name; | ||||||
if (name == "_lpython_return_variable" && v.m_intent == ASRUtils::intent_out) { | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The fix might be as simple as:
Suggested change
If it doesn't work, then let's figure out an example where this fails and understand if there are other corner cases to be fixed. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe the condition is that if it is a List, it should be passes as a pointer. |
||||||
is_return_var_intent_out = true; | ||||||
name = "*" + name; | ||||||
} | ||||||
sub = format_type_c("", list_type_c, name, | ||||||
false, false); | ||||||
} else if (ASR::is_a<ASR::Tuple_t>(*v_m_type)) { | ||||||
ASR::Tuple_t* t = ASR::down_cast<ASR::Tuple_t>(v_m_type); | ||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is hardwiring a check for
_lpython_return_variable
at several places in the C backend.However, the C backend should work with any frontend, and should be independent of how the frontend names its variables.
Is there a way to fix it without any such checks of the type
name == "_lpython_return_variable"
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall look into it !
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a couple places to consider if you think about it
subroutine_from_function
, we would end up with this ASR nodeAs we are finally storing whatever answer we want to return in the variable of intent
Out
(which in our case and I think most cases would be_lpython_return_variable
or basically the variable to be returned.)So I think we could do with just the
m_intent == ASRUtils::intent_out
check for any normal case as we know thereturn_var
is changed toout
. Only when some exceptional/corner case comes up we might have to think about thisThe "_lpython_return_variable" just adds another level of security and in general gives more protection.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say we can just use it once in the beggining (when we hit the variable)
Here we can check
Once this is done we can always use the bool variable
is_return_var_intent_out
for anything we want.If we don't want to do this, we can obviously make it a bit more specific to cater to cases relevant to us for now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After some thought and checking for some corner cases I've realized that we might be able to do without using "_lpython_return_variable" but it's best (in terms of convinience) to use it. Let's discuss more in the call today.