[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 <https://bugs.archlinux.org/> 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

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

[alexhenrie24 at gmail dot com]

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

--- Comment #13 from Alex Henrie  ---
I filled out all the forms and was approved to contribute code to GCC, but the
patches have still not been reviewed:
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00971.html

[Bug c/86407] Ignore function attributes in function type declarations?

[alexhenrie24 at gmail dot com]

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

--- Comment #6 from Alex Henrie  ---
Created attachment 46363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46363=edit
[PATCH] Add option to ignore fndecl attributes on function pointers

This patch separates warnings about applying function definition attributes to
function pointers into a separate -Wstrict-function-attributes option. It's the
ideal solution for Wine and it fits well with GCC's existing design. Any
comments before I send it to the mailing list?

[Bug c/86407] Ignore function attributes in function type declarations?

[alexhenrie24 at gmail dot com]

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

--- Comment #5 from Alex Henrie  ---
The fundamental problem here is that some people want to combine calling
convention attributes and certain other attributes in a macro and then use that
macro everywhere, whereas other people want to place each attribute only where
it technically belongs. To make both groups happy, we need more granular
warning options.

One possible solution is to add -Wattribute= and -Wno-attribute= switches for
enabling and disabling warnings about specific attributes. For example, Wine
could set `-Wno-attribute=ms_hook_prologue` to get warnings about all
attributes except the __ms_hook_prologue__ attribute and then include that
attribute in the WINAPI macro. Being able to disable warnings about particular
attributes might also be useful if someone wants to change the calling
convention of all functions that return a particular type. In that case it
might be helpful to have a macro like "#define INT64 long long
__attribute__((__cdecl__))", use it to declare both functions and variables,
and then ignore warnings about __cdecl__ being in more places than it needs to
be.

Another possible solution is to split off warnings about function attributes
being used on function pointers (presumably in addition to the function
definitions) into a new option such as -Wstrict-function-attributes to let
people turn off just that warning specifically.

Either way, __force_align_arg_pointer__ should be changed from a type attribute
to a function attribute, and the syntax for suppressing warnings should be the
same or similar for both __ms_hook_prologue__ and __force_align_arg_pointer__.

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

[alexhenrie24 at gmail dot com]

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

--- Comment #11 from Alex Henrie  ---
Created attachment 45889
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45889=edit
Proposed patches

I fixed up the patch from comment 4 and added a second patch with tests. Now
I'm just waiting to receive a copyright assignment form.

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

[alexhenrie24 at gmail dot com]

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

--- Comment #8 from Alex Henrie  ---
Why weren't Manuel's patches accepted?

[Bug c/89524] New: -Wno-error doesn't work with warnings from newer versions of GCC

[alexhenrie24 at gmail dot com]

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

Bug ID: 89524
   Summary: -Wno-error doesn't work with warnings from newer
versions of GCC
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexhenrie24 at gmail dot com
  Target Milestone: ---

I am working on a Qt4 program that we need to compile with both GCC 4.8.5 and
GCC 8.2.0. The build process sets the -Werror option, but the Qt4 header files
trigger the new class-memaccess warning. I'd like to use
-Wno-error=class-memaccess to permit compilation and still see where we've made
this mistake in our own code, but on GCC 4.8.5 that option causes the following
error:

cc1plus: error: -Werror=class-memaccess: no option -Wclass-memaccess

So I am forced to disable the new warning altogether with -Wno-class-memaccess,
which both GCC 4.8.5 and GCC 8.2.0 accept.

You can reproduce the error on GCC 8.2.0 with any arbitrary C file, for
example:

$ gcc -Werror -Wno-error=foobar test.c
cc1: error: -Werror=foobar: no option -Wfoobar

Can we please avoid this problem in the future by ignoring
-Wno-error=?

[Bug libstdc++/72830] istream::seekg should not reset eofbit if -std=c++98

[alexhenrie24 at gmail dot com]

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

--- Comment #2 from Alex Henrie  ---
All versions of GCC 5 and GCC 6 have the same problem.

[Bug libstdc++/72830] New: istream::seekg should not reset eofbit if -std=c++98

[alexhenrie24 at gmail dot com]

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

Bug ID: 72830
   Summary: istream::seekg should not reset eofbit if -std=c++98
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexhenrie24 at gmail dot com
  Target Milestone: ---

Created attachment 39070
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39070=edit
Test program that demonstrates the problem

According to N3168 [1], as recently as 2010 the C++ standards did not permit
istream::seekg to reset istream::eof. When the change to the standard was
approved, libstdc++ started using the new behavior, even for programs compiled
with -std=c++98. This caused the bioinformatics program GERMLINE [2] to break.
In PEDIndividualsExtractor.cpp [3] we see:

void PEDIndividualsExtractor::loadInput()
{
...

while (!stream.eof() )
{
getIndividuals();
stream.seekg(numberOfMarkers*4 + 1,ios::cur);
}

...
}

void PEDIndividualsExtractor::getIndividuals()
{
string discard, ID, famID;
stream >> famID >> ID >> discard >> discard >> discard >> discard;
if(!stream.good()) return;

...
}

This code stopped working sometime between GCC 4.4.5 / libstdc++ 6.0.13 and GCC
4.6.3 / libstdc++ 6.0.16. With the change to libstdc++, stream.eof() is always
false, so loadInput() goes into an infinite loop. A simple test program is
attached.

I realize that I could petition the GERMLINE authors to change the loop
condition (and I eventually will), but the fact that you can't get the old
behavior even with -std=c++98 is a bug in GCC.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3168.htm
[2] http://www.cs.columbia.edu/~gusev/germline/
[3] http://www.cs.columbia.edu/~gusev/germline/germline-1-5-1.tar.gz