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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106437
Bug ID: 106437
Summary: Glibc marks functions that resume a returns_twice call
as leaf
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: wrong-code
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
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106421
Bug ID: 106421
Summary: ICE with computed goto from a nested functon
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
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
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106019
Bug ID: 106019
Summary: Surprising SLP failure on trivial code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
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
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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105513
Bug ID: 105513
Summary: [9/10/11/12/13 Regression] Unnecessary SSE spill
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization, ra
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105504
Bug ID: 105504
Summary: Fails to break dependency for vcvtss2sd xmm, xmm, mem
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity:
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
Bug ID: 102276
Summary: -ftrivial-auto-var-init fails to initialize a
variable, causes a spurious warning
Product: gcc
Version: 12.0
Status: UNCONFIRMED
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
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
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
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
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
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
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
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
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
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
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
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99903
Alexander Monakov changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
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
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100225
Alexander Monakov changed:
What|Removed |Added
Blocks|85099 |
CC|
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
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99619
Bug ID: 99619
Summary: fails to infer local-dynamic TLS model from hidden
visibility
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords:
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!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98906
Bug ID: 98906
Summary: [8/9/10/11 Regression] Miscompiles code even at -O1
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
--- Comment #8 from Alexander Monakov ---
No, -msoft-stack-reserve-local is really meant to be in bytes: it may not
exceed the amount of .local memory reserved by CUDA driver (which is just 1-2
KB, unless overridden via cuCtxSetLimit, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97366
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97203
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
Alexander Monakov changed:
What|Removed |Added
Known to fail||9.3.0
Known to work|9.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97291
--- Comment #1 from Alexander Monakov ---
Reshuffling statements and piling up extra abstraction doesn't help solve the
core issue that GIMPLE passes can duplicate any basic block, but basic blocks
of SIMT loop epilogue should be protected from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97194
--- Comment #14 from Alexander Monakov ---
I see, there are more weaknesses than I thought. For CSE (or rather fwprop?) I
was thinking about a simpler case where the extracted-from value is loaded from
memory, but even in trivial cases RTL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97194
--- Comment #11 from Alexander Monakov ---
Yeah, for inserts such tactic would be inappropriate due to bad store
forwarding stalls anyway. As you've shown in earlier comments, inserts have a
very nice generic way to expand them (that does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97194
--- Comment #9 from Alexander Monakov ---
(In reply to Richard Biener from comment #8)
> Note that currently RTL expansion forces a local vector typed variable
> to the stack (instead of allocating a pseudo) when there are
> variable-index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97194
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97127
--- Comment #17 from Alexander Monakov ---
To me this suggests that in fact it's okay to carry the combined form in RTL up
to register allocation, but RA should decompose it to load+fma instead of
inserting a register copy that preserves the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97127
--- Comment #16 from Alexander Monakov ---
Mostly because prior to register allocation the compiler does not naturally see
that x = *mem + a*b will need an extra mov when both 'a' and 'b' are live (as
in that case registers allocated for them
301 - 379 of 379 matches
Mail list logo
