public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target
Date: Tue, 19 Feb 2013 21:10:00 -0000 [thread overview]
Message-ID: <bug-56265-4-AbGpE11GB6@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-56265-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265
--- Comment #8 from Jan Hubicka <hubicka at ucw dot cz> 2013-02-19 21:09:54 UTC ---
>
Hi,
the patch seems to work well for Mozilla. There are two issues I noticed while
testing it
1) we now enable-checking ICE on cgraph_mark_address_taken when compiling
Mozilla with FDO.
It is independent problem I was looking into for good part of day today. In
fact we need
to do similar excercise when this happen, but I wil handle this
incrementally.
It is WHOPR only bug.
2) The warning about calling a non-function surprisingly triggers few times
during Mozilla.
The values are constants:
<integer_cst 0x7f1ef4a69c20 type <pointer_type 0x7f1f05d0e9d8
hb_destroy_func_t> constant 0>
<integer_cst 0x7f204342bb00 type <pointer_type 0x7f1fee1d9a80> constant 33>
<integer_cst 0x7f204342ba40 type <pointer_type 0x7f1fee1d9a80> constant 81>
<integer_cst 0x7f1ffcb795a0 type <pointer_type 0x7f1fea0a4a80> constant 113>
<integer_cst 0x7f1ffcb795a0 type <pointer_type 0x7f1fea0a4a80> constant 113>
<integer_cst 0x7f1ffe6bca00 type <pointer_type 0x7f1fea0a4a80> constant 121>
<integer_cst 0x7f1ffe6bca00 type <pointer_type 0x7f1fea0a4a80> constant 121>
<integer_cst 0x7f204342baa0 type <pointer_type 0x7f1fee1d9930> constant 49>
<integer_cst 0x7f1ef4a69c20 type <pointer_type 0x7f1f05d0e9d8
hb_destroy_func_t> constant 0>
<integer_cst 0x7f1fdc69e8e0 type <pointer_type 0x7f1fd938ad20> constant 0>
<integer_cst 0x7f1fdc69e8e0 type <pointer_type 0x7f1fd938ad20> constant 0>
<integer_cst 0x7f202b5d5160 type <pointer_type 0x7f1ff919fc78 JSErrorCallback>
constant 0>
<integer_cst 0x7f1ffe6bca00 type <pointer_type 0x7f1fea0a4a80> constant 121>
<integer_cst 0x7f1ffe6bca00 type <pointer_type 0x7f1fea0a4a80> constant 121>
<integer_cst 0x7f1ffcb795a0 type <pointer_type 0x7f1fea0a4a80> constant 113>
<integer_cst 0x7f1ffcb795a0 type <pointer_type 0x7f1fea0a4a80> constant 113>
<integer_cst 0x7f202b5d5160 type <pointer_type 0x7f1ff919fc78 JSErrorCallback>
constant 0>
<integer_cst 0x7f204342b940 type <pointer_type 0x7f1fee1d9930> constant 97>
<integer_cst 0x7f1fba8e12c0 type <pointer_type 0x7f20353fc540> constant 25>
<integer_cst 0x7f1fba8e1680 type <pointer_type 0x7f20353fc540> constant 33>
<integer_cst 0x7f1ef4a69c20 type <pointer_type 0x7f1f05d0e9d8
hb_destroy_func_t> constant 0>
<integer_cst 0x7f1f180634e0 type <pointer_type 0x7f1edda427e0 LookupGenericOp>
constant 0>
<integer_cst 0x7f1fb28978e0 type <pointer_type 0x7f207af33c78
nsMallocSizeOfFun> constant 0>
<integer_cst 0x7f1fb28978e0 type <pointer_type 0x7f207af33c78
nsMallocSizeOfFun> constant 0>
<integer_cst 0x7f1fa8ab4780 type <pointer_type 0x7f2078d86bd0 InitDataFunc>
constant 0>
<integer_cst 0x7f204e3d0880 type <pointer_type 0x7f1fee180540> constant 201>
<integer_cst 0x7f1fbafd5a60 type <pointer_type 0x7f1ef3fc9498> constant 0>
<integer_cst 0x7f1fe63de860 type <pointer_type 0x7f205716f9d8 destroyOp>
constant 0>
<integer_cst 0x7f1fe63de860 type <pointer_type 0x7f205716f9d8 destroyOp>
constant 0>
<integer_cst 0x7f1ef4a69c20 type <pointer_type 0x7f1f05d0e9d8
hb_destroy_func_t> constant 0>
<integer_cst 0x7f1ef4a69c20 type <pointer_type 0x7f1f05d0e9d8
hb_destroy_func_t> constant 0>
<integer_cst 0x7f1ef4a69c20 type <pointer_type 0x7f1f05d0e9d8
hb_destroy_func_t> constant 0>
<integer_cst 0x7f1ef4a69c20 type <pointer_type 0x7f1f05d0e9d8
hb_destroy_func_t> constant 0>
<integer_cst 0x7f20471da2c0 type <pointer_type 0x7f1fee1d9000> constant 161>
Martin, for 4.9 we can probably turn call to NULL into builtin_trap or
builtin_unreachable (not
sure if the second is fine, but it would result in better code).
I wonder however from where the non-NULL constants are comming? Isn't it some
bug in ipa-prop
that picks complete garbage? That may be possible wrong code issue...
I will commit patch tomorrow morning.
Honza
next prev parent reply other threads:[~2013-02-19 21:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-09 16:51 [Bug tree-optimization/56265] New: " jakub at gcc dot gnu.org
2013-02-09 16:52 ` [Bug tree-optimization/56265] " jakub at gcc dot gnu.org
2013-02-10 18:46 ` ppluzhnikov at google dot com
2013-02-11 16:20 ` jakub at gcc dot gnu.org
2013-02-12 0:48 ` ppluzhnikov at google dot com
2013-02-12 17:25 ` hubicka at ucw dot cz
2013-02-13 17:16 ` aldyh at gcc dot gnu.org
2013-02-18 14:28 ` jakub at gcc dot gnu.org
2013-02-19 6:46 ` hubicka at ucw dot cz
2013-02-19 21:10 ` hubicka at ucw dot cz [this message]
2013-02-20 15:48 ` hubicka at gcc dot gnu.org
2013-02-20 21:01 ` hubicka at gcc dot gnu.org
2013-04-25 17:27 ` jamborm at gcc dot gnu.org
2013-04-25 20:52 ` hubicka at ucw dot cz
2013-05-15 10:40 ` jamborm at gcc dot gnu.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-56265-4-AbGpE11GB6@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).