: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: ibhagatgnu at gmail dot com
Target Milestone: ---
Noticed this ICE (in gmp) when bootstrapping GCC with -gbtf as an experiment.
Program received signal SIGSEGV, Segmentation fault.
0x00ce775c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283
--- Comment #20 from Indu Bhagat ---
Commit https://gcc.gnu.org/g:f007a638a86e4b59bef0a0d8efa5bb8c5e5b200a added
support for targets to opt out of CTF/BTF support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101269
Indu Bhagat changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102195
--- Comment #2 from Indu Bhagat ---
(In reply to Andrew Pinski from comment #1)
> I think this is a dup of bug 8354.
Possible. It looks like two distinct symptoms, but seem to be originating from
the same underlying issue. I don't have enough
: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: ibhagatgnu at gmail dot com
Target Milestone: ---
$ cat typedef1.c
typedef int A[2][3];
const A a = {{4, 5, 6}, {7, 8, 9}};
$ gcc -g -c typedef1.c
$ objdump --dwarf=info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101321
Indu Bhagat changed:
What|Removed |Added
CC||ibhagatgnu at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283
--- Comment #18 from Indu Bhagat ---
(In reply to Richard Biener from comment #4)
> It might make sense to provide targets a means to opt-out of CTF/BTF support
> and thus diagnose -gctf as unsupported on them.
Yes, I agree. It makes sense to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283
--- Comment #14 from Indu Bhagat ---
With the two patches (commit r12-2044-ga3543b5e8002c033b2304d7ac1d1e58218eebb51
+ the other in review) only two further failures remain to be looked into:
FAIL: gcc.dg/debug/btf/btf-bitfields-3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283
--- Comment #12 from Indu Bhagat ---
The intention is to be able to generate CTF/BTF correctly irrespective of the
DWARF version.
The case of DW_TAG_restrict_type is unique though, and looks like we will need
special handling. To be specific,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283
--- Comment #10 from Indu Bhagat ---
(In reply to Iain Sandoe from comment #9)
> (In reply to Iain Sandoe from comment #8)
> > we are now left with (where I suspect that the remaining fails are an
> > artefact of the way in which Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283
Indu Bhagat changed:
What|Removed |Added
CC||ibhagatgnu at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101269
--- Comment #1 from Indu Bhagat ---
Confirmed. This is reproducible with -m32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100749
--- Comment #2 from Indu Bhagat ---
I found the issue. I will send a fix soon, once testing on powerpc64, x86_64
finishes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100749
--- Comment #1 from Indu Bhagat ---
Thanks for the bug report. This is reproducible. Will look into it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86957
--- Comment #5 from Indu Bhagat ---
Proposed patch https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00367.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86957
--- Comment #3 from Indu Bhagat ---
Currently, GCC dumps some information in the dump files regarding functions not
being executed in the training run (And, I agree its not satisfactorily
direct).
First, in the "Symbol table:" dump section in
Keywords: diagnostic
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ibhagatgnu at gmail dot com
CC: mliska at suse dot cz
Target Milestone: ---
When using -fprofile-use
17 matches
Mail list logo
