% readelf -V list* Version symbols section '.gnu.version' contains 27 entries: Addr: 00000000004007ce Offset: 0x0007ce Link: 6 (.dynsym) 000: 0 (*local*) 1 (*global*) 1 (*global*) 1 (*global*) 004: 0 (*local*) 4 (GLIBC_2.0) 1 (*global*) 1 (*global*) 008: 1 (*global*) 2 (GLIBCXX_3.4) 9 (GCC_3.0) 7 (GLIBCXX_3.4.9) 00c: 6 (GLIBC_2.2) 2 (GLIBCXX_3.4) 5 (GLIBCXX_3.4.14) 2 (GLIBCXX_3.4) 010: 5 (GLIBCXX_3.4.14) 2 (GLIBCXX_3.4) 5 (GLIBCXX_3.4.14) 4 (GLIBC_2.0) 014: 2 (GLIBCXX_3.4) 2 (GLIBCXX_3.4) 3 (GLIBCXX_3.4.11) 2 (GLIBCXX_3.4) 018: 0 (*local*) 2 (GLIBCXX_3.4) 8 (CXXABI_1.3)
Version needs section '.gnu.version_r' contains 3 entries: Addr: 0x0000000000400804 Offset: 0x000804 Link: 7 (.dynstr) 000000: Version: 1 File: libgcc_s.so.1 Cnt: 1 0x0010: Name: GCC_3.0 Flags: none Version: 9 0x0020: Version: 1 File: libc.so.6 Cnt: 2 0x0030: Name: GLIBC_2.2 Flags: none Version: 6 0x0040: Name: GLIBC_2.0 Flags: none Version: 4 0x0050: Version: 1 File: libstdc++.so.6 Cnt: 5 0x0060: Name: CXXABI_1.3 Flags: none Version: 8 0x0070: Name: GLIBCXX_3.4.9 Flags: none Version: 7 0x0080: Name: GLIBCXX_3.4.14 Flags: none Version: 5 0x0090: Name: GLIBCXX_3.4.11 Flags: none Version: 3 0x00a0: Name: GLIBCXX_3.4 Flags: none Version: 2 ________________________________________ From: [email protected] [[email protected]] on behalf of [email protected] [[email protected]] Sent: Wednesday, April 25, 2012 2:57 PM To: [email protected] Subject: cfe-commits Digest, Vol 58, Issue 248 Send cfe-commits mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of cfe-commits digest..." Today's Topics: 1. Re: [PATCH] Implicit fall-through between switch labels (Alexander Kornienko) 2. Re: [patch] include_next <float.h> on windows for _msc_ver too, not just for __mingw32__ (Jordan Rose) 3. Re: [patch] include_next <float.h> on windows for _msc_ver too, not just for __mingw32__ (Nico Weber) 4. Re: r155585 - in /cfe/trunk/test/Rewriter: rewrite-byref-in-nested-blocks.mm rewrite-modern-block-consts.mm rewrite-modern-captured-nested-bvar.mm rewrite-modern-extern-c-func-decl.mm rewrite-rewritten-initializer.mm (Eric Christopher) 5. RecursiveASTVisitor: visit all implicit template specializations with the primary template (Richard Smith) ---------------------------------------------------------------------- Message: 1 Date: Wed, 25 Apr 2012 23:08:49 +0200 From: Alexander Kornienko <[email protected]> Subject: Re: [cfe-commits] [PATCH] Implicit fall-through between switch labels To: [email protected] Message-ID: <caoweq9lnjmf7kow-tbfmrden1k44hs6dg_+jkao6fnhd1xj...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hi, On Wed, Apr 25, 2012 at 6:12 PM, Alexander Kornienko <[email protected]>wrote: > The new version of patch addresses most of the issues discussed here + > refactored code ;) > More specifically, changes in this version of patch: * diagnostic message reworded; each warning is accompanied by exactly one note with a fix-it hint, for simplicity and consistency the location to insert fall-through annotation is always immediately before the relevant case label: test.cpp:16:5: warning: unannotated fall-through between switch labels [-Wimplicit-fallthrough] case 13: ^ test.cpp:16:5: note: insert [[fallthrough]]; to silence this warning [-Wimplicit-fallthrough] case 13: ^ [[fallthrough]]; * added specific diagnostic message for unreachable fall-through annotation, e.g. this code: switch(x) { case 1: break; [[fallthrough]]; case 2: ... will produce a similar warning: test.cpp:12:7: warning: fallthrough annotation in unreachable code [-Wimplicit-fallthrough] [[fallthrough]]; ^ There are also a couple of ideas from Jordy Rose, which I would like to implement, but didn't have time yet. -- Best regards, Alexander Kornienko -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-commits/attachments/20120425/1ae0e7fc/attachment-0001.html ------------------------------ Message: 2 Date: Wed, 25 Apr 2012 17:14:50 -0400 From: Jordan Rose <[email protected]> Subject: Re: [cfe-commits] [patch] include_next <float.h> on windows for _msc_ver too, not just for __mingw32__ To: Matthieu Monrocq <[email protected]> Cc: "[email protected] Commits" <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain; charset=iso-8859-1 On Apr 25, 2012, at 14:32, Matthieu Monrocq wrote: > I know of two mechanism in lit: > > - REQUIRES (such as REQUIRES: shell) > - XFAIL (such as XFAIL: mingw, win32) > > I do not know if REQUIRES could be used with platforms (as XFAIL) and > blacklisting does not seem very interesting... > > Is there a set of builtin such as __has_include that would detect whether an > include_next exist ? > > -- Matthieu I believe there is, in fact, a __has_include_next. You can see the usage in has_include.c. Jordy ------------------------------ Message: 3 Date: Wed, 25 Apr 2012 14:38:24 -0700 From: Nico Weber <[email protected]> Subject: Re: [cfe-commits] [patch] include_next <float.h> on windows for _msc_ver too, not just for __mingw32__ To: Jordan Rose <[email protected]> Cc: "[email protected] Commits" <[email protected]> Message-ID: <CAMGbLiHi1VQ=X0g+Zp=czu4qngam_hhs1bbaux-j4tavecm...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 25, 2012 at 2:14 PM, Jordan Rose <[email protected]> wrote: > > On Apr 25, 2012, at 14:32, Matthieu Monrocq wrote: >> I know of two mechanism in lit: >> >> - REQUIRES (such as REQUIRES: shell) >> - XFAIL (such as XFAIL: mingw, win32) >> >> I do not know if REQUIRES could be used with platforms (as XFAIL) and >> blacklisting does not seem very interesting... >> >> Is there a set of builtin such as __has_include that would detect whether an >> include_next exist ? >> >> -- Matthieu > > I believe there is, in fact, a __has_include_next. You can see the usage in > has_include.c. Is a test that only tests something interesting on a small subset of developer machines useful though? > > Jordy > > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ------------------------------ Message: 4 Date: Wed, 25 Apr 2012 14:55:43 -0700 From: Eric Christopher <[email protected]> Subject: Re: [cfe-commits] r155585 - in /cfe/trunk/test/Rewriter: rewrite-byref-in-nested-blocks.mm rewrite-modern-block-consts.mm rewrite-modern-captured-nested-bvar.mm rewrite-modern-extern-c-func-decl.mm rewrite-rewritten-initializer.mm To: Fariborz Jahanian <[email protected]> Cc: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; CHARSET=US-ASCII This looks like it's failing on the bots. I'll send the url in private. Can you take a look please? Thanks! -eric On Apr 25, 2012, at 1:48 PM, Fariborz Jahanian <[email protected]> wrote: > Author: fjahanian > Date: Wed Apr 25 15:48:00 2012 > New Revision: 155585 > > URL: http://llvm.org/viewvc/llvm-project?rev=155585&view=rev > Log: > objective-c modern translator: more tests. > > > Added: > cfe/trunk/test/Rewriter/rewrite-modern-block-consts.mm > cfe/trunk/test/Rewriter/rewrite-modern-captured-nested-bvar.mm > Modified: > cfe/trunk/test/Rewriter/rewrite-byref-in-nested-blocks.mm > cfe/trunk/test/Rewriter/rewrite-modern-extern-c-func-decl.mm > cfe/trunk/test/Rewriter/rewrite-rewritten-initializer.mm > > Modified: cfe/trunk/test/Rewriter/rewrite-byref-in-nested-blocks.mm > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Rewriter/rewrite-byref-in-nested-blocks.mm?rev=155585&r1=155584&r2=155585&view=diff > ============================================================================== > --- cfe/trunk/test/Rewriter/rewrite-byref-in-nested-blocks.mm (original) > +++ cfe/trunk/test/Rewriter/rewrite-byref-in-nested-blocks.mm Wed Apr 25 > 15:48:00 2012 > @@ -1,7 +1,7 @@ > // RUN: %clang_cc1 -x objective-c++ -Wno-return-type -fblocks -fms-extensions > -rewrite-objc -fobjc-fragile-abi %s -o %t-rw.cpp > // RUN: %clang_cc1 -fsyntax-only -fblocks -Wno-address-of-temporary > -D"SEL=void*" -D"__declspec(X)=" %t-rw.cpp > // RUN: %clang_cc1 -x objective-c++ -Wno-return-type -fblocks -fms-extensions > -rewrite-objc %s -o %t-modern-rw.cpp > -// RUN: %clang_cc1 -fsyntax-only -Wno-address-of-temporary -D"SEL=void*" > -D"__declspec(X)=" %t-modern-rw.cpp > +// RUN: %clang_cc1 -fsyntax-only -Werror -Wno-address-of-temporary > -D"SEL=void*" -D"__declspec(X)=" %t-modern-rw.cpp > // radar 7692350 > > void f(void (^block)(void)); > > Added: cfe/trunk/test/Rewriter/rewrite-modern-block-consts.mm > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Rewriter/rewrite-modern-block-consts.mm?rev=155585&view=auto > ============================================================================== > --- cfe/trunk/test/Rewriter/rewrite-modern-block-consts.mm (added) > +++ cfe/trunk/test/Rewriter/rewrite-modern-block-consts.mm Wed Apr 25 > 15:48:00 2012 > @@ -0,0 +1,19 @@ > +// RUN: %clang_cc1 -x objective-c++ -Wno-return-type -fblocks > -fms-extensions -rewrite-objc %s -o %t-modern-rw.cpp > +// RUN: %clang_cc1 -fsyntax-only -Werror -Wno-address-of-temporary > -D"__declspec(X)=" %t-modern-rw.cpp > +// rdar:// 8243071 > + > +void x(int y) {} > +void f() { > + const int bar = 3; > + int baz = 4; > + __block int bab = 4; > + __block const int bas = 5; > + void (^b)() = ^{ > + x(bar); > + x(baz); > + x(bab); > + x(bas); > + b(); > + }; > + b(); > +} > > Added: cfe/trunk/test/Rewriter/rewrite-modern-captured-nested-bvar.mm > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Rewriter/rewrite-modern-captured-nested-bvar.mm?rev=155585&view=auto > ============================================================================== > --- cfe/trunk/test/Rewriter/rewrite-modern-captured-nested-bvar.mm (added) > +++ cfe/trunk/test/Rewriter/rewrite-modern-captured-nested-bvar.mm Wed Apr 25 > 15:48:00 2012 > @@ -0,0 +1,35 @@ > +// RUN: %clang_cc1 -E %s -o %t.mm > +// RUN: %clang_cc1 -x objective-c++ -fblocks -fms-extensions -rewrite-objc > %t.mm -o - | FileCheck %s > +// rdar://9006279 > + > +void q(void (^p)(void)) { > + p(); > +} > + > +void f() { > + __block char BYREF_VAR_CHECK = 'a'; > + __block char d = 'd'; > + q(^{ > + q(^{ > + __block char e = 'e'; > + char l = 'l'; > + BYREF_VAR_CHECK = 'b'; > + d = 'd'; > + q(^{ > + e = '1'; > + BYREF_VAR_CHECK = '2'; > + d = '3'; > + } > + ); > + }); > + }); > +} > + > +int main() { > + f(); > + return 0; > +} > + > +// CHECK 2: (__Block_byref_BYREF_VAR_CHECK_0 *)BYREF_VAR_CHECK > +// CHECK: {(void*)0,(__Block_byref_BYREF_VAR_CHECK_0 *)&BYREF_VAR_CHECK, 0, > sizeof(__Block_byref_BYREF_VAR_CHECK_0), 'a'} > +// CHECK: __Block_byref_BYREF_VAR_CHECK_0 *)&BYREF_VAR_CHECK, > (__Block_byref_d_1 *)&d, 570425344)); > > Modified: cfe/trunk/test/Rewriter/rewrite-modern-extern-c-func-decl.mm > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Rewriter/rewrite-modern-extern-c-func-decl.mm?rev=155585&r1=155584&r2=155585&view=diff > ============================================================================== > --- cfe/trunk/test/Rewriter/rewrite-modern-extern-c-func-decl.mm (original) > +++ cfe/trunk/test/Rewriter/rewrite-modern-extern-c-func-decl.mm Wed Apr 25 > 15:48:00 2012 > @@ -70,3 +70,27 @@ > > // rdar://11314329 > static inline const void *auto_zone_base_pointer(void *zone, const void *ptr) > { return 0; } > + > +@interface I > +{ > + id list; > +} > +- (void) Meth; > +// radar 7589385 use before definition > +- (void) allObjects; > +@end > + > +@implementation I > +// radar 7589385 use before definition > +- (void) allObjects { > + __attribute__((__blocks__(byref))) id *listp; > + > + void (^B)(void) = ^(void) { > + *listp++ = 0; > + }; > + > + B(); > +} > +- (void) Meth { __attribute__((__blocks__(byref))) void ** listp = (void > **)list; } > +@end > + > > Modified: cfe/trunk/test/Rewriter/rewrite-rewritten-initializer.mm > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Rewriter/rewrite-rewritten-initializer.mm?rev=155585&r1=155584&r2=155585&view=diff > ============================================================================== > --- cfe/trunk/test/Rewriter/rewrite-rewritten-initializer.mm (original) > +++ cfe/trunk/test/Rewriter/rewrite-rewritten-initializer.mm Wed Apr 25 > 15:48:00 2012 > @@ -1,5 +1,7 @@ > // RUN: %clang_cc1 -x objective-c++ -Wno-return-type -fblocks -fms-extensions > -rewrite-objc -fobjc-fragile-abi %s -o %t-rw.cpp > // RUN: %clang_cc1 -fsyntax-only -Wno-address-of-temporary -D"SEL=void*" > -D"__declspec(X)=" %t-rw.cpp > +// RUN: %clang_cc1 -x objective-c++ -Wno-return-type -fblocks > -fms-extensions -rewrite-objc %s -o %t-rw-modern.cpp > +// RUN: %clang_cc1 -fsyntax-only -Werror -Wno-address-of-temporary > -D"SEL=void*" -D"__declspec(X)=" %t-rw-modern.cpp > // radar 7669784 > > typedef void * id; > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits ------------------------------ Message: 5 Date: Wed, 25 Apr 2012 14:57:45 -0700 From: Richard Smith <[email protected]> Subject: [cfe-commits] RecursiveASTVisitor: visit all implicit template specializations with the primary template To: cfe-commits <[email protected]> Message-ID: <CAOfiQqn-CJNORgO=mzmabuc+fonve0j3bjpwsnoq03dgt4m...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hi, Our current strategy is that RecursiveASTVisitor attempts to visit template specializations as part of visiting the template from which the specializations are instantiated. This goes wrong for a partial specialization of a member template of a class template: template<typename T> struct A { template<typename U> struct B; }; template<typename T> template<typename U> struct A<T>::B<U*> {}; Here, it's not trivial to find the specializations which are instantiated from the partial specialization, and the RecursiveASTVisitor fails to find them. A somewhat-related problem is that we do not visit template specializations where we have instantiated the declaration but not the definition. In such cases, we do not know (and, from the RecursiveASTVisitor, cannot reasonably compute) which primary template or partial specialization an instantiated declaration should be associated with, so the existing strategy cannot be applied there. I propose that we fix both of these issues by visiting all implicit instantiations of a template (including cases where we have not instantiated a definition) when we visit the primary template; a patch implementing this is attached. This conflicts with the chosen direction from when this functionality was added [1], so I'd like to hear any concerns with this direction. Thanks! Richard [1] http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100830/033977.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cs.uiuc.edu/pipermail/cfe-commits/attachments/20120425/2fd9616c/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: visit-all-specializations.diff Type: application/octet-stream Size: 9920 bytes Desc: not available Url : http://lists.cs.uiuc.edu/pipermail/cfe-commits/attachments/20120425/2fd9616c/attachment.obj ------------------------------ _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits End of cfe-commits Digest, Vol 58, Issue 248 ******************************************** _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
