http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46188
Jens Maurer <jens.maurer at gmx dot net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #22164|0 |1
is obsolete| |
--- Comment #2 from Jens Maurer <jens.maurer at gmx dot net> 2010-10-26
21:09:14 UTC ---
Created attachment 22165
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22165
file to reproduce the bug, now with all aliasing and memory allocation removed
Thanks for your comment. I've uploaded a new test file that removes all memory
allocations and never ever stores something in this->data, so no aliasing
issues should arise.
Instead of "delete[]", I'm now calling an external function "h". As usual,
I've removed the .cfi notes from the assembly quotes below.
bad compile:
$ g++ -S playground2.cxx -fverbose-asm -O2
125 call g(C const&, C&) #
126 .LEHE0:
127 movq 24(%rsp), %rdi # c2.b_array.data, D.3401
128 testq %rdi, %rdi # D.3401
129 je .L9 #,
130 .LEHB1:
131 call h(char*) #
132 .LEHE1:
133 .L9:
134 movq 16(%rsp), %rdi # c2.s.adr,
135 .LEHB2:
136 call h(char*) #
137 .LEHE2:
138 addq $48, %rsp #,
141 popq %rbx #
143 ret
good compile:
$ g++ -S playground2.cxx -fverbose-asm -O2 -fno-ipa-cp
130 call g(C const&, C&) #
131 .LEHE0:
132 movq 8(%rsp), %rbx # c2.b_array.data, p
133 testq %rbx, %rbx # p
134 je .L9 #,
135 movq 16(%rsp), %r12 # c2.b_array.size, D.3387
136 testq %r12, %r12 # D.3387
137 je .L10 #,
138 xorl %ebp, %ebp # i
139 jmp .L14 #
140 .p2align 4,,10
141 .p2align 3
142 .L22:
143 addq $24, %rbx #, p
144 .L14:
145 movq (%rbx), %rdi # p->char_array.data, D.3401
146 testq %rdi, %rdi # D.3401
147 je .L12 #,
148 .LEHB1:
149 call h(char*) #
150 .L12:
151 addq $1, %rbp #, i
152 cmpq %rbp, %r12 # i, D.3387
153 ja .L22 #,
154 movq 8(%rsp), %rbx # c2.b_array.data, p
155 .L10:
156 movq %rbx, %rdi # p,
157 call h(char*) #
158 .LEHE1:
159 .L9:
160 movq (%rsp), %rdi # c2.s.adr,
161 .LEHB2:
162 call h(char*) #
163 .LEHE2:
164 addq $32, %rsp #,
167 popq %rbx #
169 popq %rbp #
171 popq %r12 #
173 ret
As can be seen, the destructors on B::char_array are being called (as evidenced
by the loop calling "h"), as opposed to the bad compile, where this does not
happen. The compile turns good under the same modifications as before.
