[Bug tree-optimization/55619] New: [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable

[Bug tree-optimization/55619] New: [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable

[markus at trippelsdorf dot de]

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

             Bug #: 55619
           Summary: [4.8 Regression] Chromium build fails with: error:
                    memory input is not directly addressable
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: markus@trippelsdorf.de


On current trunk I get:

 % c++ -c compare_posix.ii
third_party/libyuv/source/compare_posix.cc: In function ‘uint32
libyuv::HashDjb2_SSE41(const uint8*, int, uint32)’:
third_party/libyuv/source/compare_posix.cc:156:4: error: memory input 4 is not
directly addressable
third_party/libyuv/source/compare_posix.cc:156:4: error: memory input 5 is not
directly addressable
third_party/libyuv/source/compare_posix.cc:156:4: error: memory input 6 is not
directly addressable
third_party/libyuv/source/compare_posix.cc:156:4: error: memory input 7 is not
directly addressable
third_party/libyuv/source/compare_posix.cc:156:4: error: memory input 8 is not
directly addressable
 %                                                                  

<= gcc version 4.8.0 20121123 (experimental) (GCC) is OK
>  gcc version 4.8.0 20121130 (experimental) (GCC) fails

[Bug tree-optimization/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable

[markus at trippelsdorf dot de]

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

--- Comment #1 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2012-12-08 07:48:26 UTC ---
Created attachment 28899
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28899
testcase

[Bug tree-optimization/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-12-08 08:05:54 UTC ---
I think it would be better to rewrite this using intrinsics than depending on
the register allocator. 
You have 3 register inputs, 4 register outputs and 5 memory inputs.

I also don't think you have the input/outputs correct either.  

%2 you only read and never write to so why have it as +?
\

[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf <markus at trippelsdorf dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glisse at gcc dot gnu.org
          Component|tree-optimization           |c++

--- Comment #3 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2012-12-08 08:19:09 UTC ---
Andrew, you may be right, but I didn't wrote this code;
I'm just reporting the issue...

Anyway this started with revision193938:

31631c5351145bb3a9a1152b2e10ad52c6b42a65 is the first bad commit
commit 31631c5351145bb3a9a1152b2e10ad52c6b42a65
Author: glisse <glisse@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Thu Nov 29 15:40:16 2012 +0000

    2012-11-29  Marc Glisse  <marc.glisse@inria.fr>

        PR c++/53094
    gcc/
        * fold-const.c (fold): Replace a CONSTRUCTOR with a VECTOR_CST.
    gcc/cp/
        * cvt.c (ocp_convert): Call convert_to_vector.
    gcc/testsuite/
        * g++.dg/ext/vector20.C: New testcase.



    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@193938
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-12-08 08:29:53 UTC ---
I think it is obvious what is happening.  The c++ front-end is propagating the
const vector.

Does a const int cause a similar issue if so the inline-asm is buggy i think.

[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> 2012-12-08 08:49:35 UTC ---
Indeed I got it down to this code, which fails just the same with an int
instead of a vector. I didn't know it was forbidden to pass constants with the
"m" constraint, I thought gcc would manage that somehow. What is the
appropriate x86 constraint for a vector constant? "C" doesn't seem to work.

typedef unsigned __attribute__((vector_size(16))) uvec32;

static const uvec32 C = { 0x92d9e201, 0, 0, 0 };
//static const unsigned C = 0x92d9e201;

void f() {
  asm volatile ( "" : : "m"(C));
}

[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.0

[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |jason at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-10 10:51:21 UTC ---
>From what I can see, the C++ FE always did what it does now, i.e. even in only
"m" inputs fold the const value into its initializer.  GCC up to 3.2 was
supporting pushing constants into constant pool without a warning, 3.3/3.4
emitted a deprecation warning on that
warning: use of memory input without lvalue in asm operand 0 is deprecated
and finally from 4.0 onwards this is a hard error.
In this light, the user inline asm could be considered invalid.

Perhaps the C++ FE could be changed, in finish_asm_stmt:

          constraint = TREE_STRING_POINTER (TREE_VALUE (TREE_PURPOSE (t)));
          operand = decay_conversion (TREE_VALUE (t), tf_warning_or_error);

          /* If the type of the operand hasn't been determined (e.g.,
             because it involves an overloaded function), then issue
             an error message.  There's no context available to
             resolve the overloading.  */
          if (TREE_TYPE (operand) == unknown_type_node)
            {
              error ("type of asm operand %qE could not be determined",
                     TREE_VALUE (t));
              operand = error_mark_node;
            }

          if (parse_input_constraint (&constraint, i, ninputs, noutputs, 0,
                                      oconstraints, &allows_mem, &allows_reg))
            {
              /* If the operand is going to end up in memory,
                 mark it addressable.  */
              if (!allows_reg && allows_mem)
                {
                  /* Strip the nops as we allow this case.  FIXME, this really
                     should be rejected or made deprecated.  */
                  STRIP_NOPS (operand);
                  if (!cxx_mark_addressable (operand))
                    operand = error_mark_node;
                }
            }
          else
            operand = error_mark_node;

perhaps parse_input_constraint could be done before decay_conversion (and just
remember its return value in a bool), if it returned true and !allows_reg &&
allows_mem, we would need to use some other *_conversion instead of
decay_conversion that wouldn't fold it into a constant and thus make something
originally potentially addressable into something non-addressable.
No idea what function would that be though.  Worst case parse it as if it was
surrounded by implicit & and then dereference the result?  That could generate
different and less clear diagnostics though.

[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-10 14:48:00 UTC ---
Created attachment 28913
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28913
gcc48-pr55619.patch

Here is (untested) patch I had in mind.  But perhaps we'd need to also change
the C FE, because with this patch we no longer error on e.g.
void
f ()
{
  int x[4];
  __asm volatile ("" : : "m" (x));
}

in C++, but still error out on it in C.  On the C side perhaps we should drop
the convert_p argument to c_parser_asm_operands, not do any conversion nor
c_fully_fold in there and instead do it in build_asm_stmt.

[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-11 16:51:31 UTC ---
Author: jakub
Date: Tue Dec 11 16:51:16 2012
New Revision: 194404

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194404
Log:
    PR c++/55619
    * semantics.c (finish_asm_stmt): Don't call decay_conversion
    on input operands that can be only in memory.

    * g++.dg/ext/asm12.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/ext/asm12.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/semantics.c
    trunk/gcc/testsuite/ChangeLog

[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-11 16:54:20 UTC ---
Fixed.

[Bug c++/55619] [4.8 Regression] Chromium build fails with: error: memory input is not directly addressable

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-20 10:41:51 UTC ---
Author: jakub
Date: Thu Dec 20 10:41:47 2012
New Revision: 194631

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194631
Log:
    PR c++/55619
    * c-parser.c (c_parser_asm_operands): Remove CONVERT_P
    argument, don't call default_function_array_conversion
    nor c_fully_fold here.
    (c_parser_asm_statement): Adjust callers.
    * c-typeck.c (build_asm_expr): Call c_fully_fold on inputs
    and outputs here, and call default_function_array_conversion
    on inputs that don't need to be addressable.

    * c-c++-common/pr55619.c: New test.

Added:
    trunk/gcc/testsuite/c-c++-common/pr55619.c
Modified:
    trunk/gcc/c/ChangeLog
    trunk/gcc/c/c-parser.c
    trunk/gcc/c/c-typeck.c
    trunk/gcc/testsuite/ChangeLog