"Bingfeng Mei" writes:
> Here the bitpos = 0, bitsize = 52. HOST_WIDE_INT for our processor
> is 32, though 64-bit long long type is supported. The marked
> statement produces a mask of 0xf, thus causes the upper 32-bit
> removed later. Is this a potential bug, or did I miss something?
gc
Hi,
I've noticed that there are a few symbols that appear " T " from
libgcc.a and " t " from libgcc_s.1.dylib.
(the exact set depends on ppc/intel and 32/64)
for example, on darwin9 (32 bit libs) the following;
___copysigntf3
___fabstf2
___udiv_w_sdiv
___unordtf2
Is there some specific reaso
Hi,
When building qt-3.3.8 and wxGTk on Tru64 UNIX 5.1
(alphaev67-dec-osf5.1) with gcc-4.2.4, we got linker failures about
duplicate non-virtual thunks, e.g. from qt:
/usr/ccs/bin/ld:
.obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to
QDragMoveEvent::~QDragMoveEvent(): multiply defined
"Peter O'Gorman" writes:
> When building qt-3.3.8 and wxGTk on Tru64 UNIX 5.1
> (alphaev67-dec-osf5.1) with gcc-4.2.4, we got linker failures about
> duplicate non-virtual thunks, e.g. from qt:
> /usr/ccs/bin/ld:
> .obj/release-shared-mt/qmotifdnd_x11.o: non-virtual thunk to
> QDragMoveEvent::~Q
Snapshot gcc-4.4-20081219 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20081219/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Dec 19, 2008, at 6:24 PM, Jack Howarth wrote:
Could you comment on...
http://gcc.gnu.org/ml/gcc/2008-12/msg00310.html
Is there some specific reason it's done this way?
Yes, libgcc_s is carefully built with carefully controlled exports.
They are controlled by:
gcc/libgcc-std.ver
wh
