[Bug libstdc++/53477] pretty printer fails with: Python Exception list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 asmwarrior changed: What|Removed |Added CC||asmwarrior at gmail dot com --- Comment #3 from asmwarrior --- I have the same error when try to print a stl container, see the log: (this happens when I debug Code::Blocks), I'm using GCC 4.6.3 and GDB CVS HEAD. [debug]> p m_Headers [debug]Python Exception list index out of range: [debug]$2 = std::set with 1 elements [debug]>>>>>>cb_gdb:
[Bug libstdc++/53477] pretty printer fails with: Python Exception list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 --- Comment #4 from asmwarrior --- This is what I get when I enable the python stack print: > set python print-stack full [debug]> set python print-stack full [debug]>>cb_gdb: > p m_Headers [debug]> p m_Headers [debug]Traceback (most recent call last): [debug] File "E:\code\gcc\PCXMinGW463\bin\libstdcxx\v6\printers.py", line 477, in children [debug]rep_type = find_type(self.val.type, '_Rep_type') [debug] File "E:\code\gcc\PCXMinGW463\bin\libstdcxx\v6\printers.py", line 52, in find_type [debug]field = typ.fields()[0] [debug]IndexError: list index out of range [debug]$3 = std::set with 1 elements [debug]>>cb_gdb: Thanks.
[Bug libstdc++/53477] pretty printer fails with: Python Exception list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477
--- Comment #5 from asmwarrior ---
> p /r m_Headers
[debug]> p /r m_Headers
[debug]$5 = (StringSet &) @0x116d0bc4: {_M_t = {_M_impl =
{ >> =
{<__gnu_cxx::new_allocator >> = {}, }, _M_key_compare = {> = {}, }, _M_header = {_M_color
= std::_S_red, _M_parent = 0x116d2d28, _M_left = 0x116d2d28, _M_right =
0x116d2d28}, _M_node_count = 1}}}
[debug]>>cb_gdb:
When I see the E:\code\gcc\PCXMinGW463\bin\libstdcxx\v6\printers.py, I see in
the line: 476
def children (self):
rep_type = find_type(self.val.type, '_Rep_type')
node = find_type(rep_type, '_Link_type')
node = node.strip_typedefs()
return self._iter (RbtreeIterator (self.val), node)
The variable is declared as: StringSet& m_Headers;
and the StringSet is defined as: typedef std::set StringSet;
Hope those information can help to solve this bug.
[Bug libstdc++/53477] pretty printer fails with: Python Exception list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477
--- Comment #6 from asmwarrior ---
Hi, all, I create a simple c++ program to reproduce this bug:
#include
#include
typedef std::set IntSet;
typedef std::map IntToSetMap;
int main()
{
IntToSetMap m;
IntSet s;
s.insert(5);
m[3] = s;
IntSet& refSet = m[3];
refSet.insert(6);
return 0;
}
Now, you can set a BP in the line "refSet.insert(6);", and run the command "p
refSet", you will get the error message.
Python Exception list index out of range:
$1 = std::set with 1 elements
If you run "n", and then type "p refSet" again, you get:
Python Exception list index out of range:
$2 = std::set with 2 elements
It looks like the elements number(from 1 to 2) is correct.
Thanks
Yuanhui Zhang
[Bug libstdc++/53477] pretty printer fails with: Python Exception list index out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477
--- Comment #7 from asmwarrior ---
Ok, I found another issue on the line "return 0", see the GDB log:
[debug]> p m
[debug]$2 = std::map with 1 elements = {[3] = std::set with 2 elements = {[0] =
5, [1] = 6}}
[debug]>>cb_gdb:
[debug]> p m[3]
[debug]Attempt to take address of value not located in memory.
[debug]>>cb_gdb:
"p m" shows the correct value, but I'm not sure why "p m[3]" failed? Is it a
GDB bug?
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #5 from asmwarrior 2011-10-29 14:06:53 UTC --- Hi, all, I think this bug happened about more than one years, I have test in both gcc 4.5 and gcc 4.6.x under Windows. I have both post an issue in GDB maillist and GCC-help maillist. see: http://gcc.gnu.org/ml/gcc-help/2011-10/msg00239.html and http://sourceware.org/ml/gdb/2011-10/msg00209.html The GDB guys thoughts that this is a bug in GCC, and GCC emit wrong debug_line information. When I use GDB under Codeblocks, it will always do some extra jump to variable declaration, and quite unfriendly. asmwarrior ollydbg from codeblocks' forum
[Bug c++/48914] #pragma GCC diagnostic ignored "-Wc++0x-compat" doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48914 --- Comment #4 from asmwarrior 2012-08-02 06:41:33 UTC --- We are Code::Blocks' developers, we see the same annoying warnings, hope it will be fixed. Thanks. See: http://forums.codeblocks.org/index.php/topic,16670.msg113169.html#msg113169
[Bug c++/48914] #pragma GCC diagnostic ignored "-Wc++0x-compat" doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48914 --- Comment #5 from asmwarrior 2012-08-02 08:28:10 UTC --- (In reply to comment #4) > We are Code::Blocks' developers, we see the same annoying warnings, hope it > will be fixed. Thanks. > See: > http://forums.codeblocks.org/index.php/topic,16670.msg113169.html#msg113169 Sorry, I post a wrong link, the link is only accessed by C::B developers, so it is a private link. But we just discuss the same issue.
[Bug c/52602] New: false compilation warning of uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52602
Bug #: 52602
Summary: false compilation warning of uninitialized variable
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: asmwarr...@gmail.com
Hi, when building gdb, I found a false warning, the code is below:
static void
print_one_vtable (struct gdbarch *gdbarch, struct value *value,
int max_voffset,
struct value_print_options *opts)
{
int i;
struct type *type = check_typedef (value_type (value));
struct value *vtable;
CORE_ADDR vt_addr;
vtable = gnuv3_get_vtable (gdbarch, type,
value_address (value)
+ value_embedded_offset (value));
vt_addr = value_address (value_field (vtable,
vtable_field_virtual_functions));
printf_filtered (_("vtable for '%s' @ %s (subobject @ %s):\n"),
TYPE_SAFE_NAME (type),
paddress (gdbarch, vt_addr),
paddress (gdbarch, (value_address (value)
+ value_embedded_offset (value;
for (i = 0; i <= max_voffset; ++i)
{
struct value *vfn;
CORE_ADDR addr;
volatile struct gdb_exception ex;
printf_filtered ("[%d]: ", i);
vfn = value_subscript (value_field (vtable,
vtable_field_virtual_functions),
i);
if (gdbarch_vtable_function_descriptors (gdbarch))
vfn = value_addr (vfn);
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
addr = value_as_address (vfn);
}
if (ex.reason < 0)
printf_filtered (_(""), ex.message);
else
print_function_pointer_address (gdbarch, addr, gdb_stdout,
opts->addressprint);
printf_filtered ("\n");
}
}
in GDB's source: gnu-v3-abi.c, the warning is:
.../../gdb/gdb/gnu-v3-abi.c: In function 'print_one_vtable.isra.2':
.../../gdb/gdb/gnu-v3-abi.c:892:33: error: 'addr' may be used uninitialized in
this function [-Werror=uninitialized]
and the bug is workaround by this patch:
http://sourceware.org/ml/gdb-cvs/2012-03/msg00203.html
Simply use: CORE_ADDR addr = 0;
Yuanhui Zhang
[Bug c/52602] false compilation warning of uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52602 --- Comment #1 from asmwarrior 2012-03-16 14:06:08 UTC --- BTW: here is the discussion in gdb's patch mail list. http://sourceware.org/ml/gdb-patches/2012-03/msg00585.html
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 asmwarrior changed: What|Removed |Added CC||asmwarrior at gmail dot com --- Comment #3 from asmwarrior --- We meet this issue when building wxWidgets trunk and Codeblocks using PCH, see http://forums.codeblocks.org/index.php/topic,18383.msg125964.html#msg125964
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 --- Comment #4 from asmwarrior --- There is a test case in this post: http://sourceforge.net/p/mingwbuilds/mailman/message/29214215/
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951
--- Comment #19 from asmwarrior ---
Hi, I see this bug happens at least in GCC 4.8.2 again. I'm using MinGW-Build
GCC 4.8.2 under Windows, and debug Codeblocks. I have a source code which have
something like:
void CompilerGCC::SetupEnvironment()
{
wxString currentPath;
}
But When I debug through lines using the step command, I see that the caret
still go back the the local variable definition of the line "wxString
currentPath".
I tried the simple test code that Peter Thompson gives, but it works fine, So
it looks like this bug happens in a larger project not the simple one.
Currently I don't have much way to show you. When I see the disassembler code,
I see some call to destructor of wxString.
0x64B0CF81call 0x64b4f094
0x64B0CF86leaeax,[ebp-0x34]
0x64B0CF89movecx,eax
0x64B0CF8Bcall 0x64b5c090
0x64B0CF90leaeax,[ebp-0x38]
0x64B0CF93movecx,eax
0x64B0CF95call 0x64b5c090
0x64B0CF9Aleaeax,[ebp-0x30]
0x64B0CF9DmovDWORD PTR [esp],0x64b6bc70
0x64B0CFA4movecx,eax
When I run
> info line *0x64B0CFDB
[debug]Line 801 of "F:\cb_sf_git\trunk\src\plugins\compilergcc\compilergcc.cpp"
starts at address 0x64b0cf9a and ends at
0x64b0cfe0 .
[debug]F:\cb_sf_git\trunk\src\plugins\compilergcc\compilergcc.cpp:801:32074:beg:0x64b0cf9a
But it looks like this is not enough information I can show you, any suggest
how to see the incorrect line-code map? Thanks.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951
--- Comment #20 from asmwarrior ---
Hi, all. After the conversation on GDB IRC with GDB developer Jan Kratochvil, a
simple test code supplied by Jan in his bug report on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58123#c0 can easily demonstrate
this issue in either GCC 4.8.2 or GCC 4.8.1.
class C {
public:
C() {}
~C() {}
int m() { return 0; }
};
/* 7 */ int main() {
/* 8 */ C a;
/* 9 */ C b;
/* 10 */ C c;
/* 11 */ return a.m() + b.m() + c.m();
/* 12 */ }
You will run "next" command back to line 10, and line 9 until go to the end of
the function main().
Note: the bug #58123 is another issue, Jan expected that the caret should go
back to line 8, but it is not.
[Bug debug/58123] [4.8/4.9 Regression] debug line not tracked for last autovariable dtor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58123 asmwarrior changed: What|Removed |Added CC||asmwarrior at gmail dot com --- Comment #3 from asmwarrior --- @Jan Kratochvil This bug is also exists in GCC 4.8.1. BTW: Your test code can also reproduce the GCC bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951, I have add a comment there. Yuanhui Zhang
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926
--- Comment #6 from asmwarrior ---
It is very simple to reproduce this bug. Here is the steps I do
1, download the GCC 4.8.2 from MinGW-w64 site, I'm using
i686-4.8.2-release-posix-dwarf-rt_v3-rev1
2, download the boost source package, I'm using boost_1_55_0.7z download from
boost official site, extract its source to some folder like:
D:\mingw-builds\boost_1_55_0. (Note, no need to build boost library, only the
boost header files are needed for testing)
3, create a simple file named "pch.h", which contains following:
#ifndef pch_h
#define pch_h
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdelete-non-virtual-dtor"
#include
#include
#include
#include
#pragma GCC diagnostic pop
#endif
4, create a simple "test.cpp" file, which contains following:
#include "pch.h"
int main()
{
int a;
int b;
int c;
a++;
b++;
}
5, build the pch file by running the command.
g++.exe -Wall -fexceptions -g -march=core2 -Wall
-ID:\mingw-builds\boost_1_55_0 -c pch.h -o pch.h.gch
6, now, you will see a file named "pch.h.gch" was generated, its size is bigger
than 200M.
7, compile the test.cpp file by running the command:
g++.exe -v -Wall -fexceptions -g -march=core2 -Wall
-ID:\mingw-builds\boost_1_55_0 -Winvalid-pch -include pch.h -c test.cpp -o
test.o
8, I see some verbose messages, but no "test.o" file was generated in the
working directory, also I see no crash dialog shown.
So, this is indeed a bug.
Now, if you comment out some lines in the pch.h file, e.g. only leave the first
#include directive: #include , and comment out the later three
include directive, and run the steps again, you get a 47M pch.h.gch and a 206K
test.o file.
I try to use GDB to catch the errors, but failed.
Try use GDB, I did such thing:
gdb g++.exe [enter]
then
set args -v -Wall -fexceptions -g -march=core2 -Wall
-ID:\mingw-builds\boost_1_55_0 -Winvalid-pch -include pch.h -c test.cpp -o
test.o [enter]
then
r [enter]
GDB can't catch anything, just the same as I run the command in the Command
line, the last message from GDB is: [Inferior 1 (process 2000) exited with code
01]
Does exit code "01" has some special meaning?
BTW: I have test the GCC 4.9 snapshot
i686-4.9.0-snapshot-20131119-rev205009-posix-dwarf-rt_v4.7z from mingw-w64
site, it has the same bug.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #14 from asmwarrior 2011-12-21 03:21:07 UTC --- Thanks for fix this bug, I hope some devs will backport this patch to 4.5/4.6 branches.
[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71867 --- Comment #12 from asmwarrior --- Hi, (In reply to Jonathan Wakely from comment #11) > Does this code still get miscompiled with GCC 6 and newer? Hi, I'm now using mingw-build i686-7.2.0-release-posix-dwarf-rt_v5-rev1, which was downloaded from: https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/7.2.0/threads-posix/dwarf/i686-7.2.0-release-posix-dwarf-rt_v5-rev1.7z/download I don't see such crash bug since 2018-02-09. (See this post in C::B forum: http://forums.codeblocks.org/index.php/topic,22198.msg152596.html#msg152596)
[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71867
--- Comment #9 from asmwarrior ---
I see this crash issue again, but still it happens in another place of the wx's
source code, add the
__attribute__((optimize("O0")))
To the function which cause the crash can workaround this issue. Note that the
-O0 option does not cause this issue.
wxString __attribute__((optimize("O0"))) wxCommandEvent::GetString() const
{
// This is part of the hack retrieving the event string from the control
// itself only when/if it's really needed to avoid copying potentially huge
// strings coming from multiline text controls. For consistency we also do
// it for combo boxes, even though there are no real performance advantages
// in doing this for them.
if (m_eventType == wxEVT_TEXT && m_eventObject)
{
#if wxUSE_TEXTCTRL
wxTextCtrl *txt = wxDynamicCast(m_eventObject, wxTextCtrl);
if ( txt )
return txt->GetValue();
#endif // wxUSE_TEXTCTRL
#if wxUSE_COMBOBOX
wxComboBox* combo = wxDynamicCast(m_eventObject, wxComboBox);
if ( combo )
return combo->GetValue();
#endif // wxUSE_COMBOBOX
}
return m_cmdString;
}
Please see discussions here in wx-user's maillist and Code::Blocks's forum:
https://groups.google.com/d/msg/wx-users/LUxm6fUhirk/FJRFNIt6AAAJ
and
http://forums.codeblocks.org/index.php/topic,22198.0.html
The original wx's workaround is here: https://trac.wxwidgets.org/ticket/17483
[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71867
--- Comment #10 from asmwarrior ---
Is it related to pointer casting? I see this post:
https://stackoverflow.com/questions/36816363/gcc-4-9-3-more-aggressive-null-pointer-check-removal
Some one reported that the Null check was removed in the following code
void someFunc(struct MyStruct *s)
{
if (s != NULL)
{
cout << s->someField << endl;
delete s;
}
}
I see comments in that question, and some one suggest using
`-fno-strict-aliasing` option.
@Vadim, dose wx use some cast? I see some macros in wx3.1's source like:
// this cast does some more checks at compile time as it uses static_cast
// internally
//
// note that it still has different semantics from dynamic_cast<> and so can't
// be replaced by it as long as there are any compilers not supporting it
#define wxDynamicCast(obj, className) \
((className *) wxCheckDynamicCast( \
const_cast(static_cast(\
const_cast(static_cast(obj, \
&className::ms_classInfo))
[Bug debug/59474] Invalid binaries produced when making win32 EXEs with -gsplit-dwarf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59474 asmwarrior changed: What|Removed |Added CC||asmwarrior at gmail dot com --- Comment #1 from asmwarrior --- Same issue with MinGW-Build i686-4.8.2-release-posix-dwarf-rt_v3-rev2
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 --- Comment #11 from asmwarrior --- Today, I did the same test as in comment 6 with a more recent gcc 5.1(http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/dongsheng-daily/5.x/gcc-5-win32_5.1.1-20150512.7z/download), but I still get the same bad result.
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 --- Comment #12 from asmwarrior --- Hi, I just did a test on the cygwin 32bit tool chain. 1, download the cygwin installer. 2, install gcc-g++ 4.9.2 and boost 1.57 package 3, run the steps in comment 6, except that you don't need to add the "-ID:\mingw-builds\boost_1_55_0" in the build command, because we can use the boost library installed from the previous step. 4, when building the pch files, I get a 318M pch.h.gch file 5, when building the object file, I get a 365K test.o file So, this bug doesn't happen in the cygwin tool chain, and it looks like the bug only happens in the MinGW and MinGW-W64 tool chain. Any ideas what is the reason of this bug? Maybe, someone can supply a debug version of g++, and let help to run under GDB.
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926
--- Comment #13 from asmwarrior ---
I did some further test with the condition I stated in comment 11. That is gcc
5.1.
Now, I have pch.h.gch file (about 200M) already generated.
First thing, I try to see whether preprocessor works OK, so I add the "-E"
option.
For test.cpp file
--
#include "pch.h"
int main()
{
int a;
int b;
int c;
a++;
b++;
}
--
Run the command:
g++.exe -v -E -Wall -fexceptions -g -march=core2 -Wall
-ID:\mingw-builds\boost_1_55_0 -Winvalid-pch -include pch.h test.cpp -o
have-include.i
Then I comment out the first line
--
//#include "pch.h"
int main()
{
int a;
int b;
int c;
a++;
b++;
}
--
Then run the command below:
g++.exe -v -E -Wall -fexceptions -g -march=core2 -Wall
-ID:\mingw-builds\boost_1_55_0 -Winvalid-pch -include pch.h test.cpp -o
no-include.i
Then I compare the result:
Both "have-include.i" and "no-include.i" are about 7M, I see the they are
nearly the same, expect the "have-include.i" have two extra lines.
Here is the have-include.i
--
...
...
#pragma GCC diagnostic pop
# 1 "" 2
# 1 "test.cpp"
# 1 "pch.h" 1
# 2 "test.cpp" 2
int main()
{
int a;
int b;
int c;
a++;
b++;
}
---
Here is no-include.i
--
...
...
#pragma GCC diagnostic pop
# 1 "" 2
# 1 "test.cpp"
int main()
{
int a;
int b;
int c;
a++;
b++;
}
--
Now, I try to build those .i files to object files with those command:
g++.exe -v -Wall -fexceptions -g -march=core2 -Wall -c no-include.i -o
no-include.o
g++.exe -v -Wall -fexceptions -g -march=core2 -Wall -c have-include.i -o
have-include.o
Result is:
I get the same result "no-include.o" and "have-include.o". (Yes, they are
exactly same in every bytes)
Now, I did other test like below:
g++.exe -v -Wall -fexceptions -g -march=core2 -Wall
-ID:\mingw-builds\boost_1_55_0 -Winvalid-pch -include pch.h -c test.cpp -o
have-include-c.o -save-temps
Here, I have "-save-temps" put in the command option, I get no
"have-include-c.o" file generated, also I get an empty "test.ii" generated.
Here is the log:
--
...
...
D:\mingw-builds\boost_1_55_0
e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/../../../../include/c++/5.1.1
e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/../../../../include/c++/5.1.1/i686-w64-mi
ngw32
e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/../../../../include/c++/5.1.1/backward
e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/include
e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/include-fixed
e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/../../../../i686-w64-mingw32/include
End of search list.
--
Now, if I remove the "-save-temps" option, and run below:
g++.exe -v -Wall -fexceptions -g -march=core2 -Wall
-ID:\mingw-builds\boost_1_55_0 -Winvalid-pch -include pch.h -c test.cpp -o
have-include-c.o
Still no "have-include-c.o" file, but this time, the log message has some extra
lines:
--
...
...
D:\mingw-builds\boost_1_55_0
e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/../../../../include/c++/5.1.1
e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/../../../../include/c++/5.1.1/i686-w64-mi
ngw32
e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/../../../../include/c++/5.1.1/backward
e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/include
e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/include-fixed
e:\code\gcc\dongsheng-daily\gcc-5-win32\bin\../lib/gcc/i686-w64-mingw32/5.1.1/../../../../i686-w64-mingw32/include
End of search list.
GNU C++ (GCC) version 5.1.1 20150512 (i686-w64-mingw32)
compiled by GNU C version 5.1.1 20150512, GMP version 5.1.3, MPFR
version 3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: af290162d8f9d7b22486b8d9679fb0bb
--
So, it looks like happens after the preprocessor has successfully read the pch
file, when it(cc1plus.exe) try to start the parsing, it get crashed, but under
my Windows XP, I don't see any message or dialog shown up when it crashed.
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926
--- Comment #14 from asmwarrior ---
The bug can be seen when "-E" and "-fpch-preprocess" is used together to
generate a preprocessed file.
If I have a small pch file named "spch.h" and "spch.h.gch"(note the spch.h.gch
size is about 47M), and if I have a test.cpp like below:
--
#include "spch.h"
int main()
{
int a;
int b;
int c;
a++;
b++;
}
--
Then, run the command:
g++.exe -v -E -Wall -fexceptions -g -march=core2 -Wall
-ID:\mingw-builds\boost_1_55_0 -Winvalid-pch -include spch.h test.cpp
-fpch-preprocess -o xxx.ii -ftime-report
I will get a xxx.ii containing such contents:
--
# 1 "test.cpp"
# 1 "D:\\mingw-builds\\test-51//"
# 1 ""
# 1 ""
#pragma GCC pch_preprocess "./spch.h.gch"
# 1 "test.cpp"
# 1 "spch.h" 1
# 2 "test.cpp" 2
int main()
{
int a;
int b;
int c;
a++;
b++;
}
--
You see, the line "#pragma GCC pch_preprocess "./spch.h.gch"" is generated
correctly, which means G++ load the pch file correctly. (That's what the
-fpch-preprocess option used for, see:
https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html)
But if I use a big pch file "pch.h.gch", and run the similar command line like
above, I don't see any .ii file generated, which means G++ crashed before log
out the line "#pragma GCC pch_preprocess ...".
By reading the source code, I see that in gcc-4.9.2\gcc\c-family\c-ppoutput.c,
there is a function:
/* Load in the PCH file NAME, open on FD. It was originally searched for
by ORIG_NAME. Also, print out a #include command so that the PCH
file can be loaded when the preprocessed output is compiled. */
static void
cb_read_pch (cpp_reader *pfile, const char *name,
int fd, const char *orig_name ATTRIBUTE_UNUSED)
{
c_common_read_pch (pfile, name, fd, orig_name);
fprintf (print.outf, "#pragma GCC pch_preprocess \"%s\"\n", name);
print.src_line++;
}
So, the bug happens before the fprintf() function, maybe inside the
c_common_read_pch function call.
I would like to see anyone can supply a debug version of 32bit cc1plus.exe, so
that I can hunt the bug further under GDB, because building the whole gcc tool
chain is too difficult for me.
[Bug pch/14940] PCH largefile test fails on various platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940 asmwarrior changed: What|Removed |Added CC||asmwarrior at gmail dot com --- Comment #46 from asmwarrior --- It looks like the windows host has the similar issue, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 --- Comment #15 from asmwarrior --- I think the bug has already reported more than ten years ago, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940 There are many fixes in various hosts, but not included the windows hosts. As Kai suggest in the post: https://sourceforge.net/p/mingw-w64/bugs/382/ We need a windows host fix.
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 --- Comment #16 from asmwarrior --- I think I may find some hard coded which limit the pch file size, it is located in: gcc/config/i386/host-mingw32.c You can view the file in https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/config/i386/host-mingw32.c;hb=HEAD There are some code around the line 45 /* FIXME: Is this big enough? */ static const size_t pch_VA_max_size = 128 * 1024 * 1024; It is about 128M as I can see. So, I would suggest to set a larger value of this variable, and try to see it could accept a larger pch file.
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926
--- Comment #17 from asmwarrior ---
Good news, I can definitely confirm that enlarge the value: pch_VA_max_size can
solve the crash issue.
Luckily, the value is defined in host-mingw32.c is a const value:
static const size_t pch_VA_max_size = 128 * 1024 * 1024;
And there are only three references in the host-mingw32.c.
Since I don't have the ability to build the gcc under windows myself, today, I
try to edit the cc1plus.exe in a binary editor.
That is: find the three references instructions in the cc1plus.exe, and edit
the instructions, so that I changed the pch_VA_max_size value from 128M to
512M.
128 * 1024 * 1024 = 128M = 08 00 00 00 (Hex)
512M = 20 00 00 00 (Hex)
To find the places where those three instructions locates, there is a trick.
I use the tool named "ollydbg" version 1.1 which is a debugger and also a
disassembler.
Open the file cc1plus.exe, and let ollydbg show a table containing all the
calls to external modules.
Two references is located in the function body:
static void *
mingw32_gt_pch_get_address (size_t size, int fd ATTRIBUTE_UNUSED)
{
void* res;
size = (size + va_granularity - 1) & ~(va_granularity - 1);
if (size > pch_VA_max_size)
return NULL;
/* FIXME: We let system determine base by setting first arg to NULL.
Allocating at top of available address space avoids unnecessary
fragmentation of "ordinary" (malloc's) address space but may not
be safe with delayed load of system dll's. Preferred addresses
for NT system dlls is in 0x7000 to 0x7800 range.
If we allocate at bottom we need to reserve the address as early
as possible and at the same point in each invocation. */
res = VirtualAlloc (NULL, pch_VA_max_size,
MEM_RESERVE | MEM_TOP_DOWN,
PAGE_NOACCESS);
if (!res)
w32_error (__FUNCTION__, __FILE__, __LINE__, "VirtualAlloc");
else
/* We do not need the address space for now, so free it. */
VirtualFree (res, 0, MEM_RELEASE);
return res;
}
Then, you can search the calling table by "VirtualAlloc" from the table, you
will find only one match, then go the address of the calling instruction, you
can easily find the two instructions which has "0008" in the instructions.
Then, change the last byte to "20", note that "0020" is in fact 20 00 00 00
which is 512M because x86 cpu uses little endian.
The third place can be found in the function body:
static int
mingw32_gt_pch_use_address (void *addr, size_t size, int fd,
size_t offset)
{
void * mmap_addr;
HANDLE mmap_handle;
/* Apparently, MS Vista puts unnamed file mapping objects into Global
namespace when running an application in a Terminal Server
session. This causes failure since, by default, applications
don't get SeCreateGlobalPrivilege. We don't need global
memory sharing so explicitly put object into Local namespace.
If multiple concurrent GCC processes are using PCH functionality,
MapViewOfFileEx returns "Access Denied" error. So we ensure the
session-wide mapping name is unique by appending process ID. */
#define OBJECT_NAME_FMT "Local\\MinGWGCCPCH-"
char* object_name = NULL;
/* However, the documentation for CreateFileMapping says that on NT4
and earlier, backslashes are invalid in object name. So, we need
to check if we are on Windows2000 or higher. */
OSVERSIONINFO version_info;
int r;
version_info.dwOSVersionInfoSize = sizeof (version_info);
if (size == 0)
return 0;
/* Offset must be also be a multiple of allocation granularity for
this to work. We can't change the offset. */
if ((offset & (va_granularity - 1)) != 0 || size > pch_VA_max_size)
return -1;
/* Determine the version of Windows we are running on and use a
uniquely-named local object if running > 4. */
GetVersionEx (&version_info);
Now, search for the function call of "GetVersionEx", you can easily find and
change the instruction.
The total changes can be listed in the patch window of ollydbg, see the screen
shot
http://imagizer.imageshack.us/v2/689x223q90/673/xL8rmw.png
(The cc1plus.exe I used to modify is the one I tested in comment 11)
Then, you can save the modified cc1plus.exe, and now, it can handle larger pch
file up to 512M.
Good luck.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #21 from asmwarrior --- I just test the sample code in comment 20 with GCC 4.9.2, and I see this "jumpy" behaviour still exists, do we need to reopen this bug? Thanks.
[Bug debug/58123] [4.8/4.9/5 Regression] debug line not tracked for last autovariable dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58123 --- Comment #10 from asmwarrior --- (In reply to Jan Kratochvil from comment #8) > (In reply to Aldy Hernandez from comment #7) > > Putting this aside for a second, my question is, do we really want a > > debugging experience where we jump from back from the end of scope, back to > > the declaration of the class? > > I do not think so. > I agree with Jan. Jump back to declaration of a variable may be OK for command line debugging, but it is very annoying especially you use an IDE, which means the whole view window get refreshed.
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 --- Comment #19 from asmwarrior --- Martin Richter has post a patch to solve this issue, see: [Comment 47](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940#c47), also there are some discussion in [MinGW-w64 - for 32 and 64 bit Windows / Bugs / #382 PCH: cc1plus.exe crash on Windows8.1](https://sourceforge.net/p/mingw-w64/bugs/382/)
[Bug pch/14940] PCH largefile test fails on various platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940 --- Comment #48 from asmwarrior --- Hi, Martin Richter, thanks, I have post this patch link in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926.
[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71867 asmwarrior changed: What|Removed |Added CC||asmwarrior at gmail dot com --- Comment #3 from asmwarrior --- Created attachment 38908 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38908&action=edit The preprocessed file This is the command I use to generate the preprocessed file(a.cpp in zip) g++ -E -o a.cpp -O2 -mthreads -DHAVE_W32API_H -D__WXMSW__ -DNDEBUG -D_UNICODE -I..\..\lib\gcc_dll\mswu -I..\..\include -W -Wall -DWXBUILDING -I..\..\src\tiff -I..\..\src\jpeg -I..\..\src\png -I..\..\src\zlib -I..\..\src\regex -I..\..\src\expat\lib -DwxUSE_BASE=1 -DWXMAKINGDLL -Wno-ctor-dtor-privacy -Wno-unused-local-typedefs -Wno-deprecated-declarations -fno-keep-inline-dllexport -g -MTgcc_mswudll\monodll_xh_sizer.o -MFgcc_mswudll\monodll_xh_sizer.o.d -MD -MP ../../src/xrc/xh_sizer.cpp I use TDM GCC5.1 under Windows XP, I use wxWidgets 2.8.12 official release. The command is run from the folder \build\msw\.
[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71867
--- Comment #4 from asmwarrior ---
It looks like the code is called from an inline function, you can see this code
snippet in the prepossessed file.
inline wxObject *wxCheckDynamicCast(wxObject *obj, wxClassInfo *classInfo)
{
return obj && obj->GetClassInfo()->IsKindOf(classInfo) ? obj :
# 502 "..\\..\\include/wx/object.h" 3 4
__null
# 502 "..\\..\\include/wx/object.h"
;
}
[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71867 --- Comment #7 from asmwarrior --- The -fno-delete-null-pointer-checks option exists in -O2 mode in both GCC 4.9 and GCC 5.x, but this crash issue only happens on GCC 5.x serials. So, why do you think it is the reason? See my related discussion here: http://forums.codeblocks.org/index.php/topic,21207.msg145242.html#msg145242
[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71867 --- Comment #8 from asmwarrior --- Hi, I just build wx2.8.12 under TDM-GCC 5.1 with -fno-delete-null-pointer-checks enabled. But the bad thing is that I still see the same crash here. The whole command is below: mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-Wno-unused-local-typedefs -Wno-deprecated-declarations -fno-keep-inline-dllexport -fno-delete-null-pointer-checks -g" >log-release-no-delete-null.txt 2>&1 For some assembler code of the crash: [debug]Stack level 0, frame at 0x22e004: [debug] eip = 0x6d11fb05 in wxClassInfo::IsKindOf (F:\wx\wxMSW-2.8.12\include\wx\object.h:94); saved eip = 0x6cfa043d [debug] inlined into frame 1 [debug] source language c++. [debug] Arglist at unknown address. [debug] Locals at unknown address, Previous frame's sp in esp [debug]>>cb_gdb: [debug]> disassemble 0x6d11fb05 [debug]Dump of assembler code for function wxCheckDynamicCast(wxObject*, wxClassInfo*): [debug] 0x6d11fa70 <+0>: push ebp [debug] 0x6d11fa71 <+1>: push edi [debug] 0x6d11fa72 <+2>: push esi [debug] 0x6d11fa73 <+3>: push ebx [debug] 0x6d11fa74 <+4>: subesp,0x1c [debug] 0x6d11fa77 <+7>: movebx,DWORD PTR [esp+0x30] [debug] 0x6d11fa7b <+11>: movesi,DWORD PTR [esp+0x34] [debug] 0x6d11fa7f <+15>: test ebx,ebx [debug] 0x6d11fa81 <+17>: je 0x6d11fb50 [debug] 0x6d11fa87 <+23>: moveax,DWORD PTR [ebx] [debug] 0x6d11fa89 <+25>: movecx,ebx [debug] 0x6d11fa8b <+27>: call DWORD PTR [eax] [debug] 0x6d11fa8d <+29>: test esi,esi [debug] 0x6d11fa8f <+31>: movedx,eax [debug] 0x6d11fa91 <+33>: je 0x6d11fb50 [debug] 0x6d11fa97 <+39>: cmpeax,esi [debug] 0x6d11fa99 <+41>: je 0x6d11fb3e [debug] 0x6d11fa9f <+47>: movedi,DWORD PTR [eax+0xc] [debug] 0x6d11faa2 <+50>: test edi,edi [debug] 0x6d11faa4 <+52>: je 0x6d11fb05 [debug] 0x6d11faa6 <+54>: cmpesi,edi [debug] 0x6d11faa8 <+56>: je 0x6d11fb3e [debug] 0x6d11faae <+62>: movebp,DWORD PTR [edi+0xc] [debug] 0x6d11fab1 <+65>: test ebp,ebp [debug] 0x6d11fab3 <+67>: je 0x6d11faed [debug] 0x6d11fab5 <+69>: cmpesi,ebp [debug] 0x6d11fab7 <+71>: je 0x6d11fb3e [debug] 0x6d11fabd <+77>: movecx,DWORD PTR [ebp+0xc] [debug] 0x6d11fac0 <+80>: test ecx,ecx [debug] 0x6d11fac2 <+82>: je 0x6d11fad5 [debug] 0x6d11fac4 <+84>: movDWORD PTR [esp],esi [debug] 0x6d11fac7 <+87>: call 0x6d166c80 [debug] 0x6d11facc <+92>: subesp,0x4 [debug] 0x6d11facf <+95>: test al,al [debug] 0x6d11fad1 <+97>: movecx,ebx [debug] 0x6d11fad3 <+99>: jne0x6d11fb40 [debug] 0x6d11fad5 <+101>:movecx,DWORD PTR [ebp+0x10] [debug] 0x6d11fad8 <+104>:test ecx,ecx [debug] 0x6d11fada <+106>:je 0x6d11faed [debug] 0x6d11fadc <+108>:movDWORD PTR [esp],esi [debug] 0x6d11fadf <+111>:call 0x6d166c80 [debug] 0x6d11fae4 <+116>:subesp,0x4 [debug] 0x6d11fae7 <+119>:test al,al [debug] 0x6d11fae9 <+121>:movecx,ebx [debug] 0x6d11faeb <+123>:jne0x6d11fb40 [debug] 0x6d11faed <+125>:movecx,DWORD PTR [edi+0x10] [debug] 0x6d11faf0 <+128>:test ecx,ecx [debug] 0x6d11faf2 <+130>:je 0x6d11fb05 [debug] 0x6d11faf4 <+132>:movDWORD PTR [esp],esi [debug] 0x6d11faf7 <+135>:call 0x6d166c80 [debug] 0x6d11fafc <+140>:subesp,0x4 [debug] 0x6d11faff <+143>:test al,al [debug] 0x6d11fb01 <+145>:movecx,ebx [debug] 0x6d11fb03 <+147>:jne0x6d11fb40 [debug]=> 0x6d11fb05 <+149>:movedx,DWORD PTR [edx+0x10] [debug] 0x6d11fb08 <+152>:test edx,edx [debug] 0x6d11fb0a <+154>:je 0x6d11fb50 [debug] 0x6d11fb0c <+156>:cmpesi,edx [debug] 0x6d11fb0e <+158>:je 0x6d11fb3e [debug] 0x6d11fb10 <+160>:movecx,DWORD PTR [edx+0xc] [debug] 0x6d11fb13 <+163>:test ecx,ecx [debug] 0x6d11fb15 <+165>:je 0x6d11fb28 [debug] 0x6d11fb17 <+167>:movDWORD PTR [esp],esi [debug] 0x6d11fb1a <+170>:call 0x6d166c80 [debug] 0x6d11fb1f <+175>:subesp,0x4 [debug] 0x6d11fb22 <+178>:test al,al [debug] 0x6d11fb24 <+180>:movecx,ebx [debug] 0x6d11fb26 <+182>:jne0x6d11fb40 [debug] 0x6d11fb28 <+184>:movecx,DWORD PTR [edx+0x10] [debug] 0x6d11fb2b <+187>:test ecx,ecx [debug] 0x6d11fb2d <+189>:je 0x6d11fb50 [debug] 0x6d11fb2f <+191>:movDWORD PTR [esp],esi [debug] 0x6d11fb32 <+194>:call 0x6d166c80 [debug] 0x6d11fb37 <+199>:subesp,0x4 [debug] 0x6d11fb3a <+202>:test al,al [debug] 0x6d11fb3c <+204>:je 0x6d11fb50 [debug] 0x6d11fb3e <+206>:movecx,ebx [debug] 0x6d11fb40 <+208
