public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
To: Jan Hubicka <hubicka@ucw.cz>
Cc: Richard Biener <richard.guenther@gmail.com>,
	       GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags
Date: Mon, 26 May 2014 13:03:00 -0000	[thread overview]
Message-ID: <yddvbssn14a.fsf@lokon.CeBiTec.Uni-Bielefeld.DE> (raw)
In-Reply-To: <20140524073913.GA27708@kam.mff.cuni.cz> (Jan Hubicka's message	of "Sat, 24 May 2014 09:39:14 +0200")

[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]

Jan Hubicka <hubicka@ucw.cz> writes:

>> I'm fine with enlarging tree_function_decl for now - ideally we'd push
>> stuff from it elsewhere (like target and optimization option tree nodes,
>> or most of the visibility and symbol related stuff).  Not sure why
>> tree_type_decl inherits from tree_decl_non_common (and thus
>> tree_decl_with_vis).  Probably because of the non-common parts
>> being (ab-)used by FEs.  Otherwise I'd say simply put a symtab
>> node pointer into tree_decl_with_vis ... (can we move
>> section_name and comdat_group more easily than assembler_name?)
>
> Hi,
> this patch removes comdat_group pointer and adds direct symtab pointer.  As
> expected, the change is not completely easy. The main uglyness in C++'s version
> of duplicate_decl that creates a duplicated decl with duplicated symtab node
> now and needs to remove it.  Other problem is copy_node and c's duplicate_decl
> that does memcpy on a node and thus also copie the symtab pointer that is not
> the right thing to do.
>
> On the other hand on middle-end side several things simplify, so I think overall
> the approach works relatively well.
>
> I have bootstrapped/regtested x86_64-linux and I plan to give it more testing
> tomorrow and commit if there are no complains.  Incrementally I would like then
> to cleanup way the decl_with_vis.symtab_node pointer is maintained.  I do not
> want to allow users to tamper with it, so I did not make accessor macro for
> it, however there are more direct uses than I would like: I will need to figure
> out how to reduce those.

This patch broke Solaris bootstrap:

/vol/gcc/src/hg/trunk/local/gcc/config/sol2.c: In function 'void solaris_elf_asm_comdat_section(const char*, unsigned int, tree)':
/vol/gcc/src/hg/trunk/local/gcc/config/sol2.c:213:17: error: 'decl_comdat_group' was not declared in this scope
/vol/gcc/src/hg/trunk/local/gcc/config/sol2.c: In function 'int solaris_define_comdat_signature(comdat_entry**, void*)':
/vol/gcc/src/hg/trunk/local/gcc/config/sol2.c:267:12: error: 'decl_comdat_group' was not declared in this scope

The following snippet allows a sparc-sun-solaris2.11 bootstrap to go
along further, only to break again later in libjava for what seems to be
unrelated reasons.

2014-05-26  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	* config/sol2.c: Include cgraph.h.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: sol2.patch --]
[-- Type: text/x-patch, Size: 332 bytes --]

diff --git a/gcc/config/sol2.c b/gcc/config/sol2.c
--- a/gcc/config/sol2.c
+++ b/gcc/config/sol2.c
@@ -32,6 +32,7 @@ along with GCC; see the file COPYING3.  
 #include "diagnostic-core.h"
 #include "ggc.h"
 #include "hash-table.h"
+#include "cgraph.h"
 
 tree solaris_pending_aligns, solaris_pending_inits, solaris_pending_finis;
 

[-- Attachment #3: Type: text/plain, Size: 553 bytes --]


I'm not sure if this is the right approach, though, using
get_comdat_group seems to be preferred!?

ISTM that other ports might have similar problems: darwin.c, mep/mep.c,
and mips/mips.c all use DECL_COMDAT_GROUP without including cgraph.h.

> 	* mips.c (mips_start_unique_function): Likewise.
> 	(ix86_code_end): Likewise.
> 	(rs6000_code_end): Likweise.

The last two entries lack the file names.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

  reply	other threads:[~2014-05-26 13:03 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-21 13:31 [PATCH 0/7] ipa-prop escape analysis Martin Jambor
2014-05-21 13:31 ` [PATCH 4/7] Break up determine_known_aggregate_parts Martin Jambor
2014-05-26  0:54   ` Jan Hubicka
2014-06-06 13:28     ` Martin Jambor
2014-05-21 13:31 ` [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags Martin Jambor
2014-05-21 14:27   ` Richard Biener
2014-05-22 12:49     ` Martin Jambor
2014-05-22 13:34       ` Richard Biener
2014-05-22 15:24         ` Jan Hubicka
2014-05-22 15:36           ` Richard Biener
2014-05-22 18:11             ` Jan Hubicka
2014-05-23 10:03               ` Richard Biener
2014-05-23 22:29                 ` Jan Hubicka
2014-05-24  7:39                 ` Jan Hubicka
2014-05-26 13:03                   ` Rainer Orth [this message]
2014-05-27 17:51                     ` Jan Hubicka
2014-05-27 18:16                       ` Rainer Orth
2014-05-26  1:01         ` Jan Hubicka
2014-05-21 13:31 ` [PATCH 5/7] Advanced aggregate jump function construction Martin Jambor
2014-05-21 13:31 ` [PATCH 1/7] Add missing documentation of four IPA-CP params Martin Jambor
2014-05-21 15:58   ` Jeff Law
2014-06-10 12:13   ` Gerald Pfeifer
2014-06-29 23:07     ` Gerald Pfeifer
2014-07-15 12:01       ` Martin Jambor
2014-05-21 13:31 ` [PATCH 6/7] Real aggregate contents merge and application of deltas Martin Jambor
2014-05-21 13:31 ` [PATCH 3/7] IPA-CP escape and clobber analysis Martin Jambor
2014-05-21 14:51   ` Richard Biener
2014-05-23 14:50     ` Martin Jambor
2014-05-21 13:31 ` [PATCH 2/7] Analyze BBs in DOM order in ipa-prop.c Martin Jambor
2014-05-26  9:00 [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags Dominique Dhumieres
2014-05-26  9:16 ` Andrew Pinski
2014-05-26  9:29   ` Christophe Lyon
2014-05-26 16:32     ` Jan Hubicka
2014-05-28  7:26   ` Thomas Schwinge
2014-05-28 21:55     ` Jan Hubicka
2014-06-03  9:56       ` Thomas Schwinge

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=yddvbssn14a.fsf@lokon.CeBiTec.Uni-Bielefeld.DE \
    --to=ro@cebitec.uni-bielefeld.de \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=richard.guenther@gmail.com \
    /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).