[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07

--- Comment #13 from Alex Henrie  ---
I should clarify that I was testing with GCC 12.2. It turns out that GCC 12.3
does not crash, and I have now confirmed that the patch from comment #5 applied
to GCC 12.3 fixes https://bugs.winehq.org/show_bug.cgi?id=55007

What will it take to get the patch accepted?

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07

--- Comment #12 from Alex Henrie  ---
Created attachment 56687
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56687=edit
Minimal example to reproduce the crash

Here's a minimal example that crashes on MinGW 12 with -m32 -mavx512f
-mpreferred-stack-boundary=2. I tried it with MinGW 13 on Compiler Explorer
 and it does not crash, so it looks like that bug has
been fixed already.

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07

--- Comment #11 from Alex Henrie  ---
Well, this is interesting: Unpatched MinGW 12 crashes in the same way if I set
both -march=native and -mpreferred-stack-boundary=2. So the problem is not the
patch itself, it's just that the patch revealed some other bug.

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07

Alex Henrie  changed:

   What|Removed |Added

 CC||alexhenrie24 at gmail dot com

--- Comment #8 from Alex Henrie  ---
Created attachment 56685
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56685=edit
File that crashed my patched MinGW

I tried to compile Wine 8.21 with GCC 12 plus the patch from comment #5 and
-march=native on a Ryzen 7800X3D, but MinGW crashed with:

i686-w64-mingw32-gcc -c -o libs/tiff/i386-windows/libtiff/tif_aux.o
libs/tiff/libtiff/tif_aux.c -Ilibs/tiff -Iinclude -Iinclude/msvcrt \
  -Ilibs/tiff/libtiff -Ilibs/jpeg -Ilibs/zlib -D_UCRT -DFAR= -DZ_SOLO
-D__WINE_PE_BUILD \
  -fno-strict-aliasing -Wno-packed-not-aligned -fno-omit-frame-pointer
-march=native -freport-bug
during RTL pass: split1
libs/tiff/libtiff/tif_aux.c: In function ‘_TIFFUInt64ToFloat’:
libs/tiff/libtiff/tif_aux.c:415:1: internal compiler error: in
assign_stack_local_1, at function.cc:429
  415 | }
  | ^
0x19408f7 internal_error(char const*, ...)
???:0
0x6674e6 fancy_abort(char const*, int, char const*)
???:0
0xee3860 assign_386_stack_local(machine_mode, ix86_stack_slot)
???:0
0x130bfa7 gen_split_56(rtx_insn*, rtx_def**)
???:0
0x17066c2 split_insns(rtx_def*, rtx_insn*)
???:0
0x873ece try_split(rtx_def*, rtx_insn*, int)
???:0
0xb60f02 split_all_insns()
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/cc824MzT.out file, please attach this to
your bugreport.
make: *** [Makefile:179744: libs/tiff/i386-windows/libtiff/tif_aux.o] Error 1

Omitting -march=native or using unpatched GCC avoids the compiler crash.

I used GCC 12 because unfortunately, Arch Linux does not yet have packaging for
GCC 13, and compiling MinGW without the help of a PKGBUILD file looked pretty
daunting. If you want to try it yourself, just clone
https://gitlab.winehq.org/wine/wine.git and run `./configure
CROSSCFLAGS='-march=native' && make -j16`.

[Bug c/111056] Missing -Wsign-compare warning with enum values

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111056

--- Comment #3 from Alex Henrie  ---
By the way, thanks for pointing out that using constexpr suppresses the warning
on GCC. Although Clang does not support constexpr in C yet, it is interesting
that Clang is smart enough to not warn about a plain const:

const int a = 1;
unsigned int b = 2;

if (a < b) // warning here on GCC, but not on Clang
puts("a < b");

I imagine that it would be difficult to change GCC's behavior to match Clang's
in this case.

[Bug c/111056] Missing -Wsign-compare warning with enum values

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111056

Alex Henrie  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Alex Henrie  ---
You're right, the second warning is unnecessary because the behavior there is
not counterintuitive (although it would have been more clear if I had written
`c = UINT32_MAX` instead of `c = -1`). It's a bad example, sorry for the noise.
GCC does warn about legitimately counterintuitive comparisons involving enums.

[Bug c/111056] New: Missing -Wsign-compare warning with enum values

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111056

Bug ID: 111056
   Summary: Missing -Wsign-compare warning with enum values
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexhenrie24 at gmail dot com
  Target Milestone: ---

#include 

int main()
{
signed int a = 1;
enum : signed int { b = 1 };
unsigned int c = -1;

if (a < c) // condition is true, -Wsign-compare warns about it
puts("a < c");

if (b < c) // condition is true, but no warning
puts("b < c");

return 0;
}

The compiler should warn about both if statements.

$ gcc --version
gcc (GCC) 13.2.1 20230801

[Bug analyzer/110426] Missing buffer overflow warning with function pointer that has the alloc_size attribute

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110426

--- Comment #4 from Alex Henrie  ---
I tried out your changes and the warnings look great now. Thank you!

[Bug analyzer/110426] New: Missing buffer overflow warning with function pointer that has the alloc_size attribute

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110426

Bug ID: 110426
   Summary: Missing buffer overflow warning with function pointer
that has the alloc_size attribute
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: alexhenrie24 at gmail dot com
  Target Milestone: ---

I expected to get a warning when compiling this program with -fanalyzer:

#include 

extern void* (*my_alloc)(size_t) __attribute__ ((alloc_size (1)));

int main(void)
{
int *x = my_alloc(1);
x[0] = 0; // buffer overflow!
return 0;
}

There is a warning if I call malloc instead of my_alloc.

[Bug c/66618] Failure to diagnose non-constant initializer for static object with -O1

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66618

--- Comment #9 from Alex Henrie  ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Alex Henrie from comment #6)
> > This wasn't fixed properly, or it was broken again before the release of GCC
> > 8.1: In GCC 8.1 and later no warning at all is issued for the example
> > program, even at -O0.
> 
> The fix was to change it to be a valid constant expression 
Oh, okay. When I read Comment 2 I thought that a -Wpedantic warning was
intended. If the intention was to have no warning ever then everything is fine.

[Bug c/66618] Failure to diagnose non-constant initializer for static object with -O1

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66618

Alex Henrie  changed:

   What|Removed |Added

 CC||alexhenrie24 at gmail dot com

--- Comment #6 from Alex Henrie  ---
This wasn't fixed properly, or it was broken again before the release of GCC
8.1: In GCC 8.1 and later no warning at all is issued for the example program,
even at -O0.

[Bug c/108476] Please turn -Wreturn-type on by default for C

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108476

--- Comment #3 from Alex Henrie  ---
(In reply to Andrew Pinski from comment #1)
> Note the warning should really be split into two different options. One for
> the return type of the declaration and one for the missing return in
> non-void case.
That would be nice, I agree. I'd just like to note that since the warning
should occur by default in both situations, this feature request does not
depend on splitting the warning in two.

(In reply to Jakub Jelinek from comment #2)
> The reason it is enabled by default for C++ is that the 2 languages differ
> significantly in this regard.  Falling through the end of a non-void
> function in C++ is undefined behavior, in C it is not, in C it is only UB if
> the caller actually uses the uninitialized return value (which is much
> harder to warn about).
Yes, I did read the note about that in the documentation (although I didn't
quote that part in comment #0). You're right that it's slightly less bad in C
because not specifying the return value is immediately undefined behavior in
C++, whereas in C it only becomes undefined behavior once the return value is
used. However, few people know about that subtle difference between C and C++
(which leads to a false sense of security when the warning does not appear in
C), and not specifying the return value will almost certainly lead to undefined
behavior in C even though technically there are situations where it does not.

> And in C it is enabled in -Wall, which you should use anyway if you care
> about warnings.
I do use -Wall whenever I can. Unfortunately, not everyone does (particularly
novices or people stuck with awful embedded-toolchain IDEs that don't make it
easy to change compiler settings), so I'd like the default to be both less
confusing and more protective against likely undefined behavior.

[Bug c/108476] New: Please turn -Wreturn-type on by default for C

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108476

Bug ID: 108476
   Summary: Please turn -Wreturn-type on by default for C
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexhenrie24 at gmail dot com
  Target Milestone: ---

According to the documentation, -Wreturn-type does the following:

"Warn whenever a function is defined with a return type that defaults to
int. Also warn about any return statement with no return value in a function
whose return type is not void (falling off the end of the function body is
considered returning without a value)."

https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

I feel strongly that gcc should turn on -Wreturn-type by default for the
following reasons:

* Not specifying the return value of a function that returns a non-void value
is almost always a bug.

* C99 and later do not allow declaring or defining a function without a return
type, so there's a good chance that code that omits the return type will break
when used with other compilers.

* GCC already turns the warning on by default for C++, and all but the most
educated of users do not expect C and C++ to be different in this regard, so it
gives a false sense of security when no such warnings appear when compiling C
code.

* Clang already turns the warning on by default for both C and C++, which goes
to show that the warning does not come up much in practice.

I've personally been bitten by forgetting to return a value from a function, so
I hope you will agree that -Wreturn-type is a sensible default to help spot
bugs sooner.

[Bug tree-optimization/105677] New: Calling strlen on a string constant is optimized out, but calling wcslen on a string constant is not

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105677

Bug ID: 105677
   Summary: Calling strlen on a string constant is optimized out,
but calling wcslen on a string constant is not
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexhenrie24 at gmail dot com
  Target Milestone: ---

strlen example, source code:

#include 

int main()
{
return strlen("Hello world!");
}

strlen example, assembly code at -O3:

movl$12, %eax
ret

wcslen example, source code:

#include 

int main()
{
return wcslen(L"Hello world!");
}

wcslen example, assembly code at -O3:

subq$8, %rsp
.cfi_def_cfa_offset 16
leaq.LC0(%rip), %rdi
callwcslen@PLT
addq$8, %rsp
.cfi_def_cfa_offset 8
ret

Interestingly, Clang produces identical assembly code for both examples, which
is what I expected GCC to do.

[Bug c/65403] -Wno-error= is an error

[alexhenrie24 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65403

--- Comment #15 from Alex Henrie  ---
Nicholas Guriev also sent a patch for this issue:

https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573774.html