[Bug ada/66205] New: gnatbind generates invalid code when finalization is enabled in restricted runtime

[Bug ada/66205] New: gnatbind generates invalid code when finalization is enabled in restricted runtime

[simon at pushface dot org]

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

            Bug ID: 66205
           Summary: gnatbind generates invalid code when finalization is
                    enabled in restricted runtime
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ada
          Assignee: unassigned at gcc dot gnu.org
          Reporter: simon at pushface dot org
  Target Milestone: ---

Created attachment 35567
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35567&action=edit
Patch to gcc/ada/bindgen.adb

This is on 4.9.1 compiled for arm-eabi on Mac OS X Mavericks (Darwin 13).
Please note that the same problem occurs with 5.1.0.

package System has

pragma Profile (Ravenscar);
pragma Restrictions (No_Enumeration_Maps);
pragma Restrictions (No_Exception_Propagation);
pragma Restrictions (No_Recursion);

and the result of a gprbuild is

gprbuild -p -P testbed
gprbind testbed.bexch
arm-eabi-gnatbind testbed.ali
arm-eabi-gcc -c b__testbed.adb
b__testbed.adb:31:14: "Is_Elaborated" is undefined (more references follow)
gprbind: compilation of binder generated file failed
gprbuild: unable to bind testbed.adb

which happens because bindgen.adb has at :2497

         if not Suppress_Standard_Library_On_Target then
            WBI ("   Is_Elaborated : Boolean := False;");
         end if;

but at :408 in the generation of adafinal

      if not CodePeer_Mode then
         WBI ("      if not Is_Elaborated then");
         WBI ("         return;");
         WBI ("      end if;");
         WBI ("      Is_Elaborated := False;");
      end if;

I’ve worked out a patch for this, but I’m confused about when to use
Suppress_Standard_Library_On_Target vs Configurable_Run_Time_On_Target vs
Configurable_Run_Time_Mode to determine that adafinal will never actually be
called & hence needn’t do anything.

Not sure whether __gnat_initialize, __gnat_finalize are expected (they aren’t
in the AdaCore arm-eabi libraries), so I’ve suppressed them too.
>From gcc-bugs-return-486683-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 19 14:56:13 2015
Return-Path: <gcc-bugs-return-486683-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 50324 invoked by alias); 19 May 2015 14:56:12 -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 49912 invoked by uid 48); 19 May 2015 14:56:07 -0000
From: "gil.hur at sf dot snu.ac.kr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
Date: Tue, 19 May 2015 14:56:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gil.hur at sf dot snu.ac.kr
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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:
Message-ID: <bug-65752-4-2aW1vzFm2c@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65752-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65752-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: 2015-05/txt/msg01523.txt.bz2
Content-length: 1794

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide752

--- Comment #21 from Chung-Kil Hur <gil.hur at sf dot snu.ac.kr> ---
(In reply to Marek Polacek from comment #20)
> (In reply to Chung-Kil Hur from comment #19)
> > (In reply to rguenther@suse.de from comment #18)
> > > On Tue, 19 May 2015, gil.hur at sf dot snu.ac.kr wrote:
> > >
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?ide752
> > > >
> > > > --- Comment #17 from Chung-Kil Hur <gil.hur at sf dot snu.ac.kr> ---
> > > > Hi Richard,
> > > >
> > > > I modified the example further.
> > > >
> > > > #include <stdio.h>
> > > >
> > > > int main() {
> > > >   int x = 0;
> > > >   uintptr_t xp = (uintptr_t) &x;
> > > >   uintptr_t i, j;
> > > >
> > > >   for (i = 0; i < xp; i++) { }
> > > >   j = i;
> > > >   /* The following "if" statement is never executed because j == xp */
> > > >   if (j != xp) {
> > > >     printf("hello\n");
> > > >     j = xp;
> > > >   }
> > >
> > > Here j is always xp and thus ...
> > >
> >
> > Why is "j" always "xp"?
> > Since "hello" is not printed, "j = xp;" is not executed.
>
> Because that "if (j != xp)" guarantees it.

OK. here is another modification.

#include <stdio.h>

int main() {
  int x = 0;
  uintptr_t xp = (uintptr_t) &x;
  uintptr_t i, j;

  for (i = 0; i < xp; i++) { }
  j = i;

  *(int*)j = 15;

  /* The following "if" statement is never executed because j == xp */
  if (j != xp) {
    printf("hello\n");
    j = xp;
  }

  *(int*)((xp+i)-j) = 15;

  printf("%d\n", x);
}

This program just prints "0".

So we know that "*(int*)j = 15;" is not executed and thus "j == xp" is not
true.

Then, can the following statement change "j" even if the printf is not
executed?

if (j != xp) {
   printf("hello\n");
   j = xp;
}

If not, how can "j == xp" suddenly hold?

[Bug ada/66205] gnatbind generates invalid code when finalization is enabled in restricted runtime

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org,
                   |                            |ramana at gcc dot gnu.org

--- Comment #1 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Eric,

Would you be able to comment further ?

Ramana

[Bug ada/66205] gnatbind generates invalid code when finalization is enabled in restricted runtime

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|arm-eabi                    |
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-06-11
               Host|x86_64-apple-darwin13       |
     Ever confirmed|0                           |1
           Severity|normal                      |enhancement

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
This combination is probably not supported.  Nothing to do with ARM in any
case.

[Bug ada/66205] gnatbind generates invalid code when finalization is enabled in restricted runtime

[simon at pushface dot org]

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

--- Comment #4 from simon at pushface dot org ---
Agree it’s not ARM-specific, but it _is_ Ada-restricted-runtime-specific.

I realise that this isn’t a configuration supported by AdaCore for their
customers (there’d have been no need for this PR if it was!); does it have to
be unsupported by GCC then?

I’ve managed to make what I think is a very-low-quality workround by
(a) not suppressing the standard library on the target in system.ads
(b) including a C source file in the RTS which provides dummies for the
irrelevant-in-this-context __gl_* objects which bindgen now references.

Anyway, now I have my copyright assignment in place, I’ll submit the patch. I’m
not sure what regression tests would be appropriate: I propose to apply the
patch and bootstrap/make check-ada for Darwin, that will show I haven’t broken
the normal case, and I can repeat the build for arm-eabi and build a null main
program.

If there’s no chance that this patch will ever be accepted, please let me know
before I embark on this!
>From gcc-bugs-return-488798-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 16:00:04 2015
Return-Path: <gcc-bugs-return-488798-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 49783 invoked by alias); 11 Jun 2015 16:00:04 -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 49635 invoked by uid 55); 11 Jun 2015 15:59:59 -0000
From: "ebotcazou at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/66252] [6 regression] bootstrap comparison failures on sparc-linux
Date: Thu, 11 Jun 2015 16:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ebotcazou at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ebotcazou at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66252-4-rTQ4Z3oBdQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66252-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66252-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: 2015-06/txt/msg01130.txt.bz2
Content-length: 1035

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf252

--- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Thu Jun 11 15:59:27 2015
New Revision: 224386

URL: https://gcc.gnu.org/viewcvs?rev"4386&root=gcc&view=rev
Log:
        PR bootstrap/66252
        * config/sparc/sparc.c (hard_regno_mode_classes): Add ??? comment.
        * config/sparc/sparc.md (zero_extendsidi2_insn_sp32): Use single order.
        (*addx_extend_sp32): Fix pasto.
        (*subx_extend): Rename into...
        (*subx_extend_sp32): ...this.
        (*adddi3_extend_sp32): Add earlyclobber.
        (*subdi3_insn_sp32): Likewise.
        (*subdi3_extend_sp32): Likewise.
        (*and_not_di_sp32): Likewise.
        (*or_not_di_sp32): Likewise.
        (*xor_not_di_sp32): Likewise.
        (*negdi2_sp32): Likewise.
        (*one_cmpldi2_sp32): Likewise.

Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/sparc/sparc.c
    branches/gcc-4_9-branch/gcc/config/sparc/sparc.md

[Bug ada/66205] gnatbind generates invalid code when finalization is enabled in restricted runtime

[charlet at adacore dot com]

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

--- Comment #5 from charlet at adacore dot com <charlet at adacore dot com> ---
> I???ve managed to make what I think is a very-low-quality workround by
> (a) not suppressing the standard library on the target in system.ads
> (b) including a C source file in the RTS which provides dummies for the
> irrelevant-in-this-context __gl_* objects which bindgen now
> references.
> 
> Anyway, now I have my copyright assignment in place, I???ll submit the
> patch. I???m
> not sure what regression tests would be appropriate: I propose to apply the
> patch and bootstrap/make check-ada for Darwin, that will show I haven???t
> broken
> the normal case, and I can repeat the build for arm-eabi and build a null main
> program.
> 
> If there???s no chance that this patch will ever be accepted, please let me
> know before I embark on this!

Certainly a very low quality workaround won't be accepted, this would cause
too much maintenance troubles.

Arno

Re: [Bug ada/66205] gnatbind generates invalid code when finalization is enabled in restricted runtime

[Arnaud Charlet]

> I???ve managed to make what I think is a very-low-quality workround by
> (a) not suppressing the standard library on the target in system.ads
> (b) including a C source file in the RTS which provides dummies for the
> irrelevant-in-this-context __gl_* objects which bindgen now
> references.
> 
> Anyway, now I have my copyright assignment in place, I???ll submit the
> patch. I???m
> not sure what regression tests would be appropriate: I propose to apply the
> patch and bootstrap/make check-ada for Darwin, that will show I haven???t
> broken
> the normal case, and I can repeat the build for arm-eabi and build a null main
> program.
> 
> If there???s no chance that this patch will ever be accepted, please let me
> know before I embark on this!

Certainly a very low quality workaround won't be accepted, this would cause
too much maintenance troubles.

Arno

[Bug ada/66205] gnatbind generates invalid code when finalization is enabled in restricted runtime

[simon at pushface dot org]

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

--- Comment #6 from simon at pushface dot org ---
(In reply to charlet@adacore.com from comment #5)

> Certainly a very low quality workaround won't be accepted, this would cause
> too much maintenance troubles.

Sorry for the confusion.

The patch I propose is the one attached to this PR; the VLQ workround is what I
will have to do, not as part of GCC of course, if the patch is rejected.

Note the workround would appear only in a restricted runtime, which would be
like AdaCore’s restricted runtimes in that it wouldn’t be part of the official
GCC tree, even though the copyright would be assigned to FSF.
>From gcc-bugs-return-488804-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 16:23:33 2015
Return-Path: <gcc-bugs-return-488804-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 48962 invoked by alias); 11 Jun 2015 16:23:32 -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 44170 invoked by uid 48); 11 Jun 2015 16:23:29 -0000
From: "ulysse.beaugnon at ens dot fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66515] New: g++ segfaults when creating an std::initializer_list
Date: Thu, 11 Jun 2015 16:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ulysse.beaugnon at ens dot fr
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created
Message-ID: <bug-66515-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01136.txt.bz2
Content-length: 2675

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

            Bug ID: 66515
           Summary: g++ segfaults when creating an std::initializer_list
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ulysse.beaugnon at ens dot fr
  Target Milestone: ---

Created attachment 35764
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35764&action=edit
Preprocessed input triggering the segfault

g++ fails when run on the input attached:

$> g++ -std=c++11 bug_gcc.ii
bug_gcc.cc: In function ‘int main()’:
bug_gcc.cc:12:49: internal compiler error: Segmentation fault
   std::initializer_list<type_t> v = { { get() } };

Version of GCC:
$> g++ -std=c++11 -v bug_gcc.ii
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-5-20150519/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --with-default-libstdcxx-abi=c++98
Thread model: posix
gcc version 5.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-std=c++11' '-v' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/cc1plus -fpreprocessed bug_gcc.ii
-quiet -dumpbase bug_gcc.ii -mtune=generic -march=x86-64 -auxbase bug_gcc
-std=c++11 -version -o /tmp/ccg4bTLJ.s
GNU C++11 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
        compiled by GNU C version 5.1.0, GMP version 6.0.0, MPFR version
3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++11 (GCC) version 5.1.0 (x86_64-unknown-linux-gnu)
        compiled by GNU C version 5.1.0, GMP version 6.0.0, MPFR version
3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2502e86cc323bb15ad071f82f9632779
>From gcc-bugs-return-488805-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 11 16:52:01 2015
Return-Path: <gcc-bugs-return-488805-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 101458 invoked by alias); 11 Jun 2015 16:52:01 -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 101392 invoked by uid 48); 11 Jun 2015 16:51:57 -0000
From: "howarth.at.gcc at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66509] the new clang-based assembler in Xcode 7 on 10.11 fails on the libjava/java/lang/reflect/natArray.cc file from FSF gcc 5.1 at -m32
Date: Thu, 11 Jun 2015 16:52:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: howarth.at.gcc at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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:
Message-ID: <bug-66509-4-167GCMJBar@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66509-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66509-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: 2015-06/txt/msg01137.txt.bz2
Content-length: 391

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf509

--- Comment #10 from Jack Howarth <howarth.at.gcc at gmail dot com> ---
The clang developers suggest the test...

filds (%ebp)

which is compilable with the clang-based assembler at both -m32 and -m64.

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-June/043463.html

fists (%ebp)

also appears to work for the second part of the test.