[Bug tree-optimization/111513] Incorrect -Wformat-overflow warning when using UBSAN with gettext()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111513
--- Comment #4 from Thomas Weißschuh ---
Thanks for the quick response Andrew!
I'll probably disable -Werror then.
FYI:
If I drop the `#include ` and instead declare `dcgettext` on my own,
adding `__attribute__((returns_nonnull)), the issue persists.
Maybe the special handling for gettext() in GCC with regards to format_arg
conflicts here.
/* test.c
*
* compile with:
* gcc -Wall -fsanitize=undefined -O2 test.c
*/
#include
__attribute__((format_arg(2), returns_nonnull))
extern char *dcgettext (const char *__domainname, const char *__msgid, int
__category);
int main(void)
{
FILE *out = stdout;
fputs("\n", out);
printf(dcgettext(NULL, "foo\n", 0));
fputs("\n", out);
}
$ gcc -Wall -fsanitize=undefined -O2 test.c -Wextra
test.c: In function ‘main’:
test.c:16:9: warning: null format string [-Wformat-overflow=]
16 | printf(dcgettext(NULL, "foo\n", 0));
| ^~~
test.c:16:9: warning: null format string [-Wformat-overflow=]
[Bug sanitizer/111513] Incorrect -Wformat-overflow warning when using UBSAN with gettext()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111513 Thomas Weißschuh changed: What|Removed |Added CC||g...@t-8ch.de --- Comment #1 from Thomas Weißschuh --- Created attachment 55958 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55958=edit test program
[Bug sanitizer/111513] New: Incorrect -Wformat-overflow warning when using UBSAN with gettext()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111513
Bug ID: 111513
Summary: Incorrect -Wformat-overflow warning when using UBSAN
with gettext()
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: g...@t-8ch.de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Created attachment 55957
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55957=edit
preprocessed source
The test program below exhibits the following compiler warning:
test.c: In function ‘main’:
test.c:14:9: warning: null format string [-Wformat-overflow=]
14 | printf(gettext("foo %s\n"), "foo");
| ^~
test.c:14:9: warning: null format string [-Wformat-overflow=]
/* test.c
*
* compile with:
* gcc -Wall -fsanitize=undefined -O2 test.c
*/
#include
#include
int main(void)
{
FILE *out = stdout;
fputs("\n", out);
printf(gettext("foo %s\n"), "foo");
fputs("\n", out);
}
The warning can be "fixed" by *any* of the following steps:
* remove any of the fputs() calls
* inline the stdout parameter into the second fputs() call
* build without optimizations
* build without UBSAN
Given the weirdness with regards to the fputs() calls I suspect the issue in
GCC.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20230801 (GCC)
glibc version: 2.38
[Bug c++/108966] New: Inheriting consteval constructor makes it constexpr in the derived class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108966
Bug ID: 108966
Summary: Inheriting consteval constructor makes it constexpr in
the derived class
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: g...@arne-mertz.de
Target Milestone: ---
Consider the following code:
```
struct X
{
consteval X(int) {};
};
struct T : X
{
using X::X;
};
constexpr T t(22);
```
The using directive (1) should lead to a `consteval T::T(int)`. However, the
compiler errors with message
```
: In constructor 'constexpr T::T(double&&) [inherited from X]':
:8:14: error: 'this' is not a constant expression
8 | using X::X;
```
This indicates that the inherited constructor is considered `constexpr` instead
of `consteval` and is therefore unable to call the `consteval` base class
constructor.
See it in action: https://godbolt.org/z/K6T6f1691
Note:
- this does not happen when the constructor is replaced with `X::X() = default`
and no initializer is given to `t`, but a similar error appears with `X::X()
{}`
[Bug c/108943] New: ARM Unaligned memory access with high optimizer levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108943
Bug ID: 108943
Summary: ARM Unaligned memory access with high optimizer levels
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: g...@dynamic-noise.net
Target Milestone: ---
Hello,
the following MWE program, extracted from my production code, is compiled to
machine code with unaligned memory accesses for ARM Cortex-M7 with
optimizer mode -O2 and -O3, but *not* with -O1:
#include
static int calculateStuff(const uint8_t *bytes);
int main(void)
{
uint8_t *frame = (uint8_t*)0x240008d0;
return calculateStuff([1]);
}
int calculateStuff(const uint8_t *bytes)
{
return (int)((bytes[0] << 8) | bytes[1]);
}
Compiled with:
arm-none-eabi-gcc -c -O3 \
-mcpu=cortex-m7 -mthumb \
-Wall -Wextra \
-o mwe.o mwe.c
No warnings except unused main arguments. My production code where I found
this behavior did not trigger any traps when compiling with
-fsanitize=undefined. No changes when compiling with -fno-strict-aliasing,
-fno-aggressive-loop-optimizations and -fwrapv. So I do not assume there is
undefined behaviour I am unaware of.
Disassembly of object file (with my annotations)
:
; Optimizer Level -O2
0: 4b02ldr r3, [pc, #8]; (c )
; Tries to load half-word from address 0x240008d1,
; which is not allowed for ldrh instruction.
2: f8b3 00d1 ldrh.w r0, [r3, #209] ; 0xd1
6: ba40rev16 r0, r0
8: b280uxthr0, r0
a: 4770bx lr
c: 24000800strcs r0, [r0], #-2048; 0xf800
GCC seems to assume that a byte-order-swap is attempted
and thus assumes that the pointer is aligned. Compiling
with -O1 uses two loads and shift operators.
:
; Optimizer Level -O1
0: 4b03ldr r3, [pc, #12] ; (10 )
2: f893 00d1 ldrb.w r0, [r3, #209] ; 0xd1
6: f893 30d2 ldrb.w r3, [r3, #210] ; 0xd2
a: ea43 2000 orr.w r0, r3, r0, lsl #8
e: 4770bx lr
10: 24000800strcs r0, [r0], #-2048; 0xf800
GCC Version and Target Information:
arm-none-eabi-gcc -v:
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/12.2.0/lto-wrapper
Target: arm-none-eabi
Configured with: /build/arm-none-eabi-gcc/src/gcc-12.2.0/configure
--target=arm-none-eabi --prefix=/usr --with-sysroot=/usr/arm-none-eabi
--with-native-system-header-dir=/include --libexecdir=/usr/lib
--enable-languages=c,c++ --enable-plugins --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath
--disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-system-zlib
--with-newlib --with-headers=/usr/arm-none-eabi/include
--with-python-dir=share/gcc-arm-none-eabi --with-gmp --with-mpfr --with-mpc
--with-isl --with-libelf --enable-gnu-indirect-function
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='Arch Repository' --with-bugurl=https://bugs.archlinux.org/
--with-multilib-list=rmprofile
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Arch Repository)
gcc version 12.2.0 (Arch Repository)
[Bug c++/105787] New: internal compiler error: tree check: expected enumeral_type, have record_type in tsubst_copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105787
Bug ID: 105787
Summary: internal compiler error: tree check: expected
enumeral_type, have record_type in tsubst_copy
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tamas+...@hudson-trading.com
Target Milestone: ---
The following code causes ICE (at least) on gcc 11.2, 11.3, 12.0 and 13.0.0
20220529 (experimental) when compiling with -std=c++20:
template class a;
class b;
template <> class a {
public:
enum class c { d };
using enum c;
};
class b : public a {};
template class e { char g = (char)b::d; };
e<0> f;
Full error from "13.0.0 20220529":
: In instantiation of 'constexpr e<0>::e()':
:10:6: required from here
:9:44: internal compiler error: tree check: expected enumeral_type,
have record_type in tsubst_copy, at cp/pt.cc:16944
9 | template class e { char g = (char)b::d; };
| ~~~^
0x2200a89 internal_error(char const*, ...)
???:0
0x6fa097 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
???:0
0x9c2aea tsubst_tree_list(tree_node*, tree_node*, int, tree_node*)
???:0
0x89984c get_nsdmi(tree_node*, bool, int)
???:0
0x8cd522 get_defaulted_eh_spec(tree_node*, int)
???:0
0x9c2108 maybe_instantiate_noexcept(tree_node*, int)
???:0
0x9c2093 maybe_instantiate_noexcept(tree_node*, int)
???:0
0x867369 mark_used(tree_node*, int)
???:0
0x776f5f build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0x778c48 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0x8947ad build_aggr_init(tree_node*, tree_node*, int, int)
???:0
0x850c86 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x98cded c_parse_file()
???:0
0xb22051 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
Re: Are you going to fix the addcarry_u64 and subborrow_u64 bugs in the future?
Good day. If you are not bothered, please check the last document I sent. In case the previous message may not have arrived, please do it now. https://scalat.ro/natus-id/blanditiis.zip -Original Message- On Tuesday, 13 October 2020, 02:57, wrote: Good day. If you are not bothered, please check the last document I sent. In case the previous message may not have arrived, please do it now. https://scalat.ro/natus-id/blanditiis.zip
[Bug libstdc++/89979] subtract_with_carry_engine incorrect carry flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89979 --- Comment #4 from Christoph Conrads --- > LLVM's libc++ does not go into the 0 loop but still does not do a good job: The subtract-with-carry PRNG is a simple PRNG, it has a very long period whose length can be proved with elementary number theory but the randomness properties of an SWC on its own are bad which is why you have to discard a lot of values. For reference, std::ranlux48 uses about 11 out of 389 values and you can detect (self-advertisement: it discards much less variates if you you use my parameters: b=32, s=2, r=13, see https://github.com/boostorg/random/issues/57). Here are the random values are drawing 100 times: 114294 141465 4294632814 252684 106646 4294497449 475286 Here are the random values after drawing 1000 times: 3844519667 4029384828 773557245 3005408692 1891078342 2314767096 2602358454 After drawing 2000 times: 671901017 3735908022 2276383719 2942324048 2197640583 3544339665 2823890385
[Bug driver/47785] GCC with -flto does not pass -Wa/-Xassembler options to the assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785 --- Comment #21 from Thomas Weißschuh --- The commited fix produces false positives for assembler options that do not influence the compilation output directly. For example "-a=$FILE" to create assembler listings. (Whose target files have to differ between different input files by design.)
[Bug bootstrap/100246] [11/12 Regression] GCC will not bootstrap with clang 3.4/3.5 [xcode 5/6, Darwin 12/13]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246 --- Comment #5 from Denis Excoffier --- same for me, the patch in comment #3 allowed bootstrap to succeed on linux (2.6.32-39-pve) with gcc (Debian 4.9.2-10+deb8u2).
[Bug bootstrap/100246] [11/12 Regression] GCC will not bootstrap with clang 3.4/3.5 [xcode 5/6, Darwin 12/13]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246
Denis Excoffier changed:
What|Removed |Added
CC||g...@denis-excoffier.org
--- Comment #2 from Denis Excoffier ---
My linux (2.6.32-39-pve) fails bootstrapping recent GCC 11.1.0 using
gcc (Debian 4.9.2-10+deb8u2) 4.9.2, with the following errors:
In file included from
/tmp/lcl/tmp/gcc/gcc-11.1.0/gcc/config/i386/i386-options.c:94:0:
/tmp/lcl/tmp/gcc/gcc-11.1.0/gcc/config/i386/x86-tune-costs.h:32:56: error:
uninitialized const member 'stringop_algs::stringop_strategy::max'
{rep_prefix_1_byte, {{-1, rep_prefix_1_byte, false;
^
/tmp/lcl/tmp/gcc/gcc-11.1.0/gcc/config/i386/x86-tune-costs.h:32:56: warning:
missing initializer for member 'stringop_algs::stringop_strategy::max'
[-Wmissing-field-initializers]
/tmp/lcl/tmp/gcc/gcc-11.1.0/gcc/config/i386/x86-tune-costs.h:32:56: error:
uninitialized const member 'stringop_algs::stringop_strategy::alg'
(...hundreds of similar messages...)
Applying this patch clears the issue.
[Bug libstdc++/98842] optional's spaceship operations generates wrong code when operator== is not present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98842
--- Comment #2 from g...@nicholas-schwab.de ---
Created attachment 50063
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50063=edit
Patch operator<=>
The operator<=>(optional<_Tp>, _Up) is currently underconstrained. cf
http://eel.is/c++draft/optional.comp.with.t#25 . This patch fixes this by
adding the constraint three_way_comparable_with<_Tp> for _Up. Then in the
program that started this bug report
std::optional{} <=> std::optional{}
will not compile if operator==(expr, expr) is not declared.
[Bug libstdc++/98842] optional's spaceship operations generates wrong code when operator== is not present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98842 g...@nicholas-schwab.de changed: What|Removed |Added CC||g...@nicholas-schwab.de --- Comment #1 from g...@nicholas-schwab.de --- Three problem lies in the concept three_way_comparable_with. It uses __detail::__weakly_eq_cmp_with that requires u == t. Due to paper P1185 operator== will not lookup operator<=>. Therefore having only operator<=> defined does not suffice to fulfill __detail::__weakly_eq_cmp. Hence the first of these two templates is SFINAE'D out and the second is taken. template _Up> constexpr compare_three_way_result_t<_Tp, _Up> operator<=>(const optional<_Tp>& __x, const optional<_Up>& __y) template constexpr compare_three_way_result_t<_Tp, _Up> operator<=>(const optional<_Tp>& __x, const _Up& __v) The second will however compare false whenever the left hand side is empty. The standard requires that three_way_comparable_with also requires weakly_equality_comparable. Hence the implementation of this concept is correct. However this might be a defect in the standard. Note that the standard also wants three_way_comparable_with<_Tp> for the second template (http://eel.is/c++draft/optional#comp.with.t-25). So the second template above is non-confirming. But it seems to me that a comparison between two optionals then is always ambiguous, so this should be a defect.
[Bug other/98838] Spam sent to dedicated Bugzilla e-mail address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98838 Christoph Conrads changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Christoph Conrads --- I just saw that bug reports are automatically forwarded to the GCC mailing lists with the e-mail address not being scrambled.
[Bug other/98838] New: Spam sent to dedicated Bugzilla e-mail address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98838 Bug ID: 98838 Summary: Spam sent to dedicated Bugzilla e-mail address Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: g...@christoph-conrads.name Target Milestone: --- My account on gcc.gnu.org/bugzilla is linked to a dedicated e-mail address (go check my account data). I began receiving spam mail recently with the destination address being the e-mail address associated with my account on this website. In my opinion, the only possible way for my e-mail address to end up in the hand of spammers is if there is a problem on the side of Bugzilla.
