https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116027
--- Comment #2 from user202729 ---
Maybe this is a less artificial example.
__attribute__((pure)) long f(__int128 a, long b);
__int128 x;
long g(){
__int128 y=x;
long z=f(0, 0);
x=1;
return f(y, z);
}
long h(){
long z=f(0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116027
Bug ID: 116027
Summary: Redundant backup and restore of register with
-flive-range-shrinkage
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116001
Bug ID: 116001
Summary: Missing optimization: Unoptimized indirect virtual
call
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115998
user202729 changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #3 from user202729 ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115998
Bug ID: 115998
Summary: Redundant stack pointer manipulation
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #20 from user202729 ---
(In reply to Jonathan Wakely from comment #19)
> That's easily solved by accessing the new object through the pointer
> returned by the new expression:
>
> std::vector v(1);
> Base* p = v.data();
> p->~Base()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115981
Bug ID: 115981
Summary: Redundant vmovaps to itself after vmovups
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #18 from user202729 ---
(In reply to Jonathan Wakely from comment #17)
> I don't think that optimization would be valid. Users could do disgusting
> things like this (as long as sizeof(Base) == sizeof(Derived)):
>
> std::vector v(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #16 from user202729 ---
(In reply to Jonathan Wakely from comment #14)
> So something like this, and then use it in containers instead of
> _Alloc_traits::destroy
>
> template
> _GLIBCXX20_CONSTEXPR
> void
> _Destroy_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115413
--- Comment #4 from user202729 ---
I wrote a patch in
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655504.html which tries to
address this issue.
Any review (or other suggestions on how to better implement the underlying
feature https://
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115576
--- Comment #5 from user202729 ---
I think this can be resolved by implementing some code in combine.cc to
replace:
(set:TI (reg:TI 101) (zero_extend:TI (...:DI ...)))
(set:DI (reg:DI ...) (subreg:DI (reg:TI 101) 8))
with
(set:TI (reg:TI 101)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115576
user202729 changed:
What|Removed |Added
CC||user202729 at protonmail dot
com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115413
--- Comment #3 from user202729 ---
(In reply to Jason Merrill from comment #2)
> If you're going to write code like this, why not
>
> if(typeid(*a)==typeid(A)) a->A::f();
>
> to force the non-virtual call?
The practical reason is that that wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #16 from user202729 ---
Hi,
I tried to implement patches that fix the two issues mentioned. Comments would
be appreciated.
1. The operator new flag with many of the mentioned issues fixed:
https://gcc.gnu.org/pipermail/gcc-patches/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105239
user202729 changed:
What|Removed |Added
CC||user202729 at protonmail dot
com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104081
user202729 changed:
What|Removed |Added
CC||user202729 at protonmail dot
com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115470
Bug ID: 115470
Summary: bad_typeid is not thrown for typeid(*null pointer) of
final class
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115468
Bug ID: 115468
Summary: Convenience functions defined in gdbinit.in does not
handle spaces in expression correctly
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115413
--- Comment #1 from user202729 ---
In practice, one way to implement this is to rewrite all instances of
typeid(a) == typeid(b)
into roughly the following (assuming the virtual pointer table has exactly 1
pointer to function)
typeid(a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410
--- Comment #9 from user202729 ---
Alright, I open https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115413 instead
(discussing one case where gcc already calls a different function from what it
should)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115413
Bug ID: 115413
Summary: Missing optimization: devirtualize the call in
"if(typeid(*a)==typeid(A)) a->f();" structure
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410
--- Comment #7 from user202729 ---
(In reply to Andrew Pinski from comment #6)
> They can be different due to the way shared libraries work.
Ah, too bad.
Is it safe to at least assume that the function pointers inside the virtual
pointer table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410
--- Comment #5 from user202729 ---
(In reply to Andrew Pinski from comment #3)
> Except it is not valid.
>
> See https://gcc.gnu.org/pipermail/libstdc++/2004-February/021443.html which
> changed this to be always a string comparison.
Thanks f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410
--- Comment #2 from user202729 ---
(In reply to Andrew Pinski from comment #1)
> I am not so sure. Many times the comparison becomes a string comparison and
> not comparing the vtable.
That's my point. Pointer comparison is faster than string c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115410
Bug ID: 115410
Summary: Missing optimization: typeid(*a)==typeid(*b) could be
optimized to a->_vptr==b->_vptr
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115381
Bug ID: 115381
Summary: Missed deoptimization opportunity when comparing two
different linker symbols
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #14 from user202729 ---
Regarding alias analysis. The current implementaion is such that:
compiler | flag | can alias?| can modify global?|
gcc | sane | no| no| << NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #8 from user202729 ---
(In reply to Jonathan Wakely from comment #7)
> Thanks for the patch, but patch review happens on the mailing list, not in
> bugzilla. Please repost to gcc-patches as documented in the submission
> guidelines,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
user202729 changed:
What|Removed |Added
CC||user202729 at protonmail dot
com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
user202729 changed:
What|Removed |Added
CC||user202729 at protonmail dot
com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035
user202729 changed:
What|Removed |Added
CC||user202729 at protonmail dot
com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115210
Bug ID: 115210
Summary: Missed optimization opportunity in redundant copies
for large structure
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
32 matches
Mail list logo
