diff options
author | Jakub Jelinek <jakub@redhat.com> | 2020-04-30 21:48:30 +0200 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2020-04-30 21:48:30 +0200 |
commit | bf9155914f0c2dac62c6abf1e45abb52a5a56e5b (patch) | |
tree | de693ac5e2948a01bcf8ed5843523adbdd6831eb /gcc/varasm.c | |
parent | 66ec22b0d3feb96049283abe5c6c9a05ecef8b86 (diff) | |
download | gcc-bf9155914f0c2dac62c6abf1e45abb52a5a56e5b.zip gcc-bf9155914f0c2dac62c6abf1e45abb52a5a56e5b.tar.gz gcc-bf9155914f0c2dac62c6abf1e45abb52a5a56e5b.tar.bz2 |
c: Fix ICE with _Atomic side-effect in nested fn param decls [PR94842]
If there are _Atomic side-effects in the parameter declarations
of non-nested function, when they are parsed, current_function_decl is
NULL, the create_artificial_label created labels during build_atomic* are
then adjusted by store_parm_decls through set_labels_context_r callback.
Unfortunately, if such thing happens in nested function parameter
declarations, while those decls are parsed current_function_decl is the
parent function (and am not sure it is a good idea to temporarily clear it,
some code perhaps should be aware it is in a nested function, or it can
refer to variables from the parent function etc.) and that means
store_param_decls through set_labels_context_r doesn't adjust anything.
As those labels are emitted in the nested function body rather than in the
parent, I think it is ok to override the context in those cases.
2020-04-30 Jakub Jelinek <jakub@redhat.com>
PR c/94842
* c-decl.c (set_labels_context_r): In addition to context-less
LABEL_DECLs adjust also LABEL_DECLs with context equal to
parent function if any.
(store_parm_decls): Adjust comment.
* gcc.dg/pr94842.c: New test.
Diffstat (limited to 'gcc/varasm.c')
0 files changed, 0 insertions, 0 deletions