Old 32-bit MinGW 4.5.4 is not supported from version 1.0.6 #273

New Issue

claunia · 2026-01-29T20:41:11Z

claunia commented

2026-01-29 20:41:11 +00:00

Originally created by @mikir on GitHub (Mar 5, 2019).

Old 32-bits MinGW 4.5.4 compiler does not generate correct code for Brotli library version 1.0.6 and newer.

The problematic code is in module common/platform.h:

#if BROTLI_GNUC_HAS_ATTRIBUTE(aligned, 2, 7, 0)
typedef  __attribute__((aligned(1))) uint64_t brotli_unaligned_uint64_t;

static BROTLI_INLINE uint64_t BrotliUnalignedRead64(const void* p) {
  return (uint64_t) ((brotli_unaligned_uint64_t*) p)[0];
}
static BROTLI_INLINE void BrotliUnalignedWrite64(void* p, uint64_t v) {
  brotli_unaligned_uint64_t* dwords = (brotli_unaligned_uint64_t*) p;
  dwords[0] = (brotli_unaligned_uint64_t) v;
}

These code has been added in version 1.0.6.

It seems that the compiler messes things up during in-lining. If we moved this code to the separated module, it started to work. There is probably some problem with __attribute__((aligned(1))).

If such old compilers are not supported, no action is needed and this issue can be considered only as a help for users of such old compilers.

Originally created by @mikir on GitHub (Mar 5, 2019). Old 32-bits MinGW 4.5.4 compiler does not generate correct code for Brotli library version 1.0.6 and newer. The problematic code is in module common/platform.h: ``` #if BROTLI_GNUC_HAS_ATTRIBUTE(aligned, 2, 7, 0) typedef __attribute__((aligned(1))) uint64_t brotli_unaligned_uint64_t; static BROTLI_INLINE uint64_t BrotliUnalignedRead64(const void* p) { return (uint64_t) ((brotli_unaligned_uint64_t*) p)[0]; } static BROTLI_INLINE void BrotliUnalignedWrite64(void* p, uint64_t v) { brotli_unaligned_uint64_t* dwords = (brotli_unaligned_uint64_t*) p; dwords[0] = (brotli_unaligned_uint64_t) v; } ``` These code has been added in version 1.0.6. It seems that the compiler messes things up during in-lining. If we moved this code to the separated module, it started to work. There is probably some problem with `__attribute__((aligned(1)))`. If such old compilers are not supported, no action is needed and this issue can be considered only as a help for users of such old compilers.

claunia closed this issue

2026-01-29 20:41:11 +00:00

claunia commented

2026-01-29 20:41:12 +00:00

@eustas commented on GitHub (Mar 5, 2019):

We would be glad to support a wide range of compilers...

In what way generated code is incorrect? What version of GCC is used by MinGW 4.5.4?

@eustas commented on GitHub (Mar 5, 2019): We would be glad to support a wide range of compilers... In what way generated code is incorrect? What version of GCC is used by MinGW 4.5.4?

claunia commented

2026-01-29 20:41:12 +00:00

@mikir commented on GitHub (Mar 6, 2019):

The generated code does not return the same data if you compress them by BrotliEncoderCompress and decompress by BrotliDecoderDecompress again.

Used underlying gcc version is 4.5.4. Actually, we use gcc 4.5.4 under Linux as well. This works. Even MinGW with gcc 4.5.4 works but only 64-bit.

It might be that this problem is somehow connected with broken packed attribute in mingw32 described here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991. I don't know.

32-bits MinGW starts to work as well if you force using of corresponding memcpy inline methods instead of these more efficient "attribute aligned(1)" alternatives.

@mikir commented on GitHub (Mar 6, 2019): The generated code does not return the same data if you compress them by BrotliEncoderCompress and decompress by BrotliDecoderDecompress again. Used underlying gcc version is 4.5.4. Actually, we use gcc 4.5.4 under Linux as well. This works. Even MinGW with gcc 4.5.4 works but only 64-bit. It might be that this problem is somehow connected with broken packed attribute in mingw32 described here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991. I don't know. 32-bits MinGW starts to work as well if you force using of corresponding memcpy inline methods instead of these more efficient "attribute aligned(1)" alternatives.

claunia commented

2026-01-29 20:41:12 +00:00

@eustas commented on GitHub (Jun 20, 2023):

Does "-mno-ms-bitfields" help?

@eustas commented on GitHub (Jun 20, 2023): Does "-mno-ms-bitfields" help?

claunia commented

2026-01-29 20:41:13 +00:00

@mikir commented on GitHub (Jun 20, 2023):

Ufff, I don't know. We have decided not to support 32-bit Win platform with such old gcc in the meantime. In case of any need, I would be probably able to dig this compiler out and tried it again.

@mikir commented on GitHub (Jun 20, 2023): Ufff, I don't know. We have decided not to support 32-bit Win platform with such old gcc in the meantime. In case of any need, I would be probably able to dig this compiler out and tried it again.

claunia commented

2026-01-29 20:41:13 +00:00

@eustas commented on GitHub (Jun 20, 2023):

No worries then. We could close this bug for now and reopen it when someone needs that. Thanks!

@eustas commented on GitHub (Jun 20, 2023): No worries then. We could close this bug for now and reopen it when someone needs that. Thanks!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/brotli#273