On 10 February 2017 at 22:23, Hans Wennborg wrote:
> A reasonable thing to do would be to put a note on the relaese
> downloads page. But I'm not even sure what to put there. "OpenMP kind
> of works on AArch64", what does that mean to a user?
The idea was to just separate in two classes: support
On Fri, Feb 10, 2017 at 3:56 AM, Renato Golin wrote:
> On 10 February 2017 at 11:38, Pavel Labath via llvm-dev
> wrote:
>> All I can say is these tests did not exist in 3.9, so I wouldn't call
>> this a regression. (Well... technically, a similar test existed, but
>> it was run by a different tes
Roman,
Thanks for verifying. I am trying to see how far this goes.
It would be interesting to look at the GCC DWARF for this. If you can attach a
copy of the binary, I would like to take a look to see if the DWARF itself has
any offending type info where it sometimes has the 'u' and other times
Yes, you're right. When I replaced unsigned with signed int it works
properly.
2017-02-10 19:46 GMT+03:00 Greg Clayton :
>
> On Feb 10, 2017, at 12:55 AM, Roman Popov wrote:
>
> Thanks Greg,
>
> So here is another case when LLDB fails to resolve dynamic type. Compiled
> with G++5.4 on Ubuntu 16
I believe if the function's visibility is hidden, then there is no need to
create class methods that aren't used. I will check with our linker experts and
get a more comprehensive reply for everyone later today.
> On Feb 10, 2017, at 8:39 AM, Pavel Labath via lldb-dev
> wrote:
>
> Interesting
> On Feb 10, 2017, at 12:55 AM, Roman Popov wrote:
>
> Thanks Greg,
>
> So here is another case when LLDB fails to resolve dynamic type. Compiled
> with G++5.4 on Ubuntu 16.04.
>
> Here I want to get dynamic type for some variable apb_memories
>
> (lldb) expr -d no-run -- apb_memories
> (sc
Interesting. So it looks like something was removing your function. I
don't know much about how linking works on mac, so I cannot say
whether that's supposed to be like that or not. Maybe one of the apple
folks will jump in and enlighten us.
cheers,
pavel
On 10 February 2017 at 16:24, Ramkumar Ra
I got around the problem using attribute used.
Ram
On Fri, Feb 10, 2017 at 9:02 AM Ramkumar Ramachandra
wrote:
> Hi,
>
> Pavel Labath wrote:
>
> a have couple of question to better understand the situation:
> - what is the system you are trying this out on (OS, arch, ...)?
>
>
> macOS, x86_64.
Hi,
Pavel Labath wrote:
>
> a have couple of question to better understand the situation:
> - what is the system you are trying this out on (OS, arch, ...)?
>
macOS, x86_64.
> - are you using any funny compiler options that you think we should
> know about ? (e.g. if you're using -ffunction-se
On 10 February 2017 at 12:30, Ramkumar Ramachandra via lldb-dev
wrote:
> Hi,
>
> This has been the source of much frustration, but I can't quite figure out
> why my toString() member function is not present in the target, according to
> lldb. The other functions in the compile unit are used and pr
Hi,
This has been the source of much frustration, but I can't quite figure out
why my toString() member function is not present in the target, according
to lldb. The other functions in the compile unit are used and present, so
the linker couldn't have eliminated the compile unit. Nor could the
fun
On 10 February 2017 at 11:38, Pavel Labath via llvm-dev
wrote:
> All I can say is these tests did not exist in 3.9, so I wouldn't call
> this a regression. (Well... technically, a similar test existed, but
> it was run by a different test runner which I believe is not hooked up
> to the command yo
Ed may be able to elaborate on lldb+freebsd state of things.
All I can say is these tests did not exist in 3.9, so I wouldn't call
this a regression. (Well... technically, a similar test existed, but
it was run by a different test runner which I believe is not hooked up
to the command you are runn
On 9 February 2017 at 17:55, Diana Picus via llvm-dev
wrote:
> Hi,
>
> AArch64 good to go.
>
> f27db27da7f75a435d89ba63c8a762885fd86a1a
> clang+llvm-4.0.0-rc2-aarch64-linux-gnu.tar.xz
No regressions from the ARM side.
f827daf4b0066f74932090cb6309fcf6be594617
clang+llvm-4.0.0-rc2-armv7a-linux-gnu
Thanks Greg,
So here is another case when LLDB fails to resolve dynamic type. Compiled
with G++5.4 on Ubuntu 16.04.
Here I want to get dynamic type for some variable apb_memories
(lldb) expr -d no-run -- apb_memories
(sc_core::sc_object *) $3 = 0x00cb6aa8
(lldb) memory read --format a
15 matches
Mail list logo
