https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70992
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81476
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81476
--- Comment #8 from Alexander Monakov ---
Yeah, the
target.insert(target.cbegin(), ranges::begin(concatenated),
ranges::end(concatenated));
appears to cause a bad case of Schlemiel-The-Painter, for each inserted char
the tail of target is mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68988
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81400
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81052
--- Comment #7 from Alexander Monakov ---
As an aside, shouldn't we issue a diagnostic here? OpenMP spec says branching
in/out of simd regions is not allowed, and I think we already diagnose invalid
branching for some other constructs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81691
--- Comment #2 from Alexander Monakov ---
Jakub said target2.f90 exposes a frontend bug (or OpenMP lowering bug, not
sure):
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02397.html
This is not a target-specific issue, it should fail in a similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81694
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81694
--- Comment #5 from Alexander Monakov ---
GCC exploits undefined behavior throughout the compilation pipeline, if you
want a methodical workaround, you need compilation mode that makes overflow
defined (-fwrapv), and likewise for other sources of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81687
--- Comment #3 from Alexander Monakov ---
In this particular case we are not exactly copying the region, we are only
moving (outlining) it to a separate function. We could properly remap the
label.
But in general GCC is indeed confused about ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
--- Comment #8 from Alexander Monakov ---
Honza: ping :). ipa-pure-const might be a better place to mark functions with
compiler memory barriers, as it already computes and propagates "nonfreeing"
property (thus computing "nonbarrier" in ipa-pur
||amonakov at gcc dot gnu.org
--- Comment #1 from Alexander Monakov ---
It's not quite right to say this is minimized from for-5.c, as original for-5.c
does not fail in this way. The difference that makes this one ICE is presence
of #pragma omp declare target [end] a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763
--- Comment #9 from Alexander Monakov ---
A (potentially simpler) alternative is to use sequential builds (make without
-j) and bisect by index of compiled source file, i.e. have a wrapper script
around gcc that uses some global counter to pass -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81778
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81805
--- Comment #1 from Alexander Monakov ---
Can't reproduce this on my end. Are you going to proceed with analyzing the
failure?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81805
--- Comment #3 from Alexander Monakov ---
The new testcase fails on any target and not related to offloading. Simplified
further:
#define N 32ULL
int a[N];
const unsigned long long c = 0x7fffULL;
f2_tpf_static32 (void)
{
unsigned
||amonakov at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Alexander Monakov ---
It seems you've submitted two identical bugs - closing as duplicate of the
earlier one.
*** This bug has been marked as a duplicate of bug 81816 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81816
--- Comment #1 from Alexander Monakov ---
*** Bug 81817 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
--- Comment #9 from Alexander Monakov ---
I don't understand how LIM may deduce that store sinking is safe without
considering may-alias relations. If it is UB to write the same object from
different declared-independent iterations, then I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
--- Comment #11 from Alexander Monakov ---
(In reply to Richard Biener from comment #10)
> Now - for refs that have an invariant address in such loop the interleaving
> effectively means that they are independent even in the same iteration.
Not
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Under -fopenmp-simd, OpenMP pragma 'ordered' is not added to IR, but it should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877
--- Comment #13 from Alexander Monakov ---
> More rigorously defining the semantic of loop->safelen (the
> middle-end term) is necessary nevertheless. I believe omp ordered
> doesn't have any middle-end representation?
Except on nvptx, 'omp ord
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
When -fno-signed-zeros is enabled, rint/nearbyint do not need to produce
negative zeros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81916
--- Comment #2 from Alexander Monakov ---
I've opened this PR for the -fno-signed-zeros aspect specifically, which the
i386 backend doesn't exploit at all: it expands to
copysign(abs(x)+1.0p52-1.0p52, x).
I think handling these expansions in a g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80454
--- Comment #3 from Alexander Monakov ---
The bug is that universal zero initializers are warned about when they are
inside of some other initializer, even though we correctly stopped doing that
when they appear on their own. In the following exa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80640
--- Comment #8 from Alexander Monakov ---
Author: amonakov
Date: Mon Aug 28 10:58:45 2017
New Revision: 251377
URL: https://gcc.gnu.org/viewcvs?rev=251377&root=gcc&view=rev
Log:
optabs: ensure mem_thread_fence is a compiler barrier
PR t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81316
Bug 81316 depends on bug 80640, which changed state.
Bug 80640 Summary: Missing memory side effect with __atomic_thread_fence (2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80640
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80640
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67458
--- Comment #2 from Alexander Monakov ---
Author: amonakov
Date: Mon Sep 4 10:16:37 2017
New Revision: 251643
URL: https://gcc.gnu.org/viewcvs?rev=251643&root=gcc&view=rev
Log:
optabs: ensure atomic_load/stores have compiler barriers
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81316
--- Comment #2 from Alexander Monakov ---
Author: amonakov
Date: Mon Sep 4 10:16:37 2017
New Revision: 251643
URL: https://gcc.gnu.org/viewcvs?rev=251643&root=gcc&view=rev
Log:
optabs: ensure atomic_load/stores have compiler barriers
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57448
--- Comment #3 from Alexander Monakov ---
Author: amonakov
Date: Mon Sep 4 10:16:37 2017
New Revision: 251643
URL: https://gcc.gnu.org/viewcvs?rev=251643&root=gcc&view=rev
Log:
optabs: ensure atomic_load/stores have compiler barriers
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81316
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67458
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67458
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
||amonakov at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #4 from Alexander Monakov ---
This should now be fixed on the trunk, although in a very different manner: RTL
expansion of atomic loads/stores now places explicit compiler memory
, openmp
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
When linker plugin is not used (either due to old Binutils, or
-fno-use-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68988
--- Comment #5 from Alexander Monakov ---
Author: amonakov
Date: Tue Sep 19 10:16:20 2017
New Revision: 252972
URL: https://gcc.gnu.org/viewcvs?rev=252972&root=gcc&view=rev
Log:
lra: make reload_pseudo_compare_func a proper comparator
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57878
--- Comment #4 from Alexander Monakov ---
Author: amonakov
Date: Tue Sep 19 10:16:20 2017
New Revision: 252972
URL: https://gcc.gnu.org/viewcvs?rev=252972&root=gcc&view=rev
Log:
lra: make reload_pseudo_compare_func a proper comparator
P
||amonakov at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #5 from Alexander Monakov ---
This bug was originally fixed in July 2013 by r201036:
https://gcc.gnu.org/ml/gcc-patches/2013-07/msg00732.html , but that patch
changed the comparator
||2017-09-20
CC||amonakov at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Alexander Monakov ---
(Marc, for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82242
Alexander Monakov changed:
What|Removed |Added
Summary|x86_64 bad optimization |IRA spills allocno in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71702
--- Comment #8 from Alexander Monakov ---
Author: amonakov
Date: Thu Sep 21 21:56:16 2017
New Revision: 253081
URL: https://gcc.gnu.org/viewcvs?rev=253081&root=gcc&view=rev
Log:
PR tree-optimization/71702
Backport r230667
2015-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71702
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81481
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Translation units that include "umbrella" x86 intrinsic files, i.e. x86intrin.h
or i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82339
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71250
--- Comment #2 from Alexander Monakov ---
Thanks. Basically the documentation can be enhanced to mention that GCC
shouldn't (and wouldn't) warn for universal zero initializer, which is '{0}' in
C and just '{}' in C++. After a day or so I can subm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71250
--- Comment #4 from Alexander Monakov ---
Note that that's a different warning: -Wmissing-braces, not
-Wmissing-field-initializers. I believe it would be nice to fix, but handling
of universal zero initializers in -Wmissing-braces should be a se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72815
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72815
--- Comment #8 from Alexander Monakov ---
Perhaps it's a good idea to adjust libmpx/configure.tgt to build libmpx only
for Glibc by default? I'm not sure if there's a particular reason that current
code accepts any suffix in the triple.
diff --g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71250
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71250
--- Comment #6 from Alexander Monakov ---
Author: amonakov
Date: Thu Apr 20 10:23:38 2017
New Revision: 247018
URL: https://gcc.gnu.org/viewcvs?rev=247018&root=gcc&view=rev
Log:
doc: mention handling of {0} in -Wmissing-field-initializers (PR 71
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80378
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80378
--- Comment #7 from Alexander Monakov ---
This sounds like a separate problem that is solvable via __builtin_constant_p?
For example:
void link_error(void) __attribute__((error("size check failed")));
if (__builtin_constant_p(size) &&
||2017-05-05
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
The attachment is missing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80640
Alexander Monakov changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80640
--- Comment #5 from Alexander Monakov ---
I think the bug is that on x86 __atomic_thread_fence(x) is expanded into
nothing for x!=__ATOMIC_SEQ_CST, it should place a compiler barrier similar to
expansion of __atomic_signal_fence.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77684
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80640
--- Comment #7 from Alexander Monakov ---
I've submitted a patch [1] for the missing compiler barrier, but however please
note that the original ompi code and the example in comment #3 are wrong: in a
pattern like
while (*foo)
__atomic_thr
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Consider:
static int i;
static int b;
void sighandler(void)
{
b = i = 1;
}
__attribute__((noinline))
static int x(void)
{
asm volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
--- Comment #2 from Alexander Monakov ---
Nowadays C has atomics and fences in the language standard, so it doesn't
matter if x() had
asm volatile("":::"memory");
or
__atomic_{signal,thread}_fence(__ATOMIC_ACQ_REL);
or
return __atomic_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
--- Comment #4 from Alexander Monakov ---
ipa-reference.c has:
/* Set of all interesting module statics. A bit is set for every module
static we are considering. This is added to the local info when asm
code is found that clobbers all me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80728
--- Comment #6 from Alexander Monakov ---
I think a possible approach is to add a new cgraph_node flag (or a multi-bit
field, if we want to track presence of acquire/release/seq-cst compiler
barriers separately), handle asms and atomics specially
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80809
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80817
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80817
--- Comment #4 from Alexander Monakov ---
On 32-bit x86 manipulating 64-bit integers, let alone atomically, is going to
be inconvenient. The emitted code could have been shorter, instead of
movl(%esp), %eax
movl4(%esp),
||amonakov at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #6 from Alexander Monakov ---
There's a bit of a misunderstanding here, the -mcx16 option remains supported,
and the compiler remains capable of issuing lock-cmpxchg16b for _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #8 from Alexander Monakov ---
Well, at least it's not too late to update the compiler manual, so I've
submitted a patch: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02080.html
||2017-07-17
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
Yes, it's a similar target-specific issue, and I've noticed it when writing a
patch for PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67822
--- Comment #3 from Alexander Monakov ---
Author: amonakov
Date: Thu Nov 24 18:10:42 2016
New Revision: 242842
URL: https://gcc.gnu.org/viewcvs?rev=242842&root=gcc&view=rev
Log:
Allow -fopenmp in NVPTX mkoffload
PR target/67822
||amonakov at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #4 from Alexander Monakov ---
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78589
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78589
--- Comment #3 from Alexander Monakov ---
Ah, sorry if I misunderstood and got carried away.
>From my investigation it looks like for the '' issue it's just a
matter of setting DECL_ABSTRACT_ORIGIN in create_omp_child_function (not sure
if that'
||2016-12-16
Assignee|unassigned at gcc dot gnu.org |amonakov at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
Thanks. This is due to r243347. After that change, crtl->is_leaf is
initialized
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Noticed this ICE when looking at OpenMP gimplification/lowering:
void use(int*);
void f(int n)
{
#pragma omp simd
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78831
--- Comment #2 from Alexander Monakov ---
Author: amonakov
Date: Wed Dec 21 14:20:09 2016
New Revision: 243855
URL: https://gcc.gnu.org/viewcvs?rev=243855&root=gcc&view=rev
Log:
nvptx: do not assume that crtl->is_leaf is unset
PR target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78831
Alexander Monakov changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78884
--- Comment #2 from Alexander Monakov ---
Not sure how well this qualifies as a regression: prior to 4.9, there was no
OpenMP SIMD support, so 4.8 just diagnoses a warning for an unrecognized
omp-simd pragma.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727
--- Comment #8 from Alexander Monakov ---
Well, if my argument is correct, then GCC generates wrong code for the very
first example in comment #0. If that is deliberate as a compromise even though
otherwise GCC suppresses optimizations to honor p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79332
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79439
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79570
Alexander Monakov changed:
What|Removed |Added
CC||abel at gcc dot gnu.org
--- Comment
||2017-03-10
CC||abel at gcc dot gnu.org,
||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
Thanks for the nice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79985
--- Comment #3 from Alexander Monakov ---
Since r235809, in df-scan.c:df_insn_refs_collect, there's
3233 if (asm_noperands (PATTERN (insn_info->insn)) >= 0)
3234 for (unsigned i = 0; i < FIRST_PSEUDO_REGISTER; i++)
3235 if (global_re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79985
--- Comment #4 from Alexander Monakov ---
It might have been nicer to adjust asms themselves, adding inputs/outputs for
each global reg, if we must pretend the asms implicitly read/write them. That
would allow any subsystem (df, sched-deps, whate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80035
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
: wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Today, GCC considers all BBs clonable on GIMPLE, as indicated by
tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80053
--- Comment #2 from Alexander Monakov ---
(In reply to Richard Biener from comment #1)
> The question is whether the transform at hand is valid if the label is
> duplicated
> but all referers still refer to the original one (so if the label is dr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80053
--- Comment #3 from Alexander Monakov ---
... unless labels are intended to act similar to non-static function-scope
variables, with computed address usable only until the containing function
returns? Except when used in static initializers, whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80053
--- Comment #6 from Alexander Monakov ---
(In reply to rguent...@suse.de from comment #4)
> To the value in the other BB/function. This works if the jump
> targets are semantically compatible. For function cloning it's
> probably hard to say as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80197
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80197
--- Comment #5 from Alexander Monakov ---
On trunk, manually fixing up inlining is not enough: trunk additionally needs
-fno-tracer, otherwise crucial if-conversion of 'if (k < 0) k += m1;' is
prevented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80197
--- Comment #7 from Alexander Monakov ---
No, with fixed-up inlining -ftracer sees reasonable edge probabilities. The
reason tracer makes things worse here, is that it clones the path leading to a
50%/50% conditional branch (and correctly stops a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69992
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
501 - 600 of 1199 matches
Mail list logo
