On 8/9/19 3:31 AM, Aleksandar Markovic wrote: > > > On Thu, Aug 8, 2019 at 5:43 PM Richard Henderson <richard.hender...@linaro.org > <mailto:richard.hender...@linaro.org>> wrote: > > On 8/8/19 4:41 AM, Aleksandar Markovic wrote: > > +/* > > + * Include the generated decoders. > > + * Note that the T32 decoder reuses some of the trans_* functions > > + * initially declared by the A32 decoder, which results in > duplicate > > + * declaration warnings. Suppress them. > > + */ > > + > > +#ifdef CONFIG_PRAGMA_DIAGNOSTIC_AVAILABLE > > +# pragma GCC diagnostic push > > +# pragma GCC diagnostic ignored "-Wredundant-decls" > > +# ifdef __clang__ > > +# pragma GCC diagnostic ignored "-Wtypedef-redefinition" > > +# endif > > +#endif > > + > > > > > > This looks more like a "band aid" solution rather than the right one. > > What would the "right" solution be, would you say? > > > The right (without quotation marks) solution is not to generate the code that > generates compiler complaints.
That would be impossible with the information supplied. Emitting zero declarations will result in invalid C. We ensure that each individual decodetree file does not emit duplicates. However, there is no knowledge across separate decodetree files about which declarations are duplicate. In this particular case, I do not even agree that the warnings themselves are useful. I suppose it's not impossible that they could diagnose some weirdness in a code base, where a function is declared in multiple headers or a patch application has gone awry leaving multiple sequential declarations, but honestly how often does that happen? I suppose with some work, we could not invoke decodetree multiple times, but give it all of the input files at once, producing a single output file. > Obviously, in this case, decodetree-generated code shows that it is > inferior to human-generated code. That is not obvious at all. Moreover, I disagree strongly. r~
