aboutsummaryrefslogtreecommitdiff
path: root/gcc/varasm.c
diff options
context:
space:
mode:
authorJakub Jelinek <jakub@redhat.com>2020-04-30 21:48:30 +0200
committerJakub Jelinek <jakub@redhat.com>2020-04-30 21:48:30 +0200
commitbf9155914f0c2dac62c6abf1e45abb52a5a56e5b (patch)
treede693ac5e2948a01bcf8ed5843523adbdd6831eb /gcc/varasm.c
parent66ec22b0d3feb96049283abe5c6c9a05ecef8b86 (diff)
downloadgcc-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