https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115190
Christoph Reiter changed:
What|Removed |Added
CC||reiter.christoph at gmail dot
com
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
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
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();
++
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
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Christoph Reiter changed:
What|Removed |Added
CC||reiter.christoph at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670
Christoph Reiter changed:
What|Removed |Added
CC||tneumann at users dot
sourceforge.
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 `
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108202
Christoph Reiter changed:
What|Removed |Added
CC||reiter.christoph at gmail dot
com
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.
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.
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.
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 t
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
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&action=edit
0001-docs-nocona-has-CX16-enabled-by-default.patch
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105745
--- Comment #10 from Christoph Reiter ---
lgtm
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
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&action=edit
libgomp: don't use GOMP_USE_ALIGNED_WORK_SHARES on Windows
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&action=edit
libgomp: use _aligned_free in gomp_aligned_free() if needed
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.
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().
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\SY
: 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
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 theo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507
Christoph Reiter changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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.
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 stepp
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 () fro
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 76f9c7f44fffb0b032667
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486
--- Comment #72 from Christoph Reiter ---
Works nicely now. Thanks everyone!
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..
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
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/MI
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
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/
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341
Christoph Reiter changed:
What|Removed |Added
CC||reiter.christoph at gmail dot
com
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reiter.christoph at gmail dot com
Target Milestone: ---
Downstream report: https://github.com/msys2/MINGW-packages/issues/6585
#include
#include
#include
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88424
--- Comment #2 from Christoph Reiter ---
For context, we use gcc in gobject-introspection where we parse metadata from
the C comments and this breaks things when users on Windows have git set up to
auto convert line endings:
https://gitlab.gnome.
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: reiter.christoph at gmail dot com
Target Milestone: ---
gcc --version
gcc (Debian 8.2.0-11) 8.2.0
When preprocessing a file which uses Windows newlines without discarding
45 matches
Mail list logo
