[M3devel] m3_load/store using bitfields for everything

[Jay]

Looks like AMD64_LINUX is still failing similarly to how it was (NOT bitfield/global related, but optimization related).
-O2 also crashes. -O1 does not.
 
birch [~/dev2/cm3/m3-libs/slisp/AMD64_LINUX] jkrell
% gdb --args cm3cg SLisp.mc -O3 -quiet
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...Using host libthread_db library
"/lib/libthread_db.so.1".
(gdb) r
Starting program: /home/jkrell/cm3/bin/cm3cg SLisp.mc -O3 -quiet
cm3cg: warning: -freorder-blocks disabled for Modula-3 ex_stack exception handli
ng
Program received signal SIGSEGV, Segmentation fault.
0x00000000006814f4 in remove_phi_node (phi=0x2b17b7ac7100, prev=0x0,
    release_lhs_p=1 '\001') at ../../gcc/gcc/tree-phinodes.c:461
461                *loc != phi;
(gdb) bt
#0  0x00000000006814f4 in remove_phi_node (phi=0x2b17b7ac7100, prev=0x0,
    release_lhs_p=1 '\001') at ../../gcc/gcc/tree-phinodes.c:461
#1  0x00000000007039fb in remove_dead_inserted_code ()
    at ../../gcc/gcc/tree-ssa-pre.c:3775
#2  0x00000000007042b2 in execute_pre (do_fre=0 '\0')
    at ../../gcc/gcc/tree-ssa-pre.c:3975
#3  0x00000000007042cc in do_pre () at ../../gcc/gcc/tree-ssa-pre.c:3987
#4  0x000000000058be1b in execute_one_pass (pass=0xe46860)
    at ../../gcc/gcc/passes.c:1122
#5  0x000000000058bf73 in execute_pass_list (pass=0xe46860)
    at ../../gcc/gcc/passes.c:1175
#6  0x000000000058bf91 in execute_pass_list (pass=0xe45420)
    at ../../gcc/gcc/passes.c:1176
#7  0x0000000000676bbd in tree_rest_of_compilation (fndecl=0x2b17b624b750)
    at ../../gcc/gcc/tree-optimize.c:404
#8  0x00000000007cee01 in cgraph_expand_function (node=0x2b17b6663200)
    at ../../gcc/gcc/cgraphunit.c:1157
#9  0x00000000007cefae in cgraph_expand_all_functions ()
    at ../../gcc/gcc/cgraphunit.c:1220
#10 0x00000000007cf561 in cgraph_optimize ()
    at ../../gcc/gcc/cgraphunit.c:1427
#11 0x000000000040f875 in m3_parse_file (xx=0)
    at ../../gcc/gcc/m3cg/parse.c:5220
#12 0x000000000062feec in compile_file () at ../../gcc/gcc/toplev.c:1042
#13 0x0000000000631a26 in do_compile () at ../../gcc/gcc/toplev.c:2247
#14 0x0000000000631a8a in toplev_main (argc=4, argv=0x7ffff4c3a7f8)
    at ../../gcc/gcc/toplev.c:2279
#15 0x0000000000417ecf in main (argc=4, argv=0x7ffff4c3a7f8)
    at ../../gcc/gcc/main.c:35
(gdb)

I'm pretty sure this is with current code.

 - Jay

----------------------------------------
> CC: m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Subject: Re: m3_load/store using bitfields for everything
> Date: Fri, 22 May 2009 09:45:08 +1000
>
> Jay, can you try these again with the latest fix I put in place?
>
> On 20 May 2009, at 09:14, Jay wrote:
>
>>
>> m3_load/store using bitfields for everything caused module-global
>> references to disappear on MIPS64_OPENBSD (all MIPS?). I worked
>> around that by declaring that the module-globals are at least of
>> size 2 * biggest_alignment.
>>
>> It caused module-global references to disappear on ARM_DARWIN as well.
>> I hardcoded RTLinker.traceInit to true, and Flush's len := 0 didn't
>> occur and PutChar eventually failed an array bounds check.
>>
>> Is this just too fragile and the failsafe form should always be used?
>>
>> Or, it fails spectacularly consistently enough that it must also be
>> working consistently enough and leave it?
>>
>> Would "component ref" (ie: struct) and declaring more type
>> information about module segments be a good compromise maybe?
>> Probably.
>>
>> - Jay
>