This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[JiÅÃ PaleÄek] [PATCH][C++] Fix constant reference in a lambda (PR c++/53488)


Let's CC Jason.

--- Begin Message --- Hello,

I've been investigating a bug in gcc I came across recently and after some difficulties, I have produced a patch that actually fixes that behavior. However, I don't think the patch is very good and I would really appreciate your help in making it better.

The problem is that when a const(expr) variable is used in a lambda, it yields garbage values in gcc when the initializer is dependent. Moreover, it should not be captured if it fulfills the requirements of a constant expression (at least that's how I understand the definition of "odr-used" along with the definition of default captures). finish_id_expression did return VAR_DECL for the corresponding automatic variable in that case, but didn't create the capture.

The idea of the fix is to postpone the decision whether or not to capture later to the template instantiation. This is because until then, we cannot know if the variable fulfills the conditions for a constant expression or not. So the patch assumes that if the constant value is a VAR_DECL (which is what I've found to happen in the debugger, although I'm not sure this is the only case) and we are in a template declaration, it just leaves the id expression there as is.

Then the patch fiddles with the capture list in template instantiation code. Because new captures can be added while processing the template, we need to concatenate them with the original list from the template, plus there's a small hack to avoid producing the lambda-to-function-pointer conversion operator while we still don't have the final capture list.

I have produced two tests (in the patch) and ran the testsuite in the gcc subdirectory successfully. I've also tested the behavior on a testcase in the attached test.cpp file (it should print ok with all possible combinations of #defined macros).

I'd be grateful on your comments on this, especially

- whether the approach taken is a good one, and
- whether my assumptions about what's going on in the code (expressed either in this mail and in the comments in code) are true


Regards
    Jiri Palecek

Attachment: gcc.diff
Description: Binary data

Attachment: test.cpp
Description: Binary data


--- End Message ---

-- 
		Dodji

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]