https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97119
--- Comment #7 from Jan Hubicka ---
Local aliases are created by ipa-visibility pass. Most common case is that
function is declared inline but ELF superposition rules say that the symbol can
be overwritten by a different library. Since GCC know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #11 from Jan Hubicka ---
If there are two ODR types with same ODR name one with integer and other with
pointer types third field, then indeed we should get ODR warning and give up on
handling them as ODR types for type merging.
So d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #8 from Jan Hubicka ---
I will take a look. Mod-ref only reuses the code detecting errneous paths in
ssa-split-paths, so that code will get confused, too. It makes sense for ivopts
to compute difference of two memory allocations, bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114501
Jan Hubicka changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033
--- Comment #18 from Jan Hubicka ---
modref_eaf_analysis::analyze_ssa_name misinterprets EAF flags. If dereferenced
parameter is passed (to map_iterator in the testcase) it can be returned
indirectly which in turn makes it to escape into the ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114207
--- Comment #5 from Jan Hubicka ---
The offset gets lost in ipa-prop.cc
diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
index 7d7cb3835d2..99ebd6229ec 100644
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -1370,9 +1370,9 @@ unadjusted_ptr_and_un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111613
--- Comment #7 from Jan Hubicka ---
I suppose there is not much to do about past noread flags. I do not see how
optimization can invalidate other properties, so I am testing the following:
diff --git a/gcc/ipa-modref.cc b/gcc/ipa-modref.cc
inde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115277
Jan Hubicka changed:
What|Removed |Added
Summary|[13/14/15 regression] ICF |[13 regression] ICF needs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033
Jan Hubicka changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13 Regression]
|Inc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114207
Jan Hubicka changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13 Regression] modref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111613
Jan Hubicka changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13 Regression] Bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Jan Hubicka changed:
What|Removed |Added
Summary|[12/13/14/15 regression]|[12/13 regression] ICU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985
Jan Hubicka changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression]
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106783
--- Comment #6 from Jan Hubicka ---
The problem is that n/=0 is undefined behavior (so we can optimize out call to
function doing divide by zero), while __builtin_trap is observable and we do
not optimize out code paths that may trip to it.
so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116055
--- Comment #4 from Jan Hubicka ---
This does not reproduce for me (with trunk nor gcc14 build with
--target=powerpc64le-linux-gnu)
However the problem is almost surely sanity check in dumping code that flags
does not get worse (which they can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116055
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109914
--- Comment #7 from Jan Hubicka ---
The idea is to help developers to annotate i.e. binary tree search function,
which he clearly knows is always to be finite, but compiler can not prove it.
Intentional infinite loops with no side effects writte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907
--- Comment #26 from Jan Hubicka ---
GGC should not release blocks that are still in use. They are linked by
function's block tree and only if dead they are removed by tree-ssa-live.cc
So the question is why that expr has dangliing pointer to d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907
--- Comment #27 from Jan Hubicka ---
Hmm, I can not seem to reproduce it. Basically we need to work out why that
expression is streamed. If it is part of function body or part of summary. For
summary it may be missing call to unshare_expr_witho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117370
Bug ID: 117370
Summary: std::nothrow variants of operator new are not
optimized away when block is unused
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #28 from Jan Hubicka ---
We could make -fassume-sane-operator-new optimization attribute, but then we
would need to prevent inlining functions with insane operators to functions
with sane operators, or drop the sanity on caller.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #27 from Jan Hubicka ---
This is somewhat weird testcase which makes two allocations which compiler can
track as non-escaping and tests its ability to disambiguate them:
int test3(int *data)
{
int *val = new int;
*va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #29 from Jan Hubicka ---
For completeness note that we can also stick info into FUNCTION_DECLs (i.e. by
an attribute) to avoid flags pollution. Then it could be TU sensitive since
lto-symtab knows that in certain cases it should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116868
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116868
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96945
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #23 from Jan Hubicka ---
with Jakub's builtion_operator_new patch and
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667834.html
on the original testcase we now optimize away allocation and produce
int vat1 (struct vector &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116582
--- Comment #6 from Jan Hubicka ---
Here is a variant of benchmark that needs masking
#include
#define M 1024*1024
T a[M], b[M];
int indices[M];
char c[M];
__attribute__ ((noipa))
void
test ()
{
for (int i = 0; i < 1024* 16; i++)
if (c[i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117440
--- Comment #3 from Jan Hubicka ---
When processing covariant return thunk to g::f() const which is expanded to
gimple we get stuck on:
# .MEM_6 = VDEF <.MEM_4(D)>
g::*.LTHUNK0 (this_5(D));
It fails on sanity check of EAF flags:
/* Check tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117440
--- Comment #4 from Jan Hubicka ---
OK, so the problem is that we analyze function body of g::f which is declared
with pure attribute:
modref analyzing 'virtual g* g::f() const/1' (ipa=0) (pure)
Analyzing flags of ssa name: this_4(D)
Analyzin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432
--- Comment #7 from Jan Hubicka ---
Hash needs to be stable for LTO streaming which affects types. But at least we
ought to compare types when we are comparing bodies in
func_checker::compare_gimple_call. I guess for non-varadic calls this hap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117764
Jan Hubicka changed:
What|Removed |Added
Summary|cddce should handle |[15 Regression] cddce
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590
Jan Hubicka changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment #36 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117639
Jan Hubicka changed:
What|Removed |Added
CC||jwakely at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117710
Bug ID: 117710
Summary: repeated calls to std::function are not inlined
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117672
--- Comment #4 from Jan Hubicka ---
There is constructor of the static variable (_GLOBAL__sub_I_main) which we do
not optimize out since we think it makes useful memory writes since at that
stage we do not know that static var is effectively wri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #32 from Jan Hubicka ---
thanks. I think codegen should be fine, so I will commit the patch so we get it
tested by LNT.
We may get bit better here.
Applying the reverted _M_invariant patch (r14-1452-gfb409a15d9babc) gets me 133
bad_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #30 from Jan Hubicka ---
Created attachment 59610
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59610&action=edit
patch for non-negative checks in std::vector::size and std::vector::capacity
This patch adds non-negativity che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #26 from Jan Hubicka ---
After some more checking we need help from libstdc++ here. Problem is that size
does the pointer subtraction which is always positive, but we do not know it,
and then converts it to size_type.
The following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116518
--- Comment #7 from Jan Hubicka ---
I wonder if DSE can use gimple_call_from_new_or_delete even without
-fassume-sane-operator-new.
In normal use of operator delete we know that the object in question was
destroyed and thus memory is undefined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483
--- Comment #23 from Jan Hubicka ---
one in comment #0 optimizes with me provided that destructors are inline
jh@shroud:/tmp> cat tt.C
#include
#include
#include
//static int calc(const std::array p_ints, const int& p_init)
static int calc(c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117793
Bug ID: 117793
Summary: missed copy propagation across memcpy
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #12 from Jan Hubicka ---
I think with my patch to basic_string we should have at least arrived to
something comparable with clang.
With -O2 it is optimized away,
with -O2 -D_GLIBCXX_USE_CXX11_ABI=0 I get:
int sain ()
{
struct alloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79349
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117764
Bug ID: 117764
Summary: cddce should handle __builtin_unreachable guards
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113197
Jan Hubicka changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117489
--- Comment #7 from Jan Hubicka ---
The problem here (and with the assert Richi nuked in PR 113197) is that the
flags really are:
no_direct_clobber no_indirect_clobber no_direct_escape no_indirect_escape
not_returned_indirectly no_direct_read n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117892
--- Comment #2 from Jan Hubicka ---
This is mine. The loop first checks that basic block is empty (consits only of
debug statements, predicts, clobbers and nops) and then it asserts that there
is only one edge out, which ought to be the case. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117875
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117924
Bug ID: 117924
Summary: unused std::vector are not optimized out fully
at gimple level
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117924
--- Comment #1 from Jan Hubicka ---
looking at dse3 dump we get:
[local count: 1073741824]:
MEM[(struct _Bvector_impl_data *)&data] ={v} {CLOBBER(bob)};
MEM[(struct __as_base &)&data] ={v} {CLOBBER(bob)};
_13 = MEM[(const struct vecto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103827
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Ever confir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117957
Bug ID: 117957
Summary: vectorization pesimises std::vector push/pop test
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318
--- Comment #6 from Jan Hubicka ---
Some profile inconsistencies are expected unless you use atomic counters since
Firefox uses threads.
Do you know why compatible_p returns false? It looks like mixing IPA and
function local profiles together..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117639
--- Comment #3 from Jan Hubicka ---
With -O3 -std=c++20
https://godbolt.org/z/3WKnn8rax
we inline but still get stuck on loop calling log and modifying errno.
Without -std=c++20 we reach --param max-inline-insns-auto. We need --param
max-inlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86276
--- Comment #2 from Jan Hubicka ---
With -O3 we now do quite well.
_Z4goodv:
.LFB1248:
.cfi_startproc
ret
.cfi_endproc
.LFE1248:
.size _Z4goodv, .-_Z4goodv
.p2align 4
.globl _Z3badv
.typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117638
--- Comment #4 from Jan Hubicka ---
Both with assertions or without we offline _M_default_append which would be
better inlined. It is because main is known to be called once.
One difference is that non-assertion clobbers the vectors prior const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80813
--- Comment #6 from Jan Hubicka ---
Patch to optimize operator[] to be again branchless posted
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672286.html
Main problem with auto-generating bt is that it needs change of conditional
from C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80641
--- Comment #18 from Jan Hubicka ---
With -O3 we now get:
int main ()
{
[local count: 114863531]:
return 0;
}
-O2 offlines destructors which prevents us from optimizing away new()
int main ()
{
void * D.27676;
int * c$_M_finish;
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90345
Jan Hubicka changed:
What|Removed |Added
Last reconfirmed|2024-04-10 00:00:00 |2024-12-28
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117984
Bug ID: 117984
Summary: missed IPA constant propagation
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103827
--- Comment #9 from Jan Hubicka ---
Jason, did you intend to close this as invalid? I think we agreed on the
original testcase being valid - we can assume that calls to
extern void foo (const std::string );
can assume the string argument being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590
--- Comment #40 from Jan Hubicka ---
As discussed with Jason, problem with _M_create not seen by middle-end is
actually due to C++ standard. Explicit instantiations prevents implicit ones
for non-inline functions, see discussion in PR39242. With
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #13 from Jan Hubicka ---
As discussed with Jason, problem with _M_create not seen by middle-end is
actually due to C++ standard. Explicit instantiations prevents implicit ones
for non-inline functions, see discussion in PR39242. With
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117875
--- Comment #12 from Jan Hubicka ---
I tried final_value_replacement_loop on simplified testcase where second loop
has known number of iterations:
void foo(int *a, int *b, int n)
{
if (n > 3 && n < 10)
for (int i = 0; i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103827
--- Comment #11 from Jan Hubicka ---
I see, I misread Jonathan's answer. If const is relevant only on definition,
what about this one:
#include
struct foo
{
int a;
void bar() const;
~foo()
{
if (a != 42)
printf ("optimize me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #14 from Jan Hubicka ---
Declaring _S_create and _M_create inline indeed helps a little:
diff --git a/libstdc++-v3/include/bits/basic_string.h
b/libstdc++-v3/include/bits/basic_string.h
index 17b973c8b45..d73a61abe5b 100644
--- a/lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60621
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86701
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97094
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103827
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
--- Comment #15 from Jan Hubicka ---
Original testcase is solved by
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671599.html
We still won't optimize longer strings because _M_create is not inline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #16 from Jan Hubicka ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671599.html
optimizes the string constructors. Having strlen pass catching more cases
would be nice, too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331
Jan Hubicka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117924
Jan Hubicka changed:
What|Removed |Added
Last reconfirmed||2024-12-14
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #35 from Jan Hubicka ---
On
#include
bool test1(const std::vector& in) {
return in == std::vector{42};
}
we produce:
bool test1 (const struct vector & in)
{
bool _12;
int * _13;
int * _14;
long int _24;
unsigned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94960
--- Comment #10 from Jan Hubicka ---
Note that passing function body to middle-end does not only enable inlining,
but other optimizations too. Often ipa-modref is able to summarize side effects
of the function and enables more optimization, since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93921
Jan Hubicka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118130
Bug ID: 118130
Summary: std::vector code quality issues
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90436
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109440
--- Comment #3 from Jan Hubicka ---
I believe that since v is constructed and passed by invisible refernece in the
caller, we would need to know constructors of std::vector and prove that they
do not make &v to escape to global memory, so foo ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Bug 109849 depends on bug 110287, which changed state.
Bug 110287 Summary: _M_check_len is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110378
--- Comment #10 from Jan Hubicka ---
Martin, I think this is fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #14 from Jan Hubicka ---
Jonathan, is there some problem with your patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80813
--- Comment #5 from Jan Hubicka ---
Combine constructs:
(set (reg:CCZ 17 flags)
(compare:CCZ (zero_extract:DI (mem:DI (plus:DI (mult:DI (reg:DI 111 [ _8 ])
(const_int 8 [0x8]))
(reg/f:DI 112 [
v_2(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80813
--- Comment #3 from Jan Hubicka ---
OK, so the horrid codegen is because bvector's [] operator is imlemented using
iterator:
return begin()[__n];
iterator's [] operator is implemented using:
_GLIBCXX20_CONSTEXPR
void
_M_incr(ptrdif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80813
--- Comment #4 from Jan Hubicka ---
Bit_reference constructor takes mask and not bit position.
_GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
reference
operator[](size_type __n)
{
__glibcxx_requires_subscript(__n);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80813
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|x86:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118527
--- Comment #3 from Jan Hubicka ---
The reason why I did not implement profile fixups to cfgcleanup is that you can
not really fix the profile without knowing why it became inconsistent.
Consider situation where we have function
foo (int a)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119368
--- Comment #5 from Jan Hubicka ---
Thinking of it more, I think enabling memory alternatives in
(define_insn "sse4_1_v4hiv4si2"
[(set (match_operand:V4SI 0 "register_operand" "=Yr,*x,v")
(any_extend:V4SI
(vec_select:V4HI
(m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #12 from Jan Hubicka ---
Indeed at IPA level we track if address of a symbol is taken, but we do not
keep any extra info about how it may be used. It would be useful to track
1) if address is used only to read (to figure out readon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119312
--- Comment #13 from Jan Hubicka ---
And forgot to write. In case of strcmp I think we can use fnspec info we
already have at the time constructing callgraph to represent it as a read
rather than taking address. This would make things go bit sm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119368
Bug ID: 119368
Summary: immintrin code running slower with gcc than clang
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119298
--- Comment #14 from Jan Hubicka ---
> > I am OK with using addss cost of 3 for trunk&release branches and make this
> > more precise next stage1.
>
> That's what we use now? But I still don't understand why exactly
> 538.imagick_r regresses
701 - 800 of 861 matches
Mail list logo
