On 04/16/2014 05:56 PM, Ian Lance Taylor wrote:
I'm still not clear on what the real problem is.
It seems to me that when using GCC, if you #include , you
will get the GCC version, since it will come from the installed
GCC include directory, which is searched ahead of /usr/include. That
seems
On Wed, Apr 16, 2014 at 3:53 PM, Eric Botcazou wrote:
>> It looks reasonable at first glance, but there's a disturbing comment in
>> the code something to the effect:
>>
>> until we have a GCC compatible unwinding library, hide the API
>
> Indeed, it looks like it was written from scratch for the
> It looks reasonable at first glance, but there's a disturbing comment in
> the code something to the effect:
>
> until we have a GCC compatible unwinding library, hide the API
Indeed, it looks like it was written from scratch for the Diab compiler and
is not fully compatible, but it is meant t
On 04/16/2014 12:55 PM, Richard Henderson wrote:
Is it a (reasonably) close match, interface-wise? Ought we be using
--with-system-libunwind for VxWorks7, like we do for hpux?
It looks reasonable at first glance, but there's a disturbing comment in
the code something to the effect:
until w
On 04/16/2014 12:48 PM, Douglas B Rupp wrote:
> On 04/16/2014 12:38 PM, Eric Botcazou wrote:
>>> Because GCC would then be already incompatible with the Intel compiler from
>>> which this interface was drawn, way back when the ia64 support was added to
>>> GCC and we redesigned GCC's exception hand
On Wed, Apr 16, 2014 at 12:01 AM, John Marino wrote:
> On 4/16/2014 03:22, Ian Lance Taylor wrote:
>> On Tue, Apr 15, 2014 at 4:45 AM, Douglas B Rupp wrote:
>>> On 04/14/2014 02:01 PM, Ian Lance Taylor wrote:
>>>
>>> No I considered that but I think that number will be very small. Will you
>>> co
On 04/16/2014 12:38 PM, Eric Botcazou wrote:
Because GCC would then be already incompatible with the Intel compiler from
which this interface was drawn, way back when the ia64 support was added to
GCC and we redesigned GCC's exception handling.
The irony being that WindRiver is now owned by Int
> Because GCC would then be already incompatible with the Intel compiler from
> which this interface was drawn, way back when the ia64 support was added to
> GCC and we redesigned GCC's exception handling.
The irony being that WindRiver is now owned by Intel...
Doug, what does this unwind.h from
On 04/16/2014 12:01 AM, John Marino wrote:
> On 4/16/2014 03:22, Ian Lance Taylor wrote:
>> On Tue, Apr 15, 2014 at 4:45 AM, Douglas B Rupp wrote:
>>> On 04/14/2014 02:01 PM, Ian Lance Taylor wrote:
>>>
>>> No I considered that but I think that number will be very small. Will you
>>> concede, in h
On 4/16/2014 03:22, Ian Lance Taylor wrote:
> On Tue, Apr 15, 2014 at 4:45 AM, Douglas B Rupp wrote:
>> On 04/14/2014 02:01 PM, Ian Lance Taylor wrote:
>>
>> No I considered that but I think that number will be very small. Will you
>> concede, in hindsight, that it would be better had the name bee
On Tue, Apr 15, 2014 at 4:45 AM, Douglas B Rupp wrote:
> On 04/14/2014 02:01 PM, Ian Lance Taylor wrote:
>>
>> You may have failed to consider that unwind.h is installed and can be
>> #include'd by any program that is built with GCC. Renaming the
>> installed file will break an unknown number of
On 15 April 2014 13:08, Игорь Пашев wrote:
> AFAIK GCC's unwind.h installed into GCC's private directory, e. g.
> /usr/lib/gcc/x86_64-pc-solaris2.11/4.8/include/unwind.h
>
> Is there any real problem?
Which header do you get if you say #include ?
Which header did you intend to include?
On Tue, Apr 15, 2014 at 01:03:42PM +0100, Jonathan Wakely wrote:
> On 15 April 2014 12:45, Douglas B Rupp wrote:
> > No I considered that but I think that number will be very small. Will you
> > concede, in hindsight, that it would be better had the name been chosen to
> > be more unique?
>
> No a
AFAIK GCC's unwind.h installed into GCC's private directory, e. g.
/usr/lib/gcc/x86_64-pc-solaris2.11/4.8/include/unwind.h
Is there any real problem?
On 15 April 2014 12:45, Douglas B Rupp wrote:
> No I considered that but I think that number will be very small. Will you
> concede, in hindsight, that it would be better had the name been chosen to
> be more unique?
No argument from me there, but the same applies to VxWorks, who have
now chosen t
On 04/14/2014 02:01 PM, Ian Lance Taylor wrote:
You may have failed to consider that unwind.h is installed and can be
#include'd by any program that is built with GCC. Renaming the
installed file will break an unknown number of existing programs.
Ian
No I considered that but I think that num
On Mon, Apr 14, 2014 at 10:10 AM, Douglas B Rupp wrote:
>
> VxWorks7 has introduced an incompatible unwind.h header file that conflicts
> with gcc's unwind.h (which is a build time header file linked to the
> appropriate source header).
>
> I'd like to propose renaming gcc's unwind.h to unwind-gcc
VxWorks7 has introduced an incompatible unwind.h header file that
conflicts with gcc's unwind.h (which is a build time header file linked
to the appropriate source header).
I'd like to propose renaming gcc's unwind.h to unwind-gcc.h
There are 54 occurrences in the gcc source tree, including
18 matches
Mail list logo
