[Bug tree-optimization/114551] [14 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2944

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551 --- Comment #7 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e152177b362143465e2b9d721ea632cae3f13445 commit r14-9781-ge152177b362143465e2b9d721ea632cae3f13445 Author: Richard Biener Date:

[Bug tree-optimization/114551] [13 Regression] wrong code at -O3 on x86_64-linux-gnu since r14-2944

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551 Richard Biener changed: What|Removed |Added Priority|P1 |P2 Known to work|

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 --- Comment #10 from uecker at gcc dot gnu.org --- Yes, this makes sense. I will try this. (I tried this approach already but I did not get this work, probably because something I missed). Otherwise one could try setting TYPE_CANONICAL only ba

[Bug c++/66766] static class member function returning auto is not assignable to a function type reference

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66766 Andrew Pinski changed: What|Removed |Added Summary|Reference to an “auto” |static class member |f

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 Richard Biener changed: What|Removed |Added Keywords||lto --- Comment #11 from Richard Biene

[Bug rtl-optimization/114575] [14 Regression] SVE addressing modes broken since g:839bc42772ba7af66af3bd16efed4a69511312ae

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114575 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #2 from Richard Biener

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 --- Comment #12 from Jakub Jelinek --- Not an expert on TYPE_CANONICAL, but my understanding is that non-NULL TYPE_CANONICAL is just an optimization to speed up type comparisons (but it seems c-typeck.cc doesn't actually use that, so it is mainl

[Bug target/114576] [14 regression] VEX-prefixed AES instruction without AVX enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114576 Richard Biener changed: What|Removed |Added Priority|P3 |P1

[Bug target/114578] New: [13/14 Regression] memory hog, virtual memory exhausted, building a c++ file on arm-linux-gnueabihf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114578 Bug ID: 114578 Summary: [13/14 Regression] memory hog, virtual memory exhausted, building a c++ file on arm-linux-gnueabihf Product: gcc Version: 13.2.1 Status: UNCONFIR

[Bug tree-optimization/110501] [13/14 regression] Invalid -Wuse-after-free / realloc with a store/load happening

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110501 Richard Biener changed: What|Removed |Added Priority|P3 |P2

[Bug tree-optimization/110501] [13/14 regression] Invalid -Wuse-after-free / realloc with a store/load happening

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110501 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.3 --- Comment #9 from Richard Biene

[Bug middle-end/110972] 13% fatigue regression with r14-3078-gd9f3ea61fe36e2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110972 Richard Biener changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #13

[Bug tree-optimization/114485] [13/14 Regression] Wrong code with -O3 -march=rv64gcv on riscv or `-O3 -march=armv9-a` for aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 --- Comment #14 from Martin Uecker --- (In reply to Jakub Jelinek from comment #12) > Not an expert on TYPE_CANONICAL, but my understanding is that non-NULL > TYPE_CANONICAL is just an optimization to speed up type comparisons (but it > seems c-

[Bug tree-optimization/114485] [13/14 Regression] Wrong code with -O3 -march=rv64gcv on riscv or `-O3 -march=armv9-a` for aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485 --- Comment #10 from Richard Biener --- /* Init_expr will be update by vect_update_ivs_after_vectorizer, if niters or vf is unkown: For shift, when shift mount >= precision, there would be UD. For mult, don't known how to genera

[Bug tree-optimization/114485] [13/14 Regression] Wrong code with -O3 -march=rv64gcv on riscv or `-O3 -march=armv9-a` for aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485 --- Comment #11 from Richard Biener --- Created attachment 57871 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57871&action=edit patch I'm testing this (on x86_64-linux).

[Bug target/99195] Optimise away vec_concat of 64-bit AdvancedSIMD operations with zeroes in aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to work||14.0 Resolution|---

[Bug middle-end/29231] need a way to produce trampolines not on the stack

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29231 Iain Sandoe changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug tree-optimization/114555] ICE: definition in block 14 does not dominate use in block 15 at -O and above with _BitInt() bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114555 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:48530efdcccb154d3ed200246384edc162debc5d commit r14-9783-g48530efdcccb154d3ed200246384edc162debc5d Author: Jakub Jelinek Date: T

[Bug c++/114537] bit_cast does not work NSDMI of bitfields

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114537 --- Comment #4 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1baec8deb014b8a7da58879a407a4c00cdeb5a09 commit r14-9784-g1baec8deb014b8a7da58879a407a4c00cdeb5a09 Author: Jakub Jelinek Date: T

[Bug middle-end/114579] New: RTL expansion add_scope_conflicts is slow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114579 Bug ID: 114579 Summary: RTL expansion add_scope_conflicts is slow Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle

[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480 Richard Biener changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Commen

[Bug tree-optimization/114555] ICE: definition in block 14 does not dominate use in block 15 at -O and above with _BitInt() bitfield

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114555 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug middle-end/114579] RTL expansion add_scope_conflicts is slow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114579 --- Comment #1 from Richard Biener --- Created attachment 57872 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57872&action=edit patch Doing this no longer will be able to handle A conflicts B, B conflicts C but A does not conflict C. Bu

[Bug libstdc++/93672] [11/12/13/14 Regression] std::basic_istream::ignore hangs if delim MSB is set

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672 Jonathan Wakely changed: What|Removed |Added Summary|std::basic_istream::ignore |[11/12/13/14 Regression]

[Bug c++/114580] New: Bogus warning on if constexpr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114580 Bug ID: 114580 Summary: Bogus warning on if constexpr Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assi

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 Arnaud Charlet changed: What|Removed |Added CC||charlet at gcc dot gnu.org --- Comment

[Bug c++/114580] Bogus warning on if constexpr

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114580 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2024-04-04 Assignee|unassigne

[Bug middle-end/29231] need a way to produce trampolines not on the stack

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29231 --- Comment #8 from Iain Sandoe --- A secondary comment - the wiring up of the built-ins that allocate/deallocate trampoline entries makes the underlying mechanism opaque to the middle end consumer. So, although the current example implementatio

[Bug middle-end/110773] [Aarch64] crash (SIGBUS) due to atomic instructions on under-aligned memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773 Sainan changed: What|Removed |Added CC||sainan+gcc.bugzilla@calamit

[Bug middle-end/110773] [Aarch64] crash (SIGBUS) due to atomic instructions on under-aligned memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773 --- Comment #4 from Wilco --- (In reply to Sainan from comment #3) > I seem to be having a related issue, although in my case the struct looks > like this: > > template > struct Data > { > T* data; > std::atomic_uint count; > bool

[Bug tree-optimization/114485] [13/14 Regression] Wrong code with -O3 -march=rv64gcv on riscv or `-O3 -march=armv9-a` for aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485 --- Comment #12 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:85621f98d245004a6c9787dde21e0acc17ab2c50 commit r14-9786-g85621f98d245004a6c9787dde21e0acc17ab2c50 Author: Richard Biener Date:

[Bug tree-optimization/114485] [13 Regression] Wrong code with -O3 -march=rv64gcv on riscv or `-O3 -march=armv9-a` for aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485 Richard Biener changed: What|Removed |Added Summary|[13/14 Regression] Wrong|[13 Regression] Wrong code

[Bug target/114415] [13/14 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415 --- Comment #5 from Vladimir Makarov --- After some considerations, I've decided to fix it in the scheduler. Such approach solves the problem for all targets and schedulers, still permitting live range shrinkage (important for space optimizatio

[Bug ipa/113359] [13/14 Regression] LTO miscompilation of ceph on aarch64 and x86_64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359 --- Comment #23 from Jan Hubicka --- The patch looks reasonable. We probably could hash the padding vectors at summary generation time to reduce WPA overhead, but that can be done incrementally next stage1. I however wonder if we really guarant

[Bug go/114454] go.test/test/fixedbugs/issue27836.go FAILs with LANG=C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114454 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Ian Lance Taylor --- > I'm not sure what is going on here. The test as such does not require a UTF-8 > LANG. That is, I can run the compiler and the test with LA

[Bug ipa/114247] RISC-V: miscompile at -O3 and IPA SRA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247 --- Comment #4 from Martin Jambor --- I don't seem to be able to get riscv64 qemu running in reasonable time. Can someone please verify that the following patch fixes the issue? diff --git a/gcc/ipa-param-manipulation.cc b/gcc/ipa-param-manipu

[Bug ipa/114247] RISC-V: miscompile at -O3 and IPA SRA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247 --- Comment #5 from Robin Dapp --- This fixes the test case for me locally, thanks. I can run the testsuite with it later if you'd like.

[Bug go/52357] 64bit-out.go and go.test/test/cmplxdivide.go time out on Solaris/SPARC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52357 Rainer Orth changed: What|Removed |Added Status|SUSPENDED |NEW --- Comment #7 from Rainer Orth --- U

[Bug go/114454] go.test/test/fixedbugs/issue27836.go FAILs with LANG=C

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114454 --- Comment #4 from Andreas Schwab --- <83> is the UTF-8 encoding of U00C3 and <84> is the UTF-8 encoding of U0084.

[Bug go/114581] New: go.test/test/fixedbugs/issue22881.go FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114581 Bug ID: 114581 Summary: go.test/test/fixedbugs/issue22881.go FAILs Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go

[Bug ipa/114247] RISC-V: miscompile at -O3 and IPA SRA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247 --- Comment #6 from Robin Dapp --- Testsuite looks unchanged on rv64gcv.

[Bug go/114582] New: go.test/test/fixedbugs/issue34123.go FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582 Bug ID: 114582 Summary: go.test/test/fixedbugs/issue34123.go FAILs Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go

[Bug sanitizer/79341] Many Asan tests fail on s390

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #77 from Ilya Leoshkevich --- Apparently fixing the message in GCC will produce maintenance overhead [1]. If that's not very important to you, I'd rather leave this message as is. [1] https://gcc.gnu.org/pipermail/gcc-patches/2024-A

[Bug target/114577] Inefficient codegen for SVE/NEON bridge

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114577 --- Comment #1 from GCC Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:86dce005a1d440154dbf585dde5a2dd4cfac7a05 commit r14-9787-g86dce005a1d440154dbf585dde5a2dd4cfac7a05 Author: Richard Sandiford Da

[Bug target/114577] Inefficient codegen for SVE/NEON bridge

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114577 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED CC|

[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 --- Comment #15 from Martin Uecker --- Created attachment 57874 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57874&action=edit patch Tentative patch for the fix that makes the incomplete types have structural equivalence at the beginni

[Bug go/114583] New: go.test/test/fixedbugs/issue4562.go FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114583 Bug ID: 114583 Summary: go.test/test/fixedbugs/issue4562.go FAILs Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go

[Bug go/114584] New: go.test/test/nil.go FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114584 Bug ID: 114584 Summary: go.test/test/nil.go FAILs Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee:

[Bug c++/114585] New: Incorrect boolean value with O2/O3 optimisation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114585 Bug ID: 114585 Summary: Incorrect boolean value with O2/O3 optimisation Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component

[Bug c++/114585] Incorrect boolean value with O2/O3 optimisation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114585 Andreas Schwab changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 Nicolas Boulenguez changed: What|Removed |Added Attachment #57865|0 |1 is obsolete|

[Bug analyzer/114586] New: Contradictory paths in reasoning for memory leak diagnostic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114586 Bug ID: 114586 Summary: Contradictory paths in reasoning for memory leak diagnostic Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal P

[Bug c++/114585] Incorrect boolean value with O2/O3 optimisation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114585 --- Comment #2 from Jonathan Wakely --- The bug reporting guidelines you were asked to read say to try -fsanitize=undefined and if you'd done that you'd have seen errors: https://godbolt.org/z/bscj8q9rr

[Bug target/114587] New: -mapxf should define a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114587 Bug ID: 114587 Summary: -mapxf should define a macro Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target As

[Bug target/114587] -mapxf should define a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114587 H.J. Lu changed: What|Removed |Added Target Milestone|--- |14.0 Ever confirmed|0

[Bug target/114587] -mapxf should define a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114587 --- Comment #1 from H.J. Lu --- We should define a macro for each APX command-line option.

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 --- Comment #14 from Nicolas Boulenguez --- The new version does not change much, but I am only posting it in order to prevent duplicated work. I will try to split the timespec changes and the timeval+Sockets changes, then attempt a build.

[Bug c++/114572] [OpenMP] "internal compiler error: in assign_temp" with assignment operator and lastprivate clause

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

[Bug analyzer/114588] New: Analyzer buffer overflow ASCII art hardcodes "RED" and "GREEN" as the terminal colors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114588 Bug ID: 114588 Summary: Analyzer buffer overflow ASCII art hardcodes "RED" and "GREEN" as the terminal colors Product: gcc Version: 14.0 Status: UNCONFIRMED Se

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0

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

[Bug target/114566] Misaligned vmovaps when compiling with stack-protector-strong for znver4

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

[Bug target/114566] [11/12/13 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Summary|Misaligned vmovap

[Bug target/114566] [11/12/13 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 --- Comment #10 from Jakub Jelinek --- Note, the a array which is the object into which the misaligned store happens has align:128 so assuming 256-bit alignment into it seems wrong: (insn 57 56 58 4 (set (reg:V8SF 135 [ vect__33.37 ]) (p

[Bug target/114566] [11/12/13 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 --- Comment #11 from Jakub Jelinek --- Seems like vectorizer bug to me. The _42 + 128 store is to MEM [(float *)_42 + 128B]; aka: unit-size align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type 0x7fffea153

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #62 from GCC Commits --- The releases/gcc-13 branch has been updated by Edwin Lu : https://gcc.gnu.org/g:c4eff4ece764d836eb7ee0c0163780d100471730 commit r13-8579-gc4eff4ece764d836eb7ee0c0163780d100471730 Author: Edwin Lu Date: M

[Bug target/114566] [11/12/13 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 --- Comment #12 from Jakub Jelinek --- The user align:32 MEM_REF comes from (gdb) p debug (dr_info->dr) #(Data Ref: # bb: 21 # stmt: a[j_38][k_41] = _48; # ref: a[j_38][k_41]; # base_object: a; # Access function 0: {0, +, 1}_3 # Access f

[Bug target/114566] [11/12/13 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 --- Comment #13 from Jakub Jelinek --- Ah, vect_analyze_data_refs_alignment -> vect_compute_data_ref_alignment actually checks for this case 1136 if (max_alignment < vect_align_c 1137 || !vect_can_force_dr_alignment_p (base

[Bug target/114566] [11/12/13/14 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 Jakub Jelinek changed: What|Removed |Added CC||avieira at gcc dot gnu.org S

[Bug middle-end/110773] [Aarch64] crash (SIGBUS) due to atomic instructions on under-aligned memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773 --- Comment #5 from Sainan --- (In reply to Wilco from comment #4) > The atomic will also set correct struct alignment. My thinking was that maybe this is not the case (= standard library issue) since both GCC and Clang seem to be causing this

[Bug target/114566] [11/12/13/14 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 --- Comment #15 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #14) > Marking for 14 as well because I believe the trunk commit just made it > latent there rather than fixed. You might be able to reproduce it on the trunk with -

[Bug middle-end/110773] [Aarch64] crash (SIGBUS) due to atomic instructions on under-aligned memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773 --- Comment #6 from Wilco --- (In reply to Sainan from comment #5) > (In reply to Wilco from comment #4) > > The atomic will also set correct struct alignment. > > My thinking was that maybe this is not the case (= standard library issue) > sin

[Bug c++/114589] New: missed optimization: losing bool range information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589 Bug ID: 114589 Summary: missed optimization: losing bool range information Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Compon

[Bug analyzer/114588] Analyzer buffer overflow ASCII art hardcodes "RED" and "GREEN" as the terminal colors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114588 --- Comment #1 from Andrew Pinski --- Confirmed. I should note that Red/Green is the opposite meaning in some places than western cultures. That is Red is good and Green is bad. Most of China is where that is true. See https://graphicdesign.sta

[Bug middle-end/110773] [Aarch64] crash (SIGBUS) due to atomic instructions on under-aligned memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773 --- Comment #7 from Sainan --- (In reply to Wilco from comment #6) > That does not make any sense. The only thing I think might happen is that > your structure is not correctly aligned (for example by using a custom > memory allocator). Can you

[Bug tree-optimization/114589] missed optimization: losing bool range information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|middle-e

[Bug middle-end/110773] [Aarch64] crash (SIGBUS) due to atomic instructions on under-aligned memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773 --- Comment #8 from Wilco --- (In reply to Sainan from comment #7) > (In reply to Wilco from comment #6) > > That does not make any sense. The only thing I think might happen is that > > your structure is not correctly aligned (for example by us

[Bug tree-optimization/114589] missed optimization: losing bool range information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Confirmed. > > Why didn't sink1 push _10, _13, _12, and _11 past the conditional here ... > If it did that I think it might have optimized correctly. Because t

[Bug middle-end/110773] [Aarch64] crash (SIGBUS) due to atomic instructions on under-aligned memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773 --- Comment #9 from Sainan --- (In reply to Wilco from comment #8) > So it's unaligned then, and that's not supported. And you're lucky your > specific alignment happens to work on v8.4 cores - it would fail for other > offsets. I'd say unlucky

[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980 --- Comment #12 from Giuliano Belinassi --- With your patch we have: > .LPFE0: > nop > nop > nop > nop > nop > nop > nop > nop > nop > nop > nop > nop > nop >

[Bug c++/45431] specify the field for initializer-string for array of chars is too long

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

[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 --- Comment #11 from GCC Commits --- The releases/gcc-13 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:b03827b261d3c8351f9c208fe2d89ca987a25bee commit r13-8584-gb03827b261d3c8351f9c208fe2d89ca987a25bee Author: Iain Sandoe D

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:02a1d49da8f95a128d131747546921b67818d144 commit r13-8586-g02a1d49da8f95a128d131747546921b67818d144 Author: Iain Sandoe Da

[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480 --- Comment #20 from Alexander Monakov --- (note that if you uninclude the testcase and compile with -fno-exceptions it's much faster) On the smaller testcase from comment 14, prune_unused_phi_nodes invokes gcc_qsort 53386 times. There are two

[Bug target/114587] -mapxf should define a macro

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114587 --- Comment #2 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:1df56719bd868c58466a549b25d7064dac3eb456 commit r14-9791-g1df56719bd868c58466a549b25d7064dac3eb456 Author: H.J. Lu Date: Thu Apr 4 08:

[Bug d/103944] [12/13/14 Regression] Testsuite hang due to libphobos/testsuite/libphobos.gc/forkgc2.d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103944 --- Comment #15 from GCC Commits --- The releases/gcc-12 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:5a72912f9b0a5aa3c5a726ec499137c189921f9b commit r12-10309-g5a72912f9b0a5aa3c5a726ec499137c189921f9b Author: Iain Sandoe

[Bug target/110624] Xcode 15 ld warns about -macosx_version_min

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110624 --- Comment #10 from GCC Commits --- The releases/gcc-12 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:a17f5a03e93d2cc6fd40cef6ab3930ba019f804a commit r12-10310-ga17f5a03e93d2cc6fd40cef6ab3930ba019f804a Author: Iain Sandoe

[Bug target/107568] Darwin: Bootstrap fails with macOS13 sdk because sprintf and friends are deprecated in the SDK.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568 --- Comment #20 from GCC Commits --- The releases/gcc-12 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:753d7e4edf63c4ff690858da11bf0d59aa24e1bb commit r12-10311-g753d7e4edf63c4ff690858da11bf0d59aa24e1bb Author: Iain Sandoe

[Bug target/114590] New: [14 Regression] FAIL: gcc.target/i386/apx-ndd-ti-shift.c (test for excess errors)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590 Bug ID: 114590 Summary: [14 Regression] FAIL: gcc.target/i386/apx-ndd-ti-shift.c (test for excess errors) Product: gcc Version: 14.0 Status: UNCONFIR

[Bug target/114590] [14 Regression] FAIL: gcc.target/i386/apx-ndd-ti-shift.c (test for excess errors)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590 H.J. Lu changed: What|Removed |Added Priority|P3 |P2 Target Milestone|---

[Bug rtl-optimization/114591] New: rtl-reload introduce an extra load operation since gcc-12

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591 Bug ID: 114591 Summary: rtl-reload introduce an extra load operation since gcc-12 Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal P

[Bug target/114591] rtl-reload introduce an extra load operation since gcc-12

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-04-04 Target|

[Bug target/114591] [12/13/14 Regression] rtl-reload introduce an extra load operation since gcc-12

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.4 Summary|rtl-reload intr

[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |REOPENED --- Comment #6 from

[Bug target/114590] [14 Regression] FAIL: gcc.target/i386/apx-ndd-ti-shift.c (test for excess errors)

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

[Bug c++/100611] coroutines: destructor called too many times for coroutine lambda stored object

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100611 vipcxj at 126 dot com changed: What|Removed |Added CC||vipcxj at 126 dot com --- Commen

[Bug c++/100611] coroutines: destructor called too many times for coroutine lambda stored object

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100611 --- Comment #8 from Avi Kivity --- Congratulations on getting the account! The bug is fixed though.

[Bug c++/100611] coroutines: destructor called too many times for coroutine lambda stored object

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100611 --- Comment #9 from Avi Kivity --- At least, on 13.2.1. Maybe a backport is required.

[Bug c++/114592] New: Bogus `maybe-uninitialized` on std::variant with std::string with -O3

(GCC) 14.0.1 20240404 (experimental) Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ g++ -Werror=maybe-uninitialized -O3 -std=gnu++20 -c test-maybe-u

  1   2   >