widespread glibc bugs.

The glibc implementation of exp10 has a very serious precision bug in
version 2.15 (and older versions). This is still very widely used (the
current Ubuntu LTS for example uses it) and so it isn't reasonable to
make transforms that produce these functions. This fixes many
miscompiles introduced when we started transforming pow(10.0, ...) into
exp10, and it may have fixed other latent miscompiles where exp10
provided sufficient precision but exp10f did not.

This is all really horrible. The primary bug has been fixed for over
a year and glibc 2.18 works correctly for the test cases I have, but it
will be 2017 before the LTS using 2.15 is no longer supported by Ubuntu
(and thus reasonable for folks to be relying on). =[ We're either going
to need to live without these optimizations, or find a way to switch
behavior more dynamically than using simply the fact that the OS is
"Linux".

To make matters worse, there appears to be significant testing and
fixing of numerous other bugs in the exp10 family of functions right now
in glibc. While those haven't been causing problems I've seen in the
wild, it gives me concerns that we may need to wait until an even later
release of glibc before we can reliably transform code into exp10.

llvm-svn: 198093

just calling into MAI and is only abstracting for a single interface that
we actually need to check in multiple places.

llvm-svn: 198092

llvm-svn: 198091

llvm-svn: 198089

llvm-svn: 198088

This reduces the size of clang-format from 22 MB to 1.8 MB, diagtool goes from
21 MB to 2.8 MB, libclang.so goes from 29 MB to 20 MB, etc.  The size of the
bin/ folder shrinks from 270 MB to 200 MB.

Targets that support plugins and don't already use EXPORTED_SYMBOL_FILE
(which libclang and libLTO already do) can set NO_DEAD_STRIP to opt out.

llvm-svn: 198087

llvm-svn: 198086

No functionality change.

llvm-svn: 198085

ConstantSDNodes (or UNDEFs) into a simple BUILD_VECTOR.

For example, given the following sequence of dag nodes:

  i32 C = Constant<1>
  v4i32 V = BUILD_VECTOR C, C, C, C
  v4i32 Result = SIGN_EXTEND_INREG V, ValueType:v4i1

The SIGN_EXTEND_INREG node can be folded into a build_vector since
the vector in input is a BUILD_VECTOR of constants.

The optimized sequence is:

  i32 C = Constant<-1>
  v4i32 Result = BUILD_VECTOR C, C, C, C

llvm-svn: 198084

llvm-svn: 198083

Follows algorithm described here: http://msdn.microsoft.com/en-us/library/36k2cdd4.aspx

llvm-svn: 198082

llvm-svn: 198081

Most importantly, this makes our vtable layout match MSVC's.  Previously
we would emit a return adjusting thunk whenever the return types
differed, even if the adjustment would have been trivial.

MSVC does emit some trivial return adjusting thunks, but only if there
was already an overridden method that required a return adjustment.

llvm-svn: 198080

It's no longer necessary to lazily add members to the DICompositeType
member list. Instead any lazy members (special member functions and
member template instantiations) are added to the parent late based on
their context link, the same way that nested types have always been
handled (never being in the member list - just added to the parent DIE
lazily based on context).

Clang's been updated not to use this function anymore as it improves
type unit consistency by never emitting lazy members in type units.

llvm-svn: 198079

In an effort to reduce the likelihood of text getting out of sync, reusing the text from some diagnostics explicitly. No functional changes intended.

llvm-svn: 198078

Removed a string literal for a diagnostic, and updated the diagnostic to not manually quote. No functional changes intended.

llvm-svn: 198076

No functionality change.

llvm-svn: 198075

llvm-svn: 198074

Summary:
This is an alternative to http://llvm-reviews.chandlerc.com/D2475
suggested by Chandler.

Reviewers: chandlerc, rnk, dblaikie

CC: cfe-commits, earthdok

Differential Revision: http://llvm-reviews.chandlerc.com/D2478

llvm-svn: 198073

I'm not 100% sure but it looks like DLL entry symbol (DLL initializer function
name) should be _DllMainCRTStartup@12. The reason why I'm not very sure is
because I have no idea what "@12" suffix is, but without it the symbol won't
be resolved...

llvm-svn: 198072

Currently .drectve section contents are parsed after other sections are parsed.
That order may result in wrong results if other sections depend on command line
options in the directive section.

For example, if a weak symbol is defined using /alternatename option in the
directive section, we have to read it first and then read the text section
contents. Otherwise the weak symbol won't be defined.

This patch changes the order to fix the issue.

llvm-svn: 198071

Before:
  void aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(int aaaaaaaaaaaaaaaaaaaaaaaaaaaa =
                                              1);

After:
  void aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
      int aaaaaaaaaaaaaaaaaaaaaaaaaaaa = 1);

llvm-svn: 198070

much more clear to me. I meant to make this change before committing the
original patch, but forgot to merge it in. Sorry.

llvm-svn: 198069

This is an iterator which you can build around a MemoryBuffer. It will
iterate through the non-empty, non-comment lines of the buffer as
a forward iterator. It should be small and reasonably fast (although it
could be made much faster if anyone cares, I don't really...).

This will be used to more simply support the text-based sample
profile file format, and is largely based on the original patch by
Diego. I've re-worked the style of it and separated it from the work of
producing a MemoryBuffer from a file which both simplifies the interface
and makes it easier to test.

The style of the API follows the C++ standard naming conventions to fit
in better with iterators in general, much like the Path and FileSystem
interfaces follow standard-based naming conventions.

llvm-svn: 198068

There are many object files in the standard library who have empty .drective
sections. Parsing the empty string is not wrong but a waste.

llvm-svn: 198067

llvm-svn: 198066

Thisadds a new warning that warns on code like this:

  if (memcmp(a, b, sizeof(a) != 0))

The warning looks like:

test4.cc:5:30: warning: size argument in 'memcmp' call is a comparison [-Wmemsize-comparison]
  if (memcmp(a, b, sizeof(a) != 0))
                   ~~~~~~~~~~^~~~
test4.cc:5:7: note: did you mean to compare the result of 'memcmp' instead?
  if (memcmp(a, b, sizeof(a) != 0))
      ^                          ~
                            )
test4.cc:5:20: note: explicitly cast the argument to size_t to silence this warning
  if (memcmp(a, b, sizeof(a) != 0))
                   ^
                   (size_t)(     )
1 warning generated.

This found 2 bugs in chromium and has 0 false positives on both chromium and
llvm.

The idea of triggering this warning on a binop in the size argument is due to
rnk.

llvm-svn: 198063

llvm-svn: 198060

With pragma pack, the layout engine would produce vfptrs that were 
packed width rather than pointer width.  This patch addresses the issue 
and adds a test case.

llvm-svn: 198059

This makes it unavailable on NetBSD, Android, etc.

Patch by Brad Smith!

llvm-svn: 198056

Teach the diagnostics engine about the Attr type to make reporting on semantic attributes easier (and not require hard-coded strings). This requires a getSpelling() function on the Attr class, which is table-driven. Updates a handful of cases where a hard-coded string was being used to test the functionality out. Updating associated test cases for the improved quoting.

llvm-svn: 198055

Removed a string literal for an attribute name, which means the attribute name will be quoted in the diagnostic. Manually added some quotes to a diagnostic for consistency. Updated the test cases as appropriate.

llvm-svn: 198054

This diagnostic did not accept arguments, and did not have any test coverage. Parameterized the diagnostic, and made it more consistent with other attribute diagnostic wordings. Added test coverage.

Since this warning was generalized, it was also given a sensible warning group flag and the corresponding test was updated to reflect this.

llvm-svn: 198053

Thanks to Alp Toker for the naming suggestion!

llvm-svn: 198052

Simplifying some diagnostics so that they don't need to work with StringRefs. No functional changes intended.

llvm-svn: 198051

llvm-svn: 198050

llvm-svn: 198049

Fixes https://code.google.com/p/address-sanitizer/issues/detail?id=188.

llvm-svn: 198048

llvm-svn: 198047

Removing some unneeded code, and a diagnostic that was obsoleted. The type has already been determined to be a ValueDecl by virtue of the attribute subjects.

Added some test case coverage as well.

llvm-svn: 198046