similar to: [LLVMdev] RTTI handling

On Sep 30, 2011, at 9:15 AM, Somorjai, Akos wrote: > I was wondering how llvm and clang handles the RTTI shared libraries issue mentioned here: http://gcc.gnu.org/faq.html#dso This is really a Clang question and so belongs on cfe-dev. > Is it using name or address comparison? Clang strives for interoperability with GCC, which means we use address comparison on targets where GCC does.

John, Is there any progress regarding RTTI handling in the newer builds? Thanks, Akos From: John McCall <rjmccall at apple.com<mailto:rjmccall at apple.com>> Date: Wednesday, October 5, 2011 7:14 PM To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at graphisoft.com>> Cc: "llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>" <llvmdev

Thanks! Yes, we are trying to avoid that situation as much as possible. Is there any compiler/linker/static analyzer option that would point out those problems (in 13 million lines, large part of that being legacy code)? Currently I don't know any better way than runtime logging and asserting. Also, what shall we do we external source libraries (like Teigha from Open Design Alliance), where

Apple clang version 3.0 (tags/Apple/clang-211.9) (based on LLVM 3.0svn) Target: x86_64-apple-darwin10.8.0 It's part of the Xcode 4.2b7 package. Shall I try to compile it on my own? Thanks, Akos From: John McCall <rjmccall at apple.com<mailto:rjmccall at apple.com>> Date: Mon, 3 Oct 2011 10:19:04 -0700 To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at

Thanks, John. I'll experiment with both the warning and the nm-weak external tool, and let you know the results. Best, Akos From: John McCall <rjmccall at apple.com<mailto:rjmccall at apple.com>> Date: Fri, 30 Sep 2011 15:24:33 -0700 To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at graphisoft.com>> Cc: "llvmdev at cs.uiuc.edu<mailto:llvmdev

John, The version from the Xcode 4.2 GM package (Apple clang version 3.0 (tags/Apple/clang-211.10.1)) still has the same problem. Which version should I use? Thanks, Akos From: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at graphisoft.com>> Date: Mon, 3 Oct 2011 17:47:06 +0000 To: John McCall <rjmccall at apple.com<mailto:rjmccall at apple.com>> Cc:

On Oct 3, 2011, at 4:42 AM, Somorjai, Akos wrote: > I'm trying to use this warning to check the vtable problem. Here's an example > > In mem.hpp > > class > AA { > // Construction / destruction: > protected: > AA (); > AA (const AA&); // Disabled > public: > virtual ~AA (); > }; > > In mem.cpp > > #include "mem.hpp" >

LLVM does not use RTTI--it has its own mechanisms; see llvm/include/llvm/Support/Casting.h, and by default it is turning off for an LLVM build. Garrison On Sep 30, 2011, at 12:15, Somorjai, Akos wrote: > Hello all, > > I was wondering how llvm and clang handles the RTTI shared libraries issue mentioned here: http://gcc.gnu.org/faq.html#dso > > Is it using name or address

On May 1, 2012, at 11:47 PM, Somorjai, Akos wrote: > Is there any progress regarding RTTI handling in the newer builds? When you're resurrecting six-month-old threads, it's polite to quote some history. :) I don't know offhand what the state of this warning is in Xcode 4.3, and I can't comment on potential future releases. If this matters a lot to you, please just try it and

Happy New Year to everyone! I'm trying to track whether this bug: http://llvm.org/viewvc/llvm-project?revision=163923&view=revision has been fixed in the Apple LLVM version we use: Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) Any ideas how I can check that? Thanks, Ákos Somorjai Developer Support Manager GRAPHISOFT | Graphisoft Park 1. Budapest 1031 Hungary | +36 1

Rather, use this URL for the darwin binaries: http://llvm.org/pre-releases/3.0/ -bw On Nov 25, 2011, at 1:32 AM, Somorjai, Akos wrote: > May I have the darwin binaries as well? > > Best, Akos > > > > On 11/25/11 10:31 AM, "Ákos Somorjai" <asomorjai at graphisoft.com> wrote: > >> Thanks! >> >> Ákos >> >> >>

On Sep 30, 2011, at 3:04 PM, Somorjai, Akos wrote: > Thanks! Yes, we are trying to avoid that situation as much as possible. > > Is there any compiler/linker/static analyzer option that would point out those problems (in 13 million lines, large part of that being legacy code)? There's a -Wweak-vtables which will point out a lot of these cases. I have to warn you that in previous

Hello, Is there a chance to get Darwin 32 bit binaries? On Mon, Nov 28, 2011 at 11:04 AM, Somorjai, Akos <ASomorjai at graphisoft.com> wrote: > Thanks, downloading at the moment. > > Best, > > Ákos > > > On 11/27/11 3:35 AM, "Bill Wendling" <wendling at apple.com> wrote: > >>Rather, use this URL for the darwin binaries: >> >>  

On Oct 5, 2011, at 3:10 AM, Somorjai, Akos wrote: > The version from the Xcode 4.2 GM package (Apple clang version 3.0 (tags/Apple/clang-211.10.1)) still has the same problem. Which version should I use? It looks like you'll have to compile your own from trunk if you want this warning improvement, sorry. Obviously, that's not an Apple-supported option, but it's a

May I have the darwin binaries as well? Best, Akos On 11/25/11 10:31 AM, "Ákos Somorjai" <asomorjai at graphisoft.com> wrote: >Thanks! > >Ákos > > > >On 11/24/11 11:18 PM, "Bill Wendling" <wendling at apple.com> wrote: > >>Sorry for the delay. Tanya uploaded the binaries we have. >> >>-bw >> >>On Nov 23,

Thanks, downloading at the moment. Best, Ákos On 11/27/11 3:35 AM, "Bill Wendling" <wendling at apple.com> wrote: >Rather, use this URL for the darwin binaries: > > http://llvm.org/pre-releases/3.0/ > >-bw > >On Nov 25, 2011, at 1:32 AM, Somorjai, Akos wrote: > >> May I have the darwin binaries as well? >> >> Best, Akos >>

Here's a code generated with -Os on darwin/x86_64 with clang from the Xcode 4.2 GM toolset on Mac OSX 10.7.2 (Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn), Target: x86_64-apple-darwin11.2.0) 0x000000010277d281 <+2102> lea 0x1d43bd0(%rip),%rax # 0x1044c0e58 <gFloorPlanCutData> 0x000000010277d288 <+2109> movaps 0x80(%rax),%xmm0

Thanks, Bob! I guess we should be expecting a 4.2.1 update after clang 3.0 has been released, shouldn't we? Best, Akos From: Bob Wilson <bob.wilson at apple.com<mailto:bob.wilson at apple.com>> Date: Thu, 20 Oct 2011 08:46:38 -0700 To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at graphisoft.com>> Cc: "llvmdev at cs.uiuc.edu<mailto:llvmdev

Thanks! Ákos On 11/24/11 11:18 PM, "Bill Wendling" <wendling at apple.com> wrote: >Sorry for the delay. Tanya uploaded the binaries we have. > >-bw > >On Nov 23, 2011, at 1:12 AM, Somorjai, Akos wrote: > >> Hello Bill, >> >> Could you please upload the rc4 binaries? >> >> Thanks in advance, >> >> Ákos >>

This is http://llvm.org/pr10514 Unfortunately the fix did not make it into that version of clang. On Oct 20, 2011, at 7:47 AM, Somorjai, Akos wrote: > Here's a code generated with -Os on darwin/x86_64 with clang from the Xcode 4.2 GM toolset on Mac OSX 10.7.2 (Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn), Target: x86_64-apple-darwin11.2.0) > >