* [Bug libstdc++/39738] GCC cannot build itself for win64 platform
2009-04-11 15:00 [Bug libstdc++/39738] New: GCC cannot build itself for win64 platform css20 at mail dot ru
@ 2009-04-11 18:47 ` paolo dot carlini at oracle dot com
2009-04-11 19:33 ` [Bug target/39738] " ktietz at gcc dot gnu dot org
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-11 18:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from paolo dot carlini at oracle dot com 2009-04-11 18:47 -------
Are you sure your entire compiler is up to date, not just the library? And the
build and install directories are clean? Because your first lines of failure
involve bits of the library which *require* a consistent simultaneous change in
the C++ front-end, and well, nobody is experiencing similar problems anywhere.
Not that this code is target-independent.
CC-ing Jason, the author of such code, to be sure.
--
paolo dot carlini at oracle dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu dot org
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/39738] GCC cannot build itself for win64 platform
2009-04-11 15:00 [Bug libstdc++/39738] New: GCC cannot build itself for win64 platform css20 at mail dot ru
2009-04-11 18:47 ` [Bug libstdc++/39738] " paolo dot carlini at oracle dot com
@ 2009-04-11 19:33 ` ktietz at gcc dot gnu dot org
2009-04-11 21:09 ` css20 at mail dot ru
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2009-04-11 19:33 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from ktietz at gcc dot gnu dot org 2009-04-11 19:33 -------
(In reply to comment #1)
> Are you sure your entire compiler is up to date, not just the library? And the
> build and install directories are clean? Because your first lines of failure
> involve bits of the library which *require* a consistent simultaneous change in
> the C++ front-end, and well, nobody is experiencing similar problems anywhere.
> Not that this code is target-independent.
>
> CC-ing Jason, the author of such code, to be sure.
>
Well, on 4.4 branch there was a patch introducing the winsup link, which got
necessary for building libstdc++. We solve this by setting up in gcc's source
tree a symbolic link "winsup" pointing to the sysroot (prefix) directory.
Cheers,
Kai
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/39738] GCC cannot build itself for win64 platform
2009-04-11 15:00 [Bug libstdc++/39738] New: GCC cannot build itself for win64 platform css20 at mail dot ru
2009-04-11 18:47 ` [Bug libstdc++/39738] " paolo dot carlini at oracle dot com
2009-04-11 19:33 ` [Bug target/39738] " ktietz at gcc dot gnu dot org
@ 2009-04-11 21:09 ` css20 at mail dot ru
2009-04-12 8:50 ` css20 at mail dot ru
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: css20 at mail dot ru @ 2009-04-11 21:09 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from css20 at mail dot ru 2009-04-11 21:09 -------
> Are you sure your entire compiler is up to date, not just the library?
No.. it was not lasest snapshot (20090331).
> We solve this by setting up in gcc's source tree a symbolic link "winsup" pointing to the sysroot (prefix) directory
I move to gcc-4.4.0-20090407, create symbolik link to my prefix directory
(/usr/win64), but build not successfully..
make running from build/x86_64-pc-mingw32/libstdc++-v3/src:
/bin/sh ../libtool --tag CXX --mode=compile x86_64-pc-mingw32-c++
-L/usr/portage/local/overlays/gcc-4.4.0/build/x86_64-pc-mingw32/winsup/mingw
-L/usr/portage/local/overlays/gcc-4.4.0/build/x86_64-pc-mingw32/winsup/w32api/lib
-isystem /usr/portage/local/overlays/gcc-4.4.0/src/winsup/mingw/include
-isystem /usr/portage/local/overlays/gcc-4.4.0/src/winsup/w32api/include
-I/usr/portage/local/overlays/gcc-4.4.0/build/x86_64-pc-mingw32/libstdc++-v3/include/x86_64-pc-mingw32
-I/usr/portage/local/overlays/gcc-4.4.0/build/x86_64-pc-mingw32/libstdc++-v3/include
-I/usr/portage/local/overlays/gcc-4.4.0/src/libstdc++-v3/libsupc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2
-std=gnu++0x -c ../../../../src/libstdc++-v3/src/atomic.cc
libtool: compile: x86_64-pc-mingw32-c++
-L/usr/portage/local/overlays/gcc-4.4.0/build/x86_64-pc-mingw32/winsup/mingw
-L/usr/portage/local/overlays/gcc-4.4.0/build/x86_64-pc-mingw32/winsup/w32api/lib
-isystem /usr/portage/local/overlays/gcc-4.4.0/src/winsup/mingw/include
-isystem /usr/portage/local/overlays/gcc-4.4.0/src/winsup/w32api/include
-I/usr/portage/local/overlays/gcc-4.4.0/build/x86_64-pc-mingw32/libstdc++-v3/include/x86_64-pc-mingw32
-I/usr/portage/local/overlays/gcc-4.4.0/build/x86_64-pc-mingw32/libstdc++-v3/include
-I/usr/portage/local/overlays/gcc-4.4.0/src/libstdc++-v3/libsupc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2
-std=gnu++0x -c ../../../../src/libstdc++-v3/src/atomic.cc -o atomic.o
In file included from
/usr/portage/local/overlays/gcc-4.4.0/build/x86_64-pc-mingw32/libstdc++-v3/include/utility:88,
from
/usr/portage/local/overlays/gcc-4.4.0/build/x86_64-pc-mingw32/libstdc++-v3/include/tuple:43,
from
/usr/portage/local/overlays/gcc-4.4.0/build/x86_64-pc-mingw32/libstdc++-v3/include/mutex:44,
from ../../../../src/libstdc++-v3/src/atomic.cc:33:
/usr/portage/local/overlays/gcc-4.4.0/src/libstdc++-v3/libsupc++/initializer_list:
In constructor 'std::initializer_list<_E>::initializer_list()':
/usr/portage/local/overlays/gcc-4.4.0/src/libstdc++-v3/libsupc++/initializer_list:59:
error: 'NULL' was not declared in this scope
There is a possibility of manual build.. call make with these options
make -j9 CFLAGS="-g -O2 -DNULL=0" CXXFLAGS="-g -O2 -DNULL=0
and compile remaining parts of gcc from root build directory, but it is not too
convenient...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/39738] GCC cannot build itself for win64 platform
2009-04-11 15:00 [Bug libstdc++/39738] New: GCC cannot build itself for win64 platform css20 at mail dot ru
` (2 preceding siblings ...)
2009-04-11 21:09 ` css20 at mail dot ru
@ 2009-04-12 8:50 ` css20 at mail dot ru
2009-04-12 19:36 ` css20 at mail dot ru
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: css20 at mail dot ru @ 2009-04-12 8:50 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from css20 at mail dot ru 2009-04-12 08:50 -------
First tests of Win64 compiler.. simple source file test.c was created:
#include "windows.h"
int main(int argc, char **argv)
{
MessageBox(NULL, "test", "test", MB_OK);
}
E:\temp\test>gcc test.c
gcc: CreateProcess: No such file or directory
E:\temp\test>gcc -### test.c
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with: ../src/configure --prefix=/usr/win64 --with-sysroot=/usr/win64
--host=x86_64-pc-mingw32 --target=x86_64-pc-mingw32 --enable-languages=c,c++
--d
isable-win32-registry --disable-nls --disable-shared --disable-sjlj-exceptions
-
-with-dwarf2 --disable-libssp --enable-libgomp
Thread model: win32
gcc version 4.4.0 20090407 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-mtune=generic'
"e:/mingw64/bin/../libexec/gcc/x86_64-pc-mingw32/4.4.0/cc1.exe" "-quiet"
"-ipre
fix" "e:\\mingw64\\bin\\../lib/gcc/x86_64-pc-mingw32/4.4.0/" "test.c" "-quiet"
"
-dumpbase" "test.c" "-mtune=generic" "-auxbase" "test" "-o"
"C:\\Users\\X\\AppDa
ta\\Local\\Temp\\cciH4k6g.s"
COLLECT_GCC_OPTIONS='-mtune=generic'
" \"" ------> <Here must be assembler path and arguments>
then compiler drivers segfaults.. gdb output:
Program received signal SIGSEGV, Segmentation fault.
main (argc=3, argv=0x72120) at ../../src/gcc/gcc.c:6848
6848 in ../../src/gcc/gcc.c
code from gcc.c(6848):
/* Determine if there are any linker input files. */
num_linker_inputs = 0;
for (i = 0; (int) i < n_infiles; i++)
if (explicit_link_files[i] || outfiles[i] != NULL)
num_linker_inputs++;
(gdb) p outfiles[i]
$12 = 0x72200 "test.c"
(gdb) p explicit_link_files[i]
No symbol "explicit_link_files" in current context - ???
disassembly listing:
000000000040DB7B cmp byte ptr [rbx+rcx],0 <--- rbx & rcx = 0
000000000040DB7F jne 000000000040DB88
000000000040DB81 cmp qword ptr [rdi+rcx*8],0
000000000040DB86 je 000000000040DB8B
What is it, incorrect build or compiler driver bug ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/39738] GCC cannot build itself for win64 platform
2009-04-11 15:00 [Bug libstdc++/39738] New: GCC cannot build itself for win64 platform css20 at mail dot ru
` (3 preceding siblings ...)
2009-04-12 8:50 ` css20 at mail dot ru
@ 2009-04-12 19:36 ` css20 at mail dot ru
2009-04-12 19:49 ` ktietz at gcc dot gnu dot org
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: css20 at mail dot ru @ 2009-04-12 19:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from css20 at mail dot ru 2009-04-12 19:35 -------
I see this bug in compiler driver is already known
(http://sourceforge.net/forum/forum.php?thread_id=3091795&forum_id=723797), it
works only with "-O0". I can't found report about this bug in database.. does
it exists ?
> Well, on 4.4 branch there was a patch introducing the winsup link, which got necessary for building libstdc++. We solve this by setting up in gcc's source tree a symbolic link "winsup" pointing to the sysroot (prefix) directory.
Symbolic link "winsup" to prefix directory with mingw-w64 runtime headers not
works properly with current gcc 4.4.0 snapshot.. for correct build you must
*temporary* remove file "stddef.h" from
${YOUR_PREFIX}/x86_64-pc-mingw32/include because it conflicts with same file in
libstdc++ build directory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/39738] GCC cannot build itself for win64 platform
2009-04-11 15:00 [Bug libstdc++/39738] New: GCC cannot build itself for win64 platform css20 at mail dot ru
` (4 preceding siblings ...)
2009-04-12 19:36 ` css20 at mail dot ru
@ 2009-04-12 19:49 ` ktietz at gcc dot gnu dot org
2009-04-13 8:12 ` css20 at mail dot ru
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2009-04-12 19:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from ktietz at gcc dot gnu dot org 2009-04-12 19:49 -------
(In reply to comment #5)
> I see this bug in compiler driver is already known
> (http://sourceforge.net/forum/forum.php?thread_id=3091795&forum_id=723797), it
> works only with "-O0". I can't found report about this bug in database.. does
> it exists ?
Yes, there is already one. But this bug is work-a-round by a temporary hack in
our crt. So it shouldn't appear anymore.
> > Well, on 4.4 branch there was a patch introducing the winsup link, which got necessary for building libstdc++. We solve this by setting up in gcc's source tree a symbolic link "winsup" pointing to the sysroot (prefix) directory.
>
>
> Symbolic link "winsup" to prefix directory with mingw-w64 runtime headers not
> works properly with current gcc 4.4.0 snapshot.. for correct build you must
> *temporary* remove file "stddef.h" from
> ${YOUR_PREFIX}/x86_64-pc-mingw32/include because it conflicts with same file in
> libstdc++ build directory.
>
Hmm, I tested a native build with current 4.4 gcc and I had no issues about it.
Please make sure, that you have in your gcc source root directory the symbolic
link "winsup" pointing to your prefix directory. Secondly, make sure you have
the symbolic link "mingw" in your prefix directory, which has to point to
x86_64-pc-mingw32 directory.
If you need further help you can join #mingw-w64 on irc.oftc.net.
Cheers,
Kai
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/39738] GCC cannot build itself for win64 platform
2009-04-11 15:00 [Bug libstdc++/39738] New: GCC cannot build itself for win64 platform css20 at mail dot ru
` (5 preceding siblings ...)
2009-04-12 19:49 ` ktietz at gcc dot gnu dot org
@ 2009-04-13 8:12 ` css20 at mail dot ru
2009-04-13 8:34 ` ktietz at gcc dot gnu dot org
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: css20 at mail dot ru @ 2009-04-13 8:12 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from css20 at mail dot ru 2009-04-13 08:11 -------
> Please make sure, that you have in your gcc source root directory the symbolic
> link "winsup" pointing to your prefix directory. Secondly, make sure you have
> the symbolic link "mingw" in your prefix directory, which has to point to
> x86_64-pc-mingw32 directory.
I use Gentoo Linux x64 as build OS with system compiler gcc 4.3.3,
configuration script arguments you can see in my first post. Both symbolic
links were created.. existing stddef.h file in winsup/mingw/include causes
error: 'NULL' was not declared in this scope during libstdc++ building (see my
earlier post).
> Yes, there is already one. But this bug is work-a-round by a temporary hack in
> our crt. So it shouldn't appear anymore.
Alltimes use -O0 is not the solution.. temporary CRT hacks too. Where I can get
more information about this bug ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/39738] GCC cannot build itself for win64 platform
2009-04-11 15:00 [Bug libstdc++/39738] New: GCC cannot build itself for win64 platform css20 at mail dot ru
` (6 preceding siblings ...)
2009-04-13 8:12 ` css20 at mail dot ru
@ 2009-04-13 8:34 ` ktietz at gcc dot gnu dot org
2009-04-13 15:48 ` css20 at mail dot ru
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2009-04-13 8:34 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from ktietz at gcc dot gnu dot org 2009-04-13 08:34 -------
(In reply to comment #7)
> > Please make sure, that you have in your gcc source root directory the symbolic
> > link "winsup" pointing to your prefix directory. Secondly, make sure you have
> > the symbolic link "mingw" in your prefix directory, which has to point to
> > x86_64-pc-mingw32 directory.
>
> I use Gentoo Linux x64 as build OS with system compiler gcc 4.3.3,
> configuration script arguments you can see in my first post. Both symbolic
> links were created.. existing stddef.h file in winsup/mingw/include causes
> error: 'NULL' was not declared in this scope during libstdc++ building (see my
> earlier post).
>
> > Yes, there is already one. But this bug is work-a-round by a temporary hack in
> > our crt. So it shouldn't appear anymore.
> Alltimes use -O0 is not the solution.. temporary CRT hacks too. Where I can get
> more information about this bug ?
>
Why using all time -O0? This bug you reference to is not related to your
bootstrap issue.
So, the only issue I see here are the following possible reasons (beside the
possibility of wrong symbolic links, which you have shown to setup properly).
Do you use for native toolchain an fresh initialized directory?
Which version of toolchain you are using (especially header-set)?
Do you use --prefix and --with-sysroot options?
You can try the following. Remove in your <prefix> directory the folder
lib/gcc/x86_64-pc-mingw32/4.4.0/ and remove in your gcc's build directory the
x86_64-pc-mingw32 folder. Then do a 'make'. This error can happen also, when
the sysroot headers are copied too late (after the 'make all-gcc', because
fixinclude get executed already here).
Cheers,
Kai
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/39738] GCC cannot build itself for win64 platform
2009-04-11 15:00 [Bug libstdc++/39738] New: GCC cannot build itself for win64 platform css20 at mail dot ru
` (7 preceding siblings ...)
2009-04-13 8:34 ` ktietz at gcc dot gnu dot org
@ 2009-04-13 15:48 ` css20 at mail dot ru
2009-04-13 18:06 ` css20 at mail dot ru
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: css20 at mail dot ru @ 2009-04-13 15:48 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from css20 at mail dot ru 2009-04-13 15:48 -------
> Do you use for native toolchain an fresh initialized directory?
> Which version of toolchain you are using (especially header-set)?
> Do you use --prefix and --with-sysroot options?
I use directory with mingw-64 runtime installed as --prefix= and
--with-sysroot= argument. Toolchain versions:
binutils 2.19.1
gmp 4.2.4
mpfr 2.4.1
CRT and pthreads - last versions from
http://sourceforge.net/project/showfiles.php?group_id=202880
> You can try the following. Remove in your <prefix> directory the folder
> lib/gcc/x86_64-pc-mingw32/4.4.0/ and remove in your gcc's build directory the
> x86_64-pc-mingw32 folder. Then do a 'make'
No any changes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/39738] GCC cannot build itself for win64 platform
2009-04-11 15:00 [Bug libstdc++/39738] New: GCC cannot build itself for win64 platform css20 at mail dot ru
` (8 preceding siblings ...)
2009-04-13 15:48 ` css20 at mail dot ru
@ 2009-04-13 18:06 ` css20 at mail dot ru
2009-04-13 19:25 ` ktietz at gcc dot gnu dot org
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: css20 at mail dot ru @ 2009-04-13 18:06 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from css20 at mail dot ru 2009-04-13 18:06 -------
I try to build gcc with latest CRT from svn (revision 764) - build is OK. It
seems, snapshot from sourceforge download page(November 15, 2008) not
compatible with gcc 4.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/39738] GCC cannot build itself for win64 platform
2009-04-11 15:00 [Bug libstdc++/39738] New: GCC cannot build itself for win64 platform css20 at mail dot ru
` (9 preceding siblings ...)
2009-04-13 18:06 ` css20 at mail dot ru
@ 2009-04-13 19:25 ` ktietz at gcc dot gnu dot org
2009-05-23 9:47 ` loaden at gmail dot com
2009-05-24 4:34 ` paolo dot carlini at oracle dot com
12 siblings, 0 replies; 14+ messages in thread
From: ktietz at gcc dot gnu dot org @ 2009-04-13 19:25 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from ktietz at gcc dot gnu dot org 2009-04-13 19:25 -------
(In reply to comment #10)
> I try to build gcc with latest CRT from svn (revision 764) - build is OK. It
> seems, snapshot from sourceforge download page(November 15, 2008) not
> compatible with gcc 4.4.
>
Well, this is true. We'll release soon the gcc 4.4 version is out of the door.
Of course we will update the crt/header-set tarball also.
Thanks and cheers,
Kai
--
ktietz at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/39738] GCC cannot build itself for win64 platform
2009-04-11 15:00 [Bug libstdc++/39738] New: GCC cannot build itself for win64 platform css20 at mail dot ru
` (10 preceding siblings ...)
2009-04-13 19:25 ` ktietz at gcc dot gnu dot org
@ 2009-05-23 9:47 ` loaden at gmail dot com
2009-05-24 4:34 ` paolo dot carlini at oracle dot com
12 siblings, 0 replies; 14+ messages in thread
From: loaden at gmail dot com @ 2009-05-23 9:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #12 from loaden at gmail dot com 2009-05-23 09:46 -------
(In reply to comment #2)
> (In reply to comment #1)
> > Are you sure your entire compiler is up to date, not just the library? And the
> > build and install directories are clean? Because your first lines of failure
> > involve bits of the library which *require* a consistent simultaneous change in
> > the C++ front-end, and well, nobody is experiencing similar problems anywhere.
> > Not that this code is target-independent.
> >
> > CC-ing Jason, the author of such code, to be sure.
> >
>
> Well, on 4.4 branch there was a patch introducing the winsup link, which got
> necessary for building libstdc++. We solve this by setting up in gcc's source
> tree a symbolic link "winsup" pointing to the sysroot (prefix) directory.
>
> Cheers,
> Kai
>
Hi, I have same question when build MinGW on Ubuntu, i use Cross compiler.
and, can you tell me: where is the "winsup" patch? and how to create a link to
gcc's source?
Thanks!
--
loaden at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |loaden at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/39738] GCC cannot build itself for win64 platform
2009-04-11 15:00 [Bug libstdc++/39738] New: GCC cannot build itself for win64 platform css20 at mail dot ru
` (11 preceding siblings ...)
2009-05-23 9:47 ` loaden at gmail dot com
@ 2009-05-24 4:34 ` paolo dot carlini at oracle dot com
12 siblings, 0 replies; 14+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-05-24 4:34 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from paolo dot carlini at oracle dot com 2009-05-24 04:34 -------
*** Bug 40231 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
^ permalink raw reply [flat|nested] 14+ messages in thread