search for: unpadded

...ector_type attributes on the clang side. >> >> Alignment and allocation size (including padding) is the original size of vector rounded up to the next power-of-2. So for example a 3 x 3 x float pad(1) or 12 x float is rounded up to 64 bytes. This is excessive. I also need to support unpadded matrices that are effectively ABI-compatible with arrays. >> >> Front-ends could lower to arrays instead of vectors and then cast them to vectors specifying the proper alignment. This would complicate front-ends and the IR. A more reasonable solution would be allow reducing the align...

Hi, I'm now adding fingerprint format method to golang crypt library. Here is the change set for it: https://go-review.googlesource.com/#/c/32814/ I'd like to make sure why the trailing "=" is removed from the result of base64. Does anybody know? Thank you! Ryuzo Yamamoto

...compressed cpio without TRAILER!!! the kernel complains "no cpio magic". In a gzipped archive one gets "junk in gzipped archive" without the TRAILER!!! This patch changes the state transitions so the kernel will follow the spec. Tested: padded uncompressed, padded compressed, unpadded compressed (error) and trailing junk in compressed (error). --- I have a boot loader that knows how to load files, determine their size, and advance to the next 4-byte boundary and reports the total size of the files loaded. It doesn't understand about converting this number to some ASCII re...

...ctor_size or ext_vector_type attributes on the clang side. Alignment and allocation size (including padding) is the original size of vector rounded up to the next power-of-2. So for example a 3 x 3 x float pad(1) or 12 x float is rounded up to 64 bytes. This is excessive. I also need to support unpadded matrices that are effectively ABI-compatible with arrays. Front-ends could lower to arrays instead of vectors and then cast them to vectors specifying the proper alignment. This would complicate front-ends and the IR. A more reasonable solution would be allow reducing the alignment and in turn t...

I'd previously been working on the assumption that the frame_height was the height of the inner picture region... and height was the height of the outer frame. Then upon readnig the spec... where it calls the outer part the frame and the inner part the picture region... i assumed i'd made a mistake and that frame_width is actually >= width in the theorainfo structure... ie

that's why i asked the original poster if the files were odd size, i had that issue before with a 24 bit mono file and wrote this script to fix it: #!/bin/sh # # sfoddfix - Sound File ODD size FIXer # # NOTE: flac v1.1.2 pukes on files that have an odd byte count, this pads them files=${*:-*.wav} for file in $files do size=$(stat --printf='%s' $file) if [ $(($size%2)) -ne 0 ];

...to the same IR type. Unlike integers, though, I think maybe we wouldn't > want to unify signed and unsigned types because of the padded-representation issue; > or maybe we'd only unify types with the same internal layout, so that a padded unsigned > type would be different from an unpadded one of the same overall width. > > Note that having saturating-arithmetic instructions would also be useful for integers > and integer vectors, and could similarly be legalized generically in the backend for > targets that don't have direct ISA support for them. > > John. >...

...ng = (frac > 0) ? cylsize - frac : 0; + align_cylsize = cylsize * align_factor; + frac = isostat.st_size % align_cylsize; + padding = (frac > 0) ? align_cylsize - frac : 0; Similarly in isohybrid.in. There is no risk that the larger padding would exceed 1024 cylinders as long as the unpadded image does not exceed this limit. Nice idea, i must say. Mathematically appealing. But up to four cylinders of padding ... ? If anybody really wants to use this, then i would prepare a modified copy of isohybrid.c for testing. (I'm not its author or maintainer. Somebody else would have to bri...

> Hi, > > Ady wrote: > > I am not so sure that using a different pair of '-h' and '-s' values > > would be better than using 255/63. > > But 255 * 63 is not divisible by 4 and thus can cause > trouble with virtual DVD-ROM. And my suggestion to modify the _amount_ of Cylinders was intended to overcome the "by 4" (or rather, "by

We would like to discuss the possibility of adding support for fixed point operations, either through new types, instructions, or intrinsics. This is an extension to a previous proposal (http://lists.llvm.org/pipermail/cfe-dev/2018-April/057756.html) for implementing fixed point arithmetic entirely in clang, but John McCall brings up good points in the comments thread of

Hi, Ady wrote: > I am not so sure that using a different pair of '-h' and '-s' values > would be better than using 255/63. But 255 * 63 is not divisible by 4 and thus can cause trouble with virtual DVD-ROM. > Most BIOS and most partition editors would assume this geometry. I cannot tell for BIOSes, but partition editors have options to set heads-per-cyl and

The Wine development release 3.18 is now available. What's new in this release (see below for details): - Subpixel font rendering with FreeType >= 2.8.1. - Support for OAEP algorithm in RSA encryption. - Array marshalling fixes in DCOM. - Improved DPI scaling in the Wine console. - Various bug fixes. The source is available from the following locations: