On Fri, Aug 19, 2016 at 8:29 AM, Martin Sebor <mse...@gmail.com> wrote: >> My biggest concern with this iteration is the tight integration between >> the optimization and warning. We generally avoid that kind of tight >> integration such that enabling the warning does not affect the >> optimization and vice-versa. >> >> So ISTM you have to do the analysis if the optimization or warning has >> been requested. Then you conditionalize whether or not the warnings are >> emitted by their flag and the optimization based on its flag. > > > As we discussed in IRC yesterday, the warning and the optimization > are independent of one another, and each controlled by its own option > (-Wformat-length and -fprintf-return-value). In light of that we've > agreed that submitting both as part of the same patch is sufficient. > >> >> I understand you're going to have some further work to do because of >> conflicts with David's patches. With that in mind, I'd suggest a bit of >> carving things up so things can start moving forward. >> >> >> Patch #1. All the fixes to static buffer sizes that were inspired by >> your warning. These are all approved and can go in immediately. > > > Attached is this patch.
Hi, this patch changed the file gcc/go/gofrontend/expressions.cc. As described in gcc/go/gofrontend/README, the files in the directory gcc/go/gofrontend should not be changed in the GCC repository. Instead, they are mirrored into GCC from a separate repository, https://go.googlesource.com/gofrontend . When you need to make changes in the gofrontend directory, you can either follow the contribution process described as https://golang.org/doc/gccgo_contribute.html, or simply ask me to make the change. Thanks. Ian
