On 05/16/13 15:32, Rainer Orth wrote:
The new gcc.dg/visibility-21.c testcase fails on i386-pc-solaris2.11 and
x86_64-unknown-linux-gnu:
FAIL: gcc.dg/visibility-21.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/visibility-21.c:1:0: warning:
this targ
Nathan Sidwell writes:
> This patch fixes a problem with section anchors. Found on powerpc, but
> also appears on MIPS and ARM targets.
>
> Section anchors can only be used for definitions known to bind in the
> current object file. The default predicate uses the bind_local_p hook to
> determin
> On 05/13/13 14:09, Jan Hubicka wrote:
> >>Index: varasm.c
> >>===
>
> >I think DECL_COMDAT is not what you really want to return true for. So
> >perhaps
> >you really want (TREE_PUBLIC (decl) && decl_binds_to_current_def_p)?
>
>
On 05/13/13 14:09, Jan Hubicka wrote:
Index: varasm.c
===
I think DECL_COMDAT is not what you really want to return true for. So perhaps
you really want (TREE_PUBLIC (decl) && decl_binds_to_current_def_p)?
Like this? This too
> Index: varasm.c
> ===
> --- varasm.c (revision 198771)
> +++ varasm.c (working copy)
> @@ -6582,10 +6582,18 @@ default_use_anchors_for_symbol_p (const_
> {
>/* Don't use section anchors for decls that might be defined
> On 05/09/13 07:02, Nathan Sidwell wrote:
> >On 05/08/13 18:47, Jan Hubicka wrote:
>
> >>Thinking about it again, isn't decl_replaceable_p the thing you are looking
> >>for
> >>here?
> >
> >that looks promising. I'll try !decl_replaceable_p in the section anchor
> >hook.
>
> It does indeed se
On 05/09/13 07:02, Nathan Sidwell wrote:
On 05/08/13 18:47, Jan Hubicka wrote:
Thinking about it again, isn't decl_replaceable_p the thing you are looking for
here?
that looks promising. I'll try !decl_replaceable_p in the section anchor hook.
It does indeed seem to be the right predicate
On 05/08/13 18:47, Jan Hubicka wrote:
On 05/08/13 14:11, Jan Hubicka wrote:
* a new function or hook 'binds_here_p' (and any default
implementations needed). Returns true if the symbol is known to
bind in the object file being emitted by the current compilation.
Thinking about it again, isn
On 2013/5/9 04:11 AM, Bernhard Reutner-Fischer wrote:
> On 8 May 2013 15:11:18 Jan Hubicka wrote:
>> > 2013-05-08 Nathan Sidwell
>> > gcc/
>> > * varasm.c (default_use_anchors_for_symbol_p): Reject WEAK.
>> > gcc/testsuite/
>> > * gcc.dg/visibility-21.c: New.
>> > Index: gcc/var
On 8 May 2013 15:11:18 Jan Hubicka wrote:
> 2013-05-08 Nathan Sidwell
>gcc/
>* varasm.c (default_use_anchors_for_symbol_p): Reject WEAK.
>gcc/testsuite/
>* gcc.dg/visibility-21.c: New.
> Index: gcc/varasm.c
> ===
> On 05/08/13 14:11, Jan Hubicka wrote:
>
> >With LTO we play more of similar tricks, by making use of the resolution
> >file.
> >I.e. for COMMON and EXTERNAL. Does it matter here?
>
> probably. It'd be a missed optimization though, rather than wrong code
> emission.
Well, the resolution inf
Thanks for fixing this.
Nathan Sidwell writes:
>> I would preffer the renaming excercise, since the name confused me few times,
>> too and the other predicate would be useful for IPA code :)
>
> before invoking sed, can we agree on the right names? I propose
>
> * renaming 'binds_local_p' to 'bi
On 05/08/13 14:11, Jan Hubicka wrote:
With LTO we play more of similar tricks, by making use of the resolution file.
I.e. for COMMON and EXTERNAL. Does it matter here?
probably. It'd be a missed optimization though, rather than wrong code
emission.
I would preffer the renaming excercise,
> 2013-05-08 Nathan Sidwell
>
> gcc/
> * varasm.c (default_use_anchors_for_symbol_p): Reject WEAK.
>
> gcc/testsuite/
> * gcc.dg/visibility-21.c: New.
>
> Index: gcc/varasm.c
> ===
> --- gcc/varasm.c
14 matches
Mail list logo
