search for: wglobal

...following use case also prohibited? int findNameId(StringRef Name) { static StringMap<int> Map = createSomeIDMap(); return Map.lookup(Name); }; It seems it isn't influence startup time and doesn't create initialization order problems. Clang isn't complaining about it with -Wglobal-constructor flag. I'm asking because under some interpretation of rule wording it can be called static constructor too. Thanks, Valery -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160309/a4715848/att...

...;> { >> static StringMap<int> Map = createSomeIDMap(); >> return Map.lookup(Name); >> }; >> >> It seems it isn't influence startup time and doesn't create >> initialization order problems. Clang isn't complaining about it with >> -Wglobal-constructor flag. >> >> I'm asking because under some interpretation of rule wording it can be >> called static constructor too. >> >> Thanks, >> Valery >> >> _______________________________________________ >> LLVM Developers mailing list &g...

...-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fvisibility-inlines-hidden -fno-function-sections -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fPIE -fno-rtti -msse3 -Wframe-larger-than=512 -Wglobal-constructors --sysroot=. -MMD -MT projects/compiler-rt/lib/tsan/CMakeFiles/clang_rt.tsan-x86_64.dir/rtl/tsan_interceptors.cc.o -MF projects/compiler-rt/lib/tsan/CMakeFiles/clang_rt.tsan-x86_64.dir/rtl/tsan_interceptors.cc.o.d -o projects/compiler-rt/lib/tsan/CMakeFiles/clang_rt.tsan-x86_64.dir/rtl/...

...Map = createSomeIDMap(); >>>> return Map.lookup(Name); >>>> }; >>>> >>>> It seems it isn't influence startup time and doesn't create >>>> initialization order problems. Clang isn't complaining about it with >>>> -Wglobal-constructor flag. >>>> >>>> I'm asking because under some interpretation of rule wording it can be >>>> called static constructor too. >>>> >>>> Thanks, >>>> Valery >>>> >>>> ________________________...

...-unused-parameter -m64 -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fno-rtti -Wframe-larger-than=570 -Wglobal-constructors -DSANITIZER_SUPPORTS_WEAK_HOOKS=0 -MD -MT projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoHooks.x86_64.dir/sanitizer_linux.cc.o -MF projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoHooks.x86_64.dir/sanitizer_linux.cc.o.d -o projects/compil...

...all -std=c++11 -m32 -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fvisibility=hidden -fno-function-sections -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fno-rtti -Wframe-larger-than=512 -Wglobal-constructors -MMD -MT projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.i386.dir/sanitizer_platform_limits_posix.cc.o -MF projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.i386.dir/sanitizer_platform_limits_posix.cc.o.d -o projects/compiler-rt/lib/sani...

I'd just like to throw my 2 cents in here. I can understand the need to drop a xiph irc server. However, I do take issue with moving to Freenode. The reason that we moved so long ago (as I understand it) is that an overwhelming flood of politics made real vorbis discussion uncomfortable. A few people took things personally and acted out, and pretty soon everybody was on edge. Just looking

I'd just like to throw my 2 cents in here. I can understand the need to drop a xiph irc server. However, I do take issue with moving to Freenode. The reason that we moved so long ago (as I understand it) is that an overwhelming flood of politics made real vorbis discussion uncomfortable. A few people took things personally and acted out, and pretty soon everybody was on edge. Just looking

Hi Kostya, One unexpected piece of fallout in your recent attributes change (r148553) was that it introduced a bunch of static constructors into .o files that #include Attributes.h, due to stuff like this: const Attributes None (0); ///< No attributes have been set const Attributes ZExt (1<<0); ///< Zero extended before/after call const Attributes SExt