Hi Brian,
>
> Indeed so. I really don't know what I'm doing with Makefiles, and that was a
> get-me-going hack which also caused Lluis problems building for nixos.
>
> There is a patch in progress to correct this and other issues, but meantime
> you
> could use the patch I posted November 6 to overcome this specific issue.
> (Revert it before applying the soon-to-be-released one, or start again from
> 0.29
> and add both large patches)
>
Argh, my bad, I had missed that patch. Anyhow, looks like we're using
the same linking config, just in different places.
Anyhow, with respect to the wrong assembler calling, it turns out that
the ghdldrv uses its own internal paths in Assembler_Cmd and Linker_Cmd
(see translate/ghdldrv/ghdldrv.adb).
So these would need to be set as a config option from an outside
Makefile later on for possible cross compiling support.
>
>> Unfortunately, not all that smooth on "make install.all":
>> ../../../../libraries/std/textio_body.v87:33:0: internal compiler error:
>> Segmentation fault
>
> Lluis uncovered (and I confirmed) a bug which segfaults some files but not
> others with -O2 (or even -O) which disappears when -On is removed.
> Confirm by looking at the command line for textio_body.v87...
I'm kinda lost here, because I know nothing about all the new GCC 4.x
internals. Let me share some traces, in case someone knows the immediate
answer:
------------------------------------------------------------------
# With -O:
Starting program: /data/src/ghdl/translate/ghdl1-gcc -g -O --std=87
--bootstrap --work=std ../../libraries/std/textio_body.v87
..
Program received signal SIGSEGV, Segmentation fault.
fold_nonarray_ctor_reference (type=0x7ffff6ac1e70, ctor=0x7ffff6b56558,
offset=0, size=32) at /data/src/gcc-4.7.2/gcc/gimple-fold.c:2865
2865 tree byte_offset = DECL_FIELD_OFFSET (cfield);
# cfield is 0x0
# Without -O:
Program received signal SIGSEGV, Segmentation fault.
aggregate_value_p (exp=0x0, fntype=0x0)
at /data/src/gcc-4.7.2/gcc/function.c:1964
1964 const_tree type = (TYPE_P (exp)) ? exp : TREE_TYPE (exp);
------------------------------------------------------------------
The native build runs very smooth, apart from a minor libiberty path fix
(ghdl executable currently links to the system-installed libiberty which
can fail when too old).
So I 'm now unsure whether the mingw32 target is fully up to date
concerning the above processing. Might be the show stopper for me..
Greetings,
- Martin
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss
