[Bug c/93206] New: non-delegitimized UNSPEC generated for C program on PowerPc with current mainline GCC tree

cel at us dot ibm.com gcc-bugzilla@gcc.gnu.org
Wed Jan 8 21:24:00 GMT 2020


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

            Bug ID: 93206
           Summary: non-delegitimized UNSPEC generated for C program on
                    PowerPc with current mainline GCC tree
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: cel at us dot ibm.com
  Target Milestone: ---

Created attachment 47616
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47616&action=edit
GCC src tree patch with test case

Issue 61879 appears to be similar, as does 81280 but for different platforms.

The following GCC patch demonstrates a bug in the GCC variable tracking logic
on the PowerPC platform, Power 9 processor but is probably independent of the
processor type.

The bug was found as part of some internal development.  The key parts of
the work were backported to demonstrate the issue on current mainline as
of commit

r279927 | danglin | 2020-01-06 17:48:42 -0600 (Mon, 06 Jan 2020) | 6 lines

        * config/pa/pa.md: Revert change to use ordered_comparison_operator
        instead of cmpib_comparison_operator in cmpib patterns.
        * config/pa/predicates.md (cmpib_comparison_operator): Revert removal
        of cmpib_comparison_operator.  Revise comment.

With this patch applied, gcc generates the following warning during
compilation.

gcc -g -mcpu=future -O2 var-tracking-bug-test.c -o var-tracking-bug-test
var-tracking-bug-test.c: In function ‘main’:
var-tracking-bug-test.c:4:5: note: non-delegitimized UNSPEC UNSPEC_FOO (170)
fou
nd in variable location
    4 | int main ()
      |     ^~~~
var-tracking-bug-test.c:4:5: note: non-delegitimized UNSPEC UNSPEC_FOO (170)
fou
nd in variable location

The test case must be compiled with -O2 to get the message.  If you use
-O2 and -fno-var-tracking the note is not printed.

Note, the patch adds RTL support for a V4SI and a V2DI future instruction.

The following is from the dwarf2out phase in dump file
var-tracking-bug-test.c.311r.dwarf2

      (expr_list (use (reg:DI 2 2))
        (expr_list:DI (use (reg:DI 3 3))
            (expr_list:DI (use (reg:DI 4 4))
                (expr_list:DI (use (reg:DI 5 5))
                    (nil))))))
(note/c 149 34 115 (var_location result (lshiftrt:DI (unspec:DI [
            (unspec:V4SI [
                    (unspec:V4SI [
                            (const_vector:V4SI [
                                    (const_int 0 [0]) repeated x4
                                ])
                            (const_int -1 [0xffffffffffffffff])
                            (const_int 0 [0])
                        ] UNSPEC_VSX_SET)
                    (const_int -1 [0xffffffffffffffff])
                    (const_int 1 [0x1])
                ] UNSPEC_VSX_SET)
            (const_int 1 [0x1])
        ] UNSPEC_FOO)

We see in the note "(lshiftrt:DI (unspec:DI" which as I understand it is
what triggers the note in the output.  So in this case the issue has to do
with the V4SI test case.

If you comment out the entire test for
result = __builtin_vec_foo_v4si (wi_src, 1); the error then shows up as:

    (expr_list (use (reg:DI 2 2))
        (expr_list:DI (use (reg:DI 3 3))
            (expr_list:DI (use (reg:DI 4 4))
                (expr_list:DI (use (reg:DI 5 5))
                    (nil))))))
(note/c 111 36 105 (var_location result (lshiftrt:DI (unspec:DI [
            (const_vector:V2DI [
                    (const_int -1 [0xffffffffffffffff]) repeated x2
                ])
            (const_int 1 [0x1])
        ] UNSPEC_FOO)

in the V2DI test.


More information about the Gcc-bugs mailing list