: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mattreecebentley at gmail dot com
Target Milestone: ---
Created attachment 49102
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49102&action=edit
Compiler outpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96750
--- Comment #4 from Matt Bentley ---
(In reply to Marc Glisse from comment #2)
> (In reply to Martin Liška from comment #1)
> > after:
> > 1794240.0
> >
> > before:
> > 1802710.0
>
> That's less than 1% of difference (with "after" better than "
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mattreecebentley at gmail dot com
Target Milestone: ---
Test setup:
Xubuntu 18, Core2Duo E8500 CPU, GCC 7.3
Results in release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #2 from Matt Bentley ---
(In reply to Andrew Pinski from comment #1)
> Does -O3 bring the performance back? -O3 enables loop distrubtion which
> should be able to detect these loops.
Just tested - yes.
However this is a fairly trivi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #3 from Matt Bentley ---
I thought I should note that there is also a missing optimization opportunity
in the code. Clang optimizes the code I've listed to remove the benchmark loops
entirely since it detects that the arrays aren't ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #5 from Matt Bentley ---
What would be even more useful is a warning: for unused data.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #6 from Matt Bentley ---
Suggested patch for libstdc++, std_algobase.h, line 688:
template
inline typename
__gnu_cxx::__enable_if<__is_scalar<_Tp>::__value, void>::__type
__fill_a(_ForwardIterator __first, _ForwardIterat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #8 from Matt Bentley ---
> This is incorrect for floating point types and non scalars. And it
> introduces an extra check at runtime if value is not known to compile time.
This is the overload for scalar types, read the function des
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #10 from Matt Bentley ---
(In reply to Marc Glisse from comment #9)
> (In reply to Andrew Pinski from comment #7)
> We could also use __builtin_constant_p, if the function is inlined often
> enough (don't know if it is).
Right - so t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #13 from Matt Bentley ---
(In reply to Jonathan Wakely from comment #12)
> Also you're doing a reinterpret_cast from an arbitrary iterator type, which
> is not necessarily a pointer, or even a random access iterator.
>
> Since you do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #14 from Matt Bentley ---
(In reply to Matt Bentley from comment #13)
> (In reply to Jonathan Wakely from comment #12)
> > Also you're doing a reinterpret_cast from an arbitrary iterator type, which
> > is not necessarily a pointer, o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #16 from Matt Bentley ---
(In reply to Jonathan Wakely from comment #15)
> Look at how this exact problem is already solved elsewhere in the same file.
> All the algorithms that dispatch to a __builtin_memxxx function use similar
> t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #19 from Matt Bentley ---
(In reply to Jonathan Wakely from comment #18)
> (In reply to Matt Bentley from comment #13)
> > Well it's more that you're doing- at any rate, the issue you've noted is
> > easily bypassed by changing the "r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #20 from Matt Bentley ---
(In reply to Matt Bentley from comment #19)
> (In reply to Jonathan Wakely from comment #18)
> > (In reply to Matt Bentley from comment #13)
> > > Well it's more that you're doing- at any rate, the issue you'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #22 from Matt Bentley ---
(In reply to Jonathan Wakely from comment #21)
> Surely static_cast is good enough, and doesn't rule out making the function
> constexpr?
It may well be, how does reinterpret_cast cause constexpr to fail, gi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #23 from Matt Bentley ---
> Actually, don't quote me on that - I may be thinking of the
> 'reinterpret_cast<_Tp>(0)' - one of the two.
Just to confirm, "reinterpret_cast(__first)" not required in this
context, either "reinterpret_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #24 from Matt Bentley ---
Ugh. I made a mistake. Clang only throws the warning when comparing NULL with 0
without reinterpret_cast/static_cast, not when comparing pointers in general.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #26 from Matt Bentley ---
(In reply to Jonathan Wakely from comment #25)
> What warning? Why can't you just pass 0 to __builtin_memset? It's a null
> pointer constant. I don't see any warning from clang when using -Weverything.
As c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96750
--- Comment #5 from Matt Bentley ---
If anyone out there is interested in working on this,
I found the smallest change possible to create the same performance as GCC8-
it is literally eliminating one branch possibility in one function
(move-ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96750
--- Comment #6 from Matt Bentley ---
Created attachment 49278
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49278&action=edit
Demonstration of code which doesn't trigger the performance anomaly.
plf_colony_fast.h does not trigger the prob
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mattreecebentley at gmail dot com
Target Milestone: ---
For example, as part of a container class:
void remove_memory_bloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100956
--- Comment #2 from Matt Bentley ---
Thank you - I'm aware GCC might optimize it out (and failed to test with
GCC10), at least in O2 mode, but other compilers might not, hence the code.
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mattreecebentley at gmail dot com
Target Milestone: ---
Created attachment 59292
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59292&action=edit
ii file
Overview: Found a sequence of code using bitset wher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008
--- Comment #11 from Matt Bentley ---
Created attachment 59294
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59294&action=edit
-v build output for -o2 only in second "if" variant
As requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008
--- Comment #9 from Matt Bentley ---
(In reply to Jonathan Wakely from comment #7)
> I'm certain it won't be, because (apart from vector) they access
> memory locations that are at least one byte, not repeating very similar
> bitwise ops for ev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008
--- Comment #10 from Matt Bentley ---
Created attachment 59293
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59293&action=edit
-v build output for -o2;-march=native for second "if" variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116931
--- Comment #5 from Matt Bentley ---
Nevermind, I realised my mistake.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008
--- Comment #4 from Matt Bentley ---
Yeah, I know, I mentioned that in the report.
It's not a bad benchmark, it's benchmarking access of individual consecutive
bits, not summing. The counting is merely for preventing the compiler from
optimizin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008
--- Comment #5 from Matt Bentley ---
(In reply to Andrew Pinski from comment #1)
> Can you provide the output of invoking g++ with -march=native and when
> compiling?
The .ii files were identical, so did you you mean .o files?
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mattreecebentley at gmail dot com
Target Milestone: ---
Created attachment 59263
--> https://gcc.gnu.org/bugzilla/attachment.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116931
--- Comment #2 from Matt Bentley ---
Enlighten me here, how is this invalid C++ code?
Because a typedef should mean that int_pointer is int *, so it should work,
right?
If it's invalid merely because it's typedef'd instead of verbatim, it's a
l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116931
--- Comment #4 from Matt Bentley ---
Okay, so that's a language defect, because const int * const isn't invalid, so
neither should a typedef of the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008
--- Comment #13 from Matt Bentley ---
Bool C-arrays also display the same problem, but only if a warm-up loop is
present before the main loop (to 'warm up' the cache). I discovered this by
accident the other day. char arrays and int arrays did n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008
--- Comment #14 from Matt Bentley ---
Created attachment 59355
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59355&action=edit
.ii file for vector code causing same issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117008
--- Comment #15 from Matt Bentley ---
Created attachment 59356
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59356&action=edit
.ii file for bool[array] causing same issue
35 matches
Mail list logo
