Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote: > Like la264 only has 40 effective bits of virtual address space. I'm OK with the change. But the VA length is configurable building the kernel. Is there any specific reason LA264 has to use the 40-bit configuration, or should we reword the

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931 --- Comment #19 from rguenther at suse dot de --- On Tue, 21 Feb 2023, ishikawa at yk dot rim.or.jp wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931 > > --- Comment #18 from ishikawa,chiaki --- > I reported the issue to the

[Bug target/108851] gcc -pie generates unwanted PE export table

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108851 --- Comment #1 from Andrew Pinski --- I doubt GCC has control over this. I suspect the issue is in the binutils side ...

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931 --- Comment #18 from ishikawa,chiaki --- I reported the issue to the following github for a very fast hashing function library. https://github.com/Cyan4973/xxHash/issues/800 >From the discussion there, I figured -Og does not define

Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

On Mon, Feb 20, 2023 at 5:23 PM Tobias Burnus wrote: > > Hi Richard, hi all, > > On 20.02.23 13:46, Richard Biener wrote: > > + /* TODO: A more middle-end friendly alternative would be to use > > NULL_TREE > > +as upper bound and store the value, e.g. as GFC_DECL_STRING_LEN. > > +

[PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

Like la264 only has 40 effective bits of virtual address space. When TRY_EMPTY_VM_SPACE is set to 0x80, it just exceeds the range of 40-bit virtual address, causing the mmap mapping to fail, thus causing the pch function to fail. To be compatible with this situation set the macro to

[Bug tree-optimization/108868] [13 Regression] ocaml-dune miscompilation on i686 since r13-5965

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108868 --- Comment #5 from Richard Biener --- (In reply to Jakub Jelinek from comment #4) > I think the reason why it doesn't work is clear, call_can_make_abnormal_goto > on the vfork call is false, because it is leaf (and that is how glibc > declares

[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846 --- Comment #7 from Andrew Pinski --- I suspect std::move has the same issue too. The ability to use memmove with trivial copyable subobjects ...

Re: [PATCH] Fortran: improve checking of character length specification [PR96025]

Hi Harald, the attached patch fixes an ICE on invalid (non-integer) specification expressions for character length in function declarations. It appears that the error handling was already in place (mostly) and we need to essentially prevent run-on errors. Regtested on x86_64-pc-linux-gnu. OK

RE: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

Hi, Kindly reminder for this PR. Pan -Original Message- From: Li, Pan2 Sent: Friday, February 17, 2023 4:39 PM To: richard.sandif...@arm.com; juzhe.zhong Cc: incarnation.p@outlook.com; gcc-patches@gcc.gnu.org; kito.ch...@sifive.com; Richard Biener Subject: RE: [PATCH] RISC-V:

[PATCH] MIPS: Account for LWL/LWR in store_by_pieces_p.

From: Matthew Fortune --- gcc/config/mips/mips.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc index 590c311e98c..bb9f4e19c22 100644 --- a/gcc/config/mips/mips.cc +++ b/gcc/config/mips/mips.cc @@ -8853,7 +8853,7 @@

[PATCH] Testsuite: Disable micromips for MSA tests

From: Matthew Fortune --- gcc/testsuite/gcc.target/mips/mips.exp | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/testsuite/gcc.target/mips/mips.exp b/gcc/testsuite/gcc.target/mips/mips.exp index 81e19f39853..bf32fe0c93f 100644 --- a/gcc/testsuite/gcc.target/mips/mips.exp +++

[Bug libstdc++/108846] std::copy, std::copy_n on potentially overlapping subobjects

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846 --- Comment #6 from Jiang An --- > For example, assuming both sizeof(B) and sizeof(D) are 8, which means the last > 2 bytes of B are padding (true for common implementations on Itanium ABI): Oh, I forgot the strange design caused by CWG43 -

[Bug tree-optimization/108860] New (since gcc 12) false positive null-dereference in vector.resize

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

Re: MicroBlaze symver attribute support

On 2/20/23 06:54, Joel Sherrill wrote: On Mon, Feb 20, 2023 at 7:56 AM Vincent Fazio via Gcc > wrote: Michael, all, Regarding: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101766

[Bug libstdc++/98449] [DR 3343] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98449 --- Comment #6 from Jonathan Wakely --- (In reply to Vinícius dos Santos Oliveira from comment #3) > LLVM's libcxx already applied this 1-line patchset: > https://github.com/llvm/llvm-project/commit/ > 64fc3cd55d586498dd21c5b3cfaa755793913772 >

Re: [PATCH] xtensa: Enforce return address saving when -Og is specified

On Fri, Feb 17, 2023 at 8:54 PM Takayuki 'January June' Suwa wrote: > > Leaf function often omits saving its return address to the stack slot, > and this feature often makes debugging very confusing, especially for > stack dump analysis. > > gcc/ChangeLog: > > * config/xtensa/xtensa.cc

[Bug c++/108848] [10/11/12/13 Regression] template keyword incorreclty required to access template class static member of non-dependent expression using member syntax in dependent context

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108848 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org

Re: [PATCH] rs6000: mark tieable between INT and FLOAT

Hi, Gently Ping: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609504.html BR, Jeff (Jiufu) Jiufu Guo writes: > Hi, > > During discussing/review patches in maillist, we find more modes are > tieable, e.g. DI<->DF. With some discussion, I drafted this patch > to mark more tieable

[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861 --- Comment #4 from Jonathan Wakely --- (In reply to Vinícius dos Santos Oliveira from comment #2) > Nobody is going to fix 98449. The ONE-line patchset fixing the issue was > there for YEARS. Why does it take so many years to review ONE line?

[Bug target/108804] missed vectorization in presence of conversion from uint64_t to float

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108804 --- Comment #3 from Hongtao.liu --- I think the point here is: although it's unit64_t -> float, but the range of x and y can be represent as int32(k & 0x007F) | 0x3F80), so we can use int32 -> float instructions which are supported by

[Bug libstdc++/108636] [10/11/12 Regression] C++20 undefined reference to `std::filesystem::__cxx11::path::_List::type(std::filesystem::__cxx11::path::_Type)' with -fkeep-inline-functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:0a2597477e482df4d67db6696431286df1ff4428 commit r12-9193-g0a2597477e482df4d67db6696431286df1ff4428 Author: Jonathan

[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

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

[Bug libstdc++/98449] [DR 3343] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98449 --- Comment #5 from Andrew Pinski --- *** Bug 108861 has been marked as a duplicate of this bug. ***

[Bug libstdc++/98449] [DR 3343] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98449 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|SUSPENDED Resolution|FIXED

[Bug tree-optimization/108868] [13 Regression] ocaml-dune miscompilation on i686 since r13-5965

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108868 --- Comment #4 from Jakub Jelinek --- I think the reason why it doesn't work is clear, call_can_make_abnormal_goto on the vfork call is false, because it is leaf (and that is how glibc declares vfork BTW) and ctrl_altering flag is initialized

[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861 --- Comment #2 from Vinícius dos Santos Oliveira --- > Isn't this just Bug 98449? Why did you close that as FIXED? Nobody is going to fix 98449. The ONE-line patchset fixing the issue was there for YEARS. Why does it take so many years to

[Bug tree-optimization/108868] [13 Regression] ocaml-dune miscompilation on i686 since r13-5965

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108868 --- Comment #3 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #2) > That would be invalid, vfork can't return from the containing function. I messed up the if (it should be the opposite way around, that is checking for

[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721 --- Comment #8 from Jerry DeLisle --- FWIW : I think the typespec is being lost because the initial call into gfc_match_array_constructor which finds and matches the typespec sets a local variable seen_ts which is used later in that function to

[Bug libstdc++/108846] std::copy, std::copy_n on potentially overlapping subobjects

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846 --- Comment #5 from Giuseppe D'Angelo --- > In the case of copy family algorithms, I believe it's OK to specially handle > cases where last - first == 1.

[Bug middle-end/108854] tbb-2021.8.0 fails on i686-linux (32-bit), internal compiler error: in expand_expr_real_1, at expr.c:10281

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108854 --- Comment #5 from Andrew Pinski --- _ZThn20_N3tbb6detail2d114broadcast_nodeINS1_12continue_msgEE18register_successorERNS1_8receiverIS3_EE demangles to: non-virtual thunk to

[Bug tree-optimization/108868] [13 Regression] ocaml-dune miscompilation on i686 since r13-5965

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108868 --- Comment #2 from Jakub Jelinek --- That would be invalid, vfork can't return from the containing function. Anyway, reduced testcase which shows the .ABNORMAL_DISPATCHER call in r13-5964 and none in r13-5965 in optimized is e.g. with just

[Bug middle-end/108854] tbb-2021.8.0 fails on i686-linux (32-bit), internal compiler error: in expand_expr_real_1, at expr.c:10281

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108854 --- Comment #4 from Andrew Pinski --- This is the ICE: tbb-i686-linux> during RTL pass: expand tbb-i686-linux> In file included from /build/source/src/tbb/../../include/tbb/flow_graph.h:17, tbb-i686-linux> from

[Bug tree-optimization/108868] [13 Regression] ocaml-dune miscompilation on i686 since r13-5965

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108868 --- Comment #1 from Andrew Pinski --- Here is a testcase which shows the removal of ABNORMAL_DISPATCHER though I am not sure what is the best way to test if the removal makes a difference. ``` extern int vfork (void) __attribute__

[Bug libstdc++/108859] Exception thrown by std::filesystem::copy() is wrong

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

[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861 --- Comment #1 from Jonathan Wakely --- Isn't this just Bug 98449? Why did you close that as FIXED?

[Bug tree-optimization/108868] [13 Regression] ocaml-dune miscompilation on i686 since r13-5965

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108868 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |13.0 CC|

[Bug tree-optimization/108868] New: [13 Regression] ocaml-dune miscompilation on i686 since r13-5965

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108868 Bug ID: 108868 Summary: [13 Regression] ocaml-dune miscompilation on i686 since r13-5965 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal

[PATCH] i386: Introduce general_x64constmem_operand predicate

Instructions that use high-part QImode registers can not be encoded with REX prefix. To avoid REX prefix, operand constraints allow only legacy QImode registers, immediates and constant memory operands. The patch introduces matching predicate, so invalid operands are not combined into instruction

[Bug analyzer/108867] New: RFE: analyzer could suppress false positives by detecting functions that are likely missing __attribute__((noreturn))

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108867 Bug ID: 108867 Summary: RFE: analyzer could suppress false positives by detecting functions that are likely missing __attribute__((noreturn)) Product: gcc

[Bug fortran/108850] SELECT CASE within BLOCK construct in one subroutine prevents compilation of another subroutine named "SELECT"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108850 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to John Wingate from comment #2) > I forgot to mention in the original description that the error does not > occur if the SELECT CASE is removed. Right. The testcase case be slightly

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 --- Comment #3 from Andrew Pinski --- (In reply to Costas Argyris from comment #2) > (In reply to Andrew Pinski from comment #1) > > Utf8 is the best generic solution really. > > Using wmain is not very portable and the rest of gcc's sources

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 --- Comment #2 from Costas Argyris --- (In reply to Andrew Pinski from comment #1) > Utf8 is the best generic solution really. > Using wmain is not very portable and the rest of gcc's sources can't use > wchar_t as that would break unix/Linux

[Bug fortran/108850] SELECT CASE within BLOCK construct in one subroutine prevents compilation of another subroutine named "SELECT"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108850 --- Comment #2 from John Wingate --- I forgot to mention in the original description that the error does not occur if the SELECT CASE is removed.

[Bug target/108866] Allow to pass Windows resource file (.rc) as input to gcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement

[Bug target/108866] Allow to pass Windows resource file (.rc) as input to gcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866 Andrew Pinski changed: What|Removed |Added Component|c |target --- Comment #1 from Andrew

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 --- Comment #1 from Andrew Pinski --- Utf8 is the best generic solution really. Using wmain is not very portable and the rest of gcc's sources can't use wchar_t as that would break unix/Linux handling.

[Bug c/108866] New: Allow to pass Windows resource file (.rc) as input to gcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108866 Bug ID: 108866 Summary: Allow to pass Windows resource file (.rc) as input to gcc Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal

[Bug c++/108550] [10/11/12/13 Regression] the type 'const auto' of 'constexpr' variable is not literal

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108550 --- Comment #7 from Marek Polacek --- We get the bogus error because we failed to deduce the auto in constexpr auto is_pointer_v = is_pointer::value; to bool. We call do_auto_deduction and type_unification_real correctly deduces targs to , but

[Bug target/108862] [13 Regression] CryptX miscompilation on power9 since r13-2107

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

[Bug driver/108865] New: gcc on Windows fails with Unicode path to source file

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 Bug ID: 108865 Summary: gcc on Windows fails with Unicode path to source file Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3

[committed] powerpc: Another umaddditi4 fix [PR108862]

Hi! The following testcase is miscompiled on powerpc64le-linux with -O2 -mcpu=power9. The problem is that gen_umaddditi4 is called with the same TImode register for both op0 and op3, and maddlddi4 overwrites the low half of op0 before the low half of op3 is read, so when they are the same

[Bug rtl-optimization/108863] Unrolling could use range information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108863 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-02-20 Ever confirmed|0

[Bug target/108862] [13 Regression] CryptX miscompilation on power9 since r13-2107

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108862 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cd8b4fae52d02541c2d8bd2200caad3812f37368 commit r13-6147-gcd8b4fae52d02541c2d8bd2200caad3812f37368 Author: Jakub Jelinek Date:

[Bug sanitizer/108864] Insufficient red zone in ASAN

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

[Bug sanitizer/108864] New: Insufficient red zone in ASAN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108864 Bug ID: 108864 Summary: Insufficient red zone in ASAN Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer

[Bug fortran/96025] [10/11/12/13 Regression] ICE in expr_check_typed_help, at fortran/expr.c:5437

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96025 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot

[PATCH] Fortran: improve checking of character length specification [PR96025]

Dear all, the attached patch fixes an ICE on invalid (non-integer) specification expressions for character length in function declarations. It appears that the error handling was already in place (mostly) and we need to essentially prevent run-on errors. Regtested on x86_64-pc-linux-gnu. OK

[Bug rtl-optimization/108863] Unrolling could use range information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108863 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |rtl-optimization --- Comment #1 from

[Bug tree-optimization/108863] Unrolling could use range information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108863 Thomas Koenig changed: What|Removed |Added Severity|normal |enhancement Keywords|

[Bug tree-optimization/108863] New: Unrolling could use range information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108863 Bug ID: 108863 Summary: Unrolling could use range information Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug sanitizer/108834] LTO: ltrans temporary file is used as module name in ASAN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834 --- Comment #10 from Martin Liška --- I've filed an upstream review request: https://reviews.llvm.org/D144424

[PATCH] c++: constant non-copy-init is manifestly constant [PR108243]

According to [basic.start.static]/2 and [expr.const]/2, a variable with static storage duration initialized with a constant initializer has constant initialization, and such an initializer is manifestly constant-evaluated. We're already getting this right with copy initialization because in that

[Bug fortran/108850] SELECT CASE within BLOCK construct in one subroutine prevents compilation of another subroutine named "SELECT"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108850 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c++/108848] template keyword incorreclty required to access template class static member of non-dependent expression using member syntax in dependent context

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

[Bug middle-end/108847] unnecessary bitwise AND on boolean types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108847 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords|ABI

[Bug c++/108243] [10/11/12/13 Regression] Missed optimization for static const std::string_view(const char*)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108243 --- Comment #9 from Patrick Palka --- (In reply to Jiang An from comment #8) > This seems a bug, not merely missing of optimization. The string_view object > should always be statically initialized, because it has static storage > duration and

[Bug c++/108550] [10/11/12/13 Regression] the type 'const auto' of 'constexpr' variable is not literal

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108550 --- Comment #6 from Marek Polacek --- Ah! Started with commit dc062b4986328bfeec3ebd744a9c116e28828bf0 Author: Jason Merrill Date: Wed Aug 5 13:56:14 2015 -0400 re PR c++/66260 ([C++14] Failure to compile variable template with

[Bug c++/108550] [10/11/12/13 Regression] the type 'const auto' of 'constexpr' variable is not literal

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108550 --- Comment #5 from Andrew Pinski --- (In reply to Marek Polacek from comment #4) > Why is this a regression? I'm not finding a released version that compiled > this. The testcase in comment #2 works both with GCC 5.1.0 and 5.2.0 at least as

Re: Problems when building NT kernel drivers with GCC / LD

On Tuesday 03 January 2023 11:06:26 Nick Clifton wrote: > Hi Pali, > > > Hello! I would like to remind this thread for gcc/binutils developers. > > Most of these issues are still present and cause problems for compiling > > native PE binary. If you have questions or you need any other information

[Bug c++/108550] [10/11/12/13 Regression] the type 'const auto' of 'constexpr' variable is not literal

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

[Bug c++/101073] [10/11/12/13 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.c:6941

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101073 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

Re: [PATCH] Fixing PR107411

> On Feb 20, 2023, at 10:17 AM, Jakub Jelinek wrote: > > On Mon, Feb 20, 2023 at 03:04:51PM +, Qing Zhao via Gcc-patches wrote: >> >> >>> On Feb 17, 2023, at 5:35 PM, Jakub Jelinek wrote: >>> >>> On Fri, Feb 17, 2023 at 10:26:03PM +, Qing Zhao via Gcc-patches wrote: +

[Bug c++/101073] [10/11/12/13 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.c:6941

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101073 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:b2287a4d9a640fdc2caef6a067830ea65044deb7 commit r13-6145-gb2287a4d9a640fdc2caef6a067830ea65044deb7 Author: Marek Polacek Date:

[Bug target/104921] aarch64: Assembler failure with vbfmlalbq_lane_f32 intrinsic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104921 Alex Coplan changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/104921] aarch64: Assembler failure with vbfmlalbq_lane_f32 intrinsic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104921 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Alex Coplan : https://gcc.gnu.org/g:617377cc1641e4f63617b192e224bc96dfbbd324 commit r10-11222-g617377cc1641e4f63617b192e224bc96dfbbd324 Author: Alex Coplan

Re: [GSoC] Help needed for building on aarch64-apple-darwin22.1.0

Hi Shengyu, > On 20 Feb 2023, at 17:31, Shengyu Huang via Gcc wrote: > > After following the instructions here > (https://gcc.gnu.org/wiki/InstallingGCC) and here > (https://gcc.gnu.org/install/index.html), the `make` step simply fails with > “*** Configuration aarch64-apple-darwin22.1.0

[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168 --- Comment #14 from Iain Sandoe --- please see the Work In Progress here: https://github.com/iains/gcc-darwin-arm64 this is a functional branch (although with known issues, since it is a prototype)

[GSoC] Help needed for building on aarch64-apple-darwin22.1.0

Dear all, After following the instructions here (https://gcc.gnu.org/wiki/InstallingGCC) and here (https://gcc.gnu.org/install/index.html), the `make` step simply fails with “*** Configuration aarch64-apple-darwin22.1.0 not supported”. I found this issue on Bugzilla

[Bug c++/108829] [12 Regression] internal compiler error: in is_capture_proxy, at cp/lambda.cc:272

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108829 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c++/108829] [12 Regression] internal compiler error: in is_capture_proxy, at cp/lambda.cc:272

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108829 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:12cdc0e266f02c3ba4e80c3d971463ff507e049b commit r12-9191-g12cdc0e266f02c3ba4e80c3d971463ff507e049b Author: Marek Polacek

Re: [PATCH RFC 1/3] c++: add __is_deducible trait [PR105841]

On Sat, 18 Feb 2023, Jason Merrill via Gcc-patches wrote: > Tested x86_64-pc-linux-gnu. Since this is fixing experimental (C++20) > functionality, I think it's reasonable to apply now; I'm interested in other > opinions, and thoughts about the user-facing functionality. I'm thinking to > make

Re: [committed] libstdc++: Fix uses of non-reserved names in simd header

On Mon, 20 Feb 2023 at 16:32, Matthias Kretz via Libstdc++ wrote: > > Tested x86_64-pc-linux. Pushed to trunk. OK for all relevant branches, thanks.

[committed] libstdc++: Fix uses of non-reserved names in simd header

Tested x86_64-pc-linux. Pushed to trunk. -- >8 -- Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: * include/experimental/bits/simd.h (__extract_part, split): Use reserved name for template parameter. --- libstdc++-v3/include/experimental/bits/simd.h | 22

Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

Hi Richard, hi all, On 20.02.23 13:46, Richard Biener wrote: + /* TODO: A more middle-end friendly alternative would be to use NULL_TREE +as upper bound and store the value, e.g. as GFC_DECL_STRING_LEN. +Caveat: this requires some cleanup throughout the code to consistently

[Bug sanitizer/108834] LTO: ltrans temporary file is used as module name in ASAN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834 --- Comment #9 from Martin Liška --- (In reply to Jakub Jelinek from comment #8) > Sure, we want to keep using libbacktrace. But libbacktrace can be extended > if Ian is ok with it, or some extensions can be done on the >

[Bug c++/108829] [12 Regression] internal compiler error: in is_capture_proxy, at cp/lambda.cc:272

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108829 Marek Polacek changed: What|Removed |Added Summary|[12/13 Regression] internal |[12 Regression] internal

[Bug sanitizer/108834] LTO: ltrans temporary file is used as module name in ASAN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834 --- Comment #8 from Jakub Jelinek --- Sure, we want to keep using libbacktrace. But libbacktrace can be extended if Ian is ok with it, or some extensions can be done on the libsanitizer/libbacktrace side of it.

RE: [PATCH] [arm] disable aes-1742098 mitigation for a72 combine tests

Hi Alexandre, > -Original Message- > From: Alexandre Oliva > Sent: Friday, February 17, 2023 7:06 AM > To: gcc-patches@gcc.gnu.org > Cc: ni...@redhat.com; Richard Earnshaw ; > ramana@gmail.com; Kyrylo Tkachov > Subject: [PATCH] [arm] disable aes-1742098 mitigation for a72 combine

[Bug sanitizer/108834] LTO: ltrans temporary file is used as module name in ASAN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834 --- Comment #7 from Martin Liška --- So clang uses __sanitizer::LLVMSymbolizer: $ clang jhead.i -fsanitize=address -g && strace -f -s512 ./a.out 2>&1 | grep execv execve("./a.out", ["./a.out"], 0x7fffd520 /* 116 vars */) = 0 [pid 5529]

[committed] RISC-V: prefetch.* only take base register with zero-offset for the address

Catched by running gcc.c-torture/execute/builtin-prefetch-2.c with -march=rv64gc_zicbop. gcc/ChangeLog: * config/riscv/riscv.md (prefetch): Use r instead of p for the address operand. (riscv_prefetchi_): Ditto. --- gcc/config/riscv/riscv.md | 4 ++-- 1 file changed, 2

[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 --- Comment #7 from Jakub Jelinek --- The patches (3 variants) have been posted and are awaiting review. I've pinged them twice.

[Bug c/106465] ICE for VLA in struct in parameter of nested function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106465 --- Comment #3 from Martin Uecker --- Created attachment 54496 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54496=edit patch for C FE Here is a patch.

Re: [PATCH] Fixing PR107411

On Mon, Feb 20, 2023 at 03:04:51PM +, Qing Zhao via Gcc-patches wrote: > > > > On Feb 17, 2023, at 5:35 PM, Jakub Jelinek wrote: > > > > On Fri, Feb 17, 2023 at 10:26:03PM +, Qing Zhao via Gcc-patches wrote: > >> +else if (!DECL_NAME (lhs_var)) > >> + { > >> +

[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464 --- Comment #6 from Orion Poplawski --- So, there was quite the initial flurry of activity here and then nothing. Any chance we could get some more movement here? It's breaking a ccache test for one. Thank you.

[Bug target/108862] [13 Regression] CryptX miscompilation on power9 since r13-2107

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108862 --- Comment #5 from Jakub Jelinek --- Created attachment 54495 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54495=edit gcc13-pr108862.patch Variant patch, instead of creating another temporary and moving it we can just do the highpart

Re: [PATCH] Fixing PR107411

> On Feb 17, 2023, at 5:35 PM, Jakub Jelinek wrote: > > On Fri, Feb 17, 2023 at 10:26:03PM +, Qing Zhao via Gcc-patches wrote: >> + else if (!DECL_NAME (lhs_var)) >> +{ >> + char *lhs_var_name_str >> += xasprintf ("D.%u", DECL_UID

Prototype 'GOMP_enable_pinned_mode' (was: [PATCH 08/17] openmp: -foffload-memory=pinned)

Hi! On 2022-07-07T23:18:03+0100, Andrew Stubbs wrote: > On 07/07/2022 12:54, Tobias Burnus wrote: >> On 07.07.22 12:34, Andrew Stubbs wrote: >>> Implement the -foffload-memory=pinned option such that libgomp is >>> instructed to enable fully-pinned memory at start-up. The option is >>> intended

[Bug target/108862] [13 Regression] CryptX miscompilation on power9 since r13-2107

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108862 --- Comment #4 from Jakub Jelinek --- Created attachment 54494 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54494=edit gcc13-pr108862.patch Untested fix.

Re: MicroBlaze symver attribute support

On Mon, Feb 20, 2023 at 7:56 AM Vincent Fazio via Gcc wrote: > Michael, all, > > Regarding: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101766 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102110 > > If I understand correctly, since the GCC MicroBlaze targets generate ELF > images, it would

  1   2   3   >