search for: unportabilities

On Mon, Dec 05, 2011 at 07:18:36PM -0800, Peter Cooper wrote: > It would be nice to add support for placing globals at fixed addresses in memory. I don't know. From my experience, the usefulness is very, very limited. As in: drivers are about the only thing that can make use of it. > For example, low level driver code tends to contain things like this > > *(int*)0x00001000

Hi all It would be nice to add support for placing globals at fixed addresses in memory. For example, low level driver code tends to contain things like this *(int*)0x00001000 which is horrible. Alternatively people are using linker scripts and assembly hacks to put symbols at fixed addresses. I propose we add first class support to this in the compiler. Like addrspace(#) we should have

Hello all, As of now, all LLVM and Clang tests have been updated/addressed to run under the new/experimental pass manager (at least the ones that failed when using the new PM). For those who aren't aware of what the new pass manager (PM) is, the tl;dr is that this will serve as a replacement for the legacy PM, and promises faster build times by restructuring how passes are run over IR units.

Hello Everyone, I am an avid Sweave user and I am trying to pretty print floating point numbers for latex output. For example in my document, I would like: 4.2\cdot 10^-{8} Instead of: 4.2e-08 The Hmisc package has a nice function for doing this- but Hmisc has a ton of dependencies and has proved very unportable to the various machines I work on. So, I set out to write my own function that

Just my two cents: Anyone thought of asking Red Hat to use documentation? I think they are getting much from the community so to copy public accessible documentation when permitted by RH could be an easy way. Why not giving that a try? Am 18. Januar 2015 20:56:59 MEZ, schrieb Darr247 <darr247 at gmail.com>: >On 18 January 2015 @19:07 zulu, Mark LaPierre wrote: >> good at C or C++

...d language. Unfortunately we are running into some problems with dependencies on libc since it is different on every operating system. The Mac, for example, defines stdin as a macro in stdio.h. Is there going to be a collection of precompiled headers for Clang that will abstract away some of the unportabilities of C from a runtime perspective using aliases and inlines in the place of macros? If not, will the proposed type system for LLVM 3.0 solve some of these problems? I'm hoping to avoid needing the runtime libraries of each programming language we're supporting. I also cannot be allowed to...

I think so far most individual projects have their own statistics on build time/performance impact on switching to the new PM, but I agree that there should at least be one place that people can reference on the impact. On Fri, Aug 2, 2019 at 1:14 PM Philip Reames <listmail at philipreames.com> wrote: > Thanks for all the hard work that went into getting it here. > > +1 > >

(resent due to mailing list breakage) On Dec 6, 2011, at 6:55 AM, Joerg Sonnenberger wrote: > On Mon, Dec 05, 2011 at 07:18:36PM -0800, Peter Cooper wrote: >> It would be nice to add support for placing globals at fixed addresses in memory. > > I don't know. From my experience, the usefulness is very, very limited. > As in: drivers are about the only thing that can make

I believe a good amount of them (if not most of them) have already been ported! Off the top of my head, I remember that asan, tsan, msan, hwasan, the kernel santizers, and sancov have been ported. I don't think ubsan has been ported yet though. You can also check if other passes you need run under the new PM by checking PassRegistry.def. On Fri, Aug 2, 2019, 14:20 Jordan Rupprecht

On 2/28/16, Linus Torvalds <torvalds at linux-foundation.org> wrote: > The fact is, undefined compiler behavior is never a good idea. Not for > serious projects. Actually, undefined behavior is essential for serious projects, but not for the reasons mentioned. If the language has no undefined behavior, then from the compiler's view, there is no such thing as a bad program. All

We have: ---------------------------------------------------------------------- typedef unsigned long uint4; ---------------------------------------------------------------------- which on an LP64 system is a lie. If uint4 is used on disk (and it's used in the btree implementation) then it would make the databases unportable, which probably isn't a good idea (unless we already have

Hi, Recently added to doc/NEWS.Rd: 'R CMD check' now gives a warning rather than a note if it finds inefficiently compressed datasets. With 'bzip2' and 'xz' compression having been available since R 2.10.0, there is no excuse for not using them. Why isn't a note enough for this? Generally speaking, warnings are for things that are dangerous, or unsafe,

> > p.s. For an in depth analysis of TCP_CORK read Christiopher Baus' excelent > article: http://www.baus.net/on-tcp_cork Thanks for this pointer. I'd been meaning to reply on this thread, but hadn't got around to it, primarily because I didn't really understand TCP_CORK (the linux manpage is, as usual, fairly unclear on what exactly it does). Now I understand! > >

This one may well be the first fully capable audio/midi DAW program to work in both Windows and Linux. This is because it is not based on Microsoft's framework. I got the freebie while this offer was around. Version 2 is supposed to come out soon. (I presently use Cakewalk Home Studio--Sonar's not so little sister and a lot of bang for the buck. I have gotten used to drawing

On 01/19/2015 10:51 AM, Tim wrote: > Just my two cents: Anyone thought of asking Red Hat to use > documentation? I think they are getting much from the community so > to copy public accessible documentation when permitted by RH could be > an easy way. > > Why not giving that a try? There's no need to ask them, they've already given permission: > Copyright ? 2014

Hello Dovecot users, Not much Sieve development was done in the last five weeks, but some important platform-dependent bugs were found and repaired. The main new feature is the addition of a custom Sieve language extension for debugging in the Sieve command line tools. Changelog Sieve v0.1.4: * Started work on the sieve-filter tool. With this command line tool it will be possible to

xf86-input-evdev 2.11 is now available. Notable changes include: - FTBFS fixes on non-linux platforms and dropping some ancient quirks - Fixes for the Compose and Kana LEDs - we remap some higher keycodes to FK20 and friends, paving the way for systemd/udev to map those properly in their hwdb files And a few years of accumulated cleanup as a result of the gitlab migration. Alan Coopersmith

Hello Dovecot users, Not much Sieve development was done in the last five weeks, but some important platform-dependent bugs were found and repaired. The main new feature is the addition of a custom Sieve language extension for debugging in the Sieve command line tools. Changelog Sieve v0.1.4: * Started work on the sieve-filter tool. With this command line tool it will be possible to

Citeren Arnaud Quette <aquette.dev op gmail.com>: > Date: Thu, 09 Dec 2010 14:01:14 +0000 > Subject: svn commit r2726 - in branches/windows_port: common drivers include > Author: fbohe-guest > Date: Thu Dec 9 14:01:07 2010 > New Revision: 2726 > URL: http://trac.networkupstools.org/projects/nut/changeset/2726 > > Log: > More work on serial drivers. > Still

Hi All I have just published a module that synchronises users and groups from Active Directory into a Puppet manifest, which can then be rolled out to subscribed agents/workstations. The module maintains generated uids and gids in an SQLite database. It has only been tested on Puppet Enterprise 2.6.1 and RHEL 6.3 so far, at my end. The module is called lpep and you can view it at