https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #4 from Alexander Monakov ---
You can place points of possible access outside of abstract machine in a
fine-grained manner with volatile asms:
asm volatile("" : "=m"(buf));
This cannot be reordered against accesses to volatile va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114960
Bug ID: 114960
Summary: [12/13/14/15 Regression] fails to clean up vector
casts
Product: gcc
Version: 12.3.1
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114944
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114944
--- Comment #4 from Alexander Monakov ---
Like this:
pandxmm1, XMMWORD PTR .LC0[rip]
movaps XMMWORD PTR [rsp-40], xmm0
xor eax, eax
xor edx, edx
movaps XMMWORD PTR [rsp-24], xmm1
mov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115091
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115132
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #18 from Alexander Monakov ---
No, allowing value-changing transformations under -ftrapping-math is really not
appropriate. Invoking the intrinsic on a large floating-point value is not UB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #20 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #19)
> If we guarantee that we never constant fold FIX/UNSIGNED_FIX with
> -ftrapping-math (we shouldn't, as the exceptions should be raised), then
> using FIX/UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115170
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #23 from Alexander Monakov ---
(In reply to Sergei Trofimovich from comment #22)
> Here `pcmpeqd %xmm2,%xmm1` is a problematic instruction. Why does `gcc` use
> `%xmm2` (result of `cvttps2dq`) instead of, say `%xmm0` which contains
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115333
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #9 from Alexander Monakov ---
(In reply to Arsen Arsenović from comment #8)
> indeed (but I believe it did happen with Alder Lake already, by accident,
> with AVX512 on P-cores but not on E-cores).
AFAIK on those Alder Lake CPUs you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #11 from Alexander Monakov ---
(In reply to Hongtao.liu from comment #10)
> > indeed (but I believe it did happen with Alder Lake already, by accident,
> > with AVX512 on P-cores but not on E-cores).
>
> AVX512 is physically fused o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111884
Bug ID: 111884
Summary: unsigned char no longer aliases anything under
-std=c2x
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112367
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82242
--- Comment #5 from Alexander Monakov ---
The small testcase from comment 3 is now improved on trunk, possibly thanks to
work in PR 110215.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
Alexander Monakov changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
--- Comment #13 from Alexander Monakov ---
> Then there is the MULT_EXPR x * x case
This is PR 111701.
It would be nice to clarify what "nonnegative" means in the contracts of this
family of functions, because it's ambiguous for NaNs and negat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112699
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112699
--- Comment #2 from Alexander Monakov ---
Sorry, even though GCC's limits.h is installed under include-fixed, it is
generated separately, not by the generic fixincludes mechanism. I was confused.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
Bug ID: 112701
Summary: wrong type inference for ternary operator in
preprocessing context
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
--- Comment #8 from Alexander Monakov ---
Thanks, I can reproduce it. It is pretty tricky though. For instance, just
swapping the mov and the compare is enough to make it fast:
--- d.out.ltrans0.ltrans.slow.s 2023-12-01 18:32:54.255841611 +0300
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
--- Comment #9 from Alexander Monakov ---
... as does inserting a nop before the compare ¯\_(ツ)_/¯
--- d.out.ltrans0.ltrans.slow.s 2023-12-01 18:32:54.255841611 +0300
+++ d.out.ltrans0.ltrans.s 2023-12-01 18:53:04.909438690 +0300
@@ -743,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109892
Bug ID: 109892
Summary: SLP failure with explicit fma
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #22 from Alexander Monakov ---
Created attachment 55105
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55105&action=edit
patch 1/3
(In reply to Richard Biener from comment #21)
>
> Sounds reasonable. Though I wouldn't use GE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #25 from Alexander Monakov ---
(In reply to Richard Biener from comment #24)
> As of the patch it looks good, I wonder if we want to check for OPTIMIZE_BOTH
> though since at least when no extra negations are required the contraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #26 from Alexander Monakov ---
> > Did you run into any of NON_LVALUE / C_MAYBE_CONST wrappings of the
> > multiplication btw?
>
> No, I'm not familiar with those, so I didn't try to construct corresponding
> testcases.
I had a loo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109916
Alexander Monakov changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922
Alexander Monakov changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109950
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109944
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110007
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
--- Comment #13 from Alexander Monakov ---
No, neither for fields nor for the complete object:
struct
__attribute__((aligned(64)))
S {
int i;
};
void f()
{
struct S s __attribute__((aligned(1))), *p = &s;
int *q = &s.i;
asm(""
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
--- Comment #15 from Alexander Monakov ---
For '--float' I think runtime differences are expected when you pass -m flags
that enable FMA, unless you also pass '-ffp-contract=off'.
For '--compiler-attributes' I'd suggest reporting only compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110052
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110053
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110054
Alexander Monakov changed:
What|Removed |Added
Keywords||wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110069
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110052
--- Comment #5 from Alexander Monakov ---
There are other reasons why it's invalid. For instance, in a multi-threaded
program it could introduce a data race on assignment to foo->size inside of
'myrealloc' where the original program might have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110087
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110089
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110035
--- Comment #15 from Alexander Monakov ---
malloc and friends modify 'errno' on failure, so in they would have to be
special-cased for alias analysis.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110169
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110202
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110249
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110250
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110260
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110260
--- Comment #6 from Alexander Monakov ---
(In reply to Jimi Huotari from comment #0)
> (By the by, is ADCX a typo of ADX? I see -madx as an option but only one
> use of it otherwise, and no -adcx as an option and lots of mentions of it...
> but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110260
--- Comment #10 from Alexander Monakov ---
Right, those are different issues. Any chance of a standalone testcase
extracted from Wine? If you already see a function where stack realignment is
missing, just give us preprocessed containing source,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
--- Comment #3 from Alexander Monakov ---
Seems to work fine with explicit '-mincoming-stack-boundary=2' on the command
line, even though it should make no difference for the 32-bit MinGW target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
--- Comment #4 from Alexander Monakov ---
Further reduced:
void f()
{
int c[4] = { 0, 0, 0, 0 };
int cc[8] = { 0 };
asm("" :: "m"(c), "m"(cc));
}
Also reproducible with -march=skylake-avx512 or even plain -mavx512f,
retitling.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
--- Comment #6 from Alexander Monakov ---
Huh? Just compile the supplied testcases without avx512, you'll see proper
stack realignment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
--- Comment #3 from Alexander Monakov ---
Do you have older versions of GCC to check on this testcase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
--- Comment #5 from Alexander Monakov ---
It's not necessary yet for this particular bug, but might be helpful for future
bugs (if disk space is not an issue).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
--- Comment #6 from Alexander Monakov ---
Cross-compiler needs HAVE_AS_EXPLICIT_RELOCS=1.
With checking enabled, we get:
t.c:8:1: error: flow control insn inside a basic block
(call_insn 97 96 98 4 (parallel [
(set (reg:DI 0 $0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
--- Comment #8 from Alexander Monakov ---
REG_EH_REGION is handled further down that function, but
copy_reg_eh_region_note_backward does not copy the note. Perhaps it needs
diff --git a/gcc/except.cc b/gcc/except.cc
index e728aa43b6..cfe140c4d0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
--- Comment #10 from Alexander Monakov ---
I think the first patch may result in duplicated notes, so I wouldn't recommend
picking it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110369
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307
--- Comment #13 from Alexander Monakov ---
Note to self: check how control_flow_insn_p relates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #11 from Alexander Monakov ---
The trapping angle seems valid, but I have a really hard time understanding the
DSE issue, and the preceding issue about disambiguation based on RTL aliasing.
How would DSE optimize out 'd[5] = 1' in y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #13 from Alexander Monakov ---
(In reply to rguent...@suse.de from comment #12)
> As explained in comment#3 the issue is related to the tree alias oracle
> part that gets invoked on the MEM_EXPR for the load where there is
> no infor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
--- Comment #8 from Alexander Monakov ---
(In reply to Sam James from comment #7)
> We keep getting quite a few reports of this downstream.
Of this mingw32 stack realignment issue specifically, i.e. Wine breakage when
AVX512 is enabled via CFLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #16 from Alexander Monakov ---
(In reply to rguent...@suse.de from comment #14)
> vectors of T and scalar T interoperate TBAA wise. What we disambiguate is
>
> int a[2];
>
> int foo(int *p)
> {
> a[0] = 1;
> *(v4si *)p = {0,0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #18 from Alexander Monakov ---
(In reply to rguent...@suse.de from comment #17)
> Yes, we do the same to loads. I hope that's not a common technique
> though but I have to admit the vectorizer itself assesses whether it's
> safe to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110431
Bug ID: 110431
Summary: Incorrect disambiguation of wide accesess from
store-merging or SLP
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Keywords: wrong-co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #21 from Alexander Monakov ---
(In reply to rguent...@suse.de from comment #19)
> But the size argument doesn't have anything to do with TBAA (and
> may_alias is about TBAA). I don't think we have any way to circumvent
> C object ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110438
Bug ID: 110438
Summary: generating all-ones zmm needs dep-breaking pxor before
ternlog
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110438
--- Comment #1 from Alexander Monakov ---
We might want to omit PXOR when optimizing for size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110202
--- Comment #7 from Alexander Monakov ---
Note that vpxor serves as a dependency-breaking instruction (see PR 110438). So
in negate1 we do the right thing for the wrong reasons, and in negate2 we can
cause a substantial stall if the previous com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110202
--- Comment #9 from Alexander Monakov ---
(In reply to Hongtao.liu from comment #8)
>
> For this one, we can load *a into %zmm0 to avoid false_dependence.
>
> vmovdqau ZMMWORD PTR [rdi], zmm0
> vpternlogq zmm0, zmm0, zmm0, 85
Yes, since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110438
--- Comment #3 from Alexander Monakov ---
Patch available:
https://inbox.sourceware.org/gcc-patches/8f73371d732237ed54ede44b7bd88...@ispras.ru/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110611
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44179
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113280
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113293
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113560
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #20 from Alexander Monakov ---
Sam, can you provide more context? It seems there is no downstream bugreport?
How does the alleged miscompilation manifest?
Note that effects of interplay of fp-contract=fast and vectorization can be
p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #22 from Alexander Monakov ---
Similar to the RawTherapee issue, SLP opportunities are created by predcom, so
either -fno-predictive-commoning or -fno-tree-slp-vectorize avoids numerical
runaway on the small testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #23 from Alexander Monakov ---
I suggest it to close this a dup of PR 106902 if there are no better ideas.
By the way, in both cases SLP introduces vectors in a loop where scalar
computations it's attempting to replace are not elimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115533
--- Comment #26 from Alexander Monakov ---
(In reply to Richard Biener from comment #24)
>
> That's because of -fno-vect-cost-model, it wouldn't be vectorized otherwise.
Thanks, I forgot. The testcase in PR 106902 was vectorized at plain -O3 b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114659
--- Comment #15 from Alexander Monakov ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Alexander Monakov from comment #13)
> > fldt does not convert (otherwise there's no way to spill/reload x87
> > registers).
>
> Doesn't it st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832
--- Comment #15 from Alexander Monakov ---
No, I didn't do older AMDs (btver2 & bdver3) and newer AMD (znver4) regressed
this once again. Here's the current picture of top 10:
nm -CS -t d --defined-only gcc/insn-automata.o | sed 's/^[0-9]* 0*//'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117239
--- Comment #2 from Alexander Monakov ---
Amazing bug. Note that it depends on high-order bits of return address
overwriting o.i, so may need -no-pie -fno-pie to reproduce. Alternatively,
changing 'if (o.i)' to 'if (o.i != 1)' allows to reproduc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117239
--- Comment #4 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #2)
> Alternatively,
> changing 'if (o.i)' to 'if (o.i != 1)' allows to reproduce with PIE as well.
^
I meant 'if (o.i ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117249
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
301 - 400 of 456 matches
Mail list logo
