[Bug c/66918] New: Disable "inline function declared but never defined" warning

[Bug c/66918] New: Disable "inline function declared but never defined" warning

[eugene.zelenko at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918

            Bug ID: 66918
           Summary: Disable "inline function declared but never defined"
                    warning
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eugene.zelenko at gmail dot com
  Target Milestone: ---

It looks like there is no way to disable this warning (at least in 5.2.0).

Part of my code base is built with -Werror, so I usually treat warnings
introduced in new versions of GCC as no errors (-Wno-error). "inline function
declared but never defined" point to -Werror as way to disable it, but I think
will be better to have individual switch.

[Bug c/66918] Disable "inline function declared but never defined" warning

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Could you explain why you don't want to have this warning really.  This warning
is telling you that the inline function is not defined  just like static
functions.

[Bug c/66918] Disable "inline function declared but never defined" warning

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-07-18
                 CC|                            |manu at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Does Clang have an option for this? GCC could use the same name.

(The same warning exists in the C++ FE, thus it should be controlled by the
same option).
>From gcc-bugs-return-492756-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 18 21:59:20 2015
Return-Path: <gcc-bugs-return-492756-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 58061 invoked by alias); 18 Jul 2015 21:59: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 58035 invoked by uid 48); 18 Jul 2015 21:59:15 -0000
From: "derodat at adacore dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
Date: Sat, 18 Jul 2015 21:59: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: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: derodat at adacore 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-66790-4-SzrVlEqj5B@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66790-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66790-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-07/txt/msg01646.txt.bz2
Content-length: 3026

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790

--- Comment #4 from Pierre-Marie de Rodat <derodat at adacore dot com> ---
(In reply to Pierre-Marie de Rodat from comment #0)
> Given the "somelabel" code path, I would rather expect DF_REF_CHAIN to hold
> a NULL reference to materialize the lack of initialization in one path. I
> found the DF_LR_IN/DF_LR_OUT macros from df.h: they provide information
> about uninitialized variables but the associated comment says they should
> not be used ("This intolerance should eventually be fixed."). Besides, they
> provide a basic-block-level information whereas we are rather interested in
> instruction-level information in REE.

Having read more thoroughly dataflow code, I saw the DF_LIVE problem claims
that it provides "the logical AND of the IN and OUT sets from the LR problem
and the must-initialized problem", which would be useful: it could provide a
conservative set of registers that *may* be uninitialized (i.e. all registers
that may be uninitialized are included).

So I started looking at the DF_LIVE results, but I got strange results. For
instance, with a very simple C function:

    extern void do_nothing (void);

    int foo (int i, int b) {
      int r;
      if (b) { do_nothing (); r = i; }
      do_nothing ();
      return r & 0xffff;
    }
    /* foobar.c */

… the reference to the register holding "r" at the return statement is present
in the IN set for the corresponding basic block:

     $ gdb --args cc1 -O2 foobar.c
    (gdb) b find_removable_extensions
    (gdb) r
    (gdb) p dump_function_to_file(cfun.decl, stderr, 0)
    [...]
    (note 13 12 14 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
    (call_insn 14 13 15 4 [...])
    (insn 15 14 21 4 (set (reg:SI 0 ax [orig:92 D.1771 ] [92])
            (zero_extend:SI (reg:HI 3 bx [orig:87 r ] [87])))
            foobar.c:13 136 {*zero_extendhisi2}
        (nil))
    [...]
    (gdb) p df_live_top_dump(cfun.cfg.x_basic_block_info.m_vecdata[4], stderr)
    ;; live in 3 [bx] 7 [sp]
    ;; live gen 0 [ax]
    ;; live kill

This looks wrong to me: there is a path from the entry to this basic block that
doesn't cross a definition for the bx register, so it's not must-initialized
and thus should not be present in this set. Digging further, I noticed that in
df_live_confluence_n, we do:

    IN(succ) = OUT(pred) OR IN(succ)

… which, I think, should instead be an AND with respect to the comment: we
want to keep only registers that are must-initialized, so as soon as one *may*
be uninitialized it is out of the result. But this is how it works since the
dataflow merge in 2006… and doing this change unsurprisingly makes the compiler
generate wrong code.

So assuming the LIVE pass actually does not compute must-initialized registers
(but instead what I would call "maybe-initialized registers"), I tried to add
another problem: MIR (Must-Initialized Registers) and to use it in the REE
pass. I'm about to submit the patch on gcc-patches@.
>From gcc-bugs-return-492757-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 19 00:01:29 2015
Return-Path: <gcc-bugs-return-492757-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13754 invoked by alias); 19 Jul 2015 00:01:29 -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 13722 invoked by uid 48); 19 Jul 2015 00:01:24 -0000
From: "a-gnu.org at 0au dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/66933] New: [AVR] Shifted multiplication produces suboptimal asm
Date: Sun, 19 Jul 2015 00:01: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.2.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: a-gnu.org at 0au dot de
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-66933-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-07/txt/msg01647.txt.bz2
Content-length: 1317

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf933

            Bug ID: 66933
           Summary: [AVR] Shifted multiplication produces suboptimal asm
           Product: gcc
           Version: 5.2.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: a-gnu.org at 0au dot de
  Target Milestone: ---

The function

    uint8_t test(uint8_t a, uint8_t b) { return (a*b) >> 7; }

compiles into the following assembly, with e.g.

    avr-gcc -mmcu=atmega328 -S -O3 test.c

(or any other optimization flag)

    test:
        mul r24,r22
        movw r24,r0
        clr __zero_reg__
        lsl r24
        mov r24,r25
        rol r24
        sbc r25,r25
        ret

This has two obvious possible enhancements:
- It uses mul instead of fmul: fmul calculates (a*b)<<1,
  so the high byte is already the correct return value of
  the function
- After calculating the return value (wih "rol r24"),
  there's an instruction "sbc r25, r25" that puts a
  completely unneeded value in r25, if I'm not mistaken
  it's 255 if (a*b) & 0x8000, else 0.

A better version that uses 8 instead of 12 cycles would be

    test:
        fmul r24, r22
        mov r24, r1
        clr __zero_reg__
        ret

[Bug c/66918] Disable "inline function declared but never defined" warning

[eugene.zelenko at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918

--- Comment #4 from Eugene Zelenko <eugene.zelenko at gmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #3)
> Does Clang have an option for this? GCC could use the same name.
> 
> (The same warning exists in the C++ FE, thus it should be controlled by the
> same option).

I tried small example with Clang 3.7 https://gcc.godbolt.org and it looks like
it doesn't have such warning (I used -Weverything -std=C++11 and C++14).

GCC already has -Wunused-function and it seems reasonable to extend it to
inline functions.
>From gcc-bugs-return-492776-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 19 14:37:34 2015
Return-Path: <gcc-bugs-return-492776-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 51778 invoked by alias); 19 Jul 2015 14:37:34 -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 51739 invoked by uid 48); 19 Jul 2015 14:37:30 -0000
From: "jana at saout dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/64394] ICE: in build_linearized_memory_access, at graphite-interchange.c:121 (isl_constraint.c:558: expecting integer value) with -floop-interchange
Date: Sun, 19 Jul 2015 14:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jana at saout dot de
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-64394-4-jqS1jHcPq7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64394-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64394-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-07/txt/msg01666.txt.bz2
Content-length: 263

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd394

--- Comment #4 from Jana Saout <jana at saout dot de> ---
Indeed - I've applied the patch on top of 5.2.0 and I can't reproduce the issue
anymore with any of the packages that have failed before. Looking fine.

[Bug c/66918] Disable "inline function declared but never defined" warning

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I don't think the C++ FE has this warning; it's about C99 inlines.

I think this should not be a part of -Wunused-function, maybe just a part of
-Wpedantic warning.

[Bug c/66918] Disable "inline function declared but never defined" warning

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918

--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #5)
> I don't think the C++ FE has this warning; it's about C99 inlines.

If not, it has a very similar warning:

/home/manuel/test.cc:1:13: warning: inline function ‘void test()’ used but
never defined
 inline void test(void);
             ^
>From gcc-bugs-return-492831-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 20 13:15:58 2015
Return-Path: <gcc-bugs-return-492831-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 38062 invoked by alias); 20 Jul 2015 13:15:57 -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 37986 invoked by uid 48); 20 Jul 2015 13:15:52 -0000
From: "vehre at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/66035] [5/6 Regression] gfortran ICE segfault
Date: Mon, 20 Jul 2015 13:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vehre at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: vehre at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-66035-4-WdKb4n7nUP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66035-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66035-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-07/txt/msg01721.txt.bz2
Content-length: 399

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf035

vehre at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from vehre at gcc dot gnu.org ---
Fixed, closing.

[Bug c/66918] Disable "inline function declared but never defined" warning

[federico.kircheis at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918

Federico Kircheis <federico.kircheis at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |federico.kircheis at gmail dot com

--- Comment #9 from Federico Kircheis <federico.kircheis at gmail dot com> ---
Hello,

I stumbled on this warning too, and would really like to disable it.

Having a defined but not implemented function can help to detect errors at
compile time since c++11, for example consider


----
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wundefined-inline"
constexpr int stop_compilation();
#pragma GCC diagnostic pop

constexpr int foo(int i){
   return is_not_valid(i) ? stop_compilation() : i+42;
}
----


thanks to `stop_compilation()`, we force the user to use foo in a constexpr
context, and we can validate the parameter.

The code works as intended with GCC, MSVC and clang(!).


Rewriting the code as

----
constexpr int foo(int i){
   return is_not_valid(i) ? throw 42 : i+42;
}
----

makes `foo` usable in a non-constexpr context.

In clang it is possible to ignore the warning with "-Wundefined-inline", maybe
GCC could adopt the same switch?

[Bug c/66918] Disable "inline function declared but never defined" warning

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |44209
                 CC|                            |egallager at gcc dot gnu.org

--- Comment #10 from Eric Gallager <egallager at gcc dot gnu.org> ---
This is an instance of bug 44209


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209
[Bug 44209] [meta-bug] Some warnings are not linked to diagnostics options

[Bug c/66918] Disable "inline function declared but never defined" warning

[oficsu at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918

Ofee Oficsu <oficsu at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |oficsu at gmail dot com

--- Comment #11 from Ofee Oficsu <oficsu at gmail dot com> ---
There's another example. A bit suspicious as it's related to loopholes, but GCC
produces too many warning on my example and there's no way to suppress them:
https://godbolt.org/z/PbnM8cfc1

[Bug c/66918] Disable "inline function declared but never defined" warning

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 100343 has been marked as a duplicate of this bug. ***