[Bug other/55523] New: gencondmd C++ conversion breaks peephole2 predicates use of get_attr_*

[Bug other/55523] New: gencondmd C++ conversion breaks peephole2 predicates use of get_attr_*

[amylaar at gcc dot gnu.org]

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

             Bug #: 55523
           Summary: gencondmd C++ conversion breaks peephole2 predicates
                    use of get_attr_*
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: build
          Severity: normal
          Priority: P3
         Component: other
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: amylaar@gcc.gnu.org
                CC: dnovillo@google.com


Created attachment 28824
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28824
Epiphany patch for improved scheduling

I tried to merge the attached patch into gcc mainline, alas, the build fails:

g++ -c   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
-I../../gcc-190402/gcc -I../../gcc-190402/gcc/build
-I../../gcc-190402/gcc/../include -I../../gcc-190402/gcc/../libcpp/include 
-I../../gcc-190402/gcc/../libdecnumber
-I../../gcc-190402/gcc/../libdecnumber/dpd -I../libdecnumber    \
        -o build/gencondmd.o build/gencondmd.c
../../gcc-190402/gcc/config/epiphany/epiphany.md:1004:45: error:
‘get_attr_sched_use_fpu’ was not declared in this scope
   "get_attr_sched_use_fpu (peep2_next_insn (0))
                                             ^
../../gcc-190402/gcc/config/epiphany/epiphany.md:1006:69: error:
‘get_attr_sched_use_fpu’ was not declared in this scope
    && get_attr_sched_use_fpu (next_active_insn (peep2_next_insn (1)))"
                                                                     ^
../../gcc-190402/gcc/config/epiphany/epiphany.md:1004:45: error:
‘get_attr_sched_use_fpu’ was not declared in this scope
   "get_attr_sched_use_fpu (peep2_next_insn (0))
                                             ^
../../gcc-190402/gcc/config/epiphany/epiphany.md:1006:69: error:
‘get_attr_sched_use_fpu’ was not declared in this scope
    && get_attr_sched_use_fpu (next_active_insn (peep2_next_insn (1)))"
                                                                     ^
make[1]: *** [build/gencondmd.o] Error 1
make[1]: *** Waiting for unfinished jobs....
rm cpp.pod gcov.pod gcc.pod fsf-funding.pod gfdl.pod
make[1]: Leaving directory `/ssd/fsf/bld-epiphany-190402/gcc'
make: *** [all-gcc] Error 2
[amylaar@rowan bld-epiphany-190402]$ g++ --version
g++ (GCC) 4.8.0 20121026 (experimental)


Searching for the revision where the failure starts, I found that is 190402,
when bootstrap was switched to C++.
In earlier versions, there was merely a warning when building gencondmd.o,
which was ignored even when configured with --enable-werror-always.

Now that we bootstrap with C++, this is a hard error.

[Bug other/55523] gencondmd C++ conversion breaks peephole2 predicates use of get_attr_*

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2012-11-29 08:54:31 UTC ---
This is rather a bug in the machine description I think.  Isn't there a target
header that is included from the generated files?

[Bug target/55523] gencondmd C++ conversion breaks peephole2 predicates use of get_attr_*

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
          Component|other                       |target

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-29 12:46:20 UTC ---
Yeah, either you'd need to provide prototype for the function in
epiphany-protos.h, or you shouldn't include those calls in the condition of the
peephole2, but instead in the C sequence do if (!get_attr_*) FAIL;
Including insn-attr.h in the generated gencondmd.c is not an option, that would
be a cyclic dependency (as insn-attr.h generation depends on insn-conditions.md
and insn-conditions.md generation depends on gencondmd.c compilation and that
would need to depend on insn-attr.h).

[Bug target/55523] gencondmd C++ conversion breaks peephole2 predicates use of get_attr_*

[amylaar at gcc dot gnu.org]

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

--- Comment #3 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2012-11-29 14:12:53 UTC ---
(In reply to comment #2)
> Yeah, either you'd need to provide prototype for the function in
> epiphany-protos.h, or you shouldn't include those calls in the condition of the
> peephole2, but instead in the C sequence do if (!get_attr_*) FAIL;
> Including insn-attr.h in the generated gencondmd.c is not an option, that would
> be a cyclic dependency (as insn-attr.h generation depends on insn-conditions.md
> and insn-conditions.md generation depends on gencondmd.c compilation and that
> would need to depend on insn-attr.h).

Well, I do declare the get_attr_* function in epiphany-protos.h for now, but
I think that's a rather ugly work around.  I have to duplicate an
auto-generated prototype.
And writing an identity wrapper for a generated function and then providing
a prototype for the wrapper function isn't really making things any simpler.
There is no fundamental reason why we can't generate the get_attr_* prototypes
before compiling gencondmd, this is just an artifact of how we structured the
generator programs.

I suppose using FAIL would solve the dependency issue, but I'm never quite
sure what that means.  In the context of expanders, it sometimes causes
(caused?) ICEs.
The documentation gives a list of specific instruction patterns that
support FAIL, but doesn't mention peephole2 in this context.

Will a recognized-but-FAILed peephole2 cause different decisions on if,
an if so, which, other peephole2 patterns can match?