[Bug c++/106384] New: -Wunused-variable is triggered for static const type-deduced initializer lists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106384
Bug ID: 106384
Summary: -Wunused-variable is triggered for static const
type-deduced initializer lists
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: martingalvan at sourceware dot org
Target Milestone: ---
It looks like -Wunused-variable is being triggered for global initializer
lists, even though they're declared as static const. This only seems to happen
if the list is declared using auto; if we explicitly write
std::initializer_list, the warning goes away.
For example, the following code triggers the warning:
#include
static const auto list = {4, 2};
int main()
{
return 0;
}
whereas the following works fine:
#include
static const std::initializer_list list = {4, 2};
int main()
{
return 0;
}
See also https://godbolt.org/z/evazo9zeM
IMHO auto shouldn't make any difference here; the warning shouldn't be
triggered as it doesn't imply -Wunused-const-variable for C++.
[Bug libgcc/97754] New: arm/lib1funcs.S (RETLDM): CFI may be incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97754
Bug ID: 97754
Summary: arm/lib1funcs.S (RETLDM): CFI may be incorrect
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: martingalvan at sourceware dot org
Target Milestone: ---
Hi all, I'm looking at the RETLDM macro for the ARM libgcc code:
.macro RETLDM regs=, cond=, unwind=, dirn=ia
#if defined (__INTERWORKING__)
.ifc "\regs",""
ldr\condlr, [sp], #8
.else
# if defined(__thumb2__)
pop\cond{\regs, lr}
# else
ldm\cond\dirn sp!, {\regs, lr}
# endif
.endif
.ifnc "\unwind", ""
/* Mark LR as restored. */
97: cfi_pop 97b - \unwind, 0xe, 0x0
.endif
bx\cond lr
#else
<...>
.endm
Here we can see that for the __INTERWORKING__ case, some CFI data is emitted if
we have an 'unwind' argument. However, I believe this may be wrong if a RETLDM
macro appears in the middle of another function. For the __INTERWORKING__ case,
the resulting output would be e.g:
pop {r4, r5, lr}
cfi_pop <...>
bx lr
Here, 'cfi_pop' would affect the rest of the function unless the caller is
careful enough to restore the CFI status for lr after doing RETLDM. This can
happen e.g. if we pass a 'cond' argument, which means the branch may not be
taken.
Unless I'm mistaken, the way to fix this would be to introduce a couple of
.cfi_remember/restore_state directives:
.ifnc "\unwind", ""
/* Mark LR as restored. */
.cfi_remember_state
97: cfi_pop 97b - \unwind, 0xe, 0x0
.endif
bx\cond lr
.ifnc "\unwind", ""
.cfi_restore_state
.endif
If this is correct, I'll send in a patch to add this change.
Speaking of this file, I have a couple more questions:
1. The file is defining macros like cfi_start, cfi_push, etc which insert the
CFI data directly in binary form. Why can't we use gas' .cfi_* directives as we
do elsewhere? If we can, I'll send a separate patch to add this change as well.
2. Why is the __INTERWORKING__ macro only defined for ARMv4t? I'm not saying
that this is wrong, just curious.
Thanks.
[Bug other/91085] fixincludes breaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085 Tendel10 at protonmail dot com changed: What|Removed |Added CC||Tendel10 at protonmail dot com martingalvan at sourceware dot org changed: What|Removed |Added CC||martingalvan at sourceware dot org --- Comment #9 from Tendel10 at protonmail dot com --- I am having this issue as well, any updates on this bug? --- Comment #10 from Tendel10 at protonmail dot com --- I am having this issue as well, any updates on this bug? --- Comment #11 from martingalvan at sourceware dot org --- This bug is still happening on gcc 9.2.1.
[Bug c++/88050] New: Add a warning for breaking the "Rule of Three"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88050
Bug ID: 88050
Summary: Add a warning for breaking the "Rule of Three"
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: martingalvan at sourceware dot org
Target Milestone: ---
Hi all,
I noticed that gcc doesn't have an option to warn the user when they're
breaking C++'s "Rule of Three" (or Five (or Zero)). For example, this code
doesn't trigger anything when built with e.g. -Wall -Wextra -Wpedantic
-Weffc++:
class Type
{
~Type()
{}
};
int main()
{
Type t;
return 0;
}
It would be useful to have a way catch these at compile time.
[Bug c++/85749] Possible -Wsign-conversion false negative with std::default_random_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85749 --- Comment #1 from martingalvan at sourceware dot org --- Created attachment 44119 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44119=edit Preprocessed source
[Bug c++/85749] New: Possible -Wsign-conversion false negative with std::default_random_engine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85749
Bug ID: 85749
Summary: Possible -Wsign-conversion false negative with
std::default_random_engine
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: martingalvan at sourceware dot org
Target Milestone: ---
I have the following code:
#include
#include
int main()
{
const auto seed =
std::chrono::system_clock::now().time_since_epoch().count();
std::default_random_engine generator(seed);
generator.seed(seed);
return 0;
}
If I build this using g++ -std=c++17 -Wsign-conversion -o random random.cpp, I
get the following warning:
random.cpp: In function ‘int main()’:
random.cpp:9:24: warning: conversion to ‘std::linear_congruential_engine::result_type {aka long unsigned int}’ from
‘long int’ may change the sign of the result [-Wsign-conversion]
generator.seed(seed);
However, AFAIK the std::default_random_engine constructor also takes a
result_type (which should be unsigned). Therefore, the warning should also come
up when constructing 'generator'.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.2.0-8ubuntu3.2' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3.2)
