Hi,
built and passed core tests on OpenMandriva x86_64, aarch64, x86_32 and
armv7hl.
ttyl
bero
On 9 March 2017 at 01:52, Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:
> Dear testers,
>
> The final version of 4.0.0 was just tagged (from the 4.0 branch at
> r297335). T
On Wed, Mar 8, 2017 at 4:52 PM, Hans Wennborg wrote:
> Dear testers,
>
> The final version of 4.0.0 was just tagged (from the 4.0 branch at
> r297335). There were no changes after rc4.
>
> Please build the final binaries and upload to the sftp.
Windows:
$ sha1sum *LLVM-4.0.0-win*.exe
b48a3dab37e
Le 09/03/2017 à 01:52, Hans Wennborg via Release-testers a écrit :
> Dear testers,
>
> The final version of 4.0.0 was just tagged (from the 4.0 branch at
> r297335). There were no changes after rc4.
>
> Please build the final binaries and upload to the sftp.
>
> For others following along: this mea
On 7 March 2017 at 22:15, Hans Wennborg via Release-testers
wrote:
> Dear testers,
>
> 4.0.0-rc4 was just tagged from the branch at r297204.
>
> This is very similar to rc3, with additional fixes for PR32142 and PR32153.
Both ARM and AArch64 look good. The weird fluke on AArch64 is gone.
I'm run
On 9 Mar 2017, at 01:52, Hans Wennborg via Release-testers
wrote:
> The final version of 4.0.0 was just tagged (from the 4.0 branch at
> r297335). There were no changes after rc4.
>
> Please build the final binaries and upload to the sftp.
Built and tested OK on FreeBSD 10. I have uploaded:
S
We encounter low pc values of 0 quite often macOS, since we leave the DWARF in
.o file and then use a debug-map to fix up the addresses (and remove unused
functions). The first function in a .o file is often at 0. Just a data point
in favor of choosing something other than a low pc of 0 to mea
Thank you for the effort put into this response. It's interesting to see
that there are problems with LLDB's handling here. This might mean we need
to have a wider discussion about how LLD does its --gc-sections. From
experience working with our proprietary linker and debugger, this issue is
someth
Thank you for the effort put into this response. It's interesting to see
that there are problems with LLDB's handling here. This might mean we need
to have a wider discussion about how LLD does its --gc-sections and/or how
LLDB treats this situation. From experience working with our proprietary
lin
Hi,
For many years I’m using Xcode to compile and debug source code written in
Pascal (Free Pascal Compiler).
Previously using the gdb-debugger.
With the lldb debugger the "Debug Bar-Proces Controls" and breakpoints still
works fine.
Variables values are displayed in the "View variables”.
Thank
Dear All,
On behalf of LLVM Foundation I would like to announce that LLVM will
be participating in Google Summer of Code this year. GSoC this year
will be quite different from what we saw over last years, so stay
tuned for updates!
Thanks to Vassil, 'Open Projects' pages received a major update t
Hi James,
I performed a quick experiment with clang –g –ffunction-sections and link with
–gc-sections with Hexagon DSP tools based on llvm3.5.
This shows an unused function as having DW_AT_low_pc as zero as you predict:
readelf –W extract of DWARF4 .debug_info)
<1><2b7>: Abbrev Number: 11 (DW_
11 matches
Mail list logo
