* Jeff Law [2016-11-29 10:35:50 -0700]:
> On 11/29/2016 07:02 AM, Andrew Burgess wrote:
> > * Jeff Law [2016-11-28 15:08:46 -0700]:
> >
> > > On 11/24/2016 02:40 PM, Andrew Burgess wrote:
> > > > * Christophe Lyon [2016-11-21 13:47:09
> > > > +0100]:
> > > >
> > > > > On 20 November 2016 at
On 11/29/2016 07:02 AM, Andrew Burgess wrote:
* Jeff Law [2016-11-28 15:08:46 -0700]:
On 11/24/2016 02:40 PM, Andrew Burgess wrote:
* Christophe Lyon [2016-11-21 13:47:09 +0100]:
On 20 November 2016 at 18:27, Mike Stump wrote:
On Nov 19, 2016, at 1:59 PM, Andrew Burgess wrote:
So, your
* Jeff Law [2016-11-28 15:08:46 -0700]:
> On 11/24/2016 02:40 PM, Andrew Burgess wrote:
> > * Christophe Lyon [2016-11-21 13:47:09 +0100]:
> >
> > > On 20 November 2016 at 18:27, Mike Stump wrote:
> > > > On Nov 19, 2016, at 1:59 PM, Andrew Burgess
> > > > wrote:
> > > > > > So, your new tes
On 11/24/2016 02:40 PM, Andrew Burgess wrote:
* Christophe Lyon [2016-11-21 13:47:09 +0100]:
On 20 November 2016 at 18:27, Mike Stump wrote:
On Nov 19, 2016, at 1:59 PM, Andrew Burgess wrote:
So, your new test fails on arm* targets:
After a little digging I think the problem might be tha
* Christophe Lyon [2016-11-21 13:47:09 +0100]:
> On 20 November 2016 at 18:27, Mike Stump wrote:
> > On Nov 19, 2016, at 1:59 PM, Andrew Burgess
> > wrote:
> >>> So, your new test fails on arm* targets:
> >>
> >> After a little digging I think the problem might be that
> >> -freorder-blocks-an
On 20 November 2016 at 18:27, Mike Stump wrote:
> On Nov 19, 2016, at 1:59 PM, Andrew Burgess
> wrote:
>>> So, your new test fails on arm* targets:
>>
>> After a little digging I think the problem might be that
>> -freorder-blocks-and-partition is not supported on arm.
>>
>> This should be detec
On Nov 19, 2016, at 1:59 PM, Andrew Burgess wrote:
>> So, your new test fails on arm* targets:
>
> After a little digging I think the problem might be that
> -freorder-blocks-and-partition is not supported on arm.
>
> This should be detected as the new tests include:
>
>/* { dg-require-effe
* Christophe Lyon [2016-11-18 13:21:50 +0100]:
> On 16 November 2016 at 23:12, Andrew Burgess
> wrote:
> > * Mike Stump [2016-11-16 12:59:53 -0800]:
> >
> >> On Nov 16, 2016, at 12:09 PM, Andrew Burgess
> >> wrote:
> >> > My only remaining concern is the new tests, I've tried to restrict
> >>
On 16 November 2016 at 23:12, Andrew Burgess
wrote:
> * Mike Stump [2016-11-16 12:59:53 -0800]:
>
>> On Nov 16, 2016, at 12:09 PM, Andrew Burgess
>> wrote:
>> > My only remaining concern is the new tests, I've tried to restrict
>> > them to targets that I suspect they'll pass on with:
>> >
>> >
On 11/16/2016 03:12 PM, Andrew Burgess wrote:
* Mike Stump [2016-11-16 12:59:53 -0800]:
On Nov 16, 2016, at 12:09 PM, Andrew Burgess
wrote:
My only remaining concern is the new tests, I've tried to restrict
them to targets that I suspect they'll pass on with:
/* { dg-final-use { scan-as
* Mike Stump [2016-11-16 12:59:53 -0800]:
> On Nov 16, 2016, at 12:09 PM, Andrew Burgess
> wrote:
> > My only remaining concern is the new tests, I've tried to restrict
> > them to targets that I suspect they'll pass on with:
> >
> >/* { dg-final-use { scan-assembler "\.section\[\t
> > \]
On Nov 16, 2016, at 12:09 PM, Andrew Burgess
wrote:
> My only remaining concern is the new tests, I've tried to restrict
> them to targets that I suspect they'll pass on with:
>
>/* { dg-final-use { scan-assembler "\.section\[\t
> \]*\.text\.unlikely\[\\n\\r\]+\[\t \]*\.size\[\t \]*foo\.col
* Bernd Schmidt [2016-11-03 13:01:32 +0100]:
> On 09/14/2016 03:00 PM, Andrew Burgess wrote:
> > In an attempt to get this patch merged (as I still think that its
> > correct) I've investigated, and documented a little more about how I
> > think things currently work. I'm sure most people readin
On 09/14/2016 03:00 PM, Andrew Burgess wrote:
In an attempt to get this patch merged (as I still think that its
correct) I've investigated, and documented a little more about how I
think things currently work. I'm sure most people reading this will
already know this, but hopefully, if my underst
* Jeff Law [2016-10-28 09:58:14 -0600]:
> On 09/15/2016 08:24 AM, Andrew Burgess wrote:
> > * Jakub Jelinek [2016-09-14 15:07:56 +0200]:
> >
> > > On Wed, Sep 14, 2016 at 02:00:48PM +0100, Andrew Burgess wrote:
> > > > In an attempt to get this patch merged (as I still think that its
> > > > co
On 09/15/2016 08:24 AM, Andrew Burgess wrote:
* Jakub Jelinek [2016-09-14 15:07:56 +0200]:
On Wed, Sep 14, 2016 at 02:00:48PM +0100, Andrew Burgess wrote:
In an attempt to get this patch merged (as I still think that its
correct) I've investigated, and documented a little more about how I
thi
* Jakub Jelinek [2016-09-14 15:07:56 +0200]:
> On Wed, Sep 14, 2016 at 02:00:48PM +0100, Andrew Burgess wrote:
> > In an attempt to get this patch merged (as I still think that its
> > correct) I've investigated, and documented a little more about how I
> > think things currently work. I'm sure
On Wed, Sep 14, 2016 at 02:00:48PM +0100, Andrew Burgess wrote:
> In an attempt to get this patch merged (as I still think that its
> correct) I've investigated, and documented a little more about how I
> think things currently work. I'm sure most people reading this will
> already know this, but
In an attempt to get this patch merged (as I still think that its
correct) I've investigated, and documented a little more about how I
think things currently work. I'm sure most people reading this will
already know this, but hopefully, if my understanding is wrong someone
can point it out.
I've
* Jeff Law [2016-06-21 20:55:15 -0600]:
> On 06/10/2016 10:56 AM, Andrew Burgess wrote:
> > The global flag `user_defined_section_attribute' is set while parsing C
> > code when the section attribute is encountered. The flag is set when
> > anything has the section attribute applied to it, funct
On Tue, Jun 21, 2016 at 08:55:15PM -0600, Jeff Law wrote:
> user_defined_section_attribute was introduced as part of the hot/cold
> partitioning changes.
>
> https://gcc.gnu.org/ml/gcc-patches/2004-07/msg01545.html
>
>
> What's supposed to happen is hot/cold partitioning is supposed to be turned
On 06/10/2016 10:56 AM, Andrew Burgess wrote:
The global flag `user_defined_section_attribute' is set while parsing C
code when the section attribute is encountered. The flag is set when
anything has the section attribute applied to it, functions or data.
The only place this global was used was
The global flag `user_defined_section_attribute' is set while parsing C
code when the section attribute is encountered. The flag is set when
anything has the section attribute applied to it, functions or data.
The only place this global was used was within the gate function for
partitioning block
23 matches
Mail list logo
