On 11/1/20 10:26 AM, Nikhil Benesch via Gcc-patches wrote: > > > On 11/1/20 6:57 AM, Eduard-Mihai Burtescu wrote: >> Reading the diff patch, the v0 changes look great. I wouldn't be too >> worried >> about the "printable character" aspect, there are similar >> Unicode-related >> issues elsewhere, e.g. the "non-control ASCII" comment in >> decode_legacy_escape >> (I suppose we could make it also go through the "print a non-control >> ASCII >> character or some escape sequence" logic you added, if you think that >> helps). > > No, it's entirely fine with me! I just wasn't sure if the small > deviations in output were acceptable. It sounds like they are.
So I think the best path forward is to let you and Eduard-Mihai make the technical decisions about what bits are ready for the trunk. When y'all think something is ready, let's go ahead and get it installed and iterate on things that aren't quite ready yet. For bits y'all think are ready, ISTM that Eduard-Mihai should commit the changes. >> I can test the patch and upload the dataset tomorrow, but if you want >> to get >> something committed sooner (is there a deadline for the next >> release?), feel >> free to land the v0 changes (snprintf + const values) without the >> legacy ones. > > My understanding is that the GCC tree closes to new features on > November 16 (for "GCC 11 Stage 3"), but I'm not sure whether that > applies to libiberty or whether this patch would be classified as a > feature or a bugfix. > > I don't have commit rights (nor am I even a GCC developer). Just > wanted to tee things up for you and Ian this week. I'm very much > looking forward to the new demangling scheme and didn't want to be > just another +1 on the GitHub issue. > > So certainly no time pressure from me. But perhaps someone from the > GCC side can confirm whether we are under a bit of time pressure here > given the GCC 11 release. It's better to get it in sooner, but there is some degree of freedom depending on the impact of the changes. Changes in the rust demangler aren't likely to trigger codegen or ABI breakages in the compiler itself -- so with that in mind I think we should give this code a higher degree of freedom to land after the stage1 close deadline. jeff
