* [Bug tree-optimization/90838] Detect table-based ctz implementation
[not found] <bug-90838-4@http.gcc.gnu.org/bugzilla/>
@ 2019-06-11 22:47 ` wdijkstr at arm dot com
2023-02-17 2:20 ` gabravier at gmail dot com
` (9 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: wdijkstr at arm dot com @ 2019-06-11 22:47 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 52488 bytes --]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
Wilco <wdijkstr at arm dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wdijkstr at arm dot com
--- Comment #2 from Wilco <wdijkstr at arm dot com> ---
(In reply to Jakub Jelinek from comment #1)
> __builtin_ctzll is undefined for 0, while the above is well defined and
> returns 0.
When the target ctz is well defined and returns 64 for 0, and we want to return
0 instead, this will work:
__builtin_ctzll (b) & 63
>From gcc-bugs-return-646373-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 11 23:35:12 2019
Return-Path: <gcc-bugs-return-646373-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 41013 invoked by alias); 11 Jun 2019 23:35:11 -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 39023 invoked by uid 48); 11 Jun 2019 23:35:08 -0000
From: "zhonghao at pku dot org.cn" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/90845] New: A recurring hang: braces around scalar initializer - should be a warning
Date: Tue, 11 Jun 2019 23:35: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: 10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: zhonghao at pku dot org.cn
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-90845-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: 2019-06/txt/msg00888.txt.bz2
Content-length: 818
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90845
Bug ID: 90845
Summary: A recurring hang: braces around scalar initializer -
should be a warning
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
A bug report complains that gcc shall warn braces around scalar initializer,
and a test case is as follows:
struct SA { int n[1]; };
SA sa{{{0}}}; // GCC error - should be warning
It is marked as fixed. My gcc is 10.0.0, and with -c, I cannot find any
warnings.
The url of the bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
>From gcc-bugs-return-646374-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 11 23:42:53 2019
Return-Path: <gcc-bugs-return-646374-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 61686 invoked by alias); 11 Jun 2019 23:42:53 -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 61662 invoked by uid 48); 11 Jun 2019 23:42:49 -0000
From: "david at doublewise dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/90846] New: Concepts sometimes ignored for friend function templates of class templates
Date: Tue, 11 Jun 2019 23:42: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: 9.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: david at doublewise dot net
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-90846-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: 2019-06/txt/msg00889.txt.bz2
Content-length: 1223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90846
Bug ID: 90846
Summary: Concepts sometimes ignored for friend function
templates of class templates
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at doublewise dot net
Target Milestone: ---
The following code reports ambiguous overload when compiling with `g++
-std=c++2a -fconcepts`:
template<typename>
struct S {
template<typename T>
friend constexpr auto f(S, S<T>) {
return true;
}
template<typename T> requires false
friend constexpr auto f(S, T) {
return false;
}
template<typename T> requires false
friend constexpr auto f(T, S) {
return false;
}
};
static_assert(f(S<int>{}, S<int>{}));
It complains that all three functions are viable overloads. Deleting the second
overload makes gcc complain the that two remaining functions are ambiguous, but
deleting the third overload makes gcc happy and accept the code.
See it live: https://godbolt.org/z/wG3Isj
>From gcc-bugs-return-646375-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 11 23:43:28 2019
Return-Path: <gcc-bugs-return-646375-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 62596 invoked by alias); 11 Jun 2019 23:43:27 -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 62554 invoked by uid 48); 11 Jun 2019 23:43:24 -0000
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/83431] -Wformat-truncation may incorrectly report truncation
Date: Tue, 11 Jun 2019 23:43: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: 8.0
X-Bugzilla-Keywords: diagnostic, missed-optimization, patch
X-Bugzilla-Severity: normal
X-Bugzilla-Who: msebor at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: msebor at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: keywords
Message-ID: <bug-83431-4-H8IHIc6X7R@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-83431-4@http.gcc.gnu.org/bugzilla/>
References: <bug-83431-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: 2019-06/txt/msg00890.txt.bz2
Content-length: 430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83431
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
Initial patch: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00668.html
>From gcc-bugs-return-646376-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 11 23:45:33 2019
Return-Path: <gcc-bugs-return-646376-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 66402 invoked by alias); 11 Jun 2019 23:45:23 -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 66131 invoked by uid 48); 11 Jun 2019 23:45:04 -0000
From: "zhonghao at pku dot org.cn" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/90847] New: requested alignment is not an integer constant
Date: Tue, 11 Jun 2019 23:45: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: 10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: zhonghao at pku dot org.cn
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-90847-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: 2019-06/txt/msg00891.txt.bz2
Content-length: 1022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90847
Bug ID: 90847
Summary: requested alignment is not an integer constant
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
My gcc is 10.0.0, and the code is:
template <int N>
void test() {
constexpr int N2 = N;
typedef int T alignas(N2);
// error: requested alignment is not an integer constant
}
int main() {
test<4>();
return 0;
}
gcc accepts the code. clang rejects it:
source>:4:16: error: 'alignas' attribute only applies to variables, data
members and tag types
typedef int T alignas(N2);
^
1 error generated.
Compiler returned: 1
icc gives a warning:
<source>(4): warning #3463: alignas does not apply here
typedef int T alignas(N2);
^
Compiler returned: 0
>From gcc-bugs-return-646377-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 11 23:50:36 2019
Return-Path: <gcc-bugs-return-646377-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 104279 invoked by alias); 11 Jun 2019 23:50:36 -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 104202 invoked by uid 48); 11 Jun 2019 23:50:32 -0000
From: "zhonghao at pku dot org.cn" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/90848] New: A recurring bug: Overeager application of conversion to function pointer during overload resolution of call to function object
Date: Tue, 11 Jun 2019 23:50: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: 10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: zhonghao at pku dot org.cn
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-90848-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: 2019-06/txt/msg00892.txt.bz2
Content-length: 1927
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90848
Bug ID: 90848
Summary: A recurring bug: Overeager application of conversion
to function pointer during overload resolution of call
to function object
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
A bug report (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71117) complains
that GCC accepts the code:
template<typename T> using id = T;
struct F {
template<typename T> operator id<T(*)(T)>();
} f;
int n = f(0);
Clang, EDG, MSVC reject it. Some comments are as follows:
"Per [over.call.object]/2, I think GCC is wrong per the current language
wording. A conversion function template does not qualify as a "non-explicit
conversion function declared in [F or base class thereof]" (because it is not a
conversion function), and nor does a specialization of one (because it is not
itself declared in F).
I also don't see any way the current wording would take us to
[temp.deduct.conv] for this case, nor how that wording would apply (since we
don't have a function type that's required as the result of the conversion).
Perhaps GCC is following the rules of [temp.deduct.call] in this case, treating
the (pointee type of the) result type of the conversion function as if it were
the function type of the callee?
In the abstract, GCC's approach to this situation seems superior -- it's able
to use a conversion to function pointer in many cases where other compilers
can't -- but I'm a little hesitant to suggest we adopt that approach since it
breaks examples like yours."
I tried gcc 10.0.0. It still accepts it, although the above bug is marked as
fixed.
>From gcc-bugs-return-646378-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 12 00:22:13 2019
Return-Path: <gcc-bugs-return-646378-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 60908 invoked by alias); 12 Jun 2019 00:22:13 -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 60884 invoked by uid 48); 12 Jun 2019 00:22:09 -0000
From: "zhonghao at pku dot org.cn" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/90849] New: Gcc accepts invalid code
Date: Wed, 12 Jun 2019 00:22: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: 10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: zhonghao at pku dot org.cn
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-90849-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: 2019-06/txt/msg00893.txt.bz2
Content-length: 1027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90849
Bug ID: 90849
Summary: Gcc accepts invalid code
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
My gcc is 10.0.0, and the code is:
template < typename = void >
class A
{
public:
A () : f0 ( 1 ) { }
A (int);
private:
typedef A<> f0;
};
A<> a;
The code comes from a previous bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70468
It is said to be invalid and it triggers a ICE. The bug is marked as fixed. I
tried gcc 10.0.0, it accepts the code. If it is invalid, gcc shall reject it.
BTW, clang reject it:
<source>:5:9: error: type 'A::f0' (aka 'A<>') is not a direct or virtual base
of 'A<type-parameter-0-0>'
A () : f0 ( 1 ) { }
^~
1 error generated.
Compiler returned: 1
>From gcc-bugs-return-646379-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 12 00:33:01 2019
Return-Path: <gcc-bugs-return-646379-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 90631 invoked by alias); 12 Jun 2019 00:33:00 -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 90578 invoked by uid 48); 12 Jun 2019 00:32:57 -0000
From: "zhonghao at pku dot org.cn" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/90850] New: template parameters do not match
Date: Wed, 12 Jun 2019 00:33: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: 10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: zhonghao at pku dot org.cn
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-90850-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: 2019-06/txt/msg00894.txt.bz2
Content-length: 1645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90850
Bug ID: 90850
Summary: template parameters do not match
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
My gcc is 10.0.0, and the code is:
template<class T1>
class C
{
template<class T2>
class C2 { };
};
template<> template<class X, class Y>
class C<int>::C2 { };
template<> template<int>
class C<float>::C2 { };
gcc accepts the code. icc:
<source>(8): error: too many template parameters -- does not match previous
declaration (declared at line 4)
template<> template<class X, class Y>
^
<source>(10): error: declaration is incompatible with template parameter "T2"
(declared at line 4)
template<> template<int>
^
compilation aborted for <source> (code 2)
Compiler returned: 2
clang rejects it:
source>:8:12: error: too many template parameters in template redeclaration
template<> template<class X, class Y>
^~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:4:2: note: previous template declaration is here
template<class T2>
^~~~~~~~~~~~~~~~~~
<source>:10:24: error: template parameter has a different kind in template
redeclaration
template<> template<int>
^
<source>:4:17: note: previous template declaration is here
template<class T2>
^
2 errors generated.
Compiler returned: 1
clang rejects it:
>From gcc-bugs-return-646380-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 12 01:13:27 2019
Return-Path: <gcc-bugs-return-646380-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 36271 invoked by alias); 12 Jun 2019 01:13:27 -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 36241 invoked by uid 48); 12 Jun 2019 01:13:23 -0000
From: "zhonghao at pku dot org.cn" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/90851] New: -O3 overflow
Date: Wed, 12 Jun 2019 01:13: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: 10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: zhonghao at pku dot org.cn
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-90851-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: 2019-06/txt/msg00895.txt.bz2
Content-length: 749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90851
Bug ID: 90851
Summary: -O3 overflow
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
My gcc is 10.0.0, and the code is:
struct S { S (); S (int); ~S (); int i; };
struct A { S s[100000]; };
void
foo ()
{
A a = {{}};
}
It takes several minutes to compile the code. With the following parameters:
g++ -Os | g++ -O3 | gcc -Os | gcc -O3 |, I got a overflow:
cc1plus: out of memory allocating 65536 bytes after a total of 58655244288
bytes
>From gcc-bugs-return-646381-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 12 01:27:19 2019
Return-Path: <gcc-bugs-return-646381-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 70135 invoked by alias); 12 Jun 2019 01:27:18 -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 70103 invoked by uid 48); 12 Jun 2019 01:27:15 -0000
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/90625] fold strcmp(a, b) == 0 to zero for strings of unequal but non-const lengths
Date: Wed, 12 Jun 2019 01:27: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: 9.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: msebor 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-90625-4-ZEMW2HJj1C@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-90625-4@http.gcc.gnu.org/bugzilla/>
References: <bug-90625-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: 2019-06/txt/msg00896.txt.bz2
Content-length: 340
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90625
--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
It looks like it might be possible by querying an EVRP instance for the range
of strinfo::nonzero_chars. I have a working prototype for snprintf that should
be easily extensible to any other similar string built-in.
>From gcc-bugs-return-646382-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 12 01:44:05 2019
Return-Path: <gcc-bugs-return-646382-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 112572 invoked by alias); 12 Jun 2019 01:44:04 -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 112540 invoked by uid 48); 12 Jun 2019 01:44:01 -0000
From: "zhonghao at pku dot org.cn" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/90852] New: A recurring bug: Constant expressions support reinterpret_cast
Date: Wed, 12 Jun 2019 01:44: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: 10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: zhonghao at pku dot org.cn
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-90852-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: 2019-06/txt/msg00897.txt.bz2
Content-length: 1983
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90852
Bug ID: 90852
Summary: A recurring bug: Constant expressions support
reinterpret_cast
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
A previous bug report (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171)
contains two samples:
//---
constexpr const char* c = reinterpret_cast<const char*>(0x123);
//---
//----------------
struct X {
X* operator&();
};
X x[2];
const bool p = (reinterpret_cast<X*>(&reinterpret_cast<char&>(x[1]))
- reinterpret_cast<X*>(&reinterpret_cast<char&>(x[0]))) == sizeof(X);
enum E { e = p }; // e should have a value equal to 1
//----------------
After some discussions, programmers agree that the first sample shall be
reject, but the second sample has its value. gcc 7.2 accepts the code. However,
gcc 10.0.0 rejects it:
source>:10:14: error: the value of 'p' is not usable in a constant expression
10 | enum E { e = p }; // e should have a value equal to 1
| ^
<source>:7:12: note: 'p' was not initialized with a constant expression
7 | const bool p = (reinterpret_cast<X*>(&reinterpret_cast<char&>(x[1]))
| ^
<source>:10:14: error: the value of 'p' is not usable in a constant expression
10 | enum E { e = p }; // e should have a value equal to 1
| ^
<source>:7:12: note: 'p' was not initialized with a constant expression
7 | const bool p = (reinterpret_cast<X*>(&reinterpret_cast<char&>(x[1]))
| ^
<source>:10:14: error: enumerator value for 'e' is not an integer constant
10 | enum E { e = p }; // e should have a value equal to 1
| ^
Compiler returned: 1
>From gcc-bugs-return-646383-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 12 01:48:55 2019
Return-Path: <gcc-bugs-return-646383-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 115194 invoked by alias); 12 Jun 2019 01:48:55 -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 115141 invoked by uid 48); 12 Jun 2019 01:48:51 -0000
From: "xuemaosheng at huawei dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/90837] Generate infinite loop when using -ftree-vrp
Date: Wed, 12 Jun 2019 01:48: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: 8.2.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: xuemaosheng at huawei dot com
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: cc
Message-ID: <bug-90837-4-2m7t7dZmNk@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-90837-4@http.gcc.gnu.org/bugzilla/>
References: <bug-90837-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: 2019-06/txt/msg00898.txt.bz2
Content-length: 432
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90837
otcmaf <xuemaosheng at huawei dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |xuemaosheng at huawei dot com
--- Comment #2 from otcmaf <xuemaosheng at huawei dot com> ---
Thank you very much. Your point of view is correct.
>From gcc-bugs-return-646384-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 12 01:49:45 2019
Return-Path: <gcc-bugs-return-646384-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 37813 invoked by alias); 12 Jun 2019 01:49:42 -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 32044 invoked by uid 48); 12 Jun 2019 01:49:39 -0000
From: "xuemaosheng at huawei dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/90837] Generate infinite loop when using -ftree-vrp
Date: Wed, 12 Jun 2019 01:49: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: 8.2.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: xuemaosheng at huawei dot com
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:
Message-ID: <bug-90837-4-7pKQkHE2nO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-90837-4@http.gcc.gnu.org/bugzilla/>
References: <bug-90837-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: 2019-06/txt/msg00899.txt.bz2
Content-length: 291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90837
--- Comment #3 from otcmaf <xuemaosheng at huawei dot com> ---
(In reply to Andrew Pinski from comment #1)
> The access auwMulRRUPeakUsrInfo[0][uwUserCountCell1] can be out of bounds.
Thank you very much. Your point of view is correct.
>From gcc-bugs-return-646385-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 12 02:07:21 2019
Return-Path: <gcc-bugs-return-646385-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 44468 invoked by alias); 12 Jun 2019 02:07:20 -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 43885 invoked by uid 48); 12 Jun 2019 02:07:17 -0000
From: "zhonghao at pku dot org.cn" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/90853] New: -O3 complains already defined symbol
Date: Wed, 12 Jun 2019 02:07: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: 10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: zhonghao at pku dot org.cn
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-90853-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: 2019-06/txt/msg00900.txt.bz2
Content-length: 761
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90853
Bug ID: 90853
Summary: -O3 complains already defined symbol
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
My gcc is 10.0.0, and the code is:
void x();
void rgb2yuv16bit_mmx422_row();
void x()
{
rgb2yuv16bit_mmx422_row();
}
void rgb2yuv16bit_mmx422_row()
{
__asm__ __volatile__ (
"rgb2yuv16_422:\n"
);
}
gcc accepts the code, but with -O3, it rejects it:
x.cpp: Assembler messages:
x.cpp:13: Error: symbol `rgb2yuv16_422' is already defined
>From gcc-bugs-return-646386-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 12 02:11:47 2019
Return-Path: <gcc-bugs-return-646386-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 62388 invoked by alias); 12 Jun 2019 02:11:47 -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 60743 invoked by uid 48); 12 Jun 2019 02:11:44 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/90853] -O3 complains already defined symbol
Date: Wed, 12 Jun 2019 02:11: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: 10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: INVALID
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_status resolution
Message-ID: <bug-90853-4-cDvXExwCi6@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-90853-4@http.gcc.gnu.org/bugzilla/>
References: <bug-90853-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: 2019-06/txt/msg00901.txt.bz2
Content-length: 938
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90853
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
inline-asm is duplicated via doing inlining. THIS IS NOT A GCC BUG. If you
want to define a symbol like this, use either top level inline-asm or the .s
file.
ALSO THIS IS DOCUMENTED:
Under certain circumstances, GCC may duplicate (or remove duplicates of) your
assembly code when optimizing. This can lead to unexpected duplicate symbol
errors during compilation if your assembly code defines symbols or labels.
--- CUT ---
>From https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Basic-Asm.html#Basic-Asm .
>From gcc-bugs-return-646389-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 12 02:12:51 2019
Return-Path: <gcc-bugs-return-646389-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 69067 invoked by alias); 12 Jun 2019 02:12:51 -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 67826 invoked by uid 48); 12 Jun 2019 02:12:47 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/8040] g++ with -O3 produces duplicate symbol
Date: Wed, 12 Jun 2019 02:12: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: 3.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: INVALID
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: cc
Message-ID: <bug-8040-4-T3H2fA5A3j@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-8040-4@http.gcc.gnu.org/bugzilla/>
References: <bug-8040-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: 2019-06/txt/msg00904.txt.bz2
Content-length: 444
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8040
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |zhonghao at pku dot org.cn
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 90853 has been marked as a duplicate of this bug. ***
>From gcc-bugs-return-646388-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 12 02:12:49 2019
Return-Path: <gcc-bugs-return-646388-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 68623 invoked by alias); 12 Jun 2019 02:12:49 -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 67742 invoked by uid 48); 12 Jun 2019 02:12:46 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/90853] -O3 complains already defined symbol
Date: Wed, 12 Jun 2019 02:12: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: 10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: DUPLICATE
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: resolution
Message-ID: <bug-90853-4-rNp59pZPm5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-90853-4@http.gcc.gnu.org/bugzilla/>
References: <bug-90853-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: 2019-06/txt/msg00903.txt.bz2
Content-length: 537
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90853
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |DUPLICATE
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup of bug 8040. The conversion from gnats to bugzilla had issues when it came
to closing bugs as invalid.
*** This bug has been marked as a duplicate of bug 8040 ***
>From gcc-bugs-return-646387-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 12 02:12:09 2019
Return-Path: <gcc-bugs-return-646387-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 65948 invoked by alias); 12 Jun 2019 02:12: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 65309 invoked by uid 48); 12 Jun 2019 02:12:06 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/8040] g++ with -O3 produces duplicate symbol
Date: Wed, 12 Jun 2019 02:12: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: 3.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: INVALID
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: resolution
Message-ID: <bug-8040-4-hjPspY5P8P@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-8040-4@http.gcc.gnu.org/bugzilla/>
References: <bug-8040-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: 2019-06/txt/msg00902.txt.bz2
Content-length: 367
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8040
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |INVALID
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.
>From gcc-bugs-return-646390-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 12 02:13:37 2019
Return-Path: <gcc-bugs-return-646390-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 78644 invoked by alias); 12 Jun 2019 02:13:37 -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 78597 invoked by uid 89); 12 Jun 2019 02:13:36 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-5.5 required=5.0 tests=AWL,BAYES_00,KAM_NUMSUBJECT,SPF_PASS autolearn=no version=3.3.1 spammy=H*u:38.0, H*UA:38.0
X-HELO: mail1.windriver.com
Received: from mail1.windriver.com (HELO mail1.windriver.com) (147.11.146.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Jun 2019 02:13:35 +0000
Received: from ALA-HCA.corp.ad.wrs.com ([147.11.189.40]) by mail1.windriver.com (8.15.2/8.15.1) with ESMTPS id x5C2DXBt029582 (version=TLSv1 cipher®S128-SHA bits\x128 verifyúIL) for <gcc-bugs@gcc.gnu.org>; Tue, 11 Jun 2019 19:13:34 -0700 (PDT)
Received: from [128.224.162.170] (128.224.162.170) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 11 Jun 2019 19:13:33 -0700
From: "Yu, Mingli" <mingli.yu@windriver.com>
Subject: Failed to build llvm 8.0.0 after upgrade gcc to 9.1.0
To: <gcc-bugs@gcc.gnu.org>
Message-ID: <5D006106.1040108@windriver.com>
Date: Wed, 12 Jun 2019 02:13:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
X-SW-Source: 2019-06/txt/msg00905.txt.bz2
Content-length: 3672
i Expert,
I encounter a build error for llvm
8.0.0(git://github.com/llvm/llvm-project.git) on ppc after upgrade gcc
to 9.1.0
| collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
The linker used here is powerpc-poky-linux-g++.
# powerpc-poky-linux-g++ -v
Using built-in specs.
COLLECT_GCC=powerpc-poky-linux-g++
COLLECT_LTO_WRAPPER=//yocto/builds/upgrade6/tmp/work/ppc7400-poky-linux/llvm/8.0.0-r0/recipe-sysroot-native/usr/bin/powerpc-poky-linux/../../libexec/powerpc-poky-linux/gcc/powerpc-poky-linux/9.1.0/lto-wrapper
Target: powerpc-poky-linux
Configured with:
../../../../../../work-shared/gcc-9.1.0-r0/gcc-9.1.0/configure
--build=x86_64-linux --host=x86_64-linux --target=powerpc-poky-linux
--prefix=//yocto/builds/upgrade6/tmp/work/x86_64-linux/gcc-cross-powerpc/9.1.0-r0/recipe-sysroot-native/usr
--exec_prefix=//yocto/builds/upgrade6/tmp/work/x86_64-linux/gcc-cross-powerpc/9.1.0-r0/recipe-sysroot-native/usr
--bindir=//yocto/builds/upgrade6/tmp/work/x86_64-linux/gcc-cross-powerpc/9.1.0-r0/recipe-sysroot-native/usr/bin/powerpc-poky-linux
--sbindir=//yocto/builds/upgrade6/tmp/work/x86_64-linux/gcc-cross-powerpc/9.1.0-r0/recipe-sysroot-native/usr/bin/powerpc-poky-linux
--libexecdir=//yocto/builds/upgrade6/tmp/work/x86_64-linux/gcc-cross-powerpc/9.1.0-r0/recipe-sysroot-native/usr/libexec/powerpc-poky-linux
--datadir=//yocto/builds/upgrade6/tmp/work/x86_64-linux/gcc-cross-powerpc/9.1.0-r0/recipe-sysroot-native/usr/share
--sysconfdir=//yocto/builds/upgrade6/tmp/work/x86_64-linux/gcc-cross-powerpc/9.1.0-r0/recipe-sysroot-native/etc
--sharedstatedir=//yocto/builds/upgrade6/tmp/work/x86_64-linux/gcc-cross-powerpc/9.1.0-r0/recipe-sysroot-native/com
--localstatedir=//yocto/builds/upgrade6/tmp/work/x86_64-linux/gcc-cross-powerpc/9.1.0-r0/recipe-sysroot-native/var
--libdir=//yocto/builds/upgrade6/tmp/work/x86_64-linux/gcc-cross-powerpc/9.1.0-r0/recipe-sysroot-native/usr/lib/powerpc-poky-linux
--includedir=//yocto/builds/upgrade6/tmp/work/x86_64-linux/gcc-cross-powerpc/9.1.0-r0/recipe-sysroot-native/usr/include
--oldincludedir=//yocto/builds/upgrade6/tmp/work/x86_64-linux/gcc-cross-powerpc/9.1.0-r0/recipe-sysroot-native/usr/include
--infodir=//yocto/builds/upgrade6/tmp/work/x86_64-linux/gcc-cross-powerpc/9.1.0-r0/recipe-sysroot-native/usr/share/info
--mandir=//yocto/builds/upgrade6/tmp/work/x86_64-linux/gcc-cross-powerpc/9.1.0-r0/recipe-sysroot-native/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=//yocto/builds/upgrade6/tmp/work/x86_64-linux/gcc-cross-powerpc/9.1.0-r0/recipe-sysroot-native
--enable-clocale=generic --with-gnu-ld --enable-shared
--enable-languages=c,c++ --enable-threads=posix --disable-multilib
--enable-c99 --enable-long-long --enable-symvers=gnu
--enable-libstdcxx-pch --program-prefix=powerpc-poky-linux-
--without-local-prefix --enable-lto --disable-libssp --enable-libitm
--disable-bootstrap --disable-libmudflap --with-system-zlib
--with-linker-hash-style=sysv --enable-linker-build-id --with-ppl=no
--with-cloog=no --enable-checking=release --enable-cheaders=c_global
--without-isl --with-gxx-include-dir=/not/exist/usr/include/c++/9.1.0
--with-sysroot=/not/exist
--with-build-sysroot=//yocto/builds/upgrade6/tmp/work/x86_64-linux/gcc-cross-powerpc/9.1.0-r0/recipe-sysroot
--enable-secureplt --with-long-double-128 --enable-targets=powerpc64
--enable-poison-system-directories --with-system-zlib --disable-static
--disable-nls --with-glibc-version=2.28 --enable-initfini-array
--enable-__cxa_atexit
Thread model: posix
gcc version 9.1.0 (GCC)
BTW, it builds successfully with gcc 8.3.0.
Any hints here?
Thanks,
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug tree-optimization/90838] Detect table-based ctz implementation
[not found] <bug-90838-4@http.gcc.gnu.org/bugzilla/>
2019-06-11 22:47 ` [Bug tree-optimization/90838] Detect table-based ctz implementation wdijkstr at arm dot com
@ 2023-02-17 2:20 ` gabravier at gmail dot com
2023-02-17 2:44 ` pinskia at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: gabravier at gmail dot com @ 2023-02-17 2:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
Gabriel Ravier <gabravier at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gabravier at gmail dot com
--- Comment #12 from Gabriel Ravier <gabravier at gmail dot com> ---
It appears this new optimization is non-functional on trunk with x86-64...
specifically on x86-64, too, on AArch64 it works just fine. So does that mean
this bug should be re-opened or should a new bug be opened for that ?
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug tree-optimization/90838] Detect table-based ctz implementation
[not found] <bug-90838-4@http.gcc.gnu.org/bugzilla/>
2019-06-11 22:47 ` [Bug tree-optimization/90838] Detect table-based ctz implementation wdijkstr at arm dot com
2023-02-17 2:20 ` gabravier at gmail dot com
@ 2023-02-17 2:44 ` pinskia at gcc dot gnu.org
2023-02-17 10:34 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-02-17 2:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Gabriel Ravier from comment #12)
> It appears this new optimization is non-functional on trunk with x86-64...
> specifically on x86-64, too, on AArch64 it works just fine. So does that
> mean this bug should be re-opened or should a new bug be opened for that ?
It does work with -mbmi where the instruction which is used has a defined value
at 0.
You can open a new issue for improvement of the case for not supplying -mbmi .
That is CTZ_DEFINED_VALUE_AT_ZERO is non-2.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug tree-optimization/90838] Detect table-based ctz implementation
[not found] <bug-90838-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2023-02-17 2:44 ` pinskia at gcc dot gnu.org
@ 2023-02-17 10:34 ` jakub at gcc dot gnu.org
2023-02-17 12:57 ` wilco at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-17 10:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The patch does:
+ bool zero_ok = CTZ_DEFINED_VALUE_AT_ZERO (TYPE_MODE (type), ctzval) ==
2;
+
+ /* Skip if there is no value defined at zero, or if we can't easily
+ return the correct value for zero. */
+ if (!zero_ok)
+ return false;
+ if (zero_val != ctzval && !(zero_val == 0 && ctzval == type_size))
+ return false;
For CTZ_DEFINED_VALUE_AT_ZERO == 1 we could support it the same way but we'd
need
to emit into the IL an equivalent of val == 0 ? zero_val : .CTZ (val) (with
GIMPLE_COND and a separate bb - not sure if anything in forwprop creates new
basic blocks right now), where there is a high chance that RTL opts would turn
it back into unconditional
ctz.
That still wouldn't help non--mbmi x86, because CTZ_DEFINED_VALUE_AT_ZERO is 0
there.
We could handle even that case by doing the branches around, but those would
stay there
in the generated code, at which point I wonder whether it would be a win. The
original
code is branchless...
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug tree-optimization/90838] Detect table-based ctz implementation
[not found] <bug-90838-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2023-02-17 10:34 ` jakub at gcc dot gnu.org
@ 2023-02-17 12:57 ` wilco at gcc dot gnu.org
2023-02-17 13:03 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: wilco at gcc dot gnu.org @ 2023-02-17 12:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
--- Comment #15 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #14)
> The patch does:
> + bool zero_ok = CTZ_DEFINED_VALUE_AT_ZERO (TYPE_MODE (type), ctzval)
> == 2;
> +
> + /* Skip if there is no value defined at zero, or if we can't easily
> + return the correct value for zero. */
> + if (!zero_ok)
> + return false;
> + if (zero_val != ctzval && !(zero_val == 0 && ctzval == type_size))
> + return false;
> For CTZ_DEFINED_VALUE_AT_ZERO == 1 we could support it the same way but we'd
> need
> to emit into the IL an equivalent of val == 0 ? zero_val : .CTZ (val) (with
> GIMPLE_COND and a separate bb - not sure if anything in forwprop creates new
> basic blocks right now), where there is a high chance that RTL opts would
> turn it back into unconditional
> ctz.
> That still wouldn't help non--mbmi x86, because CTZ_DEFINED_VALUE_AT_ZERO is
> 0 there.
> We could handle even that case by doing the branches around, but those would
> stay there
> in the generated code, at which point I wonder whether it would be a win.
> The original
> code is branchless...
It would make more sense to move x86 backends to CTZ_DEFINED_VALUE_AT_ZERO == 2
so that you always get the same result even when you don't have tzcnt. A
conditional move would be possible, so it adds an extra 2 instructions at worst
(ie. still significantly faster than doing the table lookup, multiply etc). And
it could be optimized when you know CLZ/CTZ input is non-zero.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug tree-optimization/90838] Detect table-based ctz implementation
[not found] <bug-90838-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2023-02-17 12:57 ` wilco at gcc dot gnu.org
@ 2023-02-17 13:03 ` jakub at gcc dot gnu.org
2023-02-17 14:27 ` wilco at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-17 13:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Wilco from comment #15)
> It would make more sense to move x86 backends to CTZ_DEFINED_VALUE_AT_ZERO
> == 2 so that you always get the same result even when you don't have tzcnt.
> A conditional move would be possible, so it adds an extra 2 instructions at
> worst (ie. still significantly faster than doing the table lookup, multiply
> etc). And it could be optimized when you know CLZ/CTZ input is non-zero.
Conditional moves are a lottery on x86, in many cases very bad idea. And when
people actually use __builtin_clz*, they state that they don't care about the 0
value, so emitting terribly performing code for it just in case would be wrong.
If forwprop emits the conditional in separate blocks for the CTZ_DVAZ!=2 case,
on targets where conditional moves are beneficial for it it can also emit them,
or emit the jump which say on x86 will be most likely faster than cmov.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug tree-optimization/90838] Detect table-based ctz implementation
[not found] <bug-90838-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2023-02-17 13:03 ` jakub at gcc dot gnu.org
@ 2023-02-17 14:27 ` wilco at gcc dot gnu.org
2023-02-17 14:33 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: wilco at gcc dot gnu.org @ 2023-02-17 14:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
--- Comment #17 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Wilco from comment #15)
> > It would make more sense to move x86 backends to CTZ_DEFINED_VALUE_AT_ZERO
> > == 2 so that you always get the same result even when you don't have tzcnt.
> > A conditional move would be possible, so it adds an extra 2 instructions at
> > worst (ie. still significantly faster than doing the table lookup, multiply
> > etc). And it could be optimized when you know CLZ/CTZ input is non-zero.
>
> Conditional moves are a lottery on x86, in many cases very bad idea. And
> when people actually use __builtin_clz*, they state that they don't care
> about the 0 value, so emitting terribly performing code for it just in case
> would be wrong.
> If forwprop emits the conditional in separate blocks for the CTZ_DVAZ!=2
> case, on targets where conditional moves are beneficial for it it can also
> emit them, or emit the jump which say on x86 will be most likely faster than
> cmov.
Well GCC emits a cmov for this (-O2 -march=x86-64-v2):
int ctz(long a)
{
return (a == 0) ? 64 : __builtin_ctzl (a);
}
ctz:
xor edx, edx
mov eax, 64
rep bsf rdx, rdi
test rdi, rdi
cmovne eax, edx
ret
Note the extra 'test' seems redundant since IIRC bsf sets Z=1 if the input is
zero.
On Zen 2 this has identical performance as the plain builtin when you loop it
as res = ctz (res) + 1; (ie. measuring latency of non-zero case). So I find it
hard to believe cmov is expensive on modern cores.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug tree-optimization/90838] Detect table-based ctz implementation
[not found] <bug-90838-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2023-02-17 14:27 ` wilco at gcc dot gnu.org
@ 2023-02-17 14:33 ` jakub at gcc dot gnu.org
2023-02-17 14:41 ` gabravier at gmail dot com
` (2 subsequent siblings)
10 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-17 14:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It is generally a win for cases where the condition can't be predicted, while
if it can, jumps are much better. We have dozens or hundreds of PRs about this
in either direction on x86.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug tree-optimization/90838] Detect table-based ctz implementation
[not found] <bug-90838-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2023-02-17 14:33 ` jakub at gcc dot gnu.org
@ 2023-02-17 14:41 ` gabravier at gmail dot com
2023-02-17 14:45 ` jakub at gcc dot gnu.org
2023-02-17 16:32 ` wilco at gcc dot gnu.org
10 siblings, 0 replies; 11+ messages in thread
From: gabravier at gmail dot com @ 2023-02-17 14:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
--- Comment #19 from Gabriel Ravier <gabravier at gmail dot com> ---
(In reply to Jakub Jelinek from comment #14)
> The patch does:
> + bool zero_ok = CTZ_DEFINED_VALUE_AT_ZERO (TYPE_MODE (type), ctzval)
> == 2;
> +
> + /* Skip if there is no value defined at zero, or if we can't easily
> + return the correct value for zero. */
> + if (!zero_ok)
> + return false;
> + if (zero_val != ctzval && !(zero_val == 0 && ctzval == type_size))
> + return false;
> For CTZ_DEFINED_VALUE_AT_ZERO == 1 we could support it the same way but we'd
> need
> to emit into the IL an equivalent of val == 0 ? zero_val : .CTZ (val) (with
> GIMPLE_COND and a separate bb - not sure if anything in forwprop creates new
> basic blocks right now), where there is a high chance that RTL opts would
> turn it back into unconditional
> ctz.
> That still wouldn't help non--mbmi x86, because CTZ_DEFINED_VALUE_AT_ZERO is
> 0 there.
> We could handle even that case by doing the branches around, but those would
> stay there
> in the generated code, at which point I wonder whether it would be a win.
> The original
> code is branchless...
If the original code being branchless makes it faster, wouldn't that imply that
we should use the table-based implementation when generating code for
`__builtin_ctz` ?
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug tree-optimization/90838] Detect table-based ctz implementation
[not found] <bug-90838-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2023-02-17 14:41 ` gabravier at gmail dot com
@ 2023-02-17 14:45 ` jakub at gcc dot gnu.org
2023-02-17 16:32 ` wilco at gcc dot gnu.org
10 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-17 14:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
No, because __builtin_ctz is branchless too, it just has UB when the argument
is 0.
^ permalink raw reply [flat|nested] 11+ messages in thread* [Bug tree-optimization/90838] Detect table-based ctz implementation
[not found] <bug-90838-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2023-02-17 14:45 ` jakub at gcc dot gnu.org
@ 2023-02-17 16:32 ` wilco at gcc dot gnu.org
10 siblings, 0 replies; 11+ messages in thread
From: wilco at gcc dot gnu.org @ 2023-02-17 16:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
--- Comment #21 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Gabriel Ravier from comment #19)
> If the original code being branchless makes it faster, wouldn't that imply
> that we should use the table-based implementation when generating code for
> `__builtin_ctz` ?
__builtin_ctz is 3-4 times faster than the table implementation, so this
optimization is always worth it. This is why I believe the current situation is
not ideal since various targets still set CTZ_DEFINED_VALUE_AT_ZERO to 0 or 1.
One option would be to always allow it in Gimple (perhaps add an extra argument
for the value to return for a zero input), and at expand time check whether the
backend supports the requested value. It it doesn't, emit branches.
^ permalink raw reply [flat|nested] 11+ messages in thread