On Tue, Nov 18, 2014 at 2:59 AM, David Malcolm wrote:
> On Mon, 2014-11-17 at 11:06 +0100, Richard Biener wrote:
>> On Sat, Nov 15, 2014 at 12:00 PM, David Malcolm wrote:
>> > On Thu, 2014-11-13 at 11:45 +0100, Richard Biener wrote:
>> >> On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm
>> >> wro
Hi,
On Mon, 17 Nov 2014, H.J. Lu wrote:
> It has nothing to do with large model.
Yes, I didn't say so. I've used it only to force GCC to emit @GOT relocs
(otherwise it would have used @GOTPCREL) to disprove your claim.
> The same thing happens to small model. We may be to able optimize it,
-Original Message-
From: Vladimir Makarov [mailto:vmaka...@redhat.com]
Sent: Tuesday, November 18, 2014 1:57 AM
To: Ajit Kumar Agarwal; gcc Mailing List
Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: Optimized Allocation of Argument registers
O
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: Monday, November 17, 2014 9:27 PM
To: Ajit Kumar Agarwal; Vladimir Makarov; gcc Mailing List
Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: Optimized Allocation of Argument registe
I was poking around attribs.c while trial running my tree-type-safety
stuff, and it triggered something in decl_attributes() that seems fishy
to me. It looks like it was part of the fix for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35315
decl_attributes() can be passed a tree node which is
On 11/18/2014 09:26 AM, Andrew MacLeod wrote:
I was poking around attribs.c while trial running my tree-type-safety
stuff, and it triggered something in decl_attributes() that seems fishy
to me. It looks like it was part of the fix for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35315
decl_att
On Tue, Nov 18, 2014 at 5:12 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 17 Nov 2014, H.J. Lu wrote:
>
>> It has nothing to do with large model.
>
> Yes, I didn't say so. I've used it only to force GCC to emit @GOT relocs
> (otherwise it would have used @GOTPCREL) to disprove your claim.
Well, it
On 11/18/2014 09:40 AM, Jason Merrill wrote:
On 11/18/2014 09:26 AM, Andrew MacLeod wrote:
I was poking around attribs.c while trial running my tree-type-safety
stuff, and it triggered something in decl_attributes() that seems fishy
to me. It looks like it was part of the fix for
https://gcc.gn
Dominik Vogt and I are trying to get upstream libffi merged
back to gcc, so that we can leverage better support for libgo.
I've done a heavy handed merge into a branch (likely not the
final form), and I'd like it to see wider testing.
Especially Darwin, which is known to be broken upstream.
But I
On 11/18/2014 09:52 AM, Andrew MacLeod wrote:
On 11/18/2014 09:40 AM, Jason Merrill wrote:
On 11/18/2014 09:26 AM, Andrew MacLeod wrote:
I was poking around attribs.c while trial running my tree-type-safety
stuff, and it triggered something in decl_attributes() that seems fishy
to me. It looks
Hi,
Currently x86-64 linker generate binaries with branch overflow for
large text section size:
https://sourceware.org/bugzilla/show_bug.cgi?id=17592
It happens to small, medium and large models. I will update linker
to check for branch overflow. In the meantime, Michael suggested
http://www.
On 11/18/14 09:30, Andrew MacLeod wrote:
I tried doing the if before chaning to TREE_TYPE... absolutely no
effect on the testsuite or anything else :-)
What do you think, should I check this in? What is there is clearly
incorrect.we could also revert the original patch since that is what
The relative order of multiple executable sections inside the executable
segment (distinct from nonexecutable read-only segment) is not important
to NaCl.
On 11/18/2014 01:36 PM, Jeff Law wrote:
On 11/18/14 09:30, Andrew MacLeod wrote:
I tried doing the if before chaning to TREE_TYPE... absolutely no
effect on the testsuite or anything else :-)
What do you think, should I check this in? What is there is clearly
incorrect.we could also rev
One issue with
text
PLT
readonly data
GOT
layout is it uses smaller data size for larger text size since the layout with
data is
text
PLT
readonly data
GOT
data
The data size is reduced by PLT size. If PLT is very large, impact
may be visible.
--
H.J.
On 11/18/2014 02:32 PM, Andrew MacLeod wrote:
So it effectively does nothing. Unless Jason can think of a good
reason for it, we probably ought to turf it. Its effectively a NOP.
Yeah, go ahead.
Jason
On Tue, 2014-11-18 at 10:53 +0100, Richard Biener wrote:
> On Tue, Nov 18, 2014 at 2:59 AM, David Malcolm wrote:
> > On Mon, 2014-11-17 at 11:06 +0100, Richard Biener wrote:
> >> On Sat, Nov 15, 2014 at 12:00 PM, David Malcolm
> >> wrote:
> >> > On Thu, 2014-11-13 at 11:45 +0100, Richard Biener
We see an inline problem as below caused by r201408
(https://gcc.gnu.org/ml/gcc-patches/2013-08/msg00027.html).
hoo() {
foo();
...
}
foo {
goo();
...
}
foo is func splitted, so its body changes to
foo {
goo();
...
foo.part();
}
and the used_as_abstract_origin of cgraph node of fo
On November 19, 2014 8:13:09 AM CET, Wei Mi wrote:
>We see an inline problem as below caused by r201408
>(https://gcc.gnu.org/ml/gcc-patches/2013-08/msg00027.html).
>
>hoo() {
> foo();
> ...
>}
>
>foo {
> goo();
> ...
>}
>
>foo is func splitted, so its body changes to
>
>foo {
> goo();
> ...
19 matches
Mail list logo
