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. > 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