Issue Details (XML | Word | Printable)

Key: CORE-5099
Type: Bug Bug
Status: Open Open
Priority: Minor Minor
Assignee: Unassigned
Reporter: Michal Kubeček
Votes: 3
Watchers: 7

If you were logged in you would be able to see more operations.
Firebird Core

build with gcc6 broken

Created: 03/Feb/16 10:10 AM   Updated: 15/Apr/16 01:15 PM
Component/s: Build Issues / Porting
Affects Version/s: 3.0 RC1, 2.5.5
Fix Version/s: None

Environment: x86_64 Linux with gcc6 (openSUSE Tumbleweed) but should be the same on any platform with gcc6

QA Status: No test

 Description  « Hide
Note: it will still take some time for gcc6 to reach distributions so this is not really urgent but it would be nice to be prepared.

Main change is default C++ standard: while gcc4 and gcc5 default to -std=gnu++98 (C++98 with some GNU specific extensions), gcc6 defaults to -std=gnu++14 (C++14 with some GNU extensions). This brings some changes, some subtle, some less so. Now when we have a staging project in BuildService, I tried to address some of them (first in 2.5 but 3.0 seems to be show the same problems).

1. invalid implicit conversion of 'false' to 'bool*' in par_primitive_value() (src/gpre/sqe.cpp)
A trivial mistake from replacing unsigned short with bool in 2003, fixed in 2.5 SVN recently, in 3.0 since 2011.

2. Error "declaration of operator new had different exception specifier" (src/common/classes/alloc.cpp)
Can be either worked around by explicitely switching to C++98 mode (-std=c++98) or (as suggested by our toolchain developers) fixed by dropping the redeclaration in alloc.h and exception specifier in alloc.cpp. The result builds with gcc 4.8, gcc5 and gcc6 but I'm not sure if this is OK with other compilers (like MSVC).
For details, see

3. Once these two are addressed, "../gen/firebird/bin/create_db empty.fdb" fails with "invalid request BLR at offset 24"
Additional message says "Too many Contexts of Relation/Procedure/Views. Maximum allowed is 255" which is really strange as, according to progam exit code, it fais on isc_create_database() call. No idea so far. Another strange part is that with "--enable-debug", the whole build succeeds (once the following issues are also addressed).

4. Possibly undefined expression in shutdown() (src/jrd/shut.cpp)
In 'for (Attachment* attachment = attachment = dbb->dbb_attachments; ... )', the extra '= attachment' should be dropped, I believe.

5. Warming: narrowing conversion ... inside { }
Some of these come from ODS_8_0 and friends being USHORT but used to initialize UCHAR fields in various structures. IMHO there would be no harm to declare them as UCHAR as they fit into 8 bits and if they didn't (ODS 16?), the implicit conversion would be lossy.
Similar problem in get_prot_mask() (src/dudley/exe.epp) where blr array of SCHAR is initialized with UCHAR constant (blr_end); quick fix is to declare blr[] as UCHAR and add a cast when it's passed to isc_compile_request2().

6. warning: deleting 'void*' is undefined in Database::~Database() (src/jrd/Database.cpp)
Tried to cast to 'SORTP*', seems to work.

7. warning: 'operator new' must not return NULL unless it is declared 'throw()' (or -fcheck-new is in effect)
Two occurences in class pool_alloc and three in class pool_alloc_rpt (both src/include/fb_blk.h). Adding "throw()" specifier seems to work.

8. warning: invalid suffix on literal; C++11 requires a space between literal and string macro
In constructions like "%"SLONGFORMAT",", the macro should be separated from string literals by a space. Non-fatal but the warnings are annoying (and make spotting the more important issues harder). Trivial to fix, however.

Right now, most critical seems issue 3, this will need more investigation.

To minimize changes to 2.5 code, we might try building with explicit -std=c++98 but that one fails for me with strange error about the way FB_VA_COPY macro is used in AbstractString::vprintf() (src/common/classes/fb_string.cpp).

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Adriano dos Santos Fernandes made changes - 05/Mar/16 03:34 AM
Field Original Value New Value
Comment [ Here is my findings building trunk with gcc 6:

First, I just committed a change for GPRE generate code compatible with C++-14

This options are not needed: