[PATCH] D41073: Wasm: add support in libcxx
ncw updated this revision to Diff 127242. ncw added a comment. Herald added a subscriber: krytarowski. Although Dan has already reviewed, I've sneakily added in another change here to help compilation against Musl. Musl is Linux-only, or rather, provides the linux ABI. For Wasm, `__linux` isn't defined but if we're using Musl then we can provide ELAST and get rid of the associated warnings. Musl is definitely wedded to the 4096 errno limit that's part of the Linux ABI, so I believe this change is safe. Repository: rCXX libc++ https://reviews.llvm.org/D41073 Files: include/__config src/include/config_elast.h Index: src/include/config_elast.h === --- src/include/config_elast.h +++ src/include/config_elast.h @@ -24,7 +24,7 @@ #define _LIBCPP_ELAST __ELASTERROR #elif defined(__Fuchsia__) // No _LIBCPP_ELAST needed on Fuchsia -#elif defined(__linux__) +#elif defined(__linux__) || defined(_LIBCPP_HAS_MUSL_LIBC) #define _LIBCPP_ELAST 4095 #elif defined(__APPLE__) // No _LIBCPP_ELAST needed on Apple Index: include/__config === --- include/__config +++ include/__config @@ -45,6 +45,8 @@ #define _LIBCPP_OBJECT_FORMAT_MACHO 1 #elif defined(_WIN32) #define _LIBCPP_OBJECT_FORMAT_COFF 1 +#elif defined(__wasm__) +#define _LIBCPP_OBJECT_FORMAT_WASM 1 #else #error Unknown object file format #endif Index: src/include/config_elast.h === --- src/include/config_elast.h +++ src/include/config_elast.h @@ -24,7 +24,7 @@ #define _LIBCPP_ELAST __ELASTERROR #elif defined(__Fuchsia__) // No _LIBCPP_ELAST needed on Fuchsia -#elif defined(__linux__) +#elif defined(__linux__) || defined(_LIBCPP_HAS_MUSL_LIBC) #define _LIBCPP_ELAST 4095 #elif defined(__APPLE__) // No _LIBCPP_ELAST needed on Apple Index: include/__config === --- include/__config +++ include/__config @@ -45,6 +45,8 @@ #define _LIBCPP_OBJECT_FORMAT_MACHO 1 #elif defined(_WIN32) #define _LIBCPP_OBJECT_FORMAT_COFF 1 +#elif defined(__wasm__) +#define _LIBCPP_OBJECT_FORMAT_WASM 1 #else #error Unknown object file format #endif ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D41941: [WebAssembly] Change int_fast16_t to 32-bit
ncw created this revision. ncw added reviewers: sunfish, dschuff. Herald added subscribers: cfe-commits, aheejin, jgravelle-google, sbc100, jfb. See: https://bugs.llvm.org/show_bug.cgi?id=35582 Since Wasm has to use 32-to-16 bit instructions to narrow values down, 32-bit should be a tad faster for operations needing 16 or more bits. Repository: rC Clang https://reviews.llvm.org/D41941 Files: lib/Basic/Targets/WebAssembly.h test/Preprocessor/init.c Index: test/Preprocessor/init.c === --- test/Preprocessor/init.c +++ test/Preprocessor/init.c @@ -9166,10 +9166,10 @@ // WEBASSEMBLY32-NEXT:#define __INTPTR_MAX__ 2147483647 // WEBASSEMBLY32-NEXT:#define __INTPTR_TYPE__ int // WEBASSEMBLY32-NEXT:#define __INTPTR_WIDTH__ 32 -// WEBASSEMBLY32-NEXT:#define __INT_FAST16_FMTd__ "hd" -// WEBASSEMBLY32-NEXT:#define __INT_FAST16_FMTi__ "hi" -// WEBASSEMBLY32-NEXT:#define __INT_FAST16_MAX__ 32767 -// WEBASSEMBLY32-NEXT:#define __INT_FAST16_TYPE__ short +// WEBASSEMBLY32-NEXT:#define __INT_FAST16_FMTd__ "d" +// WEBASSEMBLY32-NEXT:#define __INT_FAST16_FMTi__ "i" +// WEBASSEMBLY32-NEXT:#define __INT_FAST16_MAX__ 2147483647 +// WEBASSEMBLY32-NEXT:#define __INT_FAST16_TYPE__ int // WEBASSEMBLY32-NEXT:#define __INT_FAST32_FMTd__ "d" // WEBASSEMBLY32-NEXT:#define __INT_FAST32_FMTi__ "i" // WEBASSEMBLY32-NEXT:#define __INT_FAST32_MAX__ 2147483647 @@ -9182,10 +9182,10 @@ // WEBASSEMBLY32-NEXT:#define __INT_FAST8_FMTi__ "hhi" // WEBASSEMBLY32-NEXT:#define __INT_FAST8_MAX__ 127 // WEBASSEMBLY32-NEXT:#define __INT_FAST8_TYPE__ signed char -// WEBASSEMBLY32-NEXT:#define __INT_LEAST16_FMTd__ "hd" -// WEBASSEMBLY32-NEXT:#define __INT_LEAST16_FMTi__ "hi" -// WEBASSEMBLY32-NEXT:#define __INT_LEAST16_MAX__ 32767 -// WEBASSEMBLY32-NEXT:#define __INT_LEAST16_TYPE__ short +// WEBASSEMBLY32-NEXT:#define __INT_LEAST16_FMTd__ "d" +// WEBASSEMBLY32-NEXT:#define __INT_LEAST16_FMTi__ "i" +// WEBASSEMBLY32-NEXT:#define __INT_LEAST16_MAX__ 2147483647 +// WEBASSEMBLY32-NEXT:#define __INT_LEAST16_TYPE__ int // WEBASSEMBLY32-NEXT:#define __INT_LEAST32_FMTd__ "d" // WEBASSEMBLY32-NEXT:#define __INT_LEAST32_FMTi__ "i" // WEBASSEMBLY32-NEXT:#define __INT_LEAST32_MAX__ 2147483647 @@ -9312,12 +9312,12 @@ // WEBASSEMBLY32-NEXT:#define __UINTPTR_MAX__ 4294967295U // WEBASSEMBLY32-NEXT:#define __UINTPTR_TYPE__ unsigned int // WEBASSEMBLY32-NEXT:#define __UINTPTR_WIDTH__ 32 -// WEBASSEMBLY32-NEXT:#define __UINT_FAST16_FMTX__ "hX" -// WEBASSEMBLY32-NEXT:#define __UINT_FAST16_FMTo__ "ho" -// WEBASSEMBLY32-NEXT:#define __UINT_FAST16_FMTu__ "hu" -// WEBASSEMBLY32-NEXT:#define __UINT_FAST16_FMTx__ "hx" -// WEBASSEMBLY32-NEXT:#define __UINT_FAST16_MAX__ 65535 -// WEBASSEMBLY32-NEXT:#define __UINT_FAST16_TYPE__ unsigned short +// WEBASSEMBLY32-NEXT:#define __UINT_FAST16_FMTX__ "X" +// WEBASSEMBLY32-NEXT:#define __UINT_FAST16_FMTo__ "o" +// WEBASSEMBLY32-NEXT:#define __UINT_FAST16_FMTu__ "u" +// WEBASSEMBLY32-NEXT:#define __UINT_FAST16_FMTx__ "x" +// WEBASSEMBLY32-NEXT:#define __UINT_FAST16_MAX__ 4294967295U +// WEBASSEMBLY32-NEXT:#define __UINT_FAST16_TYPE__ unsigned int // WEBASSEMBLY32-NEXT:#define __UINT_FAST32_FMTX__ "X" // WEBASSEMBLY32-NEXT:#define __UINT_FAST32_FMTo__ "o" // WEBASSEMBLY32-NEXT:#define __UINT_FAST32_FMTu__ "u" @@ -9336,12 +9336,12 @@ // WEBASSEMBLY32-NEXT:#define __UINT_FAST8_FMTx__ "hhx" // WEBASSEMBLY32-NEXT:#define __UINT_FAST8_MAX__ 255 // WEBASSEMBLY32-NEXT:#define __UINT_FAST8_TYPE__ unsigned char -// WEBASSEMBLY32-NEXT:#define __UINT_LEAST16_FMTX__ "hX" -// WEBASSEMBLY32-NEXT:#define __UINT_LEAST16_FMTo__ "ho" -// WEBASSEMBLY32-NEXT:#define __UINT_LEAST16_FMTu__ "hu" -// WEBASSEMBLY32-NEXT:#define __UINT_LEAST16_FMTx__ "hx" -// WEBASSEMBLY32-NEXT:#define __UINT_LEAST16_MAX__ 65535 -// WEBASSEMBLY32-NEXT:#define __UINT_LEAST16_TYPE__ unsigned short +// WEBASSEMBLY32-NEXT:#define __UINT_LEAST16_FMTX__ "X" +// WEBASSEMBLY32-NEXT:#define __UINT_LEAST16_FMTo__ "o" +// WEBASSEMBLY32-NEXT:#define __UINT_LEAST16_FMTu__ "u" +// WEBASSEMBLY32-NEXT:#define __UINT_LEAST16_FMTx__ "x" +// WEBASSEMBLY32-NEXT:#define __UINT_LEAST16_MAX__ 4294967295U +// WEBASSEMBLY32-NEXT:#define __UINT_LEAST16_TYPE__ unsigned int // WEBASSEMBLY32-NEXT:#define __UINT_LEAST32_FMTX__ "X" // WEBASSEMBLY32-NEXT:#define __UINT_LEAST32_FMTo__ "o" // WEBASSEMBLY32-NEXT:#define __UINT_LEAST32_FMTu__ "u" @@ -9498,10 +9498,10 @@ // WEBASSEMBLY64-NEXT:#define __INTPTR_MAX__ 9223372036854775807L // WEBASSEMBLY64-NEXT:#define __INTPTR_TYPE__ long int // WEBASSEMBLY64-NEXT:#define __INTPTR_WIDTH__ 64 -// WEBASSEMBLY64-NEXT:#define __INT_FAST16_FMTd__ "hd" -// WEBASSEMBLY64-NEXT:#define __INT_FAST16_FMTi__ "hi" -// WEBASSEMBLY64-NEXT:#define __INT_FAST16_MAX__ 32767 -// WEBASSEMBLY64-NEXT:#define __INT_FAST16_TYPE__ short +// WEBASSEMBLY64-NEXT:#define __INT_FAST16_FMTd__ "d" +// WEBASSEMBLY64-NEXT:#define __INT_FAST16_FMTi__ "i" +// WEBASSEMBLY64-NEXT:#define __INT_FAST16_MAX__ 2147
[PATCH] D41941: [WebAssembly] Change int_fast16_t to 32-bit
ncw added inline comments.
Comment at: lib/Basic/Targets/WebAssembly.h:108
IntType getLeastIntTypeByWidth(unsigned BitWidth, bool IsSigned) const final
{
-// WebAssembly uses long long for int_least64_t and int_fast64_t.
-return BitWidth == 64
+// WebAssembly uses long long for int_least64_t and int_fast64_t, and int
+// for int_least16_t and int_fast16_t.
dschuff wrote:
> I think we want least16_t to still be short, no? We do still support 16-bit
> shorts, so my interpretation is that the smallest type with width of at least
> 16 should still be 16.
...is there a way to do that? I couldn't find any other archs that do it; it
seems like the stdint.h that Clang provides requires least16_t to match
fast16_t. I copied this from the AVR target, although maybe that doesn't
support 16-bit at all.
Repository:
rC Clang
https://reviews.llvm.org/D41941
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D41941: [WebAssembly] Change int_fast16_t to 32-bit
ncw added inline comments.
Comment at: lib/Basic/Targets/WebAssembly.h:108
IntType getLeastIntTypeByWidth(unsigned BitWidth, bool IsSigned) const final
{
-// WebAssembly uses long long for int_least64_t and int_fast64_t.
-return BitWidth == 64
+// WebAssembly uses long long for int_least64_t and int_fast64_t, and int
+// for int_least16_t and int_fast16_t.
ncw wrote:
> dschuff wrote:
> > I think we want least16_t to still be short, no? We do still support 16-bit
> > shorts, so my interpretation is that the smallest type with width of at
> > least 16 should still be 16.
> ...is there a way to do that? I couldn't find any other archs that do it; it
> seems like the stdint.h that Clang provides requires least16_t to match
> fast16_t. I copied this from the AVR target, although maybe that doesn't
> support 16-bit at all.
Sorry, now I see that AVR uses int because it has 16-bit ints...
There isn't any existing Clang target that uses 32-bit for fast16_t, so maybe
it's currently not possible within Clang's framework (or at least, not without
also fiddling with least16_t). `lib/Frontend/InitPreprocessor.cpp` hardcodes
some logic with sets them to be the same.
I can abandon this review if that's not acceptable collateral damage (probably
not, on reflection) - or could tweak InitPreprocessor.cpp and stdint.h to be
more flexible (might need more review if you don't "own" those files?)
Repository:
rC Clang
https://reviews.llvm.org/D41941
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D41941: [WebAssembly] Change int_fast16_t to 32-bit
ncw added inline comments.
Comment at: lib/Basic/Targets/WebAssembly.h:108
IntType getLeastIntTypeByWidth(unsigned BitWidth, bool IsSigned) const final
{
-// WebAssembly uses long long for int_least64_t and int_fast64_t.
-return BitWidth == 64
+// WebAssembly uses long long for int_least64_t and int_fast64_t, and int
+// for int_least16_t and int_fast16_t.
dschuff wrote:
> ncw wrote:
> > ncw wrote:
> > > dschuff wrote:
> > > > I think we want least16_t to still be short, no? We do still support
> > > > 16-bit shorts, so my interpretation is that the smallest type with
> > > > width of at least 16 should still be 16.
> > > ...is there a way to do that? I couldn't find any other archs that do it;
> > > it seems like the stdint.h that Clang provides requires least16_t to
> > > match fast16_t. I copied this from the AVR target, although maybe that
> > > doesn't support 16-bit at all.
> > Sorry, now I see that AVR uses int because it has 16-bit ints...
> >
> > There isn't any existing Clang target that uses 32-bit for fast16_t, so
> > maybe it's currently not possible within Clang's framework (or at least,
> > not without also fiddling with least16_t).
> > `lib/Frontend/InitPreprocessor.cpp` hardcodes some logic with sets them to
> > be the same.
> >
> > I can abandon this review if that's not acceptable collateral damage
> > (probably not, on reflection) - or could tweak InitPreprocessor.cpp and
> > stdint.h to be more flexible (might need more review if you don't "own"
> > those files?)
> I think it's worth trying to fix InitPreprocessor.cpp/stdint.h to remove the
> assumption that those types are the same. We'll need to get broader review,
> so it will be slower than if we were just changing our own files, but that's
> OK. If you're up for doing that I'd be happy to help you find reviewers, or
> otherwise I can take a shot at it; now is a good time since we're taking a
> closer look at our ABIs more generally anyway.
uhh... if you could take a look that would be great! I've only got a limited
Wasm "budget" from my employer, and have to get back to customer work for most
of the rest of the week.
Was there an issue I seem to remember as well, where Wasm32 was using "unsigned
int" for __SIZE_TYPE__ instead of "unsigned long".
Repository:
rC Clang
https://reviews.llvm.org/D41941
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D40738: Don't use Wasm function sections for more than one function
ncw created this revision.
Herald added subscribers: cfe-commits, aheejin, sbc100, dschuff, jfb.
Fixes Bugzilla https://bugs.llvm.org/show_bug.cgi?id=35467
If a Wasm function section is created with more than one symbol,
WasmObjectWriter fails with the following message: "function sections must
contain one function each".
Currently, if a C++ file contains multiple static initialisers, they'll all be
put in the same function section, triggering the error.
I think this change here is safe - it seems to be a spurious optimisation. In
fact, I'm not even sure how it's intended to optimise the output...?
Repository:
rC Clang
https://reviews.llvm.org/D40738
Files:
lib/Basic/Targets/OSTargets.h
test/CodeGenCXX/static-init-wasm.cpp
Index: test/CodeGenCXX/static-init-wasm.cpp
===
--- test/CodeGenCXX/static-init-wasm.cpp
+++ test/CodeGenCXX/static-init-wasm.cpp
@@ -43,12 +43,12 @@
A theA;
-// WEBASSEMBLY32: define internal void @__cxx_global_var_init() #3 section
".text.__startup" {
+// WEBASSEMBLY32: define internal void @__cxx_global_var_init() #3 {
// WEBASSEMBLY32: call %struct.A* @_ZN1AC1Ev(%struct.A* @theA)
-// WEBASSEMBLY32: define internal void @_GLOBAL__sub_I_static_init_wasm.cpp()
#3 section ".text.__startup" {
+// WEBASSEMBLY32: define internal void @_GLOBAL__sub_I_static_init_wasm.cpp()
#3 {
// WEBASSEMBLY32: call void @__cxx_global_var_init()
//
-// WEBASSEMBLY64: define internal void @__cxx_global_var_init() #3 section
".text.__startup" {
+// WEBASSEMBLY64: define internal void @__cxx_global_var_init() #3 {
// WEBASSEMBLY64: call %struct.A* @_ZN1AC1Ev(%struct.A* @theA)
-// WEBASSEMBLY64: define internal void @_GLOBAL__sub_I_static_init_wasm.cpp()
#3 section ".text.__startup" {
+// WEBASSEMBLY64: define internal void @_GLOBAL__sub_I_static_init_wasm.cpp()
#3 {
// WEBASSEMBLY64: call void @__cxx_global_var_init()
Index: lib/Basic/Targets/OSTargets.h
===
--- lib/Basic/Targets/OSTargets.h
+++ lib/Basic/Targets/OSTargets.h
@@ -711,11 +711,6 @@
Builder.defineMacro("_GNU_SOURCE");
}
- // As an optimization, group static init code together in a section.
- const char *getStaticInitSectionSpecifier() const final {
-return ".text.__startup";
- }
-
public:
explicit WebAssemblyOSTargetInfo(const llvm::Triple &Triple,
const TargetOptions &Opts)
Index: test/CodeGenCXX/static-init-wasm.cpp
===
--- test/CodeGenCXX/static-init-wasm.cpp
+++ test/CodeGenCXX/static-init-wasm.cpp
@@ -43,12 +43,12 @@
A theA;
-// WEBASSEMBLY32: define internal void @__cxx_global_var_init() #3 section ".text.__startup" {
+// WEBASSEMBLY32: define internal void @__cxx_global_var_init() #3 {
// WEBASSEMBLY32: call %struct.A* @_ZN1AC1Ev(%struct.A* @theA)
-// WEBASSEMBLY32: define internal void @_GLOBAL__sub_I_static_init_wasm.cpp() #3 section ".text.__startup" {
+// WEBASSEMBLY32: define internal void @_GLOBAL__sub_I_static_init_wasm.cpp() #3 {
// WEBASSEMBLY32: call void @__cxx_global_var_init()
//
-// WEBASSEMBLY64: define internal void @__cxx_global_var_init() #3 section ".text.__startup" {
+// WEBASSEMBLY64: define internal void @__cxx_global_var_init() #3 {
// WEBASSEMBLY64: call %struct.A* @_ZN1AC1Ev(%struct.A* @theA)
-// WEBASSEMBLY64: define internal void @_GLOBAL__sub_I_static_init_wasm.cpp() #3 section ".text.__startup" {
+// WEBASSEMBLY64: define internal void @_GLOBAL__sub_I_static_init_wasm.cpp() #3 {
// WEBASSEMBLY64: call void @__cxx_global_var_init()
Index: lib/Basic/Targets/OSTargets.h
===
--- lib/Basic/Targets/OSTargets.h
+++ lib/Basic/Targets/OSTargets.h
@@ -711,11 +711,6 @@
Builder.defineMacro("_GNU_SOURCE");
}
- // As an optimization, group static init code together in a section.
- const char *getStaticInitSectionSpecifier() const final {
-return ".text.__startup";
- }
-
public:
explicit WebAssemblyOSTargetInfo(const llvm::Triple &Triple,
const TargetOptions &Opts)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D40739: Pass through --undefined to Wasm LLD
ncw created this revision.
Herald added subscribers: cfe-commits, sunfish, aheejin, jgravelle-google,
dschuff, jfb, klimek.
This is a follow-on to https://reviews.llvm.org/D40724 (Wasm entrypoint changes
#1, add `--undefined` argument to LLD).
Repository:
rC Clang
https://reviews.llvm.org/D40739
Files:
lib/Driver/ToolChains/WebAssembly.cpp
lib/Format/ContinuationIndenter.cpp
lib/Format/ContinuationIndenter.h
unittests/Format/FormatTest.cpp
Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -9934,8 +9934,8 @@
Style.PenaltyExcessCharacter = 90;
verifyFormat("int a; // the comment", Style);
EXPECT_EQ("int a; // the comment\n"
-" // aa",
-format("int a; // the comment aa", Style));
+" // aaa",
+format("int a; // the comment aaa", Style));
EXPECT_EQ("int a; /* first line\n"
"* second line\n"
"* third line\n"
@@ -9963,14 +9963,14 @@
Style));
EXPECT_EQ("// foo bar baz bazfoo\n"
-"// foo bar\n",
+"// foo bar foo bar\n",
format("// foo bar baz bazfoo\n"
- "// foobar\n",
+ "// foo bar foo bar\n",
Style));
EXPECT_EQ("// foo bar baz bazfoo\n"
-"// foo bar\n",
+"// foo bar foo bar\n",
format("// foo bar baz bazfoo\n"
- "// foobar\n",
+ "// foobar foo bar\n",
Style));
// FIXME: Optimally, we'd keep bazfoo on the first line and reflow bar to the
@@ -9996,6 +9996,20 @@
"// foo bar baz bazfoo bar\n"
"// foo bar\n",
Style));
+
+ // Make sure we do not keep protruding characters if strict mode reflow is
+ // cheaper than keeping protruding characters.
+ Style.ColumnLimit = 21;
+ EXPECT_EQ("// foo foo foo foo\n"
+"// foo foo foo foo\n"
+"// foo foo foo foo\n",
+format("// foo foo foo foo foo foo foo foo foo foo foo foo\n",
+ Style));
+
+ EXPECT_EQ("int a = /* long block\n"
+" comment */\n"
+"42;",
+format("int a = /* long block comment */ 42;", Style));
}
#define EXPECT_ALL_STYLES_EQUAL(Styles)\
Index: lib/Format/ContinuationIndenter.h
===
--- lib/Format/ContinuationIndenter.h
+++ lib/Format/ContinuationIndenter.h
@@ -123,14 +123,25 @@
/// \brief If the current token sticks out over the end of the line, break
/// it if possible.
///
- /// \returns An extra penalty if a token was broken, otherwise 0.
+ /// \returns A pair (penalty, exceeded), where penalty is the extra penalty
+ /// when tokens are broken or lines exceed the column limit, and exceeded
+ /// indicates whether the algorithm purposefully left lines exceeding the
+ /// column limit.
///
/// The returned penalty will cover the cost of the additional line breaks
/// and column limit violation in all lines except for the last one. The
/// penalty for the column limit violation in the last line (and in single
/// line tokens) is handled in \c addNextStateToQueue.
- unsigned breakProtrudingToken(const FormatToken &Current, LineState &State,
-bool AllowBreak, bool DryRun);
+ ///
+ /// \p Strict indicates whether reflowing is allowed to leave characters
+ /// protruding the column limit; if true, lines will be split strictly within
+ /// the column limit where possible; if false, words are allowed to protrude
+ /// over the column limit as long as the penalty is less than the penalty
+ /// of a break.
+ std::pair breakProtrudingToken(const FormatToken &Current,
+ LineState &State,
+ bool AllowBreak, bool DryRun,
+ bool Strict);
/// \brief Returns the \c BreakableToken starting at \p Current, or nullptr
/// if the current token cannot be broken.
Index: lib/Format/ContinuationIndenter.cpp
===
--- lib/Format/ContinuationIndenter.cpp
+++ lib/Format/ContinuationIndenter.cpp
@@ -1390,7 +1390,36 @@
Penalty = addMultilineToken(Current, State);
} else if (State.Line->Type != LT_ImportStatement) {
// We generally don't break import statements.
-Penalty = breakProtrudingToken(Current, State, AllowBreak, DryRun);
+LineState OriginalState = State;
+
+// Whether we force the reflowing algorithm to stay strictly within the
+// column limit.
+bool Strict = f
[PATCH] D40739: Pass through --undefined to Wasm LLD
ncw updated this revision to Diff 125176.
ncw added a comment.
(D'oh, more trouble with arcane commands getting diffs into phabricator...
sorry for the spam.)
Repository:
rC Clang
https://reviews.llvm.org/D40739
Files:
lib/Driver/ToolChains/WebAssembly.cpp
Index: lib/Driver/ToolChains/WebAssembly.cpp
===
--- lib/Driver/ToolChains/WebAssembly.cpp
+++ lib/Driver/ToolChains/WebAssembly.cpp
@@ -47,6 +47,7 @@
CmdArgs.push_back("--strip-all");
Args.AddAllArgs(CmdArgs, options::OPT_L);
+ Args.AddAllArgs(CmdArgs, options::OPT_u);
ToolChain.AddFilePathLibArgs(Args, CmdArgs);
if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles))
Index: lib/Driver/ToolChains/WebAssembly.cpp
===
--- lib/Driver/ToolChains/WebAssembly.cpp
+++ lib/Driver/ToolChains/WebAssembly.cpp
@@ -47,6 +47,7 @@
CmdArgs.push_back("--strip-all");
Args.AddAllArgs(CmdArgs, options::OPT_L);
+ Args.AddAllArgs(CmdArgs, options::OPT_u);
ToolChain.AddFilePathLibArgs(Args, CmdArgs);
if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D40739: Pass through --undefined to Wasm LLD
ncw added a comment. I didn't know it existed either, and you're right it's odd that it doesn't appear in the help text... However it duly exists and is implemented in clang/lib/Driver/ToolChains/Gnu.cpp, without any note that it's deprecated. `man gcc` documents it. Repository: rC Clang https://reviews.llvm.org/D40739 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D40739: Pass through --undefined to Wasm LLD
ncw added a comment. I'm glad to be involved in a small way. Our company uses Emscripten in one of our products, and some of our employees were early contributors to Emscripten years ago, when they were trying to get C++ working. Now I've been allowed to spend a few weeks "investigating" Wasm, then I'll have to get back to my normal work on our product. I hope short-term contributors like me don't add too much burden. I'm also really impressed with Wasm, the whole design, tooling and project is coming along really well and should provide an excellent foundation for web projects. Regarding this patch - can we get away without a test...? I can confirm that I've just done a manual test, and the argument is correctly passed down to LLD. Plus the line was simply copied from the existing toolchains. Repository: rC Clang https://reviews.llvm.org/D40739 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D40738: Don't use Wasm function sections for more than one function
ncw added a comment. Thanks for the review @sunfish (and for the other input you've given). Could you land this for me Dan, as I don't have commit access? Thanks. Repository: rC Clang https://reviews.llvm.org/D40738 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D41073: Wasm: add support in libcxx
ncw created this revision. Herald added subscribers: cfe-commits, aheejin, jfb. Herald added a reviewer: EricWF. It turns out that this is the only change required in libcxx for it to compile with the new `wasm32-unknown-unknown-wasm` target recently added to Clang. I haven't done much testing of whether libc++ //works// with Wasm, but committing the compile fix is at least a start. Adding Marshall Clow and Dan Gohman as reviewers since they landed the last Emscripten-related changes in libcxx. Repository: rCXX libc++ https://reviews.llvm.org/D41073 Files: include/__config Index: include/__config === --- include/__config +++ include/__config @@ -45,6 +45,8 @@ #define _LIBCPP_OBJECT_FORMAT_MACHO 1 #elif defined(_WIN32) #define _LIBCPP_OBJECT_FORMAT_COFF 1 +#elif defined(__wasm__) +#define _LIBCPP_OBJECT_FORMAT_WASM 1 #else #error Unknown object file format #endif Index: include/__config === --- include/__config +++ include/__config @@ -45,6 +45,8 @@ #define _LIBCPP_OBJECT_FORMAT_MACHO 1 #elif defined(_WIN32) #define _LIBCPP_OBJECT_FORMAT_COFF 1 +#elif defined(__wasm__) +#define _LIBCPP_OBJECT_FORMAT_WASM 1 #else #error Unknown object file format #endif ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
