[Bug middle-end/109484] [Wrong Code][inline-asm] output operands overlap with output

2023-04-12 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484 --- Comment #6 from 。 <570070308 at qq dot com> --- A better testcase: ```c void kkk(void **const pp) { void *temp; __asm__ volatile ( "movq $0xff, %0\n\t" "movq $0xff, %1" :"=r"(temp), "=m"(*pp)

[Bug middle-end/109484] [Wrong Code][inline-asm] output operands overlap with output

2023-04-12 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484 --- Comment #5 from 。 <570070308 at qq dot com> --- (In reply to Richard Biener from comment #3) > (In reply to 。 from comment #2) > > (In reply to Richard Biener from comment #1) > > > but you clobber 'temp' early and fail to indicate that so

[Bug middle-end/109484] [Wrong Code][inline-asm] output operands overlap with output

2023-04-12 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484 --- Comment #2 from 。 <570070308 at qq dot com> --- (In reply to Richard Biener from comment #1) > but you clobber 'temp' early and fail to indicate that so GCC allocates the > same register as part of the "+m" output. The requirements you

[Bug middle-end/109484] New: [Wrong Code][inline-asm] output operands overlap with output

2023-04-12 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484 Bug ID: 109484 Summary: [Wrong Code][inline-asm] output operands overlap with output Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal

[Bug middle-end/108441] [12.2] Maybe missed optimization: loading an 16-bit integer value from .rodata instead of an immediate store

2023-01-18 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108441 --- Comment #1 from 。 <570070308 at qq dot com> --- When compiling with `-fno-tree-slp-vectorize`, it seems to be better: ``` kkk: movl$16, %eax movw%ax, ldap(%rip) ret ```

[Bug middle-end/108441] New: [12.2] Maybe missed optimization: loading an 16-bit integer value from .rodata instead of an immediate store

2023-01-18 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108441 Bug ID: 108441 Summary: [12.2] Maybe missed optimization: loading an 16-bit integer value from .rodata instead of an immediate store Product: gcc Version:

[Bug target/81036] -fcall-saved-X does not work for floating-point registers

2022-11-05 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81036 --- Comment #2 from 。 <570070308 at qq dot com> --- gcc 12.2 -fcall-saved-xmm0 not work too, target and host is x86-64.

[Bug web/107494] New: -ffinite-loops is not enable by default

2022-11-01 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107494 Bug ID: 107494 Summary: -ffinite-loops is not enable by default Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web

[Bug c/105510] error: initializer element is not constant

2022-05-09 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105510 --- Comment #2 from 。 <570070308 at qq dot com> --- (In reply to Richard Biener from comment #1) > As a workaround it works with > > struct Test t=(struct Test){1, {3, 4}}; > > I don't think it your way of writing is actually valid though.

[Bug c/105510] New: [12] error: initializer element is not constant

2022-05-06 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105510 Bug ID: 105510 Summary: [12] error: initializer element is not constant Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug middle-end/105342] [Extended Asm]Memory barrier geater than a function call

2022-04-22 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105342 --- Comment #4 from 。 <570070308 at qq dot com> --- (In reply to Richard Biener from comment #1) > Is it really important though? The doc says that "The asm statement allows you to include assembly instructions directly within C code. This may

[Bug middle-end/105342] New: [Extended Asm]Memory barrier geater than a function call

2022-04-21 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105342 Bug ID: 105342 Summary: [Extended Asm]Memory barrier geater than a function call Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal

[Bug c/105311] New: [12]Still generate memset even with -fno-tree-loop-distribute-patterns

2022-04-19 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105311 Bug ID: 105311 Summary: [12]Still generate memset even with -fno-tree-loop-distribute-patterns Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal

[Bug middle-end/104763] [12 Regression] Generate wrong assembly code

2022-03-07 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104763 --- Comment #8 from 。 <570070308 at qq dot com> --- (In reply to Richard Biener from comment #7) > Note that the case of an endless loop is somewhat special since the store > is dead there since there is no way to reach a load from that point

[Bug c/104805] [12.0] x86_64 Extended asm may use rbp register to input/output even thougth "rbp" is in the clobber list when "rsp" and "rbp" are both in the in the clobber list

2022-03-06 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104805 --- Comment #5 from 。 <570070308 at qq dot com> --- (In reply to Jakub Jelinek from comment #4) > rbp is hard frame pointer, so depending on whether the function needs a > frame pointer (at -O0 I think all functions do), the register isn't >

[Bug c/104805] [12.0] x86_64 Extended asm may use rbp register to input/output even thougth "rbp" is in the clobber list when "rsp" and "rbp" are both in the in the clobber list

2022-03-06 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104805 --- Comment #3 from 。 <570070308 at qq dot com> --- (In reply to Jakub Jelinek from comment #1) > Clobber of "rsp" makes no sense, you can't change the value of the stack > pointer in inline asm without restoring it back before the end of inline

[Bug c/104804] [12.0] x86_64 Extended asm always failed with "+" in Output Operands and wrong error info

2022-03-06 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104804 --- Comment #4 from 。 <570070308 at qq dot com> --- (In reply to Jakub Jelinek from comment #3) > What exactly are you trying to achieve (because & on your testcase makes no > sense at all, the other input is "r" and therefore can't ever match

[Bug c/104805] [12.0] x86_64 Extended asm may use rbp register to input/output even thougth "rbp" is in the clobber list when "rsp" and "rbp" are both in the in the clobber list

2022-03-06 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104805 --- Comment #2 from 。 <570070308 at qq dot com> --- (In reply to Jakub Jelinek from comment #1) > Clobber of "rsp" makes no sense, you can't change the value of the stack > pointer in inline asm without restoring it back before the end of inline

[Bug c/104805] New: [12.0] x86_64 Extended asm may use rbp register to input/output even thougth "rbp" is in the clobber list when "rsp" and "rbp" are both in the in the clobber list

2022-03-06 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104805 Bug ID: 104805 Summary: [12.0] x86_64 Extended asm may use rbp register to input/output even thougth "rbp" is in the clobber list when "rsp" and "rbp" are both in the in the clobber

[Bug c/104804] [12.0] x86_64 Extended asm always failed with "+" in Output Operands and wrong error info

2022-03-06 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104804 --- Comment #2 from 。 <570070308 at qq dot com> --- (In reply to Jakub Jelinek from comment #1) > +m is handled as =m with corresponding m, early clobber for that doesn't > make sense, on one side you require that the input is the same as the >

[Bug c/104804] New: [12.0] x86_64 Extended asm always failed with "+=m" in Output Operands and wrong error info

2022-03-06 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104804 Bug ID: 104804 Summary: [12.0] x86_64 Extended asm always failed with "+=m" in Output Operands and wrong error info Product: gcc Version: 12.0 Status: UNCONFIRMED

[Bug c/104786] [12.0]internal compiler error with extern asm

2022-03-04 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104786 --- Comment #1 from 。 <570070308 at qq dot com> --- gcc-9 crashed too

[Bug c/104786] New: [12.0]internal compiler error with extern asm

2022-03-04 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104786 Bug ID: 104786 Summary: [12.0]internal compiler error with extern asm Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug middle-end/104763] [12.0] Generate wrong assembly code

2022-03-02 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104763 --- Comment #3 from 。 <570070308 at qq dot com> --- (In reply to Jakub Jelinek from comment #2) > Can't reproduce with -O2, with -O1 there are 2 stores instead of 3 > before the endless loop starting with >

[Bug c/104763] [12.0] Generate wrong assembly code

2022-03-02 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104763 --- Comment #1 from 。 <570070308 at qq dot com> --- change `*i=0x0700070007000700;` to `*(volatile size_t *)i=0x0700070007000700;` will fix it. This is my mistake

[Bug c/104763] New: [12.0] Generate wrong assembly code

2022-03-02 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104763 Bug ID: 104763 Summary: [12.0] Generate wrong assembly code Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug c++/98261] Wrong optimize for virtual function

2020-12-13 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98261 --- Comment #3 from 。 <570070308 at qq dot com> --- (In reply to Jonathan Wakely from comment #2) > The bug reporting guidelines tell you to try -fsanitize=undefined before > reporting a bug. That would have told you your code is wrong: > > A >

[Bug c++/98261] New: Wrong optimize for virtual function

2020-12-13 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98261 Bug ID: 98261 Summary: Wrong optimize for virtual function Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug libstdc++/98233] New: A small bug in stl

2020-12-10 Thread 570070308 at qq dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98233 Bug ID: 98233 Summary: A small bug in stl Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: