https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #16 from andysem at mail dot ru ---
Thanks for the fix. And for the explanation.
Yes, backport would be nice.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #7 from andysem at mail dot ru ---
Reproduces for me:
$ g++ -g2 -O0 -o codecvt_length_bug codecvt_length_bug.cpp
$ ./codecvt_length_bug
*** buffer overflow detected ***: terminated
Aborted (core dumped)
$ g++ -v
Using built-in specs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #8 from andysem at mail dot ru ---
I think, sanitizers won't detect it unless you build libstdc++ with them
enabled. I would expect valgrind to detect it though.
I think, Ubuntu builds libstdc++ with _FORTIFY_SOURCE enabled, which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #3 from andysem at mail dot ru ---
I'm not sure about the meaning of the wrong-code keyword, but just to clear, I
do not consider the code sample in the bug report to be wrong (i.e. incorrect
usage of the standard library). If it is w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116697
--- Comment #2 from andysem at mail dot ru ---
When we say "uninitialized", we refer to a specific data access, i.e. when a
certain operation uses an object whose value is unspecified as input. With some
stretch, you could consider a mere load of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116697
Bug ID: 116697
Summary: Bogus -Wuninitialized warning when no access to
uninitialized data is done
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #13 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #12)
> (In reply to andysem from comment #11)
> > > I'm not sure what you mean by "the compiler is free to generate code that
> > > takes it into account."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #11 from andysem at mail dot ru ---
> I'm not sure what you mean by "the compiler is free to generate code that
> takes it into account." Takes what into account? What problem does that
> freedom cause?
I mean the compiler could mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #4 from andysem at mail dot ru ---
> It's mostly OK to mix code with -frtti and -fno-rtti, but sometimes it bites
> you.
Note that in this case, it is the standard library that is built with -frtti
and the rest of the code is built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #3 from andysem at mail dot ru ---
I think, a failing dynamic_cast would not be useful as this would make
std::use_facet unusable with -fno-rtti.
Re. ODR violation in the latest code, while it is true that the
dynamic/static_cast is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
Bug ID: 113099
Summary: locale without RTTI uses dynamic_cast before gcc 13.2
or has ODR violation since gcc 13.2
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110096
andysem at mail dot ru changed:
What|Removed |Added
CC||andysem at mail dot ru
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109761
--- Comment #2 from andysem at mail dot ru ---
I don't see how completeness of outer is related to nested's destructor. Or put
it another way, how nested's destructor noexcept specification has anything to
do with outer, whether it is completed o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109761
Bug ID: 109761
Summary: Nested class destructor's noexcept specification
incorrectly considered as too loose compared to the
outer class
Product: gcc
Version: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98612
andysem at mail dot ru changed:
What|Removed |Added
CC||andysem at mail dot ru
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108401
--- Comment #7 from andysem at mail dot ru ---
To be clear, I'm not asking the compiler to recognize the particular pattern of
alternating 0x00 and 0xFF bytes. Because hardcoding this particular pattern
won't improve generated code in other cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108401
--- Comment #6 from andysem at mail dot ru ---
(In reply to Andrew Pinski from comment #1)
> >and gcc 12 generates a worse code:
>
> it is not worse really; depending on the how fast moving between the
> register sets is.
I meant "worse" compar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108401
Bug ID: 108401
Summary: gcc defeats vector constant generation with intrinsics
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98978
--- Comment #6 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to andysem from comment #3)
> > Is there no way to improve standard components implementation? I'd imagine
> > you could provide the new imple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #10 from andysem at mail dot ru ---
(In reply to andysem from comment #8)
> (In reply to Jonathan Wakely from comment #7)
> >
> > Do you want ODR violations? Because that's how you get ODR violations.
>
> I understand this, but my p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #8 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to andysem from comment #6)
> > So do you think this is a problem in Boost.Filesystem?
>
> I don't know yet, I can't reproduce it with the B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #6 from andysem at mail dot ru ---
So do you think this is a problem in Boost.Filesystem?
I would say this is a regression in string_view as the code is valid in
pre-C++23, and I would expect it to stay valid in C++23 onwards. Should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #4 from andysem at mail dot ru ---
It fails the same way with 12.2 and trunk on godbolt:
https://gcc.godbolt.org/z/rT6TWhhvP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
--- Comment #3 from andysem at mail dot ru ---
I don't have the environment to build gcc locally, so I can't readily test
trunk. But I have been told the same issue reproduces with gcc-12
20220319-1ubuntu1 from Ubuntu 22.04:
https://github.com/b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106808
Bug ID: 106808
Summary: std::string_view range concept requirement causes
compile error with Boost.Filesystem
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #2 from andysem at mail dot ru ---
> outside the [s, s + max_size) range
This should be [from, from_to) range. Sorry, posted a little too soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
--- Comment #1 from andysem at mail dot ru ---
Created attachment 53089
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53089&action=edit
Test case to reproduce the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105857
Bug ID: 105857
Summary: codecvt::do_length causes unexpected buffer overflow
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88165
--- Comment #13 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to Fedor Chelnokov from comment #7)
> > This struct definition:
> > ```
> > struct A {
> > struct B {
> > int i = 0;
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102293
--- Comment #6 from andysem at mail dot ru ---
Ok, thanks for confirming.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102293
--- Comment #4 from andysem at mail dot ru ---
(In reply to Martin Liška from comment #3)
> Dup.
>
> *** This bug has been marked as a duplicate of bug 100161 ***
This bug isn't about a warning but about an ICE. Are you positive this is a
dupli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102293
--- Comment #2 from andysem at mail dot ru ---
The code compiles if -std=c++03 is replaced with e.g. -std=c++11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102293
--- Comment #1 from andysem at mail dot ru ---
I forgot to mention that the same code compiles successfully with gcc 9.4.0.
And here is the output from gcc 11.1.0:
In file included from ./boost/assert.hpp:58,
from
./boost/xpres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102293
Bug ID: 102293
Summary: [10 regression] ICE when compiling Boost.Xpressive (in
value_dependent_expression_p, at cp/pt.c:26730)
Product: gcc
Version: 10.3.0
Status: UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #9 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #8)
>
> Submitting a bug for the LTO problem is only helpful if it comes with a test
> case to reproduce it. I have heard about problems suppressing warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #7 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #6)
> In C/C++ the size of the largest object is PTRDIFF_MAX - 1 bytes. This is
> necessary so that the difference between the address of its first byte and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #5 from andysem at mail dot ru ---
(In reply to Martin Sebor from comment #4)
> The case of _size being very large and n very small may be handled correctly
> by the original code thanks to the check for _capacity but because its valu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
--- Comment #3 from andysem at mail dot ru ---
To put it another way, the case of _size being large and n small is valid, and
memset (and resize in general) do behave correctly in this case. Which is why
the warning is bogus and the suggested ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
andysem at mail dot ru changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100477
Bug ID: 100477
Summary: Bogus -Wstringop-overflow warning on memset
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971
--- Comment #10 from andysem at mail dot ru ---
Thanks. Will this be backported to 10 and 11 branches?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971
--- Comment #6 from andysem at mail dot ru ---
Hmm, it looks like the original code has changed enough so that the problem no
longer reproduces, with or without __restrict__. I don't have the older version
of the code, so I can't tell what changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971
--- Comment #3 from andysem at mail dot ru ---
I tried adding __restrict__ to the equivalents of x, y1 and y2 in the original
larger code base and it didn't help. The compiler (gcc 10.2) would still
generate the same half-vectorized code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971
--- Comment #1 from andysem at mail dot ru ---
For reference, an ideal version of this code should look something like this:
test(A&, A const&, A const&):
movdqu (%rsi), %xmm0
movdqu (%rdi), %xmm1
movdqu (%rdx), %xmm2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971
Bug ID: 99971
Summary: GCC generates partially vectorized and scalar code at
once
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99563
--- Comment #8 from andysem at mail dot ru ---
Thanks again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99563
--- Comment #5 from andysem at mail dot ru ---
Thanks. Will there be a fix in branch 10?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99563
Bug ID: 99563
Summary: Code miscompilation caused by _mm256_zeroupper()
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98978
--- Comment #3 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #1)
> This would be an ABI break, and so not going to happen.
Is there no way to improve standard components implementation? I'd imagine you
could provide th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98978
Bug ID: 98978
Summary: Consider packing _M_Engaged in the tail padding of T
in optional<>
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97891
--- Comment #5 from andysem at mail dot ru ---
Using a register is beneficial even for bytes and words if there are multiple
of mov instructions. But there has to be a single reg0 for all movs.
I'm not very knowlegeable about gcc internals, but w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97891
--- Comment #1 from andysem at mail dot ru ---
As a side note, the "xorl %edx, %edx" in the original code should have been
moved outside the loop, as it was in the code with __asm__ block.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97891
Bug ID: 97891
Summary: [x86] Consider using registers on large
initializations
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325
--- Comment #8 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to andysem from comment #2)
> > (In reply to Jonathan Wakely from comment #1)
> > > You can use a #pragma to disable -Wdeprecated locally
> >
54 matches
Mail list logo
