trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: August 2016

Re: [trinity-devel] New FTBFS with GCC 6 and C++11 dialect

From: Jim <zlists@...>
Date: Wed, 17 Aug 2016 11:26:26 -0300
On Wed, Aug 17, 2016 at 03:00 (+0200), Slávek Banko wrote:

> Hi all,

> I noticed during current builgs, on Ubuntu 16.10 (Yakkety) and now also on 
> Debian 9 (Stretch) was changed the default compiler to GCC6. This brings 
> the number of new FTBFS. That's why I started to concentrate on these 
> FTBFS. Note - for this reason the packages for Yakkety in Preliminary 
> Stable Builds are now inconsistent.

> As a first, of course, I started with tdelibs. Most were simple conflict 
> signed / unsigned char or int. However, one serious problem is here.

> In the 'kjs' and 'tdehtml/ecma' is used HashEntry structure that contains 
> the item 'value' of type short int - see 'kjs/lookup.h'. Into this item 
> was stored values DOM::NodeFilter::ShowCode::SHOW_ALL = 0xFFFFFFFF (see 
> tdehtml/dom/dom2_traversal.h) and kjs event CHANGE with value 32768 (see 
> tdehtml/ecma/kjs_events.cpp). Both are therefore outside the range of 
> short int.

> Changing the type of 'value' in HashEntry from short to long would 
> apparently cause a change in ABI - kjs/lookup.h is part of the public 
> includes. That's why I made the change values 0xFFFFFFFF and 32768 to -1. 
> I think that GCC compilers version less than 6 will store these values in 
> the same way. Therefore, I believe that the proposed patch would not 
> cause problems == can be pushed. What is your opinion?

Is anyone compiling this for a 1's complement hardware platform?
If so, that could be an issue (now or in the future).

I don't have any gcc 6.0 machine to play with, so here are some
alternative thoughts, for what they are worth.

Would (short)0xFFFFFFFF make it happy?  Or how about ~0 (or ~(short)0)
to get all 1 bits?

Cheers.
                                Jim