[Bug c++/115190] -fmodule-mapper does not accept CRLF files

[reiter.christoph at gmail dot com via Gcc-bugs]

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

Christoph Reiter  changed:

   What|Removed |Added

 CC||reiter.christoph at gmail dot 
com

--- Comment #7 from Christoph Reiter  ---
If the problem is indeed in read_tuple_file(), then I see one potential cause
there:

The file is opened in text mode and it checks if the read count matches the
size of the actual data read. But in text mode where newline normalization
happens the read part can be smaller if there are CRLF in there that got
converted to LF:

https://github.com/gcc-mirror/gcc/blob/0b3b6a8df77b0ae15078402ea5fb933d6fccd585/c%2B%2Btools/resolver.cc#L129-L130

[Bug target/115038] [14/15 regression] internal error in seh_cfa_offset with -O2 -fno-omit-frame-pointer

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Christoph Reiter  ---
I can confirm that the patch from comment 4 fixes all the above cases, and also
emacs builds again.

Thanks again

[Bug target/115038] [14/15 regression] internal error in seh_cfa_offset with -O2 -fno-omit-frame-pointer

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Christoph Reiter  ---
Thanks! I can confirm that "-fno-fold-mem-offsets" works around the issue. I'll
test the proposed patch tomorrow.

In the meantime we've reduced another instance of this when building emacs, but
this time with "simpler" C code and without -fno-omit-frame-pointer:

```
// gcc -c -O2 repro.c -> internal compiler error: in seh_cfa_offset
// gcc -c -g3 -O2 -gdwarf-2 repro.c -> internal compiler error: in
dwarf2out_frame_debug_expr
void a() {
__builtin_unwind_init();
}
```

Adding this here for completeness.

[Bug target/115038] ICE in seh_cfa_offset since 14.1.0

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Christoph Reiter  ---
Another downstream report with the same error:
https://github.com/msys2/MINGW-packages/issues/20864

I've c-reduced that as well to:

```
// gcc -c -fno-omit-frame-pointer -O2 repro.cpp
struct d {
  d();
};
struct e {
  e() : c(1.0) {}
  float c;
};
struct j {
  using ad = d;
};
class k : j {
  d g;
  e h;
};
template  using i = k;
class {
  i f;
} a;
k b;
```

[Bug c++/115038] New: ICE in seh_cfa_offset since 14.1.0

[reiter.christoph at gmail dot com via Gcc-bugs]

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

Bug ID: 115038
   Summary: ICE in seh_cfa_offset since 14.1.0
   Product: gcc
   Version: 14.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reiter.christoph at gmail dot com
  Target Milestone: ---

Downstream issue: https://github.com/msys2/MINGW-packages/issues/20861

The following code using GCC 14.1.0 on Windows targeting x86_64-w64-mingw32:

```
// gcc -c -fno-omit-frame-pointer -O2 repro.cpp
template  void b(a, a);
template  void c(a, a, float);
float d;
void e() {
  float f;
  c(f, f, d);
  b(0.0f, f);
}
```

results in

```
repro.cpp: In function 'void e()':
repro.cpp:8:1: internal compiler error: in seh_cfa_offset, at
config/i386/winnt.cc:1137
8 | }
  | ^
```

* Replacing "-O2" with "-O1" fixes the issue
* Removing "-fno-omit-frame-pointer" fixes the issue
* Downgrading to GCC 13.2.0 fixes the issue

If there is any other information I can provide, let me know.

[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #15 from Christoph Reiter  ---
(In reply to Thomas Neumann from comment #12)
> Created attachment 55037 [details]
> radix sort fix
> 
> I could reproduce the problem, the radix sort did not behave correctly when
> we ran out of bits, which can happen on 32bit platforms. The attached patch
> fixes the problem.

I can confirm that this fixes the issue for me.

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[reiter.christoph at gmail dot com via Gcc-bugs]

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

Christoph Reiter  changed:

   What|Removed |Added

 CC||reiter.christoph at gmail dot 
com

--- Comment #10 from Christoph Reiter  ---
I've compared [0] the stack size of the two builds now, and it looks like me
setting BOOT_LDFLAGS [1] somehow made the build skip the stack size adjustment
here:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=config/mh-mingw;h=e91367a711284148e16849d3066fb94599204a6c;hb=HEAD#l15
leading to the low Windows stack size defaults

So this might not be a bug, but having built gcc wrong.

[0] objdump.exe -x /ucrt64/lib/gcc/x86_64-w64-mingw32/13.1.0/cc1plus.exe | grep
SizeOfStackReserve
[1]
https://github.com/msys2/MINGW-packages/commit/518e217a129eeeb92e5090f1bb14deaf0ed70edf#diff-cf683a120abf18dd9f774ea5df77137d01e19f359f7cb40c1fc152355cde7b80R265

[Bug libgcc/109670] Exception handling broken for 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com via Gcc-bugs]

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

Christoph Reiter  changed:

   What|Removed |Added

 CC||tneumann at users dot 
sourceforge.
   ||net

--- Comment #7 from Christoph Reiter  ---
Yes, I can confirm that reverting
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1c118c9970600117700cc12284587e0238de6bbe
on top of 13.1.0 fixes exception handling, and cmake/ada/gdb work again.

[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Christoph Reiter  ---
Taking `libgcc_s_dw2-1.dll` from gcc 12.2 fixes the issue. We also found that
gdb and cmake are broken due to broken exception handling (in case of cmake it
is flaky). In both those cases taking the old `libgcc_s_dw2-1.dll` also helps.

So this is not ada specific, but exception handling being broken for 32bit
Windows.

[Bug ada/108202] [13 Regression] Many new acats fails on 32bit Darwin hosts.

[reiter.christoph at gmail dot com via Gcc-bugs]

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

Christoph Reiter  changed:

   What|Removed |Added

 CC||reiter.christoph at gmail dot 
com

--- Comment #4 from Christoph Reiter  ---
There is a similar issue on Windows, bug 109670

[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Christoph Reiter  ---
Everything seems to be dynamically linked to libgcc, I'm out of ideas.

[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Christoph Reiter  ---
This looks very much like bug 108202 though, so I'll see if I can find
something.

[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Christoph Reiter  ---
(In reply to Christoph Reiter from comment #1)
> [...] I'll try building without that.

That didn't make a difference sadly.

[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Christoph Reiter  ---
Could this be another case of exceptions being broken, as indicated here
https://github.com/AdaCore/gnat-llvm/issues/25#issuecomment-1057198363 ?
I see some "-static-libgcc" in the ada Makefile.in. I'll try building without
that.

[Bug ada/109670] New: SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com via Gcc-bugs]

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

Bug ID: 109670
   Summary: SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES
compilation error on 32bit Windows starting with GCC
13
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reiter.christoph at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Updating from 12.2.0 to 13.1.0 we are encountering build errors for all ada
packages on 32bit Windows, all failing with something like:

raised SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES : s-pehage.adb:693
gnatmake: "broken.adb" compilation error

I've reduced one ada example that fails down to:

```
with GNAT.Spitbol.Patterns;
procedure Broken is
   M : GNAT.Spitbol.Patterns.Match_Result;
   type Header_Symbol is (None, Name, Attr, Conv, Prag);
begin
   null;
end Broken;
```

With GCC 12.2.0:

```
$ gnatmake.exe broken.adb
gcc -c broken.adb
gnatbind -x broken.ali
gnatlink broken.ali

```

With GCC 13.1.0:

```
$ gnatmake.exe broken.adb
gcc -c broken.adb

raised SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES : s-pehage.adb:693
gnatmake: "broken.adb" compilation error
```

If there is any more info that I can provide or things I can try out please let
me know.

[Bug web/107337] -march docs for nocona are missing CX16

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Christoph Reiter  ---
Created attachment 53737
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53737=edit
0001-docs-nocona-has-CX16-enabled-by-default.patch

[Bug web/107337] New: -march docs for nocona are missing CX16

[reiter.christoph at gmail dot com via Gcc-bugs]

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

Bug ID: 107337
   Summary: -march docs for nocona are missing CX16
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reiter.christoph at gmail dot com
  Target Milestone: ---

On https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html nocona doesn't list CX16
despite it being enabled there.

https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/gcc/common/config/i386/i386-common.c#L1742

thanks

[Bug libgomp/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Christoph Reiter  ---
lgtm

[Bug target/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Christoph Reiter  ---
(In reply to Jakub Jelinek from comment #5)
> Ugh, that is a lame limitation.
> Does mingw support any of the other aligned allocators (memalign,
> posix_memalign or aligned_alloc) that can be freed just with free?

I don't think so. There is one internal one in
https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64-crt/misc/mingw-aligned-malloc.c
but that has the same limitation afaics.

> If not, I guess easiest fix would be to move the HAVE__ALIGNED_MALLOC
> support as last option before fallback instead of first, make sure
> GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC is not defined for HAVE__ALIGNED_MALLOC if
> no other aligned allocator works and use _aligned_free in gomp_aligned_free
> if
> HAVE__ALIGNED_MALLOC and not GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC.

I went with fixing gomp_aligned_free() and disabling
GOMP_USE_ALIGNED_WORK_SHARES on Windows instead (hoping that in other cases
gomp_aligned_free() is called properly.. (??)). With the goal in mind that this
could be fixed if the alloc/free calls are paired properly in the future.

Feedback welcome, or feel free to take over :)

[Bug target/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Christoph Reiter  ---
Created attachment 53043
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53043=edit
libgomp: don't use GOMP_USE_ALIGNED_WORK_SHARES on Windows

[Bug target/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Christoph Reiter  ---
Created attachment 53042
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53042=edit
libgomp: use _aligned_free in gomp_aligned_free() if  needed

[Bug target/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Christoph Reiter  ---
Yes, that's it I think. libgomp is mixing aligned malloc with unaligned free in
various places.

[Bug target/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Christoph Reiter  ---
Wild guess: I see _aligned_malloc() being used in libgomp, but not
_aligned_free().

[Bug target/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Christoph Reiter  ---
For "#pragma omp parallel for if (0)":

#0  0x7ffacdeac6b3 in ntdll!RtlIsZeroMemory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x7ffacdeb5512 in ntdll!.misaligned_access ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x7ffacdeb57fa in ntdll!.misaligned_access ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#3  0x7ffacdebfce5 in ntdll!.misaligned_access ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x7ffacddc8715 in ntdll!RtlGetCurrentServiceSessionId ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x7ffacddc79e1 in ntdll!RtlFreeHeap ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x7ffacb4e218b in ucrtbase!_free_base ()
   from C:\WINDOWS\System32\ucrtbase.dll
#7  0x7ffa7fd3eab6 in free_team (team=team@entry=0x25d609d0fc0)
at ../../../gcc-12.1.0/libgomp/team.c:237
#8  0x7ffa7fd3ff8a in gomp_team_end ()
at ../../../gcc-12.1.0/libgomp/team.c:1005
#9  0x7ffa7fd3899e in GOMP_parallel_end ()
at ../../../gcc-12.1.0/libgomp/parallel.c:167
#10 0x7ffa7fd38a73 in GOMP_parallel (
fn=fn@entry=0x7ff707941530 , data=data@entry=0x0,
num_threads=num_threads@entry=1, flags=flags@entry=0)
at ../../../gcc-12.1.0/libgomp/parallel.c:179
#11 0x7ff707941584 in main () at myTest.cpp:2

For "#pragma omp for schedule(dynamic)"

#0  0x7ffacdeac6b3 in ntdll!RtlIsZeroMemory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x7ffacdeb5512 in ntdll!.misaligned_access ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x7ffacdeb57fa in ntdll!.misaligned_access ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#3  0x7ffacdebfce5 in ntdll!.misaligned_access ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x7ffacddc8715 in ntdll!RtlGetCurrentServiceSessionId ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x7ffacddc79e1 in ntdll!RtlFreeHeap ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x7ffacb4e218b in ucrtbase!_free_base ()
   from C:\WINDOWS\System32\ucrtbase.dll
#7  0x7ffa7eae050e in free_work_share (team=team@entry=0x0,
ws=0x2b6040a8480) at ../../../gcc-12.1.0/libgomp/work.c:159
#8  0x7ffa7eae0682 in gomp_work_share_end ()
at ../../../gcc-12.1.0/libgomp/work.c:238
#9  0x7ffa7ead68b4 in GOMP_loop_end ()
at ../../../gcc-12.1.0/libgomp/loop.c:958
#10 0x7ff6b18f1593 in main () at myTest.cpp:3

[Bug libgomp/105745] New: Conditional OpenMP directive fails with GCC 12

[reiter.christoph at gmail dot com via Gcc-bugs]

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

Bug ID: 105745
   Summary: Conditional OpenMP directive fails with GCC 12
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reiter.christoph at gmail dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Downstream issue: https://github.com/msys2/MINGW-packages/issues/11729

The following example crashes with GCC 12.1.0, but works fine with GCC 11.3.0:

// g++ -fopenmp -o broken.exe broken.c; ./broken.exe; echo $?
int main() {
#pragma omp parallel for if (0)
for (int idx = 0; idx < 0; ++idx) { }
return 0;
}

* Removing the "if (0)" condition makes it work again
* Replacing libgomp-1.dll with the one from GCC 11.3 also makes things work
again.
* Another example that crashes is "#pragma omp for schedule(dynamic)"

This is on 32/64 bit Windows.

[Bug ada/100486] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #73 from Christoph Reiter  ---
In a similar bug 105507 we figured out that the MSYS2 build was broken because
it was linking libgcc both statically and dynamically via dependencies, and
that breaks exceptions with dwarf-2.

So in theory the above patch could be reverted. I can try building with it
being reverted to confirm, if wanted.

[Bug ada/105507] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

Christoph Reiter  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #11 from Christoph Reiter  ---
I went with --with-boot-ldflags="-static-libstdc++" and
--with-stage1-ldflags="-static-libstdc++" now, and everything works nicely.

Thanks for your help and insight.

I'll document the dwarf-2 limitation downstream, so this hopefully wont happen
again.

[Bug ada/105507] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Christoph Reiter  ---
(In reply to Eric Botcazou from comment #8)
> > We currently link:
> > 
> > shared: gmp, winpthread, zlib, zstd
> > static: mpc, mpfr, isl
> > 
> > Not for any particular gcc related reason I think, some dependent packages
> > have static/shared builds, some don't.
> 
> Why didn't I think of that for PR ada/100486?

Sorry, I didn't know this was a problem :) I'm not quite sure how I ended up
maintaining this downstream... but here we are.

> So the fix should have been
> to add -shared-libgcc to GCC_LINKERFLAGS in
> gcc/ada/gcc-interface/Make-lang.in:
> 
> # Strip -Werror during linking for the LTO bootstrap
> GCC_LINKERFLAGS = $(filter-out -Werror, $(ALL_LINKERFLAGS)) -shared-libgcc
> 
> in your setup since you link gnat1 with shared libraries. This should
> override the -static-libgcc in ALL_LINKERFLAGS inherited from toplevel.
> 
> So you need to to it 1) for GCC 11: rebuild it and reinstall it 2) for GCC
> 12: build it with the patched GCC 11.  Note that this means that GCC 11 is
> currently not fully functional anyway.

Thanks for the detailed instructions. I'll give that a try.

I'm wondering if there are any downsides to just removing "-static-libgcc" from
both "--with-stage1-ldflags" and "--with-boot-ldflags". Or is only ada using
exceptions in GCC?

Or should we try linking everything statically to avoid this alltogether?

[Bug ada/105507] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Christoph Reiter  ---
We currently link:

shared: gmp, winpthread, zlib, zstd
static: mpc, mpfr, isl

Not for any particular gcc related reason I think, some dependent packages have
static/shared builds, some don't.

[Bug ada/105507] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Christoph Reiter  ---
I see, thanks for having a look :)

We do have some open bugs re broken exception handling with mingw32, like
https://github.com/msys2/MINGW-packages/issues/9289#issuecomment-945306860

Sadly no one stepped up to look into that. Do you think this could be related?

[Bug ada/105507] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Christoph Reiter  ---
Stack trace (I rebuilt the host gcc 11.3.0 with debug symbols and re-ran the
failing command with "-wrapper gdb,--args"):

Thread 1 received signal SIGSEGV, Segmentation fault.
0x7563bd90 in strlen () from C:\WINDOWS\SysWOW64\msvcrt.dll
(gdb) bt
#0  0x7563bd90 in strlen () from C:\WINDOWS\SysWOW64\msvcrt.dll
#1  0x01731831 in libiberty_vprintf_buffer_size (
format=format@entry=0x1a3f865  "%s:%d",
args=, args@entry=0x1367df64 "")
at ../../gcc-11.3.0/libiberty/vprintf-support.c:105
#2  0x0173160a in xvasprintf (
format=format@entry=0x1a3f865  "%s:%d",
args=args@entry=0x1367df64 "")
at ../../gcc-11.3.0/libiberty/xvasprintf.c:57
#3  0x017312f7 in xasprintf (
fmt=0x1a3f865  "%s:%d")
at ../../gcc-11.3.0/libiberty/xasprintf.c:47
#4  0x0041f315 in internal_error_function (
context=0x29d40c0 ,
msgid=0x1b2aebd  "%s", ap=0x1367e0a0)
at ../../gcc-11.3.0/gcc/ada/gcc-interface/misc.c:343
#5  0x016ab28d in diagnostic_report_diagnostic (
context=0x29d40c0 ,
diagnostic=, diagnostic@entry=0x1367e048)
at ../../gcc-11.3.0/gcc/diagnostic.c:1225
#6  0x016ab7b7 in diagnostic_impl (richloc=0x1367e0a4, metadata=0x0, opt=-1,
gmsgid=0x1b2aebd  "%s", ap=0x1367e0a0,
kind=DK_ICE) at ../../gcc-11.3.0/gcc/diagnostic.c:1406
#7  0x016abd98 in internal_error (
gmsgid=gmsgid@entry=0x1b2aebd  "%s")
at ../../gcc-11.3.0/gcc/diagnostic.c:1808
#8  0x00c53db1 in crash_signal (signo=22) at ../../gcc-11.3.0/gcc/toplev.c:327
#9  0x75608081 in raise () from C:\WINDOWS\SysWOW64\msvcrt.dll
#10 0x0016 in ?? ()
#11 0x4925a812 in ?? ()
#12 0x1367e7b0 in ?? ()
#13 0x7560c5ab in msvcrt!abort () from C:\WINDOWS\SysWOW64\msvcrt.dll
#14 0x0192e3d3 in uw_init_context_1 (context=0x0, context@entry=0x1367e730,
outer_cfa=outer_cfa@entry=0x1367e7d0, outer_ra=0x16)
at ../../../gcc-11.3.0/libgcc/unwind-dw2.c:1593
#15 0x0192e77f in _Unwind_RaiseException (exc=0x1619f880)
at ../../../gcc-11.3.0/libgcc/unwind.inc:93
#16 0x00473f47 in ada.exceptions.exception_propagation.propagate_gcc_exception
(gcc_exception=0x1619f880)
at ../../gcc-11.3.0/gcc/ada/libgnat/a-exexpr.adb:597
#17 0x00473f96 in ada.exceptions.exception_propagation.propagate_exception (
excep=...) at ../../gcc-11.3.0/gcc/ada/libgnat/a-exexpr.adb:628
#18 0x00474414 in ada.exceptions.complete_and_propagate_occurrence (
x=x@entry=0x1619f8b0) at ../../gcc-11.3.0/gcc/ada/libgnat/a-except.adb:924
#19 0x00474447 in <__gnat_raise_exception> (
e=e@entry=0x1a31698 ,
message=...) at ../../gcc-11.3.0/gcc/ada/libgnat/a-except.adb:960
#20 0x0068e352 in sem_ch13.build_discrete_static_predicate.stat_pred (
typ=32975) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:9368
#21 0x0068fa75 in sem_ch13.build_discrete_static_predicate.get_rlist (
exp=) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:9129
#22 0x0068f922 in sem_ch13.build_discrete_static_predicate.get_rlist (
exp=203158) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:9015
#23 0x00693b59 in sem_ch13.build_discrete_static_predicate (typ=33050,
expr=203158, nam=-399989278) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:9409
#24 0x00696f66 in sem_ch13.build_predicate_functions (typ=typ@entry=33050,
n=n@entry=203112) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:10370
#25 0x006a59b2 in sem_ch13.freeze_entity_checks (n=203112)
at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:12728
#26 0x006a5ab5 in sem_ch13.analyze_freeze_entity (n=n@entry=203112)
at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:8155
#27 0x0064416a in sem.analyze (n=n@entry=203112)
at ../../gcc-11.3.0/gcc/ada/sem.adb:264
#28 0x00644d68 in sem.insert_list_after_and_analyze (n=203068, l=-99976824)
at ../../gcc-11.3.0/gcc/ada/sem.adb:1254
#29 0x005b490f in freeze.freeze_all.freeze_all_ent.process_flist ()
at ../../gcc-11.3.0/gcc/ada/freeze.adb:1852
#30 0x005bf0f5 in freeze.freeze_all.freeze_all_ent (after=36978, from=32525)
at ../../gcc-11.3.0/gcc/ada/freeze.adb:1940
#31 freeze.freeze_all (from=32525, after=36978)
at ../../gcc-11.3.0/gcc/ada/freeze.adb:2020
#32 0x006ad855 in sem_ch3.analyze_declarations (l=,
l@entry=-6744) at ../../gcc-11.3.0/gcc/ada/sem_ch3.adb:2837
#33 0x006fa1d7 in sem_ch7.analyze_package_specification (n=n@entry=32524)
at ../../gcc-11.3.0/gcc/ada/sem_ch7.adb:1738
#34 0x006442f7 in sem.analyze (n=32524)
at ../../gcc-11.3.0/gcc/ada/sem.adb:459
#35 0x006f978c in sem_ch7.analyze_package_declaration (n=n@entry=37004)
at ../../gcc-11.3.0/gcc/ada/sem_ch7.adb:1210
#36 0x00643e5e in sem.analyze (n=n@entry=37004)
at ../../gcc-11.3.0/gcc/ada/sem.adb:450
#37 0x0066c17a in sem_ch10.analyze_compilation_unit (n=32501)
at ../../gcc-11.3.0/gcc/ada/sem_ch10.adb:913
#38 0x00644102 in sem.analyze (n=n@entry=32501)
at ../../gcc-11.3.0/gcc/ada/sem.adb:180
#39 0x006454b1 in sem.semantics.do_analyze ()
at ../../gcc-11.3.0/gcc/ada/sem.adb:1421
#40 sem.semantics (comp_unit=32501) 

[Bug ada/105507] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Christoph Reiter  ---
I've bisected it now:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=76f9c7f44fffb0b03266730b137313fe79f1c99e

76f9c7f44fffb0b03266730b137313fe79f1c99e is the first bad commit
commit 76f9c7f44fffb0b03266730b137313fe79f1c99e
Author: Bob Duff 
Date:   Wed Feb 3 05:31:16 2021 -0500

[Ada] Variable-sized node types

 167 files changed, 18305 insertions(+), 43812 deletions(-)

[Bug ada/105507] New: Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

Bug ID: 105507
   Summary: Ada build fails for 32bit Windows
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reiter.christoph at gmail dot com
  Target Milestone: ---

Downstream context: https://github.com/msys2/MINGW-packages/pull/11582

Building gcc 12.1.0 fails for 32bit Windows (64bit works):

$ make
[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32'
make[2]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32'
rm -f stage_current
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32'
make[2]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32'
make[2]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libiberty'
make[4]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libiberty/testsuite'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libiberty/testsuite'
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libiberty'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/lto-plugin'
make  all-am
make[4]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/lto-plugin'
make[4]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/lto-plugin'
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/lto-plugin'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/intl'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/intl'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libiberty'
make[4]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libiberty/testsuite'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libiberty/testsuite'
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libiberty'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/fixincludes'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/fixincludes'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libcpp'
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libcpp'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libbacktrace'
make  all-am
make[4]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libbacktrace'
true  DO=all multi-do # make
make[4]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libbacktrace'
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libbacktrace'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libcpp'
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libcpp'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libcody'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libcody'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libdecnumber'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libdecnumber'
make[3]: Entering directory
'/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/gcc'
mkdir -p ada/
gcc -c -g  -gnatpg -gnatwns  -W -Wall -I- -I. -Iada/generated -Iada
-I../../gcc-12.1.0/gcc/ada ../../gcc-12.1.0/gcc/ada/spark_xrefs.adb -o
ada/spark_xrefs.o
gcc.exe: internal compiler error: Aborted signal terminated program gnat1
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [../../gcc-12.1.0/gcc/ada/gcc-interface/Make-lang.in:167:
ada/spark_xrefs.o] Error 4
make[3]: Leaving directory

[Bug ada/100486] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #72 from Christoph Reiter  ---
Works nicely now. Thanks everyone!

[Bug ada/100486] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #52 from Christoph Reiter  ---
Turns out this might be fallout from the last grep update, see
https://github.com/msys2/MINGW-packages/issues/9771#issuecomment-945007372
Needs investigating..

[Bug ada/100486] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #51 from Christoph Reiter  ---
(In reply to Eric Botcazou from comment #50)
> > Yes, from 2.36.1 to 2.37, but I've already tried reverting that and it
> > didn't help. I'm going to try older versions (of everything) though..
> 
> This could as well be a miscompilation of the linker.  Can you upload ld.exe
> somewhere so that I replace mine with it?

If you happen to have an tool that supports extracting .tar.zst you could take
the .exe from package directly:
https://repo.msys2.org/mingw/mingw32/mingw-w64-i686-binutils-2.37-4-any.pkg.tar.zst

[Bug ada/100486] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #48 from Christoph Reiter  ---
(In reply to Eric Botcazou from comment #47)
> > Yes, everything is checksummed in our build script. We apply various patches
> > and backports, they are also checksummed:
> > https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD
> 
> Did you change binutils, in particular the linker, in between?

Yes, from 2.36.1 to 2.37, but I've already tried reverting that and it didn't
help. I'm going to try older versions (of everything) though..

[Bug ada/100486] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #46 from Christoph Reiter  ---
(In reply to Eric Botcazou from comment #45)
> > Fore completeness: The "exceptions not working" problem now also crept into
> > our v10.3 build with the last rebuild. Maybe some dependency change in the
> > last two months, but no idea :/
> > 
> > https://github.com/msys2/MINGW-packages/issues/9771
> 
> Can you confirm that this is with the same compiler sources as the previous
> 10.3 version that works?  Do you apply local changes to them?

Yes, everything is checksummed in our build script. We apply various patches
and backports, they are also checksummed:
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD

[Bug ada/100486] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #44 from Christoph Reiter  ---
Fore completeness: The "exceptions not working" problem now also crept into our
v10.3 build with the last rebuild. Maybe some dependency change in the last two
months, but no idea :/

https://github.com/msys2/MINGW-packages/issues/9771

So this isn't something new in v11

[Bug ada/100486] Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

--- Comment #15 from Christoph Reiter  ---
Still the same error with GCC 11.2 and binutils 2.37:
https://github.com/msys2/MINGW-packages/pull/9088/checks?check_run_id=3196226530

[Bug ada/100486] New: Ada build fails for 32bit Windows

[reiter.christoph at gmail dot com via Gcc-bugs]

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

Bug ID: 100486
   Summary: Ada build fails for 32bit Windows
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reiter.christoph at gmail dot com
  Target Milestone: ---

10.3 works fine. Trying to build 11.1 results in the following error.

I can try to debug this or try patches if someone can give me some hints on
where to best start.

Downstream issue: https://github.com/msys2/MINGW-packages/pull/8320

2021-05-08T11:34:54.1653856Z mkdir -p ada/libgnat/
2021-05-08T11:34:54.2691662Z mkdir -p ada/libgnat/
2021-05-08T11:34:54.2889496Z
/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc
-B/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/
-B/mingw32/i686-w64-mingw32/bin/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib
-isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include
-B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem
/mingw32/i686-w64-mingw32/include -isystem
/mingw32/i686-w64-mingw32/sys-include   -fno-checking -c -g -O2
-D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -fno-checking -gtoggle  -gnatpg 
-W -Wall -nostdinc -I- -I. -Iada/generated -Iada -Iada/gcc-interface
-I../../gcc-11.1.0/gcc/ada -I../../gcc-11.1.0/gcc/ada/gcc-interface
-Iada/libgnat -I../../gcc-11.1.0/gcc/ada/libgnat
../../gcc-11.1.0/gcc/ada/libgnat/a-charac.ads -o ada/libgnat/a-charac.o
2021-05-08T11:34:54.3231740Z
/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc
-B/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/
-B/mingw32/i686-w64-mingw32/bin/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib
-isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include
-B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem
/mingw32/i686-w64-mingw32/include -isystem
/mingw32/i686-w64-mingw32/sys-include   -fno-checking -c -g -O2
-D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -fno-checking -gtoggle  -gnatpg 
-W -Wall -nostdinc -I- -I. -Iada/generated -Iada -Iada/gcc-interface
-I../../gcc-11.1.0/gcc/ada -I../../gcc-11.1.0/gcc/ada/gcc-interface
-Iada/libgnat -I../../gcc-11.1.0/gcc/ada/libgnat
../../gcc-11.1.0/gcc/ada/libgnat/a-chlat1.ads -o ada/libgnat/a-chlat1.o
2021-05-08T11:34:54.3849423Z gnat1.exe: warning: command-line option
'-Wno-pedantic-ms-format' is valid for C/C++/ObjC/ObjC++ but not for Ada
2021-05-08T11:34:54.4421984Z gnat1.exe: warning: command-line option
'-Wno-pedantic-ms-format' is valid for C/C++/ObjC/ObjC++ but not for Ada
2021-05-08T11:34:54.8744980Z mkdir -p ada/libgnat/
2021-05-08T11:34:54.8985212Z
/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc
-B/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/
-B/mingw32/i686-w64-mingw32/bin/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib
-isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include
-B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem
/mingw32/i686-w64-mingw32/include -isystem
/mingw32/i686-w64-mingw32/sys-include   -fno-checking -c -g -O2
-D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -fno-checking -gtoggle  -gnatpg 
-W -Wall -g -O1 -fno-inline \
2021-05-08T11:34:54.9009139Z  -nostdinc -I- -I. -Iada/generated -Iada
-Iada/gcc-interface -I../../gcc-11.1.0/gcc/ada
-I../../gcc-11.1.0/gcc/ada/gcc-interface -Iada/libgnat
-I../../gcc-11.1.0/gcc/ada/libgnat
../../gcc-11.1.0/gcc/ada/libgnat/a-except.adb -o ada/libgnat/a-except.o
2021-05-08T11:34:54.9369418Z
/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc
-B/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/
-B/mingw32/i686-w64-mingw32/bin/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib
-isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include
-B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem
/mingw32/i686-w64-mingw32/include -isystem
/mingw32/i686-w64-mingw32/sys-include   -fno-checking -c -g -O2
-D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -fno-checking -gtoggle  -gnatpg 
-W -Wall -nostdinc -I- -I. -Iada/generated -Iada -Iada/gcc-interface
-I../../gcc-11.1.0/gcc/ada -I../../gcc-11.1.0/gcc/ada/gcc-interface
-Iada/libgnat -I../../gcc-11.1.0/gcc/ada/libgnat
../../gcc-11.1.0/gcc/ada/libgnat/a-elchha.adb -o ada/libgnat/a-elchha.o
2021-05-08T11:34:55.0157169Z gnat1.exe: warning: command-line option
'-Wno-pedantic-ms-format' is valid for C/C++/ObjC/ObjC++ but not for Ada
2021-05-08T11:34:55.1250712Z gnat1.exe: warning: command-line option
'-Wno-pedantic-ms-format' is valid for C/C++/ObjC/ObjC++ but not for Ada
2021-05-08T11:34:55.2141773Z make[3]: ***
[../../gcc-11.1.0/gcc/ada/gcc-interface/Make-lang.in:1052:
ada/libgnat/a-except.o] Error 1
2021-05-08T11:34:55.2147024Z make[3]: *** Waiting for unfinished jobs
2021-05-08T11:34:55.4620283Z rm gcc.pod gfortran.pod
2021-05-08T11:34:55.4623053Z 

[Bug target/98341] [11/12 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k

[reiter.christoph at gmail dot com via Gcc-bugs]

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

Christoph Reiter  changed:

   What|Removed |Added

 CC||reiter.christoph at gmail dot 
com

--- Comment #12 from Christoph Reiter  ---
Note sure if this is related, but the 32bit Windows build of 11.1.0 fails in a
similar way:

gnat1.exe: warning: command-line option '-Wno-pedantic-ms-format' is valid for
C/C++/ObjC/ObjC++ but not for Ada
make[3]: *** [../../gcc-11.1.0/gcc/ada/gcc-interface/Make-lang.in:1052:
ada/libgnat/a-except.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm gcc.pod gfortran.pod
make[3]: Leaving directory '/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/gcc'
make[2]: *** [Makefile:4833: all-stage2-gcc] Error 2
make[2]: Leaving directory '/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32'
make[1]: *** [Makefile:26006: stage2-bubble] Error 2
make[1]: Leaving directory '/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32'
make: *** [Makefile:1013: all] Error 2