[Bug analyzer/109577] -Wanalyzer-allocation-size mishandles __builtin_mul_overflow

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #9 from nightstrike  ---
(In reply to David Malcolm from comment #8)
> Should be fixed for GCC 13 (for the upcoming GCC 13.3) by the above patches.

Did you miss my comment #5 highlighting the need to adjust the declaration of
malloc such that size_t != long?

[Bug analyzer/110014] -Wanalyzer-allocation-size mishandles realloc (..., .... * sizeof (object))

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #6 from nightstrike  ---
(In reply to David Malcolm from comment #5)
> Should be fixed for GCC 13 (for the upcoming GCC 13.3) by the above patch.

Did you miss my comment #3 that highlighted the problem due to assuming that
size_t == long?

[Bug c++/114534] New: Feature request: extend VLA support in C++

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 114534
   Summary: Feature request: extend VLA support in C++
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

See https://gcc.gnu.org/pipermail/gcc-help/2024-March/143369.html for
reference.

The documentation at https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
states that VLAs are supported in C++ as an extension.

Compiling the following:

void f(int a, int b[a]);
void f() {
  int c[2];
  f(2, c);
}

with g++ -std=gnu++20 results in the error: "use of parameter outside function
body before ']' token".  The docs say nothing about partial support of VLA,
just that they can be used.

Where this is useful as an extension is in the somewhat reasonable case of
including a C header in a C++ program.  If that C header declares a function
using a C99 VLA, it would be awesome if g++ were to accept it in -std=gnu++
mode (and it would be fine if it were rejected in -std=c++ mode).  Consider a
situation where you cannot modify the header, and so have to use it as-is.

For comparison, clang added support for this feature in version 12.  It would
be advantageous to have feature parity given that it started as a GNU
extension.  Moreover, better interoperability with C is useful in its own
right.

[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #8 from nightstrike  ---
(In reply to Andrew Pinski from comment #1)
> This one looks like a mising '()':
> ../../../gcc/gcc/ira-conflicts.cc:153:25: warning: format '%ld' expects
> argument of type 'long int', but argument 3 has type 'long long unsigned
> int' [-Wformat=]
>   153 |"+++Allocating %ld bytes for conflict table (uncompressed
> size %ld)\n",
>   |   ~~^
>   | |
>   | long int
>   |   %lld
>   154 |(long) allocated_words_num * sizeof (IRA_INT_TYPE),
>   |~~
>   |   |
>   |   long long unsigned int
> 
> Maybe it should have been `(long) (allocated_words_num * sizeof
> (IRA_INT_TYPE))`
> Likewise for the next one:
> 
>   155 |(long) object_set_words * ira_objects_num * sizeof
> (IRA_INT_TYPE));
> 
> Should have been `(long)(object_set_words * ira_objects_num * sizeof
> (IRA_INT_TYPE))`

This part should be fixed now after PR43613 and r14-8898-g2bb4556220285e.

[Bug target/43613] Some architecture-dependent codes

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #10 from nightstrike  ---
Patch thread started here:

https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644674.html
https://inbox.sourceware.org/gcc-patches/4700e066-1b50-4e7b-92f7-d8c33a330...@gmail.com/

and ended with this solution:

https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644701.html
https://inbox.sourceware.org/gcc-patches/Zbu34FTR73081bMb@tucnak/


which was committed in r14-8898-g2bb4556220285e.

I believe based on comment 7, this can now be closed.

[Bug analyzer/105755] -Wanalyzer-null-dereference regression compiling Emacs

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #6 from nightstrike  ---
(In reply to nightstrike from comment #5)
> If I open your godbolt links, they aren't using a Windows target compiler,
> so they aren't exercising an LLP64 target.

For instance:
https://godbolt.org/z/4Mx96Wjvd

: In function 'XLI':
:15:10: warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
   15 |   return (EMACS_INT) o;
  |  ^
ASM generation compiler returned: 0
ERROR: The inherited access control list (ACL) or access control entry (ACE)
could not be built.

: In function 'XLI':
:15:10: warning: cast from pointer to integer of different size
[-Wpointer-to-int-cast]
   15 |   return (EMACS_INT) o;
  |  ^
Execution build compiler returned: 0
Program returned: 254

[Bug analyzer/105755] -Wanalyzer-null-dereference regression compiling Emacs

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #5 from nightstrike  ---
(In reply to David Malcolm from comment #4)
> Looks like this was fixed sometime in GCC 13; resolving as WORKSFORME.
> 
> Feel free to reopen if you have a reproducer that triggers on a more recent
> GCC.

The testcase still fails.  To be clear, I'm referring to null-deref-pr105755.c:

Executing on host: /tmp/gcc/src/gcc-git/_w/gcc/xgcc
-B/tmp/gcc/src/gcc-git/_w/gcc/  exceptions_enabled705865.cc 
-fdiagnostics-plain-output  -Wno-complain-wrong-lang -S -o
exceptions_enabled705865.s(timeout = 300)
spawn -ignore SIGHUP /tmp/gcc/src/gcc-git/_w/gcc/xgcc
-B/tmp/gcc/src/gcc-git/_w/gcc/ exceptions_enabled705865.cc
-fdiagnostics-plain-output -Wno-complain-wrong-lang -S -o
exceptions_enabled705865.s^M
FAIL: gcc.dg/analyzer/null-deref-pr105755.c (test for excess errors)
Excess errors:
/tmp/gcc/src/gcc-git/gcc/testsuite/gcc.dg/analyzer/null-deref-pr105755.c:19:10:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]

testcase /tmp/gcc/src/gcc-git/gcc/testsuite/gcc.dg/analyzer/analyzer.exp
completed in 0 seconds


With this change:

--- a/gcc/testsuite/gcc.dg/analyzer/null-deref-pr105755.c
+++ b/gcc/testsuite/gcc.dg/analyzer/null-deref-pr105755.c
@@ -2,7 +2,7 @@
 /* { dg-additional-options "-Wno-analyzer-too-complex
-Wno-analyzer-symbol-too-complex -O2" } */

 typedef long int ptrdiff_t;
-typedef long int EMACS_INT;
+typedef __UINTPTR_TYPE__ EMACS_INT;
 typedef long int intmax_t;

 enum Lisp_Type


Then I get this:

PASS: gcc.dg/analyzer/null-deref-pr105755.c (test for excess errors)



If I open your godbolt links, they aren't using a Windows target compiler, so
they aren't exercising an LLP64 target.

Generally speaking, most of the analyzer testsuite assumes incorrect
definitions of things.  For instance, in the diff I just posted, you can see
that the lines before and after also assume the underlying types of ptrdiff_t
and intmax_t instead of using compiler builtins or just including the relevant
headers.  This is really needs to be fixed across the whole testsuite.

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #35 from nightstrike  ---
(In reply to anlauf from comment #34)
> Are you sure that it finds the right new libgfortran?

Good call.  I did a make install first and re-ran it, and they all pass now. 
Sorry for the noise, this is an unfortunate aspect of the testsuite where in
many cases it will not use the just-built libraries, but instead picks up the
libraries in the install path.

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #33 from nightstrike  ---
I modified the test further to just print which ones would have called stop. 
Almost, but not all, do:

 stop 2
 stop 3
 stop 4
 stop 7
 stop 8
 stop 9
 stop 10
 stop 11
 stop 12
 stop 13
 stop 15
 stop 20
 stop 21
 stop 22
 stop 23
 stop 24
 stop 25
 stop 26
 stop 27
 stop 28
 stop 29
 stop 30
 stop 31
 stop 32

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #32 from nightstrike  ---
(In reply to anlauf from comment #31)
> (In reply to nightstrike from comment #30)
> > (In reply to GCC Commits from comment #29)
> > > * gfortran.dg/pr111022.f90: New test.
> > 
> > This new test fails of x64 mingw.
> 
> Can you be more specific?

Sure, it exits with STOP 2, which is the following:

  write(buffer,"(EN0.3E0)") 6.660_4
  if (buffer.ne."6.660E+0") stop 2

I modified that as:

  write(buffer,"(EN0.3E0)") 6.660_4
  if (buffer.ne."6.660E+0") then 
print *, buffer
stop 2
  end if

And now it prints:

 6.660   
STOP 2


So I guess it's losing the E+0 from the string?

[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #30 from nightstrike  ---
(In reply to GCC Commits from comment #29)
> * gfortran.dg/pr111022.f90: New test.

This new test fails of x64 mingw.

[Bug c++/113624] FAIL: g++.dg/ext/dllimport4.C, ICE on windows targets

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

  Known to fail||11.3.0, 12.2.0, 13.0, 14.0

--- Comment #1 from nightstrike  ---
To be clear, the ICE happens on 11, 12, 13, and 14.  I don't have other
versions handy to test.

[Bug analyzer/105755] -Wanalyzer-null-dereference regression compiling Emacs

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #2 from nightstrike  ---
(In reply to GCC Commits from comment #1)
> * gcc.dg/analyzer/null-deref-pr105755.c: Likewise.

In this test, the XLI function tries to store a pointer in a long.  That type
should be __UINTPTR_TYPE__ instead; we see warnings on any LLP64 system.

[Bug analyzer/109577] -Wanalyzer-allocation-size mishandles __builtin_mul_overflow

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #5 from nightstrike  ---
(In reply to David Malcolm from comment #4)
> Thanks for fixing this Tim.
> 
> Keeping open to track backporting this to the gcc 13 branch.

Before this gets backported, the testcase should be fixed.  It uses an
incorrect declaration of malloc, assuming that size_t is long.  The standard
defines malloc as size_t, so the declaration should use __SIZE_TYPE__ instead. 
This works, although you could also just include stdlib.h or use
__builtin_malloc.

[Bug analyzer/110014] -Wanalyzer-allocation-size mishandles realloc (..., .... * sizeof (object))

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #3 from nightstrike  ---
(In reply to David Malcolm from comment #2)
> Thanks for fixing this Tim.
> 
> Keeping open to track backporting this to the gcc 13 branch.

Before this gets backported, the testcase should be fixed.  It uses an
incorrect declaration of realloc, assuming that size_t is long.  The standard
defines realloc as size_t, so the declaration should use __SIZE_TYPE__ instead.
 This works, although you could also just include stdlib.h or use
__builtin_realloc.

[Bug testsuite/113634] New: FAIL: gcc.dg/Wfree-nonheap-object-7.c, incorrect declaration for calloc()

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 113634
   Summary: FAIL: gcc.dg/Wfree-nonheap-object-7.c, incorrect
declaration for calloc()
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: testsuite-fail
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

This test uses an incorrect declaration for calloc():

void *calloc(long, long);

whereas the standard requires that it be:

void *calloc(size_t, size_t);


This can be replaced with:

void *calloc(__SIZE_TYPE__, __SIZE_TYPE__);

But I'd question why the test doesn't just include stdlib.h.  Or, if the intent
is to avoid including headers as much as possible, use __builtin_calloc(),
which does the right thing.  All three of these solutions work (header,
builtin, correct declaration).

[Bug target/113633] New: FAIL: gcc.dg/bf-ms-attrib.c execution test, wrong size for ms_struct

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 113633
   Summary: FAIL: gcc.dg/bf-ms-attrib.c execution test, wrong size
for ms_struct
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ABI, testsuite-fail
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
CC: ktietz at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-mingw* *-*-cygwin*

>From gcc.dg/bf-ms-attrib.c:

struct one_ms {
  int d;
  unsigned char a;
  unsigned short b:7;
  char c;   
} __attribute__((__ms_struct__));

And later:

if (sizeof(struct one_ms) != 8)
abort();

Here, we abort, because the size is 12 using the MS ABI.

Curiously, the testcase as initially committed used 12, and it was changed to 8
in r0-115284-g4d33b77106cf7f with the description being:

gcc.dg/bf-ms-attrib.c: Adjust expected size for ms_struct layout.

However, MSVC (and gcc/cygwin FWIW) creates a 12-byte struct, so I am curious
which is correct.  Should that portion of that commit be reverted, or should
the struct be packed into 8 bytes?  If you happen to still be reading this,
Kai, would you mind weighing in?

Perhaps we were incorrectly making 8-byte structs, then changed the testcase to
match 8, and later fixed something to generate 12-byte structs?

[Bug c/113631] New: FAIL: gcc.dg/pr7356.c, fix still fails with #pragma

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 113631
   Summary: FAIL: gcc.dg/pr7356.c, fix still fails with #pragma
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: diagnostic, testsuite-fail
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

The original PR7356 highlighted a problem where a diagnostic for a problem in a
source file would point to something in an included file.  This was fixed for
the case in the PR for a subset of systems with certain standard header files. 
The original testcase was:

a
#include 
#include 
#include 
int main(int argc, char** argv)
{
  return 0;
}


The expectation is that GCC warns on the 'a', not somewhere inside stdlib.h.
This now works as indicated in that PR:

:1:2: error: expected ';' before 'typedef'
1 | a
  |  ^
  |  ;


Notably, it works differently with C++:
:1:1: error: 'a' does not name a type
1 | a
  | ^

...but at least it marks 'a' as the issue (should that be a separate PR?)

However, on mingw, we have certain constructs in our headers that still confuse
the parser, resulting in this:


In file included from
/tmp/rt/mingw14/x86_64-w64-mingw32/include/_mingw.h:282,^M
 from
/tmp/rt/mingw14/x86_64-w64-mingw32/include/corecrt.h:10,^M
 from /tmp/rt/mingw14/x86_64-w64-mingw32/include/stdlib.h:9,^M
 from /tmp/gcc/testsuite/gcc.dg/pr7356.c:4:^M
/tmp/rt/mingw14/x86_64-w64-mingw32/include/vadefs.h:14:9: error: expected '=',
',', ';', 'asm' or '__attribute__' before '#pragma'^M
 #pragma pack(push,_CRT_PACKING)^M
 ^~~~^M


It turns out that the problem is target-agnostic and is really just due to
pragmas, so I've reduced it and reproduced the problem on GNU/Linux (the pragma
is meant to be a no-op, that was a close approximation.  GCC diagnostic push
also works):


a.c:
a
#include "a.h"
int main() {}

a.h:
#pragma message "foo"

$ gcc -c a.c
a.h:1:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'#pragma'
1 | #pragma message "foo"
  | ^~~
a.h:1:9: note: '#pragma message: foo'

[Bug c++/113624] New: FAIL: g++.dg/ext/dllimport4.C, ICE on windows targets

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 113624
   Summary: FAIL: g++.dg/ext/dllimport4.C, ICE on windows targets
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

Created attachment 57235
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57235=edit
output of -freport-bug

A test from the testsuite is failing for extra errors, but it also ICE's, so
this PR is to document the ICE.  This is the reduced dllimport4.C:

void faz() {
  __attribute__((dllimport)) int faa = 1;
  faa++;
}


$ x86_64-w64-mingw32-g++ -c dllimport4.C 
dllimport4.C: In function 'void faz()':
dllimport4.C:2:34: error: variable 'faa' definition is marked dllimport
2 |   __attribute__((dllimport)) int faa = 1;
  |  ^~~
dllimport4.C:4:1: internal compiler error: Segmentation fault
4 | }
  | ^
0x138a72f crash_signal
../../gcc/toplev.cc:317
0xb1287b cp_genericize_r
../../gcc/cp/cp-gimplify.cc:1620
0x16bddbc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11420
0xdae64f c_genericize_control_stmt(tree_node**, int*, void*, tree_node*
(*)(tree_node**, int*, void*), tree_node* (*)(tree_node**, int*, tree_node*
(*)(tree_node**, int*, void*), void*, hash_set >*))
../../gcc/c-family/c-gimplify.cc:557
0xb12aab cp_genericize_r
../../gcc/cp/cp-gimplify.cc:2225
0x16bddbc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11420
0xb13e9f cp_genericize_r
../../gcc/cp/cp-gimplify.cc:1836
0x16bddbc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11420
0xb12091 cp_genericize_tree
../../gcc/cp/cp-gimplify.cc:2258
0xb12409 cp_genericize(tree_node*)
../../gcc/cp/cp-gimplify.cc:2400
0xb62716 finish_function(bool)
../../gcc/cp/decl.cc:18800
0xc695b7 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.cc:32699
0xc6a74e cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.cc:32613
0xc6a74e cp_parser_init_declarator
../../gcc/cp/parser.cc:23356
0xc3dcd4 cp_parser_simple_declaration
../../gcc/cp/parser.cc:15890
0xc770ba cp_parser_declaration
../../gcc/cp/parser.cc:15563
0xc77f9a cp_parser_toplevel_declaration
../../gcc/cp/parser.cc:15584
0xc77f9a cp_parser_translation_unit
../../gcc/cp/parser.cc:5276
0xc77f9a c_parse_file()
../../gcc/cp/parser.cc:51174
0xdc6531 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1301
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ x86_64-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/tmp/rt/mingw14/bin/../libexec/gcc/x86_64-w64-mingw32/14.0.1/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --disable-multilib --disable-nls
--target=x86_64-w64-mingw32 --prefix=/tmp/rt/mingw14
--with-sysroot=/tmp/rt/mingw14
--enable-languages=c,ada,c++,d,fortran,lto,m2,objc,obj-c++,rust
Thread model: win32
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240126 (experimental) (GCC)

[Bug c++/113591] New: FAIL: g++.dg/cpp0x/lambda/lambda-ice15.C

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 113591
   Summary: FAIL: g++.dg/cpp0x/lambda/lambda-ice15.C
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

See PR 67846.  The original PR highlighted an ICE, and we do not ICE on
Windows, but we don't error out either.  We can achieve the Linux behavior with
-fno-ms-extensions on Windows, and the Windows behavior with -fms-extensions on
Linux.

If we assume that the behavior is an intended MS Extension, then it would be
good to have the testsuite verify that the error happens only with those
disabled and doesn't happen with them enabled.  If it's not an intended
extension, then this PR could stand to document the needed fix.  N


This is the part of the testcase that fails to error out on Windows:

```
class A {
  void foo() {
[=] { return foo; };
  }
};
```

On Linux:
$ g++ -c a.cc -fms-extensions
$ g++ -c a.cc
a.cc: In lambda function:
a.cc:3:30: error: cannot convert 'A::foo' from type 'void (A::)()' to type
'void (A::*)()'
3 | [=] { return foo; };
  |  ^~~
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/tmp/gcc/rt/linux14/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-nls --disable-multilib
--prefix=/tmp/rt/linux14 --enable-languages=all
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240116 (experimental) (GCC)


On Windows:
$ x86_64-w64-mingw32-g++ -c a.cc
$ x86_64-w64-mingw32-g++ -c a.cc -fno-ms-extensions
a.cc: In lambda function:
a.cc:3:30: error: cannot convert 'A::foo' from type 'void (A::)()' to type
'void (A::*)()'
3 | [=] { return foo; };
  |  ^~~
$ x86_64-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/tmp/gcc/rt/mingw14/bin/../libexec/gcc/x86_64-w64-mingw32/14.0.1/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --disable-multilib --disable-nls
--target=x86_64-w64-mingw32 --prefix=/tmp/rt/mingw14
--with-sysroot=/tmp/rt/mingw14
--enable-languages=c,ada,c++,d,fortran,lto,m2,objc,obj-c++,rust
Thread model: win32
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240120 (experimental) (GCC)

[Bug libstdc++/113589] New: FAIL: experimental/filesystem/operations/absolute.cc on Windows

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 113589
   Summary: FAIL: experimental/filesystem/operations/absolute.cc
on Windows
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

(Probably related to PR4)

The absolute.cc test fails this assertion:

VERIFY( absolute(p).is_absolute() );

on the second path in __gnu_test::test_paths, I think because
absolute(p).has_root_name() returns false:

```
std::cout << absolute(p) << std::endl;
std::cout << "has: " << absolute(p).has_root_name() << "  " <<
absolute(p).has_root_directory() << std::endl;
VERIFY( absolute(p).is_absolute() );
```

```
spawn wine64 ./absolute.exe^M
"H:/"^M^M
has: 1  1^M^M
"//\\home\\user\\p\\gcc\\src\\gcc-git\\_w\\x86_64-w64-mingw32\\libstdc++-v3\\testsuite"^M^M
has: 0  1^M^M
```

So H:/ works, but //\\path doesn't.  I guess all these extra slashes are due to
running under wine, but presumably real applications may do so.


absolute() does the following:

```
  if (p.has_root_directory()) // implies !p.has_root_name()
{
  // GetFullPathNameW("//") gives unwanted result (PR 4).
  // If there are multiple directory separators at the start,
  // skip all but the last of them.
  const auto pos = s.find_first_not_of(L"/\\");
  __glibcxx_assert(pos != 0);
  s.remove_prefix(std::min(s.length(), pos) - 1);
}
```

So I guess this needs to be a little bit smarter to handle Wine paths maybe?

Sorry I couldn't take this further, but I'll be happy to test a fix.

[Bug target/100058] -Wpadded is inconsistent using -mms-bitfields

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #1 from nightstrike  ---
(In reply to Josh Nave from comment #0)
> Someone else suggested that the line `!targetm.ms_bitfield_layout_p
> (rli->t)` in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52238 could be the
> issue, which to me seems likely from a brief look.

I don't think it's as simple as just removing those conditions, as they're
trying to restrict warning for MS-specific cases.  We need to understand under
which conditions it's expected to warn when -mms-bitfields is enabled.

[Bug target/113549] float simd crash on windows in gcc.dg/vect/vect-simd-clone-16b.c

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #4 from nightstrike  ---
(In reply to Andrew Pinski from comment #3)
> Either the stack size or the stack alignment issue.
> 
> I am suspecting a stack alignement issue.

Possibly related: PR110273

[Bug testsuite/113548] gcc.dg/vect/vect-ifcvt-19.c ICEs on LLP64 target

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #3 from nightstrike  ---
Seeing as how this is a testsuite issue, it seems that the crash in the same
location applies to the following:

FAIL: gcc.dg/vect/vect-ifcvt-19.c (internal compiler error: in build2, at
tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10a.c (internal compiler error: in build2, at
tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10b.c (internal compiler error: in build2, at
tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10c.c (internal compiler error: in build2, at
tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10d.c (internal compiler error: in build2, at
tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10e.c (internal compiler error: in build2, at
tree.cc:5097)
FAIL: gcc.dg/vect/vect-ifcvt-19.c -flto -ffat-lto-objects (internal compiler
error: in build2, at tree.cc:5097)
FAIL: gcc.dg/vect/vect-cond-arith-2.c -flto -ffat-lto-objects (internal
compiler error: in build2, at tree.cc:5097)
FAIL: gcc.dg/vect/vect-cond-arith-2.c (internal compiler error: in build2, at
tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10b.c -flto -ffat-lto-objects (internal compiler
error: in build2, at tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10c.c -flto -ffat-lto-objects (internal compiler
error: in build2, at tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10d.c -flto -ffat-lto-objects (internal compiler
error: in build2, at tree.cc:5097)
FAIL: gcc.dg/vect/slp-reduc-10e.c -flto -ffat-lto-objects (internal compiler
error: in build2, at tree.cc:5097)

[Bug target/113549] float simd crash on windows in gcc.dg/vect/vect-simd-clone-16b.c

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #2 from nightstrike  ---
Test 16e uses double instead of float, which also crashes.

[Bug target/113549] float simd crash on windows in gcc.dg/vect/vect-simd-clone-16b.c

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #1 from nightstrike  ---
Created attachment 57188
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57188=edit
Failing source for easier copying

[Bug target/113549] New: float simd crash on windows in gcc.dg/vect/vect-simd-clone-16b.c

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 113549
   Summary: float simd crash on windows in
gcc.dg/vect/vect-simd-clone-16b.c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

Created attachment 57187
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57187=edit
Assembly output

The vect-simd-clone-16b.c test runs the vect-simd-clone-16.c test with the TYPE
set to float.  The default type is int, which works fine.  Reducing that
testcase yields the following:


```
#define TYPE float
#pragma omp declare simd inbranch
TYPE __attribute__((noinline))
foo (TYPE a)
{
  return a + 1;
}

void
masked_fixed (TYPE * a, TYPE * b)
{
  #pragma omp simd
  for (int i = 0; i < 128; i++)
b[i] = a[i]<1 ? foo(a[i]) : a[i];
}

int main() {
TYPE a[1024] = {0};
TYPE b[1024] = {0};
masked_fixed(a, b);
return 0;
}
```

The noipa attribute and the __restrict keywords were removed from masked_fixed.
 noinline is required on foo.


Minimal set of compile arguments required to trigger the problem:
$ x86_64-w64-mingw32-gcc  a.c -fopenmp-simd -O2 -mavx

Note that dropping to -01 or removing -mavx avoids the crash.  

Assembly from -save-temps -fverbose-asm attached.

This is technically running under wine 8.0.  This is the backtrace provided by
wine:

```
wine: Unhandled page fault on read access to  at address
00014000163F (thread 0024), starting debugger...
Unhandled exception: page fault on read access to 0x in 64-bit
code (0x014000163f).
Register dump:
 rip:00014000163f rsp:0021dc50 rbp:0021dcd0 eflags:00010246
(  R- --  I  Z- -P- )
 rax: rbx: rcx:0021dcf0
rdx:0021dcd0
 rsi:0021ed70 rdi:0021dd70  r8:0021dcb0 
r9:00c92000 r10:00c90330
 r11: r12:0021dcb0 r13:0021dcf0
r14: r15:
Stack dump:
0x21dc50:   
0x21dc60:   
0x21dc70:   
0x21dc80:   
0x21dc90:   
0x21dca0:   
0x21dcb0:   
0x21dcc0:   
0x21dcd0:   
0x21dce0:   
0x21dcf0:   
0x21dd00:   
Backtrace:
=>0 0x014000163f in a (+0x163f) (0x21dcd0)
  1 0x0140003384 in a (+0x3384) (0x21fdf0)
  2 0x0140001340 in a (+0x1340) (0x21fdf0)
  3 0x0140001146 in a (+0x1146) (0x21fe30)
  4 0x007b647b51 BaseThreadInitThunk+0x11(unknown=,
entry=, arg=)
[H:\home\user\p\gcc\src\wine-8.0-rc4p2p3\dlls\kernel32\thread.c:61] in kernel32
(0x0
00021fe60)
0x014000163f a+0x163f: ldsl %esp,%edi
```

[Bug tree-optimization/113548] New: ICE vect-ifcvt-19 in build2, at tree.cc:5097

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 113548
   Summary: ICE vect-ifcvt-19 in build2, at tree.cc:5097
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

Created attachment 57186
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57186=edit
Preprocessed source from -freport-bug

ICE during testsuite run for vect-ifcvt-19.  Many similarly titled bugs, I
think the current title of this one is equally unhelpful, so feel free to
change this PR title to something better.

Running linux 64 to windows 64 cross compiler, fails on 11, 12, 13, 14.  I
didn't test prior versions.

Backtrace:

0x8bb855 build2(tree_code, tree_node*, tree_node*, tree_node*)
../../gcc/tree.cc:5097
0xa4dd1f build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/tree.h:4750
0xa4dd1f c_parser_gimple_binary_expression
../../gcc/c/gimple-parser.cc:1068
0xa4ec71 c_parser_gimple_statement
../../gcc/c/gimple-parser.cc:878
0xa4f95a c_parser_gimple_compound_statement
../../gcc/c/gimple-parser.cc:669
0xa51a58 c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il,
profile_count)
../../gcc/c/gimple-parser.cc:253
0xa3d3f4 c_parser_declaration_or_fndef
../../gcc/c/c-parser.cc:3011
0xa4764b c_parser_external_declaration
../../gcc/c/c-parser.cc:2046
0xa48035 c_parser_translation_unit
../../gcc/c/c-parser.cc:1900
0xa48035 c_parse_file()
../../gcc/c/c-parser.cc:26815
0xabf271 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1301

[Bug libstdc++/107603] checking for ld that supports -Wl,--gc-sections... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. for i686-w64-mingw32 target at canadian compilation

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #2 from nightstrike  ---
That config.log output isn't in the attached file.  I think you attached the
top level config.log and not the libstdc++ config.log.  Can you try again?

[Bug target/59425] ICE - seg fault building ISL on Windows

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #2 from nightstrike  ---
The preprocessed source works for me in 13.  Can you verify if this is still an
issue?

[Bug ada/113516] New: POLLPRI redefined on windows building ada

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 113516
   Summary: POLLPRI redefined on windows building ada
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

g:r11-4313-gd08d481912b9a2 defined POLLPRI to zero on Windows, stating in the
commit message "Define POLLPRI as zero on Windows as it is not supported
there."  However, it is defined on mingw-w64 targets, resulting in a build
warning:

/tmp/gcc/src/gcc-git/gcc/ada/s-oscons-tmplt.c:1871:9: warning: "POLLPRI"
redefined
 1871 | #define POLLPRI 0
  | ^~~
In file included from /tmp/gcc/src/gcc-git/gcc/ada/gsocket.h:83,
 from /tmp/gcc/src/gcc-git/gcc/ada/s-oscons-tmplt.c:103:
/tmp/rt/mingw14/x86_64-w64-mingw32/include/winsock2.h:1182:9: note: this is the
location of the previous definition
 1182 | #define POLLPRI0x0400
  | ^~~

[Bug libstdc++/65257] cin not working with empty string when _GLIBCXX_DEBUG is defined on Windows

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #2 from nightstrike  ---
I should clarify that I tested this with mingw-w64, not mingw.org where the bug
was originally reported.

[Bug libstdc++/65257] cin not working with empty string when _GLIBCXX_DEBUG is defined on Windows

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #1 from nightstrike  ---
(In reply to Muhammad Annaqeeb from comment #0)

> #define _GLIBCXX_DEBUG
> #include 
> using namespace std;
> string s,t;
> int main(){
> cin>>s>>t;
> cout< }

FWIW, this works on Wine as well as Cygwin + Win 7, compiled with g++ 14,
configured *without* --enable-fully-dynamic-string.

[Bug target/43613] Some architecture-dependent codes

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #8 from nightstrike  ---
(In reply to Andrew Pinski from comment #7)
> So just this one left I think:
> 
> /gcc/src/gcc/ira-conflicts.c: Line 125:
> 
> Still there, size_t is long long (64bits) while long is 32bits.

Assuming this is now line 153:

```
diff --git a/gcc/ira-conflicts.cc b/gcc/ira-conflicts.cc
index a4d93c8d734..4f2c2bdfebc 100644
--- a/gcc/ira-conflicts.cc
+++ b/gcc/ira-conflicts.cc
@@ -150,9 +150,9 @@ build_conflict_bit_table (void)
   if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL)
 fprintf
   (ira_dump_file,
-   "+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n",
-   (long) allocated_words_num * sizeof (IRA_INT_TYPE),
-   (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE));
+   "+++Allocating %zu bytes for conflict table (uncompressed size %zu)\n",
+   (size_t)(allocated_words_num * sizeof (IRA_INT_TYPE)),
+   (size_t)(object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)));

   objects_live = sparseset_alloc (ira_objects_num);
   for (i = 0; i < ira_max_point; i++)
```

Perhaps that will address the remaining issue?

[Bug libstdc++/110167] New: excessive compile time when optimizing std::to_array

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 110167
   Summary: excessive compile time when optimizing std::to_array
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

#include 
int f[262144]; auto g(void) { return std::to_array(f); }

(Thanks to Andrew for help reducing!)

Baseline run:

$ time g++ test.cc -std=gnu++20 -O0 -c
real0m17.274s
user0m16.806s
sys 0m0.119s


at -O1, 2, 3, or fast, it takes too long to ever finish.  I killed it after 15
minutes.

For the curious, that array size is 512*512.  I didn't bisect to see where it
starts to blow up.

[Bug target/69639] [10/11/12/13 Regression] FAIL: gcc.c-torture/compile/limits-exprparen.c

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #18 from nightstrike  ---
(In reply to nightstrike from comment #9)
> This affects 8-trunk on x86_64 cygwin, as well.  The default size of the
> stack for cc1 is:
> 
> $ peflags -x /tmp/b2/gcc/cc1.exe
> /tmp/b2/gcc/cc1.exe: stack reserve size  : 12582912 (0xc0) bytes
> 
> 
> Setting it to 0xd0 and 0xe0 also fail.  Setting it to 0xf0
> works.  I didn't go further than that to see where between 14 and 15 megs it
> starts working.
> 
> Can we just boost the default stack size of cc1.exe by a couple megs for
> affected hosts?

It looks like Dave Korn already did it here:
https://gcc.gnu.org/legacy-ml/gcc-patches/2010-12/msg00256.html

But 12 isn't enough.  We need 15 (or I guess 16 if you like powers of 2).

[Bug c/108942] New: ICE in build2, at tree.c: 5096 for gcc/testsuite/gcc.dg/torture/ssa-fre-7.c:23:3

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108942
   Summary: ICE in build2, at tree.c: 5096 for
gcc/testsuite/gcc.dg/torture/ssa-fre-7.c:23:3
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

Created attachment 54541
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54541=edit
preprocessed source from -freport-bug

The gcc.dg/torture/ssa-fre-7.c tests fail with the following backtrace:

0x844e1f build2(tree_code, tree_node*, tree_node*, tree_node*)
../../gcc/tree.cc:5096
0x9a26d7 build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/tree.h:4604
0x9a26d7 c_parser_gimple_binary_expression
../../gcc/c/gimple-parser.cc:1027
0x9a38ce c_parser_gimple_statement
../../gcc/c/gimple-parser.cc:873
0x9a38ce c_parser_gimple_compound_statement
../../gcc/c/gimple-parser.cc:664
0x9a5c11 c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il,
profile_count)
../../gcc/c/gimple-parser.cc:253
0x9954a6 c_parser_declaration_or_fndef
../../gcc/c/c-parser.cc:2835
0x99c6fb c_parser_external_declaration
../../gcc/c/c-parser.cc:1925
0x99d0d3 c_parser_translation_unit
../../gcc/c/c-parser.cc:1779
0x99d0d3 c_parse_file()
../../gcc/c/c-parser.cc:24632
0xa088e1 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1248

This is in a linux to 64-bit windows cross compiler environment.  Output of
-freport-bug added as an attachment.

For this version of the repository (commit
e6d39f68d03c46637ca6e1bede3d28eae6278df3), line 23 is:

  p_4 = _Literal (int *)  + _2;

[Bug middle-end/83286] internal compiler error: Illegal instruction

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #9 from nightstrike  ---
I compiled both of the preprocessed source attachments and could not reproduce
your failure using a recently built gcc 13 cross compiler from linux to
x86_64-w64-mingw32.  I used no options, "-O3 -Wall -fno-strict-aliasing
-fomit-frame-pointer-funroll-loops -fPIC", and "-O3 -Wall
-fno-strict-aliasing" based on your command lines.

Is it safe to assume that this is no longer an issue?

[Bug target/90458] [10/11/12/13 Regression] mingw64: ICE in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1258 with -fstack-clash-protection

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #8 from nightstrike  ---
FYI, this is the same as the failure in gcc/testsuite/gcc.dg/stack-check-16.c:

(running this under Wine)

during RTL pass: final
gcc.dg/stack-check-16.c:36:1: internal compiler error: in
i386_pe_seh_unwind_emit, at config/i386/winnt.cc:1274^M
0x86f42f i386_pe_seh_unwind_emit(_IO_FILE*, rtx_insn*)^M
../../gcc/config/i386/winnt.cc:1274^M
0xbd4d87 final_scan_insn_1^M
../../gcc/final.cc:2851^M
0xbd515b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)^M
../../gcc/final.cc:2887^M
0xbd5347 final_1^M
../../gcc/final.cc:1979^M
0xbd5e36 rest_of_handle_final^M
../../gcc/final.cc:4240^M
0xbd5e36 execute^M
../../gcc/final.cc:4318^M
Please submit a full bug report, with preprocessed source (by using
-freport-bug).^M
Please include the complete backtrace with any bug report.^M
See  for instructions.^M
compiler exited with status 1

[Bug testsuite/108675] FAIL: gcc.c-torture/execute/builtins/*printf.c when stdio.h includes definitions

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #9 from nightstrike  ---
I understand it's not ideal based on comment #6, but this fixes all the tests:

diff --git a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c
b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c
index 853a705e86d..499c81b0fa7 100644
--- a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c
+++ b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c
@@ -1,11 +1,10 @@
-#include 
 #include 
 extern void abort (void);
 extern int inside_main;

 __attribute__ ((__noinline__))
 int
-fprintf (FILE *fp, const char *string, ...)
+fprintf (void *fp, const char *string, ...)
 {
   va_list ap;
   int r;
@@ -22,7 +21,7 @@ fprintf (FILE *fp, const char *string, ...)
 /* Locking stdio doesn't matter for the purposes of this test.  */
 __attribute__ ((__noinline__))
 int
-fprintf_unlocked (FILE *fp, const char *string, ...)
+fprintf_unlocked (void *fp, const char *string, ...)
 {
   va_list ap;
   int r;
diff --git a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/printf.c
b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/printf.c
index 4be7578d124..0d405241cfe 100644
--- a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/printf.c
+++ b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/printf.c
@@ -1,4 +1,3 @@
-#include 
 #include 
 extern void abort (void);
 extern int inside_main;
diff --git a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/sprintf.c
b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/sprintf.c
index 3ac447b117f..6de24cd7df4 100644
--- a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/sprintf.c
+++ b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/sprintf.c
@@ -1,4 +1,3 @@
-#include 
 #include 
 extern void abort (void);
 extern int inside_main;

[Bug testsuite/108709] FAIL: gcc.dg/analyzer/pipe-glibc.c

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #1 from nightstrike  ---
Perhaps these are separate bugs, but:

1) gcc.dg/analyzer/pipe-manpages.c will need similar improvements

2) gcc.dg/analyzer/pipe-void-return.c passes with an incorrect declaration for
pipe(), implying that we won't test whether it captures using uninitialized
file descriptors when _pipe() fails

[Bug analyzer/108709] New: FAIL: gcc.dg/analyzer/pipe-glibc.c

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108709
   Summary: FAIL: gcc.dg/analyzer/pipe-glibc.c
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

This test fails on Windows for lack of fork.  It actually fails for not having
pipe(), also, but _pipe() does the job well enough, so that fix is a simple
#define.  It is not very apparent what the test is doing, since it doesn't get
executed and doesn't appear to have analyzer calls, but the following poor
man's solution does result in a test that executes correctly on
x86_64-redhat-linux (EL8) and x86_64-w64-mingw32 under Wine.

git diff ../gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
diff --git a/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
b/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
index a8546ea9549..3b93212f56d 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c
@@ -30,6 +30,30 @@ write_to_pipe (int file)
   fclose (stream);
 }

+#ifdef WIN32
+// Use native _pipe with a thread on windows, as forks don't exist
+// This requires that the pipes remain open, so disable close()
+
+#include 
+#include 
+#define pipe(FD) _pipe(FD, 256, O_BINARY)
+#define close(X)
+
+#include 
+#include 
+static __cdecl void
+fake_fork (void * arg)
+{
+int * mypipe = arg;
+read_from_pipe (mypipe[0]);
+}
+
+#define fork() _beginthread(fake_fork, 0, mypipe)
+#define wait(X) WaitForSingleObject((void *)pid, INFINITE)
+#else
+#include 
+#endif
+
 int
 main (void)
 {
@@ -66,6 +90,7 @@ main (void)
  Close other end first. */
   close (mypipe[0]);
   write_to_pipe (mypipe[1]);
+  wait(NULL);
   return EXIT_SUCCESS;
 }
 }

[Bug analyzer/108708] New: __analyzer_dump_named_constant fails with derived values

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108708
   Summary: __analyzer_dump_named_constant fails with derived
values
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

The analyzer test fd-access-mode-target-headers.c fails on mingw-w64 due to the
following:

FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c  (test for warnings, line
55)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c  (test for warnings, line
56)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c  (test for warnings, line
57)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for excess errors)
Excess errors:
gcc-git/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c:55:3:
warning: named constant 'O_ACCMODE' has unknown value
gcc-git/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c:56:3:
warning: named constant 'O_RDONLY' has unknown value
gcc-git/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c:57:3:
warning: named constant 'O_WRONLY' has unknown value


This fails, because on mingw-w64, we define these macros indirectly:

#define _O_RDONLY 0x
#define _O_WRONLY 0x0001
#define _O_RDWR 0x0002
#define _O_ACCMODE (_O_RDONLY|_O_WRONLY|_O_RDWR)
...
#define O_RDONLY _O_RDONLY
#define O_WRONLY _O_WRONLY
#define O_ACCMODE _O_ACCMODE


If I modify the test to do "#undef O_ACCMODE; #define O_ACCMODE 42", it works
as expected (and the other tests in the testsuite that test this also pass).

I didn't flag this as a testsuite issue, though, because it seems that the
issue is within the ability of __analyzer_dump_named_constant() to handle a
macro value that references another macro or is some other valid expression.  I
also don't think it's specific to Windows.

Perhaps related is that these tests also fail:
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c  (test for warnings, line
19)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c  (test for warnings, line
27)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c  (test for warnings, line
32)
FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c  (test for warnings, line
39)

I assume this is related to the analyzer not being able to deduce the
permissions passed to open().

[Bug testsuite/107602] dump-noaddr testcases fail when running the testsuite with already built installed toolchain

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #2 from nightstrike  ---
Better link(In reply to nightstrike from comment #1)
> Reverting 186d43a78e945ebe9fbe217fc341847af7f95d30 fixes this problem at
> least for me

Better link: r255433

[Bug testsuite/107602] dump-noaddr testcases fail when running the testsuite with already built installed toolchain

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #1 from nightstrike  ---
Reverting 186d43a78e945ebe9fbe217fc341847af7f95d30 fixes this problem at least
for me

[Bug testsuite/108675] FAIL: gcc.c-torture/execute/builtins/*printf.c when stdio.h includes definitions

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #8 from nightstrike  ---
(In reply to LIU Hao from comment #7)
> (In reply to nightstrike from comment #5)
> > (In reply to LIU Hao from comment #4)
> > > Does it make any sense to remove `#include ` from
> > > 'gcc.c-torture/execute/builtins/lib/fprintf.c' ?
> > 
> > That will prevent the FILE type from existing, so the replacement functions
> > won't compile.
> 
> That file never uses any fields of `FILE` directly. `FILE*` is always passed
> as a pointer to `vfprintf()`, so it is perfectly valid to declare
> 
>typedef struct _iobuf FILE;
> 
> or even 
> 
>int fprintf (void* fp, const char* fmt, ...);

Removing "include stdio" and changing both FILE*'s to void*'s does in fact make
the test pass.  Is this an acceptable way to pass the test?

diff --git a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c
b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c
index 853a705e86d..75406298856 100644
--- a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c
+++ b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c
@@ -1,11 +1,11 @@
-#include 
+//#include 
 #include 
 extern void abort (void);
 extern int inside_main;

 __attribute__ ((__noinline__))
 int
-fprintf (FILE *fp, const char *string, ...)
+fprintf (void *fp, const char *string, ...)
 {
   va_list ap;
   int r;
@@ -22,7 +22,7 @@ fprintf (FILE *fp, const char *string, ...)
 /* Locking stdio doesn't matter for the purposes of this test.  */
 __attribute__ ((__noinline__))
 int
-fprintf_unlocked (FILE *fp, const char *string, ...)
+fprintf_unlocked (void *fp, const char *string, ...)
 {
   va_list ap;
   int r;

[Bug testsuite/108675] FAIL: gcc.c-torture/execute/builtins/*printf.c when stdio.h includes definitions

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #5 from nightstrike  ---
(In reply to LIU Hao from comment #4)
> Does it make any sense to remove `#include ` from
> 'gcc.c-torture/execute/builtins/lib/fprintf.c' ?

That will prevent the FILE type from existing, so the replacement functions
won't compile.

[Bug testsuite/108675] FAIL: gcc.c-torture/execute/builtins/*printf.c when stdio.h includes definitions

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #2 from nightstrike  ---
(In reply to Richard Biener from comment #1)
> These tests are known to be a bit awkwardly implemented to check for
> optimizations done ...

How would you do it if you were writing the test today?

> There might be a better way to provide definitions of fprintf, but is it
> possible to short-circuit those definitions in the stdio.h header with
> some macro definition?  And would that make the execution succeed?

If I modify stdio.h to #if 0 the definitions, then at least 16 fprintf tests
pass (that's the only one I modified).  We don't currently provide a macro
mechanism to disable these, though.  @jon_y, is this a reasonable workaround? 
(Ideally, fixing the test would happen instead, but if it's desirable that the
headers can optionally define *printf outside of the testsuite, then we should
entertain that as well).

[Bug testsuite/108675] New: FAIL: gcc.c-torture/execute/builtins/*printf.c when stdio.h includes definitions

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108675
   Summary: FAIL: gcc.c-torture/execute/builtins/*printf.c when
stdio.h includes definitions
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

Failing tests:
gcc.c-torture/execute/builtins/printf.c
gcc.c-torture/execute/builtins/fprintf.c
gcc.c-torture/execute/builtins/sprintf.c

On mingw-w64, the gcc.c-torture/execute/builtins/*printf.c tests fail.  We
include definitions of various functions in stdio.h instead of just
declarations, leading to redefinition errors.  For example,

https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/crt/stdio.h:
__mingw_ovr
__attribute__((__format__ (gnu_printf, 2, 3))) __MINGW_ATTRIB_NONNULL(2)
int fprintf (FILE *__stream, const char *__format, ...)
{
  int __retval;
  __builtin_va_list __local_argv; __builtin_va_start( __local_argv, __format );
  __retval = __mingw_vfprintf( __stream, __format, __local_argv );
  __builtin_va_end( __local_argv );
  return __retval;
}

This causes the test to fail to compile at all optimization levels:
gcc.c-torture/execute/builtins/lib/fprintf.c:8:1: error: redefinition of
'fprintf'
mingw13/x86_64-w64-mingw32/include/stdio.h:357:5: note: previous definition of
'fprintf' with type 'int(FILE *, const char *, ...)' {aka 'int(struct _iobuf *,
const char *, ...)'}

The tests were originally added in r38065, r38788, and r48335.  They were later
moved in r84044 and tweaked a bit.

Is there a better way to verify that the builtin was used instead of mingw
version?

[Bug target/90826] Weak symbol does not work reliably on windows

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #3 from nightstrike  ---
See also: https://sourceware.org/bugzilla/show_bug.cgi?id=9687

[Bug testsuite/108427] New: bitfield tests fail with missing warnings

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108427
   Summary: bitfield tests fail with missing warnings
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

Both bitfield-3.m and bitfield-5.m appear to fail for the same reason on
x86_64-w64-mingw32 (cross compiled from linux, if it matters).  The tests each
contain multiple tests for warnings, only one of which is missing in each case:

PASS: objc.dg/bitfield-3.m -fgnu-runtime  (test for warnings, line 20)
FAIL: objc.dg/bitfield-3.m -fgnu-runtime  (test for warnings, line 27)
PASS: objc.dg/bitfield-3.m -fgnu-runtime  (test for warnings, line 32)
PASS: objc.dg/bitfield-3.m -fgnu-runtime  (test for warnings, line 33)
PASS: objc.dg/bitfield-3.m -fgnu-runtime (test for excess errors)
PASS: objc.dg/bitfield-3.m -fgnu-runtime execution test

PASS: objc.dg/bitfield-5.m -fgnu-runtime  (test for warnings, line 24)
PASS: objc.dg/bitfield-5.m -fgnu-runtime  (test for warnings, line 33)
FAIL: objc.dg/bitfield-5.m -fgnu-runtime  (test for warnings, line 40)
PASS: objc.dg/bitfield-5.m -fgnu-runtime  (test for warnings, line 52)
PASS: objc.dg/bitfield-5.m -fgnu-runtime  (test for warnings, line 57)
PASS: objc.dg/bitfield-5.m -fgnu-runtime  (test for warnings, line 70)
PASS: objc.dg/bitfield-5.m -fgnu-runtime  (test for warnings, line 74)
PASS: objc.dg/bitfield-5.m -fgnu-runtime  (test for warnings, line 75)
PASS: objc.dg/bitfield-5.m -fgnu-runtime  (test for warnings, line 76)
PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for excess errors)

There are similar tests and failures for objc++, but maybe these are supposed
to be XFAIL'd due to PR23610:

PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime  (test for warnings, line 21)
PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime  (test for warnings, line 33)
PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime PR23610 at line 53 (test for bogus
messages, line )
PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime PR23610 at line 55 (test for bogus
messages, line 28)
FAIL: obj-c++.dg/bitfield-4.mm -fgnu-runtime PR23610 at line 56 (test for bogus
messages, line 34)
PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime (test for excess errors)
PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime execution test

PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime  (test for warnings, line 26)
PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime  (test for warnings, line 29)
PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime  (test for warnings, line 76)
PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 118 (test for
bogus messages, line )
PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 119 (test for
bogus messages, line 42)
FAIL: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 120 (test for
bogus messages, line 45)
FAIL: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 121 (test for
bogus messages, line 59)
FAIL: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 122 (test for
bogus messages, line 62)
FAIL: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 123 (test for
bogus messages, line 77)
FAIL: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 124 (test for
bogus messages, line 78)
PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime (test for excess errors)


bitfield-3.m:
@interface Derived: Base {
  signed e: 5;
  int f: 4;
  enum Enum g: 3;
} /* { dg-warning "padding struct size to alignment boundary" } */
@end


bitfield-5.m:
@interface Derived: Base {
@public
  signed e: 5;
  unsigned f: 4;
  enum Enum g: 3;
} /* { dg-warning "padding struct size to alignment boundary" } */
@end

[Bug d/108408] New: libphobos: Support building on *-*-cygwin

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108408
   Summary: libphobos: Support building on *-*-cygwin
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99794 for reference.

This PR is tracking the state of building libphobos on cygwin using 11.3, the
last compiler that can be bootstrapped natively.  Currently, it fails due to
missing definitions for FILE, snprintf, time_t, and clock_t.  I'm currently
trying to add them to libphobos/libdruntime/core/stdc/stdio.d, because the path
for CRuntime_Newlib is currently missing.  I seem to be falling down a rabbit
hole of needing to define struct after struct, so I'm trying to gather the work
here in hopes that some kind soul can help.

I should clarify that I'm unfamiliar with D, so what I'm putting here
definitely needs someone with experience to finish the work.  My hope is to
just get it far enough along that others can do so.  Whoever put in the gcc
warning that automatically converts function pointers for you, please accept my
thanks!

I started by lifting the structure definitions from cygwin's newlib, which
unfortunately have quite a few conditional components.  I don't know how
important this is if for instance a structure has:

struct S {
#ifdef A
int a;
#else
void * b;
};

or some variation of all manner of conditions that change the struct layout and
the total size.

Guidance as to whether this is the right approach or a total waste of time
would be appreciated :).  With what I have so far, I'm down to just the
following:

/cygdrive/k/gcc/src/gcc-git/libphobos/libdruntime/core/sys/posix/stdc/time.d:52:15:
error: module core.sys.posix.sys.types import 'time_t' not found
   52 | public import core.sys.posix.sys.types : time_t, clock_t;
  |   ^
/cygdrive/k/gcc/src/gcc-git/libphobos/libdruntime/core/sys/posix/stdc/time.d:52:15:
error: module core.sys.posix.sys.types import 'clock_t' not found
   52 | public import core.sys.posix.sys.types : time_t, clock_t;
  |   ^
/cygdrive/k/gcc/src/gcc-git/libphobos/libdruntime/core/stdc/stdio.d:1514:9:
error: undefined identifier 'fpos_t', did you mean alias '_fpos_t'?
 1514 | int fgetpos(FILE* stream, scope fpos_t * pos);
  | ^
/cygdrive/k/gcc/src/gcc-git/libphobos/libdruntime/core/stdc/stdio.d:1516:9:
error: undefined identifier 'fpos_t', did you mean alias '_fpos_t'?
 1516 | int fsetpos(FILE* stream, scope const fpos_t* pos);
  | ^
../../../../libphobos/libdruntime/core/demangle.d:2615:16: error: module
core.stdc.stdio import 'snprintf' not found, did you mean function
'core.stdc.stdio.sprintf'?
 2615 | import core.stdc.stdio : snprintf;
  |^


This is the diff so far:


diff --git a/libphobos/libdruntime/core/stdc/stdio.d
b/libphobos/libdruntime/core/stdc/stdio.d
index c76b922a3eb..52bcc9d7cdd 100644
--- a/libphobos/libdruntime/core/stdc/stdio.d
+++ b/libphobos/libdruntime/core/stdc/stdio.d
@@ -397,6 +397,196 @@ else version (CRuntime_Microsoft)
 ///
 alias shared(_iobuf) FILE;
 }
+else version (CRuntime_Newlib)
+{
+alias long  _off64_t;
+alias long  _fpos_t;
+alias long  _fpos64_t;
+alias int   _float_t;
+
+struct __sbuf {
+char*   _base;
+int _size;
+}
+
+struct _mbstate_t {
+int _count;
+union {
+dchar   _wch;
+char[4] _wchb;
+}
+}
+
+struct _rand48 {
+ushort[3] _seed;
+ushort[3] _mult;
+ushort _add;
+}
+
+struct __tm {
+int   __tm_sec;
+int   __tm_min;
+int   __tm_hour;
+int   __tm_mday;
+int   __tm_mon;
+int   __tm_year;
+int   __tm_wday;
+int   __tm_yday;
+int   __tm_isdst;
+}
+
+struct __lc_cats {
+const void*  ptr;
+char*buf;
+}
+
+struct lconv {
+char* decimal_point;
+char* thousands_sep;
+char* grouping;
+char* int_curr_symbol;
+char* currency_symbol;
+char* mon_decimal_point;
+char* mon_thousands_sep;
+char* mon_grouping;
+char* positive_sign;
+char* negative_sign;
+char int_frac_digits;
+char frac_digits;
+char p_cs_precedes;
+char p_sep_by_space;
+char n_cs_precedes;
+char n_sep_by_space;
+char p_sign_posn;
+char n_sign_posn;
+char int_n_cs_precedes;
+char int_n_sep_by_space;
+char int_n_sign_posn;
+char int_p_cs_precedes;
+char int_p_sep_by_space;
+char int_p_sign_posn;
+}
+
+struct __locale_t {
+char[7][31 + 1] categories

[Bug middle-end/108300] `abort()` macro cause bootstrap failure on *-w64-mingw32

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #15 from nightstrike  ---
Someone on irc (jakub?) suggested just changing all of the aborts to
gcc_unreachable. Is that a viable option?

[Bug target/82028] Windows x86_64 should not pass float aggregates in xmm

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #5 from nightstrike  ---
(In reply to jon_y from comment #4)
> I can't seem to change the bug status to confirmed.

"NEW" is confirmed

[Bug target/90256] Optimizer with interrupt routines

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #2 from nightstrike  ---
This is not target specific (or at least it also happens on x86_64-pc-linux).

[Bug d/99794] libphobos: Support building on *-*mingw*

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #3 from nightstrike  ---
Hm, looks like it *IS* in 11.  I was confused by the PR being open and the
version stating 11, thinking that it still wasn't applied.  So the remaining
issues then are building on cygwin.  But at least on a linux to mingw cross,
the testsuite passes with only 33 fails.

[Bug d/99794] libphobos: Support building on *-*mingw*

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #2 from nightstrike  ---
Hoping this can be backported to 11 so that we can easily bootstrap later
versions.  Meanwhile, will this also fix the build errors on cygwin, or if is
specific to mingw?

[Bug testsuite/108204] pr84973-2.C fails with wrong error on mingw

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #4 from nightstrike  ---
(In reply to Richard Biener from comment #3)
> I'd suggest to add a dg-additional-options -fno-ms-extensions to the test
> then.

We certainly can (well, Jon can :P), but shouldn't the ms extensions ultimately
be fixed to work right?

[Bug libstdc++/108332] dynamic link libstdc++ with win32 thread model's gcc for windows native toolchain would cause .rdata_r: section below image base

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||10walls at gmail dot com,
   ||nightstrike at gmail dot com

--- Comment #5 from nightstrike  ---
(In reply to cqwrteur from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > cygwin was improved here:
> > https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;
> > h=801120c1f402f9b0f72b5a231bf9e1cf82614cac
> > 
> > It might be the case mingw linker script is broken 
> 
> This is mingw-w64, not newlib-cygwin

I think he's suggesting that we have to apply the same solution to mingw that
Corinna applied to Cygwin.

[Bug testsuite/108192] g++.dg/cet-notrack-1.C searching for wrong function on mingw

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #3 from nightstrike  ---
Created attachment 54209
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54209=edit
Patch to change printf to puts so it works everywhere

[Bug testsuite/108152] gcc.dg/pr71558.c fails for LLP64

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||10walls at gmail dot com

--- Comment #3 from nightstrike  ---
(In reply to Andrew Pinski from comment #1)
> { dg-options "" }

So just to be pedantic (pun intended!), the options currently in use are:

-fdiagnostics-plain-output -ansi -pedantic-errors


If we use dg-options "", both -ansi and -pedantic-errors are removed. 
-fdiagnostics-plain-output stays.  Is this ok?

[Bug preprocessor/107974] compiler can't find source file in path that is longer than 255 characters

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #7 from nightstrike  ---
Someone with build system experience could modify the build of the toolchain
binaries to include a call to windres to add the manifest. This would just be
gcc itself and not what gcc produces. I guess maybe the binutils executables
would benefit also.

[Bug testsuite/108150] gcc.dg/attr-aligned.c fails with incorrect max alignment

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||10walls at gmail dot com

--- Comment #2 from nightstrike  ---
It occurs to me, if GCC already internally knows the max alignment (since it's
outputting it in the warning message), why do we need to have such complicated
preprocessor magic to guess at what the alignment is?  Would it be easier to
have GCC just define __GCC_MAX_ALIGNMENT__ or something similar for all
targets, and then use that in the test?

[Bug target/102993] -fcf-protection=full produces segfaulting code when targeting 32-bit x86 (i686)

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #9 from nightstrike  ---
Maybe it's time to disable sjlj support on windows.  dwarf or SEH is better on
average.

[Bug target/103327] Do not search MINGW in the search dir

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #2 from nightstrike  ---
This is intentional, and goes back to at least gcc 3.  The idea here is that
the path /mingw, which has to be in your sysroot and is usually a symlink to
$target, is the place to find the mingw-w64 headers and import libraries.  This
is the equivalent of /usr/local in a posix environment, which doesn't exist for
this target.

[Bug bootstrap/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #11 from nightstrike  ---
Possible duplicate of PR39947

[Bug bootstrap/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #10 from nightstrike  ---
(In reply to cqwrteur from comment #5)
> I think the copy to bin behavior should be removed. It should be just like
> normal linux distribution. 64 bit dlls in lib. 32 bit dlls in lib32.

This is a feature of Windows.  Windows will find dlls in PATH, not in lib
directories.

Multilib toolchains do face issues with versioned runtime libraries.  You can
try configuring with --enable-version-specific-runtime-libs.  Generally
speaking, it's easier to just build two separate toolchains than to try getting
multilib to work.  I made the mistake of pushing for multilib to be enabled by
default, and we never got it working quite well.

Anyway, I don't think this is a bug as stated.

[Bug c++/106395] [12/13 regression] [mingw] "redeclared without dllimport attribute: previous dllimport ignored" on C++ friend since r12-299-ga0fdff3cf33f72

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #4 from nightstrike  ---
This appears to be fixed in GCC 13

[Bug libstdc++/108210] error: 'mutex' does not name a type; did you mean 'minutes'? for x86_64-w64-mingw32 target with win32 thread model

[nightstrike at gmail dot com via Gcc-bugs]

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

nightstrike  changed:

   What|Removed |Added

 CC||i.nixman at autistici dot org,
   ||nightstrike at gmail dot com

--- Comment #2 from nightstrike  ---
Is this before or after this patch set was applied?

https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609116.html

[Bug c++/108207] ICE in testcase g++.dg/other/ptrmem8.C on mingw

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #1 from nightstrike  ---
Ah, Andrew, before you beat me to it...  this doesn't ICE if you pass
-fno-ms-extensions, and it does ICE on Linux if you pass -fms-extensions

[Bug c++/108207] New: ICE in testcase g++.dg/other/ptrmem8.C on mingw

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108207
   Summary: ICE in testcase g++.dg/other/ptrmem8.C on mingw
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

All variants of this test fail (98, 14, 17, 20)

// Target: x86_64-w64-mingw32
// Configured with: ../configure --disable-nls --with-sysroot=/tmp/rtmingw
--target=x86_64-w64-mingw32 --disable-multilib
--enable-languages=c,c++,fortran,lto,objc,obj-c++,m2,rust
// Thread model: win32
// Supported LTO compression algorithms: zlib zstd
// gcc version 13.0.0 20221222 (experimental) (GCC)
bbe04bade0cc3b17e62c2af3d89b899367e7d2d1


g++.dg/other/ptrmem8.C: In function 'void foo(void (A::*)())':
g++.dg/other/ptrmem8.C:9:9: internal compiler error: in build_ptrmemfunc, at
cp/typeck.cc:10015


0x7f38c0 build_ptrmemfunc(tree_node*, tree_node*, int, bool, int)
../../gcc/cp/typeck.cc:10015
0xc643bb cp_build_addr_expr_1
../../gcc/cp/typeck.cc:7241
0xc64704 cp_build_addr_expr_strict
../../gcc/cp/typeck.cc:7269
0xc64704 build_x_unary_op(unsigned int, tree_code, cp_expr, tree_node*, int)
../../gcc/cp/typeck.cc:6890
0xb9b7c3 cp_parser_unary_expression
../../gcc/cp/parser.cc:9039
0xb688bc cp_parser_binary_expression
../../gcc/cp/parser.cc:10101
0xb69612 cp_parser_assignment_expression
../../gcc/cp/parser.cc:10444
0xb6ba73 cp_parser_expression
../../gcc/cp/parser.cc:10614
0xb6fa07 cp_parser_expression_statement
../../gcc/cp/parser.cc:12758
0xb7aced cp_parser_statement
../../gcc/cp/parser.cc:12538
0xb7bfdd cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:12909
0xb7c0b7 cp_parser_compound_statement
../../gcc/cp/parser.cc:12861
0xb9ea55 cp_parser_function_body
../../gcc/cp/parser.cc:25280
0xb9ea55 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.cc:25331
0xba09fe cp_parser_function_definition_after_declarator
../../gcc/cp/parser.cc:31942
0xba1eb0 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.cc:31859
0xba1eb0 cp_parser_init_declarator
../../gcc/cp/parser.cc:22734
0xba928e cp_parser_single_declaration
../../gcc/cp/parser.cc:32459
0xba94b4 cp_parser_template_declaration_after_parameters
../../gcc/cp/parser.cc:32012
0xba9d40 cp_parser_explicit_template_declaration
../../gcc/cp/parser.cc:32285



Preprocessed source is as you might expect, given the lack of includes:
struct A {};

template void foo(void (A::* f)())
{
  A a;
  &(a.*f);
}

template void bar(void (A::* f)())
{
  A *p;
  &(p->*f);
}

[Bug c++/108204] pr84973-2.C fails with wrong error on mingw

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #2 from nightstrike  ---
(In reply to Andrew Pinski from comment #1)
> Try with -fno-ms-extensions or try -fms-extension on Linux.

Hey, we have a winner!  -fms-extension on Linux results in the bad error, and
-fno-ms-extensions on mingw results in the good one!

[Bug c++/108204] New: pr84973-2.C fails with wrong error on mingw

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108204
   Summary: pr84973-2.C fails with wrong error on mingw
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

All of the pr84973-2.C tests fail on mingw.  They give the output:

g++.dg/template/pr84973-2.C: In instantiation of 'void a()::c::b() [with int
 = 0]':
g++.dg/template/pr84973-2.C:7:3:   required from 'void a() [with int
 = 0]'
g++.dg/template/pr84973-2.C:12:7:   required from here
g++.dg/template/pr84973-2.C:5:20: error: statement cannot resolve address of
overloaded function

or outside the testsuite for slightly different formatting:
$ x86_64-w64-mingw32-g++ -c a.cc
a.cc: In instantiation of 'void a()::c::b() [with int  = 0]':
a.cc:5:11:   required from 'void a() [with int  = 0]'
a.cc:10:8:   required from here
a.cc:3:38: error: statement cannot resolve address of overloaded function
3 |   void b() try { b; } catch (short) { // { dg-error
"invalid use" }
  |  ^

On linux, however, the output is different:
a.cc: In instantiation of 'void a()::c::b() [with int  = 0]':
a.cc:5:11:   required from 'void a() [with int  = 0]'
a.cc:10:8:   required from here
a.cc:3:38: error: invalid use of non-static member function 'void a()::c::b()
[with int  = 0]'
3 |   void b() try { b; } catch (short) { // { dg-error
"invalid use" }
  |  ^
a.cc:3:28: note: declared here
3 |   void b() try { b; } catch (short) { // { dg-error
"invalid use" }
  |^

[Bug c++/108203] New: Format string checking with __USE_MINGW_ANSI_STDIO

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108203
   Summary: Format string checking with __USE_MINGW_ANSI_STDIO
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

Circa v4.5, some mingw-w64 users discovered an issue with printf functions and
g++.  Addressing this resulted in a kludge on the mingw-w64 headers side, but
this should have been documented here so that we can remove the kludge and have
a better coordination between projects.

Original mail thread describing the problem:
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/4F05E61C.6010506%40t-online.de/#msg28632591


Bug report that came from it:
https://sourceforge.net/p/mingw-w64/bugs/292/


Header change from fixing the bug report:
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/280b5f973e/


This commit might potentially be related:
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/1ed6dcc2a19c1aeac5dd4e6530af899fd8d95dbb/

+/* Override __builtin_printf-routines ... Kludge for libstdc++ ...*/
+#define __builtin_vsnprintf __mingw_vsnprintf
+#define __builtin_vsprintf __mingw_vsprintf


I hope with this PR, we can better coordinate and make both sides better :)

[Bug tree-optimization/101854] [11 Regression] Invalid warning -Wstringop-overflow wrong argument

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #11 from nightstrike  ---
(In reply to Martin Sebor from comment #9)
> Fixed for GCC 12.  The patch is far too intrusive to backport but the
> following should fix the problem in GCC 11:

Would you mind applying it to 11?  Thanks!

Also, I think in your diff below, there's "// A nonnull" that should be "/* A
nonnull"... / to *

> diff --git a/gcc/calls.c b/gcc/calls.c
> index fcb0d6dec69..f116923c890 100644
> --- a/gcc/calls.c
> +++ b/gcc/calls.c
> @@ -2295,14 +2295,15 @@ initialize_argument_information (int num_actuals
> ATTRIBUTE_UNUSED,
>  operand for later processing.  */
>if (attr_access *access = rdwr_idx.get (argpos))
> {
> + int idx = i - !!struct_value_addr_value;
>   if (POINTER_TYPE_P (type))
> {
> - access->ptr = args[i].tree_value;
> + access->ptr = args[idx].tree_value;
>   // A nonnull ACCESS->SIZE contains VLA bounds.  */
> }
>   else
> {
> - access->size = args[i].tree_value;
> + access->size = args[idx].tree_value;
>   gcc_assert (access->ptr == NULL_TREE);
> }
> }

[Bug testsuite/108192] g++.dg/cet-notrack-1.C searching for wrong function on mingw

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #2 from nightstrike  ---
(In reply to H.J. Lu from comment #1)
> Since Windows doesn't support IBT, this test can be limited to Linux.

I don't know what IBT is, but if I change the two printf's to puts(), the tests
pass.  So, maybe they don't have to be skipped?

[Bug testsuite/108192] New: g++.dg/cet-notrack-1.C searching for wrong function on mingw

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108192
   Summary: g++.dg/cet-notrack-1.C searching for wrong function on
mingw
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

Created attachment 54139
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54139=edit
cet-notrack-1.s

g++.dg/cet-notrack-1.C Tries to find 'call puts()' in the asm after calling
printf() on the c++ side.  On Mingw, we do magic things with converting
printf() into __mingw_ variants to support MS style printf and other things. 
So the assembler dump on mingw results in a call to __mingw_vfprintf in this
particular case.

It would likely be possible to fix the testcase by searching for "call
__mingw_*printf" or something, but I'm curious if this is really a case of a
missed optimization.  The strings in question are simple string literals, so we
don't care about mingw or ms special versions of printf, and a call to puts
should be fine.  I don't know if this testcase is specifically trying to
validate that optimization, but it at least indirectly revealed it.

Asm attached.

[Bug testsuite/108190] g++.target/i386/*pr54700*.C testcases fail on x86_64-mingw

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #5 from nightstrike  ---
Created attachment 54138
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54138=edit
avx512vl-pr54700-1b.s

[Bug testsuite/108190] g++.target/i386/*pr54700*.C testcases fail on x86_64-mingw

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #4 from nightstrike  ---
Created attachment 54137
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54137=edit
avx512vl-pr54700-1a.s

[Bug testsuite/108190] g++.target/i386/*pr54700*.C testcases fail on x86_64-mingw

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #3 from nightstrike  ---
Created attachment 54136
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54136=edit
avx2-pr54700-1.s

[Bug testsuite/108190] Various testsuite asm fails

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #1 from nightstrike  ---
Created attachment 54135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54135=edit
avx-pr54700-1.s

[Bug testsuite/108190] New: Various testsuite asm fails

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108190
   Summary: Various testsuite asm fails
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

Created attachment 54134
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54134=edit
asm output 1

The following are a collection of failures from running PR54700 tests on a
linux to mingw cross compiler under Wine 7.20:

FAIL: g++.target/i386/sse4_1-pr54700-1.C   scan-assembler-not pcmpgt[bdq]
FAIL: g++.target/i386/sse4_1-pr54700-1.C   scan-assembler-times pblendvb 2
FAIL: g++.target/i386/sse4_1-pr54700-1.C   scan-assembler-times blendvps 4
FAIL: g++.target/i386/sse4_1-pr54700-1.C   scan-assembler-times blendvpd 4
FAIL: g++.target/i386/avx-pr54700-1.C   scan-assembler-not vpcmpgt[bdq]
FAIL: g++.target/i386/avx-pr54700-1.C   scan-assembler-times vpblendvb 2
FAIL: g++.target/i386/avx-pr54700-1.C   scan-assembler-times vblendvps 4
FAIL: g++.target/i386/avx-pr54700-1.C   scan-assembler-times vblendvpd 4
FAIL: g++.target/i386/avx2-pr54700-1.C   scan-assembler-not vpcmpgt[bdq]
FAIL: g++.target/i386/avx2-pr54700-1.C   scan-assembler-times vpblendvb 2
FAIL: g++.target/i386/avx2-pr54700-1.C   scan-assembler-times vblendvps 4
FAIL: g++.target/i386/avx2-pr54700-1.C   scan-assembler-times vblendvpd 4
FAIL: g++.target/i386/avx512vl-pr54700-1a.C   scan-assembler-times vpblendvb 2
FAIL: g++.target/i386/avx512vl-pr54700-1b.C   scan-assembler-times pblendvb 2


I don't know if it's helpful, but these are the /proc/cpuinfo flags on the cpus
running under wine on an Intel(R) Xeon(R) Gold 6230:

flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb
rdtscp lm constant_tsc art arch
_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni
pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm
pcid dca sse4_1 sse4_2 x2apic movbe
 popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch
cpuid_fault epb cat_l3 cdp_l3 invpcid_single ssbd mba ibrs ibpb stibp
ibrs_enhanced fsgsbase tsc_adjust bmi1
hle avx2 smep bmi2 erms invpcid cqm mpx rdt_a avx512f avx512dq rdseed adx smap
clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1
xsaves cqm_llc cqm_occup_llc cqm_
mbm_total cqm_mbm_local dtherm ida arat pln pts hwp hwp_act_window hwp_epp
hwp_pkg_req pku ospke avx512_vnni md_clear flush_l1d arch_capabilities

[Bug testsuite/108152] gcc.dg/pr71558.c fails for LLP64

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #2 from nightstrike  ---
(In reply to Andrew Pinski from comment #1)
> { dg-options "" }

That would remove every option, no?  Do others matter, like -pedantic, or
whatever else is there?

[Bug testsuite/108150] gcc.dg/attr-aligned.c fails with incorrect max alignment

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #1 from nightstrike  ---
Ok, that was dumb.. WINT_MAX is wide int max... hah.  So maybe test for
__CYGWIN__ || __WIN32__

[Bug testsuite/108161] New: gcc.dg/ipa/pr96040.c fails with incorrect size_t assumption (snprintf, strspn)

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108161
   Summary: gcc.dg/ipa/pr96040.c fails with incorrect size_t
assumption (snprintf, strspn)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

gcc.dg/ipa/pr96040.c assumes that size_t is unsigned long, which it isn't for
LLP64.  The following definitions are therefor incorrect:

int snprintf(char *, unsigned long, const char *, ...);
unsigned long strspn(const char *, const char *);


Changing "unsigned long" in both instances to "__SIZE_TYPE__" makes the test
pass:

int snprintf(char *, __SIZE_TYPE__, const char *, ...);
__SIZE_TYPE__ strspn(const char *, const char *);


However, it's also possible, and perhaps more maintainable, to just use
__builtin_*, or to include  and .  Both of the following
options work, though there are many ways to skin this cat:



diff --git a/gcc/testsuite/gcc.dg/ipa/pr96040.c
b/gcc/testsuite/gcc.dg/ipa/pr96040.c
index af7e9c4ed94..9c9b76269a6 100644
--- a/gcc/testsuite/gcc.dg/ipa/pr96040.c
+++ b/gcc/testsuite/gcc.dg/ipa/pr96040.c
@@ -3,8 +3,8 @@


 int puts(const char *);
-int snprintf(char *, unsigned long, const char *, ...);
-unsigned long strspn(const char *, const char *);
+int snprintf(char *, __SIZE_TYPE__, const char *, ...);
+__SIZE_TYPE__ strspn(const char *, const char *);

 struct TValue {
   union {



diff --git a/gcc/testsuite/gcc.dg/ipa/pr96040.c
b/gcc/testsuite/gcc.dg/ipa/pr96040.c
index af7e9c4ed94..2c8d405ff9b 100644
--- a/gcc/testsuite/gcc.dg/ipa/pr96040.c
+++ b/gcc/testsuite/gcc.dg/ipa/pr96040.c
@@ -3,8 +3,8 @@


 int puts(const char *);
-int snprintf(char *, unsigned long, const char *, ...);
-unsigned long strspn(const char *, const char *);
+#define snprintf __builtin_snprintf
+#define strspn __builtin_strspn

 struct TValue {
   union {

[Bug testsuite/108160] gcc.dg/format/ms_attr-3.c testsuite failure, missed update from r9-4163-g1d24950977c730

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #1 from nightstrike  ---
It looks like the other testsuite changes (attr-8.c, the objc/c++ tests, etc.)
should be evaluated and ported over also, so this isn't a complete fix.

Alternatively, maybe this would scale better in the future if the ms_ tests
were integrated into the non-ms_ tests, with a macro to set the format checking
attribute between gnu_attr_printf and ms_printf.

[Bug testsuite/108160] New: gcc.dg/format/ms_attr-3.c testsuite failure, missed update from r9-4163-g1d24950977c730

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108160
   Summary: gcc.dg/format/ms_attr-3.c testsuite failure, missed
update from r9-4163-g1d24950977c730
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

Created attachment 54120
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54120=edit
Suggested changes

r9-4163-g1d24950977c730 changed the output of certain messages and adjusted the
non-ms-printf cases, but missed the windows version of attr-3.c.

FAIL: gcc.dg/format/ms_attr-3.cbad number (test for errors, line 44)
FAIL: gcc.dg/format/ms_attr-3.cbad number (test for errors, line 45)
FAIL: gcc.dg/format/ms_attr-3.cbad format_arg number (test for errors, line
47)
FAIL: gcc.dg/format/ms_attr-3.cformat int string (test for errors, line 59)
FAIL: gcc.dg/format/ms_attr-3.csigned char string (test for errors, line
60)
FAIL: gcc.dg/format/ms_attr-3.cunsigned char string (test for errors, line
61)
FAIL: gcc.dg/format/ms_attr-3.cnot ... (test for errors, line 63)
FAIL: gcc.dg/format/ms_attr-3.cformat_arg int string (test for errors, line
66)
FAIL: gcc.dg/format/ms_attr-3.cformat_arg signed char string (test for
errors, line 67)
FAIL: gcc.dg/format/ms_attr-3.cformat_arg unsigned char string (test for
errors, line 68)
FAIL: gcc.dg/format/ms_attr-3.c(test for excess errors)


Excess errors:
gcc.dg/format/ms_attr-3.c:44:1: warning: 'format' attribute argument 2 value
'foo' is not an integer constant [-Wattributes]
gcc.dg/format/ms_attr-3.c:45:1: warning: 'format' attribute argument 3 value
'foo' is not an integer constant [-Wattributes]
gcc.dg/format/ms_attr-3.c:47:1: warning: 'format_arg' attribute argument value
'foo' is not an integer constant [-Wattributes]
gcc.dg/format/ms_attr-3.c:59:1: error: 'format' attribute argument 2 value '1'
refers to parameter type 'int'
gcc.dg/format/ms_attr-3.c:60:1: error: 'format' attribute argument 2 value '1'
refers to parameter type 'signed char *'
gcc.dg/format/ms_attr-3.c:61:1: error: 'format' attribute argument 2 value '1'
refers to parameter type 'unsigned char *'
gcc.dg/format/ms_attr-3.c:63:1: error: 'format' attribute argument 3 value '2'
does not refer to a variable argument list
gcc.dg/format/ms_attr-3.c:66:1: error: 'format_arg' attribute argument value
'1' refers to parameter type 'int'
gcc.dg/format/ms_attr-3.c:67:1: error: 'format_arg' attribute argument value
'1' refers to parameter type 'signed char *'
gcc.dg/format/ms_attr-3.c:68:1: error: 'format_arg' attribute argument value
'1' refers to parameter type 'unsigned char *'


Applying the changes to attr-3.c directly to ms_attr-3.c isn't exactly right,
though.  First, gnu_attr_printf needs to change to ms_printf.  Second, there
are followup changes from r9-5404-g23db6ced33c245 to fix the remaining issues. 
The resulting diff is a bit big, so I uploaded suggested changes as an
attachment.

[Bug testsuite/108159] gcc.dg/format/ms-format2.c fails due to warning message change

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #1 from nightstrike  ---
Andrew pointed out that this is the better fix, and it does indeed work:

diff --git a/gcc/testsuite/gcc.dg/format/ms-format2.c
b/gcc/testsuite/gcc.dg/format/ms-format2.c
index 5c950522a7c..9d21d108642 100644
--- a/gcc/testsuite/gcc.dg/format/ms-format2.c
+++ b/gcc/testsuite/gcc.dg/format/ms-format2.c
@@ -3,7 +3,7 @@
 */
 /* Origin: Kai Tietz  */
 /* { dg-do compile { target { *-*-mingw* } } } */
-/* { dg-options "-std=iso9899:1999 -pedantic -Wformat -Wno-pedantic-ms-format"
} */
+/* { dg-options "-std=iso9899:1999 -pedantic -Wformat -Wno-pedantic-ms-format
-ftrack-macro-expansion=0" } */

 #define USE_SYSTEM_FORMATS
 #include "format.h"

[Bug testsuite/108159] New: gcc.dg/format/ms-format2.c fails due to warning message change

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108159
   Summary: gcc.dg/format/ms-format2.c fails due to warning
message change
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

This is presumably a regression, as the test worked when it first went in. 
However, the warning message being tested for has since changed the line that
gets reported:

  printf (XXX, p); /* { dg-warning "format" "bad argument types" } */
  printf ("%I32x", f); /* { dg-warning "format" "bad argument types" } */
  printf ("%I64x", d); /* { dg-warning "format" "bad argument types" } */

gcc.dg/format/ms-format2.c: In function 'foo':
gcc.dg/format/ms-format2.c:12:13: warning: format '%I64x' expects argument of
type 'long long unsigned int', but argument 2 has type 'void *' [-Wformat=]
gcc.dg/format/ms-format2.c:20:11: note: in expansion of macro 'XXX'
gcc.dg/format/ms-format2.c:12:18: note: format string is defined here
gcc.dg/format/ms-format2.c:21:16: warning: format '%I32x' expects argument of
type 'long unsigned int', but argument 2 has type 'double' [-Wformat=]
gcc.dg/format/ms-format2.c:22:16: warning: format '%I64x' expects argument of
type 'long long unsigned int', but argument 2 has type 'double' [-Wformat=]
FAIL: gcc.dg/format/ms-format2.c   -DWIDE  bad argument types (test for
warnings, line 20)
PASS: gcc.dg/format/ms-format2.c   -DWIDE  bad argument types (test for
warnings, line 21)
PASS: gcc.dg/format/ms-format2.c   -DWIDE  bad argument types (test for
warnings, line 22)
FAIL: gcc.dg/format/ms-format2.c   -DWIDE  (test for excess errors)
Excess errors:
gcc.dg/format/ms-format2.c:12:13: warning: format '%I64x' expects argument of
type 'long long unsigned int', but argument 2 has type 'void *' [-Wformat=]


I assume the fix is to move the dg-warning to the macro definition line, but I
don't know how to distinguish between the 32 and 64-bit cases in dejagnu.  To
be clear, the following change makes the test work for the 64-bit case:

diff --git a/gcc/testsuite/gcc.dg/format/ms-format2.c
b/gcc/testsuite/gcc.dg/format/ms-format2.c
index 5c950522a7c..e56bfc4a9c4 100644
--- a/gcc/testsuite/gcc.dg/format/ms-format2.c
+++ b/gcc/testsuite/gcc.dg/format/ms-format2.c
@@ -9,7 +9,7 @@
 #include "format.h"

 #ifdef _WIN64
-#define XXX "%I64x"
+#define XXX "%I64x" /* { dg-warning "format" "bad argument types" } */
 #else
 #define XXX "%I32x"
 #endif
@@ -17,7 +17,7 @@
 void
 foo (float f, double d, void *p)
 {
-  printf (XXX, p); /* { dg-warning "format" "bad argument types" } */
+  printf (XXX, p);
   printf ("%I32x", f); /* { dg-warning "format" "bad argument types" } */
   printf ("%I64x", d); /* { dg-warning "format" "bad argument types" } */
 }



But that won't address the 32-bit case.  I suppose there's some other  "{}"
thing to put on both #define XXX lines to choose which architecture, but I
don't know what that would be.  Hopefully this is enough diagnosis for someone
more knowledgeable to pick it up and run with it.

[Bug testsuite/108152] New: gcc.dg/pr71558.c fails for LLP64

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108152
   Summary: gcc.dg/pr71558.c fails for LLP64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

gcc.dg/pr71558.c has the following lines:

__SIZE_TYPE__ strlen (const char *);
void *malloc (__SIZE_TYPE__);
__SIZE_TYPE__ b = strlen (a);


These are good in that they support LLP64 through size_t, however they fail
because this test case is compiled with -ansi.  When using -ansi, the following
warnings appear:

gcc.dg/pr71558.c:6:1: error: ISO C90 does not support 'long long' [-Wlong-long]
gcc.dg/pr71558.c:7:1: error: ISO C90 does not support 'long long' [-Wlong-long]
gcc.dg/pr71558.c:14:1: error: ISO C90 does not support 'long long'
[-Wlong-long]


And of course, on LLP64 systems, __SIZE_TYPE__ is in fact a long long. 
Hopefully, -ansi can just be removed from the compile options, although I don't
know how to do that.

[Bug testsuite/108151] New: gcc.dg/pr64536.c stores pointers in a long, broken for llp64

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108151
   Summary: gcc.dg/pr64536.c stores pointers in a long, broken for
llp64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

gcc/testsuite/gcc.dg/pr64536.c contains lines such as the following:

struct S { long q; } *h;
long a, b, g, j, k, *c, *d, *e, *f, *i;
i = (long *) (h->q = *f);
*c++ = (long) f;

These lines were added with the following commit:
adfac8dfed7b (Jakub Jelinek 2015-01-09 22:17:10 +0100 56)

This has the erroneous assumption that a long can hold a pointer.  This should
probably just use intptr_t or __INTPTR_TYPE__ for all occurrences.  Changing q
to be an __INTPTR_TYPE__ and both casts of f to be likewise makes the test
pass.

Note: I didn't put mingw in the target field, because this affects any LLP64
platform.

[Bug c/108150] New: gcc.dg/attr-aligned.c fails with incorrect max alignment

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 108150
   Summary: gcc.dg/attr-aligned.c fails with incorrect max
alignment
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

On Windows targets, the max alignment is 8192.  However, this test winds up
assuming the max alignment is much larger, causing multiple failures. 
Specifically, the test is getting into:

#elif __powerpc64__ || __x86_64__
/* Is this processor- or operating-system specific?  */
#  define ALIGN_MAX_STATIC  ALIGN_MAX_HARD

and ALIGN_MAX_HARD is set to:

/* The maximum alignment GCC can handle.  */
#define ALIGN_MAX_HARD 0x1000


If it fell through to:
#else
   /* Guaranteed to be accepted regardless of the target.  */
#  define ALIGN_MAX_STATIC  __BIGGEST_ALIGNMENT__

that would still be wrong, as __BIGGEST_ALIGNMENT__ is set to 16.


Another case that checks for Windows and sets it to 8192 should fix it.  The
check should cover all windows platforms, including cygwin and msys. 
Technically, msys defines both __MSYS__ and __CYGWIN__, so testing for
__CYGWIN__ || __MINGW32__ || __MINGW64__ would cover all bases.  Alternatively,
and potentially easier, __WINT_MAX__ is defined on all targets, so you could
just test for that.


Someone will likely want to do it perhaps in a more sophisticated way, or be
more obvious about the macros being tested if WINT_MAX is an obscure choice, or
some other reason.  However, the following change works:

diff --git a/gcc/testsuite/gcc.dg/attr-aligned.c
b/gcc/testsuite/gcc.dg/attr-aligned.c
index a2e11c96180..a56973c99b4 100644
--- a/gcc/testsuite/gcc.dg/attr-aligned.c
+++ b/gcc/testsuite/gcc.dg/attr-aligned.c
@@ -22,6 +22,9 @@
 #  define ALIGN_MAX_STATIC  2
 /* Work around a pdp11 ICE (see PR target/87821).  */
 #  define ALIGN_MAX_AUTO(ALIGN_MAX_HARD >> 14)
+#elif __WINT_MAX__
+#  define ALIGN_MAX_STATIC  8192
+#  define ALIGN_MAX_AUTO8192
 #elif __powerpc64__ || __x86_64__
 /* Is this processor- or operating-system specific?  */
 #  define ALIGN_MAX_STATIC  ALIGN_MAX_HARD


For reference, these are the excess errors:
gcc/testsuite/gcc.dg/attr-aligned.c:65:1: error: requested alignment
'268435456' exceeds object file maximum 8192
gcc/testsuite/gcc.dg/attr-aligned.c:66:1: error: requested alignment
'268435456' exceeds object file maximum 8192
gcc/testsuite/gcc.dg/attr-aligned.c:67:1: error: requested alignment
'268435456' exceeds object file maximum 8192
gcc/testsuite/gcc.dg/attr-aligned.c:68:1: error: requested alignment
'268435456' exceeds object file maximum 8192
gcc/testsuite/gcc.dg/attr-aligned.c:70:1: error: static assertion failed
gcc/testsuite/gcc.dg/attr-aligned.c:71:1: error: static assertion failed
gcc/testsuite/gcc.dg/attr-aligned.c:72:1: error: static assertion failed
gcc/testsuite/gcc.dg/attr-aligned.c:73:1: error: static assertion failed
gcc/testsuite/gcc.dg/attr-aligned.c:61:22: error: alignment of 't_max' is
greater than maximum object file alignment 8192
gcc/testsuite/gcc.dg/attr-aligned.c:78:47: error: alignment of 'alignas_sc_max'
is greater than maximum object file alignment 8192
gcc/testsuite/gcc.dg/attr-aligned.c:79:40: error: alignment of 'alignas_c_max'
is greater than maximum object file alignment 8192
gcc/testsuite/gcc.dg/attr-aligned.c:80:34: error: alignment of 'alignas_v_max'
is greater than maximum object file alignment 8192
gcc/testsuite/gcc.dg/attr-aligned.c:99:31: error: alignment of 'aligned_st_max'
is greater than maximum object file alignment 8192

[Bug c/107754] New: Confusing -Warray-bounds warning with strcpy

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 107754
   Summary: Confusing -Warray-bounds warning with strcpy
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

Metabug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=warray-bounds

// Compile with GCC 12.2.0 with -O2:
//warning: ‘strcpy’ offset 0 is out of the bounds [0, 0] [-Warray-bounds]
// no warning without -O2

struct Inst;
struct Class { int offset; };

static struct Class * classFoo; // No problem without static here

struct Foo
{
   unsigned int a;   // no problem if commented out
   char bar[1024];
};

void setFoo(struct Inst * this, const char * value)
{
   struct Foo * ptr = (struct Foo *)(this ? (((char *)this) + classFoo->offset)
: 0);
   __builtin_strcpy(ptr->bar, value);
}


$ gcc-12 -c -O2 -Warray-bounds a.c -o /dev/null
a.c: In function 'setFoo':
a.c:19:4: warning: '__builtin_strcpy' offset 0 is out of the bounds [0, 0]
[-Warray-bounds]
   19 |__builtin_strcpy(ptr->bar, value);
  |^

[Bug c++/107531] List of references calls destructors, add warning?

[nightstrike at gmail dot com via Gcc-bugs]

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

--- Comment #2 from nightstrike  ---
It looks like you're right.  The root cause of the problem is that in my
non-reduced case, I didn't have a copy constructor, but I had a non-default
destructor that was releasing resources twice.  So it's clearly my fault, I
just kind of hoped the compiler could be a little more omniscient :)

If a warning is not really possible here, then I guess this could be "closed
invalid".  Or maybe there are already PR's open to request a warning to remind
you that you did something requiring a non-default copy constructor?

[Bug c++/107531] New: List of references calls destructors, add warning?

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 107531
   Summary: List of references calls destructors, add warning?
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

The following code results in a destructor being calling twice:

#include 
struct S {
S() { __builtin_printf("ctor\n"); }
~S() { __builtin_printf("dtor\n"); }
};

template
void f(Args const & ... args) {
for (auto const & s: { args... })
;
}

int main() {
S s;
f(s);
}

$ ./a.out
ctor
dtor
dtor


Changing line 9 to use pointers fixes it:

for (auto const * s: {  })

$ ./a.out
ctor
dtor


I think that if my code is exploiting some kind of bad behavior (and it likely
is), a warning at -Wall would be a nice addition (currently, there is none). 
If what I'm doing is allowed, I don't think calling a destructor twice is the
best idea :) :).  I'd be betting money on the first thing, though.  Maybe
adding something from -fsanitize=undefined would be an option?

[Bug c++/107463] New: Better error request for invalid initializer list of aggregate

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 107463
   Summary: Better error request for invalid initializer list of
aggregate
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

struct S {
struct Config {
int x;
};
S(Config const & cfg);
};

void f() {
S s({
.y = "x"
});
}

results in:

: In function 'void f()':
:11:6: error: no matching function for call to 'S::S()'
   11 | });
  |  ^
:5:5: note: candidate: 'S::S(const Config&)'
5 | S(Config const & cfg);
  | ^
:5:22: note:   no known conversion for argument 1 from '' to 'const S::Config&'
5 | S(Config const & cfg);
  |   ~~~^~~
:1:8: note: candidate: 'constexpr S::S(const S&)'
1 | struct S {
  |^
:1:8: note:   no known conversion for argument 1 from '' to 'const S&'
:1:8: note: candidate: 'constexpr S::S(S&&)'
:1:8: note:   no known conversion for argument 1 from '' to 'S&&'



It would be a lot more helpful if the error was something like "there's no
member named y in Config, did you mean x?"

PR71542 seems related, but different.

[Bug c/103996] New: Enhancement: Better diagnostic for invalid reuse of a function name

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 103996
   Summary: Enhancement: Better diagnostic for invalid reuse of a
function name
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

Related email thread:
https://gcc.gnu.org/pipermail/gcc-help/2022-January/141117.html

I recently hit this problem:

#include 
void f() {
index[0] = 0;
}

#gcc is 11.2.0
gcc -c a.c
a.c:4:7: error: subscripted value is neither array nor pointer nor vector
4 |  index[1] = 0;
  |   ^

I could not find a compiler option that would tell me what the root cause was. 
I wasn't getting a simple "undeclared" error, so I surmised the name must
already be in use, but I was confused as to how or where it was being used.  My
first thought was that maybe index was a global variable, so I tried using
-Wshadow.  Eventually, I found that it was a function from strings.h which was
included several layers down an include spiral.

I think an effective note from gcc such as "index was previously declared here
as a function", or something similar that often happens in other diagnostics,
would aid in finding the root cause of my bug.

Incidentally, in my actual scenario, the real bug was that I forgot to access
index as a member of a struct: x.index vs index.  But I'd wager that expecting
GCC to look for all nearby structs for a similarly named member is
unreasonable.  Simply telling me where index originates, though, would have
helped greatly.

[Bug other/102060] New: -Wprio-ctor-dtor underlines the wrong part of the source line

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 102060
   Summary: -Wprio-ctor-dtor underlines the wrong part of the
source line
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

We get a warning when building for windows that should be fixed, but it
highlights that the warning is slightly mistaken about where the problem is:

gcc-git/libgcc/config/i386/cygming-crtend.c:59:1: warning: constructor
priorities from 0 to 100 are reserved for the implementation [-Wprio-ctor-dtor]
   59 | static void register_frame_ctor (void) __attribute__ ((constructor
(0)));
  | ^~


The word "static" is underlined, but I presume that instead it should be
"constructor(0)".

[Bug analyzer/102052] New: analyser testsuite failures with LLP64 model

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 102052
   Summary: analyser testsuite failures with LLP64 model
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

Additional details here:
https://gcc.gnu.org/pipermail/gcc/2021-August/237158.html

pr98969.c:9:19: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
* This fails because the function arguments are "long int", and that tries to
hold a pointer.  It should be uintptr_t or similar.

Something like this should work:

diff --git a/gcc/testsuite/gcc.dg/analyzer/pr98969.c
b/gcc/testsuite/gcc.dg/analyzer/pr98969.c
index 7e1587d..770e6d2 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pr98969.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pr98969.c
@@ -4,14 +4,14 @@ struct foo
 };

 void
-test_1 (long int i)
+test_1 (__UINTPTR_TYPE__ i)
 {
   struct foo *f = (struct foo *)i;
   f->expr = __builtin_malloc (1024);
 } /* { dg-bogus "leak" } */

 void
-test_2 (long int i)
+test_2 (__UINTPTR_TYPR__ i)
 {
   __builtin_free (((struct foo *)i)->expr);
   __builtin_free (((struct foo *)i)->expr); /* { dg-warning "double-'free' of
'\\*\\(\\(struct foo \\*\\)i\\)\\.expr'" } */



pr99716-2.c:13:30: warning: implicit declaration of function 'random';did you
mean 'rand'? [-Wimplicit-function-declaration]
* The C function is rand(), so it's not clear to me at least why the code is
using random.  I have no idea what the test is testing, so I don't know if
rand() is a drop in replacement, but here you go:

index 7c9881c..adc9819 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pr99716-2.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pr99716-2.c
@@ -10,7 +10,7 @@ extern int foo (void);
 void
 test_mountpoint (const char *mp)
 {
-  const int nr_passes = 5 + (random () & 31);
+  const int nr_passes = 5 + (rand () & 31);
   int pass;
   int ret = 1;
   FILE *fp;



pr99774-1.c:12:14: warning: conflicting types for built-in function 'calloc';
expected 'void *(long long unsigned int,  long long unsigned int)'
[-Wbuiltin-declaration-mismatch]
zlib-5.c:10:15: warning: conflicting types for built-in function 'strlen';
expected 'long long unsigned int(const char *)'
[-Wbuiltin-declaration-mismatch]
zlib-5.c:16:14: warning: conflicting types for built-in function 'calloc';
expected 'void *(long long unsigned int,  long long unsigned int)'
[-Wbuiltin-declaration-mismatch]
* These are all examples of hardcoding a size_t typedef that is incorrect for
an LLP64 model.  Something like this would probably be enough to fix it:

diff --git a/gcc/testsuite/gcc.dg/analyzer/pr99774-1.c
b/gcc/testsuite/gcc.dg/analyzer/pr99774-1.c
index 620cf65..a2138d9 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pr99774-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pr99774-1.c
@@ -7,9 +7,8 @@ typedef unsigned char uint8_t;
 typedef unsigned short uint16_t;
 typedef unsigned long uint64_t;
 typedef unsigned long uint64_t;
-typedef long unsigned int size_t;

-extern void *calloc(size_t __nmemb, size_t __size)
+extern void *calloc(__SIZE_TYPE__ __nmemb, __SIZE_TYPE__ __size)
   __attribute__((__nothrow__, __leaf__))
   __attribute__((__malloc__))
   __attribute__((__alloc_size__(1, 2)))
diff --git a/gcc/testsuite/gcc.dg/analyzer/zlib-5.c
b/gcc/testsuite/gcc.dg/analyzer/zlib-5.c
index afb6102..93df2b1 100644
--- a/gcc/testsuite/gcc.dg/analyzer/zlib-5.c
+++ b/gcc/testsuite/gcc.dg/analyzer/zlib-5.c
@@ -2,18 +2,17 @@

 #include "analyzer-decls.h"

-typedef long unsigned int size_t;
 typedef unsigned char Byte;
 typedef unsigned int uInt;
 typedef unsigned long uLong;

-extern size_t strlen(const char *__s) __attribute__((__nothrow__, __leaf__))
+extern __SIZE_TYPE__ strlen(const char *__s) __attribute__((__nothrow__,
__leaf__))
 __attribute__((__pure__)) __attribute__((__nonnull__(1)));
 extern void exit(int __status) __attribute__((__nothrow__, __leaf__))
 __attribute__((__noreturn__));
 extern char *strcpy(char *__restrict __dest, const char *__restrict __src)
 __attribute__((__nothrow__, __leaf__)) __attribute__((__nonnull__(1, 2)));
-extern void *calloc(size_t __nmemb, size_t __size)
+extern void *calloc(__SIZE_TYPE__ __nmemb, __SIZE_TYPE__ __size)
 __attribute__((__nothrow__, __leaf__)) __attribute__((__malloc__));

 extern int compress(Byte *dest, uLong *destLen, const Byte *source,



strndup-1.c:9:13: warning: incompatible implicit declaration of built-in
function 'strndup' [-Wbuiltin-declaration-mismatch]
* This function doesn't exist on windows.  So, either we add it to libmingwex
if it isn't already there and then link that library in to
the test, or just mark it as unsupported.  I'd probably prefer the former, but
it's not up to me.  Let me know what I should do here.


gcc.dg

[Bug c/102010] New: ICE in stack-check-8.c in i386_pe_seh_unwind_emit

[nightstrike at gmail dot com via Gcc-bugs]

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

Bug ID: 102010
   Summary: ICE in stack-check-8.c in i386_pe_seh_unwind_emit
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

See related PR97795 and PR90458

The testsuite test stack-check-8.c fails thusly:

spawn -ignore SIGHUP /tmp/_/build/gc/gcc/xgcc -B/tmp/_/build/gc/gcc/
/tmp/_/src/gcc-git/gcc/testsuite/gcc.dg/stack-check-8.c
-fdiagnostics-plain-output -O2 -fstack-clash-protection -Wno-psabi -fno-
optimize-sibling-calls --param stack-clash-protection-probe-interval=12 --param
stack-clash-protection-guard-size=12 -lm -o ./stack-check-8.exe
during RTL pass: final
/tmp/_/src/gcc-git/gcc/testsuite/gcc.dg/stack-check-8.c: In function 'f3':
/tmp/_/src/gcc-git/gcc/testsuite/gcc.dg/stack-check-8.c:40:1: internal compiler
error: in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1274
0x7f25c7 i386_pe_seh_unwind_emit(_IO_FILE*, rtx_insn*)
/tmp/_/src/gcc-git/gcc/config/i386/winnt.c:1274
0xb3aa3b final_scan_insn_1
/tmp/_/src/gcc-git/gcc/final.c:2904
0xb3ae5b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/tmp/_/src/gcc-git/gcc/final.c:2940
0xb3af36 final_1
/tmp/_/src/gcc-git/gcc/final.c:1997
0xb3baf4 rest_of_handle_final
/tmp/_/src/gcc-git/gcc/final.c:4285
0xb3baf4 execute
/tmp/_/src/gcc-git/gcc/final.c:4363
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
compiler exited with status 1