Hi!
When I try to build gcc from trunk with mingw-w64 I successfully build
only 64bit with seh exceptions. Other builds stop on error
../../../../../../mingw-sources/gcc-trunk/libgcc/unwind-c.c:238:1:
warning: no previous prototype for '__gcc_personality_seh0'
[-Wmissing-prototypes]
__gcc_person
Hi,
the cause for this is that SEH exceptions are only present for x64
64-bit target. There is no such support for 32-bit (mainly caused by
patent issues). Therefore if you want to build multilib for mingw,
then please switch back to SjLj-exception mechanism.
Regards,
Kai
My configure line is:
$ /temp/mingw-sources/gcc-trunk/gcc/configure
--cache-file=./config.cache
--prefix=/temp/x32-trunk-snapshot-posix-sjlj-rev1/prefix
--with-sysroot=/temp/x32-trunk-snapshot-posix-sjlj-rev1/prefix
--enable-shared --enable-static --enable-targets=all --enable-multilib
--enable-li
On 21/11/12 22:47, Ian Lance Taylor wrote:
On Wed, Nov 21, 2012 at 1:20 PM, Paolo Bonzini wrote:
On Wed, Nov 21, 2012 at 8:02 PM, Ian Lance Taylor wrote:
The main advantage is that you can compile a program with CFLAGS="-O2 -g
-fPIE", and libtool's adding of -fPIC for shared libraries will wo
2012/11/22 Kai Tietz:
> Hi,
>
> the cause for this is that SEH exceptions are only present for x64
> 64-bit target. There is no such support for 32-bit (mainly caused by
> patent issues). Therefore if you want to build multilib for mingw,
> then please switch back to SjLj-exception mechanism.
I
2012/11/22 niXman:
> I once asked a similar question, but didn't understand, whether sjlj
> use will be available for 4.8?
Because I a few months can not build trunk with sjlj successfully.
I wrote about this in the gcc-help mailing list, I think twice.
--
Regards,
niXman
__
Richard Earnshaw writes:
> -- namely one to restore the state to standard (not pic or pie).
-fno-pic -fno-pie
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
2012/11/22 niXman :
> 2012/11/22 niXman:
>> I once asked a similar question, but didn't understand, whether sjlj
>> use will be available for 4.8?
>
> Because I a few months can not build trunk with sjlj successfully.
> I wrote about this in the gcc-help mailing list, I think twice.
Well, __SEH__
2012/11/22 Kai Tietz:
> Well, __SEH__ is defined for x64 in any case. There is no way to have
> for x64 no SEH-support - at least not in a way it would work in a
> general way, as SEH is part of the ABI of x64.
I.e. SJLJ can't be used for 4.8(and later)-x86_64?
> I am about to setup a build for t
With 64bit multilib toolchain is the same situation as with 32bit
multilib toolchain
2012/11/22 niXman :
> 2012/11/22 Kai Tietz:
>> Well, __SEH__ is defined for x64 in any case. There is no way to have
>> for x64 no SEH-support - at least not in a way it would work in a
>> general way, as SEH is part of the ABI of x64.
> I.e. SJLJ can't be used for 4.8(and later)-x86_64?
>
>> I am
Ok I try it now.
2012/11/22 Kai Tietz :
> 2012/11/22 niXman :
>> 2012/11/22 Kai Tietz:
>>> Well, __SEH__ is defined for x64 in any case. There is no way to have
>>> for x64 no SEH-support - at least not in a way it would work in a
>>> general way, as SEH is part of the ABI of x64.
>> I.e. SJLJ ca
I have found that tree-flow.h implements iteration over htab_t,
while there is no current facility to do that with hash_table.
Unfortunately, the specific form does not match the standard C++
approach to iterators. We have several choices.
(1) Ignore the problem and leave all such tables as htab_
On Thu, Nov 22, 2012 at 12:18 PM, Lawrence Crowl wrote:
> I have found that tree-flow.h implements iteration over htab_t,
> while there is no current facility to do that with hash_table.
> Unfortunately, the specific form does not match the standard C++
> approach to iterators. We have several ch
On 11/18/2012 07:06 PM, NightStrike wrote:
What's wrong with std::shared_ptr?
The pointer needs two words, and the per-object overhead for the
reference counts etc. is four words, if I'm counting correctly.
(Other forms of reference counting have less overhead, of course, but
you were aski
On Thu, Nov 22, 2012 at 09:29:43PM +0100, Florian Weimer wrote:
> On 11/18/2012 07:06 PM, NightStrike wrote:
>
> >What's wrong with std::shared_ptr?
>
> The pointer needs two words, and the per-object overhead for the
> reference counts etc. is four words, if I'm counting correctly.
>
> (Other f
16 matches
Mail list logo
