Status of GCC 4.4 (Debian)

[Martin Michlmayr]

Given that GCC moved to stage 3 recently, I decided to build the Debian
archive to identify new issues before GCC 4.4 is released.  I compiled
the entire Debian archive (just under 8000 packages that need to be
compiled) on x86_64, ia64 and powerpc, and about 1800 packages on arm
(EABI).  I also wanted to test GCC on alpha, mips and sparc but ran
into compiler errors during bootstrap.

In total, I filed 28 new bugs and ran into 7 known issues.  64% of the
bugs I filed have already been fixed and many of those that are still
open have already received some attention.  I'd like to thank the GCC
community for such an oustanding job dealing with incoming bug reports
and fixing compiler regressions.

Here's the complete list of issues I ran into:

New bugs, fixed already: 18

 - PR37342: same canonical type node for different types void...
 - PR37343: ICE in expand_expr_real_1, at expr.c:7290
 - PR37345: Segfault in decl_function_context (TYPE_MAIN_VARIANT)
 - PR37346: insns needed body finalized, verify_cgraph_node failed
 - PR37353: ICE: vector VEC(gimple,base) push domain error, in tree_call_cdce 
at tree-call-cdce.c:890
 - PR37354: ICE in find_func_aliases, at tree-ssa-structalias.c:3906
 - PR37356: ICE in gsi_insert_seq_nodes_after, at gimple-iterator.c:222
 - PR37368: ICE: in make_decl_rtl, at varasm.c:1297
 - PR37382: ICE in extract_insn, at recog.c:2027
 - PR37385: ICE in set_mem_alias_set, at emit-rtl.c:1789
 - PR37387: ICE in extract_range_from_binary_expr, at tree-vrp.c:2145
 - PR37393: error: EH edge 10->12 is missing
 - PR37417: error: type mismatch in binary expression, verify_gimple failed
 - PR37419: memory corruption
 - PR37432: ICE in VN_INFO, at tree-ssa-sccvn.c:180
 - PR37433: tree check: expected function_decl, have string_cst in ccp_fold, at 
tree-ssa-ccp.c:1050
 - PR37434: ICE in extract_insn, at recog.c:2027
 - PR37474: vect_supported_slp_permutation_p memory corruption

New bugs, not fixed yet: 10

 - PR37344: sparc bootstrap fails with Bus error in libgcc2.c
 - PR37349: bootstrap broken on Alpha: undefined reference to 
_Jv_RegisterClasses
 - PR37381: ICE in ia64_speculate_insn, at config/ia64/ia64.c:6902
 - PR37392: Segfault in verify_ssa: !gimple_nop_p (stmt)
 - PR37394: Segfault in ia64_variable_issue with -O -fschedule-insns2
 - PR37395: mips bootstrap problem
 - PR37418: error: type mismatch in address expression, verify_gimple failed
 - PR37461: ICE in find_or_generate_expression, at tree-ssa-pre.c:2691
 - PR37482: definition in block 51 follows the use for SSA_NAME with -maltivec
 - PR37483: Segfault in noce_try_sign_mask (ifcvt.c): b_unconditional

Known bugs, fixed already: 4

 - PR37296: bootstrap failure compiling libgcc (e.g. on arm)
 - PR37333: sqlscan.c:2068: internal compiler error: in ira_flattening, at 
ira-build.c:2146
 - PR37357: undefined referenced when linking C++ code
 - PR37358: IPA-CP generates duplicated symbols at -O3

Known bugs, not fixed yet: 3

 - PR37146: secqstring.cpp:426: error: non-trivial conversion at assignment
 - PR37285: ICE in purge_dead_edges, at cfgrtl.c:2327
 - PR37456: ICE: verify_flow_info failed: control flow in the middle of
basic block, BB 3 can not throw but has EH edges

The testing was done on an EM64T system donated to Debian by Intel and
hosted by Stephen Frost, an IA64 hosted by the Gelato Federation, an
IBM OpenPower hosted at the University of Augsburg and a Marvell 78x00
development board hosted by Voipio Riku.

Affected packages:

 - PR37146: secqstring.cpp:426: error: non-trivial conversion at assignment
   - pinentry_0.7.5-2
   - qt-x11-free

 - PR37285: ICE in purge_dead_edges, at cfgrtl.c:2327
   - prelink

 - PR37333: sqlscan.c:2068: internal compiler error: in ira_flattening, at 
ira-build.c:2146
   - orafce
   - wireshark
   - libapache2-mod-python

 - PR37342: same canonical type node for different types void...
   - atlas-cpp
   - centerim
   - pasmo
   - oprofile
   - libsigc++-2.0
   - tagpy
   - avogadro
   - bisonc++
   - mior
   - vlc

 - PR37343: ICE in expand_expr_real_1, at expr.c:7290
   - lopster
   - pilrc
   - xserver-xorg-video-openchrome
   - vrweb
   - gprolog
   - scheme48
   - dmucs
   - goocanvas
   - openbabel
   - jpilot
   - gpredict
   - paraview
   - freetds
   - vtk
   - emacs22
   - cacao-oj6
   - asterisk-oh323
   - openjdk-6
   - tpm-tools

 - PR37345: Segfault in decl_function_context (TYPE_MAIN_VARIANT)
   - mkvtoolnix
   - orpheus
   - vnc
   - cultivation
   - libccscript3
   - stellarium
   - vdr
   - fluxbox
   - vdr-plugin-epgsearch
   - muse
   - rlplot
   - libghemical
   - gravitation
   - tora
   - doxygen
   - libgnomeuimm2.6
   - tomatoes
   - kscope
   - krusader
   - epos

 - PR37346: insns needed body finalized, verify_cgraph_node failed
   - libgenome

 - PR37353: ICE: vector VEC(gimple,base) push domain error, in tree_call_cdce 
at tree-call-cdce.c:890
   - qucs

 - PR37354: ICE in find_func_aliases, at tree-ssa-structalias.c:3906
   - traverso
   - sidplay-libs

Re: Status of GCC 4.4 (Debian)

[Richard Guenther]

On Sat, Sep 13, 2008 at 4:24 PM, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
> Given that GCC moved to stage 3 recently, I decided to build the Debian
> archive to identify new issues before GCC 4.4 is released.  I compiled
> the entire Debian archive (just under 8000 packages that need to be
> compiled) on x86_64, ia64 and powerpc, and about 1800 packages on arm
> (EABI).  I also wanted to test GCC on alpha, mips and sparc but ran
> into compiler errors during bootstrap.
>
> In total, I filed 28 new bugs and ran into 7 known issues.  64% of the
> bugs I filed have already been fixed and many of those that are still
> open have already received some attention.  I'd like to thank the GCC
> community for such an oustanding job dealing with incoming bug reports
> and fixing compiler regressions.

And I'd like to thank you for doing this enormous amount of work, including
filing high-quality bug-reports!

Thanks,
Richard.

Re: gdb test suite failure on i386 and x86_64 in gdb.base/break.exp

[Cary Coutant]

> This is PR 36690 which has various bits of analysis.

Thanks! I did search for this problem, but I guess I didn't use the
right terms, and it didn't turn up this bug report. Looks like if I
had done another search after analyzing the problem, it probably would
have turned up.

-cary

hercules sang melvin

[anu cindy]

mani ivor bevis
rollin 
remy ho 
thorsten 
jnye anu
 cindy janna 

Re: [Tuples] gimple_build_call_from_tree vs NeXT runtime Objective-C

[Andrew Pinski]

On Thu, Jun 19, 2008 at 1:08 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Hi,
>  When looking into stret-1.m failure, I noticed that
> gimple_build_call_from_tree calls get_callee_fndecl to get the "real"
> function decl.  Well for OBJ_TYPE_REF in Objective-C, it will return
> objc_msgSendSuper_stret/objc_msgSendSuper which is correct but after
> on we crash as that function decl really does not match the function
> type so we crash while expanding.  I don't know what the correct way
> to fix this but I think it might be to ignore get_callee_fndecl if we
> have an OBJ_TYPE_REF.  Does that seem reasonable?

With the more type checking this shows up even more than the two or
three testcases that were before.

-- Pinski

GRAPHITE Prerequisites Documentation, System Issues

[Aaron W. LaFramboise]

I'm happy to see that GRAPHITE it is in trunk now!

I don't see any documentation of prerequisites in install.texi yet; 
perhaps we should add this so users can figure out what they need to do 
to get this framework to work.


In fact, 'grep -i graphite gcc/doc/*' doesn't match anything, so I guess 
documentation is still in progress?


Also, are there any system-specific issues that need to be worked on (eg 
on Windows), or should GRAPHITE and its support libraries pretty much 
work on all host platforms?

Re: old but current libiberty/strsignal vs. cygwin

[Aaron W. LaFramboise]

Hi Jay,

Thanks for bringing this up.  I mainly work on the native-ish Windows 
targets (MinGW), so I'm not really a Cygwin guy, but see below.


Jay wrote:


 I'm still testing this but it does seem to be two smoking guns.
 The first one shot a blank but I doubt I'll find a third. :)

...
> Can someone vet and apply these changes? Thanks.

If you figure out a definitive fix, please submit it to gcc-patches@ in 
the proper format.  See  for the 
instructions on specifically how to submit a patch.


You will need to update your patch to SVN trunk or a recent 4.4 
snapshot, since that is what it would be applied to.



 Nobody builds gcc + cygwin in an integrated tree?
 I wish I could integrate more into The One Tree.
 I so dislike everything being separate..


Probably not, especially because relatively few people are doing their 
own Cygwin builds at all.



Similarly, this is kind of yucky but I guess ok:

...

Or declare them __declspec(dllimport) on Cygwin (or whatever is the gcc equiv).


I think libiberty it should do this conditional on Cygwin.  If that 
seems to fix it, you should submit a patch.  The ideal is to avoid using 
auto-import entirely if possible.

Re: Problems building Windows hosted mips-elf toolchain using Linux as build machine

[Aaron W. LaFramboise]

Hi Øyvind,

Øyvind Harboe wrote:

I'm trying to build a mips-elf toolchain hosted on Windows using
Linux as the build machine but I'm running into the following error:



mips-elf-gcc -nostdinc -isystem /tmp/gccbuild/build/gcc/./gcc/include
-B/tmp/gccbuild/build/gcc/mips-elf/newlib/ -isystem
/tmp/gccbuild/build/gcc/mips-elf/newlib/targ-include -isystem
/tmp/gccbuild/src/gcc/newlib/libc/include
-B/tmp/gccbuild/build/gcc/mips-elf/libgloss/mips
-L/tmp/gccbuild/build/gcc/mips-elf/libgloss/libnosys
-L/tmp/gccbuild/src/gcc/libgloss/mips -O2 -g -g -O2 -msoft-float -O2
-O2 -g -g -O2   -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -G 0 -g  -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I../../.././gcc
-I/tmp/gccbuild/src/gcc/libgcc -I/tmp/gccbuild/src/gcc/libgcc/.
-I/tmp/gccbuild/src/gcc/libgcc/../gcc
-I/tmp/gccbuild/src/gcc/libgcc/../include  -DHAVE_CC_TLS -o
_fixunssfsi.o -MT _fixunssfsi.o -MD -MP -MF _fixunssfsi.dep
-DL_fixunssfsi -c /tmp/gccbuild/src/gcc/libgcc/../gcc/libgcc2.c  \
-DLIBGCC2_UNITS_PER_WORD=4
In file included from /tmp/gccbuild/src/gcc/libgcc/../gcc/libgcc2.c:1697:
/tmp/gccbuild/src/gcc/newlib/libc/include/limits.h:130:26: error: no
include path in which to search for limits.h


What sort of thing is at this location in limits.h?  Unless someone 
knows something more about this, you will need to track down this 
specific failure.


Run re-run this specific command that is failing with -v to get more 
useful information about the search path.


GCC is supposed to provide a MIPS-target limits.h, and apparently thats 
not working out for some reason.



- trying to build a GCC toolchain under Windows seems like a complete
non-starter


It is fairly straightforward on Cygwin actually, and should work about 
as easily as the Linux build.  It will be substantially slower, however.


For a non-Cygwin native Windows (MinGW) build, see
.

I have no idea if that would solve your problem though. :)

By the way, this sort of question is best for [EMAIL PROTECTED], 
where people know more about these sorts of relatively common build 
problems.  gcc@ is for discussion of developing GCC specifically.