On Mon, 14 Mar 2011, Jack Howarth wrote:
>Would someone please correct http://gcc.gnu.org/gcc-4.6/changes.html by
> deleting
> the reference to darwin LTO support. Specifically we should just kill the
> line...
Done thusly.
Gerald
Index: changes.html
===
On Mon, Mar 14, 2011 at 02:08:47PM -0700, Ian Lance Taylor wrote:
>
> I think you are overthinking this. What LTO needs to do is really
> simple: store byte sequences with names. Anything which lets you do
> that will work. You need to write it out in a way that the assembler
> will accept; sim
Jack Howarth writes:
> On Sun, Mar 13, 2011 at 11:53:59AM -0700, Ian Lance Taylor wrote:
>> Jack Howarth writes:
>>
>> > So lto-object.c needs a rewrite to use only a single section for GNU_LTO
>> > with subsections.
>> > Unfortunately I can't find any documentation for using subsections in
>
On Sun, Mar 13, 2011 at 11:53:59AM -0700, Ian Lance Taylor wrote:
> Jack Howarth writes:
>
> > So lto-object.c needs a rewrite to use only a single section for GNU_LTO
> > with subsections.
> > Unfortunately I can't find any documentation for using subsections in
> > mach-o which may imply we w
Would someone please correct http://gcc.gnu.org/gcc-4.6/changes.html by
deleting
the reference to darwin LTO support. Specifically we should just kill the
line...
LTO-support.
Darwin has benefited from ongoing work on LTO; support for this is now stable
and enabled by default.
It doesn't me
On Sun, Mar 13, 2011 at 09:38:06PM +0100, Steven Bosscher wrote:
>
> I agree it is probably better to re-code things, but that will be
> impossible do before GCC 4.6 goes out.
>
> We have to make a decision: keep the LTO support for Mach-O in for now
> and recommend a non-recent Xcode, disable it
For clarity, the radar that I filed over which Apple has inflicted this
pain on us was...
--
Problem ID: 7920267possible linker bug exposed by LTO
28-Apr-2010 07:18 PM Jack Howarth:
The FSF gcc developers
Heh, so I guess it's my fault...
> I dug through radar and found the bug that triggered the change to as(1):
>
> possible assembler bug exposed by LTO
>
> The bug was written (ironically) by Jack Howarth! At the time 4/28/10),
> gcc's LTO was putting some LTO section first in the file and t
On Sun, Mar 13, 2011 at 09:43:07PM +0100, Steven Bosscher wrote:
> On Sun, Mar 13, 2011 at 9:41 PM, Jack Howarth
> wrote:
> > On Sun, Mar 13, 2011 at 09:38:06PM +0100, Steven Bosscher wrote:
> >> I agree it is probably better to re-code things, but that will be
> >> impossible do before GCC 4.6 g
Chris,
Could you clarify the following question from PR48086?
(In reply to comment #11)
> (In reply to comment #10)
> > The easiest way to fix this is maybe to just have more than one GNU_LTO
> > segment. AFAIU the limit of 255 sections is a limit per segment. It is not
> > difficult to have mu
On Sun, Mar 13, 2011 at 9:41 PM, Jack Howarth wrote:
> On Sun, Mar 13, 2011 at 09:38:06PM +0100, Steven Bosscher wrote:
>> I agree it is probably better to re-code things, but that will be
>> impossible do before GCC 4.6 goes out.
>>
>> We have to make a decision: keep the LTO support for Mach-O i
On Sun, Mar 13, 2011 at 09:38:06PM +0100, Steven Bosscher wrote:
> On Sun, Mar 13, 2011 at 9:03 PM, Jack Howarth
> wrote:
> > On Sun, Mar 13, 2011 at 08:42:58PM +0100, Steven Bosscher wrote:
> >> (sorry Chris, I forgot the list)
> >>
> >> On Mar 13, 2011,@11:59 AM, Chris Lattner wrote:
> >>
> >>
On Sun, Mar 13, 2011 at 9:03 PM, Jack Howarth wrote:
> On Sun, Mar 13, 2011 at 08:42:58PM +0100, Steven Bosscher wrote:
>> (sorry Chris, I forgot the list)
>>
>> On Mar 13, 2011,@11:59 AM, Chris Lattner wrote:
>>
>> > Sorry, I actually mean 255 of course, because of the NO_SECT
>> > sentinel. Her
On Sun, Mar 13, 2011 at 08:42:58PM +0100, Steven Bosscher wrote:
> (sorry Chris, I forgot the list)
>
> On Mar 13, 2011,@11:59 AM, Chris Lattner wrote:
>
> > Sorry, I actually mean 255 of course, because of the NO_SECT
> > sentinel. Here are the relevant bits from nlist.h. I'm not
> > sure how
On Sun, Mar 13, 2011 at 12:47:22PM -0700, Chris Lattner wrote:
>
> On Mar 13, 2011, at 12:05 PM, Jack Howarth wrote:
>
> > On Sun, Mar 13, 2011 at 11:55:02AM -0700, Chris Lattner wrote:
> >>
> >> On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote:
> >>
> Yes, I agree that this is a better so
On Mar 13, 2011, at 12:42 PM, Steven Bosscher wrote:
> (sorry Chris, I forgot the list)
>
> On Mar 13, 2011, at 11:59 AM, Chris Lattner wrote:
>
>> Sorry, I actually mean 255 of course, because of the NO_SECT
>> sentinel. Here are the relevant bits from nlist.h. I'm not
>> sure how you expect
On Mar 13, 2011, at 12:05 PM, Jack Howarth wrote:
> On Sun, Mar 13, 2011 at 11:55:02AM -0700, Chris Lattner wrote:
>>
>> On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote:
>>
Yes, I agree that this is a better solution. This error was put into the
linker to detect some overflow condi
On Mar 13, 2011, at 12:07 PM, Jan Hubicka wrote:
>>
>> Yes, I agree that this is a better solution. This error was put into the
>> linker to detect some overflow conditions for part of the code that expected
>> the section number to only be a byte. It is likely that "things worked"
>> only
(sorry Chris, I forgot the list)
On Mar 13, 2011, at 11:59 AM, Chris Lattner wrote:
> Sorry, I actually mean 255 of course, because of the NO_SECT
> sentinel. Here are the relevant bits from nlist.h. I'm not
> sure how you expect the toolchain to store more than 256
> sections in a uint8_t.
Ho
On Sun, Mar 13, 2011 at 11:59:33AM -0700, Chris Lattner wrote:
> On Mar 13, 2011, at 11:55 AM, Chris Lattner wrote:
> > On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote:
> >
> >>> Yes, I agree that this is a better solution. This error was put into the
> >>> linker to detect some overflow condit
>
> On Mar 13, 2011, at 8:38 AM, Jack Howarth wrote:
>
> > On Sun, Mar 13, 2011 at 12:39:26PM +0100, Jan Hubicka wrote:
> >>> With release of Xcode 3.2.6/4.0 this week, an unfortunate change was
> >>> made to
> >>> the darwin assembler which effectively breaks LTO support for darwin. The
> >>
On Sun, Mar 13, 2011 at 11:55:02AM -0700, Chris Lattner wrote:
>
> On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote:
>
> >> Yes, I agree that this is a better solution. This error was put into the
> >> linker to detect some overflow conditions for part of the code that
> >> expected the sectio
On Mar 13, 2011, at 11:55 AM, Chris Lattner wrote:
> On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote:
>
>>> Yes, I agree that this is a better solution. This error was put into the
>>> linker to detect some overflow conditions for part of the code that
>>> expected the section number to only b
On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote:
>> Yes, I agree that this is a better solution. This error was put into the
>> linker to detect some overflow conditions for part of the code that expected
>> the section number to only be a byte. It is likely that "things worked"
>> only out
Jack Howarth writes:
> So lto-object.c needs a rewrite to use only a single section for GNU_LTO with
> subsections.
> Unfortunately I can't find any documentation for using subsections in mach-o
> which may imply we will
> be forced to use an elf container to obtain those, no?
We can format th
On Sun, Mar 13, 2011 at 12:39:26PM +0100, Jan Hubicka wrote:
> >With release of Xcode 3.2.6/4.0 this week, an unfortunate change was
> > made to
> > the darwin assembler which effectively breaks LTO support for darwin. The
> > design
> > of LTO on darwin was based on the fact that mach-o obje
On Sun, Mar 13, 2011 at 11:19:13AM -0700, Chris Lattner wrote:
>
> On Mar 13, 2011, at 8:38 AM, Jack Howarth wrote:
>
> > On Sun, Mar 13, 2011 at 12:39:26PM +0100, Jan Hubicka wrote:
> >>> With release of Xcode 3.2.6/4.0 this week, an unfortunate change was
> >>> made to
> >>> the darwin assem
On Mar 13, 2011, at 8:38 AM, Jack Howarth wrote:
> On Sun, Mar 13, 2011 at 12:39:26PM +0100, Jan Hubicka wrote:
>>> With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made
>>> to
>>> the darwin assembler which effectively breaks LTO support for darwin. The
>>> design
>>> of
On Sun, Mar 13, 2011 at 12:39:26PM +0100, Jan Hubicka wrote:
> >With release of Xcode 3.2.6/4.0 this week, an unfortunate change was
> > made to
> > the darwin assembler which effectively breaks LTO support for darwin. The
> > design
> > of LTO on darwin was based on the fact that mach-o obje
>With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made
> to
> the darwin assembler which effectively breaks LTO support for darwin. The
> design
> of LTO on darwin was based on the fact that mach-o object files tolerated
> additional
> sections as long as they didin't con
On Sat, Mar 12, 2011 at 09:34:01PM -0800, Chris Lattner wrote:
>
> On Mar 12, 2011, at 8:17 PM, Jack Howarth wrote:
>
> > With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made
> > to
> > the darwin assembler which effectively breaks LTO support for darwin. The
> > design
>
On Mar 12, 2011, at 8:17 PM, Jack Howarth wrote:
> With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made to
> the darwin assembler which effectively breaks LTO support for darwin. The
> design
> of LTO on darwin was based on the fact that mach-o object files tolerated
> ad
Jack Howarth writes:
>With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made
> to
> the darwin assembler which effectively breaks LTO support for darwin. The
> design
> of LTO on darwin was based on the fact that mach-o object files tolerated
> additional
> sections as l
With release of Xcode 3.2.6/4.0 this week, an unfortunate change was made to
the darwin assembler which effectively breaks LTO support for darwin. The design
of LTO on darwin was based on the fact that mach-o object files tolerated
additional
sections as long as they didin't contain symbols. Wi
34 matches
Mail list logo
