Re: [Nasm-devel] NASM 2.12rc3 - FINAL RELEASE CANDIDATE

[H. P. A. <hp...@zy...>]

On February 26, 2016 11:34:22 PM PST, "H. Peter Anvin" <hp...@zy...> wrote:
>On 02/24/16 05:30, Ismail Donmez wrote:
>> H. Peter Anvin <hpa <at> zytor.com> writes:
>>
>>>
>>> I have just tagged NASM 2.12rc3.  I am hoping this is the final rc
>>> before a 2.12 release.
>>>
>>> If you can, please test it out as I would like to make a final 2.12
>>> release as soon as possible.
>>
>> This might be too late to report this (I originally reported at
>> forum.nasm.us but with no reply) but with nams.git and 2.12rc7 all
>tests
>> fail for me on openSUSE Tumbleweed x86-64, here is one example:
>>
>> ? gdb --args ../nasm -fbin -ovmread.bin vmread.asm
>> Reading symbols from ../nasm...done.
>> (gdb) r
>> Starting program: /havana/t/n/nasm/nasm -fbin -ovmread.bin vmread.asm
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> __memcpy_sse2_unaligned () at
>../sysdeps/x86_64/multiarch/memcpy-sse2-
>> unaligned.S:36
>> 36      ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S: No such
>file
>> or directory.
>> (gdb) bt
>> #0  __memcpy_sse2_unaligned () at
>../sysdeps/x86_64/multiarch/memcpy-sse2-
>> unaligned.S:36
>> #1  0x0000000000407915 in saa_wbytes (s=0x7a5db0,
>data=0x7ffd96f364d0,
>> len=18446744073709551612) at saa.c:132
>> #2  0x0000000000416b30 in bin_out (segto=2, data=0x7ffd96f364d0,
>> type=OUT_RAWDATA, size=18446744073709551612, segment=-1, wrt=-1) at
>> output/outbin.c:797
>> #3  0x000000000040a8f6 in out (offset=32, segto=2,
>data=0x7ffd96f364d0,
>> type=OUT_RAWDATA, size=18446744073709551612, segment=-1, wrt=-1) at
>> assemble.c:372
>> #4  0x000000000040e4fc in gencode (segment=2, offset=32, bits=64,
>> ins=0x7ffd96f367a0, temp=0x4bd9f0 <instrux_VMREAD+80>, insn_end=36)
>at
>> assemble.c:1945
>> #5  0x000000000040b436 in assemble (segment=2, offset=28, bits=64,
>cp=...,
>> instruction=0x7ffd96f367a0, output=0x51e660 <of_bin>, error=0x405fe6
>> <nasm_error>, listgen=0x51f7c0 <nasmlist>) at assemble.c:692
>> #6  0x00000000004054ad in assemble_file (fname=0x51f8c0 <inname>
>> "vmread.asm", depend_ptr=0x0) at nasm.c:1761
>> #7  0x00000000004026c4 in main (argc=4, argv=0x7ffd96f36b48) at
>nasm.c:466
>>
>> Tried with gcc 5.3.1, gcc-6 trunk and clang 3.8. All gives the same
>> problem.
>>
>> Any help is appreciated.
>>
>
>I cannot reproduce this with gcc 5.3.1 or clang 3.5 on Fedora.  It
>would 
>be highly useful if you could:
>
>a) configure with --enable-werror
>b) make sure you do "make clean" between trying compilers
>c) try compiling with -O0
>d) try changing uint64_t on line 311 of assemble.c to int64_t
>
>The most logical explanation is that the compiler miscompiles 
>abs((int)size) where size is uint64_t.  However, this is certainly not 
>true for all the three compilers listed.
>
>If we can narrow this down to a specific compiler it might be
>worthwhile 
>to make a bug report.
>
>	-hpa

One more thing: try adding the -fwrap option to see if that fixes the problem, especially if the problem goes away with -O0.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.