[Bug d/113125] New: [D] internal compiler error: in make_import, at d/imports.cc:48

2023-12-23 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- Debian testing, amd64, gcc version 13.2.0 (Debian 13.2.0-7) meta.d: ``` module objc.meta; struct A; ``` runtime.d

[Bug d/110516] core.volatile.volatileLoad discarded if result is unused

2023-07-01 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110516 --- Comment #9 from Witold Baryluk --- Thank you for a quick fix Iain!

[Bug d/110516] core.volatile.volatileLoad discarded if result is unused

2023-07-01 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110516 --- Comment #8 from Witold Baryluk --- I see. Point 1 is definitively incorrect. I interpreted asembler wrong: void example.actualRun(ubyte*): pushrbp mov rbp, rsp mov QWORD PTR [rbp-8], rdi nop

[Bug d/110516] New: core.volatile.volatileLoad is broken

2023-07-01 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- gcc 12.2.0 (from Debian stable) and gcc trunk 14.0.0 (in godbolt) tested. core.volatile.volatileLoad simply does not work. 1) It merges loads. 2) It removes unused loads

[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)

2023-06-11 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113 --- Comment #10 from Witold Baryluk --- Thank you Iain. Amazing debugging skills. BTW. `import std;` was because dustmite reduced original import to just that. Original import was `import std.math.algebraic : sqrt;` But you already figured

[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)

2023-06-04 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113 --- Comment #2 from Witold Baryluk --- Also FYI, I was not able to trigger this on DMD64 D Compiler v2.104.0

[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)

2023-06-04 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113 --- Comment #1 from Witold Baryluk --- BTW. Adding return statement in `raytrace`, does not change anything: ``` user@debian:~$ gdc-13 -c -fpreview=dip1021 lup.d user@debian:~$ gdc-13 -c -fpreview=dip1021 lup.d user@debian:~$ gdc-13 -c

[Bug d/110113] New: gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)

2023-06-04 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- Created attachment 55254 --> https://gcc.gnu.org/bugzi

[Bug d/109221] std.math.floor, core.math.ldexp, std.math.poly poor inlining

2023-03-20 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109221 --- Comment #2 from Witold Baryluk --- Interesting enough, GDC 10.2 does inline `poly` instantiation with all the constants.

[Bug d/109221] std.math.floor, core.math.ldexp, std.math.poly poor inlining

2023-03-20 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109221 --- Comment #1 from Witold Baryluk --- PS. LDC 1.23.0 - 1.32.0 produce optimal code. LDC 1.22.0 a bit worse (due to use of x87 codegen), and 1.21 and older fail to inline `ldexp`, but still inline `poly` and `floor` perfectly.

[Bug d/109221] New: std.math.floor, core.math.ldexp, std.math.poly poor inlining

2023-03-20 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- Example: static float sRGB_case4(float x) { // import std.math : exp; return 1.055f * expImpl(x) - 0.055f; // expImpl

[Bug c/108255] New: Repeated address-of (lea) not optimized for size.

2022-12-30 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
Component: c Assignee: unassigned at gcc dot gnu.org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- https://godbolt.org/z/q5sx9e49j void f(int *); int g(int of) { int x = 13; f(); f(); f(); f(); f(); f(); f(); f(); return

[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.

2022-12-30 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560 Witold Baryluk changed: What|Removed |Added CC||witold.baryluk+gcc at gmail dot co

[Bug d/107241] New: std.bitmanip.bigEndianToNative et al not inlined

2022-10-12 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
Component: d Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- gdc fails to inline number of small functions that should fully inline and end in single instruction. on amd64 / x86, for example std.bitmanip.bigEndianToNative

[Bug d/105413] gdc extended assembler cannot constraints r8 - r15

2022-10-08 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105413 --- Comment #3 from Witold Baryluk --- It works. Thank you. Any chance this will be in gcc 12.x? I work a lot on Debian Linux, and I doubt I will have gcc trunk or gcc 13 available any time soon. Also weirdly gcc does not inline this

[Bug d/105413] New: gdc extended assembler cannot constraints r8 - r15

2022-04-27 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
Component: d Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- gcc in C does not support directly register constraints for x86_64 registers r8 - r15. In C this can be done however using local register variables and asm

[Bug d/105360] Inlined lazy parameters / delegate literals, still emitted

2022-04-23 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105360 --- Comment #1 from Witold Baryluk --- https://godbolt.org/z/c8oT6E4cf

[Bug d/105360] New: Inlined lazy parameters / delegate literals, still emitted

2022-04-23 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- ``` extern bool g(); extern void f(int n); void log(lazy int num) { if (g()) { const n = num(); f(n

[Bug c++/103966] std::atomic relaxed load, inc, store sub-optimal codegen

2022-01-10 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103966 --- Comment #2 from Witold Baryluk --- Similarly, dec, add, sub, are affected, as well mul. Example: #include #include uint64_t x; void add_a() { x += 5; } std::atomic y; void add_b_non_atomic() {

[Bug c++/103966] std::atomic relaxed load, inc, store sub-optimal codegen

2022-01-10 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103966 --- Comment #1 from Witold Baryluk --- Current codegen on gcc 12 on 64-bit x86: inc_a(): inc QWORD PTR x[rip] ret inc_b_non_atomic(): mov rax, QWORD PTR y[rip] inc rax mov QWORD PTR

[Bug c++/103966] New: std::atomic relaxed load, inc, store sub-optimal codegen

2022-01-10 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- Both functions below, should compile to the same assembly on x86: #include #include uint64_t x; void inc_a() { x++; } std

[Bug d/100769] [D] memcmp() == 0 for small constant strings not folded

2021-05-26 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100769 Witold Baryluk changed: What|Removed |Added Resolution|FIXED |INVALID

[Bug d/100769] [D] memcmp() == 0 for small constant strings not folded

2021-05-26 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100769 Witold Baryluk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug d/100769] [D] memcmp() == 0 for small constant strings not folded

2021-05-26 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100769 --- Comment #2 from Witold Baryluk --- Hmm. It appears that using `import core.stdc.string : memcmp;` actually resolves the problem. It looks like my manually declaration of memcmp for some reason disabled optimisations for memcmp.

[Bug d/100769] [D] memcmp() == 0 for small constant strings not folded

2021-05-26 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100769 --- Comment #1 from Witold Baryluk --- A typo in the example (godbolt is good), I forgot the `.ptr`: extern(C) int memcmp(const void *s1, const void *s2, size_t n); int recognize3(const char* s) { return memcmp(s, "stract class".ptr, 12)

[Bug d/100769] New: [D] memcmp() == 0 for small constant strings not folded

2021-05-26 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- I expect this D code to be quite optimal, but it isn't. ``` extern(C) int memcmp(const void *s1, const void *s2, size_t n); int

[Bug c/100257] New: poor codegen with vcvtph2ps / stride of 6

2021-04-25 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
Assignee: unassigned at gcc dot gnu.org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- gcc (Compiler-Explorer-Build) 12.0.0 20210424 (experimental) https://godbolt.org/z/n6ooMdnz8 This C code: ``` #include #include #include struct float3 { float

[Bug d/98494] New: libphobos: std.process Config.stderrPassThrough missing

2020-12-31 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- It appears that gdc version of libphobos is somehow lagging in some aspects behind upstream. One of the things I see missing

[Bug d/98457] [d] writef!"%s" doesn't work with MonoTime / SysTick

2020-12-27 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98457 --- Comment #1 from Witold Baryluk --- Godbolt link: https://godbolt.org/z/q3bzhP with gcc trunk 20201217 and a bit more diagnostic /opt/compiler-explorer/gcc-trunk-20201227/lib/gcc/x86_64-linux-gnu/11.0.0/include/d/core/time.d:2405:16: error:

[Bug d/98457] New: [d] writef!"%s" doesn't work with MonoTime / SysTick

2020-12-27 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
iority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- void main() { import std.stdio; import core.time : MonoTime; writef!"%s"(MonoTime.currTime()); } Doesn't compile with gdc 10.2.1: $

[Bug tree-optimization/96275] Vectorizer doesn't take into account bitmask condition from branch conditions.

2020-12-27 Thread witold.baryluk+gcc at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96275 --- Comment #3 from Witold Baryluk --- Thanks for looking into that. I just wanted to update that this still suboptimal in current gcc trunk 20201226. While clang produces superior code.

[Bug c/96275] Vectorizer doesn't take into account bitmask condition from branch conditions.

2020-07-21 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96275 --- Comment #1 from Witold Baryluk --- FYI. clang trunk 12 / 76a0c0ee6ffa9c38485776921948d8f930109674, doesn't do that either: fillArray: # @fillArray testdil, 31 jne .LBB0_8 test

[Bug c/96275] New: Vectorizer doesn't take into account bitmask condition from branch conditions.

2020-07-21 Thread witold.baryluk+gcc at gmail dot com
: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- https://godbolt.org/z/Gfebjd With gcc trunk 20200720 If the loop to be vectorized is inside a if condition

[Bug d/95250] New: [D] ICE instead of error when trying to use bad template type inside template

2020-05-20 Thread witold.baryluk+gcc at gmail dot com
: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- https://godbolt.org/z/xWrXP5 Minimized version ``` module m; import std.traits : Unsigned; void* f(T)(T a, T b

[Bug d/95198] [D] extern(C) private final functions should use 'local' linker attribute

2020-05-20 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95198 --- Comment #3 from Witold Baryluk --- > The main example to demonstrate the current behaviour is correct would be the > following: ``` extern(C) private final int f() { return 5; } auto pubf()() { return f(); } ``` I see, I guess you

[Bug d/95198] [D] extern(C) private final functions should use 'local' linker attribute

2020-05-18 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95198 --- Comment #1 from Witold Baryluk --- BTW. Using: ``` extern(C) private final static int f() { ... } ``` doesn't change anything.

[Bug d/95198] New: [D] extern(C) private final functions should use 'local' linker attribute

2020-05-18 Thread witold.baryluk+gcc at gmail dot com
: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- ``` module t1; extern(C) private final int f() { return 5; } pragma(msg, f.mangleof); ``` `gdc -c t1.d -o t1.o

[Bug d/95174] [D] Incorrect compiled functions involving const fixed size arrays

2020-05-18 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95174 --- Comment #2 from Witold Baryluk --- Doh. Of course. My bad. Sorry. static arrays are value type, dynamic arrays are reference type. Changing signature to: ``` void f(immutable(float[64]) x, float[] o); ``` solves the problem.

[Bug d/95174] New: [D] Incorrect compiled functions involving const fixed size arrays

2020-05-17 Thread witold.baryluk+gcc at gmail dot com
Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- https://explore.dgnu.org/z/LppySp ``` void f(immutable(float[64]) x, float[64] o) { o[] = x[] * 2.0f; } ``` and ``` void f

[Bug d/95173] New: [D] ICE on some architecture targets when trying to use unknown attribute

2020-05-17 Thread witold.baryluk+gcc at gmail dot com
Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- https://explore.dgnu.org/z/bseyKQ ``` import gcc.attribute; @attribute("foo") void f() {} ``` This co

[Bug d/94496] [D] Use aggressive optimizations in release mode

2020-05-15 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94496 --- Comment #3 from Witold Baryluk --- Also about 'nothrow' and Errors. I would really welcome a flag to compiler that simply terminates all threads immidetly any Error is thrown at throw location. They aren't really recoverable. The only

[Bug d/95120] [D] Incorrectly allows fqdn access to imported symbols when doing selective imports.

2020-05-13 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95120 --- Comment #2 from Witold Baryluk --- Created attachment 48530 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48530=edit Minimized example

[Bug d/95120] [D] Incorrectly allows fqdn access to imported symbols when doing selective imports.

2020-05-13 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95120 --- Comment #1 from Witold Baryluk --- Further minimized: == import std.stdio; import std.algorithm.comparison : min; int main() { return std.algorithm.comparison.min(3, 2); } == Removing `import std.stdio;`, results in the same

[Bug d/95120] New: [D] Incorrectly allows fqdn access to imported symbols when doing selective imports.

2020-05-13 Thread witold.baryluk+gcc at gmail dot com
Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- Created attachment 48529 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48529=edit Exam

[Bug d/94496] [D] Use aggressive optimizations in release mode

2020-05-13 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94496 Witold Baryluk changed: What|Removed |Added CC||witold.baryluk+gcc at gmail dot co

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

2019-10-20 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584 --- Comment #20 from Witold Baryluk --- FYI. http://austingroupbugs.net/view.php?id=74#c205 says Note that conversion from a void * pointer to a function pointer as in: fptr = (int (*)(int))dlsym(handle,

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

2019-10-20 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584 Witold Baryluk changed: What|Removed |Added CC||witold.baryluk+gcc at gmail dot co

[Bug tree-optimization/92130] Missed vectorization for iteration dependent loads and simple multiplicative accumulators

2019-10-17 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92130 --- Comment #9 from Witold Baryluk --- Indeed, passing -fno-tree-pre in the first example does make it be vectorized. In the mesh_simple.c this corresponds to ONTHEFLY_CONSTANTS being defined, but USE_LOOP_CONSTANTS being not. The SIMPLIFIED

[Bug tree-optimization/92130] Missed vectorization for iteration dependent loads and simple multiplicative accumulators

2019-10-16 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92130 --- Comment #7 from Witold Baryluk --- Online examples: https://gcc.godbolt.org/z/Nyjty3

[Bug tree-optimization/92130] Missed vectorization for iteration dependent loads and simple multiplicative accumulators

2019-10-16 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92130 --- Comment #6 from Witold Baryluk --- I also tested clang with LLVM 10~svn374655 and it does vectorize the loop properly, even when both frequency and amplitude variables are updated every loop. It still doesn't inline calls to sinf, even if

[Bug tree-optimization/92130] Missed vectorization for iteration dependent loads and simple multiplicative accumulators

2019-10-16 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92130 --- Comment #5 from Witold Baryluk --- As a bonus: static float perlin1d(float x) { float accum = 0.0f; for (int i = 0; i < 8; i++) { accum += powf(0.781f, i) * sinf(x * powf(2.131f, i)); } return accum; } claims to be

[Bug tree-optimization/92130] Missed vectorization for iteration dependent loads and simple multiplicative accumulators

2019-10-16 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92130 --- Comment #4 from Witold Baryluk --- If I reduce minimized test case even further: only frequency update: VECTORIZED: static float perlin1d(float x) { float accum = 0.0f; float amplitude = 1.0f; float frequency = 1.0f; for (int i =

[Bug tree-optimization/92130] Missed vectorization for iteration dependent loads and simple multiplicative accumulators

2019-10-16 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92130 --- Comment #3 from Witold Baryluk --- If only the frequency is updated in the inner loop: frequency *= 2.131f; function fill_data is vectorized: mesh_minimal.c:34:3: optimized: loop vectorized using 64 byte vectors mesh_minimal.c:33:13:

[Bug tree-optimization/92130] Missed vectorization for iteration dependent loads and simple multiplicative accumulators

2019-10-16 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92130 --- Comment #2 from Witold Baryluk --- Added a minimized test case that has only one outer loop, and f and h are removed for simple inlined replacement. Example diagnostic: $ gcc -std=c17 -march=knm -O3 -ffast-math -fassociative-math

[Bug tree-optimization/92130] Missed vectorization for iteration dependent loads and simple multiplicative accumulators

2019-10-16 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92130 --- Comment #1 from Witold Baryluk --- Created attachment 47052 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47052=edit Minimized test case

[Bug tree-optimization/92130] New: Missed vectorization for iteration dependent loads and simple multiplicative accumulators

2019-10-16 Thread witold.baryluk+gcc at gmail dot com
Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: witold.baryluk+gcc at gmail dot com Target Milestone: --- Created attachment 47051 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47051=e

[Bug tree-optimization/63945] Missing vectorization optimization

2019-10-16 Thread witold.baryluk+gcc at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63945 Witold Baryluk changed: What|Removed |Added CC||witold.baryluk+gcc at gmail dot co