[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #4 from Iouri Kharon 2011-05-01 13:29:35 UTC --- Created attachment 24157 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24157 CHAR16 and CHAR32 in avr with -mint8 This patch correct bug 46261 in gcc-4.5.x
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #4 from Iouri Kharon --- (In reply to Sam James from comment #3) > (In reply to Iouri Kharon from comment #2) > > In addition, a bug in ld-2.44 was found :). See > > https://savannah.gnu.org/patch/index.php?10520 > > Could you file that on the sourceware bugzilla? I don't think anyone looks > at savannah for binutils (didn't even know a page was there). https://sourceware.org/bugzilla/show_bug.cgi?id=32942
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 Iouri Kharon changed: What|Removed |Added Attachment #61272|0 |1 is obsolete|| --- Comment #2 from Iouri Kharon --- Created attachment 61313 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61313&action=edit A small patch for temporary(?) fix for this (and several similar) problems. Another situation leading to GPF in cc1/cc1plus was found. I'm attaching a common patch (it includes all previous cases, so the previous patch should be removed). In addition, a bug in ld-2.44 was found :). See https://savannah.gnu.org/patch/index.php?10520
[Bug c/119940] New: Incorrect calculate MD5 (for -gcodeview) under windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119940
Bug ID: 119940
Summary: Incorrect calculate MD5 (for -gcodeview) under windows
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bc-info at styx dot cabel.net
Target Milestone: ---
When build gcc under windows (mingw-w64, etc) incorrect calculation MD5 for
option -gcodeview.
Patch for fix this bug:
--- gcc-15.0/gcc/dwarf2codeview.cc.orig 2025-04-25 11:18:00 +0300
+++ gcc-15.0/gcc/dwarf2codeview.cc 2025-04-25 18:17:58 +0300
@@ -1746,7 +1746,7 @@
sf->string_offset = string_offset;
sf->filename = xstrdup (filename);
- f = fopen (filename, "r");
+ f = fopen (filename, "rb");
if (!f)
internal_error ("could not open %s for reading", filename);
[Bug debug/120051] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 Iouri Kharon changed: What|Removed |Added CC||bc-info at styx dot cabel.net --- Comment #1 from Iouri Kharon --- Created attachment 61272 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61272&action=edit A small patch for temporary(?) fix for this (and several similar) problems. Most likely some of the fixes should be done the different way (let the author of the code decide), but it removes the detected crashes (both on your test and on several more complex ones). info: remove GPF's in cc1 when build patch-2.8 and libiconv-1.18.
[Bug debug/120227] Incorrect debug info generation with options -gcodeview -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120227 --- Comment #1 from Iouri Kharon --- FYI: The problem is in the compiler (cc1/cc1plus)- with such a combination of keys, a "mixture" of codeview-style and dwarf-style info gets into the generated assembler
[Bug c/120227] New: Incorrect debug info generation with options -gcodeview -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120227
Bug ID: 120227
Summary: Incorrect debug info generation with options
-gcodeview -g
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bc-info at styx dot cabel.net
Target Milestone: ---
$ cat test.c
// gcc -c -gcodeview -g test.c
void f(void) {}
$ gcc -c -gcodeview -g test.c
cciogM22.s: Assembler messages:
cciogM22.s:174: Error: can't resolve .debug$T - .Ltext0
cciogM22.s:246: Error: can't resolve .debug$T - .Ltext0
But -g -gcodeview work correct :)
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 Iouri Kharon changed: What|Removed |Added Attachment #61313|0 |1 is obsolete|| --- Comment #7 from Iouri Kharon --- Created attachment 61364 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61364&action=edit A small patch for temporary(?) fix for this (and several similar) problems. This patch is also trivial :). Unfortunately, I haven't managed to find the cause of "memory corruption" in some large C++ projects yet - unlike your tests, it's not a "direct" error, but an induced one :(
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #12 from Iouri Kharon --- FYI: Yet cc1/cc1plus can be linked with --pdb :) - secondary patch for ld added to https://sourceware.org/bugzilla/show_bug.cgi?id=32942
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 Iouri Kharon changed: What|Removed |Added Attachment #61364|0 |1 is obsolete|| --- Comment #9 from Iouri Kharon --- Created attachment 61379 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61379&action=edit A complex patch fixed for this (and several similar) problems. 1. ATTENTION! Don't use 'cfun' as a pointer outside of its processing time - it is allocated via ggc (garbage collector) and can be moved/deleted. 2. When implementation of structure present without preliminary declaration, infinite recursion could occur (when determining the 'this' type for member-function and/or pointers to the processed type from nested types, etc). 3. Also fixed variable size array (thanks for test).
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #10 from Iouri Kharon --- (In reply to Sam James from comment #6) > Mark, when you get a chance to work on this, if you haven't tried it before, > I'd recommend doing a bootstrap w/ -gcodeview enabled by default to see what > falls out. With -O0 the compilers got it right (after last patch :). Only I had to add -Wl,--exclude-all-symbols to LDFLAGS - too many exports for PE :). And link without debugging (ld "hang" with code 5). With -Os, there are problems interacting with assembler generation - I'll see when I have time.
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #17 from Iouri Kharon --- (In reply to Christoph Reiter from comment #16) > (In reply to Christoph Reiter from comment #15) > > Thanks, that seems to have fixed the babl build. > > ah, I meant the gegl build. And did you apply the patch that I posted on the 10th? Because this example compiles for me.
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 Iouri Kharon changed: What|Removed |Added Attachment #61379|0 |1 is obsolete|| --- Comment #14 from Iouri Kharon --- Created attachment 61393 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61393&action=edit A complex patch fixed for this (and several similar) problems. Workaround for a bug that prevented some binutils and gcc components from being built with -gcodeview. Marked as TODO, since "optimized information" about local variables like CONST_STRING is now discarded, since to save it you either have to write your own helper (duplicating the one in final.cc) or make it public.
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #20 from Iouri Kharon --- (In reply to Christoph Reiter from comment #19) > After doing some more testing, the 32bit build now fails with these patches: > > [1/301] Compiling C++ object > operations/external/exr-save.dll.p/exr-save.cc.obj > FAILED: operations/external/exr-save.dll.p/exr-save.cc.obj > "ccache" "c++" "-Ioperations/external/exr-save.dll.p" > "-Ioperations/external" "-I../operations/external" "-I." "-I.." "-Igegl" > "-I../gegl" "-Igegl/buffer" "-I../gegl/buffer" "-Igegl/graph" > "-I../gegl/graph" "-Igegl/module" "-I../gegl/module" "-Igegl/opencl" > "-I../gegl/opencl" "-Igegl/operation" "-I../gegl/operation" "-Igegl/process" > "-I../gegl/process" "-Igegl/property-types" "-I../gegl/property-types" > "-IC:/msys64/mingw32/include/babl-0.1" > "-IC:/msys64/mingw32/include/glib-2.0" > "-IC:/msys64/mingw32/lib/glib-2.0/include" > "-IC:/msys64/mingw32/include/gio-win32-2.0" > "-IC:/msys64/mingw32/include/OpenEXR" "-IC:/msys64/mingw32/include/Imath" > "-fdiagnostics-color=always" "-D_GLIBCXX_ASSERTIONS=1" "-Wall" > "-Winvalid-pch" "-std=gnu++14" "-O2" "-g" "-DHAVE_CONFIG_H" > "-DGEGL_ENABLE_DEBUG" "-Winit-self" "-Wmissing-declarations" > "-Wpointer-arith" "-Wno-unused-parameter" "-Wno-cast-function-type" > "-D_FILE_OFFSET_BITS=64" "-gcodeview" "-ftree-vectorize" "-pthread" > "-DLIBDEFLATE_DLL" -MD -MQ > operations/external/exr-save.dll.p/exr-save.cc.obj -MF > "operations/external/exr-save.dll.p/exr-save.cc.obj.d" -o > operations/external/exr-save.dll.p/exr-save.cc.obj "-c" > ../operations/external/exr-save.cc > C:\msys64\tmp\ccR9hXob.s: Assembler messages: > C:\msys64\tmp\ccR9hXob.s:19098: Error: can't resolve .text - Lcvline612 > C:\msys64\tmp\ccR9hXob.s:19100: Error: can't resolve .text - Lcvline612 > C:\msys64\tmp\ccR9hXob.s:19102: Error: can't resolve .text - Lcvline612 > C:\msys64\tmp\ccR9hXob.s:19104: Error: can't resolve .text - Lcvline612 > C:\msys64\tmp\ccR9hXob.s:19106: Error: can't resolve .text - Lcvline612 > C:\msys64\tmp\ccR9hXob.s:19108: Error: can't resolve .text - Lcvline612 > C:\msys64\tmp\ccR9hXob.s:19110: Error: can't resolve .text - Lcvline612 > C:\msys64\tmp\ccR9hXob.s:19112: Error: can't resolve .text - Lcvline612 > C:\msys64\tmp\ccR9hXob.s:19114: Error: can't resolve .text - Lcvline612 > ... Try removing the -g switch from the command line (leaving -gcodeview) - the combination of the -gcodeview -g switches (and in that order!) leads to such errors. Well, only those who know what SHOULD happen with such a combination of switches can "fix" it :). And it seems to me that it is worth opening a separate ticket about this situation (it appears on any source) and is not directly related to codeview generation errors.
