Hi Luc, thank you once again! Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> writes: > On Mon, Jan 25, 2016 at 03:47:51PM +0100, Nicolai Stange wrote: >> This is the second attempt to clean up and improve sparse's handling >> of constant expressions. After I got some helpful reviews from >> Josh Triplett and Luc Van Oostenryck on my initial RFC series, I feel >> quite comfortable with this now and dropped the 'RFC' tag in favour of >> 'v2'. > > Great. > >> Quote from my initial 'RFC' cover letter regarding the structure of >> this series: >> >> This patch series is split into four parts: >> - The first part deals with the refactorization of the current integer >> constant expression handling and introduces some support for >> recognizing arithmetic expressions. [1-5/13] >> - The second part introduces support for recognizing address constants. >> [6/13] >> - The third part introduces a check for the constness of static storage >> duration objects' initializers. [7/13] >> - The last part stems from my tests with the kernel. It contains things >> I missed in the first [9-10/13] and second [8,12/13] parts and >> relaxes some of the constraints on constant expressions [11/13]. >> For the last patch [13/13], please see below. >> [...] >> Although the patches of the fourth part, the fixup part, fit very well >> into the first two categories, their associated testcases, if any, >> depend on [7/13]. Thus, I dediced to keep the order as is. > > Yes, it's fine. certainly so since you now added the -W flag. > I really consider your [13/13] as a totally separate patch > but it needs this series to see its effect. You're right, it somehow feels like it could go separately. However, it is strictly needed in this form or another in order to avoid false positives with -Wstatic-initializer-not-const (see the commit message of [13/13] for an example). Because of that, I'd prefer to keep it with this series. >> Quote end. >> >> >> The question from the initial 'RFC' series whether or not to relax the >> constexpr constraints, meaning that >> >> a difference of address constants may yield an integer constant >> >> in order to make the kernel's ACPI_OFFSET macro happy, is still >> unaddressed. However, if it turns out that we actually want to do so, >> this single issue can be easily handled by some follow up patch. > > Yes, indeed. > > > Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
