[Bug c/59697] New: Function attribute __target_(("no-avx)) work on Windows/mingw but fails on Linux.

[Bug c/59697] New: Function attribute __target_(("no-avx)) work on Windows/mingw but fails on Linux.

[oystein at gnubg dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59697

            Bug ID: 59697
           Summary: Function attribute __target_(("no-avx)) work on
                    Windows/mingw but fails on Linux.
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: oystein at gnubg dot org

Created attachment 31754
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31754&action=edit
Example source code file

Hi,

As I last week tried to compile a file with one function to sse instruction and
another to avx, (see invalid bug report #59657), I tried to solve this by using
function attributes.

static void calculate_sse(float *data, float scale, int size ) __attribute__
((__target__ ("no-avx")));
static void calculate_avx(float *data, float scale, int size );

(Full example code attached)

When I compile this as my mingw system, the produced code is as expected, and
the code runs good at my no-avx Windows-machine.

Compiled with:
 gcc -Wall -O3 -g -mavx sse_test.c -o sse_test

[10:52:28,97 C:\APPL\ssetest]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/appl/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.7.2/configure
--enable-languages=c,c++,ada,fortran,objc,obj-c++
--disable-sjlj-exceptions --wit
h-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry
--enable-libstdcxx-debug --disable-build-poststage1-wi
th-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.7.2 (GCC)

Disassembly of the calculate_sse functions looks like this:
(gdb) disassemble  calculate_sse
Dump of assembler code for function calculate_sse:
   0x0040138c <+0>:     mov    0xc(%esp),%eax
   0x00401390 <+4>:     sar    $0x2,%eax
   0x00401393 <+7>:     lea    -0x1(%eax),%edx
   0x00401396 <+10>:    test   %eax,%eax
   0x00401398 <+12>:    je     0x4013be <calculate_sse+50>
   0x0040139a <+14>:    mov    0x4(%esp),%eax
   0x0040139e <+18>:    movss  0x8(%esp),%xmm0
   0x004013a4 <+24>:    shufps $0x0,%xmm0,%xmm0
   0x004013a8 <+28>:    movaps %xmm0,%xmm1
   0x004013ab <+31>:    nop
   0x004013ac <+32>:    movaps (%eax),%xmm0
   0x004013af <+35>:    mulps  %xmm1,%xmm0
   0x004013b2 <+38>:    movaps %xmm0,(%eax)
   0x004013b5 <+41>:    add    $0x10,%eax
   0x004013b8 <+44>:    dec    %edx
   0x004013b9 <+45>:    cmp    $0xffffffff,%edx
   0x004013bc <+48>:    jne    0x4013ac <calculate_sse+32>
   0x004013be <+50>:    ret
End of assembler dump.

All nice and as expected on Windows/mingw!

I then try the same code with the same function attribute on my Arch linux
laptop (also non-avx CPU). But on this system the calculate_sse functions is
compiled with avx instruction despite the function attribute.

I compile with the same command line:
 gcc -Wall -O3 -g -mavx sse_test.c -o sse_test

[oystein@oysteins-laptop ~]$ gcc --version
gcc (GCC) 4.8.2 20131219 (prerelease)

Produced disassembly of calculate_sse function:
(gdb) disassemble 
Dump of assembler code for function calculate_sse:
   0x08048440 <+0>:    mov    0xc(%esp),%ecx
   0x08048444 <+4>:    mov    0x4(%esp),%eax
   0x08048448 <+8>:    sar    $0x2,%ecx
   0x0804844b <+11>:    test   %ecx,%ecx
   0x0804844d <+13>:    lea    -0x1(%ecx),%edx
   0x08048450 <+16>:    je     0x8048474 <calculate_sse+52>
=> 0x08048452 <+18>:    vbroadcastss 0x8(%esp),%xmm1
   0x08048459 <+25>:    lea    0x0(%esi,%eiz,1),%esi
   0x08048460 <+32>:    vmulps (%eax),%xmm1,%xmm0
   0x08048464 <+36>:    sub    $0x1,%edx
   0x08048467 <+39>:    add    $0x10,%eax
   0x0804846a <+42>:    vmovaps %xmm0,-0x10(%eax)
   0x0804846f <+47>:    cmp    $0xffffffff,%edx
   0x08048472 <+50>:    jne    0x8048460 <calculate_sse+32>
   0x08048474 <+52>:    repz ret 
End of assembler dump.

I'm always unsure what to expect, but at least I did not the behavior to be
different on the two systems. Well, it might not be the Windows/Linux systems
that makes the difference but maybe rather the 4.7.x / 4.8.x gcc-version that
makes the difference. What do I know?

Thanks,
-Øystein
>From gcc-bugs-return-439388-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 06 13:04:29 2014
Return-Path: <gcc-bugs-return-439388-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28390 invoked by alias); 6 Jan 2014 13:04:28 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 28368 invoked by uid 48); 6 Jan 2014 13:04:23 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/59694] no finalization of an unused variable
Date: Mon, 06 Jan 2014 13:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-59694-4-3iWOY2n1FL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59694-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59694-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg00530.txt.bz2
Content-length: 407

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY694

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-01-06
     Ever confirmed|0                           |1

[Bug c/59697] Function attribute __target_(("no-avx)) work on Windows/mingw but fails on Linux.

[oystein at gnubg dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59697

--- Comment #1 from Øystein Schønning-Johansen <oystein at gnubg dot org> ---
Follow up:

I try the same code on a RedHat 6.5 64bit workstation with GCC4.4.

st-lx794988(ojohans) -/ojohans 37> gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) 

On this system the sse function is also translated to avx instructions. :-(

00000000004004f0 <calculate_sse>:
  4004f0:    c1 fe 02                 sar    $0x2,%esi
  4004f3:    85 f6                    test   %esi,%esi
  4004f5:    74 2e                    je     400525 <calculate_sse+0x35>
  4004f7:    83 ee 01                 sub    $0x1,%esi
  4004fa:    c5 f8 c6 c0 00           vshufps $0x0,%xmm0,%xmm0,%xmm0
  4004ff:    48 c1 e6 04              shl    $0x4,%rsi
  400503:    48 8d 44 37 10           lea    0x10(%rdi,%rsi,1),%rax
  400508:    0f 1f 84 00 00 00 00     nopl   0x0(%rax,%rax,1)
  40050f:    00 
  400510:    c5 f8 28 0f              vmovaps (%rdi),%xmm1
  400514:    c5 f0 59 c8              vmulps %xmm0,%xmm1,%xmm1
  400518:    c5 f8 29 0f              vmovaps %xmm1,(%rdi)
  40051c:    48 83 c7 10              add    $0x10,%rdi
  400520:    48 39 c7                 cmp    %rax,%rdi
  400523:    75 eb                    jne    400510 <calculate_sse+0x20>
  400525:    f3 c3                    repz retq 
  400527:    66 0f 1f 84 00 00 00     nopw   0x0(%rax,%rax,1)


-Øystein
>From gcc-bugs-return-439610-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jan 08 10:25:28 2014
Return-Path: <gcc-bugs-return-439610-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17634 invoked by alias); 8 Jan 2014 10:25:27 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 17563 invoked by uid 48); 8 Jan 2014 10:25:23 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/59584] [4.8/4.9 Regression]: cannot handle define_split for insn emitted for __builtin_stack_restore
Date: Wed, 08 Jan 2014 10:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P5
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: blocked
Message-ID: <bug-59584-4-mYZYNLexkQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59584-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59584-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg00752.txt.bz2
Content-length: 810

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY584

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|58956                       |

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I still think this is not the correct definition of regression, I believe
regression is regressing against released compiler version.  If somebody
commits a wrong change that magically fixes something and has to be reverted
the next day, the magically fixed issue doesn't all of sudden become a
regression because of that.  Not to mention that Richard's change has not been
a fix for that, just unrelated change that made the problem in the cris port
latent.

[Bug target/59697] Function attribute __target_(("no-avx)) does not work

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59697

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
            Summary|Function attribute          |Function attribute
                   |__target_(("no-avx)) work   |__target_(("no-avx)) does
                   |on Windows/mingw but fails  |not work
                   |on Linux.                   |
           Keywords|                            |rejects-valid
   Last reconfirmed|                            |2021-09-16
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.  The target header files don't turn off what was turned on via the
command line which causes the inline functions not to be usable that way.

In older versions of GCC this produced wrong code but in newer versions GCC
rejects the code.

Note clang has the same behavior ...