* [Bug c/66918] Disable "inline function declared but never defined" warning
2015-07-17 20:11 [Bug c/66918] New: Disable "inline function declared but never defined" warning eugene.zelenko at gmail dot com
@ 2015-07-18 8:18 ` pinskia at gcc dot gnu.org
2015-07-18 20:44 ` manu at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu.org @ 2015-07-18 8:18 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/66918] Disable "inline function declared but never defined" warning
2015-07-17 20:11 [Bug c/66918] New: Disable "inline function declared but never defined" warning eugene.zelenko at gmail dot com
2015-07-18 8:18 ` [Bug c/66918] " pinskia at gcc dot gnu.org
@ 2015-07-18 20:44 ` manu at gcc dot gnu.org
2015-07-19 14:03 ` eugene.zelenko at gmail dot com
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: manu at gcc dot gnu.org @ 2015-07-18 20:44 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/66918] Disable "inline function declared but never defined" warning
2015-07-17 20:11 [Bug c/66918] New: Disable "inline function declared but never defined" warning eugene.zelenko at gmail dot com
2015-07-18 8:18 ` [Bug c/66918] " pinskia at gcc dot gnu.org
2015-07-18 20:44 ` manu at gcc dot gnu.org
@ 2015-07-19 14:03 ` eugene.zelenko at gmail dot com
2015-07-20 12:42 ` mpolacek at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: eugene.zelenko at gmail dot com @ 2015-07-19 14:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/66918] Disable "inline function declared but never defined" warning
2015-07-17 20:11 [Bug c/66918] New: Disable "inline function declared but never defined" warning eugene.zelenko at gmail dot com
` (2 preceding siblings ...)
2015-07-19 14:03 ` eugene.zelenko at gmail dot com
@ 2015-07-20 12:42 ` mpolacek at gcc dot gnu.org
2015-07-20 13:14 ` manu at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2015-07-20 12:42 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/66918] Disable "inline function declared but never defined" warning
2015-07-17 20:11 [Bug c/66918] New: Disable "inline function declared but never defined" warning eugene.zelenko at gmail dot com
` (3 preceding siblings ...)
2015-07-20 12:42 ` mpolacek at gcc dot gnu.org
@ 2015-07-20 13:14 ` manu at gcc dot gnu.org
2020-11-04 17:28 ` federico.kircheis at gmail dot com
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: manu at gcc dot gnu.org @ 2015-07-20 13:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/66918] Disable "inline function declared but never defined" warning
2015-07-17 20:11 [Bug c/66918] New: Disable "inline function declared but never defined" warning eugene.zelenko at gmail dot com
` (4 preceding siblings ...)
2015-07-20 13:14 ` manu at gcc dot gnu.org
@ 2020-11-04 17:28 ` federico.kircheis at gmail dot com
2021-10-19 15:57 ` egallager at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: federico.kircheis at gmail dot com @ 2020-11-04 17:28 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/66918] Disable "inline function declared but never defined" warning
2015-07-17 20:11 [Bug c/66918] New: Disable "inline function declared but never defined" warning eugene.zelenko at gmail dot com
` (5 preceding siblings ...)
2020-11-04 17:28 ` federico.kircheis at gmail dot com
@ 2021-10-19 15:57 ` egallager at gcc dot gnu.org
2021-11-15 4:38 ` oficsu at gmail dot com
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: egallager at gcc dot gnu.org @ 2021-10-19 15:57 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/66918] Disable "inline function declared but never defined" warning
2015-07-17 20:11 [Bug c/66918] New: Disable "inline function declared but never defined" warning eugene.zelenko at gmail dot com
` (6 preceding siblings ...)
2021-10-19 15:57 ` egallager at gcc dot gnu.org
@ 2021-11-15 4:38 ` oficsu at gmail dot com
2022-12-28 19:01 ` pinskia at gcc dot gnu.org
2024-09-18 13:34 ` himehaieto at gmail dot com
9 siblings, 0 replies; 11+ messages in thread
From: oficsu at gmail dot com @ 2021-11-15 4:38 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/66918] Disable "inline function declared but never defined" warning
2015-07-17 20:11 [Bug c/66918] New: Disable "inline function declared but never defined" warning eugene.zelenko at gmail dot com
` (7 preceding siblings ...)
2021-11-15 4:38 ` oficsu at gmail dot com
@ 2022-12-28 19:01 ` pinskia at gcc dot gnu.org
2024-09-18 13:34 ` himehaieto at gmail dot com
9 siblings, 0 replies; 11+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-12-28 19:01 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug c/66918] Disable "inline function declared but never defined" warning
2015-07-17 20:11 [Bug c/66918] New: Disable "inline function declared but never defined" warning eugene.zelenko at gmail dot com
` (8 preceding siblings ...)
2022-12-28 19:01 ` pinskia at gcc dot gnu.org
@ 2024-09-18 13:34 ` himehaieto at gmail dot com
9 siblings, 0 replies; 11+ messages in thread
From: himehaieto at gmail dot com @ 2024-09-18 13:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66918
Hime Haieto <himehaieto at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |himehaieto at gmail dot com
--- Comment #13 from Hime Haieto <himehaieto at gmail dot com> ---
For specific functions, annotating them with __attribute__((unused))
(pre-c++17) or [[maybe_unused]] (c++17 and beyond) removes this warning with
clang but not g++. For all functions, using -Wno-unused works for both clang
and g++, at least going back as far as g++ 12.2.0. The diagnostic disparity
with the unused attribute not working for g++ is what needs to be fixed. See
PR116729 for the related report for c code.
^ permalink raw reply [flat|nested] 11+ messages in thread