public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop Date: Tue, 11 Sep 2007 17:21:00 -0000 [thread overview] Message-ID: <20070911172124.19843.qmail@sourceware.org> (raw) In-Reply-To: <bug-33136-12956@http.gcc.gnu.org/bugzilla/> ------- Comment #27 from jakub at gcc dot gnu dot org 2007-09-11 17:21 ------- Created an attachment (id=14191) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14191&action=view) gcc43-pr33136.patch Updated patch which tries to handle SFTs as well. Unfortunately it causes a regression with gcc.dg/torture/pr26587.c at -O2 and above. That to me looks like an ipa-type-escape.c bug. In particular, may_alias_p is now called with a SFT whose type is ARRAY_TYPE. The first argument to ipa_type_escape_does_not_clobber_p is <record_type 0x2aaaaea4f1a0 type_0 BLK size <integer_cst 0x2aaaae941b40 type <integer_type 0x2aaaae9340d0 bit_size_type> constant invariant 576> unit size <integer_cst 0x2aaaaea4e150 type <integer_type 0x2aaaae934000 long unsigned int> constant invariant 72> align 32 symtab 0 alias set -1 canonical type 0x2aaaaea4f1a0 fields <field_decl 0x2aaaae9f10b0 P type <array_type 0x2aaaaea4f0d0 BF_key type <integer_type 0x2aaaaea39a90 BF_word> BLK size <integer_cst 0x2aaaae941b40 576> unit size <integer_cst 0x2aaaaea4e150 72> align 32 symtab 0 alias set -1 canonical type 0x2aaaaea39ea0 domain <integer_type 0x2aaaaea39b60> pointer_to_this <pointer_type 0x2aaaaea4f410>> BLK file pr26587.c line 8 size <integer_cst 0x2aaaae941b40 576> unit size <integer_cst 0x2aaaaea4e150 72> align 32 offset_align 128 offset <integer_cst 0x2aaaae925750 constant invariant 0> bit offset <integer_cst 0x2aaaae9413f0 constant invariant 0> context <record_type 0x2aaaaea4f1a0>> context <translation_unit_decl 0x2aaaaea4f750 D.1521> pointer_to_this <pointer_type 0x2aaaaea4f820> chain <type_decl 0x2aaaaea4f270 D.1500>> and the second is <array_type 0x2aaaaea4f0d0 BF_key type <integer_type 0x2aaaaea39a90 BF_word sizes-gimplified public unsigned SI size <integer_cst 0x2aaaae925ab0 constant invariant 32> unit size <integer_cst 0x2aaaae925720 constant invariant 4> align 32 symtab 0 alias set -1 canonical type 0x2aaaae934680 precision 32 min <integer_cst 0x2aaaae925ae0 0> max <integer_cst 0x2aaaae925a80 4294967295> pointer_to_this <pointer_type 0x2aaaaea39d00>> BLK size <integer_cst 0x2aaaae941b40 type <integer_type 0x2aaaae9340d0 bit_size_type> constant invariant 576> unit size <integer_cst 0x2aaaaea4e150 type <integer_type 0x2aaaae934000 long unsigned int> constant invariant 72> align 32 symtab 0 alias set -1 canonical type 0x2aaaaea39ea0 domain <integer_type 0x2aaaaea39b60 type <integer_type 0x2aaaae934000 long unsigned int public unsigned sizetype DI size <integer_cst 0x2aaaae925ba0 constant invariant 64> unit size <integer_cst 0x2aaaae925bd0 constant invariant 8> align 64 symtab 0 alias set -1 canonical type 0x2aaaae942270 precision 64 min <integer_cst 0x2aaaae925c00 0> max <integer_cst 0x2aaaae9414e0 -1>> public DI size <integer_cst 0x2aaaae925ba0 64> unit size <integer_cst 0x2aaaae925bd0 8> align 64 symtab 0 alias set -1 canonical type 0x2aaaaea39b60 precision 64 min <integer_cst 0x2aaaae925750 0> max <integer_cst 0x2aaaaea4e090 17>> pointer_to_this <pointer_type 0x2aaaaea4f410>> ipa_type_escape_field_does_not_clobber_p calls get_canon_type_uid (, true, true) on this, which returns TYPE_UID of an unsigned int. But if I check what actually mark_interesting_addressof marked, it is TYPE_UID of a different ARRAY_TYPE - <array_type 0x2aaaaea39c30 type <integer_type 0x2aaaaea39a90 BF_word sizes-gimplified public unsigned SI size <integer_cst 0x2aaaae925ab0 constant invariant 32> unit size <integer_cst 0x2aaaae925720 constant invariant 4> align 32 symtab 0 alias set -1 canonical type 0x2aaaae934680 precision 32 min <integer_cst 0x2aaaae925ae0 0> max <integer_cst 0x2aaaae925a80 4294967295> pointer_to_this <pointer_type 0x2aaaaea39d00>> BLK size <integer_cst 0x2aaaae941b40 type <integer_type 0x2aaaae9340d0 bit_size_type> constant invariant 576> unit size <integer_cst 0x2aaaaea4e150 type <integer_type 0x2aaaae934000 long unsigned int> constant invariant 72> align 32 symtab 0 alias set 2 canonical type 0x2aaaaea39ea0 domain <integer_type 0x2aaaaea39b60 type <integer_type 0x2aaaae934000 long unsigned int public unsigned sizetype DI size <integer_cst 0x2aaaae925ba0 constant invariant 64> unit size <integer_cst 0x2aaaae925bd0 constant invariant 8> align 64 symtab 0 alias set -1 canonical type 0x2aaaae942270 precision 64 min <integer_cst 0x2aaaae925c00 0> max <integer_cst 0x2aaaae9414e0 -1>> public DI size <integer_cst 0x2aaaae925ba0 64> unit size <integer_cst 0x2aaaae925bd0 8> align 64 symtab 0 alias set -1 canonical type 0x2aaaaea39b60 precision 64 min <integer_cst 0x2aaaae925750 0> max <integer_cst 0x2aaaaea4e090 17>>> so very different uid, and nothing actually ensures that if this type has been marked that e.g. what it sees through has been marked as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
next prev parent reply other threads:[~2007-09-11 17:21 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-08-21 12:23 [Bug regression/33136] New: -Os generated code grew almost twice 4.2.1 versus 4.1.1 vda dot linux at googlemail dot com 2007-08-21 12:24 ` [Bug regression/33136] " vda dot linux at googlemail dot com 2007-08-21 12:26 ` vda dot linux at googlemail dot com 2007-08-21 12:27 ` vda dot linux at googlemail dot com 2007-08-21 13:11 ` rguenth at gcc dot gnu dot org 2007-08-21 13:12 ` [Bug tree-optimization/33136] [4.2/4.3 Regression] " rguenth at gcc dot gnu dot org 2007-08-21 16:20 ` pinskia at gcc dot gnu dot org 2007-08-22 13:27 ` jakub at gcc dot gnu dot org 2007-08-22 13:55 ` jakub at gcc dot gnu dot org 2007-08-22 13:57 ` jakub at gcc dot gnu dot org 2007-08-22 14:20 ` rguenth at gcc dot gnu dot org 2007-08-22 14:29 ` jakub at gcc dot gnu dot org 2007-08-22 15:15 ` [Bug tree-optimization/33136] [4.1/4.2/4.3 " rguenth at gcc dot gnu dot org 2007-08-22 15:53 ` [Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop dberlin at gcc dot gnu dot org 2007-08-22 17:24 ` jakub at gcc dot gnu dot org 2007-08-22 20:10 ` dberlin at gcc dot gnu dot org 2007-08-23 12:13 ` jakub at gcc dot gnu dot org 2007-08-23 13:45 ` dberlin at dberlin dot org 2007-08-23 14:49 ` jakub at redhat dot com 2007-08-23 17:09 ` dberlin at dberlin dot org 2007-08-24 15:39 ` jakub at gcc dot gnu dot org 2007-08-24 15:42 ` dberlin at dberlin dot org 2007-08-24 16:17 ` jakub at gcc dot gnu dot org 2007-08-24 16:21 ` dberlin at dberlin dot org 2007-08-24 16:37 ` jakub at gcc dot gnu dot org 2007-09-05 1:09 ` mmitchel at gcc dot gnu dot org 2007-09-05 5:47 ` jakub at gcc dot gnu dot org 2007-09-11 17:21 ` jakub at gcc dot gnu dot org [this message] 2007-09-11 19:26 ` jakub at gcc dot gnu dot org 2007-09-11 19:52 ` jakub at gcc dot gnu dot org 2007-09-28 4:02 ` mmitchel at gcc dot gnu dot org 2007-10-15 18:30 ` jakub at gcc dot gnu dot org 2007-10-15 18:52 ` [Bug tree-optimization/33136] [4.1/4.2 " jakub at gcc dot gnu dot org 2008-07-04 22:16 ` [Bug tree-optimization/33136] [4.2 " jsm28 at gcc dot gnu dot org 2009-03-30 22:17 ` jsm28 at gcc dot gnu dot 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=20070911172124.19843.qmail@sourceware.org \ --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: linkBe 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).