https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #14 from Alexander Monakov ---
Just to clarify, the two testcases added in the quoted commit don't try to
catch the issue discussed here: that the operand is passed in a wrong register.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87733
--- Comment #21 from Alexander Monakov ---
> I could guess the compiler might ignore your inputs/outputs that you specify
> if you don't have any % usages for them.
Are you seriously suggesting that examples in the GCC manual are invalid and
ev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94728
Alexander Monakov changed:
What|Removed |Added
CC||abel at gcc dot gnu.org
Reso
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91972
--- Comment #1 from Alexander Monakov ---
Another reason to have -Wmissing-declarations is that otherwise mismatches of
unused functions are not caught until it's too late (mismatching definition is
assumed to be an overload of the function decla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91972
--- Comment #4 from Alexander Monakov ---
> Why is it missing the static keyword then? (Or alternatively, why isn't it in
> an anonymous namespace?)
Huh? Without the warning developers may simply forget to put the 'static'
keyword. With the war
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95103
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95123
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95103
--- Comment #5 from Alexander Monakov ---
No, this analogy does not work. setjmp both sets up a buffer and receives
control, so it corresponds to both try and catch together. A matching "C++"
code would look like:
> void f3() {
> std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95123
--- Comment #6 from Alexander Monakov ---
Oh, you're probably configuring your compiler with --enable-default-pie. Please
paste the entire gcc -v. I can reproduce the miscompile it if I pass -fpie
-pie.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95435
--- Comment #8 from Alexander Monakov ---
There's no tuning tables for memcmp at all, existing structs cover only memset
and memcpy. So as far as I see retuning memset/memcpy doesn't need to wait for
[1], because there's no infrastructure in plac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92396
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96420
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96633
--- Comment #2 from Alexander Monakov ---
Martin added me to CC so I assume he wants me to chime in.
First of all, I find Nathan's behavior in that gcc@ thread distasteful at best
(but if you ask me, such responses are simply more harm than good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96672
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
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #9 from Alexander Monakov ---
The most pronounced difference for depth=18 seems to be caused by m_b_r
over-allocating by 2x: internally it mallocs 2x of the size given to the
constructor, and then Linux pre-faults those extra pages, p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #14 from Alexander Monakov ---
> It adds 11 bytes to the size given to the constructor (for its internal
> bookkeeping) and then rounds up to a power of two.
What is the purpose of this rounding up?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #18 from Alexander Monakov ---
Huh? malloc is capable of splitting the tail of the last page for reuse in
subsequent small allocations, why not let it do it? It will not be "wasted".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #20 from Alexander Monakov ---
Round up to 64 bytes (typical cache line size).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96942
--- Comment #23 from Alexander Monakov ---
Are you benchmarking with bt_pmr_0thrd (attached in comment #3) with depth=18?
On earlier tests there are other effects in play too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97127
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97127
--- Comment #4 from Alexander Monakov ---
> More so, gcc variant occupies 2 reservation station entries (2 fused uOps) vs
> 4 entries by de-transformed sequence.
I don't think this is true for the test at hand? With base+offset memory
operand th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92151
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92250
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047
--- Comment #16 from Alexander Monakov ---
I'd like to backport this to gcc-9 branch and then close this bug (Richi
already indicated that further backports are not desirable). Thoughts?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92462
--- Comment #10 from Alexander Monakov ---
> atomic_cmpxchg_func tries to cast 'dest' from uint8_t* to int*
I made a typo here, I meant uint32_t rather than uint8_t, and there's no
aliasing violation here as signedness difference is explicitly O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91161
--- Comment #3 from Alexander Monakov ---
With -fno-dce, a NOTE_INSN_DELETED_LABEL appears between the last "real" insn
in the basic block (a sibcall) and a barrier rtx:
(call_insn/u/c 20 19 12 3 (call (mem:QI (symbol_ref:DI ("ni") [flags 0x3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92597
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92768
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92855
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92855
Alexander Monakov changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #6 from Alexan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47877
Alexander Monakov changed:
What|Removed |Added
CC||thiago at kde dot org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47877
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
gcc-10 branch regressed for code that needs bitwise operations on floats:
float f(float x)
{
union {float f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905
--- Comment #4 from Alexander Monakov ---
Perhaps only xmm0 is problematic, as making xmm0 unused by adding a dummy
argument brings back the old spill-free result:
float my_copysign(float dummy, float x, float y)
{
union {float f; unsigned i
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
Consider:
/* Return 0 if a==b, any positive value if a>b, any negative value otherwise.
*/
int foo(int a, int b)
{
int c;
if (__builtin_sub_overflow(a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92953
--- Comment #2 from Alexander Monakov ---
Well, the aarch64 backend does not implement subv4 pattern in the first
place, which would be required for efficient branchy code:
foo:
subsw0, w0, w1
b.vc.LBB0_2
mvn
||amonakov at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #5 from Alexander Monakov ---
Looks like the documentation was added in r230651, overflow patterns for arm in
r239739, and for arm64 in r262890.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92953
--- Comment #4 from Alexander Monakov ---
At least then GCC should try to use cmovno instead of seto-test-cmove for
if-conversion:
foo:
movl%edi, %eax
subl%esi, %eax
notl%eax
orl $1, %eax
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93031
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
(the non-regression part of PR 92905)
libm functions need to manipulate individual bits of float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905
--- Comment #8 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #0)
> Eventually it would be nicer to use SSE bitwise operations for this, for
> example LLVM already generates
> f:
> orps.LCPI0_0(%rip), %xmm0
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
--- Comment #2 from Alexander Monakov ---
Can you attach preprocessed source and double-check command-line flags? I can't
reproduce the problem with lea, and the code does not have explicit prefetch
instructions that I get with -O3 -march=bdver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93056
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
--- Comment #4 from Alexander Monakov ---
The attachment is edited to test insertion_sort, and doesn't call
accumulate_vector at all - looks like you attached a wrong file?
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-12-25
CC||amonakov at gcc dot gnu.org
Summary|ICE: Segmentation fault |[8/9/10 Regression] ICE
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-12-27
CC||amonakov at gcc dot gnu.org
Component|tree-optimization |target
Ever confirmed|0 |1
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #29 from Alexander Monakov ---
(In reply to Alexander Cherepanov from comment #28)
> I see the same even with pure pointers. I guess RTL doesn't care about such
> differences but it means the problem could bite a relatively innocent c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93165
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93039
--- Comment #3 from Alexander Monakov ---
> The question is for which CPUs is it actually faster to use SSE?
In the context of chains where the source and the destination need to be SSE
registers, pretty much all CPUs? Inter-unit moves typically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93039
--- Comment #5 from Alexander Monakov ---
Ah, in that sense. The extra load is problematic in cold code where it's likely
a TLB miss. For hot code: the load does not depend on any previous computations
and so does not increase dependency chains.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93274
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90565
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93278
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91824
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
||2020-01-23
CC||amonakov at gcc dot gnu.org
Summary|Wrong code when returning |[8/9/10 Regression] Wrong
|padded struct |code when returning padded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
--- Comment #19 from Alexander Monakov ---
(In reply to Michael Matz from comment #18)
> represent all accesses indirectly via pointers
Would that be necessary in presence of a verifier that ensures that all
references are dominated by births?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838
--- Comment #5 from Alexander Monakov ---
Ah, indeed, it should be explicitly UB, and the documentation should mention
that as well as that implicit integer promotion does not happen for vector
shifts and other operations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
CC: ch3root at openwall dot com
Target Milestone: ---
Splitting out bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93301
--- Comment #8 from Alexander Monakov ---
Pasted that to new PR 93444 (should have done that right away, sorry).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93444
Alexander Monakov changed:
What|Removed |Added
Summary|[8/9/10 Regression] |[8/9/10 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93444
--- Comment #5 from Alexander Monakov ---
The problem is lifting a conditional access. We don't have an example where
lifting an invariant from an always-executed block in a loop to its preheader
poses a problem.
LLVM adopted an approach where h
||amonakov at gcc dot gnu.org
--- Comment #4 from Alexander Monakov ---
(In reply to Alexander Cherepanov from comment #2)
> > Do you have a testcase were gcc does this optimize without the user adding
> > const and still traps?
>
> No. I'll file a separat
||amonakov at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Alexander Monakov ---
Dup.
*** This bug has been marked as a duplicate of bug 93056 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93056
Alexander Monakov changed:
What|Removed |Added
CC||hehaochen at hotmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572
--- Comment #5 from Alexander Monakov ---
GCC is emitting static_local as @gnu_unique_object, so it should be unified by
the Glibc dynamic linker. You can use 'nm -CD' to check its type after linking
for the main executable and the library to mak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
--- Comment #15 from Alexander Monakov ---
This should not be reproducible with current HEAD because the assert was simply
eliminated. If GCC master definitely fails, can you please provide the exact
diagnostic?
As for 9.2 this is sadly expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93734
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879
Alexander Monakov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
-*-*
Status|UNCONFIRMED |NEW
Keywords||wrong-code
Last reconfirmed||2020-02-14
Component|c |rtl-optimization
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93743
Alexander Monakov changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93744
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745
--- Comment #4 from Alexander Monakov ---
Placement new is translated to a plain pointer assignment on GIMPLE, so
optimizers cannot distinguish programs that had placement new from programs
that did not.
(in C we need memory from malloc to be re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93623
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
||amonakov at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #2 from Alexander Monakov ---
fcmov can only raise an x87 fpu exception on x87 stack underflow, which cannot
happen here.
Even if it did raise FE_INVALID for SNaNs, note that GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934
--- Comment #5 from Alexander Monakov ---
Ah, indeed. fld won't raise FE_INVALID for 80-bit long double, but here
'result' is stored on the stack in 64-bit format.
So: fcmov and 80-bit fldt don't trap, 32-bit flds and 64-bit fldl do.
Somehow RT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934
--- Comment #8 from Alexander Monakov ---
I think regstack is fine as x87 only supports computations in its native 80-bit
format and conversions to/from ieee float/double happen only on memory
loads/stores.
> I suppose a fldt followed by "trunca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56077
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56200
--- Comment #2 from Alexander Monakov 2013-02-04
21:36:38 UTC ---
(In reply to comment #1)
> What happens if you also use -fno-ivopts ?
For me, -fno-ivopts gives a small improvement, but still slower than -O0. I
think the slowdown is r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56200
Alexander Monakov changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56507
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39851
Alexander Monakov changed:
What|Removed |Added
CC||bratsinot at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53265
--- Comment #10 from Alexander Monakov 2013-03-11
16:15:36 UTC ---
(In reply to comment #8)
> Not sure about the warning wording
What about (... "iteration %E invokes undefined behavior", max)?
> plus no idea how to call the warning o
1 - 100 of 1199 matches
Mail list logo
