Due to weird circumstances detailed in the PR, this test briefly
passed (it has always failed before), so technically I'm fixing
a regression. :)
The test checks that a certain label is mentioned twice; being
mentioned once infers that there are two identical initializer
vectors in the constant-pool.
But, for cris-elf (and reasonably the same for other targets)
there might not be such a constant-pool entry in the first
place: the vectors are too short to rule out piecewise
initialization as optimal for size (counting the vectors once
per use). Let's increase them. Twice might just break-even for
cris-elf so let's make them four times as long. Sanity-checked
for x86_64 w/w.o -m32 for a gcc-version that includes the
optimization for which the test-case tests (CCing author).
Ok to commit?
gcc/testsuite:
PR testsuite/55186
* gcc/testsuite/gcc.dg/const-uniq-1.c (a): Increase length four times.
Index: gcc/testsuite/gcc.dg/const-uniq-1.c
===================================================================
--- gcc/testsuite/gcc.dg/const-uniq-1.c (revision 193117)
+++ gcc/testsuite/gcc.dg/const-uniq-1.c (working copy)
@@ -5,13 +5,18 @@
int lookup1 (int i)
{
- int a[] = { 0, 1, 2, 3, 4, 5, 6, 7 };
+ /* We use vectors long enough that piece-wise initialization is not
+ reasonably preferable even for size (when including the constant
+ vectors for initialization) for any target. */
+ int a[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
+ 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 };
return a[i];
}
int lookup2 (int i)
{
- int a[] = { 0, 1, 2, 3, 4, 5, 6, 7 };
+ int a[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
+ 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 };
return a[i+1];
}
brgds, H-P
