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=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=97203
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
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=97366
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
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
--- 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=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
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=97194
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
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
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
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
--- 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=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 #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 #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=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=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=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
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
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
--- 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=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=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=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 #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 #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 #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=100363
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
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=99903
Alexander Monakov changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
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=99582
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=100225
Alexander Monakov changed:
What|Removed |Added
Blocks|85099 |
CC|
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=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=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=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=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=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=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=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=112367
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
--- Comment #11 from Alexander Monakov ---
(In reply to Richard Biener from comment #10)
> And this conservatively has to apply to all FP divisions where we might infer
> "nonnegative" unless we can also infer !zerop?
Yes, I think the logic in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111701
Bug ID: 111701
Summary: [11/12/13/14 Regression] wrong code for
__builtin_signbit(x*x)
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #3 from Alexander Monakov ---
Sorry, the second half of my comment is confusing. To clarify, ASan works fine
for TLS data (the compiler knows that TLS base is at fs:0; libsanitizer uses
some hacks to initialize shadow for TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694
--- Comment #7 from Alexander Monakov ---
No backport for gcc-13 planned?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111768
--- Comment #5 from Alexander Monakov ---
I think it's similar to attempting -march=native under distcc, which is already
warned about on Gentoo wiki: https://wiki.gentoo.org/wiki/Distcc
The difference here is that Intel so far decided to make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111210
Alexander Monakov changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111210
--- Comment #4 from Alexander Monakov ---
The testcase is small enough to notice the issue by inspection.
Note that you get the "expected" answer with -fno-strict-aliasing, and as
explained in https://gcc.gnu.org/bugs/ it is one of the things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #6 from Alexander Monakov ---
Thanks.
i5-1335U has two "performance cores" (with HT, four logical CPUs) and eight
"efficiency cores". They have different micro-architecture. Are you binding the
benchmark to some core in particular?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=01
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
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=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=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=105688
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
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=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=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=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
Summary|[11/12/13 Regression] ICE |[11/12 Regression] ICE in
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 #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=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=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=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 #10 from Alexander Monakov ---
The leaf issue is now PR 106437.
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=105135
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
---
1 - 100 of 373 matches
Mail list logo
