[Bug c/93893] New: MIPS32r2: GCC is unable to figure out that it can use a single INS instruction instead of SLL+OR

Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: siarhei.siamashka at gmail dot com Target Milestone: --- Created attachment 47891 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47891&acti

[Bug tree-optimization/54965] New: [4.6] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965 Bug #: 54965 Summary: [4.6] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining Classification: Unclassified Product: gcc Version: 4.6.4

[Bug tree-optimization/54965] [4.6] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965 --- Comment #1 from Siarhei Siamashka 2012-10-18 01:56:34 UTC --- Created attachment 28476 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28476 pixman-combine-float.i.gz - the original full preprocessed source Applying the changes

[Bug tree-optimization/54965] [4.6 Regression] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965 --- Comment #3 from Siarhei Siamashka 2012-10-18 10:47:51 UTC --- (In reply to comment #2) > void combine_conjoint_xor_ca_float () > { > combine_channel_t j = pd_combine_conjoint_xor, k = > pd_combine_conjoint_xor; > a[0] = k (0

[Bug tree-optimization/54965] [4.6 Regression] sorry, unimplemented: inlining failed in call to 'foo': function not considered for inlining

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54965 --- Comment #5 from Siarhei Siamashka 2012-10-19 00:17:13 UTC --- (In reply to comment #4) > In the above case you probably want big_function_a to have all > calls inlined. You can then conveniently use the flatten attribute: > > void

[Bug target/45094] [arm] wrong instructions for dword move in some cases

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45094 --- Comment #9 from Siarhei Siamashka 2010-12-18 15:43:39 UTC --- Can this bug get a "[4.5 regression]" header please? Even though the bug existed in gcc sources since 2007 (see the link in comment 1), the reported wrong-code problem itself was

[Bug target/45094] [arm] wrong instructions for dword move in some cases

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45094 --- Comment #10 from Siarhei Siamashka 2010-12-18 15:47:12 UTC --- (In reply to comment #9) > see the link in comment 1 Sorry, I mean the link in the original report from Akos: http://repo.or.cz/w/official-gcc.git/commitdiff/f1225f6f

[Bug target/45886] [ARM] support for __ARM_PCS_VFP predefined symbol in gcc 4.5.x would be very nice

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45886 Siarhei Siamashka changed: What|Removed |Added CC||toolchain at gentoo dot org --- Comme

[Bug target/47759] New: _mm_empty() intrinsic fails to serve as a boundary between MMX and x87 code due to optimizations

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47759 Summary: _mm_empty() intrinsic fails to serve as a boundary between MMX and x87 code due to optimizations Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal

[Bug target/50856] New: ARM: suboptimal code for absolute difference calculation

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50856 Bug #: 50856 Summary: ARM: suboptimal code for absolute difference calculation Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED

[Bug target/53659] New: ARM: Using -mcpu=cortex-a9 option results in bad performance for Cortex-A9 processor in C-Ray phoronix benchmark

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53659 Bug #: 53659 Summary: ARM: Using -mcpu=cortex-a9 option results in bad performance for Cortex-A9 processor in C-Ray phoronix benchmark Classification: Unclassified Produ

[Bug c/52355] New: [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355 Bug #: 52355 Summary: [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore Classification: Unclassified Pro

[Bug middle-end/52355] [4.7 regression] address difference between array elements is not considered to be a compile time constant anymore

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355 --- Comment #4 from Siarhei Siamashka 2012-02-23 15:56:24 UTC --- Now I wonder if multidimensional array is still treated as the same array in "When two pointers are subtracted, both shall point to elements of the same array object, or one past t

[Bug middle-end/32074] Optimizer does not exploit assertions

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32074 --- Comment #7 from Siarhei Siamashka 2012-03-29 09:31:37 UTC --- (In reply to comment #6) > Fixed by means of __builtin_unreachable (). But __builtin_unreachable() is not a part of C standard yet? Is there no way to extract some useful informat

[Bug middle-end/32074] Optimizer does not exploit assertions

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32074 --- Comment #8 from Siarhei Siamashka 2012-03-29 10:11:39 UTC --- (In reply to comment #5) > (In reply to comment #4) > > We have __builtin_unreachable() now which should allow for this > > optimization. > > I've been using __builtin_unreachabl

[Bug target/55454] New: [PPC] unaligned memory accesses do not work correctly for vector extensions when using altivec

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55454 Bug #: 55454 Summary: [PPC] unaligned memory accesses do not work correctly for vector extensions when using altivec Classification: Unclassified Product: gcc Version: 4

[Bug c/55457] New: Having some predefined macros to get more information about gcc vector extensions capabilities would be nice

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55457 Bug #: 55457 Summary: Having some predefined macros to get more information about gcc vector extensions capabilities would be nice Classification: Unclassified Product: gcc

[Bug target/55454] [PPC] unaligned memory accesses do not work correctly for vector extensions when using altivec

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55454 --- Comment #2 from Siarhei Siamashka 2012-11-25 18:18:16 UTC --- (In reply to comment #1) > Besides from whether the testcase is valid According to http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html "packed - This attribute, atta

[Bug target/55454] [PPC] unaligned memory accesses do not work correctly for vector extensions when using altivec

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55454 --- Comment #3 from Siarhei Siamashka 2012-11-25 19:32:02 UTC --- Also fails with GCC trunk (gcc version 4.8.0 20120518 (experimental)) The disassembly listing for "init_buffer" function: : 0:7d 80 42 a6 mfvrsave r

[Bug target/55454] [PPC] unaligned memory accesses do not work correctly for vector extensions when using altivec

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55454 --- Comment #4 from Siarhei Siamashka 2012-11-25 21:16:53 UTC --- (In reply to comment #3) > Also fails with GCC trunk (gcc version 4.8.0 20120518 (experimental)) ^^ Sorry, I accidental

[Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46128 --- Comment #6 from Siarhei Siamashka 2012-12-05 00:06:39 UTC --- (In reply to comment #5) > This is really an enhancement request... Is there anything that can be done with this enhancement request? I can see that __ARM_FEATURE_DSP a

[Bug c/55457] Having some predefined macros to get more information about gcc vector extensions capabilities would be nice

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55457 --- Comment #2 from Siarhei Siamashka 2012-12-09 02:33:24 UTC --- (In reply to comment #1) > The whole point of the gcc vector extensions is that you don't need to depend > on what the hardware can do under neath as it should produce good

[Bug tree-optimization/55623] New: [ARM] GCC should not prefer long dependency chains, they inhibit performance on superscalar processors

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55623 Bug #: 55623 Summary: [ARM] GCC should not prefer long dependency chains, they inhibit performance on superscalar processors Classification: Unclassified Product: gcc Ve

[Bug tree-optimization/55623] [ARM] GCC should not prefer long dependency chains, they inhibit performance on superscalar processors

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55623 --- Comment #1 from Siarhei Siamashka 2012-12-09 10:00:59 UTC --- Created attachment 28904 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28904 badsched.c

[Bug middle-end/55623] [ARM] GCC should not prefer long dependency chains, they inhibit performance on superscalar processors

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55623 --- Comment #3 from Siarhei Siamashka 2012-12-09 11:18:56 UTC --- (In reply to comment #2) > This is an ARM (both arm32 and arm64) specific issue due to the shifts being > "free". If you look at the mips assembly, it looks good for a dual

[Bug middle-end/55623] [ARM] GCC should not prefer long dependency chains, they inhibit performance on superscalar processors

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55623 --- Comment #4 from Siarhei Siamashka 2012-12-09 11:21:42 UTC --- Created attachment 28905 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28905 badschedmul.c The testcase, converted to use multiplications. Can be used to demonstrat

[Bug tree-optimization/55614] [4.6/4.7 Regression] vector extensions cause movdqa to be generated for memcpy on unaligned buffer

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55614 --- Comment #8 from Siarhei Siamashka 2012-12-09 20:59:42 UTC --- FWIW, the current gentoo patchset for gcc-4.7.2 contains 10_all_default-fortify-source.patch intended to "Enable -D_FORTIFY_SOURCE=2 by default". It makes this bug non-repro

[Bug target/55634] New: ARM: gcc vector extensions: storing vector to unaligned memory location does not use VST1.8 NEON instruction

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55634 Bug #: 55634 Summary: ARM: gcc vector extensions: storing vector to unaligned memory location does not use VST1.8 NEON instruction Classification: Unclassified

[Bug target/55454] [PPC] unaligned memory accesses do not work correctly for vector extensions when using altivec

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55454 Siarhei Siamashka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug tree-optimization/55614] [4.6/4.7 Regression] vector extensions cause movdqa to be generated for memcpy on unaligned buffer

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55614 --- Comment #9 from Siarhei Siamashka 2012-12-09 22:25:17 UTC --- *** Bug 55454 has been marked as a duplicate of this bug. ***

[Bug target/39469] Calculated values replaced with constants even if the constants cost more than the calculations

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39469 --- Comment #5 from Siarhei Siamashka 2012-12-09 23:31:33 UTC --- (In reply to comment #4) > The ARM backend should do a splitter just like the rs6000 back-end does if it > is faster/smaller to load a constant via the instructions. I'm

[Bug target/39469] Calculated values replaced with constants even if the constants cost more than the calculations

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39469 --- Comment #6 from Siarhei Siamashka 2012-12-10 00:24:12 UTC --- (In reply to comment #5) > (In reply to comment #4) > > The ARM backend should do a splitter just like the rs6000 back-end does if > > it > > is faster/smaller to load a c

[Bug target/43364] Suboptimal code for the use of ARM NEON intrinsic "vset_lane_f32"

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43364 Siarhei Siamashka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug rtl-optimization/29294] 4.1, 4.2 (possibly 4.0?) not finding postmodify address mode on ARM

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29294 Siarhei Siamashka changed: What|Removed |Added CC||siarhei.siamashka at gmail

[Bug rtl-optimization/29294] 4.1, 4.2 (possibly 4.0?) not finding postmodify address mode on ARM

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29294 --- Comment #10 from Siarhei Siamashka 2012-12-20 05:47:30 UTC --- (In reply to comment #9) And some performance measurements (for working with L1 cache): > $ arm-none-eabi-gcc-4.7.2 -O2 -mcpu=cortex-a8 -c test.c > $ objdump -d test.o

[Bug target/53659] ARM: Using -mcpu=cortex-a9 option results in bad performance for Cortex-A9 processor in C-Ray phoronix benchmark

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53659 --- Comment #8 from Siarhei Siamashka --- Since my report predates bug 68664 by several years, shouldn't bug 68664 be a duplicate? In addition, my report was much more detailed, since it also provided a practical use case, showcasing the importan

[Bug tree-optimization/61299] New: [4.9 Regression] Performance regression for the SIMD rotate operation with GCC vector extensions

Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: siarhei.siamashka at gmail dot com A small test: /**/ typedef unsigned int uint32x4 __attribute__ ((vector_size(16))); typedef

[Bug tree-optimization/61299] [4.9/4.10 Regression] Performance regression for the SIMD rotate operation with GCC vector extensions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61299 --- Comment #3 from Siarhei Siamashka --- (In reply to Marc Glisse from comment #2) > That's PR 57233 I believe. Oh, sorry for the duplicate. Don't know how I missed it when searching for similar bugs.

[Bug target/64172] New: [4.9 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: siarhei.siamashka at gmail dot com The attached partially reduced testcase misbehaves at runtime if it is compiled using GCC 4.9.2 on ARM with -O2 optimizations

[Bug target/64172] [4.9 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172 Siarhei Siamashka changed: What|Removed |Added CC||siarhei.siamashka at gmail dot com

[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172 --- Comment #3 from Siarhei Siamashka --- (In reply to Richard Biener from comment #2) > So it works with GCC 4.8? Yes, the testcase works with GCC 4.8. It started to fail only with GCC 4.9 and only on ARM hardware. Originally reported at https:

[Bug target/64172] [4.9/5 Regression] Wrong code with GCC vector extensions on ARM when compiled without NEON

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64172 --- Comment #6 from Siarhei Siamashka --- (In reply to ktkachov from comment #4) > I can't reproduce with -O2 and -mfpu=neon. > Can you please give the exact configuration of your GCC? > The output of 'arm-none-linux-gnueabi-gcc -v' should be goo

[Bug rtl-optimization/64208] New: [4.9 Regression][iwmmxt] ICE: internal compiler error: Max. number of generated reload insns per insn is achieved (90)

Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: siarhei.siamashka at gmail dot com GCC 4.9.2 $ arm-none-linux-gnueabi-gcc -c -O1 -march=iwmmxt

[Bug target/48576] wrong code when accessing variables in a large stack frame

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48576 Siarhei Siamashka changed: What|Removed |Added CC||siarhei.siamashka at gmail

[Bug target/45886] New: [ARM] support for __ARM_PCS_VFP predefined symbol in gcc 4.5.x would be very nice

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45886 Summary: [ARM] support for __ARM_PCS_VFP predefined symbol in gcc 4.5.x would be very nice Product: gcc Version: 4.5.1 URL: http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02186.htm

[Bug target/43725] Poor instructions selection, scheduling and registers allocation for ARM NEON intrinsics

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43725 --- Comment #2 from Siarhei Siamashka 2010-10-04 22:59:56 UTC --- (In reply to comment #1) > So the compiler is correct not to be using vld1 for this code. The memory > format of int32x4_t is defined to be the format of a neon register that has

[Bug middle-end/37734] Missing optimization: gcc fails to reuse flags from already calculated expression for condition check with zero

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37734 Siarhei Siamashka changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comme

[Bug target/43725] Poor instructions selection, scheduling and registers allocation for ARM NEON intrinsics

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43725 --- Comment #5 from Siarhei Siamashka 2010-10-08 14:13:08 UTC --- (In reply to comment #3) > On Mon, 4 Oct 2010, siarhei.siamashka at gmail dot com wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43725 > > >

[Bug target/45886] [ARM] support for __ARM_PCS_VFP predefined symbol in gcc 4.5.x would be very nice

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45886 --- Comment #2 from Siarhei Siamashka 2010-10-11 14:31:29 UTC --- (In reply to comment #1) > Confirmed though I think this isn't an "enhancement" but more a bug because > code can't identify whether -mfloat-abi=hard is chosen by use of a > pre-pr

[Bug middle-end/32820] optimizer malfunction when mixed with asm statements

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32820 Siarhei Siamashka changed: What|Removed |Added CC||siarhei.siamashka at gmail

[Bug middle-end/46164] New: Local variables in specified registers don't work correctly with inline asm operands

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164 Summary: Local variables in specified registers don't work correctly with inline asm operands Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Prio

[Bug middle-end/32820] optimizer malfunction when mixed with asm statements

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32820 --- Comment #8 from Siarhei Siamashka 2010-10-25 10:17:47 UTC --- On the second thought, this bug was about global variables. But my problem is related to the use of local variables. So I have submitted a separate PR46164 about it.

[Bug middle-end/46164] Local variables in specified registers don't work correctly with inline asm operands

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164 --- Comment #1 from Siarhei Siamashka 2010-10-25 10:37:13 UTC --- Created attachment 22144 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22144 proposed testcase for x86_64

[Bug middle-end/46164] Local variables in specified registers don't work correctly with inline asm operands

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46164 Siarhei Siamashka changed: What|Removed |Added Attachment #22144|0 |1 is obsolete|

[Bug target/46128] There is no mechanism for detecting VFP revisions in ARM GCC.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46128 --- Comment #2 from Siarhei Siamashka 2010-10-25 14:43:52 UTC --- (In reply to comment #1) > Note that there may be problems clobbering D registers. See bug 43440. I > don't think Richard Earnshaw's patch >

[Bug target/45886] [ARM] support for __ARM_PCS_VFP predefined symbol in gcc 4.5.x would be very nice

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45886 --- Comment #3 from Siarhei Siamashka 2010-11-12 15:30:24 UTC --- Richard, what would be the appropriate target milestone to get this bug fixed? This needs just a backport of a trivial patch from trunk to 4.5 branch, but delaying this fix increa

[Bug target/49526] New: ARM missed optimization: SMMUL instruction

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49526 Summary: ARM missed optimization: SMMUL instruction Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: u

[Bug target/49526] ARM missed optimization: SMMUL instruction

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49526 --- Comment #1 from Siarhei Siamashka 2011-06-24 22:48:46 UTC --- And clang 2.9 has no problems optimizing this code: $ cat test.c int smmul(int a, int b) { return ((long long)a * b) >> 32; } $ clang -ccc-host-triple arm-none-linux -O2 -mcpu=c

[Bug target/43725] Poor instructions selection, scheduling and registers allocation for ARM NEON intrinsics

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43725 --- Comment #6 from Siarhei Siamashka 2011-06-29 13:35:13 UTC --- Created attachment 24630 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24630 test.c Attached a slightly updated testcase, which can demonstrate unnecessary spills to stack e

[Bug d/104317] New: D language: rt.config module doesn't work as expected in GDC 9/10 (multiple definition linker error)

tatus: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: siarhei.siamashka at gmail dot com Target Milestone: --- The rt.config module provides a set of configuration variables with various ways to ove

[Bug d/104317] D language: rt.config module doesn't work as expected in GDC 9/10 (multiple definition linker error)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104317 --- Comment #1 from Siarhei Siamashka --- An attempted fix for the linker error had been introduced in GDC11 via: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99914 But it made function templates non-inlineable as a side effect: https:/

[Bug d/104317] D language: rt.config module doesn't work as expected in GDC 9/10 (multiple definition linker error)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104317 Siarhei Siamashka changed: What|Removed |Added CC||siarhei.siamashka at gmail dot com

[Bug d/102765] [11 Regression] GDC11 stopped inlining library functions and lambdas used by a binary search one-liner code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102765 --- Comment #4 from Siarhei Siamashka --- First of all, it's my own fault for not just bisecting the GDC code from the day one to figure out all the relevant details many months earlier. The code is large and takes a lot of time to compile, so I

[Bug tree-optimization/103615] New: [8/9 Regression] wrong code with "-O3" or "-O1 -ftree-vectorize" on x86_64-pc-linux-gnu

Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: siarhei.siamashka at gmail dot com Target Milestone: --- A reduced testcase from https://codeforces.com/blog/entry/97433 $

[Bug d/102765] [11 Regression] GDC11 stopped inlining library functions and lambdas used by a binary search one-liner code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102765 --- Comment #3 from Siarhei Siamashka --- Thanks for the explanations. Is there a small example, which demonstrates templates inlining causing a real practical problem for older versions of GDC? A link to a bugtracker, commit message, post in a

[Bug d/102765] New: [11 Regression] GDC11 stopped inlining library functions and lambdas used by a binary search one-liner code

Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: siarhei.siamashka at gmail dot com Target Milestone: --- The performance of the following simple binary search code