[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #4 from Khem Raj --- I dont think its a bug per-se, I am looking for fixing it right way. Should I pass a non-default value via gcc cmdline or adjust the size expectations in code.

[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #6 from Khem Raj --- this is from mongodb.

[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #8 from Khem Raj --- So in this case if I change static_assert(sizeof(decltype(_together)) <= hardware_constructive_interference_size, "cache line spill"); to static_assert(sizeof(decltype(_together)) <

[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #9 from Khem Raj --- how does something like this look ? #include #include #include #include #ifdef __cpp_lib_hardware_interference_size using std::hardware_constructive_interference_size; using std::hardware_destructiv

[Bug target/105251] static assert sizeof(decltype(_together)) <= hardware_constructive_interference_size fails with gcc12

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105251 --- Comment #11 from Khem Raj --- yes thanks. I have done so https://jira.mongodb.org/browse/SERVER-65664

[Bug middle-end/105312] New: attribute__((optimize("-O3"))) stress_matrix_xy_identity compiling stress-ng for arm

NCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: raj.khem at gmail dot com Target Milestone: --- GCC 12 gets into an ICE when compiling this testcase (reduced from stress-ng) typ

[Bug middle-end/105316] New: Seemingly bogus -Wdangling-pointer from ppc/ppc64 kernel printk with gcc12

: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: raj.khem at gmail dot com Target Milestone: --- I have reduced this case from ppc kernel 5.15, this breaks the kernel build as the warning is treated as error

[Bug middle-end/105316] Seemingly bogus -Wdangling-pointer from ppc/ppc64 kernel printk with gcc12

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105316 --- Comment #2 from Khem Raj --- ah yes. Thanks

[Bug tree-optimization/105312] [11 Regression] ICE in gimple_expand_vec_cond_expr on arm-linux since r12-834-ga6eacbf1055520

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105312 --- Comment #8 from Khem Raj --- yeah I can verify that the ICE is gone.

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061 Khem Raj changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #17

[Bug target/113986] [14 regression] Build failure on aarch64-linux-musl or if ifunc support is disabled (error: 'export_load_16' aliased to undefined symbol 'libat_load_16')

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113986 Khem Raj changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #5

[Bug driver/110901] New: -march does not override -mcpu on aarch64

: driver Assignee: unassigned at gcc dot gnu.org Reporter: raj.khem at gmail dot com Target Milestone: --- As per https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#index-mcpu When -march is used then relevant part of -mcpu are overridden by that. However this seems to be not

[Bug target/110901] -march does not override -mcpu on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110901 --- Comment #2 from Khem Raj --- (In reply to Andrew Pinski from comment #1) > Order matters. In this case -march is after -mcpu ... It does not seem to be effective in this case. I tried to specify -mcpu after -march and vice-versa, result is

[Bug target/115042] New: valgrind test fails to compile on armv7

: target Assignee: unassigned at gcc dot gnu.org Reporter: raj.khem at gmail dot com Target Milestone: --- Created attachment 58180 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58180&action=edit testcase Attached test comes from valgrind, it worked fine with gcc-13

[Bug driver/115368] New: Wrong order of gcc include paths on musl systems

Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: raj.khem at gmail dot com Target Milestone: --- When doing cross-builds targeting musl based systems, gcc driver adds -iprefix to cc1/cc1plus call, the path is based on gcc cross compiler installation location, and

[Bug driver/115368] Wrong order of gcc include paths on musl systems

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115368 --- Comment #1 from Khem Raj --- Created attachment 58366 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58366&action=edit potential fix This patch uses -idirafter instead of -iprefix when building for musl. This fixes the issue as the se

[Bug driver/115368] Wrong order of gcc include paths on musl systems

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115368 Khem Raj changed: What|Removed |Added Attachment #58366|0 |1 is obsolete|

[Bug middle-end/117342] .base64 emitted when gas doesn't support it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342 --- Comment #18 from Khem Raj --- (In reply to Andrew Pinski from comment #16) > (In reply to Khem Raj from comment #15) > > My problem was that I made the version to be 15.1.0 > > How? in yocto, we copy the tools/symlinks into locations manua

[Bug middle-end/117342] .base64 emitted when gas doesn't support it

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342 Khem Raj changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #15

<    1   2