<div dir="ltr">FYI, this is landed in r298491; thanks for the reviews.<div><br></div><div>I'm hoping to have papers for standards bodies (and also useful for libc maintainers) by next week.</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Mar 18, 2017 at 2:36 AM Philip Reames <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
    <div class="m_8972152876394780548moz-cite-prefix gmail_msg">I'm in support of unblocking the LLVM
      side optimization changes.  I'm definitely not qualified to speak
      towards the direction of the clang changes though.  :)</div></div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg"><div class="m_8972152876394780548moz-cite-prefix gmail_msg"><br class="gmail_msg">
      <br class="gmail_msg">
      Philip</div></div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg"><div class="m_8972152876394780548moz-cite-prefix gmail_msg"><br class="gmail_msg">
      <br class="gmail_msg">
      On 03/16/2017 03:39 PM, Chandler Carruth via cfe-dev wrote:<br class="gmail_msg">
    </div></div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
    <blockquote type="cite" class="gmail_msg">
      <div dir="ltr" class="gmail_msg">Are there blockers to landing <a href="https://reviews.llvm.org/D30806" class="gmail_msg" target="_blank">https://reviews.llvm.org/D30806</a> ?
        <div class="gmail_msg"><br class="gmail_msg">
        </div>
        <div class="gmail_msg">I'm committed to following through with the respective
          standards bodies and anyone else we feel is prudent, but I
          would somewhat like to unblock the optimization work in this
          area in parallel as I suspect that the communication and
          establishment of a rational plan will require a lot of time.</div>
      </div>
      <br class="gmail_msg">
      <div class="gmail_quote gmail_msg">
        <div dir="ltr" class="gmail_msg">On Tue, Mar 14, 2017 at 2:54 PM Chandler Carruth
          via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a>>
          wrote:<br class="gmail_msg">
        </div>
        <blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div dir="ltr" class="gmail_msg">I'm happy to handle at least
            the standards side of this; I don't really have great
            connections on the libc front, but happy to help folks do
            that.</div>
          <br class="gmail_msg">
          <div class="gmail_quote gmail_msg">
            <div dir="ltr" class="gmail_msg">On Tue, Mar 14, 2017 at
              2:35 PM James Y Knight <<a href="mailto:jyknight@google.com" class="gmail_msg" target="_blank">jyknight@google.com</a>> wrote:<br class="gmail_msg">
            </div>
            <blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir="ltr" class="gmail_msg">
                <div class="gmail_extra gmail_msg">
                  <div class="gmail_quote gmail_msg">Just to
                    reiterate...</div>
                  <div class="gmail_quote gmail_msg"><br class="gmail_msg">
                  </div>
                  <div class="gmail_quote gmail_msg">I would really like
                    to see us communicate this decision, with an
                    appropriately persuasive argument, both to the glibc
                    authors and to the standards committees, and treat
                    this as a *transitional* hack, which is needed until
                    glibc (and any other libc if there are any?) can
                    remove the erroneous nonnull declarations from their
                    headers, and everyone has upgraded.</div>
                </div>
              </div>
              <div dir="ltr" class="gmail_msg">
                <div class="gmail_extra gmail_msg">
                  <div class="gmail_quote gmail_msg"><br class="gmail_msg">
                  </div>
                  <div class="gmail_quote gmail_msg">On Thu, Mar 9, 2017
                    at 11:04 PM, Chandler Carruth <span dir="ltr" class="gmail_msg"><<a href="mailto:chandlerc@google.com" class="gmail_msg" target="_blank">chandlerc@google.com</a>></span>
                    wrote:<br class="gmail_msg">
                    <blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      <div dir="ltr" class="gmail_msg">I've sent a patch
                        to implement this here: <a href="https://reviews.llvm.org/D30806" class="gmail_msg" target="_blank">https://reviews.llvm.org/D30806</a>
                        <div class="gmail_msg"><br class="gmail_msg">
                        </div>
                        <div class="gmail_msg">It turns out to be both
                          easier and I hope less controversial than I
                          had imagined. Neither Clang nor LLVM ever
                          actually got nonnull onto these declarations
                          even when they were suitable annotated. We
                          didn't carry that annotation across to the
                          declaration. Oops.</div>
                        <div class="gmail_msg"><br class="gmail_msg">
                        </div>
                        <div class="gmail_msg">So I've fixed that, but
                          *also* disabled it for the libc functions that
                          we have library builtin recognition for. We
                          can extend this to cover any set of library
                          functions folks want, just let me know. The
                          use of it will even be correctly controlled by
                          -fno-builtin and friends.</div>
                        <div class="gmail_msg"><br class="gmail_msg">
                        </div>
                        <div class="gmail_msg">The net result is that
                          this should not regress optimizations for
                          *anyone*, and actually enable a bunch of
                          optimizations outside of libc functions, while
                          preserving safety on those libc functions.</div>
                        <div class="gmail_msg"><br class="gmail_msg">
                        </div>
                        <div class="gmail_msg">We still have the
                          nullability attributes which can be used to
                          annotate more interfaces in a way that will
                          provide warnings and static analysis aid, but
                          not optimize on and so not run the risk of
                          changing behavior of existing code. Those
                          would be good candidates (IMO) for libc++ to
                          use on any relevant interfaces which match the
                          criteria outlined in this thread: pointers
                          paired with a size should allow null+zero.</div>
                        <div class="gmail_msg"><br class="gmail_msg">
                        </div>
                        <div class="gmail_msg">Hopefully this makes
                          everyone happy, please feel free to chime in
                          on the review thread if more discussion is
                          needed.</div>
                      </div>
                      <br class="gmail_msg">
                      <div class="gmail_quote gmail_msg">
                        <div class="gmail_msg">
                          <div class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753h5 gmail_msg">
                            <div dir="ltr" class="gmail_msg">On Wed, Jan
                              4, 2017 at 11:24 AM Aaron Ballman via
                              cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a>>
                              wrote:<br class="gmail_msg">
                            </div>
                          </div>
                        </div>
                        <blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                          <div class="gmail_msg">
                            <div class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753h5 gmail_msg">On Wed, Jan 4, 2017 at 2:01 PM,
                              James Y Knight <<a href="mailto:jyknight@google.com" class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg" target="_blank">jyknight@google.com</a>>
                              wrote:<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              ><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              ><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > On Wed, Jan 4, 2017 at 12:54 PM, Hal
                              Finkel <<a href="mailto:hfinkel@anl.gov" class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg" target="_blank">hfinkel@anl.gov</a>>
                              wrote:<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >> On 01/04/2017 11:43 AM, James Y
                              Knight via cfe-dev wrote:<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >> On Wed, Jan 4, 2017 at 11:12 AM,
                              Aaron Ballman via cfe-dev<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >> <<a href="mailto:cfe-dev@lists.llvm.org" class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a>>
                              wrote:<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >>><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >>> So I would be opposed to
                              ignoring those attributes in<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >>><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >>> Sema (I think we should still
                              warn when users do nonportable things),<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >>> but in favor of not changing
                              the optimizer to capitalize on this<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >>> "opportunity."<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >> I'd be opposed to ignoring the
                              attributes only in some places and not in<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >> others. It should be ignored
                              totally, as if it wasn't present on those<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >> functions. Doing anything else
                              sends the wrong message -- that libc
                              authors<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >> should continue to use nonnull on
                              these functions because they might be<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >> helpful, and won't do anything
                              bad.<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >> I think that we have a
                              responsibility to our users to continue to
                              warn<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >> (statically, in ubsan, etc.) on
                              non-portable behavior, which this is and<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >> will continue to be in practice
                              for at least a decade or two, regardless
                              of<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >> the message we'd like to send
                              libc authors. We cannot undo history here
                              and<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >> this will be relevant to
                              production systems for at least a decade.
                              We can<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >> talk to libc developers directly
                              -- they're a much smaller set -- and we
                              can<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >> pursue change at the standards
                              level while still providing the most
                              useful<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              >> set of tools to our users in the
                              mean time.<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              ><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              ><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > But, this is an entirely different
                              question.<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              ><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > - Should clang warn about
                              non-portable usage of passing NULL to
                              memcpy/etc?<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              ><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > Sounds like a fine warning to add.<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              ><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > - Should that warning be dependent on
                              the libc headers having nonnull<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > annotations on these functions, which
                              will be used only for warnings, and<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > ignored for semantics, on this given
                              list of hardcoded functions?<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              ><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > No.<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              ><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > Firstly: I'd note that nearly all
                              libc implementations don't use these<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > attributes today. In some cases,
                              because they've simply not thought about<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > it, but in others because they
                              explicitly decided to NOT break their
                              users'<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > code by introducing this problem!
                              Glibc is the outlier, here.<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              ><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > So: what portability do you want to
                              warn for? Portability assuming the same<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > libc, but a different compiler which
                              might fail to ignore the nonnull<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > attribute? Or portability to other
                              libc? If the latter, depending on the<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > nonnull attribute being present
                              doesn't and can't work.<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              <br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              My preference is for portability for both,
                              but you bring up a good<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              point about other libc implementations not
                              being annotated. So long as<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              we retain the ability to tell users their
                              code is not portable *and*<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              we get rid of the dangerous optimizations,
                              I'm happy. I just don't<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              want to lose the diagnostics because of
                              the optimizations.<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              <br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              ~Aaron<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              <br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > Secondly: if we already have a
                              hardcoded list of functions to special
                              case,<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > that could just as well be used to
                              generate a nonportable-stringfunc-null<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                              > warning, as well.<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                            </div>
                          </div>
                          <span class="gmail_msg">
_______________________________________________<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                            cfe-dev mailing list<br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                            <a href="mailto:cfe-dev@lists.llvm.org" class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                            <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="m_8972152876394780548m_8087689980988160966m_-1348109265394321626m_5255863683635004753m_-8502790148464743892gmail_msg gmail_msg">
                          </span></blockquote>
                      </div>
                    </blockquote>
                  </div>
                  <br class="gmail_msg">
                </div>
              </div>
            </blockquote>
          </div>
          _______________________________________________<br class="gmail_msg">
          cfe-dev mailing list<br class="gmail_msg">
          <a href="mailto:cfe-dev@lists.llvm.org" class="gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a><br class="gmail_msg">
          <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="gmail_msg">
        </blockquote>
      </div>
      <br class="gmail_msg">
      <fieldset class="m_8972152876394780548mimeAttachmentHeader gmail_msg"></fieldset>
      <br class="gmail_msg">
      <pre class="gmail_msg">_______________________________________________
cfe-dev mailing list
<a class="m_8972152876394780548moz-txt-link-abbreviated gmail_msg" href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
<a class="m_8972152876394780548moz-txt-link-freetext gmail_msg" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
    </blockquote>
    <p class="gmail_msg"><br class="gmail_msg">
    </p>
  </div></blockquote></div>