This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 03/30/2017 02:24 PM, Jakub Jelinek wrote:
On Thu, Mar 30, 2017 at 10:21:09AM -0600, Martin Sebor wrote:I don't think rejecting all VLA initialization just to avoid an Asan ICE with string literals is a good way to solve the problem. For one, it will break working programs that rely onThe Asan ICE can be easily worked around, the reason I don't want to do that is that this is the second time this broke something; the FE should not pass a VLA static constant (STRING_CST in this case) to the middle-end, VLA objects can be by definition only automatic variables or something on the heap, never in the data/rodata sections. Plus, while for VLA initialized from arrays etc. we copy the initializer and zero initialize the rest, for VLA initialization by STRING_CST we just copy over the STRING_CST and the rest is uninitialized.
I agree that's a bug, one that should be fixed, but ion my view it's not serious enough to justify disabling the feature altogether. If every feature with a bug in it or that happens to trigger an ICE with some combination of command line options had to be disabled there wouldn't be much left. As I said, a patch that fixes this exists. I ran out of time to resubmit it for GCC 7 but I plan to do it for GCC 8. It be quite unfriendly to users to have GCC 7 reject working code that's accepted by GCC 6 only to have GCC 8 accept it again. I know you have concerns about the runtime costs of the patch and I'm willing to listen and work with you to minimize the performance impact. Martin
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |