public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <law@redhat.com>
To: Dharmakan Rohit Arul Raj <rohitarulraj@freescale.com>,
	       "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	       "rguenther@suse.de" <rguenther@suse.de>,
	       Jakub Jelinek <jakub@redhat.com>
Cc: Alan Modra <amodra@gmail.com>, David Edelsohn <dje.gcc@gmail.com>,
	       Edmar Wienskoski <edmar@freescale.com>
Subject: Re: [RFC: Patch, PR 60158] gcc/varasm.c : Pass actual alignment value to output_constant_pool_2
Date: Fri, 15 May 2015 17:53:00 -0000	[thread overview]
Message-ID: <55562E64.2040009@redhat.com> (raw)
In-Reply-To: <BLUPR03MB1458F5EE315C61519E4E8B1AC2C70@BLUPR03MB1458.namprd03.prod.outlook.com>

On 05/15/2015 04:37 AM, Dharmakan Rohit Arul Raj wrote:
>
>> -----Original Message-----
>> From: Jeff Law [mailto:law@redhat.com]
>> Sent: Friday, May 15, 2015 10:30 AM
>>> Just to summarize: By default in GCC v4.7.x, all the constants are put
>>> into '.rodata.str1.4' section. In GCC v4.8.x from r192719 onwards, one
>>> of the move instruction of the string constant ".LC0" is getting
>>> spilled. The reload pass, for any constants that aren't allowed and
>>> can't be reloaded in to registers tries to change them into memory
>>> references. Then while emitting that string constant to asm code
>>> (A:varasm.c: output_constant_pool_1), it explicitly passes the
>>> alignment as 1 which prevents the generation of fix-up table entries
>>> in  'B: rs6000.c:rs6000_assemble_integer' because the data is
>>> considered unaligned now.
>>>
>>> The bug seems to have gone latent with an unrelated trunk commit
>>> r204695 [* tree-ssa-loop-ivopts.c (force_expr_to_var_cost): Refactor
>>> the code. Handle type conversion.]. This commit chooses different
>>> spill candidates hence all the string constants are being put in to
>>> '.rodata.str1.4´section.
>>>
>>> The check I had in the test case is that if there is a
>>> '.data.rel.ro.local', then there should be '.fixup' section generated.
>>>
>>> Please let me know if you need any other details.
>> Thanks.  Even though I wasn't able to trigger the bug with the testcase from
>> 65018, I went ahead and committed this patch to the trunk.  It can't hurt and
>> it's the right thing to do.
>>
>> Thanks for your patience,
>>
>
> Jeff, Thanks for checking-in the changes.
> Can we apply the patch to GCC v4.8 and GCC v4.9 branch as well?
That's up to the branch maintainers.  I'd think it's safe, but it's 
ultimately their call.

jeff

  reply	other threads:[~2015-05-15 17:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-27 14:27 rohitarulraj
2015-04-28 10:06 ` rohitarulraj
2015-04-28 18:37   ` Jeff Law
2015-04-28 18:46     ` rohitarulraj
2015-04-28 22:46       ` Jeff Law
2015-04-29 10:43         ` rohitarulraj
2015-04-30 15:15           ` Jeff Law
2015-04-30 15:44             ` rohitarulraj
2015-04-30 15:55               ` Jeff Law
2015-05-05  7:59                 ` rohitarulraj
2015-05-15  5:01                   ` Jeff Law
2015-05-15 10:38                     ` Dharmakan Rohit Arul Raj
2015-05-15 17:53                       ` Jeff Law [this message]
2015-05-18  8:00                         ` Richard Biener
2015-05-25  8:21                           ` Dharmakan Rohit Arul Raj
2015-05-26  8:49                             ` Richard Biener

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=55562E64.2040009@redhat.com \
    --to=law@redhat.com \
    --cc=amodra@gmail.com \
    --cc=dje.gcc@gmail.com \
    --cc=edmar@freescale.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=rguenther@suse.de \
    --cc=rohitarulraj@freescale.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).