search for: underspecifi

On 18 April 2018 at 18:13, Manoj Gupta via cfe-dev <cfe-dev at lists.llvm.org> wrote: > Therefore, I would like to implement support for this flag (maybe with a > different name), I'd suggest -mdo-what-i-mean; the whole idea is horribly underspecified, and basically rips up the LangRef in favour of a nebulous set of good and bad optimizations (probably as dictated by the ones that have bitten someone who wrote bad code recently and was grumpy enough about it to complain at us). In particular I'm skeptical that the address space solution a...

...ave the flexibility to identify the want_init_on_free case so we can > > work around it. > > I don't have a too strong opinion here, but this sounds like one of the > improvements we wanted to have for free page hinting, but learned that > it's not possible because it was *underspecified*. Right. For free page hinting it is underspecified. By defining a tight relationship between free page reporting and page poison we might be able to better handle those sorts of cases. I suspect there may be interest in having free page reporting eventually take on many of the responsibilities...

On Wed, Feb 6, 2013 at 3:01 PM, Sean Silva <silvas at purdue.edu> wrote: > IMO, any functional/correctness difference between an incremental and > clean build should be considered a build system bug, If your (c)makefile underspecifies dependencies, there's nothing the build system can do. > especially for > C++ projects where incremental vs. clean can mean 10 second vs 30 > minute build times. > > -- Sean Silva > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs...

On 11/14/2017 11:30 AM, Richard W.M. Jones wrote: > This was underspecified before. > --- > docs/nbdkit-plugin.pod | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > +=head1 SHUTDOWN > + > +When nbdkit receives certain signals it will shut down (see > +L<nbdkit(1)/SIGNALS>). The server will wait for any currently running > +plug...

The current specification of the behavior of the !nontemporal attribute in LLVM, and the __builtin_nontemporal_* functions in Clang, is rather spartan and underspecified. In effect, it says the following things: * Atomic !nontemporal has no defined semantics * !nontemporal may use special instructions to save cache bandwidth, such as "MOVNT" on x86. What is crucially lacking from this specification is its effects in relation to other memory or...

...me. -Hal On Apr 28, 2020, at 2:42 PM, Cranmer, Joshua <joshua.cranmer at intel.com<mailto:joshua.cranmer at intel.com>> wrote: The current specification of the behavior of the !nontemporal attribute in LLVM, and the __builtin_nontemporal_* functions in Clang, is rather spartan and underspecified. In effect, it says the following things: * Atomic !nontemporal has no defined semantics * !nontemporal may use special instructions to save cache bandwidth, such as “MOVNT” on x86. What is crucially lacking from this specification is its effects in relation to other memory ordering co...

Hi, This is regarding support for -fno-delete-null-pointer-checks in clang (PR 9251). Linux kernel uses this flag to keep null pointer checks from getting optimized away. Since clang does not currently support this flag, it often invites comments from kernel devs that clang is not yet *ready* to compile Linux kernel. I have also heard that developers working on firmware, bare-metal tools and

...nnot share a vector element across two values. For example, representing you struct example as <8 x i8> would be correct, but not as <2 x i32>. Or we can use structures to have elements of the exact size. You are right that the ABI lowering and the contracts for vectors are a bit underspecified. That's probably one of the reasons why vectors of i1s crash and generate bad code frequently. Is there padding between vector elements or not? Or are sub-word elements packed somehow? Nuno

On Mon, Apr 27, 2020 at 1:08 AM David Hildenbrand <david at redhat.com> wrote: > > On 24.04.20 18:24, Alexander Duyck wrote: > > From: Alexander Duyck <alexander.h.duyck at linux.intel.com> > > > > We should disable free page reporting if page poisoning is enabled in the > > kernel but we cannot report it via the balloon interface. This way we can >

On Mon, Apr 27, 2020 at 1:08 AM David Hildenbrand <david at redhat.com> wrote: > > On 24.04.20 18:24, Alexander Duyck wrote: > > From: Alexander Duyck <alexander.h.duyck at linux.intel.com> > > > > We should disable free page reporting if page poisoning is enabled in the > > kernel but we cannot report it via the balloon interface. This way we can >

Hi, I'm in the process of adding support for Markdown to a minimal CMS in Rails, [Railfrog][railfrog], which uses mime types to select appropriate processing. I have had a look through the archives but have not been able to see that a consensus has emerged as to what such a mime type for Markdown should look like. My reading of the RFCs suggests that it should be within the "text/*"

On 20 March 2018 at 09:39, Nuno Lopes via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > > Let me give you my view of the status: > The proposal you mentioned was, I believe, well understood and accepted. > Except for one bit, which was that it requires correct typing of load/store > operations. That is, if you load an i32, it means you are loading a single >

...entified by its name. But > the current module linker "resolves" this as if there is a name clash, and > one of that opaque types is renamed. It contradicts an intuitively expected > identifier behaviour and makes it literally impossible to use opaque types > for identifying underspecified types across different modules. > > Our position is that structure type names should be treated as proper > identifiers, as long as types are structurally equivalent, and all the > opaque types are structurally equivalent unless they're specialised. > > Could anyone famil...

...me feedback about tblgen from my side, i.e. an LLVM newcomer with quite some compiler construction experience: When it comes to tblgen descriptions and corresponding DAG selection and lowering code to be written for a backend, I found the use of InFlag, OutFlag and chains less understandable, very underspecified and not (well ) documented. Even though they are used in all backends, their semantics and correct use is far from obvious (even though I'm not new to compiler writing). I spent most time on getting these things right. And I learned that if they misbehave it has very fatal consequences on the...

For anyone interested, X86InstrSSE.td makes extensive use of multiclasses now if people are looking for examples other than the sparc backend. -Chris -- http://nondot.org/sabre/ http://llvm.org/

Hi, On 1/31/19 11:20 PM, Jacob Lifshay wrote: > We're in-progress designing a RISC-V extension > (http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000433.html) > that would have variable-length vectors of short vectors (1 to 4): > <VL x <4 x float>> > where each predicate bit masks out a whole short vector. We're using > this extension

...tage), it is only identified by its name. But the current module linker "resolves" this as if there is a name clash, and one of that opaque types is renamed. It contradicts an intuitively expected identifier behaviour and makes it literally impossible to use opaque types for identifying underspecified types across different modules. Our position is that structure type names should be treated as proper identifiers, as long as types are structurally equivalent, and all the opaque types are structurally equivalent unless they're specialised. Could anyone familiar with the linker comment pl...

...ied by its name. But > the current module linker "resolves" this as if there is a name clash, and > one of that opaque types is renamed. It contradicts an intuitively > expected > identifier behaviour and makes it literally impossible to use opaque types > for identifying underspecified types across different modules. > > Our position is that structure type names should be treated as proper > identifiers, as long as types are structurally equivalent, and all the > opaque types are structurally equivalent unless they're specialised. > > Could anyone familiar...

IMO, any functional/correctness difference between an incremental and clean build should be considered a build system bug, especially for C++ projects where incremental vs. clean can mean 10 second vs 30 minute build times. -- Sean Silva

This was underspecified before. --- docs/nbdkit-plugin.pod | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/nbdkit-plugin.pod b/docs/nbdkit-plugin.pod index ceaef1a..47a46da 100644 --- a/docs/nbdkit-plugin.pod +++ b/docs/nbdkit-plugin.pod @@ -240,6 +240,7 @@ This may be called once just before the...