https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #7 from Alexander Monakov ---
I wanted to understand what gets exposed in LTO mode that causes a blowup.
I'd say flatten is not appropriate for this function (I don't think you want to
force inlining of memset or _find_next_bit?), s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
--- Comment #5 from Alexander Monakov ---
(In reply to Jiri Slaby from comment #4)
> > I am surprised that "flatten" blows up on this function. Is that with any
> > config, or again some specific settings like gcov? Is there an existing lkml
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #13 from Alexander Monakov ---
(In reply to Richard Biener from comment #12)
> > Isn't it easy now to implement -ffp-contract=on by a GENERIC-only match.pd
> > rule?
>
> You mean in the frontend only for -ffp-contract=on?
Yes.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #11 from Alexander Monakov ---
Can we move -ffp-contract=fast under the -ffast-math umbrella and default to
-ffp-contract=on/off?
Isn't it easy now to implement -ffp-contract=on by a GENERIC-only match.pd
rule?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106952
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #7 from Alexander Monakov ---
Lawrence, thank you for the nice work reducing the testcase. For RawTherapee
the recommended course of action would be to compile everything with
-ffp-contract=off, then manually reintroduce use of fma i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299
Alexander Monakov changed:
What|Removed |Added
Keywords||wrong-code
Summary|LTO in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #10 from Alexander Monakov ---
Okay, so this should have been reported against Binutils, but since we are
having the conversation here: the current behavior is not good, gas is silently
selecting a different relocation kind for no cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106453
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #8 from Alexander Monakov ---
Right, sorry, due to presence of 'main' I overlooked -fPIC in comment #0, and
then after my prompt it got dropped in comment #3.
If you modify the testcase as follows and compile it with -fPIC, it's evi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
--- Comment #6 from Alexander Monakov ---
(In reply to Martin Liška from comment #5)
> Do you mean gas or ld?
gas
> How did you get this output, please (from foo.o or final executable)?
>From foo.o like in comment #0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
--- Comment #3 from Alexander Monakov ---
It would be unfortunate if that makes it difficult or even impossible to make a
R_386_32 relocation for the address of GOT in hand-written assembly.
In any case, it seems GCC is not making the rules her
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
Alexander Monakov changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106834
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106804
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106781
--- Comment #5 from Alexander Monakov ---
GCC discovers that 'bar' is noreturn, tries to remove its LHS but unfortunately
cgraph.cc:cgraph_edge::redirect_call_stmt_to_callee wants to emit an assignment
of SSA default-def to the LHS. fixup_noretu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106781
--- Comment #4 from Alexander Monakov ---
(In reply to Martin Liška from comment #3)
> > Also ICEs in ipa-modref when 'noclone' added to 'noinline', a 12/13
> > regression (different cause, needs a separate PR).
>
> Can't reproduce Alexander, p
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, asolokha at gmx dot com,
marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106781
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
For the following testcase, gcc -O2
unsigned foo(const unsigned char *buf, long size);
unsigned bar(const unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106553
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
--- Comment #8 from Alexander Monakov ---
But that's the point of many warnings, isn't it? To help the user understand
what's wrong when the code is bad? And bogus warnings just confuse more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106453
--- Comment #1 from Alexander Monakov ---
Any idea if the following is reasonable? It compiles and achieves the desired
result.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index bdde577dd..d82656678 100644
--- a/gcc/config/i3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422
Alexander Monakov changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Commen
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
On 64-bit x86, straightforward use of SSE 4.2 crc instruction looks like
#include
#include
uint32_t f(uint32_t c, uint64_t *p, size_t n)
{
for (size_t i = 0; i < n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105135
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299
--- Comment #11 from Alexander Monakov ---
Marxin, you've marked this as WAITING, can you please re-evaluate? The nice
testcase from comment #2 is reproducible on trunk as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422
--- Comment #11 from Alexander Monakov ---
A cleaner testcase for jump threading (still ICEs despite presence of
ABNORMAL_DISPATCHER):
void vfork() __attribute__((__leaf__));
void semanage_reload_policy(char *arg, void cb(void)) {
if (!arg) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422
--- Comment #10 from Alexander Monakov ---
The leaf issue is now PR 106437.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106437
--- Comment #1 from Alexander Monakov ---
With the exception of '_exit', exit family of functions (exit, _Exit,
quick_exit) are also marked leaf despite exit and quick_exit invoking
atexit/on_exit/at_quick_exit handlers. Only _Exit is specified
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, asolokha at gmx dot com,
dcb314 at hotmail dot com, hubicka at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422
--- Comment #8 from Alexander Monakov ---
I mean the minimized testcase, the original attachment does execve/_exit after
vfork.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422
--- Comment #7 from Alexander Monakov ---
I think item 2 from comment #3 (jump threading) still needs to be solved
independently of what is decided about item 1 (leaf functions resuming earlier
returns_twice call).
---
The problem with 'leaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422
--- Comment #4 from Alexander Monakov ---
Regarding point 1 above, I should mention that Glibc headers mark both 'vfork'
and 'raise' as leaf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
int main(int argc, char **argv)
{
__label__ loop, end;
void jmp(int c) { goto *(c ? &&loop : &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101347
Alexander Monakov changed:
What|Removed |Added
Summary|[11/12/13 Regression] ICE |[11/12 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101347
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106277
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: ---
In the following code, 'f' is not SLP-vectorized, but 'g' is. From a brief look
at slp2 dump, looks like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700
--- Comment #5 from Alexander Monakov ---
(In reply to Artem S. Tashkinov from comment #4)
> > There should be a note in dmesg when a process segfaults outside of a
> > debugger. If you run wine without gdb, and winedevice.exe crashes, is there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61810
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105513
--- Comment #7 from Alexander Monakov ---
The second sequence is 3 uops vs 1/2 (issued/executed) uops in first, and on
Haswell and Skylake it ties up port 5 for two cycles.
Unclear if you're microbenchmarking latency or throughput, but in any c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105504
--- Comment #5 from Alexander Monakov ---
The strange xmm0 spill issue may affect more code, so I reported an isolated
testcase: PR 105513 (regression vs. gcc-8, the complete testcase in this PR
also does not spill with gcc-8).
: 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-*-*
Minimized from PR 105504.
Compile with -O2 -mtune=haswell -mavx (other
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Created attachment 52933
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52933&action=edit
testcase
Hit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104631
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558
--- Comment #10 from Alexander Monakov ---
As comment #5 mentioned, it is still broken, you just need -fno-inline in
addition to -O2 for the original testcase. Andrew's remark is quite useful for
situations like this, you know :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86948
--- Comment #8 from Alexander Monakov ---
How does your patch expand 64-bit highpart multiply (i.e. with 128-bit full
product) on 32-bit targets?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91972
--- Comment #7 from Alexander Monakov ---
As I understand, only the gcc subdirectory changed implementation language from
C to C++, so, yes (as far as this bug is concerned).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934
--- Comment #14 from Alexander Monakov ---
Zoltan, excuse me, could you please clarify what specifically you are worried
about? Your bug title says "results in UB" and the opening comment said "the
behavior [..] is unpredictable", but as far as I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #18 from Alexander Monakov ---
>From my perspective, the main blocker for a nice and clean solution is lack of
"birth" statements on GIMPLE.
Without them, expansion to RTL would either need to insert initialization at
the top of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #2 from Alexander Monakov ---
That -ftrivial-auto-var-init places an initialization at the point of the
declaration is an implementation detail: there's no initializer in the testcase
itself, so it is valid C and C++ (spelling this o
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
int g(int *);
int f1()
{
switch (0) {
int x;
default:
return g(&x);
}
}
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80053
--- Comment #15 from Alexander Monakov ---
(In reply to Richard Biener from comment #14)
> I think the original asm goto case clearly remains and this is a difficult
> to handle case since the label address only appears as regular input and the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80053
--- Comment #13 from Alexander Monakov ---
Yes, I'm talking only about labels which are potential branch targets, of
course after the jumps have been DCE'd it is not really observable where the
label points to. Unfortunately after four years I do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80053
Alexander Monakov changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80053
Alexander Monakov changed:
What|Removed |Added
Last reconfirmed||2021-07-24
Resolution|INVALI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #10 from Alexander Monakov ---
Is there something wrong or undesirable with making this under -fno-plt (or the
noplt attribute as in your example)?
(after all, it is a kind of PLT-avoidance transformation, just for addressing
rather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #19 from Alexander Monakov ---
Ah, does the issue arise because foo._omp_fn.0 is (before the patch) callable
in two contexts, in one it's called from host and should be 'omp target
entrypoint', and in the other it's called from offlo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #17 from Alexander Monakov ---
Yes, I'd agree normally it's present in the offload table, but ideally if
you're trying to stub out the call, it should not be present in the offload
table.
I think Tobias is saying that on GIMPLE this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100573
--- Comment #14 from Alexander Monakov ---
I would break in gdb on cuModuleGetFunction and
x/s $rdx
to print the failing symbol (it's the third argument to the function).
It seems the "inner" entrypoint (which your patch attempted to nullif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #7 from Alexander Monakov ---
Thanks. I agree that inferring address significance on the linker side is
problematic.
Thinking about your original request, I was about to say that it would be very
reasonable to do under -fno-plt flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #5 from Alexander Monakov ---
Hm, I still don't think I'm misunderstanding what you're saying. I'm familiar
with the ELF standard (and FWIW I have read your blog posts on related
matters). I am responding to this sentiment from the o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #3 from Alexander Monakov ---
I understand what you're saying, but it seems we're talking past each other.
I agree that if a library is linked with any -Bsymbolic* flag, the main
executable is at risk of broken address uniqueness un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100618
--- Comment #3 from Alexander Monakov ---
Furthermore as discussed in bug 100483 this request appears based on a
misunderstanding what the 'semantic-' part of the option is about. It does not
affect assembly/linker-level binding mechanism, so th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100618
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
|UNCONFIRMED
CC||amonakov at gcc dot gnu.org
--- Comment #4 from Alexander Monakov ---
32-bit Linux should also be affected (perhaps with less probability if clock()
is more precise). It is surprising we track time in a 'double'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93031
--- Comment #7 from Alexander Monakov ---
In comment #2 I touched upon a potentially more practical way to offer
-fno-strict-alignment:
Run early work with ABI alignments: compute __alignof correctly, lay out
composite types as required by ABI,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100363
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
||amonakov at gcc dot gnu.org,
||zhroma at gcc dot gnu.org
--- Comment #1 from Alexander Monakov ---
Hi Martin, this is a modulo-scheduling bug; I think you added "Blocks:
sel-sched" by mistake — removing, and Cc'ing Roma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99582
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99728
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: ---
Thread-local variables with hidden visibility don't need to use the
"general-dy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99469
Alexander Monakov changed:
What|Removed |Added
Blocks||82407
--- Comment #2 from Alexander
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99462
--- Comment #3 from Alexander Monakov ---
(for context, the above patch was for PR 98856, but it's based on incorrect
latency analysis, see bug 98856 comment #38 )
Right now schedulers cannot easily split instructions for that purpose, it
would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86096
--- Comment #8 from Alexander Monakov ---
It was fixed on the trunk only, so as the title says it remains an issue on the
gcc-8 branch (which is still open). Bugzilla doesn't have separate resolutions
for different branches, we cannot have this "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98906
--- Comment #6 from Alexander Monakov ---
Ah, -fsanitize=float-cast-overflow catches it, but it needs to be enabled
explicitly (not implied by -fsanitize=undefined). Thank you!
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Created attachment 50097
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50097&action=edit
testcase
The a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98258
--- Comment #10 from Alexander Monakov ---
Thanks for checking. As for this:
> Please, stop suggesting untested workarounds.
Yes, I should have mentioned those are untested. I was typing the response late
at night without access to offloading-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98258
--- Comment #8 from Alexander Monakov ---
(In reply to Chinoune from comment #7)
> $ gfortran-10 -O3 -fopenmp -fopenacc -c bug_omp_acc.f90
> $ gfortran-10 bug_omp_acc.o -lgomp -o test.x
Contrary to my suggestion, you have omitted -fopenacc from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98258
--- Comment #5 from Alexander Monakov ---
One possible solution is -foffload=-fno-openmp
Another possible solution is separate compilation and linking, with only
OpenACC enabled at link step (needs explicit -lgomp):
gfortran -fopenmp -fopenacc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
--- Comment #30 from Alexander Monakov ---
Asm operand binding should work by looking at bound lvalue: "c"(a) binds an
lvalue so if 'a' is a register var the compiler must remember its associated
register; "c"(a+0) binds an rvalue, so what kind o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97734
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97708
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
--- Comment #11 from Alexander Monakov ---
Yes, that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97366
--- Comment #5 from Alexander Monakov ---
afaict LRA is just following IRA decisions, and IRA allocates that pseudo to
memory due to costs.
Not sure where strange cost is coming from, but it depends on x86 tuning
options: with -mtune=skylake we
301 - 400 of 1161 matches
Mail list logo
