[Bug c++/61292] auto keyword to vector reference generates wrong alignment move (causing runtime segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61292 --- Comment #2 from Jim Rees --- Created attachment 47203 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47203&action=edit Reproducer source Compile with -std=c++14 (or higher standard), -O1(not -O0, for easy of comprehending assembly) -march=haswell (or greater, anything that enables __AVX__ support).
[Bug c++/61292] auto keyword to vector reference generates wrong alignment move (causing runtime segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61292 Jim Rees changed: What|Removed |Added CC||jimreesma at gmail dot com --- Comment #3 from Jim Rees --- Reproduced this recently on x86/64-Linux, and did some research: - yes auto seems to strip gcc-style alignment from types. - So does template argument deduction (because the two use the same rules). - Yes, decltype(auto) does not strip the alignment away. - All this appears to be intentional: see gcc source repo, ./gcc/cp/pt.c, line 7926: /* Since type attributes aren't mangled, we need to strip them from template type arguments. */ - The workaround for auto is to avoid using it where your gcc extension attributes matter. Use decltype(auto) if that's useful to you. - The workaround for template argument deduction -- don't pass vector types (with extension attributes) to template parameters. I found that wrapping the vector type in a union or struct works nicely as the mangled name only needs the name of the struct/union so the member type is left intact. If there were to be an actual fix, it might require the mangling format to incorporate gcc extension type attributes, so the stripping of attributes wouldn't be necessary. The template-argument-deduction case is actually something c++ programmers use a lot -- it would be nice if this limitation were better documented. On occasion, one gets the compiler warning about attributes being ignored, but there's no explanation for 1) which attributes, and 2) why that is.
[Bug c/92999] New: [armhf] struct with adjacent __fp16's copies wrongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92999 Bug ID: 92999 Summary: [armhf] struct with adjacent __fp16's copies wrongly Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jimreesma at gmail dot com Target Milestone: --- Created attachment 47523 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47523&action=edit Reproducer source Discovered on "cc (Raspbian 8.3.0-6+rpi1) 8.3.0" -dumpmachine ==> arm-linux-gnueabihf Copying a struct with two adjacent __fp16's effectively copies the second __fp16 onto the first. See attached reproducer code. Upon examining the assembly, it seems to be expecting to return the structure in a single-precision floating point register -- the copy function converts the 2nd field to the single-precision register, then the caller treats that result as the value from both fields. The bug is consistent with -O0 through -O3. The copy function must not be inlined, else the compiler bypasses the copy entirely, so this is an issue with structure copy semantics.
[Bug target/92999] [armhf] struct with adjacent __fp16's copies wrongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92999 --- Comment #1 from Jim Rees --- Reproduced on gcc-9.2 and figured out a fix, though I'm not savvy enough with this code to say it's a complete fix. In (gcc-9.2.0 release) gcc/config/arm/arm.c: 6226a6227 > int ag_mode_size; 6241c6242,6243 < shift = GET_MODE_SIZE(ag_mode) / GET_MODE_SIZE(SFmode); --- > ag_mode_size = MAX (GET_MODE_SIZE (ag_mode), GET_MODE_SIZE (SFmode)); > shift = ag_mode_size / GET_MODE_SIZE(SFmode); Prior to the patch, shift becomes 0 when ag_mode is HFmode, which is what causes every field of the struct to get mapped to the same floating-point register.
[Bug c/93235] New: [AArch64] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93235 Bug ID: 93235 Summary: [AArch64] ICE Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jimreesma at gmail dot com Target Milestone: --- Created attachment 47638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47638&action=edit compile with gcc -O1 -S gcc9_ice.c on aarch64-linux-gnu On aarch64-linux-gnu, ubuntu@ubuntu:~$ gcc -O -c gcc9_ice.c during RTL pass: expand gcc9_ice.c: In function ‘get’: gcc9_ice.c:13:11: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:1010 13 | return u.s; | ~^~ With the -O, or with -O0, no ice, and the emitted code works correctly.
[Bug c/93236] New: [AArch64] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93236 Bug ID: 93236 Summary: [AArch64] ICE Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jimreesma at gmail dot com Target Milestone: --- On aarch64-linux-gnu, ubuntu@ubuntu:~$ gcc -O -c gcc9_ice.c during RTL pass: expand gcc9_ice.c: In function ‘get’: gcc9_ice.c:13:11: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:1010 13 | return u.s; | ~^~ With the -O, or with -O0, no ice, and the emitted code works correctly.
[Bug c/93236] [AArch64] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93236 --- Comment #1 from Jim Rees --- Created attachment 47639 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47639&action=edit sample code
