[Bug target/112334] ICE in gen_untyped_return arm.md:9197 while compiling harden-cfr-bret.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112334 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Alexandre Oliva --- Fixed, though there's an (optional) followup, posted along with the fix, that's not clearly approved.
[Bug target/112334] ICE in gen_untyped_return arm.md:9197 while compiling harden-cfr-bret.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112334 --- Comment #4 from GCC Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:d96533559e26dd0c86f0708fa46eef65c35f7b90 commit r14-6446-gd96533559e26dd0c86f0708fa46eef65c35f7b90 Author: Alexandre Oliva Date: Tue Dec 12 01:12:04 2023 -0300 untyped calls: enable target switching [PR112334] The computation of apply_args_size and apply_result_size is saved in a static variable, so that the corresponding _mode arrays are initialized only once. That is not compatible with switchable targets, and ARM's arm_set_current_function, by saving and restoring target globals, exercises this problem with a testcase such as that in the PR, in which more than one function in the translation unit calls __builtin_apply or __builtin_return, respectively. This patch moves the _size statics into the target_builtins array, with a bit of ugliness over _plus_one so that zero initialization of the struct does the right thing. for gcc/ChangeLog PR target/112334 * builtins.h (target_builtins): Add fields for apply_args_size and apply_result_size. * builtins.cc (apply_args_size, apply_result_size): Cache results in fields rather than in static variables. (get_apply_args_size, set_apply_args_size): New. (get_apply_result_size, set_apply_result_size): New.
[Bug target/112334] ICE in gen_untyped_return arm.md:9197 while compiling harden-cfr-bret.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112334 Alexandre Oliva changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-12-06 Status|UNCONFIRMED |ASSIGNED --- Comment #3 from Alexandre Oliva --- The testcase changes silenced the noise that made the problem visible, but the latent bug is still lurking. The patch that cures the underlying bug is at https://gcc.gnu.org/pipermail/gcc-patches/2023-December/638949.html
[Bug target/112334] ICE in gen_untyped_return arm.md:9197 while compiling harden-cfr-bret.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112334 --- Comment #2 from GCC Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:b8edb812ff4934c609fdfafe2e1c7f932bc18305 commit r14-6062-gb8edb812ff4934c609fdfafe2e1c7f932bc18305 Author: Alexandre Oliva Date: Fri Dec 1 14:31:22 2023 -0300 hardcfr: make builtin_return tests more portable [PR112334] Rework __builtin_return tests to explicitly call __builtin_apply and use its return value rather than anything else. Also require untyped_assembly. Avoid the noise out of exceptions escaping the builtin-applied function, but add a test to cover their effects as well. for gcc/testsuite/ChangeLog PR target/112334 * c-c++-common/torture/harden-cfr-bret.c: Rework for stricter untyped_return requirements. Require untyped_assembly. * c-c++-common/torture/harden-cfr-bret-except.c: New. * c-c++-common/torture/harden-cfr-bret-always.c: Require untyped_assembly. * c-c++-common/torture/harden-cfr-bret-never.c: Likewise. * c-c++-common/torture/harden-cfr-bret-noopt.c: Likewise. * c-c++-common/torture/harden-cfr-bret-noret.c: Likewise. * c-c++-common/torture/harden-cfr-bret-no-xthrow.c: Likewise. * c-c++-common/torture/harden-cfr-bret-nothrow.c: Likewise. * c-c++-common/torture/harden-cfr-bret-retcl.c: Likewise.
[Bug target/112334] ICE in gen_untyped_return arm.md:9197 while compiling harden-cfr-bret.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112334
--- Comment #1 from Richard Earnshaw ---
This might be a side issue, but:
@defbuiltin{{void} __builtin_return (void *@var{result})}
This built-in function returns the value described by @var{result} from
the containing function. You should specify, for @var{result}, a value
returned by @code{__builtin_apply}.
So I'm not sure it's legal to pass to __builtin_return().
