#1245 abnormal termination(global variable __m128i type)

OTHER
closed
binutils (105)
fixed
Known_bugs
2013-01-29
2009-01-24
Kelley567
No

When I declare __m128i type by global variable and use it, it is terminated
abnormally.
There does not seem to be no problem when I compile it in g++.

Environment:
gcc 4.3.0(20080305) alpha-testing
binutils-2.19
w32api-3.13
mingwrt-3.15.2
Windows XP Home Edition SP3(Japanese)

Discussion

  • Kelley567

    Kelley567 - 2009-01-24
     
  • Kelley567

    Kelley567 - 2009-01-24

    It is an additional report.
    There was not a problem in MinGW on Debian GNU/Linux(lenny).

    i586-mingw32msvc-gcc -v
    Using built-in specs.
    Target: i586-mingw32msvc
    Configured with: /build/buildd/mingw32-4.2.1.dfsg/build_dir/src/gcc-4.2.1-2-dfsg/configure -v --prefix=/usr --target=i586-mingw32msvc --enable-languages=c,c++ --enable-threads --enable-sjlj-exceptions --disable-multilib --enable-version-specific-runtime-libs
    Thread model: win32
    gcc version 4.2.1-sjlj (mingw32-2)

     
  • Kelley567

    Kelley567 - 2009-01-27

    This problem happened in gcc-3.4.5.
    It seems to be a problem of binutils not gcc.
    This seems to be a problem of GNU ld (GNU Binutils) 2.19
    When it was GNU ld version 2.17.50 20060824, there was not a problem.

     
  • Kelley567

    Kelley567 - 2009-01-27
    • labels: 103944 --> binutils
     
  • Kelley567

    Kelley567 - 2009-01-27

    Reference information
    MinGW on Debian GNU/Linux(lenny)
    i586-mingw32msvc-ld -v
    GNU ld (GNU Binutils) 2.18.50.20080109
    It is also no problem.

     
  • Kelley567

    Kelley567 - 2009-01-28

    In version 2.18.50-20071123 - 2.19 of binutils, the same problem seems to happen.

    The package which I confirmed is as follows.
    binutils-2.19-mingw32-bin.tar.gz
    binutils-2.18.50-20080109-2.tar.gz
    binutils-2.18.50-20080109.tar.gz
    binutils-2.18.50-20071123.tar.gz

    #This English used the translation site.
    #There may be funny expression.

     
  • Keith Marshall

    Keith Marshall - 2009-01-30

    Can you please provide a minimal, but complete and self-contained test case, which illustrates this problem, and includes detailed instructions on how to reproduce it? Without such detail, there really isn't much we can do to progress this. (If, as you seem to have determined, this actually is a binutils issue, you will need to provide such information anyway, when we direct you to submit a report to the binutils project).

    Additionally, can you please be more specific as to which of the binutils versions you have tested exhibit this issue, and which behave as expected, for this isn't at all clear from your previous comments?

    FWIW, using *our* cross-compiler build on Ubuntu-8.04, the code you *have* provided as a test case doesn't even compile for me:

    $ mingw32-gcc --version
    mingw32-gcc (GCC) 3.4.5 (mingw-vista special r2)
    Copyright (C) 2004 Free Software Foundation, Inc.
    [...]

    $ mingw32-ld --version
    GNU ld (GNU Binutils) 2.19
    Copyright 2007 Free Software Foundation, Inc.
    [...]

    $ mingw32-gcc test-sse2.c
    test-sse2.c:3: error: syntax error before "dummy"
    test-sse2.c:3: warning: data definition has no type or storage class

     
  • Kelley567

    Kelley567 - 2009-01-30

    Thank you for commenting.

    I add a test code.
    Please compile it with the following option.
    gcc -o test-sse2.exe test-sse2.c -msse2
    gcc -o test-sse2b.exe test-sse2b.c -msse2

    In addition, this does not reappear in the cross compilation environment (Debian lenny).
    It is the problem that it met with in MinGW on Windows.

    $ gcc -v
    Reading specs from c:/mingw/bin/../lib/gcc/mingw32/3.4.5/specs
    Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug
    Thread model: win32
    gcc version 3.4.5 (mingw-vista special r3)

    $ ld -v
    GNU ld (GNU Binutils) 2.19

    #This English used the translation site.
    #There may be funny expression.

     
  • Kelley567

    Kelley567 - 2009-01-30
     
  • Kelley567

    Kelley567 - 2009-01-30

    In the case of binutils 2.19, test-sse2b.exe outputs SIGSEGV.
    This is the movement that I do not expect.

    test-sse2b.exe outputs nothing and, in the case of binutils-2.17, is finished as expected.
    test-sse2b.exe outputs nothing and, in mingw32 package (binutils-2.18.50.20080109) of Debian lenny, is finished as expected.
    Is it still incomprehensible?

    As a result of being as good as expected
    binutils-2.17(windows)
    binutils-2.18.50.20080109(Debian lenny)

    As a result of not expecting it
    binutils-2.19(windows)
    binutils-2.18.50-20080109-2(windows)
    binutils-2.18.50-20080109(windows)
    binutils-2.18.50-20071123(windows)

     
  • Keith Marshall

    Keith Marshall - 2009-01-30

    Ok. This is totally weird. I've used your original test case, compiled with my current gcc-3.4.5-mingw32 compiler, with mingwrt-3.15.1, w32api-3.12 and binutils-2.19, as:

    $ mingw32-gcc -msse2 test-sse2.c

    Running ./a.exe under wine results in a SIGSEGV, with access violation reading address 0xffffffff. I then switched to a prior installation, differing only in that it still has binutils built from binutils-2.18.50-20080109-2-src.tar.gz, and repeated this with the same result. Finally, I built a third mingw32-gcc suite, again identical, except with binutils from binutils-2.17.50-20060824-1-src.tar.gz, and confirmed your finding of no access violation for this case.

    However, on reverting to using my current installation, with binutils-2.19, and completely untouched in any way, I am no longer able to reproduce the access violation -- behaviour is now as expected for both binutils-2.17.50 and binutils-2.19! I can, however, still consistently reproduce the failure with binutils-2.18.50, (both my original installation, and recently rebuilt).

    I see similar results with your second test case: fails with binutils-2.18.50, but not with either binutils-2.17.50 or binutils-2.19.

    I am at a complete loss to explain this, and don't know how to progress it further; maybe Chris can follow up on a native MSW host.

     
  • Keith Marshall

    Keith Marshall - 2009-01-30
    • assigned_to: nobody --> ir0nh34d
     
  • Chris Sutcliffe

    Chris Sutcliffe - 2009-02-01

    This indeed seems to be a regression with 2.19, since I can confirm the same behaviour. 2.17.50-20060824-1 works as expected.

    kelley567, can you please open a bug report in the binutils tracker (http://sourceware.org/bugzilla/)?

     
  • Danny Smith

    Danny Smith - 2009-02-01

    This appears to be a dup of gcc bug report:
    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216

    It is not really a gcc bug or a binutils bug, but rather a "feature" of the PE-COFF object format, which does not support aligned data in .comm.

    An immediate workaround is to compile with -fno-common to put unitialized data in .bss (which can be aligned) rather than .comm. or to just add __attribute__((no_common)) to sse[2] data decls.

    Danny

     
  • Kelley567

    Kelley567 - 2009-02-01

    Thank you for Chris, comment.
    I was relieved to know that there was not a problem only for my environment.

    Thank you for danny, splendid information.

    I think like a case of the gcc bug report that you taught.
    Is it caused by the fact that PE COFF format does not support aligned data in .comm?
    And will developers of gcc be good by understanding to be dealing with this problem?

    In addition, you showed two measures plan of the present about this problem.
    1. attribute:no_common
    2. compile option:-fno-common

    and
    3.#pragma gcc optimize (no_common)
    It was introduced to gcc bug report, too.
    Unfortunately 1 and 3 did not function well in my environment.

    warning: `no_common' attribute directive ignored

    As for 2, it followed that I was as good as expected.

    I think that it is a same problem reported in GCC Bugzilla Bug 37216.
    Therefore to be release of future MinGW will be that it is settled naturally.
    And I think that it is not necessary to report it to developers of binutils and gcc.
    Is it OK?

     
  • Kelley567

    Kelley567 - 2009-02-02
     
  • Kelley567

    Kelley567 - 2009-02-02

    There was the case which I cannot evade even if I used the -fno-common option.
    I attached test-sse2c.c.

    There seems to have no me except that I initialize a variable to evade this.
    About this case, will you report it in bugzilla of gcc?
    In addition, is there the measures plan by the present with this case besides initialization what it is?

    # Because I was weak in English, I was not able to confirm it.

     
  • Danny Smith

    Danny Smith - 2009-02-02

    test-sse2c.c is the local common (.lcomm) variant of the bug.

    It is fixed in binutils 2.19
    (http://sourceware.org/ml/binutils/2008-09/msg00010.html)
    and in the upcoming gcc 4.4.0
    (http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00229.html)

    Danny

     
  • Kelley567

    Kelley567 - 2009-02-02

    Thank you.
    I decide to wait for the next release of MinGW.

     
  • Earnie Boyd

    Earnie Boyd - 2012-08-03

    Thank you for your interest in the MinGW project. This post is old and I am therefore closing it, if problems still exist
    please resubmit.

    The MinGW Project Administrators.

     
  • Earnie Boyd

    Earnie Boyd - 2012-08-03
    • status: open --> closed-out-of-date
     
  • Earnie Boyd

    Earnie Boyd - 2013-01-29
    • status: closed-out-of-date --> closed
    • resolution: --> fixed
    • category: --> Known_bugs
    • milestone: --> OTHER
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks