maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Headers/stdbool.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

26 lines
1021 B
C++
Raw Normal View History

Add -fgnuc-version= to control __GNUC__ and other GCC macros I noticed that compiling on Windows with -fno-ms-compatibility had the side effect of defining __GNUC__, along with __GNUG__, __GXX_RTTI__, and a number of other macros for GCC compatibility. This is undesirable and causes Chromium to do things like mix __attribute__ and __declspec, which doesn't work. We should have a positive language option to enable GCC compatibility features so that we can experiment with -fno-ms-compatibility on Windows. This change adds -fgnuc-version= to be that option. My issue aside, users have, for a long time, reported that __GNUC__ doesn't match their expectations in one way or another. We have encouraged users to migrate code away from this macro, but new code continues to be written assuming a GCC-only environment. There's really nothing we can do to stop that. By adding this flag, we can allow them to choose their own adventure with __GNUC__. This overlaps a bit with the "GNUMode" language option from -std=gnu*. The gnu language mode tends to enable non-conforming behaviors that we'd rather not enable by default, but the we want to set things like __GXX_RTTI__ by default, so I've kept these separate. Helps address PR42817 Reviewed By: hans, nickdesaulniers, MaskRay Differential Revision: https://reviews.llvm.org/D68055 llvm-svn: 374449
2019-10-11 05:04:25 +08:00
// RUN: %clang_cc1 -fgnuc-version=4.2.1 -std=gnu++98 -E -dM %s | FileCheck --check-prefix=CHECK-GNU-COMPAT-98 %s
// RUN: %clang_cc1 -fgnuc-version=4.2.1 -std=gnu++11 -E -dM %s | FileCheck --check-prefix=CHECK-GNU-COMPAT-11 %s
// RUN: %clang_cc1 -fgnuc-version=4.2.1 -std=c++98 -E -dM %s | FileCheck --check-prefix=CHECK-CONFORMING %s
// RUN: %clang_cc1 -fgnuc-version=4.2.1 -fsyntax-only -std=gnu++98 -verify -Weverything %s
Define _Bool, bool, true, and false macros in <stdbool.h> when we're in a GNU-compatible C++ dialect. Fixes <rdar://problem/8477819>. llvm-svn: 115028
2010-09-29 12:57:11 +08:00
#include <stdbool.h>
#define zzz
In stdbool.h, define bool, false, true only in gnu++98 GCC has meanwhile corrected that with the similar <https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=216679> "C++11 explicitly forbids macros for bool, true and false." Differential Revision: https://reviews.llvm.org/D40167 llvm-svn: 320135
2017-12-08 16:28:08 +08:00
// CHECK-GNU-COMPAT-98: #define _Bool bool
// CHECK-GNU-COMPAT-98: #define bool bool
// CHECK-GNU-COMPAT-98: #define false false
// CHECK-GNU-COMPAT-98: #define true true
// CHECK-GNU-COMPAT-11: #define _Bool bool
// CHECK-GNU-COMPAT-11-NOT: #define bool bool
// CHECK-GNU-COMPAT-11-NOT: #define false false
// CHECK-GNU-COMPAT-11-NOT: #define true true
Define _Bool, bool, true, and false macros in <stdbool.h> when we're in a GNU-compatible C++ dialect. Fixes <rdar://problem/8477819>. llvm-svn: 115028
2010-09-29 12:57:11 +08:00
// CHECK-CONFORMING-NOT: #define _Bool
// CHECK-CONFORMING: #define __CHAR_BIT__
// CHECK-CONFORMING-NOT: #define false false
// CHECK-CONFORMING: #define zzz
Reinstate r173952, this time limiting it to exactly the form #define X X for which there is no point warning, ever. llvm-svn: 173991
2013-01-31 07:10:17 +08:00
zzz
// expected-no-diagnostics
extern bool x;