* modules/stdalign, modules/stdalign-h, modules/stdnoreturn:
* modules/stdnoreturn-h: Use more consistent deprecation
warnings, that do not recommend a different deprecated module.
---
ChangeLog | 7 +++
modules/stdalign | 3 ++-
modules/stdalign-h| 2 +-
modules/stdnoretu
Worth noting I've seen faults at avx2/512 for reads that aren't correctly
aligned, unless I've made a mistake somewhere along the way
* m4/stdalign.m4 (gl_ALIGNASOF):
Work around similar bug in IBM XL C V16.1.0 cc (non-clang).
Since this is the last version of this obsolescent compiler,
assume the bug is in earlier versions.
---
ChangeLog | 6 ++
m4/stdalign.m4 | 8 +---
2 files changed, 11 insertions(+), 3 deletion
On Fri, Jan 17, 2025 at 1:05 PM Paul Eggert wrote:
>
> On 2025-01-17 06:44, Jeffrey Walton wrote:
> > Change:
> >
> > const __m128i *data = buf;
> >
> > To this so the compiler cannot pick between MOVDQA and MOVDQU:
> >
> > const __m128i data = _mm_loadu_si128(buf);
>
> This doesn't look
Building a recent coreutils snapshot on FreeBSD 5.2.1, I see this compilation
error:
CC src/tail.o
../src/tail.c: In function `file_lines':
../src/tail.c:524: error: syntax error before "bufsize"
../src/tail.c:542: error: `bufsize' undeclared (first use in this function)
../src/tail.c:542:
On 2025-01-14 Paul Eggert wrote:
> On 2025-01-14 02:43, Lasse Collin wrote:
> > Pedantic interpretation might be that EILSEQ isn't allowed in this
> > situation because EOVERFLOW already describes the error condition.
>
> No, because EOVERFLOW is intended for things like inode numbers don't
> f
We discussed this previously, we decided since AVX1 supports unaligned
accesses we could not do an alignment check at the start of the function,
but as you've discovered, this memcpy issue creates undefined behaviour.
Most performant would probably be an alignment check at the start and then
manua
please read "we could not do" as "we could avoid doing"
I suspect commit 6f6cc5e "Use the translation domain gnulib"
triggered the following -Werror=format-security issue with ./configure
--disable-nls,
due to the redefinition of _(), but the attached works around the issue for
coreutils at least.
lib/xmemcoll.c:39:3: error: format not a string li
Lasse Collin writes:
> [1]
> https://github.com/tukaani-project/xz/blob/master/src/liblzma/check/crc_x86_clmul.h
Oh. Do you see any chance to merge your code into gnulib? If there is
any feature in your implementation that we don't have. And then use it
in xz? It seems a bit silly to have a
Pádraig Brady wrote:
> I suspect commit 6f6cc5e "Use the translation domain gnulib"
> triggered the following -Werror=format-security issue with ./configure
> --disable-nls,
> due to the redefinition of _(), but the attached works around the issue for
> coreutils at least.
>
>lib/xmemcoll.c:
On Fri, Jan 17, 2025 at 3:40 AM Sam Russell wrote:
>
> We discussed this previously, we decided since AVX1 supports unaligned
> accesses we could not do an alignment check at the start of the function, but
> as you've discovered, this memcpy issue creates undefined behaviour.
I don't believe th
On 2025-01-17 06:44, Jeffrey Walton wrote:
Change:
const __m128i *data = buf;
To this so the compiler cannot pick between MOVDQA and MOVDQU:
const __m128i data = _mm_loadu_si128(buf);
This doesn't look right, as 'data' is used as a pointer later.
On 2025-01-17 02:24, Lasse Collin wrote:
Try using __m128i_u* instead of __m128i*. The former has aligned(1)
attribute. It's not available in old GCC versions though.
Thanks for the suggestion. I installed the attached two patches to use
the unaligned type, and to check for compiler support. T
I'm fairly new on the list and haven't read earlier discussion about
the crc-x86_64 module, so I hope this doesn't come out wrong. I rewrote
the CRC CLMUL code[1] in XZ Utils six months ago, and I'm commenting
based on that experience.
On 2025-01-16 Paul Eggert wrote:
> That being said, it does ap
On 2025-01-14 Bruno Haible wrote:
> Maybe we should spread the word about the UTF-8 mode, that you made
> us aware of recently [1].
Yes, UTF-8 compatibility would be good nowadays. If a user has set it
globally in Windows settings (a beta feature), then programs use UTF-8
even when they don't have
On 2025-01-17 05:40, Simon Josefsson wrote:
Do you see any chance to merge your code into gnulib? If there is
any feature in your implementation that we don't have. And then use it
in xz?
Someone could merge xz's improvements into Gnulib because xz is 0BSD
which can donate to LGPLv3. Using G
17 matches
Mail list logo
