https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683
--- Comment #14 from ian at gcc dot gnu.org ---
Author: ian
Date: Fri Apr 17 21:29:20 2015
New Revision: 00
URL: https://gcc.gnu.org/viewcvs?rev=00&root=gcc&view=rev
Log:
PR go/64683
runtime/pprof: Assume function with no name is in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64683
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65798
--- Comment #1 from Ian Lance Taylor ---
The libgo code actually follows the lead of the gc code here. The 1.3 code, in
C, said this:
} else if((f = runtime·findfunc(rpc[1])) == nil) {
retfile = runtime·emptystring;
retline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65798
--- Comment #2 from Ian Lance Taylor ---
I don't see it as a good idea to ignore an empty file name, but I'm fine with
ignoring a 0 PC, so that is what I will implement. Though I am definitely
curious how they got a 0 PC from runtime.Caller.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #43 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Fri Apr 17 21:54:22 2015
New Revision: 01
URL: https://gcc.gnu.org/viewcvs?rev=01&root=gcc&view=rev
Log:
Don't define ix86_binds_local_p for MacOS nor Windows
PR targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #44 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Fri Apr 17 21:55:05 2015
New Revision: 02
URL: https://gcc.gnu.org/viewcvs?rev=02&root=gcc&view=rev
Log:
Don't define ix86_binds_local_p for MacOS nor Windows
PR targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65798
--- Comment #3 from ian at gcc dot gnu.org ---
Author: ian
Date: Fri Apr 17 21:58:58 2015
New Revision: 03
URL: https://gcc.gnu.org/viewcvs?rev=03&root=gcc&view=rev
Log:
PR go/65798
runtime: In Caller don't return ok == true if PC ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65798
--- Comment #4 from ian at gcc dot gnu.org ---
Author: ian
Date: Fri Apr 17 21:59:10 2015
New Revision: 04
URL: https://gcc.gnu.org/viewcvs?rev=04&root=gcc&view=rev
Log:
PR go/65798
runtime: In Caller don't return ok == true if PC ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65798
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787
--- Comment #9 from Bill Schmidt ---
Author: wschmidt
Date: Fri Apr 17 22:05:12 2015
New Revision: 05
URL: https://gcc.gnu.org/viewcvs?rev=05&root=gcc&view=rev
Log:
[gcc]
2015-04-17 Bill Schmidt
PR target/65787
* config/rs60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65797
--- Comment #3 from Jan Hubicka ---
Hi,
the ICF wrapper are created same way as thunks (by expand_thunk) which probably
suppress debug info because we do not want to see it for thunks. I suppose it
is:
DECL_IGNORED_P (thunk_fndecl) = 1
I suppose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65792
--- Comment #3 from Dominique d'Humieres ---
> Created attachment 35346 [details]
> draft patch, untested
The patch fixes the PR, but causes
FAIL: gfortran.dg/class_19.f03 -O0 execution test
FAIL: gfortran.dg/class_19.f03 -O1 execution te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65792
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65797
--- Comment #4 from Ian Lance Taylor ---
I think we should have a goal of making backtraces always work. I don't know
why we would ever want backtraces to fail. Every function should have a name
and a file name. I can accept that in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65797
--- Comment #5 from Jan Hubicka ---
Well, if you turn one function to alias of another, there is no way to preserve
it (like Gold's ICF doesn't). With dwarf extensions we can restore some of the
info based on context where the function is called,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65797
--- Comment #6 from Jan Hubicka ---
The following untested patch could help. We may need to set location of the
debug statement
etc. I probably won't be able to do much more on this till Monday evening
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65797
--- Comment #7 from Ian Lance Taylor ---
With gold's ICF, as I understand it, there is a function name and file/line
information for every function in the backtrace. It may not be the name or the
file/line info you expect, but it's there.
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
Jack Howarth changed:
What|Removed |Added
CC||howarth.at.gcc at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65799
Bug ID: 65799
Summary: Allows constexpr coversion from cv void * to other
type
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65797
--- Comment #8 from Jan Hubicka ---
> With gold's ICF, as I understand it, there is a function name and file/line
> information for every function in the backtrace. It may not be the name or
> the
ICF does not do the wrappers as far as I know.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
Jakub Jelinek changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
101 - 122 of 122 matches
Mail list logo
