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
Snapshot gcc-4.3-20110313 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20110313/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
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
26 matches
Mail list logo
