[Bug lto/91299] [10/11/12/13 Regression] LTO inlines a weak definition in presence of a non-weak definition from an ELF file

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91299 Alexander Monakov changed: What|Removed |Added Keywords||wrong-code Summary|LTO in

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

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

[Bug target/106952] Missed optimization: x < y ? x : y not lowered to minss

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106952 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

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?

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

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. >

[Bug lto/107014] flatten+lto fails the kernel build

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107014 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug lto/107014] flatten+lto fails the kernel build

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 > >

[Bug lto/107014] flatten+lto fails the kernel build

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

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 --- Comment #15 from Alexander Monakov --- (In reply to Richard Biener from comment #14) > I can't > seem to reproduce any vectorization for your smaller example though. My small C samples omit some detail as they were meant to illustrate what

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 --- Comment #17 from Alexander Monakov --- (In reply to Richard Biener from comment #16) > I do think that since the only way to > preserve expression boundaries is by PAREN_EXPR Yes, but... > that the middle-end > shouldn't care about FAST v

[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 --- Comment #19 from Alexander Monakov --- (In reply to rguent...@suse.de from comment #18) > True - but does that catch the cases people are interested and are > allowed by the FP contraction rules? I'm thinking of > > x = a*b + c*d + e + f;

[Bug tree-optimization/107099] New: uncprop a bit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107099 Bug ID: 107099 Summary: uncprop a bit Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assign

[Bug tree-optimization/107107] [10/11/12/13 Regression] Wrong codegen from TBAA when stores to distinct same-mode types are collapsed?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107107 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug middle-end/107115] Wrong codegen from TBAA under stores that change effective type?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org,

[Bug middle-end/107115] Wrong codegen from TBAA under stores that change effective type?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115 --- Comment #8 from Alexander Monakov --- Just optimizing out the redundant store seems difficult because on some targets scheduling is invoked from reorg (and it relies on alias sets). We need a solution that works for combine too — is it poss

[Bug middle-end/107115] Wrong codegen from TBAA under stores that change effective type?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115 --- Comment #12 from Alexander Monakov --- For reference, the previous whacked mole appears to be PR 106187 (where mems_same_for_tbaa_p comes from).

[Bug tree-optimization/107250] Load unnecessarily happens before malloc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107250 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug target/107250] Load unnecessarily happens before malloc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107250 --- Comment #3 from Alexander Monakov --- Well, obviously because in one function both 'f' and 'tmp' are live across the call, and in the other function only 'f' is live across the call. The difference is literally pushing one register vs. two r

[Bug middle-end/102380] [meta-bug] visibility (fvisibility=* and attributes) issues

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102380 Bug 102380 depends on bug 99619, which changed state. Bug 99619 Summary: fails to infer local-dynamic TLS model from hidden visibility https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99619 What|Removed |Added

[Bug middle-end/99619] fails to infer local-dynamic TLS model from hidden visibility

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99619 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug hsa/86948] Internal compiler error compiling brig.dg/test/gimple/mulhi.hsail

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?

[Bug ipa/95558] [9/10/11/12 Regression] Invalid IPA optimizations based on weak definition

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 :)

[Bug bootstrap/91972] Bootstrap should use -Wmissing-declarations

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).

[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug middle-end/102276] New: -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning

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 Severi

[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning

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

[Bug middle-end/21111] IA-64 NaT consumption faults due to uninitialized register reads

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

[Bug target/93934] Unnecessary fld of uninitialized float stack variable results in ub of valid C++ code

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

[Bug target/87832] AMD pipeline models are very costly size-wise

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832 --- Comment #1 from Alexander Monakov --- Suggested partial fix for the integer-pipe side of the blowup: https://inbox.sourceware.org/gcc-patches/4549f27b-238a-7d77-f72b-cc77df8ae...@ispras.ru/

[Bug other/107353] [13 regression] Numerous ICEs after r13-3416-g1d561e1851c466

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug other/107353] [13 regression] Numerous ICEs after r13-3416-g1d561e1851c466

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353 --- Comment #8 from Alexander Monakov --- (In reply to Arseny Solokha from comment #7) > I have it on x86_64-pc-linux-gnu… Thanks for the info (I assume you don't have any special configure arguments), but that's surprising, I ran bootstrap+reg

[Bug other/107353] [13 regression] Numerous ICEs after r13-3416-g1d561e1851c466

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353 --- Comment #9 from Alexander Monakov --- Actually, latest results from H.J. Lu's periodic x86_64 tester don't exhibit such issues either: https://inbox.sourceware.org/gcc-testresults/20221025065901.6dc0062...@gnu-34.sc.intel.com/T/#u

[Bug c++/107393] New: Wrong TLS model for specialized template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107393 Bug ID: 107393 Summary: Wrong TLS model for specialized template Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority:

[Bug other/107353] [13 regression] Numerous ICEs after r13-3416-g1d561e1851c466

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353 --- Comment #11 from Alexander Monakov --- I've broken out the C++ issue from comment #10 as PR 107393, thanks for the testcase. It's a separate issue from emutls and Fortran ICEs on other targets.

[Bug other/107353] [13 regression] Numerous ICEs after r13-3416-g1d561e1851c466

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353 --- Comment #12 from Alexander Monakov --- ICE on the emutls-3.c testcase isn't related to emutls. Rather, the frontend invokes decl_default_tls_model before attributes are processed, so the first time around we miss the 'common' attribute when

[Bug other/107353] [13 regression] Numerous ICEs after r13-3416-g1d561e1851c466

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353 --- Comment #13 from Alexander Monakov --- As for the Fortran testcases, the issue is again caused by the front-end invoking decl_default_tls_model before assigning DECL_COMMON, this time in fortran/trans-common.cc:build_common_decl. So I guess

[Bug c/107419] New: attributes are ignored when selecting TLS model

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107419 Bug ID: 107419 Summary: attributes are ignored when selecting TLS model Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Pr

[Bug fortran/107421] New: problematic interaction of 'common' and 'threadprivate'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107421 Bug ID: 107421 Summary: problematic interaction of 'common' and 'threadprivate' Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: openmp Sever

[Bug other/107353] frontends sometimes select wrong (too strong) TLS access model

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107353 Alexander Monakov changed: What|Removed |Added Summary|[13 regression] Numerous|frontends sometimes select

[Bug tree-optimization/107505] [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107505 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug target/87832] AMD pipeline models are very costly size-wise

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832 --- Comment #3 from Alexander Monakov --- Followup patches have been posted at https://inbox.sourceware.org/gcc-patches/20221101162637.14238-1-amona...@ispras.ru/

[Bug tree-optimization/107505] [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 2)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107505 Alexander Monakov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug other/107621] spinx generated documents has too much white space on the top

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107621 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 --- Comment #6 from Alexander Monakov --- Sure, but I was talking specifically about the pattern matching introduced by that commit.

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #15 from Alexander Monakov --- Ah, there will be an mfence after the vmovdqa when necessary for an atomic store, thanks (I missed that because the testcase doesn't scan for mfence).

[Bug target/107676] Nonsensical docs for -mrelax-cmpxchg-loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107676 Alexander Monakov changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug target/87832] AMD pipeline models are very costly size-wise

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832 --- Comment #6 from Alexander Monakov --- With these patches on trunk, current situation is: nm -CS -t d --defined-only gcc/insn-automata.o | sed 's/^[0-9]* 0*//' | sort -n | tail -40 2496 r slm_base 2527 r bdver3_load_min_issue_delay 2746 r glm

[Bug target/87832] AMD pipeline models are very costly size-wise

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832 --- Comment #8 from Alexander Monakov --- (In reply to Jan Hubicka from comment #7) > > 53730 r btver2_fp_min_issue_delay > > 53760 r znver1_fp_transitions > > 93960 r bdver3_fp_transitions > > 106102 r lujiazui_core_check > > 106102 r lujiazui_c

[Bug tree-optimization/107715] TSVC s161 for double runs at zen4 30 times slower when vectorization is enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107715 --- Comment #3 from Alexander Monakov --- There's a forward dependency over 'c' (read of c[i] vs. write of c[i+1] with 'i' iterating forward), and the vectorized variant takes the hit on each iteration. How is a slowdown even surprising. For th

[Bug target/87832] AMD pipeline models are very costly size-wise

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832 --- Comment #10 from Alexander Monakov --- (In reply to Jan Hubicka from comment #9) > Actually for older cores I think the manufacturers do not care much. I > still have a working Bulldozer machine and I can do some testing. > I think in Buldoz

[Bug middle-end/107719] 14% regression on TSVC s3113 on znve4 compared to GCC 7.5

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107719 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug tree-optimization/107647] [12/13 Regression] GCC 12.2.0 may produce FMAs even with -ffp-contract=off

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647 --- Comment #15 from Alexander Monakov --- I'm confused about the first hunk in the attached patch: --- a/gcc/tree-vect-slp-patterns.cc +++ b/gcc/tree-vect-slp-patterns.cc @@ -1035,8 +1035,10 @@ complex_mul_pattern::matches (complex_operation_t

[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comm

[Bug middle-end/107879] [13 Regression] ffmpeg-4 test suite fails on FPU arithmetics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107879 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832 --- Comment #21 from Alexander Monakov --- (In reply to Michael_S from comment #19) > > Also note that 'vfnmadd231pd 32(%rdx,%rax), %ymm3, %ymm0' would be > > 'unlaminated' (turned to 2 uops before renaming), so selecting independent > > IVs for

[Bug rtl-optimization/107772] function prologue generated even though it's only needed in an unlikely path

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107772 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #24 from Alexander Monakov --- (In reply to Peter Cordes from comment #23) > But at least on Linux, I don't think there's a way for user-space to even > ask for a page of WT or WP memory (or UC or WC). Only WB memory is easily > ava

[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #26 from Alexander Monakov --- Sure, the right course of action seems to be to simply document that atomic types and built-ins are meant to be used on "common" (writeback) memory, and no guarantees can be given otherwise, because it

[Bug middle-end/107905] 2x slowdown versus CLANG and ICL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107905 Alexander Monakov changed: What|Removed |Added Keywords|ra | CC|

[Bug driver/107787] -Werror=array-bounds=X does not work as expected

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107787 Alexander Monakov changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug middle-end/107905] 2x slowdown versus CLANG and ICL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107905 --- Comment #5 from Alexander Monakov --- Not sure what you don't like about the inputs, they appear quite reasonable. Perhaps GCC's estimation of bb frequencies is off (with profile feedback we achieve good performance). Georgi: you'll likely

[Bug middle-end/107905] 2x slowdown versus CLANG and ICL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107905 --- Comment #6 from Alexander Monakov --- Let me add that Clang supports GCC's -fprofile-{generate,use} flags for compatibility as well.

[Bug tree-optimization/107879] [13 Regression] ffmpeg-4 test suite fails on FPU arithmetics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107879 --- Comment #10 from Alexander Monakov --- If anyone is confused like I was, the commit actually includes a testcase, but the addition is not mentioned in the Changelog. I was sure the server-side receive hook was supposed to reject such incompl

[Bug c/107971] linking an assembler object creates an executable stack

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107971 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug c++/108008] Compiler mis-optimization with posix_memalign

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108008 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug target/87832] AMD pipeline models are very costly size-wise

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832 --- Comment #11 from Alexander Monakov --- Factoring out Lujiazui divider shrinks its tables by almost 20x: 3 r lujiazui_decoder_min_issue_delay 20 r lujiazui_decoder_transitions 32 r lujiazui_agu_min_issue_delay 126 r lujiazui_agu_transitions 3

[Bug tree-optimization/108008] [12 Regression] wrong code with -O3 and posix_memalign

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108008 --- Comment #9 from Alexander Monakov --- I think this is tree-ldist placing memset(sameZ, 0, zPlaneCount) after the loop, overwriting conditional 'sameZ[i] = true' assignments that happen in the loop. For the smaller testcase from comment #6,

[Bug tree-optimization/108008] [12 Regression] wrong code with -O3 and posix_memalign

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108008 --- Comment #10 from Alexander Monakov --- Looks similar to PR 107323, but needs explicit -ftree-loop-distribution to trigger.

[Bug tree-optimization/108076] [10/11/12/13 Regression] GCC with -O3 produces code which fails to link

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108076 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org

[Bug rtl-optimization/108117] Wrong instruction scheduling on value coming from abnormal SSA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug rtl-optimization/108117] Wrong instruction scheduling on value coming from abnormal SSA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117 Alexander Monakov changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVA

[Bug rtl-optimization/108117] Wrong instruction scheduling on value coming from abnormal SSA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117 --- Comment #9 from Alexander Monakov --- (In reply to Feng Xue from comment #8) > In another angle, because gcc already model control flow and SSA web for > setjmp/longjmp, explicit volatile specification is not really needed. That covers GIM

[Bug tree-optimization/108129] New: nop_atomic_bit_test_and_p is too bloated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108129 Bug ID: 108129 Summary: nop_atomic_bit_test_and_p is too bloated Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-op

[Bug rtl-optimization/108117] Wrong instruction scheduling on value coming from abnormal SSA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117 --- Comment #12 from Alexander Monakov --- Shouldn't there be another bug for the sched1 issue specifically? In absence of abnormal control flow, extending lifetimes of pseudos across calls is still likely to be a pessimization.

[Bug rtl-optimization/108117] Wrong instruction scheduling on value coming from abnormal SSA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117 Alexander Monakov changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #14 from Alexande

[Bug rtl-optimization/108117] Wrong instruction scheduling on value coming from abnormal SSA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117 Alexander Monakov changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #15 from Alex

[Bug rtl-optimization/57067] Missing control flow edges for setjmp/longjmp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57067 --- Comment #9 from Alexander Monakov --- *** Bug 108117 has been marked as a duplicate of this bug. ***

[Bug middle-end/108140] ICE expanding __rbit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108140 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org

[Bug rtl-optimization/108117] Wrong instruction scheduling on value coming from abnormal SSA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117 --- Comment #16 from Alexander Monakov --- Draft patch for the sched1 issue: https://inbox.sourceware.org/gcc-patches/cf62c3ec-0a9e-275e-5efa-2689ff1f0...@ispras.ru/T/#m95238afa0f92daa0ba7f8651741089e7cfc03481

[Bug middle-end/108209] New: goof in genmatch.cc:commutative_op

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108209 Bug ID: 108209 Summary: goof in genmatch.cc:commutative_op Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end

[Bug middle-end/108209] goof in genmatch.cc:commutative_op

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108209 --- Comment #1 from Alexander Monakov --- Keeping notes as I go... Duplicated checks for 'op0' in lower_for are duplicated.

[Bug target/108229] New: [13 Regression] unprofitable STV transform

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108229 Bug ID: 108229 Summary: [13 Regression] unprofitable STV transform Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: targe

[Bug target/108229] [13 Regression] unprofitable STV transform since r13-4873-g0b2c1369d035e928

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108229 --- Comment #3 from Alexander Monakov --- Thank you! I considered this unprofitable for these reasons: 1. As you said, the code grows in size, but the speed benefit is not clear. 2. The transform converts load+add operations in a loop, and the

[Bug middle-end/108256] New: Missing integer overflow instrumentation when assignment LHS is narrow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108256 Bug ID: 108256 Summary: Missing integer overflow instrumentation when assignment LHS is narrow Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal

[Bug target/108315] New: -mcpu=power10 changes ABI

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 Bug ID: 108315 Summary: -mcpu=power10 changes ABI Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ABI, wrong-code Severity: normal Priority: P3

[Bug rtl-optimization/108318] Floating point calculation moved out of loop despite fesetround

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108318 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug target/105504] New: Fails to break dependency for vcvtss2sd xmm, xmm, mem

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: n

[Bug rtl-optimization/105513] New: [9/10/11/12/13 Regression] Unnecessary SSE spill

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: no

[Bug target/105504] Fails to break dependency for vcvtss2sd xmm, xmm, mem

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).

[Bug target/105513] [9/10/11/12/13 Regression] Unnecessary SSE spill since r9-5748-g1d4b4f4979171ef0

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

[Bug target/61810] init-regs.c papers over issues elsewhere

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61810 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comm

[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m

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

[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug c/105863] RFE: __attribute__((incbin("file"))) or __builtin_incbin("file")

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105863 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

[Bug tree-optimization/106019] New: Surprising SLP failure on trivial code

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 Pr

[Bug target/106277] missed-optimization: redundant movzx

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106277 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Com

<    1   2   3   4   5   >