Hi!
As part of preparations for possible switch of system compiler in F19
to GCC 4.8.0, we (myself and Marek Polacek) have performed a test mass
rebuild of rawhide (December 17th package list) using gcc-4.8.0-0.1.fc19
on x86_64, and for those packages that failed also rebuilt the same
package with gcc-4.7.2-9.fc19 to quickly remove from the list packages
that fail for non-gcc related reasons.
11687 packages built fine, 933 packages failed to build with
both gcc-4.8.0-0.1.f19.x86_64.rpm and gcc-4.7.2-9.fc19.x86_64.rpm
(ignored for this analysis, unlikely to be gcc 4.8 related).
The remaining packages, that failed to build with 4.8.0-0.1
and succeeded with 4.7.2-9 are listed below. 67 of these look
like issues on the package side, 22 gcc bugs that were supposedly
fixed by now upstream and thus should be ok in 4.8.0-0.3 when
it is built next week and 3 are not yet fixed gcc issues.
CCing Benjamin if he is again interested in writing
http://gcc.gnu.org/gcc-4.8/porting_to.html and could find this
information useful.
Besides build failures, the -Wsizeof-pointer-memaccess
warning triggered in several packages that succeeded building,
but it would be nice if package maintainers actually checked those
and fixed up, most likely those are real package bugs. The list of such
packages is included in first attachment.
For the more aggresive loop optimizations if the loop contain undefined
behavior, while it caused build failures just for 12 packages during the
mass rebuild, supposedly more packages will be affected, just the problems
weren't triggered during package build. Usually such loops are either
turned into infinite loops that soon crash, or hang, or as can be seen
on the perl-PDL case loops can be turned into just conditional non-looping
code (e.g. when compiler assumes that it can validly loop just at most
once).
blktap-2.0.90-6.git20111216.62de90d.fc18.src.rpm
cdrkit-1.1.11-14.fc19.src.rpm
elfutils-0.155-1.fc19.src.rpm
isomd5sum-1.0.9-2.fc18.src.rpm
libopensync-plugin-opie-0.22-8.fc18.src.rpm
linphone-3.5.2-4.fc18.src.rpm
lldpad-0.9.45-3.fc19.src.rpm
openvas-libraries-5.0.4-1.fc19.src.rpm
pilot-link-0.12.5-13.fc18.src.rpm
sh-elf-binutils-2.21-5.fc19.src.rpm
packages built with -Werror, for which the new
-Wsizeof-pointer-memaccess warning included in -Wall warns
and -Werror makes a fatal error out of it
bamf-0.2.104-4.fc18.src.rpm
byzanz-0.3-0.5.fc17.src.rpm
fvkbd-0.2.2-6.fc18.src.rpm
gedit-collaboration-3.6.0-1.fc18.src.rpm
gtkimageview-1.6.4-6.fc18.src.rpm
gypsy-0.8-6.fc17.src.rpm
libindicator-0.4.94-3.fc18.src.rpm
ltrace-0.7.0-1.fc19.src.rpm
mail-notification-5.4-64.git.eab5c13.fc19.src.rpm
ModemManager-0.6.0.0-2.fc19.src.rpm
physfs-2.0.2-3.fc18.src.rpm
roboptim-core-0.5-6.fc18.src.rpm
v8-3.10.8-2.fc18.src.rpm
xen-4.2.0-6.fc19.src.rpm
packages built with -Werror, for which the new
-Wunused-local-typedefs warning included in -Wall warns
and -Werror makes a fatal error out of it
trafficserver-3.2.0-3.fc18.src.rpm
package built with -Werror, and -Wmaybe-uninitialized warns
about possibly uninitialized fields which are uninitialized
if inc_gmtime_r returns -1 (and ink_time_current_mdy doesn't
bother to check that return value)
armacycles-ad-0.2.8.3.2-3.fc18.src.rpm
irrlicht-1.8-1.fc19.src.rpm
kdevelop-4.4.1-2.fc19.src.rpm
kst-2.0.3-7.fc18.src.rpm
maildrop-2.5.0-17.fc18.src.rpm
megaglest-3.7.1-1.fc19.src.rpm
opal-3.10.9-2.fc19.src.rpm
oxygen-gtk2-1.3.1-1.fc19.src.rpm
oxygen-gtk3-1.1.1-2.fc19.src.rpm
supertuxkart-0.7.3-3.fc19.src.rpm
syncevolution-1.3.2-1.fc19.src.rpm
gcc bug - internal compiler error in inline_call,
fixed upstream already, see
http://gcc.gnu.org/PR55683
pari-2.5.3-1.fc19.src.rpm
gcc bug - internal compiler error in LRA,
fixed upstream already, see
http://gcc.gnu.org/PR55775
avrdude-5.11.1-2.fc18.src.rpm
gcc bug - internal compiler error in remove_redundant_iv_tests,
fixed upstream already, see
http://gcc.gnu.org/PR55684
openttd-1.2.2-1.fc19.src.rpm
gcc bug - the package is built with LTO, and the problem
is extremely hard to reduce, just rebuild without --with-lto
for now
b43-openfwwf-5.2-8.fc18.src.rpm
ccache-3.1.8-1.fc18.src.rpm
openchange-1.0-12.fc19.src.rpm
openttd-opengfx-0.4.5-1.fc19.src.rpm
samba-4.0.0-171.fc19.rc6.src.rpm
/usr/include/stdc-predef.h issues
gcc preprocessor now in C/C++ modes automatically includes
<stdc-predef.h> header, packages which are using preprocessor
for non-C/C++ code or doing weird things with the preprocessor
might run into issues. For non-C/C++ code, it is always better
to preprocess as assembly instead of C
libxc-1.2.0-2.fc18.src.rpm
/usr/include/stdc-predef.h issues - using cpp -C -ansi to preprocess
Fortran sources is simply a very bad idea
adobe-source-libraries-1.0.43-13.fc19.src.rpm
asl-gcc.patch patch needs to be tweaked also for GCC 4.8
aws-2.11.0-11.fc19.src.rpm
gprbuild-2011-5.fc18.src.rpm
matreshka-0.3.0-2.fc19.src.rpm
needs dependencies rebuilt with GCC 4.8 gnat
cp2k-2.3-1.fc19.src.rpm
loop iterator passed as INTENT(INOUT) argument, see
http://gcc.gnu.org/PR30146
dragonegg-3.1-18.fc19.src.rpm
needs to be ported to GCC 4.8+
flterm-1.0-1.rc3.fc18.2.src.rpm
gedit-code-assistance-0.1.5-1.fc18.src.rpm
hfsplus-tools-540.1.linux3-2.fc18.src.rpm
clang needs to be updated not to require libstdc++-devel 4.7
gambas3-3.3.4-2.fc19.src.rpm
gcc bug for --enable-checking=yes compiler only, see
http://gcc.gnu.org/PR55878
distro compilers are always --enable-checking=release, so non-issue
except for the testing compiler
gccxml-0.9.0-0.13.20120309.fc19.src.rpm
supposedly needs to be ported for GCC 4.8, some tests failed
getdata-0.7.3-3.fc18.src.rpm
GCC is now more aggresive in turning loops that invoke undefined
behavior into endless loops. In test/get_uint32.c there is:
uint32_t data_data[128];
int fd, n, error, r = 0;
...
for (fd = 0; fd < 128; ++fd)
data_data[fd] = fd * (0x02000001);
When fd is 64 or above, fd * 0x02000001 overflows, which is invalid
in C/C++ for signed types (int here). To fix use
data_data[fd] = fd * 0x02000001U;
or
data_data[fd] = (uint32_t) fd * 0x02000001;
etc. instead.
sys_basher-1.1.24-3.fc18.src.rpm
similarly to getdata bug:
for(i=0;i<MAX_THREADS;i++)
{
csvt[i] = 0;
seed[i] = (i + 1LL) * 0x0123456789ABCDEFLL;
}
again, should have been 1ULL or 0x0123456789ABCDEFULL (or both)
ipv6calc-0.93.1-3.fc18.src.rpm
similarly to getdata bug:
for (i = 0; i < (int) (sizeof(newidentifier->in6_addr.s6_addr) /
sizeof(newidentifier->in6_addr.s6_addr[0])); i++) {
/* copy into */
newidentifier->in6_addr.s6_addr[i + 8] = (uint8_t) digest[i];
newtoken->in6_addr.s6_addr[i + 8] = (uint8_t) digest[i + 8];
};
s6_addr array size is 16 (i.e. i < 16 is the loop condition), digest
array has size 16, but obviously for i 8 and above the [i + 8]
accesses are all out of bounds. No idea what the code meant to do.
mpir-2.6.0-2.fc19.src.rpm
similarly to getdata bug, another clear out of bounds access in a loop:
#define numberof(x) (sizeof (x) / sizeof ((x)[0]))
...
for (oindex = 0; oindex <= numberof (offset); oindex++)
{
o = offset[oindex];
...
}
hdf-4.2.8-1.fc19.src.rpm
similarly to getdata bug:
for (i = 0; i < 10; i++)
{
for (j = 0; j < 10; j++)
{
...
ui32[i][j] = (uint32) ((i * 400000000) + j); /* range: 0 ~ 4-billion */
}
...
}
skf-1.99.0-1.fc18.2.src.rpm
similar to getdata bug:
#define BIG5P_TBL_LEN 23940 /* BIG5-Plus 190 * 126 */
...
#define HKSCS_FA_LEN 1140 /* f940 - fefe */
...
unsigned short big5a_uni_byte[BIG5P_TBL_LEN];
skf_ucode big5uao_fa_uni_byte[HKSCS_FA_LEN] = { ... };
...
for (j=0;j<HKSCS_FA_LEN;j++) { /* fa00 - */
big5a_uni_byte[BIG5P_TBL_LEN+j-950] = big5uao_fa_uni_byte[j];
};
yap-6.2.2-4.fc18.src.rpm
similar to getdata bug:
LAST_FLAG = 23
...
#define NUMBER_OF_YAP_FLAGS LAST_FLAG
...
#define yap_flags Yap_heap_regs->yap_flags_field
...
Int yap_flags_field[NUMBER_OF_YAP_FLAGS];
...
/* This must be done before initialising predicates */
for (i = 0; i <= LAST_FLAG; i++) {
yap_flags[i] = 0;
}
avr-gcc-4.7.2-1.fc19.src.rpm
gcc-4.7.2-9.fc19.src.rpm
mingw-gcc-4.7.2-6.fc19.src.rpm
msp430-gcc-4.6.3-2.fc19.src.rpm
another occurrences of similar issue, fixed upstream with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186590
when using older gcc codebases (4.6 and 4.7 based), this
needs to be backported.
perl-PDL-2.4.10-4.fc19.src.rpm
struct pdl_trans { ... pdl *pdls[1]; ... };
...
for(j=0; j<trans->vtable->nparents; j++) {
if(trans->vtable->per_pdl_flags[j] & 0x01) {
par_pvaf++;
if(!trans->pdls[j]) {return;}
pdl_make_physvaffine(trans->pdls[j]);
} else {
if(!trans->pdls[j]) {return;}
pdl_make_physical(trans->pdls[j]);
}
}
for(; j<trans->vtable->npdls; j++) {
...
}
From pdls[1] above the compiler figures out the first loop
iterates at most once (otherwise it would be an out of bounds
access). As the function is called with ->nparents ranging
from 0 to roughly 11 and ->npdls ranging from 1 to roughly 14
if it happened to "work" before, it was purely by luck.
glm-0.9.3.4-2.fc19.src.rpm
test/core/core_setup_message.cpp needs to be adjusted to grok GLM_COMPILER_GCC48
inkscape-0.48.3.1-4.fc19.src.rpm
qelectrotech-0.30-0.4.svn1844.fc18.src.rpm
texmaker-3.5-1.fc19.src.rpm
xmlcopyeditor-1.2.0.4-4.fc18.src.rpm
stray comma at the end of declaration, see
http://gcc.gnu.org/PR55368
struct A { void *member,; }; used to be accepted, now is rejected as
invalid.
kdbg-2.5.1-2.fc18.src.rpm
lemonpos-0.9.4-5.fc19.src.rpm
libaccounts-qt-0.31-6.fc18.src.rpm
qgis-1.8.0-10.fc19.src.rpm
rosegarden4-12.04-3.fc18.src.rpm
scribus-1.4.1-3.fc19.src.rpm
sir-2.4-1.fc18.src.rpm
unixODBC-gui-qt-0-0.6.20120105svn98.fc18.src.rpm
gcc bug, fixed upstream by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194816
llvm-3.1-12.fc19.src.rpm
gcc bug, not fixed yet, see
http://gcc.gnu.org/PR55875
openjpa-2.2.1-1.fc19.src.rpm
flaky (every time failed in a different spot) java issue, not clear
if in any way related to gcj/libgcj
python-webob1.2-1.2.1-8.fc19.src.rpm
flaky (every time failed in a different spot), doesn't contain any
non-python code, so I don't see how it could be related to gcc
snapper-0.1.0-1.20121026git1aaa372.fc19.src.rpm
includes <auto_ptr.h> which is declared to be a libstdc++ internal
header not supposed to be included directly, see
http://gcc.gnu.org/PR55866
sunpinyin-2.0.4-0.4.fc18.src.rpm
seems to be flaky SConstruct, with scons -j16 install (or even -j4)
it usually fails to install, with -j1 or -j2 it always succeeds
zarafa-7.0.9-1.fc19.src.rpm
gcc bug, fixed upstream already, see
http://gcc.gnu.org/PR55877
blender-2.64a-2.fc19.src.rpm
centerim-4.22.10-6.fc18.src.rpm
HippoDraw-1.21.3-6.fc19.src.rpm
meshlab-1.3.1-7.fc18.src.rpm
/usr/lib/rpm/debugedit: canonicalization unexpectedly shrank by one character
('/builddir/build/BUILD/' vs '/usr/src/debug/')
See
https://bugzilla.redhat.com/show_bug.cgi?id=304121 , avoid using
double slashes in path names and filenames.
E.g. for centerim it is in
AM_CPPFLAGS = -I$(top_srcdir)/kksystr/include -I$(top_srcdir)//kkstrtext
(note the useless // there, just making it / fixes this issue).
Jakub