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=110438
--- Comment #1 from Alexander Monakov ---
We might want to omit PXOR when optimizing for size.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
VPTERNLOG is never a dependency-breaking instruction on existing x86
implementations, so generating a
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
-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Inspired by bug 110237 comment 19:
int b, a;
int main()
{
int *pa = &a, *pb
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=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=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 #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=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=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=110369
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
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=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 #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 #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 #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
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
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=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 #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=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=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
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110250
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110249
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110202
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110169
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
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=109967
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110089
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110087
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
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=110069
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
||amonakov at gcc dot gnu.org
--- Comment #1 from Alexander Monakov ---
This is a correctness issue as well due to lack of SFENCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110053
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110052
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
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=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=110007
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109944
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109950
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922
Alexander Monakov changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #
|UNCONFIRMED |RESOLVED
CC||amonakov at gcc dot gnu.org
--- Comment #1 from Alexander Monakov ---
There's a family of similar reports that "late" warnings do not observe this
pragma under LTO. I think it's best to ma
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=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 #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
: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
At -O2 -mfma (x86) or -O3 (arm64) we fail to SLP-vectorize 'f', but succeed in
'g':
double f(double x[], long n)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #32 from Alexander Monakov ---
Ranger ICE is PR 109841 (reduced so it doesn't need LTO).
-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Created attachment 55076
--> https://gcc.gnu.org/bugzilla/attachment.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #31 from Alexander Monakov ---
(In reply to Xi Ruoyao from comment #28)
> "To put it simply, operator delete for class User inspects memory of the
> object after the end of its lifetime. This shows as a use-after-dtor error
> when ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #26 from Alexander Monakov ---
Would that help? GCC raises its own stack limit to 64MB:
gcc.cc: stack_limit_increase (64 * 1024 * 1024);
toplev.cc: stack_limit_increase (64 * 1024 * 1024);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #24 from Alexander Monakov ---
Appreciate the advice. So far I've managed to reduce the number of LTO inputs
down to two files, RegisterBankInfo.cpp.o plus APInt.cpp.o. I also built
gcc-12.3 with lineinfo and have a better backtrace:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #22 from Alexander Monakov ---
(In reply to Jan Hubicka from comment #19)
> It would be really nice to have the ranger bug fixed. Since lifetime
> DSE is all handled in C++ FE there is no good reason why it should not
> work to LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #21 from Alexander Monakov ---
(In reply to Xi Ruoyao from comment #18)
> Maybe. Should we send a patch?
Yes, if we have a volunteer.
> If I read the LLVM code correctly, -fno-strict-aliasing is enabled for
> Clang, but not other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #17 from Alexander Monakov ---
Right, thanks, I think SUSE build log confirms that (careful, large file):
https://build.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/llvm16/_log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #14 from Alexander Monakov ---
(In reply to Jan Hubicka from comment #13)
> Indeed it is quite long time problem with clang not building with lifetime
> DSE and strict aliasing. I wonder why this is not fixed on clang side?
Because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #12 from Alexander Monakov ---
That would not fix the problem, lifetime-dse affects code that creates 'class
User' objects, not the implementation of its 'operator new' override.
(also the linked bug says "MDNode has the same patter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #10 from Alexander Monakov ---
Indeed, that makes things easier, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #8 from Alexander Monakov ---
Ah, forgot to mention that compiler the offending User.cpp without -flto also
avoids the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #7 from Alexander Monakov ---
This problem seems to go way back. I'm told even gcc-9 broke LLVM like that.
For my investigation, I took latest gcc-11 snapshot and llvm-13.0.1.
My conclusion that it is a lifetime-dse violation in LL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #20 from Alexander Monakov ---
I missed it the first time around, but placing PAREN_EXPR around the complete
expression won't work: nothing will prevent GCC from duplicating evaluations of
the sub-expressions, and then randomly formi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109780
Alexander Monakov changed:
What|Removed |Added
Summary|csmith: runtime crash with |[12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109780
--- Comment #12 from Alexander Monakov ---
Eh, that commit sneakily changed avx2 tuning without explaining that in the
Changelog. Anyway, it should possible to "workaround" that by compiling with
-O2 -mavx2 -mtune=skylake-avx512
instead, in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109780
--- Comment #10 from Alexander Monakov ---
(In reply to Martin Liška from comment #9)
> Started with zen tuning revision r13-4839-geef81eefcdc2a5.
The issue is also reproducible with -march=haswell or -march=skylake, so you
can use those for fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109780
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109690
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90746
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109634
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109587
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
--- Comment #19 from Alexander Monakov ---
Manually minimized testcase for investigation, miscompiled at -O2:
struct P {
long v;
struct P *n;
};
struct F {
long x;
struct P fam[];
};
int f(struct F *f, int i)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109369
--- Comment #9 from Alexander Monakov ---
(In reply to Pali Rohár from comment #8)
> So from the discussion, do I understand correctly that this is rather LD
> linker issue?
Yes, ld changes will be needed to make this work automatically, withou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109469
--- Comment #8 from Alexander Monakov ---
*** Bug 109477 has been marked as a duplicate of this bug. ***
||amonakov at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #4 from Alexander Monakov ---
This is also SLP emitting a vector ctor in an unexpected place, just like in
PR109469, so I'll go ahead and mark it as a dup. Thanks fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109469
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109369
--- Comment #7 from Alexander Monakov ---
Yes, ld should claim _pei386_runtime_relocator (even if later it becomes
unneeded due to zero relocations left to fix up) to make this work properly.
That's for Binutils to fix on their side.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109369
--- Comment #5 from Alexander Monakov ---
Indeed, sorry, __attribute__((used)) seems a much better solution for symbols
that might be referenced implicitly, in a manner that LTO plugin cannot see.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109369
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109368
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109187
Alexander Monakov changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-*-*
With -O2 -mstrict-align, for
void f(void *p)
{
__builtin_memset(p, 0, 16);
}
gcc-10 and before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109187
--- Comment #3 from Alexander Monakov ---
The reduced case is offsetting stack variables in a manner that seems too
invalid for my taste, so I plan to send a patch with a following testcase
instead (needs -O2 --param sched-autopref-queue-depth=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109187
--- Comment #2 from Alexander Monakov ---
This is caused by overflowing subtraction in autopref_rank_for_schedule:
if (!irrel1 && !irrel2)
/* Sort memory references from lowest offset to the largest. */
r = data1->offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #18 from Alexander Monakov ---
It seems you are saying that as long as GCC emits code according to the Holy
Scripture that is the ABI spec, everything is fine. I imagine on other
architectures maintainers are able to consider how the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
Alexander Monakov changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #14 from Alexander Monakov ---
Are you guys really sure you want to blame the user here, considering that all
linkers, including the BFD linker, initially misinterpreted the ABI the same
way?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #10 from Alexander Monakov ---
(In reply to Rui Ueyama from comment #9)
> I'm the maintainer of the mold linker. I didn't implement that POWER10 ABI
> because I didn't have an access to a POWER10 machine and therefore couldn't
> veri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #4 from Alexander Monakov ---
Let me address one point separately:
(In reply to Peter Bergner from comment #1)
> CCing Alan, since he probably knows best how this all works, but yes,
> -mcpu-power10 changes the ABI, namely it adds p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #3 from Alexander Monakov ---
Alan implemented the special case of .localentry 1 in this patch for the BFD
linker (that appeared in binutils 2.32 if my calculations are correct):
https://sourceware.org/pipermail/binutils/2018-July/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #22 from Alexander Monakov ---
Strange, comment #8 claims the opposite (unless Jan tested the revert not on
trunk, but on some branch).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #19 from Alexander Monakov ---
I get the feeling that you're ignoring me, but gcc-4.8.3 was already emitting a
helper fmod call for setting errno without any flag_errno_math checks in
i386.md, i.e. it was already in the middle-end. A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #15 from Alexander Monakov ---
That is the fancy-error-handling path that is reached under _LIB_VERSION !=
_IEEE_. Before glibc-2.27, linking with -lieee would set _LIB_VERSION = _IEEE_,
and then glibc would use the fprem[1] instruct
101 - 200 of 1147 matches
Mail list logo