From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4602 invoked by alias); 4 Jul 2013 19:35:33 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 4580 invoked by uid 48); 4 Jul 2013 19:35:30 -0000 From: "daniel.kruegler at googlemail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/57825] Template specialization for ref qualified member pointers Date: Thu, 04 Jul 2013 19:35: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.8.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: daniel.kruegler at googlemail dot com X-Bugzilla-Status: UNCONFIRMED 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: In-Reply-To: References: 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: 2013-07/txt/msg00285.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D57825 --- Comment #4 from Daniel Kr=C3=BCgler --- (In reply to Tomasz Kami=C5=84ski from comment #2) > Propably this is also causing the problem with the standard library > is_function and is_member function traits, because they cannot be > implemented correclty. No, this was a different problem and it became fixed. Your example code wor= ks fine gcc 4.9.0 20130616 (experimental) (I do know this, because I recently completed the implementation of std::function for gcc) >>From gcc-bugs-return-425779-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 04 19:43:06 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 7147 invoked by alias); 4 Jul 2013 19:43:06 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 7098 invoked by uid 48); 4 Jul 2013 19:42:57 -0000 From: "daniel.kruegler at googlemail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/57825] Template specialization for ref qualified member pointers Date: Thu, 04 Jul 2013 19: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: 4.8.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: daniel.kruegler at googlemail dot com X-Bugzilla-Status: UNCONFIRMED 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: In-Reply-To: References: 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: 2013-07/txt/msg00286.txt.bz2 Content-length: 459 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D57825 --- Comment #5 from Daniel Kr=C3=BCgler --- (In reply to Paolo Carlini from comment #3) > Daniel, which library testcases did we commit?!? ;) Crazy. During an intermediate state we had bug 57388 which prevented for some time= the proper specialization of std::is_function. The difference in the here discu= ssed case is the specialization for pointer to members >>From gcc-bugs-return-425780-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 04 19:46:10 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 8601 invoked by alias); 4 Jul 2013 19:46:10 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 8555 invoked by uid 48); 4 Jul 2013 19:46:07 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended Date: Thu, 04 Jul 2013 19:46:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.3.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-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: In-Reply-To: References: 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: 2013-07/txt/msg00287.txt.bz2 Content-length: 1279 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776 --- Comment #14 from Marc Glisse --- (In reply to Jakub Jelinek from comment #12) > Not all CPUs that have defined behavior for 0 define it to the precision > though, and even on i?86 it is undefined even when using lzcnt/tzcnt on > older CPUs. > Even the libgcc routines provide various return values for 0 depending on > target (look for COUNT_LEADING_ZEROS_0). > So it is not an option to redefine the builtins, they are undefined behavior > for 0 and that can't change. I didn't mean to document the value for 0 or have other optimizations create calls to this builtin relying on this property. I just meant that if we already have a call to clz and the argument happens to be 0 (which is undefined), we could optimize based on the assumption that the result is the precision, that may break less code than your current patch. Otherwise we might as well assert (well, tell it to VRP) that the argument is non-zero. But you are probably right that trying to work around the undefined value for 0 is wrong, another builtin should be used instead. > There is __builtin_ffs that provides defined behavior for 0. So, should that be used for the x86 and power intrinsics? Or a new __builtin_clz0?