search for: char_bit

On Tue, Oct 29, 2019 at 07:19:25PM +0000, Tim Northover via llvm-dev wrote: > On Tue, 29 Oct 2019 at 19:11, Dmitriy Borisenkov via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > 2. Test with a dummy target. It might work if we have a group of contributors who is willing to rewrite and upstream some of their downstream tests as well as to design and implement the target

...ant to any modern compiler though? > > I strongly agree with Tim. As I said in previous threads, unless people will have > actual testable targets for this type of thing, I think we shouldn’t add > maintenance burden. This isn’t really C or C++ anymore because so much code > assumes CHAR_BIT == 8, or at a minimum CHAR_BIT % 8 == 0, that we’re > supporting a different language. IMO they should use a different language, and > C / C++ should only allow CHAR_BIT % 8 == 0 (and only for small values of > CHAR_BIT). We (Synopsys ASIP Designer team) and our customers tend to disagree...

...d of: > • – 64K Bytes of Dual-Access RAM (DARAM), 8 Blocks of 4K x 16-Bit > • – 192K Bytes of Single-Access RAM (SARAM), 24 Blocks of 4K x 16-Bit > > Perhaps you could begin by defining more accurately what you're talking about? I'm assuming he means an architecture where CHAR_BIT > 8. -Eli

...Bytes of Dual-Access RAM (DARAM), 8 Blocks of 4K x 16-Bit >> • – 192K Bytes of Single-Access RAM (SARAM), 24 Blocks of 4K x 16-Bit >> >> Perhaps you could begin by defining more accurately what you're talking about? > > I'm assuming he means an architecture where CHAR_BIT > 8. AFAIK, CHAR_BIT isn't a property of the architecture, but of the C implementation. One can imagine having two different (non-ABI-compatible) C implementations for the same ISA that define CHAR_BIT differently. --Owen

Hi All I am experiencing a mail download problem with dovecot's pop3 protocol. We use outlook XP 2002 mail clients and I have setup a mail system with pop accounts on a Fedora 2 installation using dovecot. Some of the clients download email fine but others do not download email and also do not give any error messages. I have enabled the "verbose" options in the

...section 3.6): > > addressable unit of data storage large enough to hold any member of the basic character > set of the execution environment That definition isn't really relevant to LLVM, though. You can define char to be (say) 16 bits, and your frontend (clang?) just needs to set CHAR_BIT properly, and generate code with i16 whenever you wrote char. I suspect what you want to talk about, and the part that is relevant to LLVM as opposed to clang, is supporting architectures where the minimum addressable unit is not 8 bits in size. --Owen

> I'm a bit confused by this concept. For the term byte, I use the "archaic" definition in the C (and C++) standard (section 3.6): addressable unit of data storage large enough to hold any member of the basic character set of the execution environment /Patrik Hägglund -----Original Message----- From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] Sent: den 19 oktober

...1400) is always true and can be removed. 2) The argument for FLAC__clz_uint32() is of FLAC__uint32 type, so FLAC__clz_soft_uint32() should have the same argument type. 3) The patch removes unnecessary parentheses around 'word' variable. 4) It also replaces "sizeof(FLAC__uint32) * CHAR_BIT - 1 - FLAC__clz_uint32(v)" with "FLAC__clz_uint32(v) ^ 31U" (and the same for 64-bit version). "sizeof(FLAC__uint32) * CHAR_BIT" must be 32, or the code won't work. So it's simpler to use "31 - FLAC__clz_uint32(v)" or even better, "FLAC__clz_uint32(...

...I said in previous threads, unless > > > people will have > > > actual testable targets for this type of thing, I think we > > > shouldn’t add > > > maintenance burden. This isn’t really C or C++ anymore because so > > > much code > > > assumes CHAR_BIT == 8, or at a minimum CHAR_BIT % 8 == 0, that > > > we’re > > > supporting a different language. IMO they should use a different > > > language, and > > > C / C++ should only allow CHAR_BIT % 8 == 0 (and only for small > > > values of > > > CHAR...

...facing with peripherals that require the use of these instructions. I know this could be handled with intrinsic functions (as with much in LLVM), however this removes the opportunity for globally allocating low cost atomic flags. Modelled as address spaces, p0 and p<bit> would have different CHAR_BITs, of 8 and 1 respectively. This somewhat works as one would expect too, with, ((bit *)&somevalue)[3] producing bit3 of somevalue - at least until the first time you access through a struct or array: gep(addrspacecast(gep p0, 4) to p<bit>, 3) == (p0 + 4) * 8 + 3 As LLVM optimises this e...

...them we used something up. */ @@ -925,6 +930,15 @@ static void create_thread(struct virtque close(vq->eventfd); } +static bool accepted_feature(struct device *dev, unsigned int bit) +{ + const u8 *features = get_feature_bits(dev) + dev->feature_len; + + if (dev->feature_len < bit / CHAR_BIT) + return false; + return features[bit / CHAR_BIT] & (1 << (bit % CHAR_BIT)); +} + static void start_device(struct device *dev) { unsigned int i; @@ -938,6 +952,8 @@ static void start_device(struct device * verbose(" %02x", get_feature_bits(dev) [dev->feature_len+...

...fd, buf, sizeof(buf)) != 0) @@ -1043,6 +1049,15 @@ static void create_thread(struct virtque close(vq->eventfd); } +static bool accepted_feature(struct device *dev, unsigned int bit) +{ + const u8 *features = get_feature_bits(dev) + dev->feature_len; + + if (dev->feature_len < bit / CHAR_BIT) + return false; + return features[bit / CHAR_BIT] & (1 << (bit % CHAR_BIT)); +} + static void start_device(struct device *dev) { unsigned int i; @@ -1056,6 +1071,8 @@ static void start_device(struct device * verbose(" %02x", get_feature_bits(dev) [dev->feature_le...

...them we used something up. */ @@ -925,6 +930,15 @@ static void create_thread(struct virtque close(vq->eventfd); } +static bool accepted_feature(struct device *dev, unsigned int bit) +{ + const u8 *features = get_feature_bits(dev) + dev->feature_len; + + if (dev->feature_len < bit / CHAR_BIT) + return false; + return features[bit / CHAR_BIT] & (1 << (bit % CHAR_BIT)); +} + static void start_device(struct device *dev) { unsigned int i; @@ -938,6 +952,8 @@ static void start_device(struct device * verbose(" %02x", get_feature_bits(dev) [dev->feature_len+...

...fd, buf, sizeof(buf)) != 0) @@ -1043,6 +1049,15 @@ static void create_thread(struct virtque close(vq->eventfd); } +static bool accepted_feature(struct device *dev, unsigned int bit) +{ + const u8 *features = get_feature_bits(dev) + dev->feature_len; + + if (dev->feature_len < bit / CHAR_BIT) + return false; + return features[bit / CHAR_BIT] & (1 << (bit % CHAR_BIT)); +} + static void start_device(struct device *dev) { unsigned int i; @@ -1056,6 +1071,8 @@ static void start_device(struct device * verbose(" %02x", get_feature_bits(dev) [dev->feature_le...

...char **ap; char const *syntax; - int quoted = *quotedp; int subtype = varflags & VSTYPE; int discard = subtype == VSPLUS || subtype == VSLENGTH; int quotes = (discard ? 0 : (flags & QUOTES_ESC)) | QUOTES_KEEPNUL; ssize_t len = 0; + char c; sep = (flags & EXP_FULL) << CHAR_BIT; syntax = quoted ? DQSYNTAX : BASESYNTAX; @@ -928,12 +929,25 @@ numvar: goto param; /* fall through */ case '*': - if (quoted) - sep = 0; - sep |= ifsset() ? ifsval()[0] : ' '; + /* We will set c to 0 or ~0 depending on whether + * we're doing field splitting....

...char **ap; char const *syntax; - int quoted = *quotedp; int subtype = varflags & VSTYPE; int discard = subtype == VSPLUS || subtype == VSLENGTH; int quotes = (discard ? 0 : (flags & QUOTES_ESC)) | QUOTES_KEEPNUL; ssize_t len = 0; + char c; sep = (flags & EXP_FULL) << CHAR_BIT; syntax = quoted ? DQSYNTAX : BASESYNTAX; @@ -928,12 +929,25 @@ numvar: goto param; /* fall through */ case '*': - if (quoted) - sep = 0; - sep |= ifsset() ? ifsval()[0] : ' '; + /* We will set c to 0 or ~0 depending on whether + * we're doing field splitting....

Jeroen Dobbelaere via llvm-dev <llvm-dev at lists.llvm.org> writes: > Hi Jesper, > >> Thanks, these are interesting differences. The CHAR_BIT and byte >> relation is established in the C standard and I would prefer the byte >> terminology. It means the same thing as addressable unit but is a bit >> shorter and probably more widely known. > > Looking purely from a c/c++ language viewpoint, this makes sense. We &gt...

Kevin André wrote: > For my master's thesis, I am trying to cross compile programs for the > PSP (PlayStation Portable) with LLVM and llvm-gcc. > > This is what I do: > > (1) compile a program and the libraries it uses (libpng etc.) with llvm-gcc > (2) link the bitcode files with llvm-ld into one file > (3) run "llc -march=c" on the result > (4) compile

...nd.c index a2f99f14..c04ff6e1 100644 --- a/usr/dash/expand.c +++ b/usr/dash/expand.c @@ -901,6 +901,7 @@ varvalue(char *name, int varflags, int flags, int *quotedp) int quotes = (discard ? 0 : (flags & QUOTES_ESC)) | QUOTES_KEEPNUL; ssize_t len = 0; + sep = (flags & EXP_FULL) << CHAR_BIT; syntax = quoted ? DQSYNTAX : BASESYNTAX; switch (*name) { @@ -931,16 +932,14 @@ numvar: expdest = p; break; case '@': - sep = 0; - if (quoted) + if (quoted && sep) goto param; /* fall through */ case '*': - sep = ifsset() ? ifsval()[0] : ' ...

...nd.c index a2f99f14..c04ff6e1 100644 --- a/usr/dash/expand.c +++ b/usr/dash/expand.c @@ -901,6 +901,7 @@ varvalue(char *name, int varflags, int flags, int *quotedp) int quotes = (discard ? 0 : (flags & QUOTES_ESC)) | QUOTES_KEEPNUL; ssize_t len = 0; + sep = (flags & EXP_FULL) << CHAR_BIT; syntax = quoted ? DQSYNTAX : BASESYNTAX; switch (*name) { @@ -931,16 +932,14 @@ numvar: expdest = p; break; case '@': - sep = 0; - if (quoted) + if (quoted && sep) goto param; /* fall through */ case '*': - sep = ifsset() ? ifsval()[0] : ' ...