dim (Dimitry Andric)
User

Projects

User does not belong to any projects.

User Details

User Since
Apr 15 2014, 12:19 PM (235 w, 6 d)

Recent Activity

Yesterday

dim committed rL345002: Don't mess up RelIplt symbols during relocatable processing.
Don't mess up RelIplt symbols during relocatable processing
Mon, Oct 22, 10:56 PM
dim committed rLLD345002: Don't mess up RelIplt symbols during relocatable processing.
Don't mess up RelIplt symbols during relocatable processing
Mon, Oct 22, 10:56 PM
dim closed D53515: Don't mess up RelIplt symbols during relocatable processing.
Mon, Oct 22, 10:56 PM
dim created D53515: Don't mess up RelIplt symbols during relocatable processing.
Mon, Oct 22, 11:05 AM

Thu, Oct 11

dim added a comment to rL325887: [ELF] - Do not remove empty output sections that are explicitly assigned to….

I think that the inconsistency of linkers behavior shown above shows that LLD behavior is
not incorrect. It is different. But we never tried to be fully bug compatible with bfd/gold.
First of all the problem is caused by a weak assumption in the linker script, which assumes
that orphans are placed at the particular place before the assignment command,
and my feeling it should be fixed.

Thu, Oct 11, 1:16 PM

Mon, Oct 8

dim added a comment to rL325887: [ELF] - Do not remove empty output sections that are explicitly assigned to….

Here is the shortest test case I could come up with. (This uses ld.lld-r325886, but it could also use ld.lld 6.0.1.)

Mon, Oct 8, 1:16 PM
dim added a comment to rL325887: [ELF] - Do not remove empty output sections that are explicitly assigned to….

I am still debugging it, but one observation to mention:

If you remove the .data1 : { *(.data1) } line from the script,
(https://github.com/freebsd/freebsd/blob/master/sys/conf/ldscript.i386#L141)
you'll get the same result as after this patch

.data1 is the empty section and it is anyways removed. But with this patch, it is done a bit earlier, what does not
allows our orphan placement algorithm to see/use it for finding the insertion point.

So it is just a luck that the script worked before this revision.

Mon, Oct 8, 12:22 PM

Sat, Oct 6

dim added a comment to rL325887: [ELF] - Do not remove empty output sections that are explicitly assigned to….

My guess it happens because of set_sysinit_set, set_sysuninit_set, set_pcpu, set_vnet are orphans (not listed in the linker script),
and our algorithm of placing the orphans started to place them in between of
(https://github.com/freebsd/freebsd/blob/master/sys/conf/ldscript.i386#L142)

_edata = .; PROVIDE (edata = .);
__bss_start = .;

for some reason. And honestly, I would not call this incorrect behavior, though I do not understand now how this patch could affect this.

Sat, Oct 6, 11:58 AM
dim added a comment to rL325887: [ELF] - Do not remove empty output sections that are explicitly assigned to….

Furthermore, we have read-only and read/write set_ sections. BFD ld and older lld seem to figure these out, then place the read-only ones just after .rodata, and the read/write ones after .data. I am not sure if there is a way to distinguish between these in a linker script? The names always match set_*, but there is no different naming scheme for r/o and r/w sets.

What I meant is to specify them explicitly. You do not need to match the 'set_*' for that.
I modified the script from the reproduce file in the following way (added all set_* r/w sections before _edata symbol assignment):

...
  .data1          : { *(.data1) }
  
  set_sysinit_set    : { *(set_sysinit_set) }
  set_sysuninit_set  : { *(set_sysuninit_set ) }
  set_pcpu           : { *(set_pcpu) }
  set_vnet           : { *(set_sysinit_set) }
  
  _edata = .; PROVIDE (edata = .);
...

And that resolves the issue (at least _edata == 01e2ef78 now, I did not check the booting).
I think the same should be done for the rest (r/o) set_* sections for the safety and overall correctness of the script.

Speaking about some kind of auto distinguishing between r/o and r/w, I do not think it is possible.
The script may have ONLY_IF_RO and ONLY_IF_RW commands, but that is
about different thing and will not help here I believe.

Will the suggested solution work for you?

Sat, Oct 6, 11:47 AM

Tue, Oct 2

dim added a comment to rL325887: [ELF] - Do not remove empty output sections that are explicitly assigned to….

Two questions:

  1. Why don't you just list them in the script at the expected place? This will solve the issue and make the behavior explicit and cleaner I think.
Tue, Oct 2, 9:41 AM

Mon, Oct 1

dim updated subscribers of rL325887: [ELF] - Do not remove empty output sections that are explicitly assigned to….

This change breaks booting an lld-linked i386-freebsd kernel, apparently because it moves symbols around, while not updating the sections? For instance, with lld r325886, I have the following readelf output:

Mon, Oct 1, 1:04 PM

Sep 22 2018

dim added a comment to D52394: [libcxx] Fix the definition of the check-cxx-abilist target on Darwin.

Ah, sorry about that! I should have realized this, but my CMake-fu is weak. :)

Sep 22 2018, 12:39 PM
dim committed rL342805: Similar to the handling of darwin target triples, strip the version.
Similar to the handling of darwin target triples, strip the version
Sep 22 2018, 7:39 AM
dim committed rCXX342805: Similar to the handling of darwin target triples, strip the version.
Similar to the handling of darwin target triples, strip the version
Sep 22 2018, 7:39 AM
dim committed rCXX342803: Remove a bunch of empty subdirectories. NFCI..
Remove a bunch of empty subdirectories. NFCI.
Sep 22 2018, 6:39 AM
dim committed rL342803: Remove a bunch of empty subdirectories. NFCI..
Remove a bunch of empty subdirectories. NFCI.
Sep 22 2018, 6:36 AM

Sep 21 2018

dim updated subscribers of D52240: Partial Fix for PR#38964.
In D52240#1242341, @dim wrote:

Hmm, I tried on macOS 10.13.6 with Xcode 9.4.1 and Apple LLVM version 9.1.0 (clang-902.0.39.2), using stock libc++ r342744, but that already failed:

ninja: Entering directory `/Users/dim/obj/llvm-342744-trunk-darwin17-x86_64-ninja-rel-1'
[1/1] Testing ABI compatibility...
FAILED: projects/libcxx/lib/abi/CMakeFiles/check-cxx-abilist
cd /Users/dim/obj/llvm-342744-trunk-darwin17-x86_64-ninja-rel-1/projects/libcxx/lib/abi && /Users/dim/tmp/llvm/projects/libcxx/utils/sym_diff.py --only-stdlib-symbols --strict /Users/dim/tmp/llvm/projects/libcxx/lib/abi/x86_64-apple-darwin.v1.abilist /Users/dim/obj/llvm-342744-trunk-darwin17-x86_64-ninja-rel-1/lib/libc++.1.dylib
Symbol added: __ZNSt3__16__itoa8__u32toaEjPc
    {'type': 'FUNC', 'is_defined': True, 'name': '__ZNSt3__16__itoa8__u32toaEjPc'}

Symbol added: __ZNSt3__16__itoa8__u64toaEyPc
    {'type': 'FUNC', 'is_defined': True, 'name': '__ZNSt3__16__itoa8__u64toaEyPc'}

Summary
    Added:   2
    Removed: 0
    Changed: 0
Symbols added.

So I assume the ABI is already broken in some way...

Sep 21 2018, 1:53 PM
dim updated subscribers of D52240: Partial Fix for PR#38964.

Marshall, can you confirm that the change does not break check-cxx-abilist on OS X. I'm fine with the change if that's not broken.

Sep 21 2018, 11:55 AM
dim committed rLLD342746: Align AArch64 and i386 image base to superpage.
Align AArch64 and i386 image base to superpage
Sep 21 2018, 10:00 AM
dim committed rL342746: Align AArch64 and i386 image base to superpage.
Align AArch64 and i386 image base to superpage
Sep 21 2018, 10:00 AM
dim closed D50297: Align AArch64 and i386 image base to superpage.
Sep 21 2018, 9:59 AM

Sep 18 2018

dim added a comment to D52240: Partial Fix for PR#38964.

Built with mkdir build && cd build && cmake -G Ninja .. && ninja, the resulting libc++.so.1 has the following additional symbols:

Sep 18 2018, 12:16 PM
dim retitled D52240: Partial Fix for PR#38964 from Partial Fix for PR#39864 to Partial Fix for PR#38964.
Sep 18 2018, 12:16 PM

Sep 16 2018

dim added a comment to D50297: Align AArch64 and i386 image base to superpage.

So, any more actions to take, or can I commit this?

Sep 16 2018, 1:42 AM

Sep 1 2018

dim committed rL341279: For the 2018 Developers' Meeting page, use https:// links for the W3C.
For the 2018 Developers' Meeting page, use https:// links for the W3C
Sep 1 2018, 7:32 AM

Aug 29 2018

dim added a comment to D50297: Align AArch64 and i386 image base to superpage.

Oh, I didn't notice that you are trying to make a change for i386, not for x86-64. What is your motivation to use superpages for 32-bit applications? I believe that the applications you want to use superpages are large programs and naturally be 64-bit, so I wonder if this change is actually useful.

Aug 29 2018, 3:48 AM

Aug 28 2018

dim retitled D50297: Align AArch64 and i386 image base to superpage from On FreeBSD, align AArch64 and i386 image base to superpage to Align AArch64 and i386 image base to superpage.
Aug 28 2018, 1:03 PM
dim updated the diff for D50297: Align AArch64 and i386 image base to superpage.

Update all tests to match current output.

Aug 28 2018, 9:06 AM

Aug 15 2018

dim accepted D50799: Fix for PR 38495: <ctime> no longer compiles on FreeBSD, due to lack of timespec_get().

LGTM.

Aug 15 2018, 2:14 PM
dim committed rCXX339794: For FreeBSD, don't define _M in nasty_macros.hpp.
For FreeBSD, don't define _M in nasty_macros.hpp
Aug 15 2018, 10:32 AM
dim committed rL339794: For FreeBSD, don't define _M in nasty_macros.hpp.
For FreeBSD, don't define _M in nasty_macros.hpp
Aug 15 2018, 10:31 AM

Aug 7 2018

dim added a comment to D50297: Align AArch64 and i386 image base to superpage.

Looking at this a bit more, I see that it is unconditionally setting the DefaultImage base for all platforms, which cannot be right. I didn't notice this when it was committed into FreeBSD, but it doesn't matter there, of course. I'm not sure if there is a good way to override this setting on a per-platform basis. Maybe just if (os == FreeBSD) DefaultImageBase=x?

Is there any reason that this value doesn't work for other operating systems? I guess the new image base values work everywhere. If that's the case, I'd change the default so that we have less moving parts in the linker.

Aug 7 2018, 10:42 PM

Aug 4 2018

dim updated subscribers of rL330566: [Atomics] warn about atomic accesses using libcalls.

@t.p.northover, I'm seeing this warning now on some code in FreeBSD, but the variable in question is perfectly aligned, so there should be no penalty at all. Does this warning check the actual variable being accessed in any way?

Aug 4 2018, 12:06 PM
dim added a comment to D50297: Align AArch64 and i386 image base to superpage.

Looking at this a bit more, I see that it is unconditionally setting the DefaultImage base for all platforms, which cannot be right. I didn't notice this when it was committed into FreeBSD, but it doesn't matter there, of course. I'm not sure if there is a good way to override this setting on a per-platform basis. Maybe just if (os == FreeBSD) DefaultImageBase=x?

Aug 4 2018, 11:38 AM
dim added a comment to D48433: [ELF] - Report unimplemented -z options..

Ah, only now I've noticed that in the FreeBSD kernel link, we've been using the unsupported -z common-page-size= option:

Aug 4 2018, 9:47 AM
dim added a comment to D50297: Align AArch64 and i386 image base to superpage.

Note that we have already committed this in FreeBSD, see https://reviews.freebsd.org/D16385 and https://reviews.freebsd.org/rS337282.

Aug 4 2018, 6:04 AM
dim created D50297: Align AArch64 and i386 image base to superpage.
Aug 4 2018, 6:04 AM

Jul 2 2018

dim added a comment to D48806: [asan] Fix deadlock issue on FreeBSD, caused by use of .preinit_array in rL325240.
In D48806#1149655, @dim wrote:
In D48806#1149021, @dim wrote:

Sorry for not getting to this one earlier, indeed it fixes the deadlock for me too!

Now the only "big" thing left is the hundreds of:

==41641==AddressSanitizer CHECK failed: /share/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:48 "((0)) == ((pthread_key_create(&tsd_key, destructor)))" (0x0, 0x4e)
`

failures. :-)

I guess it s FreeBSD 11.2 ? Seems his fix working on 10.4, will check on 11.x when I can ... otherwise there is always the thread local solution I threw a while ago. WE might need to come up with another solution anyway @krytarowski reports it is still an issue on NetBSD.

This is on FreeBSD 12-CURRENT, but it could also show the same issue on 11.x.

Jul 2 2018, 2:37 PM
dim added a comment to D48806: [asan] Fix deadlock issue on FreeBSD, caused by use of .preinit_array in rL325240.
In D48806#1149021, @dim wrote:

Sorry for not getting to this one earlier, indeed it fixes the deadlock for me too!

Now the only "big" thing left is the hundreds of:

==41641==AddressSanitizer CHECK failed: /share/dim/src/llvm/trunk/projects/compiler-rt/lib/asan/asan_posix.cc:48 "((0)) == ((pthread_key_create(&tsd_key, destructor)))" (0x0, 0x4e)
`

failures. :-)

I guess it s FreeBSD 11.2 ? Seems his fix working on 10.4, will check on 11.x when I can ... otherwise there is always the thread local solution I threw a while ago. WE might need to come up with another solution anyway @krytarowski reports it is still an issue on NetBSD.

Jul 2 2018, 9:35 AM

Jul 1 2018

dim added a comment to D48806: [asan] Fix deadlock issue on FreeBSD, caused by use of .preinit_array in rL325240.

Sorry for not getting to this one earlier, indeed it fixes the deadlock for me too!

Jul 1 2018, 2:24 PM

Jun 29 2018

dim committed rC336008: Request init/fini array on FreeBSD 12 and later.
Request init/fini array on FreeBSD 12 and later
Jun 29 2018, 12:23 PM
dim committed rL336008: Request init/fini array on FreeBSD 12 and later.
Request init/fini array on FreeBSD 12 and later
Jun 29 2018, 12:23 PM
dim closed D24867: Request init/fini array on FreeBSD 12 and later.
Jun 29 2018, 12:22 PM

Jun 15 2018

dim added a comment to rL325240: Add Xray instrumentation support to FreeBSD.

FWIW, after this commit, on FreeBSD 12.0-CURRENT, most (if not all) ASan tests hang in 'urdlck' state. I'm still investigating.

Jun 15 2018, 12:22 PM

Jun 13 2018

dim committed rCRT334659: Disable MSan tests of prlimit on FreeBSD.
Disable MSan tests of prlimit on FreeBSD
Jun 13 2018, 2:42 PM
dim committed rL334659: Disable MSan tests of prlimit on FreeBSD.
Disable MSan tests of prlimit on FreeBSD
Jun 13 2018, 2:42 PM

Jun 9 2018

dim created D47987: Provide only one declaration of __throw_runtime_error.
Jun 9 2018, 2:49 PM

May 14 2018

dim updated subscribers of D46857: [CMake] Detect the compiler runtime and standard library.

Do we still leave the defaults for particular OSes here? I'm asking because for example in FreeBSD, we use libcxxrt, but you *won't* find it in linker output, since our libc++.so is a linker script:

$ clang++ /usr/local/share/cmake/Modules/DummyCXXFile.cxx -###
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
Target: x86_64-unknown-freebsd11.2
Thread model: posix
InstalledDir: /usr/bin
 "/usr/bin/clang++" "-cc1" "-triple" "x86_64-unknown-freebsd11.2" "-emit-obj" "-mrelax-all" "-disable-free" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "DummyCXXFile.cxx" "-mrelocation-model" "static" "-mthread-model" "posix" "-mdisable-fp-elim" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" "x86-64" "-dwarf-column-info" "-debugger-tuning=gdb" "-resource-dir" "/usr/lib/clang/6.0.0" "-internal-isystem" "/usr/include/c++/v1" "-fdeprecated-macro" "-fdebug-compilation-dir" "/home/dim/src/llvm/trunk" "-ferror-limit" "19" "-fmessage-length" "160" "-fobjc-runtime=gnustep" "-fcxx-exceptions" "-fexceptions" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "/tmp/DummyCXXFile-5ffab3.o" "-x" "c++" "/usr/local/share/cmake/Modules/DummyCXXFile.cxx"
 "/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "--hash-style=both" "--enable-new-dtags" "-o" "a.out" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib" "/tmp/DummyCXXFile-5ffab3.o" "-lc++" "-lm" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/crtend.o" "/usr/lib/crtn.o"

E.g., you see -lc++, and our /usr/lib/libc++.so contains:

$ cat /usr/lib/libc++.so
/* $FreeBSD: stable/11/lib/libc++/libc++.ldscript 253917 2013-08-03 16:23:43Z dim $ */
GROUP ( /usr/lib/libc++.so.1 /usr/lib/libcxxrt.so )

So what would check_link_libraries find in this case?

May 14 2018, 4:56 PM

May 13 2018

dim committed rL332197: Follow-up to rL332176 by adding a test case for PR37264..
Follow-up to rL332176 by adding a test case for PR37264.
May 13 2018, 7:36 AM

May 12 2018

dim committed rL332176: Clear converters map after X86 Domain Reassignment to avoid crashes.
Clear converters map after X86 Domain Reassignment to avoid crashes
May 12 2018, 1:03 PM
dim closed D46425: Clear converters map after X86 Domain Reassignment to avoid crashes.
May 12 2018, 1:03 PM
dim added inline comments to rL330269: [x86] Switch EFLAGS copy lowering to use reg-reg form of testing for.
May 12 2018, 12:20 PM
dim added inline comments to D46425: Clear converters map after X86 Domain Reassignment to avoid crashes.
May 12 2018, 12:15 PM
dim updated the diff for D46425: Clear converters map after X86 Domain Reassignment to avoid crashes.

Use DeleteContainerSeconds instead of rolling our own.

May 12 2018, 12:13 PM

May 11 2018

dim added a comment to D46425: Clear converters map after X86 Domain Reassignment to avoid crashes.

Ping.

May 11 2018, 2:19 PM

May 10 2018

dim added a comment to rL326644: Adding Msan support to FreeBSD.

Sorry for reacting rather late to this, but I'm getting:

May 10 2018, 8:53 AM

May 9 2018

dim accepted D46623: Omit PT_NOTE for SHT_NOTE without SHF_ALLOC.

I'm fine with this, and also with committing it into FreeBSD's copy of lld, but I'd like to see the opinion of @ruiu and/or @grimar too. (I take it @espindola is no longer being monitored...)

May 9 2018, 3:44 AM

May 7 2018

dim added a comment to D24867: Request init/fini array on FreeBSD 12 and later.

Brooks, I can commit this if you prefer. Maybe it can go into 6.0.2 still...

May 7 2018, 11:59 AM

May 4 2018

dim created D46425: Clear converters map after X86 Domain Reassignment to avoid crashes.
May 4 2018, 5:26 AM

Apr 25 2018

dim added a comment to D45652: Asan, fix FreeBSD support.

Do we know why pthread_{get,set}specific fails now? And would it make sense to use tls more broadly (not just on FreeBSD)?

Apr 25 2018, 10:31 AM

Apr 12 2018

dim added inline comments to rL329673: [x86] Model the direction flag (DF) separately from the rest of EFLAGS..
Apr 12 2018, 11:32 AM
dim added inline comments to rL329673: [x86] Model the direction flag (DF) separately from the rest of EFLAGS..
Apr 12 2018, 11:29 AM

Apr 11 2018

dim committed rL329827: Document -std= values for different languages.
Document -std= values for different languages
Apr 11 2018, 10:25 AM
dim committed rC329827: Document -std= values for different languages.
Document -std= values for different languages
Apr 11 2018, 10:25 AM
dim closed D45406: Document -std= values for different languages.
Apr 11 2018, 10:25 AM
dim added a comment to D45406: Document -std= values for different languages.

Ping

Apr 11 2018, 2:05 AM

Apr 9 2018

dim added a comment to D45406: Document -std= values for different languages.

So, does this look good enough to commit?

Apr 9 2018, 10:54 AM

Apr 8 2018

dim updated the diff for D45406: Document -std= values for different languages.

Attempt to put the standard values in to definition lists. In the HTML
output, this looks fairly nice, but as a man page, it seems a bit
strange, for example:

Apr 8 2018, 4:08 AM
dim added a comment to D45406: Document -std= values for different languages.

Well, my idea was to list the standards one per line (like on GCC manpage), and then the '(deprecated)' comments would probably stand out enough to apply to a single line. Also, FWICS the gcc manpage simply lists which aliases are deprecated in the description text. But skipping them entirely also works for me.

Apr 8 2018, 3:14 AM

Apr 7 2018

dim updated the diff for D45406: Document -std= values for different languages.
  • Use "values" instead of "options"
  • Remove deprecated standard values
Apr 7 2018, 3:30 PM
dim added a comment to D45406: Document -std= values for different languages.

To be honest, I find those '(deprecated)' confusing — the user may mistakenly assume that it's about all values rather than the alias.

Apr 7 2018, 12:33 PM
dim created D45406: Document -std= values for different languages.
Apr 7 2018, 12:26 PM

Apr 4 2018

dim added inline comments to rL322010: [TargetLibraryInfo] fix finite mathlib function availability.
Apr 4 2018, 11:35 AM
dim added a comment to rL322010: [TargetLibraryInfo] fix finite mathlib function availability.

Interestingly, adding some debug prints to ConstantFoldFP seems to indicate the the NativeFP call *does* give the correct result:

Apr 4 2018, 11:08 AM
dim updated subscribers of rL322010: [TargetLibraryInfo] fix finite mathlib function availability.
Apr 4 2018, 10:29 AM

Mar 28 2018

dim added a comment to D44536: Avoid segfault when destructor is not yet known.

Ping. Open to sugggestions here :)

Mar 28 2018, 1:45 PM

Mar 22 2018

dim accepted D41869: Rename llvm library from libLLVM-X.Y to libLLVM-X.

LGTM

Mar 22 2018, 4:33 AM

Mar 21 2018

dim accepted D41808: Rename clang link from clang-X.Y to clang-X.

LGTM.

Mar 21 2018, 4:10 AM

Mar 19 2018

dim added a comment to D44536: Avoid segfault when destructor is not yet known.

@rsmith, any objections?

Mar 19 2018, 3:44 PM

Mar 17 2018

dim added a comment to D44604: Make stdarg.h compatible with FreeBSD.

I'm fine with either this approach, or with the approach in stdint.h, e.g. using __has_include_next(), and in that case first including the system-provided header before this one.

Mar 17 2018, 5:19 PM
dim added a reviewer for D44604: Make stdarg.h compatible with FreeBSD: emaste.
Mar 17 2018, 5:15 PM
dim added inline comments to D41808: Rename clang link from clang-X.Y to clang-X.
Mar 17 2018, 7:20 AM

Mar 15 2018

dim added a comment to D44536: Avoid segfault when destructor is not yet known.

I'm not sure it's supposed to be a valid state to get into IRGen with a non-trivial destructor that isn't yet declared. Richard?

Mar 15 2018, 1:41 PM
dim created D44536: Avoid segfault when destructor is not yet known.
Mar 15 2018, 1:15 PM

Feb 28 2018

dim committed rL326358: Fix llvm-config --system-libs output on FreeBSD and NetBSD.
Fix llvm-config --system-libs output on FreeBSD and NetBSD
Feb 28 2018, 12:06 PM
dim closed D42702: Fix llvm-config --system-libs output on FreeBSD and NetBSD.
Feb 28 2018, 12:06 PM
dim updated the diff for D42702: Fix llvm-config --system-libs output on FreeBSD and NetBSD.

Update using @bdrewery's suggestion, with one small fix for Linux, where
Backtrace_LIBRARIES is usually an empty string.

Feb 28 2018, 8:04 AM

Feb 17 2018

dim committed rC325446: [X86] Add 'sahf' CPU feature to frontend.
[X86] Add 'sahf' CPU feature to frontend
Feb 17 2018, 1:10 PM
dim committed rL325446: [X86] Add 'sahf' CPU feature to frontend.
[X86] Add 'sahf' CPU feature to frontend
Feb 17 2018, 1:06 PM
dim closed D43394: [X86] Add 'sahf' CPU feature to frontend.
Feb 17 2018, 1:06 PM
dim retitled D43394: [X86] Add 'sahf' CPU feature to frontend from [X86] Add 'sahf' CPU feature, and emit __LAHFSAHF__ for it to [X86] Add 'sahf' CPU feature to frontend.
Feb 17 2018, 10:47 AM
dim updated the diff for D43394: [X86] Add 'sahf' CPU feature to frontend.

Remove the __LAHFSAHF__ predefined macro.

Feb 17 2018, 10:47 AM
dim accepted D43418: [X86] Add 'sahf' to getHostCPUFeatures so -march=native will pick it up correctly..

LGTM.

Feb 17 2018, 3:53 AM

Feb 16 2018

dim updated the diff for D43394: [X86] Add 'sahf' CPU feature to frontend.

Added the sahf feature for knm, knl and amdfam10 too.

Feb 16 2018, 3:24 PM
dim added inline comments to D43394: [X86] Add 'sahf' CPU feature to frontend.
Feb 16 2018, 2:57 PM
dim created D43394: [X86] Add 'sahf' CPU feature to frontend.
Feb 16 2018, 9:07 AM

Feb 13 2018

dim committed rL325028: Make the ctype_byname::widen test cases pass on FreeBSD..
Make the ctype_byname::widen test cases pass on FreeBSD.
Feb 13 2018, 9:45 AM
dim committed rCXX325028: Make the ctype_byname::widen test cases pass on FreeBSD..
Make the ctype_byname::widen test cases pass on FreeBSD.
Feb 13 2018, 9:45 AM
dim committed rL325027: Put type attributes after class keyword.
Put type attributes after class keyword
Feb 13 2018, 9:44 AM
dim committed rCXX325027: Put type attributes after class keyword.
Put type attributes after class keyword
Feb 13 2018, 9:44 AM