[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 #19 from rguenther at suse dot de --- On Wed, 21 Feb 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988 > > --- Comment #17 from Jakub Jelinek --- > So, either we could somehow handle that

[Bug tree-optimization/114041] New: wrong code with _BitInt() and -O -fgraphite-identity

cxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-9117-20240221083607-g5772ea772d1-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240221 (experimental) (GCC)

[Bug target/114027] [14] RISC-V vector: miscompile at -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027 --- Comment #4 from Li Pan --- Just did some hacks from the riscv backend, which is to replace the expanding code of reduc_smax_scal_ to the reduc_xor_scal_. diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md index 3b32369f6

[Bug ipa/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476 --- Comment #17 from rguenther at suse dot de --- On Wed, 21 Feb 2024, aldyh at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476 > > --- Comment #8 from Aldy Hernandez --- > (In reply to Richard Biener from comment

[Bug c/114042] New: diagnostics about __builtin_stdc_bit_ceil() mentions __builtin_clzg()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114042 Bug ID: 114042 Summary: diagnostics about __builtin_stdc_bit_ceil() mentions __builtin_clzg() Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: diagnost

[Bug tree-optimization/114041] wrong code with _BitInt() and -O -fgraphite-identity

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114041 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c/114042] diagnostics about __builtin_stdc_bit_ceil() mentions __builtin_clzg()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114042 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-02-22 Status|UNCONFIRM

[Bug rtl-optimization/114044] ICE: in expand_fn_using_insn, at internal-fn.cc:208 with _BitInt() and -O -fno-tree-dce

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114044 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0

[Bug rtl-optimization/114044] New: ICE: in expand_fn_using_insn, at internal-fn.cc:208 with _BitInt() and -O -fno-tree-dce

/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-9117-20240221083607-g5772ea772d1-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240221 (experimental) (GCC)

[Bug target/114027] [14] RISC-V vector: miscompile at -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114027 Li Pan changed: What|Removed |Added CC||pan2.li at intel dot com --- Comment #3 from L

[Bug tree-optimization/114040] wrong code with __builtin_sub_overflow_p() and _BitInt() at -O2 and above

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114040 --- Comment #2 from Andrew Pinski --- ` -fdisable-tree-evrp -fdisable-tree-vrp1` also fixes it. EVRP and VRP1 changes: _3 = IMAGPART_EXPR <_8>; _4 = (_Bool) _3; _5 = (unsigned _BitInt(8671)) _4; into _7 = .SUB_OVERFLOW (_2, 0); _3 =

[Bug tree-optimization/114040] wrong code with __builtin_sub_overflow_p() and _BitInt() at -O2 and above

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114040 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED

[Bug tree-optimization/114040] New: wrong code with __builtin_sub_overflow_p() and _BitInt() at -O2 and above

--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-9117-20240221083607-g5772ea772d1-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240221 (experimental) (GCC)

[Bug target/112299] [14 Regression] Cross compiling to loongarch64-linux-gnuf64 fails because "HAVE_AS_TLS was not declared" after r14-4925-g1b30ef7cea773e

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112299 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by LuluCheng : https://gcc.gnu.org/g:b1cad801dac215b2f594166e69759f33bd791308 commit r13-8352-gb1cad801dac215b2f594166e69759f33bd791308 Author: Xi Ruoyao Date:

[Bug target/112330] [14 Regression] LoongArch: Outputted .align directive may trigger assembler error with GAS 2.41

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112330 --- Comment #19 from GCC Commits --- The releases/gcc-13 branch has been updated by LuluCheng : https://gcc.gnu.org/g:727ae33dae301d9ae5cc753493764ded1876a1ac commit r13-8351-g727ae33dae301d9ae5cc753493764ded1876a1ac Author: Xi Ruoyao Date:

[Bug target/112330] [14 Regression] LoongArch: Outputted .align directive may trigger assembler error with GAS 2.41

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112330 --- Comment #18 from GCC Commits --- The releases/gcc-12 branch has been updated by LuluCheng : https://gcc.gnu.org/g:186381812dce832c95cc5c4ace47b0efb0aee41f commit r12-10171-g186381812dce832c95cc5c4ace47b0efb0aee41f Author: Xi Ruoyao Date:

[Bug target/112299] [14 Regression] Cross compiling to loongarch64-linux-gnuf64 fails because "HAVE_AS_TLS was not declared" after r14-4925-g1b30ef7cea773e

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112299 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by LuluCheng : https://gcc.gnu.org/g:09de4b6b22bd66dacdade65ce633f29f302363b5 commit r12-10172-g09de4b6b22bd66dacdade65ce633f29f302363b5 Author: Xi Ruoyao Date:

[Bug target/100799] Stackoverflow in optimized code on PPC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 --- Comment #24 from Peter Bergner --- (In reply to Jakub Jelinek from comment #23) > if the PowerPC backend maintainers wanted, there could be a similar workaround > on the rs6000 backend side, in the decisions whether the callee can use > the

[Bug libcc1/113977] debug info for alignment of structure is unspecified

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977 Tom Tromey changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tromey at gcc dot gnu.org --- Comm

[Bug target/114017] RISC-V: wrong __riscv_v_intrinsic predefined macro value (14.x)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114017 --- Comment #1 from GCC Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:3688c2b1a604a16b9ff46935770976960016b15c commit r14-9128-g3688c2b1a604a16b9ff46935770976960016b15c Author: Pan Li Date: Wed Feb 21 12:0

[Bug tree-optimization/114010] Unwanted effects of using SSA free lists.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010 --- Comment #7 from ptomsich at gcc dot gnu.org --- (In reply to Manolis Tsamis from comment #5) > On of these happens to precede a relevant vector statement and then > in one case combine does the umlal transformation but in the other not. Plea

[Bug tree-optimization/114010] Unwanted effects of using SSA free lists.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010 --- Comment #6 from ptomsich at gcc dot gnu.org --- (In reply to Manolis Tsamis from comment #5) > On of these happens to precede a relevant vector statement and then > in one case combine does the umlal transformation but in the other not. Plea

[Bug tree-optimization/114030] redundant load due to unions and different size loads

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114030 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Summary|redundant load of

[Bug target/114039] Unroll loops with SSE/AVX intrinsic where an immediate argument is a loop var

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114039 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/113249] RISC-V: regression testsuite errors -mtune=generic-ooo

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113249 --- Comment #7 from GCC Commits --- The master branch has been updated by Edwin Lu : https://gcc.gnu.org/g:bc6b42666cfe1467774b942c7afabe480e3b5ccb commit r14-9123-gbc6b42666cfe1467774b942c7afabe480e3b5ccb Author: Edwin Lu Date: Wed Feb 14

[Bug target/113249] RISC-V: regression testsuite errors -mtune=generic-ooo

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113249 --- Comment #6 from GCC Commits --- The master branch has been updated by Edwin Lu : https://gcc.gnu.org/g:67a29f99cc81384b9245ac5997e47bcf3ff84545 commit r14-9122-g67a29f99cc81384b9245ac5997e47bcf3ff84545 Author: Edwin Lu Date: Wed Feb 14

[Bug c/114039] New: Unroll loops with SSE/AVX intrinsic where an immediate argument is a loop var

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114039 Bug ID: 114039 Summary: Unroll loops with SSE/AVX intrinsic where an immediate argument is a loop var Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity

[Bug ipa/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960 --- Comment #10 from Jakub Jelinek --- So, I believe the really problematic change was r14-2389-g3cce8d98f270f48f which introduced at least in theory the buffer overflow, before that the maximum string length no matter what m_val was was 62 char

[Bug ipa/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960 --- Comment #9 from Jakub Jelinek --- Ok, so what I see is a buffer overflow during 97 sprintf (buffer, "%" PRId64 " (%s, freq %.4f)", m_val, 98 profile_quality_display_names[m_quality], 99 to_sreal_s

[Bug tree-optimization/114038] wrong code with __builtin_mul_overflow_p() and _BitInt() at -O0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114038 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug fortran/114023] complex part%ref of complex named constant array cannot be used in an initialization expression.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114023 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #1 from kargl

[Bug target/113295] [14 Regression] SPEC 2006 416.gamess miscompares on Aarch64 when built with -Ofast -mcpu=native since g:2f46e3578d45ff060a0a329cb39d4f52878f9d5a

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295 --- Comment #6 from Richard Sandiford --- For me the miscompilation is in jkdmem_, where we end up allocating the same registers to both arms of an fcsel. It sounds like it occurs elsewhere too. I have a candidate fix, but need to think a bit

[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org

[Bug fortran/114024] ICE allocate statement with source=cmp%re and z an array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024 --- Comment #3 from kargl at gcc dot gnu.org --- Created attachment 57482 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57482&action=edit patch The attached patch fixes this PR. It includes a new testcase and passes regression testing.

[Bug libgomp/113867] [14 Regression][OpenMP] Wrong code with mapping pointers in structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867 --- Comment #5 from Tobias Burnus --- For: int *q; #pragma omp target device(y5) map(q, q[:5]) GCC currently generates: map(tofrom:q [len: 8]) map(tofrom:*q.4_1 [len: 20]) map(attach:q [bias: 0]) Expected: 'alloc:' instead of 'attach:

[Bug tree-optimization/114038] New: wrong code with __builtin_mul_overflow_p() and _BitInt() at -O0

-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-9091-20240220194451-g0a6a5f8656c-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240221 (experimental) (GCC)

[Bug target/113742] ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx set) in riscv_macro_fusion_pair_p, at config/riscv/riscv.cc:8416 with -O2 -finstrument-functions -mtune=sifive-p600-se

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113742 --- Comment #3 from GCC Commits --- The master branch has been updated by Edwin Lu : https://gcc.gnu.org/g:3232ebd91ed55b275b9d5a6e8355336382c4afd5 commit r14-9118-g3232ebd91ed55b275b9d5a6e8355336382c4afd5 Author: Edwin Lu Date: Tue Feb 20

[Bug c/114029] -Warray-bounds does not warn for const global arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114029 Andrew Pinski changed: What|Removed |Added Component|middle-end |c --- Comment #2 from Andrew Pinski --

[Bug middle-end/114029] -Warray-bounds does not warn for global arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114029 --- Comment #1 from Andrew Pinski --- Without `const`, GCC warns at -O2 also.

[Bug target/108495] [11/12/13/14 Regression] aarch64 ICE with __builtin_aarch64_rndr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108495 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug tree-optimization/111770] predicated loads inactive lane values not modelled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111770 --- Comment #2 from Alex Coplan --- I think to progress this and related cases we need to have .MASK_LOAD defined to zero in the case that the predicate is false (either unconditionally for all targets if possible or otherwise conditionally for

[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #16 from Joseph S. Myers --- I think it's clear that __has_c_attribute(gnu::unused) should only return 1 if the [[gnu::unused]] syntax is actually parsed. (An unavoidable limitation if it might return 1 in pre-C23 modes is that if it

[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #17 from Joseph S. Myers --- The tests that GCC's internal notion of the types agrees with the headers are in gcc.dg/c99-stdint-5.c and gcc.dg/c99-stdint-6.c.

[Bug sanitizer/114037] New: ASAN fork should ensure no unwind is in progress

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114037 Bug ID: 114037 Summary: ASAN fork should ensure no unwind is in progress Product: gcc Version: 12.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Componen

[Bug ipa/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960 --- Comment #8 from Jakub Jelinek --- Ah, not that easily, only in -O0 built compilers, including stage1 of bootstrapped compilers, stage2/3 don't.

[Bug ipa/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960 --- Comment #7 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #6) > Strange, reproduces for me just fine > /volume/tor/opt/notnfs/gcc-bisect/obj/gcc/cc1.r14-9114 -quiet -O > --param=max-inline-recursive-depth=100 > -fdump-tre

[Bug ipa/111960] [14 Regression] ICE: during GIMPLE pass: rebuild_frequencies: SIGSEGV (Invalid read of size 4) with -fdump-tree-rebuild_frequencies-all

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6

[Bug testsuite/114034] Failure of tests gcov-dump-{1,2}.C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034 Andrew Pinski changed: What|Removed |Added Keywords||testsuite-fail Component|targe

[Bug modula2/114026] incorrect location during for loop type check

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114026 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug modula2/114026] incorrect location during for loop type check

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114026 --- Comment #3 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:161a67b2bee84d8fd5ab7711e411f76221c1ea52 commit r14-9116-g161a67b2bee84d8fd5ab7711e411f76221c1ea52 Author: Gaius Mulley Date: Wed

[Bug target/114033] Failure of test darwin-cfstring1.C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033 --- Comment #4 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #2) > This is latest released version: MacOSX13.3.sdk from CLT 15.1 (on macOS > 14.3). > I am attaching the preprocessed source. > > The code from CFData.h th

[Bug target/114036] Test failure of gcov-14.c on darwin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036 --- Comment #3 from Francois-Xavier Coudert --- There's only one symbol we care about here, and its name is known, so I'll make a patch with your suggestion and test it.

[Bug target/114033] Failure of test darwin-cfstring1.C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033 --- Comment #3 from Francois-Xavier Coudert --- Created attachment 57480 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57480&action=edit Preprocessed source

[Bug target/114033] Failure of test darwin-cfstring1.C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033 --- Comment #2 from Francois-Xavier Coudert --- This is latest released version: MacOSX13.3.sdk from CLT 15.1 (on macOS 14.3). I am attaching the preprocessed source. The code from CFData.h that is triggering this is: typedef CF_OPTIONS(CFOpti

[Bug target/114036] Test failure of gcov-14.c on darwin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036 --- Comment #2 from Iain Sandoe --- if there are lots of symbols that need to be undefined .. then one can use an undefined symbols file. Of course, it does not work if we do not know the symbol names at build-time.

[Bug target/114036] Test failure of gcov-14.c on darwin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036 --- Comment #1 from Iain Sandoe --- yeah, there is a better way to do this with ld64 (and presumably dyld-ld), my guess is that this is an anachronism from the ld_classic (v1) days. We can tell the linker it's OK for a symbol to be undefined -

[Bug target/114035] Failure of pr97172-2.c on darwin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114035 Francois-Xavier Coudert changed: What|Removed |Added Target||x86_64-apple-darwin23 Last

[Bug target/114036] Test failure of gcov-14.c on darwin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Target|

[Bug target/114036] New: Test failure of gcov-14.c on darwin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036 Bug ID: 114036 Summary: Test failure of gcov-14.c on darwin Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target

[Bug target/114034] Failure of tests gcov-dump-{1,2}.C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034 --- Comment #1 from Iain Sandoe --- let me see if we're adding an extra in the Darwin specs that is covered elsewhere (sometimes the specs get changed in gcc/gcc.cc and it takes us some time to sync the ones in darwin.h)

[Bug target/114035] New: Failure of pr97172-2.c on darwin

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114035 Bug ID: 114035 Summary: Failure of pr97172-2.c on darwin Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target

[Bug target/114033] Failure of test darwin-cfstring1.C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033 --- Comment #1 from Iain Sandoe --- which actual SDK is this? you should be able to look at the SDKsettings.plist in the root of the SDK, if there's any need to discriminate versions with the same name. (and is it possible to get pre-processed

[Bug target/114034] Failure of tests gcov-dump-{1,2}.C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Target|

[Bug target/114034] New: Failure of tests gcov-dump-{1,2}.C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034 Bug ID: 114034 Summary: Failure of tests gcov-dump-{1,2}.C Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target

[Bug target/114033] Failure of test darwin-cfstring1.C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033 Francois-Xavier Coudert changed: What|Removed |Added Last reconfirmed||2024-02-21 Ever confirmed

[Bug target/114033] New: Failure of test darwin-cfstring1.C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033 Bug ID: 114033 Summary: Failure of test darwin-cfstring1.C Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target

[Bug c++/114031] gcc rejects valid code with pointer to member field cast inside a class not completed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114031 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment

[Bug ipa/108802] [11/12/13/14 Regression] missed inlining of call via pointer to member function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802 --- Comment #7 from Martin Jambor --- I have proposed a patch on the mailing list: https://inbox.sourceware.org/gcc-patches/ri6y1bdx3yg@virgil.suse.cz/T/#u

[Bug ipa/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug ipa/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476 --- Comment #15 from GCC Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:c8742849e22d004b6ab94b3f573639f763e42e3a commit r14-9115-gc8742849e22d004b6ab94b3f573639f763e42e3a Author: Martin Jambor Date:

[Bug target/113915] [14 regression] glibc's _dl_find_object_update_1 miscompiled for armv7a since r14-4365-g0731889c026bfe

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915 --- Comment #13 from Wilco --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646189.html

[Bug tree-optimization/114032] ifcvt may introduce UB calls to __builtin_clz(0)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114032 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1

[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #15 from Jakub Jelinek --- (In reply to Richard Sandiford from comment #14) > I might have misunderstood the suggestion and so be arguing against > something that no-one is suggesting, but I think [[__extension__ …]] should > accept

[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 --- Comment #14 from Richard Sandiford --- I might have misunderstood the suggestion and so be arguing against something that no-one is suggesting, but I think [[__extension__ …]] should accept the same things for all standard versions (C23, pre

[Bug tree-optimization/114032] New: ifcvt may introduce UB calls to __builtin_clz(0)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114032 Bug ID: 114032 Summary: ifcvt may introduce UB calls to __builtin_clz(0) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug preprocessor/114007] gcc chokes on __has_cpp_attribute(clang::unsafe_buffer_usage)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007 Jakub Jelinek changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment

[Bug c++/113987] [12/13/14 Regression] Binding a reference to an uninitialized data member should not cause -Wuninitialized

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #6 from Marek Polacek

[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #15 from Jonathan Wakely --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #14) >> * When checking clang, there were more surprises: >> >> #define __INT8_TYP

[Bug c++/114031] New: gcc rejects valid code with pointer to member field cast inside a class not completed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114031 Bug ID: 114031 Summary: gcc rejects valid code with pointer to member field cast inside a class not completed Product: gcc Version: 13.2.0 Status: UNCONFIRMED

[Bug tree-optimization/114030] New: redundant load of inline function's arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114030 Bug ID: 114030 Summary: redundant load of inline function's arguments Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[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 #18 from Jakub Jelinek --- Created attachment 57479 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57479&action=edit gcc14-pr113988.patch Full untested patch for that variant.

[Bug target/113542] [14 Regression] gcc.target/arm/bics_3.c regression after change for pr111267

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542 Maxim Kuvyrkov changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org

[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 #17 from Jakub Jelinek --- So, I've tried --- gcc/gimple-lower-bitint.cc.jj 2024-02-15 09:52:40.999145971 +0100 +++ gcc/gimple-lower-bitint.cc 2024-02-21 12:48:38.704163901 +0100 @@ -5307,12 +5307,15 @@ bitint_large_huge::lowe

[Bug target/113994] [13/14 Regression] Probable C++ code generation bug with -O2 on s390x platform

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113994 --- Comment #5 from Jakub Jelinek --- Bisected to r13-1268-g8c99e307b20c502e55c425897fb3884ba8f05882 . But that just means the bug was latent before that.

[Bug middle-end/114029] New: -Warray-bounds does not warn for global arrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114029 Bug ID: 114029 Summary: -Warray-bounds does not warn for global arrays Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org

[Bug tree-optimization/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476 --- Comment #14 from Jakub Jelinek --- Ah, ok, in that case it can wait for stage1.

[Bug tree-optimization/114010] Unwanted effects of using SSA free lists.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010 --- Comment #5 from Manolis Tsamis --- Also, I further investigated the codegen difference in the second example (zip + umlal vs umull) and it looks to be some sort of RTL ordering + combine issue. Specifically, when the we expand the RTL for t

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018 --- Comment #18 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #15) > void nexttoward(float32_t, long double) = delete; > void nexttoward(float64_t, long double) = delete; > void nexttoward(float128_t, long double) = delete; >

[Bug tree-optimization/114010] Unwanted effects of using SSA free lists.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010 --- Comment #4 from Manolis Tsamis --- Hi Andrew, Thank for your insights on this. Let me reply to some of your points: (In reply to Andrew Pinski from comment #1) > >The most important case I have observed is that the vectorizer can fail or

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018 --- Comment #17 from Jonathan Wakely --- Or just: template __enable_if_t::value> nexttoward(_Tp, long double) = delete; So that it is present for C++11 and so works when _Float32 and _Float64 names are used instead of the C++23 alias

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018 --- Comment #16 from Jonathan Wakely --- We could also just add: #if __cplusplus > 202002L template void nexttoward(_Tp, long double) = delete; #endif The existing overloads would be preferred for float, double, long double and inte

[Bug tree-optimization/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476 --- Comment #13 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #12) > (In reply to Aldy Hernandez from comment #11) > > Both patches pass test. Up to the release maintainers to decide if they > > want to include them in this re

[Bug libstdc++/114018] std::nexttoward is not implemented for C++23-FP-Types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018 --- Comment #15 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #13) > Then I wonder what was the reason for the final LWG3790 revision, the middle > proposed resolution seems to be much more readable and understandable where >

[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 --- Comment #13 from GCC Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:c8c587b854c9e85fc9ce58c8192d532205f0ee1f commit r14-9104-gc8c587b854c9e85fc9ce58c8192d532205f0ee1f Author: Tamar Christina Date

[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #15 from Jonathan Wakely --- (In reply to r...@cebitec.uni-bielefeld.de from comment #14) > Further research has uncovered some interesting facts: > > * Neither the SysV SPARC psABI (3rd Edition, 1996) nor the original i386 > psAB

[Bug tree-optimization/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1

[Bug tree-optimization/113476] [14 Regression] irange::maybe_resize leaks memory via IPA VRP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476 --- Comment #11 from Aldy Hernandez --- Both patches pass test. Up to the release maintainers to decide if they want to include them in this release. Otherwise, I'll queue them up for later.

[Bug target/113995] ICE: in change_address_1, at emit-rtl.cc:2299 with [[arm::streaming_compatible]] and -march=armv9-a+sve -finstrument-functions -fstack-clash-protection

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113995 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/113220] [aarch64] ICE Segmentation fault with r14-6178-g8d29b7aca15133

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113220 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

  1   2   >