[Bug other/59783] New: inline expansion stack when attribute error/warning triggered is displayed incorrectly

[Bug other/59783] New: inline expansion stack when attribute error/warning triggered is displayed incorrectly

[daniel.santos at pobox dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59783

            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 mechanism,
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 = 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 ‘validate_pair’,
    inlined from ‘main’ at asdf.c:15:18:
asdf.c:6:15: error: call to ‘diedie’ declared with attribute error: x + y = too
many
         diedie();
               ^
In function ‘validate_pair’,
    inlined from ‘main’ at asdf.c:10:18:
asdf.c:6:15: error: call to ‘diedie’ declared with attribute error: x + y = 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 preprocessor
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 inline
function instantiation/expansion stack, e.g.:

In function ‘validate_pair’,
    inlined from ‘a2’ at asdf.c:15:18:
    inlined from ‘b’ at asdf.c:23:25:
    inlined from ‘main’ at asdf.c:30:15:
asdf.c:6:15: error: call to ‘diedie’ declared with attribute error: x + y = 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 ‘validate_pair’,
    inlined from ‘a2’ [with x=28, y=14] at asdf.c:15:18:
    inlined from ‘b’ [with x=28, y=14] at asdf.c:23:25:
    inlined from ‘main’ [with x=28, y=14] at asdf.c:30:15:
asdf.c:6:15: error: call to ‘diedie’ declared with attribute error: x + y = too
many
         diedie();

Now I realize that actually involves a lot as many data types can be treated 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: <gcc-bugs-return-440169-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <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 20136 invoked by uid 48); 13 Jan 2014 05:29:05 -0000
From: "kirill.yukhin at intel dot com" <gcc-bugzilla@gcc.gnu.org>
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: <bug-59754-4-p8V7jr9QKk@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59754-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59754-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: 2014-01/txt/msg01311.txt.bz2
Content-length: 464

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY754

--- Comment #6 from Yukhin Kirill <kirill.yukhin at intel dot com> ---
(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!

[Bug other/59783] inline expansion stack when attribute error/warning triggered is displayed incorrectly

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59783

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-01-13
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug other/59783] inline expansion stack when attribute error/warning triggered is displayed incorrectly

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59783

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If you want precise call trace in the diagnostics, you need to use -g.

[Bug other/59783] inline expansion stack when attribute error/warning triggered is displayed incorrectly

[daniel.santos at pobox dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59783

--- Comment #3 from Daniel Santos <daniel.santos at pobox dot com> ---
(In reply to Jakub Jelinek from comment #2)
> If you want precise call trace in the diagnostics, you need to use -g.

holy backtrace batman!