[Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO

[Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO

[marxin at gcc dot gnu.org]

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

            Bug ID: 66163
           Summary: [6 Regression] Not working Firefox built with LTO
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: hubicka at ucw dot cz
          Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

I've just built FF with LTO and -O3 and the browser is unable to render a
complex page. Unfortunately that's an error in MessageChannel, can't catch it
in gdb:

###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv

Starting from r222054, where following hunk is responsible for the error:

+  /* THIS argument of method is always non-NULL.  */
+  if (TREE_CODE (TREE_TYPE (current_function_decl)) == METHOD_TYPE
+      && arg == DECL_ARGUMENTS (current_function_decl)
+      && flag_delete_null_pointer_checks)
+    return true;

As I added dump for cases where we return, it's more than 100k occurrences.
Any idea Honza how to isolate the issue?

Thanks,
Martin

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This really sounds like a bug in Firefox. This argument is not valid to be
null. Hmm, I suspect there should be an undefined sanitizer that should be
added to catch this case if not already there.

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> This really sounds like a bug in Firefox. This argument is not valid to be
> null. Hmm, I suspect there should be an undefined sanitizer that should be
> added to catch this case if not already there.

Well, I can try to update my Firefox tree to verify that the issue still
persists. I'm wondering how can call a class method having this == NULL?

Are you talking about ubsan?
>From gcc-bugs-return-486364-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri May 15 17:00:10 2015
Return-Path: <gcc-bugs-return-486364-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 50300 invoked by alias); 15 May 2015 17:00:10 -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 50186 invoked by uid 48); 15 May 2015 17:00:05 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66130] "invalid use of non-static member function" message could be clearer
Date: Fri, 15 May 2015 17:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords: easyhack, patch
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-66130-4-RhNllxbhGp@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66130-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66130-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-05/txt/msg01204.txt.bz2
Content-length: 1733

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

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Paolo Carlini from comment #9)
> But the error message is about l->*ptr, not about ptr per se. 

Yes, but the location should already point to l->*ptr. I'm thinking in cases
such as:

struct Local
{
  void f();
  int z;
};

Local *l;
void (Local::*j)();
int Local::*i;
decltype((l->*j)) x;

where printing "invalid use of non-static member function 'void (Local::*j)()'"
seems more useful than "invalid use of non-static member function 'l->*j'" in
order to spot the typo (i vs j).

> that in such cases using dump_type (or %qT at the call site) on TREE_TYPE
> (t) (TREE_TYPE (expr)) should be Ok.

Yes!

@@ -1826,11 +1826,16 @@ invalid_nonstatic_memfn_p (tree expr, ts
   if (is_overloaded_fn (expr) && !really_overloaded_fn (expr))
     expr = get_first_fn (expr);
   if (DECL_NONSTATIC_MEMBER_FUNCTION_P (expr))
     {
       if (complain & tf_error)
-        error ("invalid use of non-static member function");
+       {
+         if (DECL_P (expr))
+           error_at (loc, "invalid use of non-static member function %qD",
expr);
+         else
+           error_at (loc, "invalid use of non-static member function %qT",
TREE_TYPE (expr));
+       }
       return true;
     }
   return false;
 }


prints:

test.cc:10:17: error: invalid use of non-static member function ‘void
(Local::)()’
 decltype((l->*j)) x;
                 ^

which looks fine to me, except for the column location, but that seems harder
to fix.

We could also print a "note: declared here" to be extra helpful, but I'll leave
that to whoever gets to finish this ;-)
>From gcc-bugs-return-486365-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri May 15 17:34:52 2015
Return-Path: <gcc-bugs-return-486365-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 60234 invoked by alias); 15 May 2015 17:34:52 -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 60191 invoked by uid 55); 15 May 2015 17:34:48 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/64454] optimize (x%5)%5
Date: Fri, 15 May 2015 17:34: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: 5.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-64454-4-cAyFPmX4Fw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64454-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64454-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/msg01205.txt.bz2
Content-length: 653

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

--- Comment #11 from Marc Glisse <glisse at gcc dot gnu.org> ---
Author: glisse
Date: Fri May 15 17:34:15 2015
New Revision: 223221

URL: https://gcc.gnu.org/viewcvs?rev"3221&root=gcc&view=rev
Log:
2015-05-15  Marc Glisse  <marc.glisse@inria.fr>

        PR tree-optimization/64454
gcc/
        * match.pd ((X % Y) % Y, (X % Y) < Y): New patterns.
        (-1 - A -> ~A): Remove unnecessary condition.
gcc/testsuite/
        * gcc.dg/modmod.c: New testcase.


Added:
    trunk/gcc/testsuite/gcc.dg/modmod.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/match.pd
    trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Yes, ubsan should have flag to check that for methods the THIS parameter is
non-NULL and that all REFERENCE_TYPE parameters are non-NULL, too. It should be
easy excercise to get implemented :)

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
-fsanitize=null should do exactly that.

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Hmm, interesting.  I tried a testcase:
$ more t.C
struct test {int a; int foo (int &b);};
int
test2 (test *t, int *q)
{
  if (t && q)
    return t->a+*q;
  else
    return 1;
}
int test::foo(int &b)
{
  return test2(this,&b);
}

compiled with -O3 -fsanitize=null.  I would expect test2 to have no sanitizer
checks (since it returns 1 at NULL) and test to have them.

Curiously enough test2 gets compiled as:
int test2(test*, int*) (struct test * t, int * q)
{
  int _1;
  bool _3;
  bool _5;
  bool _6;
  int _8;
  int _9;
  int _10;

  <bb 2>:
  _3 = t_2(D) != 0B;
  _5 = q_4(D) != 0B;
  _6 = _3 & _5;
  if (_6 != 0)
    goto <bb 3>;
  else
    goto <bb 8>;

  <bb 3>:
  if (t_2(D) == 0B)
    goto <bb 4>;
  else
    goto <bb 5>;

  <bb 4>:
  __builtin___ubsan_handle_type_mismatch (&*.Lubsan_data0, 0);

  <bb 5>:
  _8 = t_2(D)->a;
  if (q_4(D) == 0B)
    goto <bb 6>;
  else
    goto <bb 7>;

  <bb 6>:
  __builtin___ubsan_handle_type_mismatch (&*.Lubsan_data1, 0);

  <bb 7>:
  _9 = *q_4(D);
  _10 = _8 + _9;

  <bb 8>:
  # _1 = PHI <_10(7), 1(2)>
  return _1;

}

Why we do not simplify the checks here?
  _3 = t_2(D) != 0B;
  _5 = q_4(D) != 0B;
  _6 = _3 & _5;
  if (_6 != 0)
    goto <bb 3>;
  else
    goto <bb 8>;

  <bb 3>:
  if (t_2(D) == 0B)
    goto <bb 4>;
  else
    goto <bb 5>;

this is certainly jump-threadable. I am adding Jeff for this.

simplified testcase:
struct test {int a; int foo (int &b);};
int
test2 (test *t, int *q)
{
  if (t)
    return t->a;
  else
    return 1;
}
int test::foo(int &b)
{
  return test2(this,&b);
}

gets compiled as:
int test2(test*, int*) (struct test * t, int * q)
{
  int _1;
  int _4;

  <bb 2>:
  if (t_2(D) != 0B)
    goto <bb 3>;
  else
    goto <bb 6>;

  <bb 3>:
  if (t_2(D) == 0B)
    goto <bb 4>;
  else
    goto <bb 5>;

  <bb 4>:
  __builtin___ubsan_handle_type_mismatch (&*.Lubsan_data0, 0);

  <bb 5>:
  _4 = t_2(D)->a;

  <bb 6>:
  # _1 = PHI <_4(5), 1(2)>
  return _1;

}


so still no jump threading, but RTL gets it:
_Z5test2P4testPi:
.LFB0:
        .cfi_startproc
        testq   %rdi, %rdi
        movl    $1, %eax
        je      .L2
        movl    (%rdi), %eax
.L2:

however test:foo is also compiled as:
_ZN4test3fooERi:
.LFB1:
        .cfi_startproc
        testq   %rdi, %rdi
        movl    $1, %eax
        je      .L8
        movl    (%rdi), %eax
.L8:
        rep ret

whic is wrong, it should complain about undefined behaviour for NULL this.

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.0.1

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.1                       |6.0

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
According to -fsanitize=null, there are many places in Firefox that produce
undefined behavior in followin way:

https://bugzilla.mozilla.org/show_bug.cgi?id=1165904

One common example:

    static size_t offsetOfThis() {
        JitFrameLayout* base = nullptr;
        return reinterpret_cast<size_t>(&base->argv()[0]);
    }


Martin
>From gcc-bugs-return-486539-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 18 14:28:21 2015
Return-Path: <gcc-bugs-return-486539-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17732 invoked by alias); 18 May 2015 14:28:21 -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 17694 invoked by uid 48); 18 May 2015 14:28:17 -0000
From: "dje at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66192] New: C++ static initializer unnecessary __cxa_guard_acquire for TARGET_RELAXED_ORDERING
Date: Mon, 18 May 2015 14:28: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: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dje at gcc dot gnu.org
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
Message-ID: <bug-66192-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/msg01379.txt.bz2
Content-length: 919

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

            Bug ID: 66192
           Summary: C++ static initializer unnecessary __cxa_guard_acquire
                    for TARGET_RELAXED_ORDERING
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

// static_init.cc

int* f(void) {
  static int* p = new int;
  return p;
}

$ g++ -O2 -S -fno-exceptions static_init.cc

generates an unnecessary call to __cxa_guard_acquire on what should be the fast
path for targets with TARGET_RELAXED_ORDERING defined.  The guard should be an
atomic variable accessed with the equivalent of __atomic_load(ACQUIRE) instead
of a heavy-weight __cxa_guard_acquire() call invoking heavier-weight
synchronization.

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[hubicka at ucw dot cz]

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

--- Comment #7 from Jan Hubicka <hubicka at ucw dot cz> ---
> According to -fsanitize=null, there are many places in Firefox that produce
> undefined behavior in followin way:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1165904
> 
> One common example:
> 
>     static size_t offsetOfThis() {
>         JitFrameLayout* base = nullptr;
>         return reinterpret_cast<size_t>(&base->argv()[0]);
>     }

Jason,
just to double check, this is indeed an undefined and offsetof is usable
only for POD?

Honza

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at redhat dot com

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Forgot to actually CC Jason, sorry for that.

>     static size_t offsetOfThis() {
>         JitFrameLayout* base = nullptr;
>         return reinterpret_cast<size_t>(&base->argv()[0]);
>     }

Jason,
just to double check, this is indeed an undefined and offsetof is usable
only for POD?

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[law at redhat dot com]

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

--- Comment #9 from Jeffrey A. Law <law at redhat dot com> ---
We don't thread because we don't lower UBSAN_NULL to actual conditionals until
the end of the gimple/ssa pipeline.  ie, in DOM2 we have:

int test::foo(int&) (struct test * const this, int & b)
{
  int _5;
  int _6;

;;   basic block 2, loop depth 0, count 0, freq 10000, maybe hot
;;    prev block 0, next block 3, flags: (NEW, REACHABLE)
;;    pred:       ENTRY [100.0%]  (FALLTHRU,EXECUTABLE)
  if (this_2(D) != 0B)
    goto <bb 3>;
  else
    goto <bb 4>;
;;    succ:       3 [78.3%]  (TRUE_VALUE,EXECUTABLE)
;;                4 [21.6%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 3, loop depth 0, count 0, freq 7835, maybe hot
;;    prev block 2, next block 4, flags: (NEW, REACHABLE)
;;    pred:       2 [78.3%]  (TRUE_VALUE,EXECUTABLE)
  UBSAN_NULL (this_2(D), 3B, 0);
  _5 = this_2(D)->a;
;;    succ:       4 [100.0%]  (FALLTHRU,EXECUTABLE)

;;   basic block 4, loop depth 0, count 0, freq 10000, maybe hot
;;    prev block 3, next block 1, flags: (NEW, REACHABLE)
;;    pred:       2 [21.6%]  (FALSE_VALUE,EXECUTABLE)
;;                3 [100.0%]  (FALLTHRU,EXECUTABLE)
  # _6 = PHI <1(2), _5(3)>
  return _6;
;;    succ:       EXIT [100.0%]  (EXECUTABLE)

}

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

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

--- Comment #12 from Martin Liška <marxin at gcc dot gnu.org> ---
Resolved as invalid.
>From gcc-bugs-return-488478-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 09 12:56:09 2015
Return-Path: <gcc-bugs-return-488478-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 69253 invoked by alias); 9 Jun 2015 12:56:09 -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 69204 invoked by uid 48); 9 Jun 2015 12:56:06 -0000
From: "marxin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
Date: Tue, 09 Jun 2015 12: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: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marxin at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: hubicka at ucw dot cz
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66163-4-IfXm5KmUrs@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66163-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66163-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/msg00810.txt.bz2
Content-length: 251

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

--- Comment #11 from Martin Liška <marxin at gcc dot gnu.org> ---
Fixing all sanitizer issues in Firefox helped me to successfully built FF with
LTO. The binary does not segfault :)

Martin
>From gcc-bugs-return-488480-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 09 13:04:33 2015
Return-Path: <gcc-bugs-return-488480-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8355 invoked by alias); 9 Jun 2015 13:04:33 -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 8305 invoked by uid 48); 9 Jun 2015 13:04:29 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66472] -Wshadow gets confused by using statements in template classes
Date: Tue, 09 Jun 2015 13:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: NEW
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: keywords bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-66472-4-fUChlsHeud@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66472-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66472-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/msg00812.txt.bz2
Content-length: 461

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-06-09
     Ever confirmed|0                           |1

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[hubicka at ucw dot cz]

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

--- Comment #13 from Jan Hubicka <hubicka at ucw dot cz> ---
Great, do you have patch?
Honza

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #13)
> Great, do you have patch?
> Honza

Yes, I've suggested a patch here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1167119

Let's see if it will be accepted by Mozilla folks.
Anyway, the GCC revision where you made VRP more aggressive works, but there's
a different revision that causes a segfault. I will bisect it.

Martin
>From gcc-bugs-return-488524-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 09 18:39:58 2015
Return-Path: <gcc-bugs-return-488524-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 74074 invoked by alias); 9 Jun 2015 18:39:58 -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 74054 invoked by uid 48); 9 Jun 2015 18:39:55 -0000
From: "richard-gccbugzilla at metafoo dot co.uk" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66477] New: [constexpr] accepts-invalid with constexpr member call on non-constant reference
Date: Tue, 09 Jun 2015 18:39: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: richard-gccbugzilla at metafoo dot co.uk
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
Message-ID: <bug-66477-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/msg00856.txt.bz2
Content-length: 783

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

            Bug ID: 66477
           Summary: [constexpr] accepts-invalid with constexpr member call
                    on non-constant reference
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

GCC accepts this invalid code:

  struct a { constexpr int size() const { return 3; } };
  void f(a &r) { static_assert(r.size() == 3, "error"); }

The static_assert condition is non-constant because it mentions the reference
'r' whose referent is not known within that constant expression.