g++ version: 8.3.0 (and later) system: Ubuntu 18.04 complete command line that triggers the bug: g++ -std=c++11 -o out main.cpp compiler output: none ----------------------- When I use g++8.3 and later version to compile and run the following code, the results are not as expected. But if I use 8.2 and earlier version or other compiler, like clang, wont't occure a fault result. /* class define */ class A { private: int d = 9; public: A()=default; A(int a) : d(a) {} void f() {cout << d << endl;} }; /* class define end */ /* test code 1 */ A a[3] = {1}; //global int main() { a[0].f(); //Output: 1 a[1].f(); //Output: 9 a[2].f(); //Output: 0 //error return 0; } /* test code 1 end */ But if put A a[3] = {1} in main() function, it doesn't error. /* test code 2 */ int main() { A a[3] = {1}; a[0].f(); //Output: 1 a[1].f(); //Output: 9 a[2].f(); //Output: 9 //right! return 0; } /* test code 2 end */ And I find add number in initialization list, how many elements are initialized then the last number of elements in the array is an incorrect result. For example: /* test code 3 */ A a[100]={1,1, 1}; // global int main() { a[0].f(); //Output: 1 a[1].f(); //Output: 1 a[2].f(); //Output: 1 a[3].f(); //Output: 9 a[4].f(); //Output: 9 ..... //Output: 9 a[96].f(); //Output: 9 a[97].f(); //Output: 0 //error a[98].f(); //Output: 0 //error a[99].f(); //Output: 0 //error return 0; } /* test code 3 end */ /* full code of test code 1 */ class A { private: int d = 9; public: A()=default; A(int a) : d(a) {} void f() {cout << d << endl;} }; A a[3]={1}; int main() { a[0].f(); a[1].f(); a[2].f(); return 0; } /* full code end*/
Untested fix: --- gcc/varasm.c.jj 2020-01-22 10:19:24.000000000 +0100 +++ gcc/varasm.c 2020-03-24 18:03:08.532690584 +0100 @@ -5152,6 +5152,26 @@ struct oc_local_state { static void output_constructor_array_range (oc_local_state *local) { + /* Perform the index calculation in modulo arithmetic but + sign-extend the result because Ada has negative DECL_FIELD_OFFSETs + but we are using an unsigned sizetype. */ + unsigned prec = TYPE_PRECISION (sizetype); + offset_int idx = wi::sext (wi::to_offset (TREE_OPERAND (local->index, 0)) + - wi::to_offset (local->min_index), prec); + tree valtype = TREE_TYPE (local->val); + HOST_WIDE_INT fieldpos + = (idx * wi::to_offset (TYPE_SIZE_UNIT (valtype))).to_short_addr (); + + /* Advance to offset of this element. */ + if (fieldpos > local->total_bytes) + { + assemble_zeros (fieldpos - local->total_bytes); + local->total_bytes = fieldpos; + } + else + /* Must not go backwards. */ + gcc_assert (fieldpos == local->total_bytes); + unsigned HOST_WIDE_INT fieldsize = int_size_in_bytes (TREE_TYPE (local->type));
Regressed with r267142
Jonathan has bisected this to my r9-4877-gfaa9232da39587b27b46341667d6d415d2af9280 change (though, as the patch shows, the bug is actually that varasm.c didn't handle RANGE_EXPRs properly during output_constructor.
Created attachment 48107 [details] gcc10-pr94303.patch Full untested patch.
*** Bug 94316 has been marked as a duplicate of this bug. ***
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:5f18995e23edc944af3a401d9d9d3320a9362652 commit r10-7368-g5f18995e23edc944af3a401d9d9d3320a9362652 Author: Jakub Jelinek <jakub@redhat.com> Date: Wed Mar 25 09:21:05 2020 +0100 varasm: Fix output_constructor where a RANGE_EXPR index needs to skip some elts [PR94303] The following testcase is miscompiled, because output_constructor doesn't output the initializer correctly. The FE creates {[1...2] = 9} in this case, and we emit .long 9; long 9; .zero 8 instead of the expected .zero 8; .long 9; .long 9. If the CONSTRUCTOR is {[1] = 9, [2] = 9}, output_constructor_regular_field has code to notice that the current location (local->total_bytes) is smaller than the location we want to write to (1*sizeof(elt)) and will call assemble_zeros to skip those. But RANGE_EXPRs are handled by a different function which didn't do this, so for RANGE_EXPRs we emitted them properly only if local->total_bytes was always equal to the location where the RANGE_EXPR needs to start. 2020-03-25 Jakub Jelinek <jakub@redhat.com> PR middle-end/94303 * varasm.c (output_constructor_array_range): If local->index RANGE_EXPR doesn't start at the current location in the constructor, skip needed number of bytes using assemble_zeros or assert we don't go backwards. PR middle-end/94303 * g++.dg/torture/pr94303.C: New test.
Fixed on the trunk so far.
The releases/gcc-9 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:56407bab53a514ffcd6ac011965cebdc5eb3ef54 commit r9-8471-g56407bab53a514ffcd6ac011965cebdc5eb3ef54 Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Apr 7 20:59:37 2020 +0200 varasm: Fix output_constructor where a RANGE_EXPR index needs to skip some elts [PR94303] The following testcase is miscompiled, because output_constructor doesn't output the initializer correctly. The FE creates {[1...2] = 9} in this case, and we emit .long 9; long 9; .zero 8 instead of the expected .zero 8; .long 9; .long 9. If the CONSTRUCTOR is {[1] = 9, [2] = 9}, output_constructor_regular_field has code to notice that the current location (local->total_bytes) is smaller than the location we want to write to (1*sizeof(elt)) and will call assemble_zeros to skip those. But RANGE_EXPRs are handled by a different function which didn't do this, so for RANGE_EXPRs we emitted them properly only if local->total_bytes was always equal to the location where the RANGE_EXPR needs to start. 2020-03-25 Jakub Jelinek <jakub@redhat.com> PR middle-end/94303 * varasm.c (output_constructor_array_range): If local->index RANGE_EXPR doesn't start at the current location in the constructor, skip needed number of bytes using assemble_zeros or assert we don't go backwards. PR middle-end/94303 * g++.dg/torture/pr94303.C: New test.
Fixed for 9.4+ too.
Fixed for 8.5 in r8-10475-g0aa738f8d4469434c131dc36711a045cfd8ecd7f too.