[Bug middle-end/78879] -fprofile-generate causes undefined reference to `____ilog2_NaN'
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 middle-end/78879] -fprofile-generate causes undefined reference to `____ilog2_NaN'
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'
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'
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'
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'
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] New: -fprofile-generate causes undefined reference to `____ilog2_NaN'
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=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 gcov-profile/68025] pragma/attribute optimize("profile-arcs") does not work as intended
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.
[Bug gcov-profile/68025] pragma/attribute optimize("profile-arcs") does not work as intended
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 gcov-profile/68025] New: pragma/attribute optimize("profile-arcs") does not work as intended
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 target/55014] New: ICE: Segmentation fault while compiling complex_io.cc on x86_64-w64-mingw32
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_traitschar]': 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 http://gcc.gnu.org/bugs.html 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55014 --- Comment #1 from coolypf coolypf at qq dot com 2012-10-22 01:09:01 UTC --- Created attachment 28501 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28501 preprocessed source
[Bug c++/48569] internal compiler error: in build_zero_init_1, at cp/init.c:278
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48569 coolypf coolypf at qq dot com changed: What|Removed |Added CC||coolypf at qq dot com --- Comment #3 from coolypf coolypf at qq dot com 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 template-parameter-1-1 ::result_type last_value template-parameter-1-1 ::operator()(InputIterator, InputIterator) [with InputIterator = slot_call_iteratorcall_bound0void::callerfunction0void , named_slot_map_iterator, template-parameter-1-1 = void, last_value template-parameter-1-1 ::result_type = void]': pr48569.cpp:25:432: instantiated from 'signal0R, Combiner, Group, template-parameter-1-4, SlotFunction::result_type signal0R, Combiner, Group, template-parameter-1-4, SlotFunction::operator()() [with R = void, Combiner = last_valuevoid, Group = functionvoid(), template-parameter-1-4 = lessfunctionvoid() , SlotFunction = function0void, signal0R, Combiner, Group, template-parameter-1-4, 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 lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #6 from coolypf coolypf at qq dot com 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'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241 --- Comment #8 from coolypf coolypf at qq dot com 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'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241 --- Comment #9 from coolypf coolypf at qq dot com 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 lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
coolypf coolypf at qq dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution||FIXED
--- Comment #3 from coolypf coolypf at qq dot com 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] New: lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
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 stdio.h
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:
[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241 --- Comment #1 from coolypf coolypf at qq dot com 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
[Bug plugins/47223] Fail to build gcc 4.6.0 (r168594) on mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47223 --- Comment #3 from coolypf coolypf at qq dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47223 --- Comment #5 from coolypf coolypf at qq dot com 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 plugins/47223] New: Fail to build gcc 4.6.0 (r168594) on mingw32
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
