https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93743
Alexander Monakov changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
-*-*
Status|UNCONFIRMED |NEW
Keywords||wrong-code
Last reconfirmed||2020-02-14
Component|c |rtl-optimization
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93734
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
--- Comment #15 from Alexander Monakov ---
This should not be reproducible with current HEAD because the assert was simply
eliminated. If GCC master definitely fails, can you please provide the exact
diagnostic?
As for 9.2 this is sadly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572
--- Comment #5 from Alexander Monakov ---
GCC is emitting static_local as @gnu_unique_object, so it should be unified by
the Glibc dynamic linker. You can use 'nm -CD' to check its type after linking
for the main executable and the library to
||amonakov at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Alexander Monakov ---
Dup.
*** This bug has been marked as a duplicate of bug 93056 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93056
Alexander Monakov changed:
What|Removed |Added
CC||hehaochen at hotmail dot com
---
||amonakov at gcc dot gnu.org
--- Comment #4 from Alexander Monakov ---
(In reply to Alexander Cherepanov from comment #2)
> > Do you have a testcase were gcc does this optimize without the user adding
> > const and still traps?
>
> No. I'll file a separate bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93444
--- Comment #5 from Alexander Monakov ---
The problem is lifting a conditional access. We don't have an example where
lifting an invariant from an always-executed block in a loop to its preheader
poses a problem.
LLVM adopted an approach where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93444
Alexander Monakov changed:
What|Removed |Added
Summary|[8/9/10 Regression] |[8/9/10 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
--- Comment #8 from Alexander Monakov ---
Pasted that to new PR 93444 (should have done that right away, sorry).
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: ch3root at openwall dot com
Target Milestone: ---
Splitting out bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838
--- Comment #5 from Alexander Monakov ---
Ah, indeed, it should be explicitly UB, and the documentation should mention
that as well as that implicit integer promotion does not happen for vector
shifts and other operations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
--- Comment #19 from Alexander Monakov ---
(In reply to Michael Matz from comment #18)
> represent all accesses indirectly via pointers
Would that be necessary in presence of a verifier that ensures that all
references are dominated by births?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
||2020-01-23
CC||amonakov at gcc dot gnu.org
Summary|Wrong code when returning |[8/9/10 Regression] Wrong
|padded struct |code when returning padded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91824
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93278
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90565
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93274
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93039
--- Comment #5 from Alexander Monakov ---
Ah, in that sense. The extra load is problematic in cold code where it's likely
a TLB miss. For hot code: the load does not depend on any previous computations
and so does not increase dependency chains.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93039
--- Comment #3 from Alexander Monakov ---
> The question is for which CPUs is it actually faster to use SSE?
In the context of chains where the source and the destination need to be SSE
registers, pretty much all CPUs? Inter-unit moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93165
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #29 from Alexander Monakov ---
(In reply to Alexander Cherepanov from comment #28)
> I see the same even with pure pointers. I guess RTL doesn't care about such
> differences but it means the problem could bite a relatively innocent
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-12-27
CC||amonakov at gcc dot gnu.org
Component|tree-optimization |target
Ever confirmed|0 |1
--- Comment #1
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-12-25
CC||amonakov at gcc dot gnu.org
Summary|ICE: Segmentation fault |[8/9/10 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
--- Comment #4 from Alexander Monakov ---
The attachment is edited to test insertion_sort, and doesn't call
accumulate_vector at all - looks like you attached a wrong file?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93056
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
--- Comment #2 from Alexander Monakov ---
Can you attach preprocessed source and double-check command-line flags? I can't
reproduce the problem with lea, and the code does not have explicit prefetch
instructions that I get with -O3 -march=bdver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905
--- Comment #8 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #0)
> Eventually it would be nicer to use SSE bitwise operations for this, for
> example LLVM already generates
> f:
> orps.LCPI0_0(%rip), %xmm0
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
(the non-regression part of PR 92905)
libm functions need to manipulate individual bits of float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93031
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92953
--- Comment #4 from Alexander Monakov ---
At least then GCC should try to use cmovno instead of seto-test-cmove for
if-conversion:
foo:
movl%edi, %eax
subl%esi, %eax
notl%eax
orl $1, %eax
||amonakov at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #5 from Alexander Monakov ---
Looks like the documentation was added in r230651, overflow patterns for arm in
r239739, and for arm64 in r262890.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92953
--- Comment #2 from Alexander Monakov ---
Well, the aarch64 backend does not implement subv4 pattern in the first
place, which would be required for efficient branchy code:
foo:
subsw0, w0, w1
b.vc.LBB0_2
mvn
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Consider:
/* Return 0 if a==b, any positive value if a>b, any negative value otherwise.
*/
int foo(int a, int b)
{
int c;
if (__builtin_sub_overflow(a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905
--- Comment #4 from Alexander Monakov ---
Perhaps only xmm0 is problematic, as making xmm0 unused by adding a dummy
argument brings back the old spill-free result:
float my_copysign(float dummy, float x, float y)
{
union {float f; unsigned
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
gcc-10 branch regressed for code that needs bitwise operations on floats:
float f(float x)
{
union {float f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47877
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92855
Alexander Monakov changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47877
Alexander Monakov changed:
What|Removed |Added
CC||thiago at kde dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92855
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92768
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92597
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91161
--- Comment #3 from Alexander Monakov ---
With -fno-dce, a NOTE_INSN_DELETED_LABEL appears between the last "real" insn
in the basic block (a sibcall) and a barrier rtx:
(call_insn/u/c 20 19 12 3 (call (mem:QI (symbol_ref:DI ("ni") [flags 0x3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #10 from Alexander Monakov ---
> atomic_cmpxchg_func tries to cast 'dest' from uint8_t* to int*
I made a typo here, I meant uint32_t rather than uint8_t, and there's no
aliasing violation here as signedness difference is explicitly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
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
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
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=gcc=rev
Log:
ifcvt: improve cost estimation (PR 87047)
PR
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=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://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
>
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=gcc=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|---
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 address
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=gcc=rev
Log:
sel-sched: allow negative insn priority (PR 88879)
PR
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 overflow matters when
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 less
||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
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
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=gcc=rev
Log:
sel-sched: skip outer loop in get_all_loop_exits (PR 84206)
2019-04-02
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=gcc=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|---
401 - 500 of 1116 matches
Mail list logo
