https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87453
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87505
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84301
--- Comment #4 from Alexander Monakov ---
Moreover, without --param selsched-max-lookahead=2 sel-sched moves both the
assignment and use into middle of BB 2, breaking the assumption in
mode-switching that retval use is the last insn:
249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84566
--- Comment #1 from Alexander Monakov ---
Sorry, I cannot reproduce this. I've built a cross-compiler from today's trunk
via 'configure --target aarch64-linux-gnu && make all-gcc' (i.e. just to
cc1plus, no binutils etc.) and it doesn't abort.
If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84566
--- Comment #2 from Alexander Monakov ---
Bah, built a wrong branch, not the trunk. I'll recheck later, sorry for the
noise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84566
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84562
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64
The following code (derived from a hot loop in a Huffman encoder, reported by
Fabian Giesen) suffers from TER activity too much on x86-64. TER lifts
loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84861
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #12 from Alexander Monakov ---
I can reproduce it with downloaded Debian's cc1plus, and for me -Wnonnull alone
is sufficient to cause diverging codegen. It diverges very early, in the
frontend: diff of .tu dumps starts with:
--- a/1/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #13 from Alexander Monakov ---
> (in the diffs, plus-lines correspond to -Wnonnull added to command line)
No, sorry, it was the other way around. Here's the reverse diff with more
context:
if (0)
{
<;
}
- if
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
I expected predcom to eliminate one of the loads in this loop at -O3:
int is_sorted(int *a, int n)
{
for (int i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87528
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87528
--- Comment #4 from Alexander Monakov ---
(In reply to Richard Biener from comment #3)
> Can you point me to the source for which we generate the popcount call(s)?
> It might be not final value replacement but instead code-generating a niter
> a
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: arm-*-*
When tailcalling via a pointer that needs to be loaded from memory, gcc could
use 'ldr pc, [...]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87565
--- Comment #2 from Alexander Monakov ---
PLT trampolines all end with 'ldr pc, [ip, xxx]!', so do all calls via PLT
suffer from poor branch prediction of such indirect jumps?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86677
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87581
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82803
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87599
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87599
--- Comment #5 from Alexander Monakov ---
I think we should use punpcklqdq here rather than movddup, because (at least on
Intel) it has same latency, and same-or-better throughput. It may be ok to use
movddup when broadcasting from a memory sourc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82803
--- Comment #7 from Alexander Monakov ---
Sorry, should have double-checked when commenting. I see RTL LIM simply
considers all calls non-invariant in check_maybe_invariant.
I wonder if it would make sense to represent tls abi calls as unspecs u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87599
--- Comment #7 from Alexander Monakov ---
But note that even with -mavx, gcc still uses movddup, even though the second
alternative has vpunpcklqdq with a register source.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87599
--- Comment #8 from Alexander Monakov ---
Never mind, I was misunderstanding the effect of your patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87608
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615
--- Comment #3 from Alexander Monakov ---
On gcc-8 -fno-ipa-cp does not affect time, I brought it up prematurely:
-O2 -time
# cc1 207.15 0.22
-O2 -time -fno-ipa-cp
# cc1 207.57 0.18
-O2 -time -fno-inline
# cc1 21.13 0.10
Looks like gcc-9 regres
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
On the following example the 'p' argument in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: i?86-*-*
Created attachment 44858
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44858&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627
--- Comment #5 from Alexander Monakov ---
I've spent some time looking at this again, and I couldn't find a way to
preserve REG_EQUIV notes (it's actually unclear what REG_EQUIV means
precisely).
What I think could help in simple cases like this
: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
PR 63900 points out a case where RTL CSE fails to clean up redundant loads in
presence of BLKmode accesses, but there really isn&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63900
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: ilya.lesokhin at gmail dot com
Target Milestone: ---
GCC fails to allocate %rsi for the first operand of the asm at -O2:
int test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15089
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87627
--- Comment #6 from Alexander Monakov ---
FWIW the following CSE enhancement cleans this up, but I'm unhappy with this
patch because it's too narrowly targeted; in particular, won't clean up
void g(int a, int *b, int c);
void f(int a, int *b, in
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
Looking at i386 insn-automata.o, out of its 2.2M rodata size almost all is due
to very large tables for AMD CPU models. Note how
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
by_pieces code uses only mov_optab, never checking movmisalign_optab, so on
STRICT_ALIGNMENT targets such as arm it does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87942
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87958
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87942
--- Comment #4 from Alexander Monakov ---
(In reply to Johannes Vetter from comment #3)
> My problem now: in how many other cases is the same behavior? I cannot check
> every global variable/struct by hand.
I recommend to open a new bugreport fo
||2018-11-12
CC||amonakov at gcc dot gnu.org
Resolution|DUPLICATE |---
Ever confirmed|0 |1
--- Comment #5 from Alexander Monakov ---
Reopening per comment #4: while we do
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
In the following snippet the arguments to the second asm are not correctly
prepared:
void f(long long x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87978
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #8 from Alexander Monakov ---
Executable testcase suitable for bisecting, aborts with -O2 -m32
__attribute__((weak))
int f(long long x[])
{
int o=0, i;
for (i=0; i<3; i++) {
register int a asm("eax");
a = x[0]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #9 from Alexander Monakov ---
Actually, no long division needed, broken with a plain move as well:
__attribute__((weak))
int f(void)
{
int o=0, i;
for (i=0; i<3; i++) {
register int a asm("eax");
a = 1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88005
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88005
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485
--- Comment #9 from Alexander Monakov ---
Martin, Jakub: if I add -fstack-protector-strong, the problem is reproducible
for me - can you try that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52171
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
--- Comment #17 from Alexander Monakov ---
Test shown in comment #2 is still not optimized at -O2, so as comment #12 said,
> Load part remains.
Not sure if that needs to be split off into a separate bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485
--- Comment #11 from Alexander Monakov ---
Just for information: the extra flag is needed due to --enable-default-ssp on
Arseny's configure command line.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735
--- Comment #24 from Alexander Monakov ---
Janus, can you attach your .s and .o files please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735
--- Comment #28 from Alexander Monakov ---
It seems like object file is not correctly assembled, note wrong offset to the
last instruction (movdqu):
.s:
vpgatherqd (%rax,%ymm3,4), %xmm4{%k4}
vpgatherqd (%rax,%ymm1,4),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65855
Alexander Monakov changed:
What|Removed |Added
CC||giuliano.belinassi at usp dot
br
--
||amonakov at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Alexander Monakov ---
See PR 65855.
*** This bug has been marked as a duplicate of bug 65855 ***
||amonakov at gcc dot gnu.org
--- Comment #1 from Alexander Monakov ---
It's tricky to use macro-expanded expressions in scope of default(none), you
never know what the expansion is going to reference. This is not limited to the
assert macro (or to its use of __PRETTY_FUNCT
||amonakov at gcc dot gnu.org
Component|c |tree-optimization
Summary|Wrong code for intrinsic|[8/9 Regression] Wrong code
|memmove |for intrinsic memmove
--- Comment #2 from Alexander
|WAITING |NEW
CC||amonakov at gcc dot gnu.org
Known to work||4.3.2
Summary|Invalid tree PRE|[7/8/9 Regression] Invalid
|optimization around |tree PRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88096
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88279
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88279
--- Comment #4 from Alexander Monakov ---
To clarify, the decl/type mixup is causing the compiler to use local-dynamic
TLS references where general-dynamic are intended (and were used prior to the
patch).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88302
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #14 from Alexander Monakov ---
With -fno-tree-fre it's still broken.
How long will GCC play this sort of whack-a-mole with ad-hoc restrictions to
gimple optimizations (PR 29877, PR 42491, PR 61572)?
And this:
> for fixed registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #15 from Alexander Monakov ---
Typo: PR 42491 should have said PR 43491.
Hopefully more obviously-broken testcase with an inline function:
static inline void
ff(int *o)
{
register int a asm("eax");
a = 1;
asm("add %1, %0
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
With -std=c++17 GCC segfaults on
template
int f()
{
return 0;
}
template int f();
Clang accepts with -fsyntax-only, segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #6 from Alexander Monakov ---
If this is fixed then the testcase should be added to the testsuite to make
sure we catch it if we regress again (this worked before e.g. on gcc-4.1).
Peter, can you please clarify, is this actually fixe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028
Bug #: 56028
Summary: Splitting a 64-bit volatile store
Classification: Unclassified
Product: gcc
Version: 4.7.2
URL: http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00870.htm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #2 from Alexander Monakov ---
(added SH maintainers, Oleg Endo and Kaz Kojima to Cc)
In response to the last sentence in my analysis, on IRC Rich pointed out that
using r1/r2/r3 should be better that r0 because some instruction can o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #7 from Alexander Monakov ---
Oleg, Rich, there's some confusion in comments 4-6. Please unwind all the way
back to comment #1, and let me explain the issue once again. I now see that my
phrasing back then was insufficiently detaile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #8 from Alexander Monakov ---
Hm, if GCC won't accept clobbering a hardreg that overlaps the output hardregs
holding the return value (operands[0]), then it's less obvious. r0 is always
suitable then and does not require mentioning in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #10 from Alexander Monakov ---
If always using r0 is not an issue, I think it's possible to just use
operands[0] (casting it to the right size with subreg:SI, if needed) to avoid
using a potentially-reserved hardreg. This would allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #12 from Alexander Monakov ---
> Do you have anything in particular in mind?
I mostly wonder why does sh.md change RTL representation of a sibcall that way,
instead of simply generating the required relative address load upfront, dur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65362
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
int f(long a)
{
int *p=(int*)(a<<1);
//asm("" : "+r"(p));
return *p;
}
Starting from 4.9
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
#include
int main()
{
int i=0;
#pragma omp task default(shared) if(0)
{
#pragma omp simd
for
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
int f(int (**p)(void))
{
return -p[1]();
}
gcc-6 -O2 produces:
f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70804
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70804
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
GCC doesn't warn for:
const char s[] = "\008";
(just the two zeros following the backslash become a part of the octal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952
--- Comment #1 from Alexander Monakov ---
Octal escapes have no more than three digits by definition, so "\0009" clearly
doesn't fall under this warning.
Upon further testing, there's no diagnostic for
const char c = '\9'; /* same as ... = 9; *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952
--- Comment #2 from Alexander Monakov ---
Bah, please disregard the last point; '\9' is diagnosed similar to "\9".
Keywords: accepts-invalid, openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
OpenMP 4.5 says (4.0 had a similar restriction, sans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71064
--- Comment #1 from Alexander Monakov ---
> (It's generally tuned for speed instead of precision, and does not strive for
> full IEEE-754 conformance.)
(PTX is an abstract ISA, if it's tuned for anything it's the simplicity of
abstraction and m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945
--- Comment #3 from Alexander Monakov ---
I like to avoid touching generic stuff for issues like this one. Please see
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01022.html for a brief outline of
an alternative solution: I think my proposal of
-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
If A and B are both unsigned, then 'A > -1 / B' is a nice predic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71289
--- Comment #2 from Alexander Monakov ---
> What do the dumps look like? Gcc is likely to change things to -1 / B < A,
> which you don't handle...
The dumps didn't help much, but you're right that normally the order is
opposite, thanks (I didn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71289
--- Comment #4 from Alexander Monakov ---
Author: amonakov
Date: Mon May 30 14:37:02 2016
New Revision: 236882
URL: https://gcc.gnu.org/viewcvs?rev=236882&root=gcc&view=rev
Log:
match.pd: optimize unsigned mul overflow check
gcc/
2016-05-28 Al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71289
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71495
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71535
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71536
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
401 - 500 of 1199 matches
Mail list logo
