Merge commit 69d42eef4bec from llvm-project (by Dimitry Andric):

[Clang] Show type in enum out of range diagnostic

When the diagnostic for an out of range enum value is printed, it
currently

Merge commit 69d42eef4bec from llvm-project (by Dimitry Andric):

[Clang] Show type in enum out of range diagnostic

When the diagnostic for an out of range enum value is printed, it
currently does not show the actual enum type in question, for example:

v8/src/base/bit-field.h:43:29: error: integer value 7 is outside the valid range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
static constexpr T kMax = static_cast<T>(kNumValues - 1);
^

This can make it cumbersome to find the cause for the problem. Add the
enum type to the diagnostic message, to make it easier.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D152788

PR: 271047
MFC after: 1 month

show more ...

Apply clang fix for assertion failure building webkit2-gtk

Merge commit 30baa5d2a450 from llvm git (by Richard Smith):

PR45879: Fix assert when constant evaluating union assignment.

Consider t

Apply clang fix for assertion failure building webkit2-gtk

Merge commit 30baa5d2a450 from llvm git (by Richard Smith):

PR45879: Fix assert when constant evaluating union assignment.

Consider the form of the first operand of a class assignment not the
second operand when implicitly starting the lifetimes of union members.
Also add a missing check that the assignment call actually came from a
syntactic assignment, not from a direct call to `operator=`.

PR: 264280
Reported by: bapt
MFC after: 3 days

show more ...

r356104 | jhibbits | 2019-12-27 00:06:28 +0100 (Fri, 27 Dec 2019) | 25 lines

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:

r356104 | jhibbits | 2019-12-27 00:06:28 +0100 (Fri, 27 Dec 2019) | 25 lines

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free. At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check. According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.

On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.

This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.

Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: jhibbits, dim

Differential Revision: https://reviews.freebsd.org/D22549

show more ...

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtim

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free. At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check. According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.

On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.

This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.

Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: jhibbits, dim

Differential Revision: https://reviews.freebsd.org/D22549

show more ...

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That i

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.

Updating the vendor area to match this layout is next.

show more ...

Merge commit 69d42eef4bec from llvm-project (by Dimitry Andric):

[Clang] Show type in enum out of range diagnostic

When the diagnostic for an out of range enum value is printed, it
currently

Merge commit 69d42eef4bec from llvm-project (by Dimitry Andric):

[Clang] Show type in enum out of range diagnostic

When the diagnostic for an out of range enum value is printed, it
currently does not show the actual enum type in question, for example:

v8/src/base/bit-field.h:43:29: error: integer value 7 is outside the valid range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
static constexpr T kMax = static_cast<T>(kNumValues - 1);
^

This can make it cumbersome to find the cause for the problem. Add the
enum type to the diagnostic message, to make it easier.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D152788

PR: 271047
MFC after: 1 month

show more ...

Apply clang fix for assertion failure building webkit2-gtk

Merge commit 30baa5d2a450 from llvm git (by Richard Smith):

PR45879: Fix assert when constant evaluating union assignment.

Consider t

Apply clang fix for assertion failure building webkit2-gtk

Merge commit 30baa5d2a450 from llvm git (by Richard Smith):

PR45879: Fix assert when constant evaluating union assignment.

Consider the form of the first operand of a class assignment not the
second operand when implicitly starting the lifetimes of union members.
Also add a missing check that the assignment call actually came from a
syntactic assignment, not from a direct call to `operator=`.

PR: 264280
Reported by: bapt
MFC after: 3 days

show more ...

r356104 | jhibbits | 2019-12-27 00:06:28 +0100 (Fri, 27 Dec 2019) | 25 lines

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:

r356104 | jhibbits | 2019-12-27 00:06:28 +0100 (Fri, 27 Dec 2019) | 25 lines

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free. At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check. According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.

On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.

This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.

Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: jhibbits, dim

Differential Revision: https://reviews.freebsd.org/D22549

show more ...

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtim

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free. At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check. According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.

On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.

This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.

Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: jhibbits, dim

Differential Revision: https://reviews.freebsd.org/D22549

show more ...

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That i

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.

Updating the vendor area to match this layout is next.

show more ...

Merge commit 69d42eef4bec from llvm-project (by Dimitry Andric):

[Clang] Show type in enum out of range diagnostic

When the diagnostic for an out of range enum value is printed, it
currently

Merge commit 69d42eef4bec from llvm-project (by Dimitry Andric):

[Clang] Show type in enum out of range diagnostic

When the diagnostic for an out of range enum value is printed, it
currently does not show the actual enum type in question, for example:

v8/src/base/bit-field.h:43:29: error: integer value 7 is outside the valid range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
static constexpr T kMax = static_cast<T>(kNumValues - 1);
^

This can make it cumbersome to find the cause for the problem. Add the
enum type to the diagnostic message, to make it easier.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D152788

PR: 271047
MFC after: 1 month

show more ...

Apply clang fix for assertion failure building webkit2-gtk

Merge commit 30baa5d2a450 from llvm git (by Richard Smith):

PR45879: Fix assert when constant evaluating union assignment.

Consider t

Apply clang fix for assertion failure building webkit2-gtk

Merge commit 30baa5d2a450 from llvm git (by Richard Smith):

PR45879: Fix assert when constant evaluating union assignment.

Consider the form of the first operand of a class assignment not the
second operand when implicitly starting the lifetimes of union members.
Also add a missing check that the assignment call actually came from a
syntactic assignment, not from a direct call to `operator=`.

PR: 264280
Reported by: bapt
MFC after: 3 days

show more ...

r356104 | jhibbits | 2019-12-27 00:06:28 +0100 (Fri, 27 Dec 2019) | 25 lines

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:

r356104 | jhibbits | 2019-12-27 00:06:28 +0100 (Fri, 27 Dec 2019) | 25 lines

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free. At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check. According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.

On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.

This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.

Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: jhibbits, dim

Differential Revision: https://reviews.freebsd.org/D22549

show more ...

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtim

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free. At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check. According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.

On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.

This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.

Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: jhibbits, dim

Differential Revision: https://reviews.freebsd.org/D22549

show more ...

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That i

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.

Updating the vendor area to match this layout is next.

show more ...

Apply clang fix for assertion failure building webkit2-gtk

Merge commit 30baa5d2a450 from llvm git (by Richard Smith):

PR45879: Fix assert when constant evaluating union assignment.

Consider t

Apply clang fix for assertion failure building webkit2-gtk

Merge commit 30baa5d2a450 from llvm git (by Richard Smith):

PR45879: Fix assert when constant evaluating union assignment.

Consider the form of the first operand of a class assignment not the
second operand when implicitly starting the lifetimes of union members.
Also add a missing check that the assignment call actually came from a
syntactic assignment, not from a direct call to `operator=`.

PR: 264280
Reported by: bapt
MFC after: 3 days

show more ...

r356104 | jhibbits | 2019-12-27 00:06:28 +0100 (Fri, 27 Dec 2019) | 25 lines

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:

r356104 | jhibbits | 2019-12-27 00:06:28 +0100 (Fri, 27 Dec 2019) | 25 lines

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free. At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check. According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.

On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.

This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.

Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: jhibbits, dim

Differential Revision: https://reviews.freebsd.org/D22549

show more ...

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtim

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free. At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check. According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.

On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.

This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.

Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: jhibbits, dim

Differential Revision: https://reviews.freebsd.org/D22549

show more ...

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That i

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.

Updating the vendor area to match this layout is next.

show more ...

Apply clang fix for assertion failure building webkit2-gtk

Merge commit 30baa5d2a450 from llvm git (by Richard Smith):

PR45879: Fix assert when constant evaluating union assignment.

Consider t

Apply clang fix for assertion failure building webkit2-gtk

Merge commit 30baa5d2a450 from llvm git (by Richard Smith):

PR45879: Fix assert when constant evaluating union assignment.

Consider the form of the first operand of a class assignment not the
second operand when implicitly starting the lifetimes of union members.
Also add a missing check that the assignment call actually came from a
syntactic assignment, not from a direct call to `operator=`.

PR: 264280
Reported by: bapt
MFC after: 3 days

show more ...

r356104 | jhibbits | 2019-12-27 00:06:28 +0100 (Fri, 27 Dec 2019) | 25 lines

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:

r356104 | jhibbits | 2019-12-27 00:06:28 +0100 (Fri, 27 Dec 2019) | 25 lines

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free. At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check. According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.

On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.

This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.

Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: jhibbits, dim

Differential Revision: https://reviews.freebsd.org/D22549

show more ...

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtim

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free. At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check. According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.

On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.

This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.

Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: jhibbits, dim

Differential Revision: https://reviews.freebsd.org/D22549

show more ...

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That i

Move all sources from the llvm project into contrib/llvm-project.

This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.

Updating the vendor area to match this layout is next.

show more ...

Apply clang fix for assertion failure building webkit2-gtk

Merge commit 30baa5d2a450 from llvm git (by Richard Smith):

PR45879: Fix assert when constant evaluating union assignment.

Consider t

Apply clang fix for assertion failure building webkit2-gtk

Merge commit 30baa5d2a450 from llvm git (by Richard Smith):

PR45879: Fix assert when constant evaluating union assignment.

Consider the form of the first operand of a class assignment not the
second operand when implicitly starting the lifetimes of union members.
Also add a missing check that the assignment call actually came from a
syntactic assignment, not from a direct call to `operator=`.

PR: 264280
Reported by: bapt
MFC after: 3 days

show more ...

r356104 | jhibbits | 2019-12-27 00:06:28 +0100 (Fri, 27 Dec 2019) | 25 lines

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:

r356104 | jhibbits | 2019-12-27 00:06:28 +0100 (Fri, 27 Dec 2019) | 25 lines

[PowerPC] enable atomic.c in compiler_rt and do not check and forces
lock/lock_free decisions in compiled time

Summary:
Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime
decision about lock/lock_free. At compiling time, if clang can't decide if
atomic operation can be lock free, it emits calls to external functions like
`__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and
`__atomic_always_lock_free`, postponing decision to a runtime check. According
to LLVM code documentation, the mechanism exists due to differences between
x86_64 processors that can't be decided at runtime.

On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock
free, so we force the decision at compile time and avoid having to implement it
in an external library.

This patch was made after 32 bit users testing the PowePC32 bit ISO reported
llvm could not be compiled with in-base llvm due to `__atomic_load8` not
implemented.

Submitted by: alfredo.junior_eldorado.org.br
Reviewed by: jhibbits, dim

Differential Revision: https://reviews.freebsd.org/D22549

show more ...