jfb (JF Bastien)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 27 2014, 9:36 AM (225 w, 5 d)

Recent Activity

Yesterday

jfb committed rCXX333351: Revert "Add nonnull; use it for atomics".
Revert "Add nonnull; use it for atomics"
Sat, May 26, 12:50 PM
jfb committed rL333351: Revert "Add nonnull; use it for atomics".
Revert "Add nonnull; use it for atomics"
Sat, May 26, 12:50 PM
jfb added a comment to D47290: [Sema] -Wformat-pedantic only for NSInteger/NSUInteger %zu/%zi on Darwin.

Addressed comments.

Sat, May 26, 12:36 PM
jfb updated the diff for D47290: [Sema] -Wformat-pedantic only for NSInteger/NSUInteger %zu/%zi on Darwin.
  • Fix variable capitalization.
Sat, May 26, 12:36 PM
jfb added a comment to D47290: [Sema] -Wformat-pedantic only for NSInteger/NSUInteger %zu/%zi on Darwin.

This is relaxing -Wformat and making users instead write -Wformat-pedantic to get the strong guarantees, which is the opposite of what I thought the consensus was. Have I misunderstood something?

Sat, May 26, 12:20 PM

Fri, May 25

jfb added 1 commit(s) for D47225: Add nonnull; use it for atomics: rCXX333327: Fix GCC handling of ATOMIC_VAR_INIT.
Fri, May 25, 5:18 PM
jfb added an edge to rCXX333327: Fix GCC handling of ATOMIC_VAR_INIT: D47225: Add nonnull; use it for atomics.
Fri, May 25, 5:18 PM
jfb committed rCXX333327: Fix GCC handling of ATOMIC_VAR_INIT.
Fix GCC handling of ATOMIC_VAR_INIT
Fri, May 25, 5:18 PM
jfb committed rL333327: Fix GCC handling of ATOMIC_VAR_INIT.
Fix GCC handling of ATOMIC_VAR_INIT
Fri, May 25, 5:18 PM
jfb added a comment to D47225: Add nonnull; use it for atomics.

GCC in libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 seems to mis-handle ATOMIC_VAR_INIT:

Fri, May 25, 5:15 PM
jfb committed rCXX333325: Add nonnull; use it for atomics.
Add nonnull; use it for atomics
Fri, May 25, 4:48 PM
jfb committed rL333325: Add nonnull; use it for atomics.
Add nonnull; use it for atomics
Fri, May 25, 4:48 PM
jfb closed D47225: Add nonnull; use it for atomics.
Fri, May 25, 4:47 PM
jfb committed rL333317: Fix optional<char> test breakage.
Fix optional<char> test breakage
Fri, May 25, 2:36 PM
jfb committed rCXX333317: Fix optional<char> test breakage.
Fix optional<char> test breakage
Fri, May 25, 2:36 PM
jfb committed rL333315: Fix array deduction guide test breakage.
Fix array deduction guide test breakage
Fri, May 25, 2:21 PM
jfb committed rCXX333315: Fix array deduction guide test breakage.
Fix array deduction guide test breakage
Fri, May 25, 2:21 PM
jfb committed rCXX333308: Fix optional deduction guide test breakage.
Fix optional deduction guide test breakage
Fri, May 25, 1:49 PM
jfb committed rL333308: Fix optional deduction guide test breakage.
Fix optional deduction guide test breakage
Fri, May 25, 1:47 PM
jfb added 1 commit(s) for D47229: Make atomic non-member functions as nonnull: rL333290: Follow-up fix for nonnull atomic non-member functions.
Fri, May 25, 10:41 AM
jfb added an edge to rL333290: Follow-up fix for nonnull atomic non-member functions: D47229: Make atomic non-member functions as nonnull.
Fri, May 25, 10:41 AM
jfb added a comment to D47229: Make atomic non-member functions as nonnull.

Fixed by r333290.

Fri, May 25, 10:41 AM
jfb committed rL333290: Follow-up fix for nonnull atomic non-member functions.
Follow-up fix for nonnull atomic non-member functions
Fri, May 25, 10:41 AM
jfb committed rC333290: Follow-up fix for nonnull atomic non-member functions.
Follow-up fix for nonnull atomic non-member functions
Fri, May 25, 10:40 AM
jfb added a comment to D47229: Make atomic non-member functions as nonnull.

This is causing breaks in fuchsia,

Code that looks like this

uintptr_t last_unlogged =
     atomic_load_explicit(&unlogged_tail, memory_order_acquire);
 do { 
     if (last_unlogged == 0)
         return;
 } while (!atomic_compare_exchange_weak_explicit(&unlogged_tail,
                                                 &last_unlogged, 0,
                                                 memory_order_acq_rel,
                                                 memory_order_relaxed));

Where unlogged_tail is somewhere on the stack. And 'atomic_compare_exchange_weak_explicit' is an #define alias for '__c11_atomic_compare_exchange_weak'

Full context here: https://fuchsia.googlesource.com/zircon/+/master/third_party/ulib/musl/ldso/dynlink.c#822

Fri, May 25, 10:15 AM

Thu, May 24

jfb added a comment to D47225: Add nonnull; use it for atomics.

Ping! clang side landed in https://reviews.llvm.org/rL333246

Thu, May 24, 5:13 PM
jfb committed rC333246: Make atomic non-member functions as nonnull.
Make atomic non-member functions as nonnull
Thu, May 24, 5:11 PM
jfb committed rL333246: Make atomic non-member functions as nonnull.
Make atomic non-member functions as nonnull
Thu, May 24, 5:11 PM
jfb closed D47229: Make atomic non-member functions as nonnull.
Thu, May 24, 5:11 PM
jfb added inline comments to D47229: Make atomic non-member functions as nonnull.
Thu, May 24, 4:51 PM
jfb updated the diff for D47229: Make atomic non-member functions as nonnull.
  • Address nit.
  • Change suggested by Richard
Thu, May 24, 4:50 PM
jfb added inline comments to D47290: [Sema] -Wformat-pedantic only for NSInteger/NSUInteger %zu/%zi on Darwin.
Thu, May 24, 1:14 PM
jfb updated the diff for D47290: [Sema] -Wformat-pedantic only for NSInteger/NSUInteger %zu/%zi on Darwin.
  • Merge format-size-spec-nsinteger
Thu, May 24, 1:13 PM
jfb added a comment to D47229: Make atomic non-member functions as nonnull.

Addressed nit.

Thu, May 24, 11:38 AM
jfb updated the diff for D47229: Make atomic non-member functions as nonnull.
  • Address nit.
Thu, May 24, 11:37 AM
jfb added a comment to D46084: [Fixed Point Arithmetic] Addition of the Fixed Point _Accum type.

Can you also add a test for _Bool _Accum.

Thu, May 24, 11:00 AM · Restricted Project

Wed, May 23

jfb updated the summary of D47290: [Sema] -Wformat-pedantic only for NSInteger/NSUInteger %zu/%zi on Darwin.
Wed, May 23, 3:42 PM
jfb added inline comments to D47290: [Sema] -Wformat-pedantic only for NSInteger/NSUInteger %zu/%zi on Darwin.
Wed, May 23, 3:28 PM
jfb created D47290: [Sema] -Wformat-pedantic only for NSInteger/NSUInteger %zu/%zi on Darwin.
Wed, May 23, 3:07 PM
jfb added a comment to D46084: [Fixed Point Arithmetic] Addition of the Fixed Point _Accum type.

Actually, scratch that. We will be enabling it since GCC does. Will update this and other relevant C++ related code appropriately.

Wed, May 23, 11:34 AM · Restricted Project
jfb added a comment to D42933: [Sema] Avoid -Wformat warning for NSInteger/NSUInteger 'int' values with %zu/%zi long specifiers.

Based on the cfe-dev discussion we'll want to handle the case of NSInteger with %z format on Darwin separately from other attempts at portability warnings in printf formats. I'll therefore re-post this patch as-is and CC all of you.

Wed, May 23, 9:43 AM

Tue, May 22

jfb added a comment to D46084: [Fixed Point Arithmetic] Addition of the Fixed Point _Accum type.

This is on by default for any version of C? AFAICK _Accum isn't on the C17 draft that I have, I'd expect to have to specify a command-line flag pertaining to TR 18037 to get this. At a minimum I'd be OK having it with the GNU variant of C, but not the __ANSI_C__ one.

Tue, May 22, 9:01 PM · Restricted Project
jfb added a dependency for D47229: Make atomic non-member functions as nonnull: D47225: Add nonnull; use it for atomics.
Tue, May 22, 2:44 PM
jfb added a dependent revision for D47225: Add nonnull; use it for atomics: D47229: Make atomic non-member functions as nonnull.
Tue, May 22, 2:44 PM
jfb updated the summary of D47225: Add nonnull; use it for atomics.
Tue, May 22, 2:43 PM
jfb created D47229: Make atomic non-member functions as nonnull.
Tue, May 22, 2:43 PM
jfb created D47225: Add nonnull; use it for atomics.
Tue, May 22, 1:39 PM

Fri, May 18

jfb closed D47096: CodeGen: block capture shouldn't ICE.

r332801

Fri, May 18, 9:37 PM
jfb added 1 commit(s) for D47096: CodeGen: block capture shouldn't ICE: rC332801: CodeGen: block capture shouldn't ICE.
Fri, May 18, 9:37 PM
jfb added an edge to rC332801: CodeGen: block capture shouldn't ICE: D47096: CodeGen: block capture shouldn't ICE.
Fri, May 18, 9:37 PM
jfb committed rC332801: CodeGen: block capture shouldn't ICE.
CodeGen: block capture shouldn't ICE
Fri, May 18, 9:25 PM
jfb committed rL332801: CodeGen: block capture shouldn't ICE.
CodeGen: block capture shouldn't ICE
Fri, May 18, 9:25 PM
jfb added a comment to D47096: CodeGen: block capture shouldn't ICE.

Test case should go in test/CodeGenCXX. Also, there already is a blocks.cpp there.

Fri, May 18, 9:23 PM
jfb updated the diff for D47096: CodeGen: block capture shouldn't ICE.
  • move test
Fri, May 18, 9:22 PM
jfb added a comment to D47096: CodeGen: block capture shouldn't ICE.

children() is actually defined at the Stmt level, and if you look at how it's implemented on e.g. IfStmt, you can see that it visits all of the child Stmts, including the if-condition. So it should be fine.

Fri, May 18, 9:07 PM
jfb updated the diff for D47096: CodeGen: block capture shouldn't ICE.
  • Follow John's suggestion.
Fri, May 18, 9:07 PM
jfb added a comment to D47096: CodeGen: block capture shouldn't ICE.

RecursiveASTVisitor instantiations are huge. Can you just make the function take a Stmt and then do the first few checks if it happens to be an Expr?

Fri, May 18, 4:54 PM
jfb created D47096: CodeGen: block capture shouldn't ICE.
Fri, May 18, 4:26 PM
jfb added inline comments to D46998: [XRay][compiler-rt] Remove reliance on C++ ABI features.
Fri, May 18, 9:58 AM
jfb committed rL332735: [NFC] update coding standard links to HTTPS.
[NFC] update coding standard links to HTTPS
Fri, May 18, 9:48 AM
jfb abandoned D46723: Require GCC 5.1 and LLVM 3.5 at a minimum.

I quite like the approach in D47073. I'll defer to it.

Fri, May 18, 9:43 AM
jfb added a comment to D47073: Document and Enforce new Host Compiler Policy.

Thanks for starting the discussion, the general approach seems good. I think we can discuss MSVC versions as well as STL requirements separately, along with the libstdc++ ABI problems. and whether we should statically / dynamically link libc++ in some cases.

Fri, May 18, 9:43 AM

Thu, May 17

jfb accepted D47046: [WebAssembly] Object: Add more error checking for object file reading.

One comment, lgtm otherwise.

Thu, May 17, 9:37 PM
jfb added a comment to D46569: [libFuzzer] Generalize libFuzzer build and tests to multiple architectures.

lgtm, though of course someone like @kcc should sign off.

Thu, May 17, 2:18 PM
jfb added inline comments to D46569: [libFuzzer] Generalize libFuzzer build and tests to multiple architectures.
Thu, May 17, 1:10 PM

Wed, May 16

jfb added inline comments to D46569: [libFuzzer] Generalize libFuzzer build and tests to multiple architectures.
Wed, May 16, 10:47 PM
jfb added a comment to D46985: [NFC] WebAssembly build break #2.

Why does this work? Doesn't LLVM_DUMP_METHOD force this method into the link regardless? I though that was the point of it.. so it would never be eliminated.

Wed, May 16, 3:46 PM
jfb added a dependent revision for D46977: [NFC] WebAssembly build fix: D46985: [NFC] WebAssembly build break #2.
Wed, May 16, 3:36 PM
jfb added a dependency for D46985: [NFC] WebAssembly build break #2: D46977: [NFC] WebAssembly build fix.
Wed, May 16, 3:36 PM
jfb committed rL332542: [NFC] WebAssembly build break #2.
[NFC] WebAssembly build break #2
Wed, May 16, 3:35 PM
jfb closed D46985: [NFC] WebAssembly build break #2.
Wed, May 16, 3:35 PM
jfb added a comment to D46977: [NFC] WebAssembly build fix.
In D46977#1102150, @jfb wrote:
In D46977#1102147, @vsk wrote:

I still see a build break with LLVM_ENABLE_MODULES=On:

Do we need to make these targets depend on libObject?

I'm not sure we want to. Let me fix it by moving dump as well.

Wed, May 16, 3:31 PM
jfb created D46985: [NFC] WebAssembly build break #2.
Wed, May 16, 3:31 PM
jfb added a comment to D46977: [NFC] WebAssembly build fix.
In D46977#1102147, @vsk wrote:

I still see a build break with LLVM_ENABLE_MODULES=On:

$ ninja DebugInfoCodeViewTests llvm-rc       
[1/2] Linking CXX executable bin/llvm-rc
FAILED: bin/llvm-rc 
: && /Volumes/Xcode10A177_m18A288_i16A283_t16J278_w16R278a_b16P290a_XcodeInternals_32bitSupport_FastSim_Boost_ASan_36GB/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++  -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -fmodules -fmodules-cache-path=/Users/vsk/src/builds/llvm.org-master-RA/module.cache -fcxx-modules -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics -O3 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-dead_strip tools/llvm-rc/CMakeFiles/llvm-rc.dir/llvm-rc.cpp.o tools/llvm-rc/CMakeFiles/llvm-rc.dir/ResourceFileWriter.cpp.o tools/llvm-rc/CMakeFiles/llvm-rc.dir/ResourceScriptCppFilter.cpp.o tools/llvm-rc/CMakeFiles/llvm-rc.dir/ResourceScriptParser.cpp.o tools/llvm-rc/CMakeFiles/llvm-rc.dir/ResourceScriptStmt.cpp.o tools/llvm-rc/CMakeFiles/llvm-rc.dir/ResourceScriptToken.cpp.o  -o bin/llvm-rc  -Wl,-rpath,@loader_path/../lib lib/libLLVMOption.a lib/libLLVMSupport.a lib/libLLVMBinaryFormat.a lib/libLLVMSupport.a -lz -lcurses -lm lib/libLLVMDemangle.a && :
Undefined symbols for architecture x86_64:
  "llvm::object::WasmSymbol::print(llvm::raw_ostream&) const", referenced from:
      llvm::object::WasmSymbol::dump() const in ResourceFileWriter.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[2/2] Linking CXX executable unittests/DebugInfo/CodeView/DebugInfoCodeViewTests
FAILED: unittests/DebugInfo/CodeView/DebugInfoCodeViewTests 
: && /Volumes/Xcode10A177_m18A288_i16A283_t16J278_w16R278a_b16P290a_XcodeInternals_32bitSupport_FastSim_Boost_ASan_36GB/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++  -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -fmodules -fmodules-cache-path=/Users/vsk/src/builds/llvm.org-master-RA/module.cache -fcxx-modules -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics -O3 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-dead_strip unittests/DebugInfo/CodeView/CMakeFiles/DebugInfoCodeViewTests.dir/RandomAccessVisitorTest.cpp.o unittests/DebugInfo/CodeView/CMakeFiles/DebugInfoCodeViewTests.dir/TypeHashingTest.cpp.o unittests/DebugInfo/CodeView/CMakeFiles/DebugInfoCodeViewTests.dir/TypeIndexDiscoveryTest.cpp.o  -o unittests/DebugInfo/CodeView/DebugInfoCodeViewTests  lib/libLLVMDebugInfoCodeView.a lib/libLLVMBinaryFormat.a lib/libLLVMSupport.a lib/libgtest_main.a lib/libgtest.a lib/libLLVMTestingSupport.a lib/libLLVMDebugInfoMSF.a lib/libgtest.a lib/libLLVMSupport.a -lz -lcurses -lm lib/libLLVMDemangle.a -lpthread && :
Undefined symbols for architecture x86_64:
  "llvm::object::WasmSymbol::print(llvm::raw_ostream&) const", referenced from:
      llvm::object::WasmSymbol::dump() const in RandomAccessVisitorTest.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

Do we need to make these targets depend on libObject?

Wed, May 16, 3:27 PM
jfb added a comment to D46977: [NFC] WebAssembly build fix.

Thanks. Makes sense.

My rational with the original change is that anyone who depends on libObject is almost certainly also depending on libBinaryFormat (at the very least the headers). But your change makes thing nicer since it allows some users to avoid the explicit dependency on the lib I guess.

Wed, May 16, 3:26 PM
jfb committed rL332530: [NFC] WebAssembly build fix.
[NFC] WebAssembly build fix
Wed, May 16, 2:28 PM
jfb closed D46977: [NFC] WebAssembly build fix.
Wed, May 16, 2:28 PM
jfb accepted D46977: [NFC] WebAssembly build fix.

Seems like a no-brainer, I'll commit.

Wed, May 16, 2:28 PM
jfb created D46977: [NFC] WebAssembly build fix.
Wed, May 16, 2:28 PM
jfb added 2 commit(s) for D46858: Signal handling should be signal-safe: rL332429: Revert "Signal handling should be signal-safe", rL332496: Signal handling should be signal-safe.
Wed, May 16, 10:30 AM
jfb added an edge to rL332496: Signal handling should be signal-safe: D46858: Signal handling should be signal-safe.
Wed, May 16, 10:30 AM
jfb added an edge to rL332429: Revert "Signal handling should be signal-safe": D46858: Signal handling should be signal-safe.
Wed, May 16, 10:30 AM
jfb closed D46858: Signal handling should be signal-safe.

Update landed in r332496.

Wed, May 16, 10:29 AM
jfb committed rL332496: Signal handling should be signal-safe.
Signal handling should be signal-safe
Wed, May 16, 10:29 AM
jfb accepted D46858: Signal handling should be signal-safe.
Wed, May 16, 10:28 AM
jfb added a comment to D46858: Signal handling should be signal-safe.

Comments addressed.

Wed, May 16, 10:28 AM
jfb updated the diff for D46858: Signal handling should be signal-safe.
  • Address comments
Wed, May 16, 10:27 AM
jfb added inline comments to D46858: Signal handling should be signal-safe.
Wed, May 16, 9:31 AM
jfb updated the diff for D46858: Signal handling should be signal-safe.
  • Fix double-wide CAS
Wed, May 16, 9:30 AM

Tue, May 15

jfb reopened D46858: Signal handling should be signal-safe.

Had to revert because some bots don't have double-pointer-wide atomics.

Tue, May 15, 9:45 PM
jfb committed rL332429: Revert "Signal handling should be signal-safe".
Revert "Signal handling should be signal-safe"
Tue, May 15, 9:40 PM
jfb committed rL332428: Signal handling should be signal-safe.
Signal handling should be signal-safe
Tue, May 15, 9:33 PM
This revision was not accepted when it landed; it landed in state Needs Review.
Tue, May 15, 9:33 PM
jfb updated the diff for D46858: Signal handling should be signal-safe.
  • Misc updates, cleanup
Tue, May 15, 11:27 AM

Mon, May 14

jfb requested review of D46858: Signal handling should be signal-safe.

Actually I had a bit of time and addressed all outstanding comments from @dexonsmith.

Mon, May 14, 10:19 PM
jfb updated the diff for D46858: Signal handling should be signal-safe.
  • Rebase, address comments.
Mon, May 14, 10:16 PM
jfb added a comment to D46858: Signal handling should be signal-safe.

I committed the two requests NFC changes. Will address other changes tomorrow.

Mon, May 14, 9:29 PM
jfb committed rL332325: [NFC] pull a function into its own lambda.
[NFC] pull a function into its own lambda
Mon, May 14, 9:27 PM
jfb committed rL332323: [NFC] Update comments.
[NFC] Update comments
Mon, May 14, 9:10 PM
jfb added a comment to D46858: Signal handling should be signal-safe.

(Will address code changes separately)

Mon, May 14, 8:58 PM