[Bug target/101804] New: float_vector_all_ones_operand should be used more

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101804 Bug ID: 101804 Summary: float_vector_all_ones_operand should be used more Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component

[Bug target/101804] float_vector_all_ones_operand should be used more

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101804 H.J. Lu changed: What|Removed |Added Attachment #51270|0 |1 is obsolete|

[Bug middle-end/101809] New: emulated gather capability doesn't support 32-bit target

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101809 Bug ID: 101809 Summary: emulated gather capability doesn't support 32-bit target Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Prio

[Bug middle-end/101809] emulated gather capability doesn't support 32-bit target

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101809 --- Comment #1 from H.J. Lu --- It fails in get_load_store_type: else if (!TYPE_VECTOR_SUBPARTS (vectype).is_constant () || !known_eq (TYPE_VECTOR_SUBPARTS (vectype), TYPE_VECTOR_SUB

[Bug tree-optimization/88531] Index data types when targeting AVX-512 vectorization with gather/scatter

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531 H.J. Lu changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|---

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 88531, which changed state. Bug 88531 Summary: Index data types when targeting AVX-512 vectorization with gather/scatter https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88531 What|Removed

[Bug middle-end/74113] by_pieces_ninsns doesn't support TImode/OImode/XImode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74113 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug middle-end/90773] Improve piecewise operation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90773 --- Comment #18 from H.J. Lu --- *** Bug 74113 has been marked as a duplicate of this bug. ***

[Bug target/63842] x86-64 large PIC model may load the GOT base into the wrong register

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63842 H.J. Lu changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #4 from H.J. Lu --- Dup

[Bug target/63833] REAL_PIC_OFFSET_TABLE_REGNUM is wrong for x86-64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63833 --- Comment #4 from H.J. Lu --- *** Bug 63842 has been marked as a duplicate of this bug. ***

[Bug target/101696] Function multiversioning not usable with new x86-64-v*

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101696 --- Comment #6 from H.J. Lu --- (In reply to Martin Liška from comment #5) > Right now, the x86-64* are defined as aliases to k8: > > {"x86-64", PROCESSOR_K8, CPU_K8, PTA_X86_64_BASELINE, 0, P_NONE}, > {"x86-64-v2", PROCESSOR_K8, CPU_GENERI

[Bug target/101696] Function multiversioning not usable with new x86-64-v*

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101696 --- Comment #8 from H.J. Lu --- Created attachment 51290 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51290&action=edit A patch Try this.

[Bug target/101900] New: -mtune-ctrl=use_vector_fp_converts,use_vector_converts doesn't work with AVX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101900 Bug ID: 101900 Summary: -mtune-ctrl=use_vector_fp_converts,use_vector_converts doesn't work with AVX Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: n

[Bug target/101900] -mtune-ctrl=use_vector_fp_converts,use_vector_converts doesn't work with AVX

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101900 --- Comment #1 from H.J. Lu --- Created attachment 51301 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51301&action=edit A patch

[Bug target/82883] eax register unnecessary consumed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82883 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/91569] Optimisation test case and unnecessary XOR-OR pair instead of MOV.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91569 --- Comment #3 from H.J. Lu --- It is fixed by r11-165.

[Bug target/88496] Unnecessary stack adjustment with -mavx512f

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88496 H.J. Lu changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED

[Bug target/88483] Unnecessary stack alignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88483 --- Comment #7 from H.J. Lu --- *** Bug 88496 has been marked as a duplicate of this bug. ***

[Bug middle-end/101926] [meta-bug] struct/complex argument passing and return should be improved

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926 Bug 101926 depends on bug 88496, which changed state. Bug 88496 Summary: Unnecessary stack adjustment with -mavx512f https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88496 What|Removed |Added --

[Bug target/57601] Vector lowering could use larger modes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57601 H.J. Lu changed: What|Removed |Added Target Milestone|--- |10.0 Status|UNCONFIRMED

[Bug middle-end/88670] [meta-bug] generic vector extension issues

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670 Bug 88670 depends on bug 57601, which changed state. Bug 57601 Summary: Vector lowering could use larger modes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57601 What|Removed |Added -

[Bug target/43147] SSE shuffle merge

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147 H.J. Lu changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com --- Comment

[Bug middle-end/33103] Redundant multiplications for memset

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33103 H.J. Lu changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #4 from H.J. Lu --- Dup

[Bug middle-end/90773] Improve piecewise operation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90773 H.J. Lu changed: What|Removed |Added CC||guillaume.melquiond at inria dot f

[Bug target/43147] SSE shuffle merge

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147 H.J. Lu changed: What|Removed |Added Keywords||patch URL|

[Bug c/100532] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:259

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100532 H.J. Lu changed: What|Removed |Added Summary|[12 Regression] ICE: tree |ICE: tree check: expected |

[Bug ipa/101949] [11/12 Regression] git miscompiled with -flto -fipa-pta since r11-5061-g85ebbabd85e03bdc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101949 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #16 fr

[Bug ipa/101949] [11/12 Regression] git miscompiled with -flto -fipa-pta since r11-5061-g85ebbabd85e03bdc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101949 --- Comment #17 from H.J. Lu --- (In reply to H.J. Lu from comment #16) > On Linux/x86-64 with -m32, r12-3059 gave > > FAIL: gcc.dg/lto/pr101949 c_lto_pr101949_0.o-c_lto_pr101949_1.o execute -O2 > -fipa-pta -flto -flto-partition=1to1 It also f

[Bug target/102021] Redudant mov instruction for broadcast.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102021 H.J. Lu changed: What|Removed |Added Last reconfirmed||2021-08-23 Status|UNCONFIRMED

[Bug target/102027] [11/12 Regression] ABI break when using vector type in function arg/return value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027 --- Comment #4 from H.J. Lu --- (In reply to Andrew Pinski from comment #3) > There are calls to vector_mode_supported_p in stor-layout which changes the > TYPE_MODE of the RECORD_TYPE depending on if vector_mode_supported_p returns > true or no

[Bug target/102027] [11/12 Regression] ABI break when using vector type in function arg/return value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027 --- Comment #5 from H.J. Lu --- (In reply to Andrew Pinski from comment #3) > There are calls to vector_mode_supported_p in stor-layout which changes the It sounds odd to me since vector_mode_supported_p can change overtime. > TYPE_MODE of the

[Bug rtl-optimization/43147] SSE shuffle merge

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147 H.J. Lu changed: What|Removed |Added Assignee|hjl.tools at gmail dot com |unassigned at gcc dot gnu.org

[Bug target/102021] Redudant mov instruction for broadcast.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102021 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/102027] [11/12 Regression] ABI break when using vector type in function arg/return value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102027 --- Comment #8 from H.J. Lu --- (In reply to Richard Biener from comment #7) > Yes, it would be nice to transition away from relying on TYPE_MODE for > argument passing. Does the psABI say anything about this case or is it in > the area of impl

[Bug other/34835] splay-tree doesn't support 64bit value on 32bit host

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34835 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug lto/50568] [4.7 Regression] Massive LTO failures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 Bug 50568 depends on bug 34835, which changed state. Bug 34835 Summary: splay-tree doesn't support 64bit value on 32bit host https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34835 What|Removed |Added ---

[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED

[Bug target/101492] -msse4 -mgeneral-regs-only doesn't work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101492 H.J. Lu changed: What|Removed |Added Target Milestone|12.0|11.3 --- Comment #4 from H.J. Lu --- Also fi

[Bug target/101935] [12 Regression] 538.imagick_r LTO -Ofast regression on Zen2 and Kabylake caused by r12-2666-g29f0e955c97

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101935 H.J. Lu changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com --- Commen

[Bug target/102080] [12 Regression] avx512vl related ICE, on firefox-92 gcc ICEs: in expand_insn, at optabs.c:7946 by r12-2679

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|---

[Bug ipa/102081] [12 regression] ICE building compiler starting with r12-3159

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102081 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED

[Bug target/113837] New: Zeroing unused bits in _BitInt can improve codegen

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837 Bug ID: 113837 Summary: Zeroing unused bits in _BitInt can improve codegen Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Componen

[Bug target/113837] Zeroing unused bits in _BitInt can improve codegen

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837 --- Comment #3 from H.J. Lu --- (In reply to Jakub Jelinek from comment #2) > OT, what is the state of the ia32 _BitInt ABI? I'd really like to enable it > in GCC 14 even for ia32 (and perhaps -mx32 if you care about that case). I think we sho

[Bug target/113837] Zeroing unused bits in _BitInt can improve codegen

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837 --- Comment #5 from H.J. Lu --- (In reply to Jakub Jelinek from comment #1) > Ugh no, please don't. > This is significant ABI change. > First of all, zeroing even for signed _BitInt is very weird, sign extension > for that case is more natural,

[Bug target/113837] Zeroing unused bits in _BitInt can improve codegen

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837 --- Comment #6 from H.J. Lu --- (In reply to Jakub Jelinek from comment #4) > (In reply to H.J. Lu from comment #3) > > (In reply to Jakub Jelinek from comment #2) > > > OT, what is the state of the ia32 _BitInt ABI? I'd really like to enable

[Bug target/113837] Zeroing unused bits in _BitInt can improve codegen

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113837 --- Comment #9 from H.J. Lu --- (In reply to Jakub Jelinek from comment #7) > (In reply to H.J. Lu from comment #5) > > (In reply to Jakub Jelinek from comment #1) > > > Ugh no, please don't. > > > This is significant ABI change. > > > First of

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #3 from H.J. Lu --- Created attachment 57385 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57385&action=edit A patch Try this.

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #7 from H.J. Lu --- (In reply to Florian Weimer from comment #6) > > (In reply to H.J. Lu from comment #4) > > > (In reply to H.J. Lu from comment #3) > > > > Created attachment 57385 [details] > > > > A patch > > > > > > > > Try th

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #19 from H.J. Lu --- (In reply to Florian Weimer from comment #9) > (In reply to H.J. Lu from comment #7) > > > The __tls_get_addr call with the default approach potentially needs to > > > solve > > > the same problem, doesn't it? >

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #21 from H.J. Lu --- (In reply to Florian Weimer from comment #20) > (In reply to H.J. Lu from comment #19) > > (In reply to Florian Weimer from comment #9) > > > (In reply to H.J. Lu from comment #7) > > > > > The __tls_get_addr cal

[Bug tree-optimization/113752] [14 Regression] warning: ‘%s’ directive writing up to 10218 bytes into a region of size between 0 and 10240 [-Wformat-overflow=] since r14-261-g0ef3756adf078c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113752 --- Comment #6 from H.J. Lu --- I can reproduce it with r14-8930-g1e94648ab7b370

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #23 from H.J. Lu --- (In reply to Jakub Jelinek from comment #22) > BTW, does aarch64 dl-tlsdesc.S save SVE/SME register state (I only see fixed > offsets in there), or are those call-saved? > What about floating point registers in x

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 H.J. Lu changed: What|Removed |Added Resolution|--- |MOVED Status|NEW

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #26 from H.J. Lu --- (In reply to Jakub Jelinek from comment #25) > (In reply to H.J. Lu from comment #23) > > > And i386/dl-tlsdesc.S needs to save/restore 387 and SSE regs? > > > > i386 doesn't preserve them in _dl_runtime_resolve

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #28 from H.J. Lu --- (In reply to Jakub Jelinek from comment #27) > (In reply to H.J. Lu from comment #26) > > Even if I compile ia32 glibc with -march=skylake, the _dl_tlsdesc_dynamic > > slow > > path doesn't touch XMM registers at

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #30 from H.J. Lu --- (In reply to Michael Matz from comment #29) > It not only can call malloc. As the backtrace of H.J. shows, it quite > clearly _does_ so :-) > ld.so can only call the malloc implementation internal to ld.so.

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #32 from H.J. Lu --- (In reply to Michael Matz from comment #31) > (In reply to H.J. Lu from comment #30) > > (In reply to Michael Matz from comment #29) > > > It not only can call malloc. As the backtrace of H.J. shows, it quite >

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #33 from H.J. Lu --- (In reply to H.J. Lu from comment #32) > (In reply to Michael Matz from comment #31) > > (In reply to H.J. Lu from comment #30) > > > (In reply to Michael Matz from comment #29) > > > > It not only can call mallo

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #34 from H.J. Lu --- (In reply to H.J. Lu from comment #33) > (In reply to H.J. Lu from comment #32) > > (In reply to Michael Matz from comment #31) > > > (In reply to H.J. Lu from comment #30) > > > > (In reply to Michael Matz from

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #36 from H.J. Lu --- (In reply to Andreas Schwab from comment #35) > ld.so use its internal malloc only during bootstrapping. ___tls_get_addr always uses the internal malloc.

[Bug target/113874] GNU2 TLS descriptor calls do not follow psABI on x86_64-linux-gnu

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874 --- Comment #38 from H.J. Lu --- The new glibc patch set covers both i386 and x86-64: https://patchwork.sourceware.org/project/glibc/list/?series=30854

[Bug target/113909] gcc.target/i386/pr113689-1.c etc. FAIL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113909 --- Comment #1 from H.J. Lu --- It fails on Solaris because of: sol2.h:#undef NO_PROFILE_COUNTERS Just skip these tests for Solaris.

[Bug target/113876] ICE: in ix86_expand_epilogue, at config/i386/i386.cc:10101 with -O -mpreferred-stack-boundary=3 -finstrument-functions -mapxf -mcmodel=large

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113876 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/113876] ICE: in ix86_expand_epilogue, at config/i386/i386.cc:10101 with -O -mpreferred-stack-boundary=3 -finstrument-functions -mapxf -mcmodel=large

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113876 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/113912] New: push2/pop2 generated when stack isn't aligned to 16 bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113912 Bug ID: 113912 Summary: push2/pop2 generated when stack isn't aligned to 16 bytes Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Pri

[Bug target/113912] push2/pop2 generated when stack isn't aligned to 16 bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113912 H.J. Lu changed: What|Removed |Added Target Milestone|--- |14.0 Last reconfirmed|

[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/113912] push2/pop2 generated when stack isn't aligned to 16 bytes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113912 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug middle-end/113988] during GIMPLE pass: bitintlower: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5470

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988 --- Comment #13 from H.J. Lu --- (In reply to Jakub Jelinek from comment #11) > Though, bet that would mean we punt with -mavx -mno-avx2 on 32-byte copies, > because there we support just V8SFmode and not V32QImode. Punt AVX without AVX2 should

[Bug rtl-optimization/91161] [11/12/13/14 Regression] ICE in begin_move_insn, at sched-ebb.c:175

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91161 --- Comment #14 from H.J. Lu --- (In reply to Andrew Pinski from comment #13) > I looked into the IR between GCC 12 and GCC 13 (with the added attributes), > before sched2 there is no difference. So it would good to see what change > "fixes" this

[Bug c/114097] Missed register optimization in _Noreturn functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114097 H.J. Lu changed: What|Removed |Added Last reconfirmed||2024-02-25 Version|unknown

[Bug c/114097] Missed register optimization in _Noreturn functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114097 --- Comment #2 from H.J. Lu --- I couldn't find a way to access the _Noreturn info in backend.

[Bug c/114097] Missed register optimization in _Noreturn functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114097 --- Comment #3 from H.J. Lu --- Created attachment 57524 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57524&action=edit A patch

[Bug target/114097] Missed register optimization in _Noreturn functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114097 H.J. Lu changed: What|Removed |Added Component|c |target Target Milestone|---

[Bug target/114098] New: _tile_loadconfig doesn't work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114098 Bug ID: 114098 Summary: _tile_loadconfig doesn't work Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target A

[Bug target/114098] _tile_loadconfig doesn't work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114098 --- Comment #1 from H.J. Lu --- The problem is that in extern __inline void __attribute__((__gnu_inline__, __always_inline__, __artificial__)) _tile_loadconfig (const void *__config) { __asm__ volatile ("ldtilecfg\t%X0" :: "m" (*((const void

[Bug target/114098] _tile_loadconfig doesn't work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114098 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED

[Bug target/114097] Missed register optimization in _Noreturn functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114097 --- Comment #5 from H.J. Lu --- A patch is submitted: https://patchwork.sourceware.org/project/gcc/list/?series=31294

[Bug target/114097] Missed register optimization in _Noreturn functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114097 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116 H.J. Lu changed: What|Removed |Added Last reconfirmed||2024-02-26 Ever confirmed|0

[Bug gcov-profile/114115] xz-utils segfaults when built with -fprofile-generate (bad interaction between IFUNC and binding?)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0

[Bug gcov-profile/114115] xz-utils segfaults when built with -fprofile-generate (bad interaction between IFUNC and binding?)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115 --- Comment #7 from H.J. Lu --- Created attachment 57544 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57544&action=edit A patch

[Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116 --- Comment #3 from H.J. Lu --- (In reply to Jakub Jelinek from comment #2) > Created attachment 57545 [details] > gcc14-pr114116.patch > > This seems to fix it, so far tested just on the small testcase, back to the > expected backtrace there.

[Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|hjl.tools at gmail dot

[Bug gcov-profile/114115] xz-utils segfaults when built with -fprofile-generate (bad interaction between IFUNC and binding?)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114115 --- Comment #8 from H.J. Lu --- A patch is posted at https://patchwork.sourceware.org/project/gcc/list/?series=31343

[Bug target/114098] _tile_loadconfig doesn't work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114098 H.J. Lu changed: What|Removed |Added Target Milestone|--- |11.5 Resolution|---

[Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116 --- Comment #8 from H.J. Lu --- (In reply to Lukas Grätz from comment #7) > (In reply to H.J. Lu from comment #6) > > (In reply to Jakub Jelinek from comment #5) > > > Yeah. Not to mention, one can call backtrace even if -g0; you just don't > >

[Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116 --- Comment #10 from H.J. Lu --- (In reply to Lukas Grätz from comment #9) > > Not on my computer. When I used -g I got: > > > no_return_to_caller: > .LFB0: > .loc 1 16 1 view -0 > .cfi_startproc > .loc 1 17 3 view .LVU1 >

[Bug target/114116] [14 Regression] Broken backtraces in bootstrapped x86_64 gcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114116 --- Comment #12 from H.J. Lu --- (In reply to Lukas Grätz from comment #11) > > I applied it, double checked, make distclean, configure, make again. > > But your result seems different. Have you applied Jakub Jelinek's patch to No. > save %r

[Bug lto/114337] New: LTO symbol table doesn't include builtin functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337 Bug ID: 114337 Summary: LTO symbol table doesn't include builtin functions Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Componen

[Bug lto/114337] LTO symbol table doesn't include builtin functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337 --- Comment #1 from H.J. Lu --- Maybe linker can deal with it.

[Bug lto/114337] LTO symbol table doesn't include builtin functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114337 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/111165] [13 regression] builtin strchr miscompiles on Debian/x32 with dietlibc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65 --- Comment #15 from H.J. Lu --- We need a testcase which can be reproduced with glibc since the bug may be in other parts of dietlibc.

[Bug target/116174] [14/15 regression] Alignment request is added before endbr with -fcf-protection=branch

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116174 H.J. Lu changed: What|Removed |Added Last reconfirmed||2024-08-02 Ever confirmed|0

[Bug target/116174] [14/15 regression] Alignment request is added before endbr with -fcf-protection=branch since r15-888-gb644126237a1aa

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116174 --- Comment #6 from H.J. Lu --- Created attachment 58876 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58876&action=edit A patch Here is a patch. Hongtao, please take a look and add a testcase. Thanks.

[Bug lto/116361] lto1: fatal error: multiple prevailing defs when using both LTO and OpenMP named critical sections with static libraries

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116361 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com See Also

[Bug lto/116361] lto1: fatal error: multiple prevailing defs when using both LTO and OpenMP named critical sections with static libraries

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116361 --- Comment #3 from H.J. Lu --- The BFD linker checks if a symbol in archive member is real definition, not common, before including the archive member in the link output so that a real definition in archive member can override the common symbol

[Bug lto/116361] lto1: fatal error: multiple prevailing defs when using both LTO and OpenMP named critical sections with static libraries

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116361 H.J. Lu changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #4 from

[Bug lto/116361] lto1: fatal error: multiple prevailing defs when using both LTO and OpenMP named critical sections with static libraries

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116361 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

<    5   6   7   8   9   10   11   12   13   14   >