Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
Consider this C++ code:
struct Base1
{
int x;
};
struct Base2
{
int y;
};
struct Derived
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
Consider this C++ code:
struct res
{
int val;
bool ok;
bool dummy;
};
res fun(int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #4 from John Zwinck ---
Richard Biener said:
> Note it will make a difference for very large objects (and thus very large
> offsets added) which may end up accessing actually mapped memory so IMHO what
> clang does by default is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #11 from John Zwinck ---
Jeffrey, when I compile with -fno-isolate-erroneous-paths-dereference I am
asking the compiler not to insert traps. I filed this issue in hopes that GCC
can better optimize when it is told not to insert traps
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
If I cast "this" in a base class constructor to a derived class type, there is
no warning even with -Wall -Wextra. Such a cast is
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
For the following example, GCC 8.3 uses memmove unless compiling with
-DRESTRICT. With -DRESTRICT it optimizes the copy to just 4 mov instructions.
The copy code is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89617
--- Comment #2 from John Zwinck ---
Jakub, here is a similar example using structs instead of arrays. It still
generates different code, with RESTRICT giving memcpy instead of mov, but no
RESTRICT still using memmove which is suboptimal.
st
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
Demo code:
#include
class C
{
std::array a{};
int b{};
};
C slow()
{
return {};
}
C fast()
{
C c
++
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
This code compiled in GCC prior to 8.0, but fails to compile in GCC 8.1 and
8.2:
std::make_shared(0)
The error is:
bits/shared_ptr.h: In instantiation of 'std::share
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
C++11 range-based for loops over arrays of size known at compile time result in
bloated, branchy, and unreachable code with -O3
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
In the following code, GCC fails to recognize that the data inside a std::array
has the same alignment guarantees as the array itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80561
--- Comment #3 from John Zwinck ---
I'm aware of the workaround using __builtin_assume_aligned() - you can see I
formulated an equivalent but pure C++ workaround using alignas() in the
aforementioned Stack Overflow post. But 99% of users won't k
D
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
The gcc and g++ man pages say:
-Wno-aggressive-loop-optimizations
Warn if in a loop with constant numb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387
John Zwinck changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
--- Comment #17 from jzwinck at gmail dot com 2010-03-09 18:40 ---
(In reply to comment #16)
> there is evidence (eg, the Dinkumware implementation) that returning an
> iterator doesn't necessarily impact performance.
The GCC implementation does have poor performance. Wh
--- Comment #21 from jzwinck at gmail dot com 2010-03-09 19:55 ---
(In reply to comment #18)
> Because would be non-conforming. In case my previous message was not clear
> enough, in C++1x erase will return *iterator*.
The Boost approach is still an option for GCC: let the sta
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
This is a type of error I've seen multiple times in production code. It
typically arises when forwarding variadic arguments to another function, like
so:
#include
#include
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
The following is nonsensical yet compiles cleanly with "g++ -Wall -Wextra
-Werror -Winit-self" (I tested GCC 4.7.2 and 4.9.0):
#include
#inc
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Whenever a program does (isnan(x) || isnan(y)), GCC 4.7 and 4.9 in the best
case emits code like this on x86-64:
ucomisd %xmm0, %xmm0 ; set parity flag if x is NAN
--- Comment #6 from jzwinck at gmail dot com 2009-11-28 22:59 ---
The same bug has recently been raised in Boost's implementation of unordered
containers: https://svn.boost.org/trac/boost/ticket/3693
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41975
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
Consider this C++ code:
#include
// returns a if less than b or if b is INT32_MIN
int32_t special_min(int32_t a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 80561, which changed state.
Bug 80561 Summary: Missed optimization: std::array data is aligned if array is
aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80561
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80561
John Zwinck changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
This code produces an extra instruction in GCC 11 and 12 (but not 10 or
before):
#include
struct S
verity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
This code seems to have a missed optimization in GCC 10/11/12:
#include
struct S
{
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
This code compiles but does something the programmer almost certainly does not
want:
#include
constexpr std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106926
--- Comment #2 from John Zwinck ---
Jonathan, yes it was a real problem, I wrote such buggy code myself. I was
more complacent with string_view than I might have been with std::string
because everyone knows string_view doesn't have to be null t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106926
--- Comment #4 from John Zwinck ---
Jonathan, thank you for the discussion, I agree with your points and think
adding an attribute for this makes sense.
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107298
--- Comment #3 from John Zwinck ---
Martin, this bug is the only false positive I see in a large corporate
codebase. I think your comment makes it sound like this is a documented thing
where there are tons of false positives and it's not practi
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
I believe this code should compile (and with MSVC it does), but with GCC it
does not:
template
auto & C(Arg && a
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jzwinck at gmail dot com
Target Milestone: ---
Here is some simple code from a real application which converts one struct to a
similar but larger one:
#include
32 matches
Mail list logo
