Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

2014-10-20 Thread Xinliang David Li
ok (for google branch). David On Mon, Oct 20, 2014 at 1:44 PM, Sriraman Tallam wrote: > On Mon, Oct 20, 2014 at 12:59 PM, Xinliang David Li > wrote: >> On Mon, Oct 20, 2014 at 11:59 AM, Sriraman Tallam >> wrote: >>> On Mon, Oct 20, 2014 at 10:51 AM, Andrew Pinski wrote: On Mon, Oct 20,

Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

2014-10-20 Thread Sriraman Tallam
On Mon, Oct 20, 2014 at 12:59 PM, Xinliang David Li wrote: > On Mon, Oct 20, 2014 at 11:59 AM, Sriraman Tallam wrote: >> On Mon, Oct 20, 2014 at 10:51 AM, Andrew Pinski wrote: >>> On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam >>> wrote: On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David

Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

2014-10-20 Thread Xinliang David Li
On Mon, Oct 20, 2014 at 11:59 AM, Sriraman Tallam wrote: > On Mon, Oct 20, 2014 at 10:51 AM, Andrew Pinski wrote: >> On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam >> wrote: >>> On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David Li >>> wrote: Why removing the tree_code check? >>> >>> Th

Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

2014-10-20 Thread Sriraman Tallam
On Mon, Oct 20, 2014 at 10:51 AM, Andrew Pinski wrote: > On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam wrote: >> On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David Li >> wrote: >>> Why removing the tree_code check? >> >> The actual problem happens because STRING_CSTs (end up in .lrodata) >> a

Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

2014-10-20 Thread Sriraman Tallam
On Mon, Oct 20, 2014 at 10:59 AM, Xinliang David Li wrote: > Perhaps explicitly allowing STRING_CST to go through the large data > check, instead of removing the var-decl check? Do you see other > opcodes that need to be handled too? I do not see any other opcodes explicitly but the code in ix86_

Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

2014-10-20 Thread Xinliang David Li
Perhaps explicitly allowing STRING_CST to go through the large data check, instead of removing the var-decl check? Do you see other opcodes that need to be handled too? David On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam wrote: > On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David Li > wrote:

Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

2014-10-20 Thread Andrew Pinski
On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam wrote: > On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David Li > wrote: >> Why removing the tree_code check? > > The actual problem happens because STRING_CSTs (end up in .lrodata) > are not set a far address as they dont match the VAR_DECL check h

Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

2014-10-20 Thread Sriraman Tallam
On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David Li wrote: > Why removing the tree_code check? The actual problem happens because STRING_CSTs (end up in .lrodata) are not set a far address as they dont match the VAR_DECL check here. Futher, "ix86_in_large_data_p" call has the TREE_CODE check to

Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

2014-10-20 Thread Xinliang David Li
Why removing the tree_code check? David On Mon, Oct 20, 2014 at 10:35 AM, Sriraman Tallam wrote: > Hi, > >This patch is under review for trunk GCC : > https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01638.html. > > In the mean time, is this ok for google/gcc-4_9 branch? Without > this, -m

[Google/gcc-4_9][PATCH][target/x86_64] PR 63538

2014-10-20 Thread Sriraman Tallam
Hi, This patch is under review for trunk GCC : https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01638.html. In the mean time, is this ok for google/gcc-4_9 branch? Without this, -mcmodel=medium is unusable if .lrodata goes beyond the 2G boundary. Thanks Sri Index: testsuite/gcc.dg/pr63538.c

[PATCH][target/x86_64] PR 63538

2014-10-16 Thread Sriraman Tallam
Hi, I have attached patch for bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63538 Please review. Thanks Sri With -mcmodel=medium, .lrodata accesses must use far address. Here the check for TREE_CODE(decl) == VAR_DECL in function ix86_encode_section_info is removed as this does not handl