aboutsummaryrefslogtreecommitdiff
path: root/gcc/cp/semantics.c
diff options
context:
space:
mode:
authorRichard Sandiford <richard.sandiford@arm.com>2020-01-21 18:22:38 +0000
committerRichard Sandiford <richard.sandiford@arm.com>2020-01-22 14:33:19 +0000
commit7c46e71d016c86971ac26c6fa38d76482859f296 (patch)
treed9688d2364432c863c54b7e08635fa8e9dda8bba /gcc/cp/semantics.c
parent7491c17fe01d8cf116f645532d46120029b26408 (diff)
downloadgcc-7c46e71d016c86971ac26c6fa38d76482859f296.zip
gcc-7c46e71d016c86971ac26c6fa38d76482859f296.tar.gz
gcc-7c46e71d016c86971ac26c6fa38d76482859f296.tar.bz2
cfgexpand: Update partition size when merging variables
cfgexpand sorts variables by decreasing size, so when merging a later variable into an earlier one, there's usually no need to update the merged size. But for poly_int sizes, the sort function just uses a lexicographical comparison of the coefficients, so e.g. 2X+2 comes before 0X+32. Which is bigger depends on the runtime value of X. This patch therefore takes the upper bound of the two sizes, which is conservatively correct for variable-length vectors and a no-op on other targets. It's probably a bad idea to merge fixed-length and variable-length variables in practice, but that's really an optimisation decision. I think we should have this patch as a correctness fix either way. This is easiest to test using the ACLE, but in principle it could happen for autovectorised code too, e.g. when using OpenMP vector variables. It's therefore a regression from GCC 8. 2020-01-22 Richard Sandiford <richard.sandiford@arm.com> gcc/ * cfgexpand.c (union_stack_vars): Update the size. gcc/testsuite/ * gcc.target/aarch64/sve/acle/general/stack_vars_1.c: New test.
Diffstat (limited to 'gcc/cp/semantics.c')
0 files changed, 0 insertions, 0 deletions