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
S
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
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: una
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 -f
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 o
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
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
coolypf changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
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, i
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 st
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 t
ormal
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
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?
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78879
Yuan Pengfei changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
CC|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78879
Yuan Pengfei changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
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_re
ty: 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 optimiz
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48569
coolypf changed:
What|Removed |Added
CC||coolypf at qq dot com
--- Comment #3 from
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-grain
22 matches
Mail list logo
