On Fri, Dec 15, 2017 at 4:40 AM, Martin Sebor <mse...@gmail.com> wrote: > On 12/07/2017 03:48 PM, Jeff Law wrote: >> >> On 12/07/2017 03:38 PM, Richard Sandiford wrote: >> >>>> So I think that's the final ack on this series. >>> >>> >>> Thanks to both of you, really appreciate it! >> >> Sorry it took so long. >> >>> >>>> Richard S. can you confirm? I fully expect the trunk has moved some >>>> and the patches will need adjustments -- consider adjustments which >>>> work in a manner similar to the patches to date pre-approved. >>> >>> >>> Yeah, that's now all of the poly_int patches. I still owe you replies >>> to some of them -- I'll get to that as soon as I can. >> >> NP. I don't think any of the questions were all that significant. >> Those which were I think you already responded to. > > > I am disappointed that the no-op ctor issue hasn't been adequately > addressed. No numbers were presented as to the difference it makes > to have the ctor do the expected thing (i.e., initialize the object). > In my view, the choice seems arbitrarily in favor of a hypothetical > performance improvement at -O0 without regard to the impact on > correctness. We have recently seen the adverse effects of similar > choices in other areas: the hash table insertion[*] and the related > offset_int initialization.
As were coming from a C code base not initializing stuff is what I expect. I'm really surprised to see lot of default initialization done in places where it only hurts compile-time (of GCC at least where we need to optimize that away). Richard. > Martin > > [*] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82977 > > PS To be clear, the numbers I asked for were those showing > the difference between a no-op ctor and one that initializes > the object to some determinate state, whatever that is. IIUC > the numbers in the following post show the aggregate slowdown > for many or most of the changes in the series, not just > the ctor. If the numbers were significant, I suggested > a solution to explicitly request a non-op ctor to make > the default safe and eliminate the overhead where it mattered. > > https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01028.html
