From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25648 invoked by alias); 13 Jan 2014 04:11:03 -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 25628 invoked by uid 48); 13 Jan 2014 04:10:57 -0000 From: "daniel.santos at pobox dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug other/59783] New: inline expansion stack when attribute error/warning triggered is displayed incorrectly Date: Mon, 13 Jan 2014 04:11:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: other X-Bugzilla-Version: 4.8.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: daniel.santos at pobox 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: 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: 2014-01/txt/msg01310.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D59783 Bug ID: 59783 Summary: inline expansion stack when attribute error/warning triggered is displayed incorrectly Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: daniel.santos at pobox dot com In C < C11, __attribute__((error())) is a wonderful replacement for _Static_assert() (e.g., http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include= /linux/compiler.h#n316). However, when used in nested __always_inline functions where parameters to = the function are treated as compiletime constants and tested via such a mechani= sm, the compiler doesn't tell us the correct root cause of the problem. static void inline __attribute__((always_inline)) validate_pair(int x, int = y) { extern void diedie() __attribute__((error("x + y =3D too many"))); if (x + y > 32) diedie(); } static void inline __attribute__((always_inline)) a1(int x, int y) { validate_pair(x, y); /* do some stuff */ } static void inline __attribute__((always_inline)) a2(int x, int y) { validate_pair(x, y); /* do some other stuff */ } static void inline __attribute__((always_inline)) b(int x, int y) { if (x & 1) a1(x, y); else a2(x, y); } int main(int argc, char *argv[]) { b(4, 12); b(5, 13); b(6, 13); b(28, 14); b(27, 14); b(2, 15); return 0; } When built with -O1 or greater, it yields this output: In function =E2=80=98validate_pair=E2=80=99, inlined from =E2=80=98main=E2=80=99 at asdf.c:15:18: asdf.c:6:15: error: call to =E2=80=98diedie=E2=80=99 declared with attribut= e error: x + y =3D too many diedie(); ^ In function =E2=80=98validate_pair=E2=80=99, inlined from =E2=80=98main=E2=80=99 at asdf.c:10:18: asdf.c:6:15: error: call to =E2=80=98diedie=E2=80=99 declared with attribut= e error: x + y =3D too many diedie(); ^ It is correct that these two errors were inlined from the function main, but the line number given is the function that actually calls validate_pair(), although the actual inline instantiation stack for the first error was main= () -> b() -> a1() -> validate_pair() and for the second error main() -> b() -> a1() -> validate_pair(). The work-around is essentially to use a preproces= sor macro, although a lot of simplicity, type-safety, etc. are then lost. Since we are working with compile-time constant values, what would be nice (similar to what is requested for bug #41373) is to display the entire inli= ne function instantiation/expansion stack, e.g.: In function =E2=80=98validate_pair=E2=80=99, inlined from =E2=80=98a2=E2=80=99 at asdf.c:15:18: inlined from =E2=80=98b=E2=80=99 at asdf.c:23:25: inlined from =E2=80=98main=E2=80=99 at asdf.c:30:15: asdf.c:6:15: error: call to =E2=80=98diedie=E2=80=99 declared with attribut= e error: x + y =3D too many diedie(); This way, we can trace it to the exact function call (or inline function expansion) that caused the problem. Welcome to the new age of C metaprogramming! (and thank you for helping to make it possible) This is an= age of compile-time data (if not types, like C++ metaprogramming). So if you *really* wanted to be helpful, you could do something like this: In function =E2=80=98validate_pair=E2=80=99, inlined from =E2=80=98a2=E2=80=99 [with x=3D28, y=3D14] at asdf.c:15:18: inlined from =E2=80=98b=E2=80=99 [with x=3D28, y=3D14] at asdf.c:23:25: inlined from =E2=80=98main=E2=80=99 [with x=3D28, y=3D14] at asdf.c:30:= 15: asdf.c:6:15: error: call to =E2=80=98diedie=E2=80=99 declared with attribut= e error: x + y =3D too many diedie(); Now I realize that actually involves a lot as many data types can be treate= d as compiletime constants, even structs and pointers to structs and functions, = but I didn't think it could hurt to throw it out there. Essentially, displaying the constant parameters of an inlined function call like you do the template parameters in a C++ templatized function or type. See also: bug #41373 >>From gcc-bugs-return-440169-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 13 05:29:10 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 20169 invoked by alias); 13 Jan 2014 05:29:09 -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 20136 invoked by uid 48); 13 Jan 2014 05:29:05 -0000 From: "kirill.yukhin at intel dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/59754] [ree.c] Incorrect merge while working with vector registers Date: Mon, 13 Jan 2014 05:29:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: kirill.yukhin at intel dot com X-Bugzilla-Status: RESOLVED 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: 2014-01/txt/msg01311.txt.bz2 Content-length: 464 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59754 --- Comment #6 from Yukhin Kirill --- (In reply to Jeffrey A. Law from comment #3) > Kirill, can you verify that Jakub's patch restores proper behaviour for your > tests? It'd be greatly appreciated. Hello, I've checked recent trunk with Jakub's changes checked in and it seems that at the moment all of AVX-512 tests are pass (under simulator). Thanks a lot for fixing that!