[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer

[asmwarrior at gmail dot com]

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

[asmwarrior at gmail dot com]

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, \
::ms_classInfo))

[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer

[asmwarrior at gmail dot com]

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

[asmwarrior at gmail dot com]

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]

[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer

[asmwarrior at gmail dot com]

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

[asmwarrior at gmail dot com]

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

[asmwarrior at gmail dot com]

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=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 pch/14940] PCH largefile test fails on various platforms

[asmwarrior at gmail dot com]

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

--- Comment #48 from asmwarrior asmwarrior at gmail dot com ---
Hi, Martin Richter, thanks, I have post this patch link in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926.

[Bug c++/56926] Crash (without ICE) while compiling Boost.Math

[asmwarrior at gmail dot com]

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

--- Comment #19 from asmwarrior asmwarrior at gmail dot com ---
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 c++/56926] Crash (without ICE) while compiling Boost.Math

[asmwarrior at gmail dot com]

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

--- Comment #17 from asmwarrior asmwarrior at gmail dot com ---
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 c++/56926] Crash (without ICE) while compiling Boost.Math

[asmwarrior at gmail dot com]

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

--- Comment #15 from asmwarrior asmwarrior at gmail dot com ---
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

[asmwarrior at gmail dot com]

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

--- Comment #16 from asmwarrior asmwarrior at gmail dot com ---
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 pch/14940] PCH largefile test fails on various platforms

[asmwarrior at gmail dot com]

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

asmwarrior asmwarrior at gmail dot com changed:

   What|Removed |Added

 CC||asmwarrior at gmail dot com

--- Comment #46 from asmwarrior asmwarrior at gmail dot com ---
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

[asmwarrior at gmail dot com]

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

--- Comment #13 from asmwarrior asmwarrior at gmail dot com ---
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 command-line 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 command-line 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

[asmwarrior at gmail dot com]

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

--- Comment #14 from asmwarrior asmwarrior at gmail dot com ---
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 built-in
# 1 command-line
#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 c++/56926] Crash (without ICE) while compiling Boost.Math

[asmwarrior at gmail dot com]

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

--- Comment #12 from asmwarrior asmwarrior at gmail dot com ---
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

[asmwarrior at gmail dot com]

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

--- Comment #11 from asmwarrior asmwarrior at gmail dot com ---
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 debug/58123] [4.8/4.9/5 Regression] debug line not tracked for last autovariable dtor

[asmwarrior at gmail dot com]

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

--- Comment #10 from asmwarrior asmwarrior at gmail dot com ---
(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 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

[asmwarrior at gmail dot com]

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

--- Comment #21 from asmwarrior asmwarrior at gmail dot com ---
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/59474] Invalid binaries produced when making win32 EXEs with -gsplit-dwarf

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59474

asmwarrior asmwarrior at gmail dot com changed:

   What|Removed |Added

 CC||asmwarrior at gmail dot com

--- Comment #1 from asmwarrior asmwarrior at gmail dot com ---
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

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926

--- Comment #6 from asmwarrior asmwarrior at gmail dot com ---
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 boost/asio.hpp
#include boost/iostreams/filtering_stream.hpp
#include boost/program_options.hpp
#include boost/thread.hpp

#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 boost/asio.hpp, 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

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951

--- Comment #19 from asmwarrior asmwarrior at gmail dot com ---
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 InfoWindow::Display(wxString const, wxString
const, unsigned int, unsigned int)
0x64B0CF86leaeax,[ebp-0x34]
0x64B0CF89movecx,eax
0x64B0CF8Bcall   0x64b5c090 wxString::~wxString()
0x64B0CF90leaeax,[ebp-0x38]
0x64B0CF93movecx,eax
0x64B0CF95call   0x64b5c090 wxString::~wxString()
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 CompilerGCC::SetupEnvironment()+3258 and ends at
0x64b0cfe0 CompilerGCC::SetupEnvironment()+3328.
[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

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951

--- Comment #20 from asmwarrior asmwarrior at gmail dot com ---
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

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58123

asmwarrior asmwarrior at gmail dot com changed:

   What|Removed |Added

 CC||asmwarrior at gmail dot com

--- Comment #3 from asmwarrior asmwarrior at gmail dot com ---
@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

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926

--- Comment #4 from asmwarrior asmwarrior at gmail dot com ---
There is a test case in this post:
http://sourceforge.net/p/mingwbuilds/mailman/message/29214215/

[Bug c++/56926] Crash (without ICE) while compiling Boost.Math

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926

asmwarrior asmwarrior at gmail dot com changed:

   What|Removed |Added

 CC||asmwarrior at gmail dot com

--- Comment #3 from asmwarrior asmwarrior at gmail dot com ---
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 libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477

--- Comment #6 from asmwarrior asmwarrior at gmail dot com ---
Hi, all, I create a simple c++ program to reproduce this bug:

#include set
#include map
typedef std::setint  IntSet;
typedef std::mapint, IntSet 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 type 'exceptions.IndexError' 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 type 'exceptions.IndexError' 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 type 'exceptions.IndexError' list index out of range

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477

--- Comment #7 from asmwarrior asmwarrior at gmail dot com ---
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 libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477

asmwarrior asmwarrior at gmail dot com changed:

   What|Removed |Added

 CC||asmwarrior at gmail dot com

--- Comment #3 from asmwarrior asmwarrior at gmail dot com ---
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 type 'exceptions.IndexError' list index out of range: 
[debug]$2 = std::set with 1 elements
[debug]cb_gdb:

[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477

--- Comment #4 from asmwarrior asmwarrior at gmail dot com ---
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 type 'exceptions.IndexError' list index out of range

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477

--- Comment #5 from asmwarrior asmwarrior at gmail dot com ---
 p /r m_Headers

[debug] p /r m_Headers
[debug]$5 = (StringSet ) @0x116d0bc4: {_M_t = {_M_impl =
{std::allocatorstd::_Rb_tree_nodewxString  =
{__gnu_cxx::new_allocatorstd::_Rb_tree_nodewxString  = {No data
fields}, No data fields}, _M_key_compare = {std::binary_functionwxString,
wxString, bool = {No data fields}, No data fields}, _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::setwxString  StringSet;

Hope those information can help to solve this bug.

[Bug c++/48914] #pragma GCC diagnostic ignored -Wc++0x-compat doesn't work

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48914

--- Comment #4 from asmwarrior asmwarrior at gmail dot com 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

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48914

--- Comment #5 from asmwarrior asmwarrior at gmail dot com 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

[asmwarrior at gmail dot com]

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 (_(error: %s), 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

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52602

--- Comment #1 from asmwarrior asmwarrior at gmail dot com 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 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

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951

--- Comment #14 from asmwarrior asmwarrior at gmail dot com 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 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

[asmwarrior at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951

--- Comment #5 from asmwarrior asmwarrior at gmail dot com 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