[Bug target/55014] New: ICE: Segmentation fault while compiling complex_io.cc on x86_64-w64-mingw32

2012-10-21 Thread coolypf at qq dot com 


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



 Bug #: 55014

   Summary: ICE: Segmentation fault while compiling complex_io.cc

on x86_64-w64-mingw32

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: cool...@qq.com





Revision: 192664

Host & Target: x86_64-w64-mingw32



/bin/sh ../../libtool --tag CXX --tag disable-shared   --mode=compile

/build/./gcc/xgcc -shared-libgcc -B/build/./gcc -nostdinc++

-L/build/x86_64-w64-mingw32/32/libstdc++-v3/src

-L/build/x86_64-w64-mingw32/32/libstdc++-v3/src/.libs

-L/gcc/x86_64-w64-mingw32/lib -L/gcc/mingw/lib -isystem

/gcc/x86_64-w64-mingw32/include -isystem /gcc/mingw/include

-B/gcc/x86_64-w64-mingw32/bin/ -B/gcc/x86_64-w64-mingw32/lib/ -isystem

/gcc/x86_64-w64-mingw32/include -isystem /gcc/x86_64-w64-mingw32/sys-include 

-m32 -I/gcc-svn/libstdc++-v3/../libgcc

-I/build/x86_64-w64-mingw32/32/libstdc++-v3/include/x86_64-w64-mingw32

-I/build/x86_64-w64-mingw32/32/libstdc++-v3/include

-I/gcc-svn/libstdc++-v3/libsupc++-fno-implicit-templates -Wall -Wextra

-Wwrite-strings -Wcast-qual -Wabi  -fdiagnostics-show-location=once  

-ffunction-sections -fdata-sections  -frandom-seed=complex_io.lo -g -O2  -m32 

-c -o complex_io.lo

../../../../../../gcc-svn/libstdc++-v3/src/c++98/complex_io.cc

libtool: compile:  /build/./gcc/xgcc -shared-libgcc -B/build/./gcc -nostdinc++

-L/build/x86_64-w64-mingw32/32/libstdc++-v3/src

-L/build/x86_64-w64-mingw32/32/libstdc++-v3/src/.libs

-L/gcc/x86_64-w64-mingw32/lib -L/gcc/mingw/lib -isystem

/gcc/x86_64-w64-mingw32/include -isystem /gcc/mingw/include

-B/gcc/x86_64-w64-mingw32/bin/ -B/gcc/x86_64-w64-mingw32/lib/ -isystem

/gcc/x86_64-w64-mingw32/include -isystem /gcc/x86_64-w64-mingw32/sys-include

-m32 -I/gcc-svn/libstdc++-v3/../libgcc

-I/build/x86_64-w64-mingw32/32/libstdc++-v3/include/x86_64-w64-mingw32

-I/build/x86_64-w64-mingw32/32/libstdc++-v3/include

-I/gcc-svn/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra

-Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once

-ffunction-sections -fdata-sections -frandom-seed=complex_io.lo -g -O2 -m32 -c

../../../../../../gcc-svn/libstdc++-v3/src/c++98/complex_io.cc -o complex_io.o

In file included from

../../../../../../gcc-svn/libstdc++-v3/src/c++98/complex_io.cc:25:0:

D:/MinGW/build/x86_64-w64-mingw32/32/libstdc++-v3/include/complex: In function

'std::basic_ostream<_CharT, _Traits>&

std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::complex<_Tp>&)

[with _Tp = float; _CharT = char; _Traits = std::char_traits]':

D:/MinGW/build/x86_64-w64-mingw32/32/libstdc++-v3/include/complex:529:5:

internal compiler error: Segmentation fault

 }

 ^

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

make[7]: *** [complex_io.lo] Error 1

make[7]: Leaving directory

`/build/x86_64-w64-mingw32/32/libstdc++-v3/src/c++98'

make[6]: *** [all-recursive] Error 1

make[6]: Leaving directory `/build/x86_64-w64-mingw32/32/libstdc++-v3/src'

make[5]: *** [all-recursive] Error 1

make[5]: Leaving directory `/build/x86_64-w64-mingw32/32/libstdc++-v3'

make[4]: *** [all] Error 2

make[4]: Leaving directory `/build/x86_64-w64-mingw32/32/libstdc++-v3'

make[3]: *** [multi-do] Error 1

make[3]: Leaving directory `/build/x86_64-w64-mingw32/libstdc++-v3'

make[2]: *** [all-multi] Error 2

make[2]: Leaving directory `/build/x86_64-w64-mingw32/libstdc++-v3'

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/build/x86_64-w64-mingw32/libstdc++-v3'

make: *** [all] Error 2





Reduced command line for prepocessed source:

/build/gcc/xgcc -B/build/gcc -O2 -m32 -c complex_io.cpp



Compiling at -O1 or -O2 triggers ICE.

[Bug target/55014] ICE: Segmentation fault while compiling complex_io.cc on x86_64-w64-mingw32

2012-10-21 Thread coolypf at qq dot com 


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



--- Comment #1 from coolypf  2012-10-22 01:09:01 UTC ---

Created attachment 28501

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28501

preprocessed source

[Bug plugins/47223] New: Fail to build gcc 4.6.0 (r168594) on mingw32

2011-01-07 Thread coolypf at qq dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47223

   Summary: Fail to build gcc 4.6.0 (r168594) on mingw32
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cool...@qq.com


configured with '--disable-shared'
so lto-plugin built as static library
when configuring target libgcc
failed with 'liblto_plugin-0.dll not found' error

I think there is something wrong with the option checking in gcc/gcc.c (line
6812)
LTOPLUGINSONAME is invalid when configured with '--disable-shared'
because there is no dynamic library

[Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32

2011-01-08 Thread coolypf at qq dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47223

--- Comment #3 from coolypf  2011-01-08 14:42:14 UTC ---
(In reply to comment #2)
> What is the failure?
> 
> Honza

when configuring target-libgcc,
failed with xgcc cannot create executable
config.log shows 'liblto_plugin-0.dll not found'
maybe -fuse-linker-plugin option not handled correctly

[Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32

2011-01-08 Thread coolypf at qq dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47223

--- Comment #5 from coolypf  2011-01-08 15:05:29 UTC ---
(In reply to comment #4)
> > when configuring target-libgcc,
> > failed with xgcc cannot create executable
> > config.log shows 'liblto_plugin-0.dll not found'
> > maybe -fuse-linker-plugin option not handled correctly
> 
> Yes, it seems that linker plugin handling on cygwin is not done well.
> Is linker plugin built for you and does the linker support it?
> 
> Honza

lto and linker plugin was OK in 20110101 snapshot
in which '-fuse-linker-plugin' was off by default
but in rev 168594, the option becomes on by default

this option causes checking LTOPLUGINSONAME in gcc/gcc.c (line
6812 around), which is not built with '--disable-shared'

something is wrong either with makefile or with gcc/gcc.c

[Bug lto/47241] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file'

2011-01-10 Thread coolypf at qq dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241

   Summary: lto not work on mingw32, reporting 'ld.exe: could not
unlink output file'
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cool...@qq.com


gcc 4.6.0 snapshot 20110108
compile following code with 'gcc-4 -v -flto test.c'

#include 
int main()
{
printf("Test\n");
return 0;
}

and get the following error message:

Using built-in specs.
COLLECT_GCC=D:\MinGW\bin\gcc-4.exe
COLLECT_LTO_WRAPPER=d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-4.6-20110108/configure --prefix=/gcc4
--program-suffix=-4 --with-gnu-as --with-gnu-ld --enable-threads
--disable-shared --disable-win32-registry --disable-werror --disable-nls
--disable-libquadmath --disable-bootstrap
Thread model: win32
gcc version 4.6.0 20110108 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-flto' '-mtune=generic' '-march=pentiumpro'
 d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/cc1.exe -quiet -v -iprefix
d:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.6.0/ test.c -quiet -dumpbase test.c
-mtune=generic -march=pentiumpro -auxbase test -version -flto -o
C:\Users\coolypf\AppData\Local\Temp\ccZ46Rlb.s
GNU C (GCC) version 4.6.0 20110108 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.6.0 20110101 (experimental), GMP version 5.0.1,
MPFR version 3.0.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"d:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/include"
ignoring duplicate directory
"d:/mingw/lib/gcc/../../lib/gcc/i686-pc-mingw32/4.6.0/include"
ignoring nonexistent directory "D:/MinGW/gcc4/include"
ignoring nonexistent directory "/gcc4/include"
ignoring duplicate directory
"d:/mingw/lib/gcc/../../lib/gcc/i686-pc-mingw32/4.6.0/include-fixed"
ignoring nonexistent directory
"d:/mingw/lib/gcc/../../lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/include"
ignoring duplicate directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 d:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.6.0/include
 d:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.6.0/../../../../include
 d:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.6.0/include-fixed
End of search list.
GNU C (GCC) version 4.6.0 20110108 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.6.0 20110101 (experimental), GMP version 5.0.1,
MPFR version 3.0.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: c752079cf4e558b53a88eee0a5828d49
COLLECT_GCC_OPTIONS='-v' '-flto' '-mtune=generic' '-march=pentiumpro'
 as -v -o C:\Users\coolypf\AppData\Local\Temp\cc0lkcdl.o
C:\Users\coolypf\AppData\Local\Temp\ccZ46Rlb.s
GNU assembler version 2.21.51 (i686-pc-mingw32) using BFD version (GNU
Binutils) 2.21.51.20110109
COMPILER_PATH=d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/;d:/mingw/bin/../libexec/gcc/
LIBRARY_PATH=d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/;d:/mingw/bin/../lib/gcc/;d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/../../../;/mingw/lib/
COLLECT_GCC_OPTIONS='-v' '-flto' '-mtune=generic' '-march=pentiumpro'
 d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/collect2.exe -plugin
d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/liblto_plugin-0.dll
-plugin-opt=d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/lto-wrapper.exe
-plugin-opt=-fresolution=C:\Users\coolypf\AppData\Local\Temp\ccAKIfIl.res
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex
-plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-ladvapi32
-plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32
-plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -flto
-Bdynamic d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/../../../crt2.o
d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/crtbegin.o
-Ld:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0 -Ld:/mingw/bin/../lib/gcc
-Ld:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/../../.. -L/mingw/lib
C:\Users\coolypf\AppData\Local\Temp\cc0lkcdl.o -lmingw32 -lgcc -lmoldname
-lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc
-lmoldname -lmingwex -lmsvcrt
d:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.6.0/crtend.o
 D:\MinGW\bin\gcc-4.exe @C:\Users\coolypf\AppData\Local\Temp\ccOgvLTl.args
Using built-in specs.
COLLECT_GCC=D:\MinGW\bin\gcc-4.exe
COLLECT_LTO_WRAPPER=d:/mingw/lib/gcc/../../libexec/gcc/i686-pc-mingw32/4.6.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-4.6-201

[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'

2011-01-10 Thread coolypf at qq dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241

--- Comment #1 from coolypf  2011-01-10 13:59:45 UTC ---
same problem on mingw-w64, with error message:


Using built-in specs.
COLLECT_GCC=D:\MinGW\bin\gcc64.exe
COLLECT_LTO_WRAPPER=d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.6-20110108/configure --prefix=/gcc4 --enable-threads
--disable-nls --disable-win32-registry --disable-werror --disable-shared
--disable-bootstrap --disable-multilib --disable-libquadmath
--with-ld=/x86_64-w64-mingw32/bin/ld --with-as=/x86_64-w64-mingw32/bin/as
--target=x86_64-w64-mingw32
Thread model: win32
gcc version 4.6.0 20110108 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-flto' '-mtune=generic' '-march=x86-64'
 d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/cc1.exe -quiet -v
-iprefix d:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/ test.c -quiet
-dumpbase test.c -mtune=generic -march=x86-64 -auxbase test -version -flto -o
C:\Users\coolypf\AppData\Local\Temp\ccWy8m2U.s
GNU C (GCC) version 4.6.0 20110108 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 4.6.0 20110108 (experimental), GMP version 5.0.1,
MPFR version 3.0.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"d:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/sys-include"
ignoring duplicate directory
"d:/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.6.0/include"
ignoring duplicate directory
"d:/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.6.0/include-fixed"
ignoring nonexistent directory
"d:/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/sys-include"
ignoring duplicate directory
"d:/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
 d:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/include
 d:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/include-fixed

d:\mingw\bin\../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/include
End of search list.
GNU C (GCC) version 4.6.0 20110108 (experimental) (x86_64-w64-mingw32)
compiled by GNU C version 4.6.0 20110108 (experimental), GMP version 5.0.1,
MPFR version 3.0.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 8be092602fa0cd5a35bfde8b7f46ede4
COLLECT_GCC_OPTIONS='-v' '-flto' '-mtune=generic' '-march=x86-64'

d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/bin/as.exe
-v -o C:\Users\coolypf\AppData\Local\Temp\ccc16uMR.o
C:\Users\coolypf\AppData\Local\Temp\ccWy8m2U.s
GNU assembler version 2.21.51 (x86_64-w64-mingw32) using BFD version (GNU
Binutils) 2.21.51.20110109
COMPILER_PATH=d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/;d:/mingw/bin/../libexec/gcc/;d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/bin/
LIBRARY_PATH=d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/;d:/mingw/bin/../lib/gcc/;d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib/../lib/;d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib/
COLLECT_GCC_OPTIONS='-v' '-flto' '-mtune=generic' '-march=x86-64'
 d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/collect2.exe -plugin
d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/liblto_plugin-0.dll
-plugin-opt=d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/lto-wrapper.exe
-plugin-opt=-fresolution=C:\Users\coolypf\AppData\Local\Temp\cckhpf6R.res
-plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex
-plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-ladvapi32
-plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32
-plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname
-plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -flto -m
i386pep -Bdynamic
d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o
d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib/../lib/crtbegin.o
-Ld:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0 -Ld:/mingw/bin/../lib/gcc
-Ld:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib/../lib
-Ld:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib
C:\Users\coolypf\AppData\Local\Temp\ccc16uMR.o -lmingw32 -lgcc -lmoldname
-lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc
-lmoldname -lmingwex -lmsvcrt
d:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.6.0/../../../../x86_64-w64-mingw32/lib/../lib/crtend.o
 D:\MinGW\bin\gcc64.exe @C:\Users\coolypf\AppData

[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'

2011-02-08 Thread coolypf at qq dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241

coolypf  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #3 from coolypf  2011-02-09 03:32:28 UTC ---
(In reply to comment #2)
> Hmm, this could be related to wrapper and file-removing there.
> 
> Does this patch fixes the issue you have?
> 
> Index: lto-plugin.c
> ===
> --- lto-plugin.c(revision 169926)
> +++ lto-plugin.c(working copy)
> @@ -660,12 +660,14 @@
>if (arguments_file_name)
>  {
>t = unlink (arguments_file_name);
> +  if (t != 0 && errno == ENOENT) t = 0;
>check (t == 0, LDPL_FATAL, "could not unlink arguments file");
>  }
> 
>for (i = 0; i < num_output_files; i++)
>  {
>t = unlink (output_files[i]);
> +  if (t != 0 && errno == ENOENT) t = 0;
>check (t == 0, LDPL_FATAL, "could not unlink output file");
>  }

It does not fix the problem.
But the following code WORKS:

if (t != 0 && errno == 13) t = 0;

Something related to unlink is not implemented in mingw.

[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'

2011-02-09 Thread coolypf at qq dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241

--- Comment #6 from coolypf  2011-02-09 12:54:46 UTC ---
(In reply to comment #5)
> So it seems to be an issue of lto and file-caching. There is a dangling
> file-handle, which can cause this issue.
> 
> Could you please test the following patch, if it solves the unlink issue?
> Please make sure that lto-plugin is unmodified version.
> 
> Thanks in advance,
> Kai
> 
> Index: lto.c
> ===
> --- lto.c(revision 169962)
> +++ lto.c(working copy)
> @@ -593,7 +593,11 @@
>fd_name = xstrdup (file_data->file_name);
>fd = open (file_data->file_name, O_RDONLY|O_BINARY);
>if (fd == -1)
> -return NULL;
> +{
> +  free (fd_name);
> +  fd_name = NULL;
> +  return NULL;
> +}
>  }
> 
>  #if LTO_MMAP_IO
> @@ -619,9 +623,17 @@
>|| read (fd, result, len) != (ssize_t) len)
>  {
>free (result);
> -  return NULL;
> +  result = NULL;
>  }
> -
> +#ifdef __MINGW32__
> +  /* Native windows doesn't supports delayed unlink on opened file. So
> + We close file here again. This produces higher I/O load, but at least
> + it prevents to have dangling file handles preventing unlink.  */
> +  free (fd_name);
> +  fd_name = NULL;
> +  close (fd);
> +  fd = -1;
> +#endif
>return result;
>  #endif
>  }

The patch does not take effect.
The errno before "could not unlink output file" message 
in lto-plugin.c is still 13.

[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'

2011-02-09 Thread coolypf at qq dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241

--- Comment #8 from coolypf  2011-02-09 13:50:15 UTC ---
(In reply to comment #7)
> So there seems to be another dangling file-handle on it ... you are sure new
> plugin was used by ld? Another thing of interest, is the file it tries to
> remove still existing or already removed, and if existing what access-rights 
> it
> has?

The filename is something like 'ccGQSy8u.ltrans0.ltrans.o'.
It still exists in TEMP dir.

The file is created by:

lto1.exe -quiet -dumpbase ccGQSy8u.ltrans0.o -mtune=generic -march=pentiumpro
-auxbase-strip ccGQSy8u.ltrans0.ltrans.o -version -fltrans @cckZmRUy -o
ccuOzyFX.s

as -v -o ccGQSy8u.ltrans0.ltrans.o ccuOzyFX.s

[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'

2011-02-09 Thread coolypf at qq dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241

--- Comment #9 from coolypf  2011-02-09 13:53:17 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > So there seems to be another dangling file-handle on it ... you are sure new
> > plugin was used by ld? Another thing of interest, is the file it tries to
> > remove still existing or already removed, and if existing what 
> > access-rights it
> > has?
> 
> The filename is something like 'ccGQSy8u.ltrans0.ltrans.o'.
> It still exists in TEMP dir.
> 
> The file is created by:
> 
> lto1.exe -quiet -dumpbase ccGQSy8u.ltrans0.o -mtune=generic -march=pentiumpro
> -auxbase-strip ccGQSy8u.ltrans0.ltrans.o -version -fltrans @cckZmRUy -o
> ccuOzyFX.s
> 
> as -v -o ccGQSy8u.ltrans0.ltrans.o ccuOzyFX.s

So, I don't think the bug is related to lto1.exe,
because it doesn't produce .o files.

[Bug middle-end/78879] New: -fprofile-generate causes undefined reference to `____ilog2_NaN'

2016-12-21 Thread coolypf at qq dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78879

Bug ID: 78879
   Summary: -fprofile-generate causes undefined reference to
`ilog2_NaN'
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coolypf at qq dot com
  Target Milestone: ---

Created attachment 40385
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40385&action=edit
test case

When building Linux kernel 3.10 for aarch64 with -fprofile-generate, I
encountered undefined reference to `ilog2_NaN'. Here are steps to
reproduce:

coolypf@experiment:~$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/aarch64-linux-gnu/6.2.1/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../gcc/configure --enable-languages=c --disable-threads
--disable-nls --disable-tls --disable-plugin --disable-bootstrap
--disable-werror --enable-cloog-backend=isl --disable-lto --enable-multiarch
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=aarch64-linux-gnu
Thread model: single
gcc version 6.2.1 20161221 (GCC)
coolypf@experiment:~$ aarch64-linux-gnu-gcc -c -O2 test.i
coolypf@experiment:~$ nm test.o | grep ilog2
coolypf@experiment:~$ aarch64-linux-gnu-gcc -c -O2 -fprofile-generate test.i
coolypf@experiment:~$ nm test.o | grep ilog2
 U ilog2_NaN

Related source code location is
http://lxr.free-electrons.com/source/drivers/scsi/sd.c?v=3.10#L2197

[Bug middle-end/78879] -fprofile-generate causes undefined reference to `____ilog2_NaN'

2016-12-21 Thread coolypf at qq dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78879

--- Comment #2 from Yuan Pengfei  ---
(In reply to Markus Trippelsdorf from comment #1)
> See discussion in PR72785.

I am using GCC 6.2.1. Is it the same problem?

[Bug middle-end/78879] -fprofile-generate causes undefined reference to `____ilog2_NaN'

2016-12-21 Thread coolypf at qq dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78879

--- Comment #5 from Yuan Pengfei  ---
(In reply to Markus Trippelsdorf from comment #3)
> (In reply to Yuan Pengfei from comment #2)
> > (In reply to Markus Trippelsdorf from comment #1)
> > > See discussion in PR72785.
> > 
> > I am using GCC 6.2.1. Is it the same problem?
> 
> Yes, I think so. The compiler is under no obligation to optimize the
> ilog2_NaN call away. It looks like a kernel bug.

I don't think so. In this case, the value of sector_size is constant (256, 512,
1024, 2048, 4096) and the ilog2_NaN call can be optimized away.

It is after enabling the -fprofile-generate option when the compiler thinks the
ilog2_NaN call can not be optimized away.

Reference source code:
http://lxr.free-electrons.com/source/drivers/scsi/sd.c?v=3.10#L2163

[Bug middle-end/78879] -fprofile-generate causes undefined reference to `____ilog2_NaN'

2016-12-21 Thread coolypf at qq dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78879

Yuan Pengfei  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 CC||law at redhat dot com
 Resolution|DUPLICATE   |---

--- Comment #7 from Yuan Pengfei  ---
After some binary search, I figure out that this bug is a regression since
r226516 .
Here are the related patches:
  https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01856.html
  https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00096.html

[Bug middle-end/78879] -fprofile-generate causes undefined reference to `____ilog2_NaN'

2016-12-21 Thread coolypf at qq dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78879

--- Comment #8 from Yuan Pengfei  ---
I have sent a patch that fixes this bug. Please review it. Thanks!

https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01824.html

[Bug middle-end/78879] -fprofile-generate causes undefined reference to `____ilog2_NaN'

2016-12-22 Thread coolypf at qq dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78879

Yuan Pengfei  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #10 from Yuan Pengfei  ---
(In reply to Jeffrey A. Law from comment #9)
> The posted patch is just papering over the problem by changing the iteration
> order of jump threads we examine.  Since realization of some jump threads
> will cause others to not be realized, changing the iteration order can cause
> different jump threads to be realized.
> 
> As discussed PR72785, this is a kernel bug in that the kernel code assumes
> that paths leading to a __builtin_object_size will not be
> duplicated/isolated.

The case in PR72785 is that a non-constant b_c_p argument turns into a constant
argument, which is a kernel bug as you have discussed.

But the case here is that a constant, non-zero b_c_p argument (sector_size)
turns into a constant, maybe-zero argument. Therefore, I think this is a
compiler bug.

I don't know much about how jump threading interacts with profile
instrumentation. But keeping the original iteration order does fix this
particular bug.

[Bug middle-end/78879] -fprofile-generate causes undefined reference to `____ilog2_NaN'

2016-12-22 Thread coolypf at qq dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78879

--- Comment #11 from Yuan Pengfei  ---
It seems that if a variable has two or more constant values, gcc does not treat
it as a constant and b_c_p returns 0. Is that correct?

If so, I might have figured out where the problem is.

With unordered_remove, the case is:

sector_size {256, 512, 1024, 2048, 4096}
  |
  +---+---+ ...
  | {256} | {512}
b_c_p   b_c_p
  |   |
  +---+
  | b_c_p == 1
"calculations for constant sector_size"

In "calculations for constant sector_size", sector_size has two or more
constant values, making gcc not treat it as a constant. Therefore, the call to
ilog2_NaN is not optimized away.

With ordered_remove, the case is:

sector_size {256, 512, 1024, 2048, 4096}
  |
  +---+ ...
  | {256, 512}
b_c_p
  | b_c_p == 0
"calculations for non-constant sector_size"

The call to ilog2_NaN is optimized away with "calculations for constant
sector_size".

[Bug gcov-profile/68025] New: pragma/attribute optimize("profile-arcs") does not work as intended

2015-10-19 Thread coolypf at qq dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68025

Bug ID: 68025
   Summary: pragma/attribute optimize("profile-arcs") does not
work as intended
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coolypf at qq dot com
  Target Milestone: ---

Case 1. The following code, when compiled, both x and y are instrumented:

#pragma GCC push_options
#pragma GCC optimize("profile-arcs")

int x(int p)
{
if (p > 0) return 1;
return 0;
}

#pragma GCC pop_options

int y(int q)
{
if (q < 0) return 0;
return 1;
}


Case 2. The following code, when compiled, both x and y are instrumented:

int x(int) __attribute__ ((optimize("profile-arcs")));

int x(int p)
{
if (p > 0) return 1;
return 0;
}

int y(int q)
{
if (q < 0) return 0;
return 1;
}


Case 3. The following code, when compiled, both x and y are instrumented:

int x(int p)
{
if (p > 0) return 1;
return 0;
}

#pragma GCC push_options
#pragma GCC optimize("profile-arcs")

int y(int q)
{
if (q < 0) return 0;
return 1;
}

#pragma GCC pop_options


Case 4. The following code, when compiled, both x and y are instrumented:

int x(int p)
{
if (p > 0) return 1;
return 0;
}

int y(int) __attribute__ ((optimize("profile-arcs")));

int y(int q)
{
if (q < 0) return 0;
return 1;
}

[Bug gcov-profile/68025] pragma/attribute optimize("profile-arcs") does not work as intended

2015-10-20 Thread coolypf at qq dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68025

--- Comment #2 from Yuan Pengfei  ---
(In reply to Richard Biener from comment #1)
> Confirmed.  profile-arcs is not supposed to be used in optimize pragmas or
> attributes and GCC should emit an error here but somehow it does not.

If so, how can I achieve function-level instrumentation control?

[Bug c++/48569] internal compiler error: in build_zero_init_1, at cp/init.c:278

2011-04-18 Thread coolypf at qq dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48569

coolypf  changed:

   What|Removed |Added

 CC||coolypf at qq dot com

--- Comment #3 from coolypf  2011-04-18 11:52:21 UTC ---
(In reply to comment #2)
> Created attachment 23966 [details]
> pr48569.ii
> 
> Slightly reduced testcase.

This test fails on MinGW

g++-svn -v
Using built-in specs.
COLLECT_GCC=D:\MinGW\bin\g++-svn.exe
COLLECT_LTO_WRAPPER=d:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.7.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-svn/configure --prefix=/gcc4 --program-suffix=-svn
--enable-threads --disable-nls --disable-win32-registry --disable-werror
--disable-shared --disable-bootstrap --build=x86_64-w64-mingw32
--target=i686-pc-mingw32 --enable-languages=c,c++ --disable-libquadmath
--with-as=/i686-pc-mingw32/bin/as --with-ld=/i686-pc-mingw32/bin/ld
Thread model: win32
gcc version 4.7.0 20110418 (experimental) (GCC)

g++-svn -c pr48569.cpp
pr48569.cpp: In member function 'last_value< 
>::result_type last_value< 
>::operator()(InputIterator, InputIterator) [with InputIterator =
slot_call_iterator::caller >,
named_slot_map_iterator>,  = void, last_value<
 >::result_type = void]':
pr48569.cpp:25:432:   instantiated from 'signal0, SlotFunction>::result_type signal0, SlotFunction>::operator()() [with R = void,
Combiner = last_value, Group = function, 
= less >, SlotFunction = function0, signal0, SlotFunction>::result_type = void]'
pr48569.cpp:31:36:   instantiated from here
pr48569.cpp:12:158: internal compiler error: in build_zero_init_1, at
cp/init.c:277
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug gcov-profile/68025] pragma/attribute optimize("profile-arcs") does not work as intended

2016-07-26 Thread coolypf at qq dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68025

--- Comment #5 from Yuan Pengfei  ---
(In reply to Martin Liška from comment #4)
> May I please ask you for motivation of having such a control?

Some functions in the Linux kernel, when instrumented, may cause boot failure.

Therefore, fine-grained instrumentation control is needed.