[M3devel] strange errors...

[Mika Nystrom]

Guten Tag Olaf!

--- building in FreeBSD4 ---

cd FreeBSD4
ignoring ../src/m3overrides

rm .M3SHIP
rm .M3OVERRIDES
inhale libm3core.m3x

new source -> compiling RTHooks.i3
m3front ../src/runtime/common/RTHooks.i3 -w1
/usr/local/cm3/bin/cm3cg -quiet RTHooks.ic -o RTHooks.is -g
RTHooks.i3: In function 'RTHooks_I3':
RTHooks.i3:146: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
rm RTHooks.is


I figured that building cm3cg with debugging symbols involves
running "cm3 -DM3CC_CFLAGS=-g" (not completely obvious), and
obtained the following:

(gdb) run -quiet RTHooks.ic -o RTHooks.is -g
Starting program: /usr/local/cm3/bin/cm3cg -quiet RTHooks.ic -o RTHooks.is -g

Program received signal SIGSEGV, Segmentation fault0x080f614b in gen_field_die (decl=0x6873f228, context_die=0x68714208) at ../../gcc/gcc/dwarf2out.c:12079
12079     if (TREE_CODE (DECL_FIELD_CONTEXT (decl)) != UNION_TYPE)
(gdb) where
#0  0x080f614b in gen_field_die (decl=0x6873f228, context_die=0x68714208) at ../../gcc/gcc/dwarf2out.c:12079
#1  0x080f7ad6 in gen_decl_die (decl=0x6873f228, context_die=0x68714208) at ../../gcc/gcc/dwarf2out.c:13121
#2  0x080f671d in gen_member_die (type=0x6873f33c, context_die=0x68714208) at ../../gcc/gcc/dwarf2out.c:12280
#3  0x080f69e4 in gen_struct_or_union_type_die (type=0x6873f33c, context_die=0x68714138) at ../../gcc/gcc/dwarf2out.c:12357
#4  0x080f6f0f in gen_type_die (type=0x6873f33c, context_die=0x68714138) at ../../gcc/gcc/dwarf2out.c:12562
#5  0x080f79a0 in gen_decl_die (decl=0x6871c548, context_die=0x68714138) at ../../gcc/gcc/dwarf2out.c:13072
#6  0x080f808b in dwarf2out_decl (decl=0x6871c548) at ../../gcc/gcc/dwarf2out.c:13371
#7  0x080f7ceb in dwarf2out_type_decl (decl=0x6871c548, local=0) at ../../gcc/gcc/dwarf2out.c:13183
#8  0x0804c48b in debug_struct () at ../../gcc/gcc/m3cg/parse.c:1762
#9  0x0804de17 in m3cg_declare_formal () at ../../gcc/gcc/m3cg/parse.c:2463
#10 0x08053941 in m3_parse_file (xx=0) at ../../gcc/gcc/m3cg/parse.c:4773
#11 0x082eec3b in compile_file () at ../../gcc/gcc/toplev.c:991
#12 0x082f018a in do_compile () at ../../gcc/gcc/toplev.c:1949
#13 0x082f01f2 in toplev_main (argc=6, argv=0xbfbfe3bc) at ../../gcc/gcc/toplev.c:1981
#14 0x0805a2ae in main (argc=6, argv=0xbfbfe3bc) at ../../gcc/gcc/main.c:35
(gdb) print decl
$1 = 0x6873f228
(gdb) whatis decl
type = tree
(gdb) print *decl
$2 = {common = {chain = 0x6873f284, type = 0x68716284, ann = 0x0, code = FIELD_DECL, ... [large data structure follows]
(gdb) whatis context_die
type = dw_die_ref
(gdb) print *context_die
$5 = {die_tag = DW_TAG_structure_type, die_symbol = 0x0, die_attr = 0x68708fc0, die_parent = 0x68714138, die_child = 0x6871423c, die_sib = 0x0, die_definition = 0x0, die_offset = 0, 
  die_abbrev = 0, die_mark = 0, decl_id = 0}


Here I must confess I have never debugged parts of gcc before...  

If it helps, I put RTHooks.ic at http://www.async.caltech.edu/~mika/RTHooks.ic
Maybe someone can use this to tell whether it is m3front or cm3cg that is (more) broken.

Are the .ic files architecture-independent?

    Mika



"Olaf Wagner" writes:
>On Mon, June 25, 2007 5:47 am, Mika Nystrom wrote:
>> Yes, cm3 is just reporting it, I think.  I assume it's cm3cg that's
>> segfaulting:
>>
>> (compiling m3core)
>>
> --- building in FreeBSD4 ---
>>
>> ignoring ../src/m3overrides
>>
>> new source -> compiling RTHooks.i3
>> RTHooks.i3: In function 'RTHooks_I3':
>> RTHooks.i3:146: internal compiler error: Segmentation fault
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>> new source -> compiling RT0.i3
>> RT0.i3: In function 'RT0_I3':
>> RT0.i3:230: internal compiler error: Segmentation fault
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>
>This looks really broken :-(
>Please use the cm3 options -commands to see the actual backend executions
>and -keep to save the input data which provokes gcc to give up.
>You can then use gdb on cm3cg to get a backtrace and try to figure out
>what's going wrong. A backtrace of cm3cg will probably be most helpful.
>
>Olaf
>
>PS: As for automation of the installation and upgrade process, this
>    used to work fine some time ago. The problem seems to be that nobody
>    really does extensive testing of fresh installations unless Elego
>    pays some student for release engineering :-/ I think we should
>    just try to keep the existing installation scripts up-to-date;
>    perhaps add a bit more information. For example, if the m3gc-xxx
>    packages are not needed anymore, we should simply remove them from
>    all current scripts. It would also be helpful if we had a tinderbox
>    system that does regular builds at least on some reference platforms.
>PPS: Antony, did you change anything recently regarding code generation
>    that could cause such failures as above?
>-- 
>Olaf Wagner -- elego Software Solutions GmbH, Ohmstr. 9, 10179 Berlin, Germany
>phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
>Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194