[Bug c++/45303] New: Compile error when not using -ftree-ter

[Bug c++/45303] New: Compile error when not using -ftree-ter

[jobnoorman at gmail dot com]

I have the following program:

main.cpp
--------------------------------------------------
    struct Foo
    {
        void foobar() {}
    };

    typedef void (*plain_foobar_t)(Foo*);

    int main()
    {
        asm("push %0;"
            :
            : "i"((plain_foobar_t)&Foo::foobar));
    }
--------------------------------------------------
If I compile this with

    g++ -Wno-pmf-conversions main.cpp

I get the following:

    main.cpp: In function 'void test()':
    main.cpp:12: warning: asm operand 0 probably doesn't match constraints
    main.cpp:12: error: impossible constraint in 'asm'

If I compile it using -ftree-ter, like this:

    g++ -Wno-pmf-conversions -ftree-ter main.cpp

I do not get any error.

Some info about my system:

$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)

$ uname -a
Linux squatpc 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 06:07:29 UTC 2010
i686 GNU/Linux

I suspect this is a bug, but since I'm not completely sure, I posted this
question on the mailing list
(http://gcc.gnu.org/ml/gcc-help/2010-08/msg00126.html) but I didn't get any
answers.


-- 
           Summary: Compile error when not using -ftree-ter
           Product: gcc
           Version: 4.4.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jobnoorman at gmail dot com


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

[Bug c++/45303] Compile error when not using -ftree-ter

[jakub at gcc dot gnu dot org]

------- Comment #1 from jakub at gcc dot gnu dot org  2010-08-17 09:21 -------
IMHO this isn't a bug, to simplify that into an integer you really need some
optimizations.  The conversion looks very weird, if you use something saner
like (void *)&Foo::foobar, it will even work with -O0.


-- 


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

[Bug c++/45303] Compile error when not using -ftree-ter

[redi at gcc dot gnu dot org]

------- Comment #2 from redi at gcc dot gnu dot org  2010-08-17 09:38 -------
(In reply to comment #1)
> IMHO this isn't a bug, to simplify that into an integer you really need some
> optimizations.  The conversion looks very weird, if you use something saner

The conversion uses this extension
http://gcc.gnu.org/onlinedocs/gcc/Bound-member-functions.html

> like (void *)&Foo::foobar, it will even work with -O0.

Does that cast still use the extension?


-- 


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

[Bug c++/45303] Compile error when not using -ftree-ter

[redi at gcc dot gnu dot org]

------- Comment #3 from redi at gcc dot gnu dot org  2010-08-17 09:42 -------
Looking at the diagnostics issued when -pedantic is added, I think the right
conversion is

(void*)(plain_foobar_t)&Foo::foobar

That still uses the G++ extension, and doesn't give the asm error even without
optimisation.


-- 


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

[Bug c++/45303] Compile error when not using -ftree-ter

[jobnoorman at gmail dot com]

------- Comment #4 from jobnoorman at gmail dot com  2010-08-17 10:04 -------
(In reply to comment #1)
> IMHO this isn't a bug, to simplify that into an integer you really need some
> optimizations.  The conversion looks very weird, if you use something saner
> like (void *)&Foo::foobar, it will even work with -O0.

I still think it's kind of weird to have an error without optimizations and
none with. Shouldn't an error always be an error, no matter what the
optimizations are?


-- 


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

[Bug c++/45303] Compile error when not using -ftree-ter

[jakub at gcc dot gnu dot org]

------- Comment #5 from jakub at gcc dot gnu dot org  2010-08-17 10:16 -------
For inline-asm?  Certainly not.  Consider much simpler:
void foo (void)
{
  int i;
  i = 6;
  asm volatile ("" : : "i" (i));
}
which will work with -O and above, but not for -O0, for exactly the same
reason.


-- 


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

[Bug c++/45303] Compile error when not using -ftree-ter

[jobnoorman at gmail dot com]

------- Comment #6 from jobnoorman at gmail dot com  2010-08-17 10:49 -------
(In reply to comment #5)
> For inline-asm?  Certainly not. Consider much simpler:
> void foo (void)
> {
>   int i;
>   i = 6;
>   asm volatile ("" : : "i" (i));
> }
> which will work with -O and above, but not for -O0, for exactly the same
> reason.

IMHO, your example should always give an error. The "i" constraint is to be
used for constant integer operands. A variable of type "int" just isn't
constant, even if GCC is smart enough to optimize the variable away and use a
constant instead. Your example will always work if you make "i" of type "const
int".

I also think there is an important difference between your example and mine:
the expression "(plain_foobar_t)&Foo::foobar" is a constant expression (please
correct me if I'm wrong) and thus should always be allowed when using the "i"
constraint.


-- 


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

[Bug c++/45303] Compile error when not using -ftree-ter

[jobnoorman at gmail dot com]

------- Comment #7 from jobnoorman at gmail dot com  2010-08-18 14:03 -------
(In reply to comment #3)
> Looking at the diagnostics issued when -pedantic is added, I think the right
> conversion is
> 
> (void*)(plain_foobar_t)&Foo::foobar
> 
> That still uses the G++ extension, and doesn't give the asm error even without
> optimisation.

That looks like a workaround to me.

How could it ever be that "(void*)some_expression" is accepted as a constant
expression when "some_expression" is not?


-- 


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

[Bug c++/45303] Compile error when not using -ftree-ter

[ian at airs dot com]

------- Comment #8 from ian at airs dot com  2010-08-18 17:44 -------
Just for the record, I'm with Jakub: the general rule should be that "r" always
works for a value that fits in a register, and anything else requires enabling
optimization to work reliably.

I don't see why we should sign up to handle all constants for inline asm when
not optimizing.  It seems like an unusual edge case, a bunch of work for really
minimal benefit.

Changing the example in comment #5 to reliably fail will break real code for no
useful benefit and is thus contra-indicated.


-- 


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

[Bug c++/45303] Compile error when not using -ftree-ter

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2010-08-18 22:42 -------


*** This bug has been marked as a duplicate of 23200 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


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