diff options
| author | Jakub Jelinek <jakub@redhat.com> | 2025-01-03 17:59:57 +0100 |
|---|---|---|
| committer | Jakub Jelinek <jakub@gcc.gnu.org> | 2025-01-03 17:59:57 +0100 |
| commit | 6f444e45d3fd6c45fc34a79ac66bf46c20fd95b1 (patch) | |
| tree | 7f8cfef370d3616038a78df2bae0868cbc719f0c /gcc/c/c-parser.cc | |
| parent | 514577c66b39fc321bec1c957130fbcd66207822 (diff) | |
| download | gcc-6f444e45d3fd6c45fc34a79ac66bf46c20fd95b1.zip gcc-6f444e45d3fd6c45fc34a79ac66bf46c20fd95b1.tar.gz gcc-6f444e45d3fd6c45fc34a79ac66bf46c20fd95b1.tar.bz2 | |
varasm: Fix up array_size_for_constructor RAW_DATA_CST handling once again [PR118275]
As the following testcases show (the latter only if I revert the
temporary reversion of the C++ large array speedup), the FEs aren't
really consistent in the type of array CONSTRUCTOR_ELTS indexes,
it can be bitsizetype, but can be sizetype as well.
Given that everything else is able to cope with it just fine,
I'm using build_int_cst which also doesn't care what type it is,
instead of bitsize_int, which I've used in PR117190 fix (previously
it was size_int).
2025-01-03 Jakub Jelinek <jakub@redhat.com>
PR c++/118275
* varasm.cc (array_size_for_constructor): Use build_int_cst
with TREE_TYPE (index) as first argument, instead of bitsize_int.
* g++.dg/cpp/embed-18.C: New test.
* g++.dg/ext/flexary41.C: New test.
Diffstat (limited to 'gcc/c/c-parser.cc')
0 files changed, 0 insertions, 0 deletions