search for: char_bits

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

> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of JF Bastien via [..] > Is it relevant 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

On Fri, Oct 19, 2012 at 9:27 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Oct 19, 2012, at 2:24 AM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: > >>> non-8-bit byte > > I'm a bit confused by this concept. I'm aware of the archaic meaning of the word byte, but it has meant 8 bits for the last 30 years. There's even an

On Oct 19, 2012, at 10:47 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Oct 19, 2012 at 9:27 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> >> On Oct 19, 2012, at 2:24 AM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: >> >>>> non-8-bit byte >> >> I'm a bit confused by this concept.

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

On Oct 19, 2012, at 11:43 AM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: >> 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

> 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

1) FLAC supports only MSVS 2005 and newer, so (_MSC_VER >= 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 -

On Wed, 2019-10-30 at 15:30 -0700, Chris Lattner via llvm-dev wrote: > > On Oct 30, 2019, at 3:07 AM, Jeroen Dobbelaere via llvm-dev < > > llvm-dev at lists.llvm.org> wrote: > > > > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of JF > > > Bastien via > > > > [..] > > > Is it relevant to any modern compiler

...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 ex...

VIRTIO_F_NOTIFY_ON_EMPTY indicates to the Guest that we will hit them with an interrupt every time the xmit queue is emptied. Because it results in lots of tx interrupts, modern Guests probably don't want it, so let's only force it when they accept the option. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- Documentation/lguest/lguest.c | 27

VIRTIO_F_NOTIFY_ON_EMPTY indicates to the Guest that we will hit them with an interrupt every time the xmit queue is emptied. Because it results in lots of tx interrupts, modern Guests probably don't want it, so let's only force it when they accept the option. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- Documentation/lguest/lguest.c | 25 +++++++++++++++++++++----

VIRTIO_F_NOTIFY_ON_EMPTY indicates to the Guest that we will hit them with an interrupt every time the xmit queue is emptied. Because it results in lots of tx interrupts, modern Guests probably don't want it, so let's only force it when they accept the option. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- Documentation/lguest/lguest.c | 27

VIRTIO_F_NOTIFY_ON_EMPTY indicates to the Guest that we will hit them with an interrupt every time the xmit queue is emptied. Because it results in lots of tx interrupts, modern Guests probably don't want it, so let's only force it when they accept the option. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> --- Documentation/lguest/lguest.c | 25 +++++++++++++++++++++----

Commit-ID: c36feecd03749ebe7eccb7556c5fc5d38bd88dfd Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=c36feecd03749ebe7eccb7556c5fc5d38bd88dfd Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Fri, 23 Mar 2018 18:58:47 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 25 Jan 2019 02:57:21 +0000 [klibc] expand: Fix ghost

Commit-ID: 887c4118916c8ee1aff8cdefbb691bd835c6566e Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=887c4118916c8ee1aff8cdefbb691bd835c6566e Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Fri, 23 Mar 2018 18:58:47 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:54 +0000 [klibc] dash: expand: Fix

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

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

Commit-ID: 77604985dadef38bdaf251e3898a0b2ef33ea08e Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=77604985dadef38bdaf251e3898a0b2ef33ea08e Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Thu, 1 Jan 2015 07:53:10 +1100 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 25 Jan 2019 02:57:21 +0000 [klibc] expand: Fixed

Commit-ID: 57da2c169d4f22009725f47645ca6a4501f2475f Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=57da2c169d4f22009725f47645ca6a4501f2475f Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Thu, 1 Jan 2015 07:53:10 +1100 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:54 +0000 [klibc] dash: expand: Fixed