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

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

[vanboxem.ruben at gmail dot com]

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

             Bug #: 56926
           Summary: Crash (without ICE) while compiling Boost.Math
    Classification: Unclassified
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: vanboxem.ruben@gmail.com


When compiling the file libs\math\build\..\src\tr1\assoc_laguerre.cpp from
Boost 1.52.0 or 1.53.0 (perhaps any other version is affected too), GCC causes
a dirty crash providing me no way of getting a sensible backtrace or providing
a preprocessed source for reproduction. The compile command is:

"g++"  -ftemplate-depth-128 -O0 -fno-inline -Wall -g -mthreads
-fvisibility=hidden -Winvalid-pch -DBOOST_ALL_NO_LIB=1
-DBOOST_BUILD_PCH_ENABLED
-I"bin.v2\libs\math\build\gcc-mingw-4.8.1\debug\link-static\threading-multi\..\src\tr1"
-I"." -I"libs\math\src\tr1" -c -o
"bin.v2\libs\math\build\gcc-mingw-4.8.1\debug\link-static\threading-multi\assoc_laguerre.o"
"libs\math\build\..\src\tr1\assoc_laguerre.cpp"

This does not happen with GCC 4.7. If there is anything I can try to give more
output, please let me know. The crash happens before -save-temps outputs
anything.

The binaries are for Windows 64-bit and available here (but require Win64, I
haven't tested the Linux binaries built with the exact same build process):
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.8-release/x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb.7z/download

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-04-12
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-12 08:42:20 UTC ---
Don't use PCH.  But we still need a testcase.

[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

[1000hz.radiowave at gmail dot com]

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

baltic <1000hz.radiowave at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |1000hz.radiowave at gmail dot com

--- Comment #5 from baltic <1000hz.radiowave at gmail dot com> ---
Experience the same while trying to build a project with massive amounts of Qt
headers in a pch. Happens with mingw64 builds for versions 4.8.0 4.8.1 and
4.8.2
Can upload the pch, if needed. worked fine with 4.6

[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 c++/56926] Crash (without ICE) while compiling Boost.Math

[1000hz.radiowave at gmail dot com]

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

--- Comment #7 from baltic <1000hz.radiowave at gmail dot com> ---
(In reply to baltic from comment #5)
> worked fine with 4.6
This is not true anymore :) was probably working fine with previous versions of
the Qt, because headers were smaller back than. Now 4.6 version of MinGW-64
doesn't work with the PCH's full of Qt headers either.

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

[ai.emma.me at gmail dot com]

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

Emma <ai.emma.me at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ai.emma.me at gmail dot com

--- Comment #8 from Emma <ai.emma.me at gmail dot com> ---
Probably I'd better add some comments here, even though the problem was not
caused by compiling boost. Well, it is crashed because compiling large
precompiled header file. Any progress to solve the problem?

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

[andre at netzeband dot eu]

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

Andre Netzeband <andre at netzeband dot eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andre at netzeband dot eu

--- Comment #9 from Andre Netzeband <andre at netzeband dot eu> ---
Hello

I'm using MingW64 with GCC 4.9.1 (x86_64-4.9.1-posix-seh-rt_v3-rev1) and tried
to precompile some Boost Headers to speed up compiling.
Unfortunately I get the same error described here: It crashed and windows just
show the following information:

  Problemereignisname:    APPCRASH
  Anwendungsname:    cc1plus.exe
  Anwendungsversion:    0.0.0.0
  Anwendungszeitstempel:    00000000
  Fehlermodulname:    cc1plus.exe
  Fehlermodulversion:    0.0.0.0
  Fehlermodulzeitstempel:    00000000
  Ausnahmecode:    c0000005
  Ausnahmeoffset:    0000000000923688
  Betriebsystemversion:    6.1.7601.2.1.0.256.48
  Gebietsschema-ID:    1031
  Zusatzinformation 1:    50fa
  Zusatzinformation 2:    50fa4f6a0bed1a7f9bb7018c9ff4ca3f
  Zusatzinformation 3:    7510
  Zusatzinformation 4:    751099e505bceb2fa8cbac2f21c93fb2

This issue was reported over one year ago. Was there any progress?

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

[andre at netzeband dot eu]

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

--- Comment #10 from Andre Netzeband <andre at netzeband dot eu> ---
Once again the question: The original error report is around 1,5 years old. I
can hardly believe that there has been absolutely no progress so far.

[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 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 #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 #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 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 0x70000000 to 0x78000000 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 "00000008" in the instructions.
Then, change the last byte to "20", note that "00000020" 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

[ismail at donmez dot ws]

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

İsmail "cartman" Dönmez <ismail at donmez dot ws> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ismail at donmez dot ws

--- Comment #18 from İsmail "cartman" Dönmez <ismail at donmez dot ws> ---
It would make sense to set this fixed size to 1GB.
>From gcc-bugs-return-487793-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 02 08:50:08 2015
Return-Path: <gcc-bugs-return-487793-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 83710 invoked by alias); 2 Jun 2015 08:50:08 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 83562 invoked by uid 48); 2 Jun 2015 08:50:04 -0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/65419] incorrect sibcalls to libgomp functions
Date: Tue, 02 Jun 2015 08:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: openacc
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: vries at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65419-4-dwLGzOBr0U@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65419-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65419-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg00125.txt.bz2
Content-length: 546

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide419

--- Comment #15 from vries at gcc dot gnu.org ---
(In reply to vries from comment #3)
> [ There's a problem with the matching.  The rs in "..rrr" were supposed to
> match the PTR_PTR_PTR arguments. But that's not the case, since we need to
> add a dot even for a void result. So the intended spec string was "...rrr".
> AFAIU, this problem does not affect this PR. But I will review
> omp-builtins.def for similar problems. ]

Fixed in https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00089.html