* [Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
2015-05-15 16:07 [Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO marxin at gcc dot gnu.org
@ 2015-05-15 16:14 ` pinskia at gcc dot gnu.org
2015-05-15 16:43 ` marxin at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: pinskia at gcc dot gnu.org @ 2015-05-15 16:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
2015-05-15 16:07 [Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO marxin at gcc dot gnu.org
2015-05-15 16:14 ` [Bug tree-optimization/66163] " pinskia at gcc dot gnu.org
@ 2015-05-15 16:43 ` marxin at gcc dot gnu.org
2015-05-15 19:27 ` hubicka at gcc dot gnu.org
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: marxin at gcc dot gnu.org @ 2015-05-15 16:43 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
2015-05-15 16:07 [Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO marxin at gcc dot gnu.org
2015-05-15 16:14 ` [Bug tree-optimization/66163] " pinskia at gcc dot gnu.org
2015-05-15 16:43 ` marxin at gcc dot gnu.org
@ 2015-05-15 19:27 ` hubicka at gcc dot gnu.org
2015-05-16 7:51 ` mpolacek at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: hubicka at gcc dot gnu.org @ 2015-05-15 19:27 UTC (permalink / raw)
To: gcc-bugs
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 :)
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
2015-05-15 16:07 [Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO marxin at gcc dot gnu.org
` (2 preceding siblings ...)
2015-05-15 19:27 ` hubicka at gcc dot gnu.org
@ 2015-05-16 7:51 ` mpolacek at gcc dot gnu.org
2015-05-16 21:57 ` hubicka at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2015-05-16 7:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
2015-05-15 16:07 [Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO marxin at gcc dot gnu.org
` (3 preceding siblings ...)
2015-05-16 7:51 ` mpolacek at gcc dot gnu.org
@ 2015-05-16 21:57 ` hubicka at gcc dot gnu.org
2015-05-18 11:52 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: hubicka at gcc dot gnu.org @ 2015-05-16 21:57 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
2015-05-15 16:07 [Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO marxin at gcc dot gnu.org
` (4 preceding siblings ...)
2015-05-16 21:57 ` hubicka at gcc dot gnu.org
@ 2015-05-18 11:52 ` rguenth at gcc dot gnu.org
2015-05-18 11:53 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-05-18 11:52 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
2015-05-15 16:07 [Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO marxin at gcc dot gnu.org
` (5 preceding siblings ...)
2015-05-18 11:52 ` rguenth at gcc dot gnu.org
@ 2015-05-18 11:53 ` rguenth at gcc dot gnu.org
2015-05-18 14:02 ` marxin at gcc dot gnu.org
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-05-18 11:53 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
2015-05-15 16:07 [Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO marxin at gcc dot gnu.org
` (6 preceding siblings ...)
2015-05-18 11:53 ` rguenth at gcc dot gnu.org
@ 2015-05-18 14:02 ` marxin at gcc dot gnu.org
2015-05-18 14:32 ` hubicka at ucw dot cz
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: marxin at gcc dot gnu.org @ 2015-05-18 14:02 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
2015-05-15 16:07 [Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO marxin at gcc dot gnu.org
` (7 preceding siblings ...)
2015-05-18 14:02 ` marxin at gcc dot gnu.org
@ 2015-05-18 14:32 ` hubicka at ucw dot cz
2015-05-18 14:33 ` hubicka at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: hubicka at ucw dot cz @ 2015-05-18 14:32 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
2015-05-15 16:07 [Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO marxin at gcc dot gnu.org
` (8 preceding siblings ...)
2015-05-18 14:32 ` hubicka at ucw dot cz
@ 2015-05-18 14:33 ` hubicka at gcc dot gnu.org
2015-05-19 6:47 ` law at redhat dot com
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: hubicka at gcc dot gnu.org @ 2015-05-18 14:33 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
2015-05-15 16:07 [Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO marxin at gcc dot gnu.org
` (9 preceding siblings ...)
2015-05-18 14:33 ` hubicka at gcc dot gnu.org
@ 2015-05-19 6:47 ` law at redhat dot com
2015-06-09 12:56 ` marxin at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: law at redhat dot com @ 2015-05-19 6:47 UTC (permalink / raw)
To: gcc-bugs
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)
}
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
2015-05-15 16:07 [Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO marxin at gcc dot gnu.org
` (10 preceding siblings ...)
2015-05-19 6:47 ` law at redhat dot com
@ 2015-06-09 12:56 ` marxin at gcc dot gnu.org
2015-06-09 16:55 ` hubicka at ucw dot cz
2015-06-09 18:15 ` marxin at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: marxin at gcc dot gnu.org @ 2015-06-09 12:56 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
2015-05-15 16:07 [Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO marxin at gcc dot gnu.org
` (11 preceding siblings ...)
2015-06-09 12:56 ` marxin at gcc dot gnu.org
@ 2015-06-09 16:55 ` hubicka at ucw dot cz
2015-06-09 18:15 ` marxin at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: hubicka at ucw dot cz @ 2015-06-09 16:55 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
2015-05-15 16:07 [Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO marxin at gcc dot gnu.org
` (12 preceding siblings ...)
2015-06-09 16:55 ` hubicka at ucw dot cz
@ 2015-06-09 18:15 ` marxin at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: marxin at gcc dot gnu.org @ 2015-06-09 18:15 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread