On 05/03/15 15:28, Ramana Radhakrishnan wrote:
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 7bf5b4d..777230e 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -6392,14 +6392,8 @@ arm_set_default_type_attributes (tree type)
static bool
arm_function_in_section
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 7bf5b4d..777230e 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -6392,14 +6392,8 @@ arm_set_default_type_attributes (tree type)
static bool
arm_function_in_section_p (tree decl, section *section)
{
- /* We can
On 03/03/15 15:58, Alex Velenko wrote:
On 19/02/15 17:26, Richard Henderson wrote:
On 02/19/2015 09:08 AM, Alex Velenko wrote:
Your suggestion seem to fix gcc.target/arm/long-calls-1.c, but has
to be
thoroughly tested.
Before you do complete testing, please also delete the TREE_STATIC test.
On 19/02/15 17:26, Richard Henderson wrote:
On 02/19/2015 09:08 AM, Alex Velenko wrote:
Your suggestion seem to fix gcc.target/arm/long-calls-1.c, but has to be
thoroughly tested.
Before you do complete testing, please also delete the TREE_STATIC test.
That bit should never be relevant to func
On Thu, Feb 19, 2015 at 10:35 PM, H.J. Lu wrote:
> On Thu, Feb 19, 2015 at 1:16 PM, Richard Henderson wrote:
>> On 02/19/2015 01:04 PM, Uros Bizjak wrote:
>>> 2015-02-19 Uros Bizjak
>>>
>>> * config/alpha/alpha.c (alpha_in_small_data_p): Reject common symbols.
>>
>> Ok. Thanks.
>
> We tri
On Thu, Feb 19, 2015 at 1:16 PM, Richard Henderson wrote:
> On 02/19/2015 01:04 PM, Uros Bizjak wrote:
>> 2015-02-19 Uros Bizjak
>>
>> * config/alpha/alpha.c (alpha_in_small_data_p): Reject common symbols.
>
> Ok. Thanks.
We tried it on ia64 and failed with Ada build.
--
H.J.
On 02/19/2015 01:07 PM, H.J. Lu wrote:
>> > The attached patch fixes all alpha-linux-gnu failures.
>> >
>> > 2015-02-19 Uros Bizjak
>> >
>> > * config/alpha/alpha.c (alpha_in_small_data_p): Reject common symbols.
>> >
>> > Patch was bootstrapped and regression tested on alphaev68-linux-gnu.
On 02/19/2015 01:04 PM, Uros Bizjak wrote:
> 2015-02-19 Uros Bizjak
>
> * config/alpha/alpha.c (alpha_in_small_data_p): Reject common symbols.
Ok. Thanks.
r~
On Thu, Feb 19, 2015 at 1:07 PM, H.J. Lu wrote:
> On Thu, Feb 19, 2015 at 1:04 PM, Uros Bizjak wrote:
>> On Mon, Feb 16, 2015 at 5:30 PM, Richard Henderson wrote:
>>
>> 2015-02-12 H.J. Lu
>> Richard Henderson
>>
>> PR rtl/32219
>> * cgraphunit
On Thu, Feb 19, 2015 at 1:04 PM, Uros Bizjak wrote:
> On Mon, Feb 16, 2015 at 5:30 PM, Richard Henderson wrote:
>
> 2015-02-12 H.J. Lu
> Richard Henderson
>
> PR rtl/32219
> * cgraphunit.c (cgraph_node::finalize_function): Set definition
>
On Mon, Feb 16, 2015 at 5:30 PM, Richard Henderson wrote:
2015-02-12 H.J. Lu
Richard Henderson
PR rtl/32219
* cgraphunit.c (cgraph_node::finalize_function): Set definition
before notice_global_symbol.
(varpool_nod
On 02/19/2015 09:08 AM, Alex Velenko wrote:
> Your suggestion seem to fix gcc.target/arm/long-calls-1.c, but has to be
> thoroughly tested.
Before you do complete testing, please also delete the TREE_STATIC test.
That bit should never be relevant to functions, as it indicates not that
it is in the
On 19/02/15 14:16, Richard Henderson wrote:
On 02/18/2015 06:17 AM, Alex Velenko wrote:
By changing behaviour of varasm.c:default_binds_local_p, this patch changes
behaviour of gcc/config/arm/arm.c:arm_function_in_section_p and through it
breaks gcc/config/arm/arm.c:arm_is_long_call_p for weak s
On 02/18/2015 06:17 AM, Alex Velenko wrote:
> By changing behaviour of varasm.c:default_binds_local_p, this patch changes
> behaviour of gcc/config/arm/arm.c:arm_function_in_section_p and through it
> breaks gcc/config/arm/arm.c:arm_is_long_call_p for weak symbols.
>
> As a result, I get regressio
On Wed, Feb 18, 2015 at 6:17 AM, Alex Velenko wrote:
> On 13/02/15 05:11, Richard Henderson wrote:
>>
>> On 02/12/2015 08:14 PM, H.J. Lu wrote:
>>>
>>> I tried the second patch. Results look good on Linux/x86-64.
>>
>>
>> Thanks. My results concurr. I went ahead and installed the patch as
>> po
On 13/02/15 05:11, Richard Henderson wrote:
On 02/12/2015 08:14 PM, H.J. Lu wrote:
I tried the second patch. Results look good on Linux/x86-64.
Thanks. My results concurr. I went ahead and installed the patch as posted.
r~
2015-02-12 H.J. Lu
Richard Henderson
On Mon, Feb 16, 2015 at 8:30 AM, Richard Henderson wrote:
> On 02/16/2015 06:01 AM, H.J. Lu wrote:
>> On Mon, Feb 16, 2015 at 5:25 AM, Uros Bizjak wrote:
>>> Hello!
>>>
2015-02-12 H.J. Lu
Richard Henderson
PR rtl/32219
* cgraphunit.c (cgra
On 02/16/2015 06:01 AM, H.J. Lu wrote:
> On Mon, Feb 16, 2015 at 5:25 AM, Uros Bizjak wrote:
>> Hello!
>>
>>> 2015-02-12 H.J. Lu
>>> Richard Henderson
>>>
>>> PR rtl/32219
>>> * cgraphunit.c (cgraph_node::finalize_function): Set definition
>>> before notice
On Mon, Feb 16, 2015 at 5:25 AM, Uros Bizjak wrote:
> Hello!
>
>> 2015-02-12 H.J. Lu
>> Richard Henderson
>>
>> PR rtl/32219
>> * cgraphunit.c (cgraph_node::finalize_function): Set definition
>> before notice_global_symbol.
>> (varpool_node::finaliz
Hello!
> 2015-02-12 H.J. Lu
> Richard Henderson
>
> PR rtl/32219
> * cgraphunit.c (cgraph_node::finalize_function): Set definition
> before notice_global_symbol.
> (varpool_node::finalize_decl): Likewise.
> * varasm.c (default_binds_local_p_
On 02/12/2015 08:14 PM, H.J. Lu wrote:
> I tried the second patch. Results look good on Linux/x86-64.
Thanks. My results concurr. I went ahead and installed the patch as posted.
r~
2015-02-12 H.J. Lu
Richard Henderson
PR rtl/32219
* cgraphunit.c (cgraph_nod
On Thu, Feb 12, 2015 at 4:04 PM, Richard Henderson wrote:
> On 02/12/2015 03:05 PM, H.J. Lu wrote:
>> @@ -6830,9 +6830,15 @@ default_binds_local_p_2 (const_tree exp, bool shlib,
>> bool weak_dominate)
>>bool resolved_locally = false;
>>if (symtab_node *node = symtab_node::get (exp))
>>
On 02/12/2015 03:05 PM, H.J. Lu wrote:
> @@ -6830,9 +6830,15 @@ default_binds_local_p_2 (const_tree exp, bool shlib,
> bool weak_dominate)
>bool resolved_locally = false;
>if (symtab_node *node = symtab_node::get (exp))
> {
> - /* When not building shared library and weak_dominat
On Thu, Feb 12, 2015 at 3:04 PM, H.J. Lu wrote:
> On Thu, Feb 12, 2015 at 11:25 AM, Richard Henderson wrote:
>> On 02/12/2015 10:58 AM, H.J. Lu wrote:
>>>if (DECL_VISIBILITY_SPECIFIED (exp)
>>> + && (resolved_locally
>>> + || !flag_pic
>>
>> Yes, this essentially goes back to your
On Thu, Feb 12, 2015 at 11:25 AM, Richard Henderson wrote:
> On 02/12/2015 10:58 AM, H.J. Lu wrote:
>>if (DECL_VISIBILITY_SPECIFIED (exp)
>> + && (resolved_locally
>> + || !flag_pic
>
> Yes, this essentially goes back to your original patch, which I claim still
> conflates issues.
>
On Thu, Feb 12, 2015 at 2:18 PM, H.J. Lu wrote:
> On Thu, Feb 12, 2015 at 11:16 AM, Jack Howarth
> wrote:
>> H.J.,
>>Oddly I saw no regressions in the g++ test suite at -m32/-m64 on
>> x86_64-apple-darwin14.
>>Jack
>
> They have
>
> // { dg-require-effective-target tls }
>
> Does
On 02/12/2015 10:58 AM, H.J. Lu wrote:
>if (DECL_VISIBILITY_SPECIFIED (exp)
> + && (resolved_locally
> + || !flag_pic
Yes, this essentially goes back to your original patch, which I claim still
conflates issues.
In particular, I believe mentioning flag_pic here is a serious error.
On Thu, Feb 12, 2015 at 11:16 AM, Jack Howarth wrote:
> H.J.,
>Oddly I saw no regressions in the g++ test suite at -m32/-m64 on
> x86_64-apple-darwin14.
>Jack
They have
// { dg-require-effective-target tls }
Does x86_64-apple-darwin14 support TLS? If yes, what does the
generate
H.J.,
Oddly I saw no regressions in the g++ test suite at -m32/-m64 on
x86_64-apple-darwin14.
Jack
On Thu, Feb 12, 2015 at 1:16 PM, H.J. Lu wrote:
> On Wed, Feb 11, 2015 at 10:22 PM, Richard Henderson wrote:
>> On 02/10/2015 01:19 PM, Richard Henderson wrote:
>>> As an existing iss
On Thu, Feb 12, 2015 at 10:16 AM, H.J. Lu wrote:
> On Wed, Feb 11, 2015 at 10:22 PM, Richard Henderson wrote:
>> On 02/10/2015 01:19 PM, Richard Henderson wrote:
>>> As an existing issue, I'm not sure why "specified" visibility is any
>>> different
>>> from unspecified visibility. As far as I'm
On Wed, Feb 11, 2015 at 10:22 PM, Richard Henderson wrote:
> On 02/10/2015 01:19 PM, Richard Henderson wrote:
>> As an existing issue, I'm not sure why "specified" visibility is any
>> different
>> from unspecified visibility. As far as I'm aware, the "specified" bit simply
>> means that the dec
On 02/10/2015 01:19 PM, Richard Henderson wrote:
> As an existing issue, I'm not sure why "specified" visibility is any different
> from unspecified visibility. As far as I'm aware, the "specified" bit simply
> means that the decl doesn't inherit inherit visibility from the class, or from
> the co
32 matches
Mail list logo
