[llvm] r199886 - Prevent repetitive warnings for unrecognized processors and features

[Sean Silva]

On Mon, Jan 27, 2014 at 12:12 PM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
>
> On Sat, Jan 25, 2014 at 9:33 AM, Artyom Skrobov <Artyom.Skrobov at arm.com>wrote:
>
>> > Our documentation is not very good surrounding some of these larger
>> > architectural issues. However, I can tell you with certainty that
>> > this patch is unacceptable in it's current state. Revert it.
>> >
>> > As David said, it violates a fundamental invariant of the LLVM
>> > codebase, which is that library users in the same process can
>> > independently use the LLVM library. (There are some unfortunate
>> > historical deviations from this that are being slowly mended,
>> > but going new code doesn't regress on this: it's not up for debate).
>>
>> Reverted as r200083, but I'd still appreciate any hints as to what can be
>> an
>> acceptable solution to the issue at hand (preventing the same warning from
>> being reported multiple times from multiple calling points).
>>
>
> While Sean and I are trying to provide feedback where we can, at least for
> myself (and I suspect Sean would agree) we're not necessarily the owners in
> any of these areas and are by no means an authority to say "this must be
> reverted" - I appreciate you reverting this to continue discussion.
>

Yeah, I have no "authority" over this code. However, I think that the rule
which this patch breaks is sufficiently universal that I can confidently
know the community consensus on this issue.

-- Sean Silva


>
> It'd probably be helpful if we had someone a little more "owner-y" to
> comment on how problematic this is, whether there's an obvious alternative,
> etc. I would guess Jim Grosbach, but not sure if he or others would be most
> helpful (the usual "how busy are they", "how knowledgable/authoritative are
> they", etc tradeoffs).
>
>
>> If the documentation doesn't guide around these larger architectural
>> issues,
>> and the existing code cannot be trusted as an example to follow, then the
>> only remaining option I can see is to submit patches at random, until one
>> of
>> them gets accepted.
>
>
> My naive question would be: what's unique about this argument handling
> that leads to duplicate error messages here but not for any other argument
> handling?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140128/dba8a683/attachment.html>