https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047
--- Comment #16 from Alexander Monakov ---
I'd like to backport this to gcc-9 branch and then close this bug (Richi
already indicated that further backports are not desirable). Thoughts?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92250
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92151
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92030
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91965
--- Comment #3 from Alexander Monakov ---
(In reply to Marc Glisse from comment #2)
> What exact transformation do you want? Canonicalize the constant C to
> something like C % (1 << (bitsize - N))?
I'm thinking (C << N) >>> N where '>>>' is sig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91965
--- Comment #1 from Alexander Monakov ---
On a related thought, I wonder if we can canonicalize (x << CST) to (x * CST')
where CST' is 1<
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
In the good old days when gcc was written in C, bootstrap stage2/3 enabled
-Wmissing-prototypes and so it caught attempted definitions of functions that
should be static, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047
Alexander Monakov changed:
What|Removed |Added
Summary|[7/8/9/10 Regression] |[7/8/9 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047
--- Comment #14 from Alexander Monakov ---
Author: amonakov
Date: Wed Oct 2 15:37:12 2019
New Revision: 276466
URL: https://gcc.gnu.org/viewcvs?rev=276466&root=gcc&view=rev
Log:
ifcvt: improve cost estimation (PR 87047)
PR rtl-optimiza
normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Noticed this issue when preparing a testcase for PR 87047. We do not simplify
(1048575ull - x) << 44 on GIMPLE:
u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91899
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047
--- Comment #12 from Alexander Monakov ---
Created attachment 46911
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46911&action=edit
patch for scaled cost calculation
Attaching a patch that implements the tactic outlined in comment #10.
||amonakov at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #12 from Alexander Monakov ---
Nothing, closing the bug.
CC||amonakov at gcc dot gnu.org
Summary|builtin fma is not |[9/10 Regression] builtin
|optimized or vectorized as |fma is not optimized or
|*+ |vectorized as *+
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83661
--- Comment #5 from Alexander Monakov ---
sincos performs range reduction for the argument just once, which is fairly
important. A well-optimized sincos also shares some computations for the
sin/cos parts, as done in
https://github.com/ARM-softwa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91539
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91539
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78884
Alexander Monakov changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91043
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90811
--- Comment #7 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 46479 [details]
> gcc10-pr90811-overalign.patch
>
> Perhaps during estimate_stack_frame_size we should make sure not to adjust
> DECL_ALIG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90817
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90811
--- Comment #3 from Alexander Monakov ---
Thanks. The change in the attached patch looks good to me, but I must admit I
don't see how the testcase triggers the problem. Basically, it's not obvious
how the controlling if condition becomes true:
>
||amonakov at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Alexander Monakov ---
Documentation for -Wuninitialized points out that you need -Winit-self to catch
such patterns (and you do get a warning in that case). Seems to work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90523
--- Comment #2 from Alexander Monakov ---
See also PR 87076, which has a reduced testcase and some root-cause analysis
(likely a duplicate).
||amonakov at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #8 from Alexander Monakov ---
Should be resolved by Vlad's patch - thanks for the report!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90394
--- Comment #7 from Alexander Monakov ---
Author: amonakov
Date: Thu May 16 12:36:33 2019
New Revision: 271287
URL: https://gcc.gnu.org/viewcvs?rev=271287&root=gcc&view=rev
Log:
tree-ssa-uninit: avoid ICE with BIT_AND_EXPR (PR 90394)
2019-05-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90061
Alexander Monakov changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
ostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
GCC 9 introduced a new warning (-Waddress-of-packed-member) for situations
where the code tries to assign ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
Alexander Monakov changed:
What|Removed |Added
Summary|[9/10 Regression] ICE in|[9 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
--- Comment #10 from Alexander Monakov ---
Author: amonakov
Date: Thu May 9 18:13:28 2019
New Revision: 271039
URL: https://gcc.gnu.org/viewcvs?rev=271039&root=gcc&view=rev
Log:
sel-sched: allow negative insn priority (PR 88879)
PR rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90292
--- Comment #3 from Alexander Monakov ---
When changing iterators to 'int', you also need to change n to int as well,
otherwise in 'n*(i) + (j)', i and j are promoted to unsigned anyway.
||amonakov at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Alexander Monakov ---
The compiler cannot perform this hoisting, because the computation 'n*(i) +
(j)' happens in 'unsigned int' type, where wrapping o
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Controlling expression in _Generic undergoes lvalue conversion, so it will have
const/volatile qualifiers stripped. Therefore, a qualified
-*-*
Status|UNCONFIRMED |NEW
Known to work||7.3.0
Keywords||wrong-code
Last reconfirmed||2019-04-20
CC||amonakov at gcc dot gnu.org
Ever
||2019-04-16
CC||amonakov at gcc dot gnu.org
Resolution|INVALID |---
Ever confirmed|0 |1
--- Comment #6 from Alexander Monakov ---
Reopening and confirming, GCC's code looks
||2019-04-12
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Alexander Monakov ---
Please provide an example, as a simple smoke-test is compiled correctly:
long f(struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
--- Comment #4 from Alexander Monakov ---
Well, often sel-sched just does not discriminate hardregs and pseudos when
checking if renaming/substitution may be applied. Sure, as a matter of
efficiency we should probably disallow substitution throug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
--- Comment #2 from Alexander Monakov ---
We have a pseudo:SI<-hardreg:SI assignment followed by
pseudo:DF<-float(pseudo:SI) conversion, and we substitute the latter through
the former, creating a pseudo:DF<-float(hardreg:SI) insn that fails in r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84206
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85876
--- Comment #3 from Alexander Monakov ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84206
--- Comment #2 from Alexander Monakov ---
Author: amonakov
Date: Tue Apr 2 15:45:57 2019
New Revision: 270096
URL: https://gcc.gnu.org/viewcvs?rev=270096&root=gcc&view=rev
Log:
sel-sched: skip outer loop in get_all_loop_exits (PR 84206)
2019-0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85876
--- Comment #2 from Alexander Monakov ---
Author: amonakov
Date: Tue Apr 2 15:39:22 2019
New Revision: 270095
URL: https://gcc.gnu.org/viewcvs?rev=270095&root=gcc&view=rev
Log:
sel-sched: fixup reset of first_insn (PR 85876)
2019-04-02 Andrey
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89916
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86928
Bug 86928 depends on bug 89916, which changed state.
Bug 89916 Summary: New test case gcc.dg/pr86928.c fails on 64 bit targets
(r270061)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89916
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89916
--- Comment #2 from Alexander Monakov ---
Author: amonakov
Date: Tue Apr 2 11:04:22 2019
New Revision: 270087
URL: https://gcc.gnu.org/viewcvs?rev=270087&root=gcc&view=rev
Log:
testsuite: do not try to add -m32 (PR 89916)
PR testsuite/
||2019-04-02
Blocks||86928
Assignee|unassigned at gcc dot gnu.org |amonakov at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
Thanks. I assume the test should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412
Alexander Monakov changed:
What|Removed |Added
Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412
--- Comment #14 from Alexander Monakov ---
Author: amonakov
Date: Mon Apr 1 18:05:08 2019
New Revision: 270065
URL: https://gcc.gnu.org/viewcvs?rev=270065&root=gcc&view=rev
Log:
sel-sched: correct reset of reset_sched_cycles_p (PR 85412)
2019-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099
Bug 85099 depends on bug 86928, which changed state.
Bug 86928 Summary: ICE in compute_live, at sel-sched.c:3097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86928
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86928
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86928
--- Comment #4 from Alexander Monakov ---
Author: amonakov
Date: Mon Apr 1 16:32:24 2019
New Revision: 270061
URL: https://gcc.gnu.org/viewcvs?rev=270061&root=gcc&view=rev
Log:
sel-sched: update liveness in redirect_edge_and_branch hooks (PR 86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87273
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87273
--- Comment #6 from Alexander Monakov ---
Author: amonakov
Date: Mon Apr 1 15:20:13 2019
New Revision: 270059
URL: https://gcc.gnu.org/viewcvs?rev=270059&root=gcc&view=rev
Log:
sel-sched: remove assert in merge_fences (PR 87273)
2019-04-01 An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43798
--- Comment #17 from Alexander Monakov ---
> Can the bogus situation be reproduced with C _Alignas?
C11 does not allow _Alignas on typedefs, so don't see how; likewise for alignas
in C++11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43798
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #6 from Alexander Monakov ---
... and even considering that the standard never actually says that "compatible
type" relation is transitive, and so two enums technically need not be
compatible with each other, the following should foll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
--- Comment #5 from Alexander Monakov ---
C11 6.7.2.2 p4 says,
Each enumerated type shall be compatible with char, a signed integer type, or
an unsigned integer type [...]
and 6.5 p7 says,
An object shall have its stored value accessed onl
-07-29 00:00:00 |2019-3-14
CC||amonakov at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #2 from Alexander Monakov ---
Optimized to 'return 1' already in fre1.
At the same time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85899
--- Comment #5 from Alexander Monakov ---
Author: amonakov
Date: Fri Mar 1 16:18:04 2019
New Revision: 269319
URL: https://gcc.gnu.org/viewcvs?rev=269319&root=gcc&view=rev
Log:
haifa-sched: handle fallthru edge to EXIT block (PR 85899)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85899
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85899
--- Comment #4 from Alexander Monakov ---
It appears that fallthru edges to the exit block are unusual in that they don't
obey the invariant e->dest == e->src->next_bb (i.e. next_bb may be anything).
If so, the assert in haifa-sched needs to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86096
--- Comment #5 from Alexander Monakov ---
Author: amonakov
Date: Mon Feb 25 15:14:39 2019
New Revision: 269189
URL: https://gcc.gnu.org/viewcvs?rev=269189&root=gcc&view=rev
Log:
df-scan: fix use of mw_order in df_mw_compare (PR 86096)
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89436
--- Comment #2 from Alexander Monakov ---
This was previously reported as PR 86096. Let me copy-paste my response from
there:
df_mw_compare has:
if (mw1->mw_reg != mw2->mw_reg)
return mw1->mw_order - mw2->mw_order;
Note mw_reg in the '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89334
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
||amonakov at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #5 from Alexander Monakov ---
As far as I can tell this report was not correctly triaged 10 years ago, as
that's exactly what -mtune= is for: optimize for a given CPU wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853
Alexander Monakov changed:
What|Removed |Added
CC||vermaelen.wouter at gmail dot
com
-
||amonakov at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #3 from Alexander Monakov ---
This was implemented for gcc-9 via PR 82853; it seems this bug was overlooked
in the renewed discussion.
*** This bug has been marked as a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #25 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #22)
> A function call must be assumed to clobber any call used registers of course.
> But calls already do have vops (well, const/pure don't, and I don't think we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89256
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #21 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #18)
> We could cache a bool in struct function whether the function has any local
> hard register vars and just propagate that info during inlining etc. and
> jus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #17 from Alexander Monakov ---
Well, the asm with the xor was just to make the testcase more-obviously-broken,
it's still broken when %eax is clobbered in a more subtle way, like via a
libcall for integer division like in earlier exam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670
Bug 88670 depends on bug 88698, which changed state.
Bug 88698 Summary: Relax generic vector conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
--- Comment #11 from Alexander Monakov ---
Author: amonakov
Date: Mon Feb 4 15:00:41 2019
New Revision: 268522
URL: https://gcc.gnu.org/viewcvs?rev=268522&root=gcc&view=rev
Log:
doc: showcase a "union of vectors" pattern (PR 88698)
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89106
--- Comment #4 from Alexander Monakov ---
My concern is that the cast does not "create a compound literal": what it
creates is an object, more specifically, an unnamed temporary object in
automatic storage with unspecified lifetime [1]. A compou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89106
--- Comment #2 from Alexander Monakov ---
I don't think it's appropriate to say "creates a compound literal". My
preference would be:
Unlike a compound literal, a cast to a union yields an rvalue like standard
casts do.
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
The patch for PR 71560 changed the wording in "Cast to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89060
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88955
--- Comment #3 from Alexander Monakov ---
Note, without the attribute gcc passes the union on an SSE register, so it
doesn't look like TImode on the union matters (otherwise it would be passed via
rdx:rax register pair):
typedef unsigned long u6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88955
--- Comment #1 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #0)
> Adding a dummy __int128 field makes GCC accept the code (but such workaround
> won't work for wider vectors, or on 32-bit).
But this causes the union to
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
GCC (and Clang) rejects an attempt to create a transparent union corresponding
to an SSE register:
typedef unsigned long u64x2 __attribute__ ((vector_size (16)));
typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
Alexander Monakov changed:
What|Removed |Added
CC||abel at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88793
--- Comment #4 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #3)
> I think it's fair to raise the question if gcc should not use scasb/cmpsb by
> default (I thought there was a bug for that but apparently there isn't?).
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
Performance difference between libc strlen and x86 rep-scasb has grown too
large and seems unlikely to improve anytime soon.
On most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
--- Comment #8 from Alexander Monakov ---
Yeah, on GCC users' side I think there's a demand for both: treating UB as
unreachable (e.g. on tiny systems with heavy program size constraints) and
transforming UB to a trap briefly annotated with sourc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88793
--- Comment #3 from Alexander Monakov ---
(In reply to Florian Weimer from comment #2)
> The startup overhead isn't the problem. The asymptotic performance is
> really bad, too. (I hope I didn't botch my test, though. It's vaguely
> based on w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88793
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979
--- Comment #10 from Alexander Monakov ---
As discussed with Andrew offline, the real problem is creating a path where
stack pointer is decremented twice - that is really not supposed to happen (so
the issue could appear even in absence of REG_AR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88600
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88593
--- Comment #4 from Alexander Monakov ---
It seems to avoid this sort of gotchas cleanup_cfg should
gcc_checking_assert (!dom_info_available_p (CDI_DOMINATORS));
gcc_checking_assert (!dom_info_available_p (CDI_POST_DOMINATORS));
but maybe t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88593
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481
--- Comment #9 from Alexander Monakov ---
Thanks. I still don't see what's wrong. Are you testing only by single-stepping
in gdb, or does your program overall behave differently with/without
if-conversion?
In other words, do you see if-conversio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88425
--- Comment #4 from Alexander Monakov ---
Thanks! Should this be closed as fixed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481
--- Comment #6 from Alexander Monakov ---
And just to be sure, can you confirm that -fno-if-conversion changes program
behavior (the testcase is not executable so I cannot check), and the issue is
not about debug info quality (i.e. that single-st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88481
--- Comment #5 from Alexander Monakov ---
The code shown in the opening comment looks fine to me, so please isolate the
issue further using debug counters.
Add -fdbg-cnt=if_conversion:99,if_after_combine:99 to -O1. This should lead to
broken cod
||2018-12-13
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
Without -O, optimization passes are not enabled, even if individual -f options
are passed on the
501 - 600 of 1161 matches
Mail list logo
