On Mon, Mar 21, 2011 at 12:18:43PM -0700, Mike Stump wrote:
> I didn't put them into the release branch yet... RM? You have a
> preference on timing? Now, after .0 goes out?
After .0 goes out. RC2 is building already and the fewer changes after RC2,
the better.
Jakub
On Mar 12, 2011, at 1:01 PM, Jack Howarth wrote:
> 2011-03-12 Jack Howarth
>
> libstdc++-v3/
> * testsuite/lib/prune.exp: Prune "could not create compact unwind for"
> warnings.
>
> gcc/
> * testsuite/lib/prune.exp: Ditto.
Checked in r171263. I modified the Changelogs slightly,
On Sat, Mar 19, 2011 at 08:52:32AM +, IainS wrote:
>
> On 19 Mar 2011, at 06:22, Mike Stump wrote:
>
>> On Mar 12, 2011, at 1:01 PM, Jack Howarth wrote:
>>> Xcode 4.0's linker now defaults on...
>>>
>>>-warn_compact_unwind
>>
>> So, if this is a flag, and we can turn the warning off, and we
On Fri, Mar 18, 2011 at 11:22:11PM -0700, Mike Stump wrote:
> On Mar 12, 2011, at 1:01 PM, Jack Howarth wrote:
> > Xcode 4.0's linker now defaults on...
> >
> > -warn_compact_unwind
>
> So, if this is a flag, and we can turn the warning off, and we truly don't
> care about the warnings, why
On 19 Mar 2011, at 06:22, Mike Stump wrote:
On Mar 12, 2011, at 1:01 PM, Jack Howarth wrote:
Xcode 4.0's linker now defaults on...
-warn_compact_unwind
So, if this is a flag, and we can turn the warning off, and we truly
don't care about the warnings, why not just use -
no_warn_compac
On Mar 12, 2011, at 1:01 PM, Jack Howarth wrote:
> Xcode 4.0's linker now defaults on...
>
> -warn_compact_unwind
So, if this is a flag, and we can turn the warning off, and we truly don't care
about the warnings, why not just use -no_warn_compact_unwind? That would be
preferable, I think
Xcode 4.0's linker now defaults on...
-warn_compact_unwind
When producing a final linked image, the linker processes the
__eh_frame section and produces an
__unwind_info section. Most FDE entries in the __eh_frame can
be represented by a 32-bit value in
