similar to: [LLVMdev] How to represent zero-sized string?

On Fri, Jan 9, 2009 at 5:40 PM, Evan Cheng <evan.cheng at apple.com> wrote: > The difference seems innocent enough. However, in objc if the zero- > sized string is part of a cfstring, it causes a problem. The linker > expects it in the readonly __cstring section, but llvm puts it in the > read / write bss section. That seems extremely weird... what sort of magic is objc using

There is a problem with Objective-C code where a null string is placed in the wrong section. If we have this code: #include <Foundation/Foundation.h> void foo() { NSLog(@""); } The null string is defined like this: .const .lcomm LC,1,0 ## LC Causing our linker to go nuts, because it expects anonymous strings to be in the __cstring section. I came up with the attached

On Jan 26, 2009, at 4:07 PMPST, Bill Wendling wrote: > There is a problem with Objective-C code where a null string is placed > in the wrong section. If we have this code: > > #include <Foundation/Foundation.h> > void foo() { > NSLog(@""); > } > > The null string is defined like this: > > .const > .lcomm LC,1,0 ## LC > > Causing our

On Mon, Jan 26, 2009 at 4:45 PM, Dale Johannesen <dalej at apple.com> wrote: > > On Jan 26, 2009, at 4:07 PMPST, Bill Wendling wrote: > >> There is a problem with Objective-C code where a null string is placed >> in the wrong section. If we have this code: >> >> #include <Foundation/Foundation.h> >> void foo() { >> NSLog(@"");

Alexander, On Darwin the "__cstring" section (really section with type S_CSTRING_LITERAL) is defined to contain zero terminate strings of bytes that the linker can merge and re-order. If you want pad bytes before and after the string, you need to put the strings in a different section (e.g. __TEXT, __const). But, CF/NSString literals will be problematic. The compiler emits a static

(forgot to CC llvmdev) On Thu, Mar 21, 2013 at 5:54 PM, Alexander Potapenko <glider at google.com> wrote: > Hey Anna, Nick, Ted, > > We've the following problem with string literals under ASan on Mac. > Some global string constants end up being put into the .cstring > section, for which the following rules apply: > - the strings can't contain zeroes in their

The Constants.cpp file returns a ConstantAggregateZero object when you pass it a c"\000" string. Here is the code: Constant *ConstantArray::get(const ArrayType *Ty, const std::vector<Constant*> &V) { // If this is an all-zero array, return a ConstantAggregateZero object if (!V.empty()) { Constant *C = V[0]; if (!C->isNullValue())

On Nov 24, 2008, at 11:07 AM, Chris Lattner wrote: > > On Nov 24, 2008, at 11:01 AM, Bill Wendling wrote: > >> The symbols I'm interested in already have internal linkage (as you >> would expect). But because the mangler is in charge of assigning them >> names, they never seem to be decorated with the 'L' in front. . . . > > If you use

Hi Andrew, it looks like your commit r139842 | atrick | 2011-09-15 22:58:37 +0200 (Thu, 15 Sep 2011) | 2 lines Reapply r139759. Disable IV rewriting by default. See PR10916. broke this buildbot: http://lab.llvm.org:8011/builders/llvm-x86_64-linux-checks The failure is a bootstrap failure of llvm-gcc when comparing object files from stages 2 and 3 (which don't match). I was able

On Oct 15, 2008, at 7:34 PM, Eli Friedman wrote: > This bug actually manifests itself in two places: one is > ConstantMerge, the other is the AsmPrinter. It's non-trivial to fix > because it's really a design bug: we assume that constant==mergeable, > which simply isn't true. There are a few different ways of fixing > this; however, I think the only real option is to

On Oct 15, 2008, at 10:11 PM, Chris Lattner wrote: > Eli, I don't disagree with you on any specific detail here. I think > there are decent solutions to this if anyone cares enough. My only > point is that this is an existing problem with other compilers. On > darwin, for example, x and y can get the same address, because x and y > end up in the 'cstring' section

On Sat, 3 Jul 2004, Chris wrote: > >That should work fine. I'm not familiar at all with internix, but it >appears to have a buggy header or something. From what I understand, >internix is a posix layer for windows. Have you tried compiling under >cygwin? No, not yet. >If you grab the latest CVS sources, they should work fine with >cygwin, and will probably work

Hi all, I would like to combine elements of a vector: vec <- c("astring", "b", "cstring", "d", "e") > vec [1] "astring" "b" "cstring" "d" "e" such that for every element that contains "string" at the end, it is combined with the next element, so that I get this:

> On Jun 26, 2015, at 9:25 PM, Charles Lepple <clepple at gmail.com> wrote: > > On Jun 26, 2015, at 8:35 AM, Sundeep Mediratta <smedius at gmail.com> wrote: > >> OSX Yosemite 10.10.3 >> Nut version 2.6.5 >> Installed via Macports >> Device is Cyberpower CP1000AVRLCD >> Device is visible and is monitored in the OSX control panel >>

OSX Yosemite 10.10.3 Nut version 2.6.5 Installed via Macports Device is Cyberpower CP1000AVRLCD Device is visible and is monitored in the OSX control panel Error- macosx-ups -DD -a cyberpower Network UPS Tools - Mac OS X UPS meta-driver 1.0 (2.6.5-Unversioned directory) Warning: This is an experimental driver. Some features may not function correctly. 0.000000 debug level is '2'

On Jun 27, 2015, at 9:17 AM, Charles Lepple <clepple at gmail.com> wrote: > On Jun 26, 2015, at 11:07 PM, Sundeep Mediratta <smedius at gmail.com> wrote: > >> 0.000233 upsdrv_initups(): Power Sources blob: >> <CFArray 0x7ffd18605480 [0x7fff7443bed0]>{type = immutable, count = 1, values = ( >> 0 : <CFBasicHash 0x7ffd18605360 [0x7fff7443bed0]>{type

Hi Guys I'm trying to port and build LLVM to the Interix environment. I've succeded until the Interix version of gcc program executes: Before the patch: gmake[1]: Entering directory `/usr/local/src/llvm/lib/Support' gmake[1]: Leaving directory `/usr/local/src/llvm/lib/Support' gmake[1]: Entering directory `/usr/local/src/llvm/lib/Support' Compiling CommandLine.cpp

Hi Daniel, attached is a patch that pushes most of the object file specific parsing out of AsmParser and down into MachOAsmParser. This was done as a cleanup for the ELF work. I know that you're not happy with this approach, particularly the fact that as we add more object file formats and assembler dialects, it's going to cause a class explosion. But I was hoping that we could use this

Hi, On Fedora 9 GCC 4.3, LLVMCConfigurationEmitter.cpp needs #include <typeinfo>. ValueTracking.cpp needs #include <cstring>. Thanks. --Zhongxing Xu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080603/38f917f4/attachment.html>

Index: include/llvm/ADT/APInt.h =================================================================== --- include/llvm/ADT/APInt.h (revision 55101) +++ include/llvm/ADT/APInt.h (working copy) @@ -20,6 +20,7 @@ #include <cassert> #include <iosfwd> #include <string> +#include <cstring> namespace llvm { class Serializer; -------------- next part -------------- An