[Bug tree-optimization/96701] Failure to optimize self right-shift to 0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96701 Eugene Rozenfeld changed: What|Removed |Added CC||erozen at microsoft dot com ---

[Bug tree-optimization/97223] Failure to optimize comparison of char arithmetic to single comparison

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97223 Eugene Rozenfeld changed: What|Removed |Added CC||erozen at microsoft dot com ---

Re: [PATCH] PowerPC: Don't assume all targets have GLIBC

On Fri, Oct 30, 2020 at 06:39:16PM -0500, Segher Boessenkool wrote: > On Fri, Oct 30, 2020 at 06:50:30PM -0400, Michael Meissner wrote: > > On Fri, Oct 30, 2020 at 03:54:06PM -0500, Segher Boessenkool wrote: > > > But, time will fix all problems here. So, okay for trunk. Thanks! > > > > Note, I

[Bug c++/95519] [coroutines] non-functions for promise_type::return_void not supported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95519 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED CC|

[Bug libstdc++/96958] Long Double in Hash Table policy forces soft-float calculations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96958 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

Re: [committed] libstdc++: Use double for unordered container load factors [PR 96958]

On 31/10/20 00:23 +, Jonathan Wakely wrote: These calculations were changed to use long double nearly ten years ago in order to get more precision than float: https://gcc.gnu.org/pipermail/libstdc++/2011-September/036420.html However, double should be sufficient, whlie being potentially

[Bug libstdc++/96958] Long Double in Hash Table policy forces soft-float calculations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96958 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:943cc2a1b70f2d755b4fed97b1c4b49234d92899 commit r11-4585-g943cc2a1b70f2d755b4fed97b1c4b49234d92899 Author: Jonathan Wakely Date:

[r11-4578 Regression] FAIL: gcc.target/i386/zero-scratch-regs-31.c (test for excess errors) on Linux/x86_64

On Linux/x86_64, d10f3e900b0377b4760a090b0f90371bcef01686 is the first bad commit commit d10f3e900b0377b4760a090b0f90371bcef01686 Author: qing zhao Date: Fri Oct 30 20:41:38 2020 +0100 Add -fzero-call-used-regs option and zero_call_used_regs function attributes. caused FAIL:

[Bug libstdc++/97600] [ranges] satisfaction value of range affected by prior use of basic_istream_view::begin()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97600 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:afb8da7faa9dfe5a0d94ed45a373d74c076784ab commit r11-4584-gafb8da7faa9dfe5a0d94ed45a373d74c076784ab Author: Patrick Palka Date:

[committed] libstdc++: Use double for unordered container load factors [PR 96958]

These calculations were changed to use long double nearly ten years ago in order to get more precision than float: https://gcc.gnu.org/pipermail/libstdc++/2011-September/036420.html However, double should be sufficient, whlie being potentially faster than long double, and not requiring soft FP

[committed] libstdc++: Fix some more warnings in test

libstdc++-v3/ChangeLog: * testsuite/23_containers/vector/bool/modifiers/insert/31370.cc: Avoid -Wcatch-value warnings. Tested powerpc64le-linux. Committed to trunk. commit d1e5d82af819025df9d9a81e8c591690e299924a Author: Jonathan Wakely Date: Fri Oct 30 10:47:25 2020

[Bug libstdc++/96958] Long Double in Hash Table policy forces soft-float calculations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96958 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.0 --- Comment #6 from Jonathan

[committed] libstdc++: Implement P2017R1 "Conditionally borrowed ranges"

This makes some range adaptors model the borrowed_range concept if they are adapting a borrowed range. This hasn't been added to the C++23 working paper yet, but it has been approved by LWG, and the recommendation is to treat it as a defect report for C++20 as well. libstdc++-v3/ChangeLog:

Re: [PATCH] PowerPC: Don't assume all targets have GLIBC

On Fri, Oct 30, 2020 at 06:50:30PM -0400, Michael Meissner wrote: > On Fri, Oct 30, 2020 at 03:54:06PM -0500, Segher Boessenkool wrote: > > But, time will fix all problems here. So, okay for trunk. Thanks! > > Note, I discovered the ABI is not set to ELFv2 at the time the test is done, > so >

[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461 --- Comment #20 from Sergei Trofimovich --- (In reply to Martin Liška from comment #17) > Or I may have a smarter trick: let's do dry run of malloc/free functions > early in __gcov_init. Can you please test the patch as well? > > commit

Re: [patch] Fixing ppc64 test failure after patch dealing with scratches in IRA

Hi! On Fri, Oct 30, 2020 at 03:19:12PM -0400, Vladimir Makarov wrote: >   The following patch fixes failures for test p9-extract-2.c on > ppc64.  The failures are a result of committing patch dealing with insn > scratches in IRA.  The pseudo corresponding the 1st scratch in the > following insn

Re: [PATCH] PowerPC: Don't assume all targets have GLIBC

On Fri, Oct 30, 2020 at 03:54:06PM -0500, Segher Boessenkool wrote: > But, time will fix all problems here. So, okay for trunk. Thanks! Note, I discovered the ABI is not set to ELFv2 at the time the test is done, so I removed that part of the test. This is the patch I committed: >From

[Bug libgomp/97649] OpenMP: 'target teams' with host-fallback: race condition according to TSAN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97649 Tobias Burnus changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED

gcc-9-20201030 is now available

Snapshot gcc-9-20201030 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20201030/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

[Bug libgomp/97649] OpenMP: 'target teams' with host-fallback: race condition according to TSAN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97649 --- Comment #1 from Jakub Jelinek --- Was this a --disable-linux-futex build or not? I believe TSAN at least in the past didn't understand well the futex synchronization libgomp does on linux.

[Bug libgomp/97649] New: OpenMP: 'target teams' with host-fallback: race condition according to TSAN

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97649 Bug ID: 97649 Summary: OpenMP: 'target teams' with host-fallback: race condition according to TSAN Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords:

Re: [PATCH] Treat { 0 } specially for structs with the designated_init attribute.

Joseph Myers writes: > I've tested and committed the first patch. Great, thanks! > The second one introduces some test failures: > > [...] > > Could you investigate those and send versions of the second and third > patches that don't introduce any test regressions? I've also found a more

Re: [PATCH] libstdc++: Don't initialize from *this inside some views [PR97600]

On 30/10/20 11:11 -0400, Patrick Palka via Libstdc++ wrote: This works around a subtle issue where instantiating the begin()/end() member of some views (as part of return type deduction) inadvertently requires computing the satisfaction value of range. This is problematic because the constraint

RE: [PATCH] rs6000, vector integer multiply/divide/modulo instructions

On Fri, 2020-10-30 at 17:05 -0400, David Edelsohn wrote: > On Fri, Oct 30, 2020 at 4:07 PM Carl Love wrote: > > > diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-1-p10- > > runnable.c b/gcc/testsuite/gcc.target/powerpc/builtins-1-p10- > > runnable.c > > new file mode 100644 > > index

[Bug libstdc++/96958] Long Double in Hash Table policy forces soft-float calculations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96958 --- Comment #5 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a1343e5c74093124d7fbce6052d838f47a8eeb20 commit r11-4581-ga1343e5c74093124d7fbce6052d838f47a8eeb20 Author: Jonathan Wakely Date:

Re: [PATCH] rs6000, vector integer multiply/divide/modulo instructions

On Fri, Oct 30, 2020 at 4:07 PM Carl Love wrote: > diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c > b/gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c > new file mode 100644 > index 000..549bc742d12 > --- /dev/null > +++

[Bug fortran/93678] [8/9/10/11 Regression] ICE with TRANSFER and typebound procedures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678 --- Comment #9 from anlauf at gcc dot gnu.org --- Another data point: comparing the -fdump-fortran-original of res = b_unpackbytes (me) ! ok vs. res = me% unpackbytes () ! ICE I see: ASSIGN b_unpackint:res(FULL)

[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 Jonathan Wakely changed: What|Removed |Added Target Milestone|11.0|---

Re: [PATCH] PowerPC: Don't assume all targets have GLIBC

On Fri, Oct 30, 2020 at 04:00:30PM -0400, Michael Meissner wrote: > On Fri, Oct 30, 2020 at 01:52:13PM -0500, Segher Boessenkool wrote: > > On Fri, Oct 30, 2020 at 01:21:34PM -0400, Michael Meissner wrote: > > > David reminded me that not all targets support GLIBC. This patch should > > > fix my

[Bug fortran/93678] [8/9/10/11 Regression] ICE with TRANSFER and typebound procedures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678 --- Comment #8 from anlauf at gcc dot gnu.org --- Further reduced: module mo_a implicit none type t_b contains procedure :: unpackbytes => b_unpackbytes end type t_b contains function b_unpackbytes (me) result (res)

[Bug d/97644] FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644 --- Comment #5 from Iain Buclaw --- Without doing any bisecting, r11-4572 looks very suspect for the cause of the segmentation fault.

Re: [PATCH] c++: Disable -Winit-list-lifetime in unevaluated operand [PR97632]

On 10/29/20 10:35 PM, Marek Polacek wrote: Jon suggested turning this warning off when we're not actually evaluating the operand. This patch does that. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? OK. gcc/cp/ChangeLog: PR c++/97632 * init.c (build_new_1):

Re: [PATCH v2] c++: Implement -Wvexing-parse [PR25814]

On 10/29/20 11:00 PM, Marek Polacek wrote: On Thu, Oct 29, 2020 at 02:25:33PM -0400, Jason Merrill via Gcc-patches wrote: On 10/29/20 2:11 PM, Marek Polacek wrote: On Thu, Oct 29, 2020 at 11:17:37AM -0400, Jason Merrill via Gcc-patches wrote: On 10/28/20 7:40 PM, Marek Polacek wrote: On Wed,

Re: [PATCH] c++: Tweaks for value_dependent_expression_p.

On 10/29/20 10:36 PM, Marek Polacek wrote: We may not call value_dependent_expression_p on expressions that are not potential constant expressions, otherwise value_d could crash, as I saw recently (in C++98). So beef up the checking in i_d_e_p. This revealed a curious issue: when we have

[Bug fortran/93678] [8/9/10/11 Regression] ICE with TRANSFER and typebound procedures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678 --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #5) > A somewhat smaller test case, which of course does nothing useful, > but still reproduces the ICE: Further reduced / simplified: module mo_a

[Bug target/97323] [10/11 Regression] ICE 'verify_type' failed on arm-linux-gnueabihf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97323 --- Comment #10 from Richard Henderson --- Created attachment 49473 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49473=edit rfc patch The following fixes the ICE. It seems like a hack, done at the wrong level. Should we have in fact

[Bug d/97644] FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644 --- Comment #4 from Iain Buclaw --- (In reply to Iain Buclaw from comment #3) > I haven't seen any failures as of r11-4466. So a regression cropped up over > the last couple days maybe? Actually, make that r11-4555 being the last commit

[Bug d/97644] FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644 --- Comment #3 from Iain Buclaw --- I haven't seen any failures as of r11-4466. So a regression cropped up over the last couple days maybe?

[PATCH] rs6000, vector integer multiply/divide/modulo instructions

GCC maintainers: The following patch adds new builtins for the vector integer multiply, divide and modulo operations. The builtins are: vec_mulh(), vec_div(), vec_dive(), vec_mod() for signed and unsigned integers and long long integers. Support for signed and unsigned long long integers the

Re: [PATCH] i386: Cleanup i386/i386elf.h and align it's return convention with the SVR4 ABI

> As observed a number of years ago in the following thread, i386/i386elf.h has > not been > kept up to date: > > https://gcc.gnu.org/pipermail/gcc/2013-August/209981.html > > This patch does the following cleanup: > > 1. The return convention now follows the i386 and x86_64 SVR4 ABIs again. As

Re: [PATCH] PowerPC: Don't assume all targets have GLIBC

On Fri, Oct 30, 2020 at 01:52:13PM -0500, Segher Boessenkool wrote: > On Fri, Oct 30, 2020 at 01:21:34PM -0400, Michael Meissner wrote: > > David reminded me that not all targets support GLIBC. This patch should > > fix my > > previous committed patch not to use TARGET_GLIBC_MAJOR or

[Bug c++/97648] New: Rejects valid direct initialization from prvalue (private destructor)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97648 Bug ID: 97648 Summary: Rejects valid direct initialization from prvalue (private destructor) Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal

[Bug c++/86373] Destructor shall not be instantiated in C++17 mode for prvalue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86373 Lénárd Szolnoki changed: What|Removed |Added CC||leni536 at gmail dot com --- Comment

Re: [PATCH] aarch64: Add backend support for expanding __builtin_memset

Sudakshina Das writes: >> > + >> > + /* "Cast" the *dst to the correct mode. */ >> > + *dst = adjust_address (*dst, mode, 0); >> > + /* Emit the memset. */ >> > + emit_move_insn (*dst, reg); >> > + /* Move the pointer forward. */ >> > + *dst = aarch64_progress_pointer (*dst); } >> > + >>

[Bug libfortran/97581] libgfortran/intrinsics/random.c:754: bad array size ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97581 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug libfortran/97581] libgfortran/intrinsics/random.c:754: bad array size ?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97581 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:667db6dedd80487663c29b21efa942f661b569a8 commit r11-4579-g667db6dedd80487663c29b21efa942f661b569a8 Author: Harald Anlauf Date:

Re: [PATCH][middle-end][i386][version 6]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

FYI. I just committed the patch to gcc11 as: https://gcc.gnu.org/pipermail/gcc-cvs/2020-October/336263.html Qing

Re: [PATCH] i386: Set the stack usage to 0 for naked functions

> -fstack-usage raises a "stack usage computation not supported for this target" > warning when it encounters a naked function because the prologue returns early > for naked function on i386. This patch sets the stack usage to zero for naked > function, following the fix done for Arm by Eric

[Bug target/97323] [10/11 Regression] ICE 'verify_type' failed on arm-linux-gnueabihf

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97323 --- Comment #9 from Richard Henderson --- As a data point, this problem can be seen with any strict-alignment target -- e.g. sparc.

[patch] Fixing ppc64 test failure after patch dealing with scratches in IRA

  The following patch fixes failures for test p9-extract-2.c on ppc64.  The failures are a result of committing patch dealing with insn scratches in IRA.  The pseudo corresponding the 1st scratch in the following insn get unexpected register class (general regs) and unexpected insn alternative

[Bug tree-optimization/97556] [11 Regression] ICE at -O2 and -O3 in 32-bit mode on x86_64-pc-linux-gnu in size_remaining, at builtins.c:235 since r11-3827

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

[committed] avoid creating inverted ranges in access_ref::add_offset (PR 97556)

access_ref::add_offset() works hard to restore the property that the lower bound of a range is less than or equal to its upper bound. But by capping the upper bound to at most PTRDIFF_MAX without also considering the lower bound, it allows the latter to exceed the value of the former, thus

[committed] patch to deal with insn scratches in global RA

 The following patch implements taking insn scratch requirements into account in global RA (IRA).  Before the patch IRA simply ignored insn scratches.  Only LRA took the scratches into account and assigned hard registers to scratches if neccessary.  In some cases it resulted in spilling pseudos

[Bug c++/97647] New: Accepts undefined delete expression in constant expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97647 Bug ID: 97647 Summary: Accepts undefined delete expression in constant expression Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal

[Bug tree-optimization/97556] [11 Regression] ICE at -O2 and -O3 in 32-bit mode on x86_64-pc-linux-gnu in size_remaining, at builtins.c:235 since r11-3827

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97556 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:bdf6524bc0bfa0908a7a7c52e799dbecbebaefe8 commit r11-4576-gbdf6524bc0bfa0908a7a7c52e799dbecbebaefe8 Author: Martin Sebor Date: Fri

[Bug d/97644] FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644 --- Comment #2 from Martin Sebor --- Also same ICE in: FAIL: gdc.test/runnable_cxx/cppa.d (internal compiler error)

[Bug c++/97646] New: FAIL: obj-c++.dg/template-4.mm due to ICE in n potential_constant_expression_1, at cp/constexpr.c:8417

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97646 Bug ID: 97646 Summary: FAIL: obj-c++.dg/template-4.mm due to ICE in n potential_constant_expression_1, at cp/constexpr.c:8417 Product: gcc Version: unknown

[Bug c++/97645] New: Rejects valid subscript expression on array of unknown bound in constant expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97645 Bug ID: 97645 Summary: Rejects valid subscript expression on array of unknown bound in constant expression Product: gcc Version: 11.0 Status: UNCONFIRMED

ipa-cp: New debug counters for IPA-CP

Hi, Martin Liška has been asking me to add debug counters to the IPA-CP pass so that testcase reductions are easier. The pass already has one for the bit value propagation, so this patch adds one for value_range propagation and one for the actual constant propagation. Passed bootstrap and

[Bug d/97644] FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644 --- Comment #1 from Martin Sebor --- Ditto in gdc.dg/pr92216.d: /ssd/test/src/gcc/97556/gcc/testsuite/gdc.dg/pr92216.d:10:1: internal compiler error: Segmentation fault 0xe979da crash_signal /ssd/test/src/gcc/97556/gcc/toplev.c:330

[Bug d/97644] New: FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644 Bug ID: 97644 Summary: FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3

Re: [PATCH] PowerPC: Don't assume all targets have GLIBC

On Fri, Oct 30, 2020 at 01:21:34PM -0400, Michael Meissner wrote: > David reminded me that not all targets support GLIBC. This patch should fix > my > previous committed patch not to use TARGET_GLIBC_MAJOR or TARGET_GLIBC_MINOR > unless they are defined. > + This support is only in little

Re: [PATCH] Fix gnu-versioned-namespace build

On 30/10/20 18:51 +0100, François Dumont wrote: On 30/10/20 2:37 pm, Jonathan Wakely wrote: On 30/10/20 13:23 +, Jonathan Wakely wrote: On 30/10/20 13:59 +0100, François Dumont via Libstdc++ wrote: The gnu-versioned-namespace build is broken. The fix in charconv/floating_from_chars.cc

[Bug c++/97643] New: Accepts invalid qualification conversion involving array of unknown bound [P0388]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97643 Bug ID: 97643 Summary: Accepts invalid qualification conversion involving array of unknown bound [P0388] Product: gcc Version: 11.0 Status: UNCONFIRMED

Re: [PATCH] rs6000, Add bcd builtings listed in appendix B of the ABI

Hi! On Fri, Oct 30, 2020 at 09:36:13AM -0700, Carl Love wrote: > On Wed, 2020-10-28 at 20:43 -0400, David Edelsohn wrote: > > Better, but please use > > > > /* { dg-require-effective-target int128 } */ > > > > not "target int128" in the selector. Segher and I both agree that > > it's cleaner

RE: [PATCH] aarch64: Add backend support for expanding __builtin_memset

Hi Richard Thank you for the review. Please find my comments inlined. > -Original Message- > From: Richard Sandiford > Sent: 30 October 2020 15:03 > To: Sudakshina Das > Cc: gcc-patches@gcc.gnu.org; Kyrylo Tkachov ; > Richard Earnshaw > Subject: Re: [PATCH] aarch64: Add backend

[Bug c++/97642] Incorrect replacement of vmovdqu32 with vpblendd can cause fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97642 --- Comment #2 from Jakub Jelinek --- The testcase is: #include #include #include #include #define N 5 // Faults with GCC because usage of vpblendd __m256i __attribute__((noinline)) mask_load(uint32_t * arr) { __m256i tmp; return

[Bug c++/97642] Incorrect replacement of vmovdqu32 with vpblendd can cause fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97642 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 CC|

Re: [PATCH] Fix gnu-versioned-namespace build

On 30/10/20 2:37 pm, Jonathan Wakely wrote: On 30/10/20 13:23 +, Jonathan Wakely wrote: On 30/10/20 13:59 +0100, François Dumont via Libstdc++ wrote: The gnu-versioned-namespace build is broken. The fix in charconv/floating_from_chars.cc is quite trivial. I am not so sure about the fix

Dead Field Elimination and Field Reordering

Hello again, I've been working on several implementations of data layout optimizations for GCC, and I am again kindly requesting for a review of the type escape based dead field elimination and field reorg. Thanks to everyone that has helped me. The main differences between the previous

Re: [PATCH] rs6000, Add bcd builtings listed in appendix B of the ABI

On Fri, Oct 30, 2020 at 12:36 PM Carl Love wrote: > > David: > > On Wed, 2020-10-28 at 20:43 -0400, David Edelsohn wrote: > > Better, but please use > > > > /* { dg-require-effective-target int128 } */ > > > > not "target int128" in the selector. Segher and I both agree that > > it's cleaner and

[PATCH] PowerPC: Don't assume all targets have GLIBC

PowerPC: Don't assume all targets have GLIBC. David reminded me that not all targets support GLIBC. This patch should fix my previous committed patch not to use TARGET_GLIBC_MAJOR or TARGET_GLIBC_MINOR unless they are defined. I have done a bootstrap on a little endian power9 system and it was

Time for std::bit_cast

Thank you! Jakub. YES to std::bit_cast Sent from Mail for Windows 10

Re: [nvptx, committed] Force vl32 if calling vector-partitionable routines

Hi Tom! On 2019-01-07T20:11:59+0100, Tom de Vries wrote: > [nvptx] Force vl32 if calling vector-partitionable routines > > With PTX_MAX_VECTOR_LENGTH set to larger than PTX_WARP_SIZE, routines can be > called from offloading regions with vector-size set to larger than warp size. > OTOH,

[Bug tree-optimization/97556] [11 Regression] ICE at -O2 and -O3 in 32-bit mode on x86_64-pc-linux-gnu in size_remaining, at builtins.c:235 since r11-3827

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97556 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org

[Bug c++/89605] A method cannot have two identical lambdas as default arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89605 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org,

RE: [PATCH] rs6000, Add bcd builtings listed in appendix B of the ABI

David: On Wed, 2020-10-28 at 20:43 -0400, David Edelsohn wrote: > Better, but please use > > /* { dg-require-effective-target int128 } */ > > not "target int128" in the selector. Segher and I both agree that > it's cleaner and more readable. The selector (the target part on the > dg-do line)

[Bug c++/97642] New: Incorrect replacement of vmovdqu32 with vpblendd can cause fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97642 Bug ID: 97642 Summary: Incorrect replacement of vmovdqu32 with vpblendd can cause fault Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal

Re: [PATCH 6/9] [nvptx] Force vl32 if calling vector-partitionable routines -- test-cases

On 10/30/20 5:16 PM, Thomas Schwinge wrote: > Hi Tom! > > While working on something completely different, I had to dig deeper, and > noticed a thing there, and deeper, and notice another thing, and deeper, > and noticed this other thing here... (So, business as usual...) ;-) > > On

[Bug c++/97641] Wrong codegen if optimizer is enabled

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

Re: [PATCH 6/9] [nvptx] Force vl32 if calling vector-partitionable routines -- test-cases

Hi Tom! While working on something completely different, I had to dig deeper, and noticed a thing there, and deeper, and notice another thing, and deeper, and noticed this other thing here... (So, business as usual...) ;-) On 2019-01-12T23:21:28+0100, Tom de Vries wrote: > --- /dev/null > +++

[Bug c++/97641] Wrong codegen if optimizer is enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97641 --- Comment #7 from Dmitriy Ovdienko --- If I change the body of the loop like this, it also works ``` while ('\x01' != *ptr) { result = result * 10 - '0' + *ptr++; } ``` Looks like integer overflow happens on last iteration and compiler

[Patch, committed] – was: [Patch] testsuite: Avoid TCL errors when rootme or ASAN/TSAN/UBSAN is not available

I have now committed it as obvious. Tobias On 19.10.20 18:03, Tobias Burnus wrote: [...] On 10/19/20 11:46 AM, Tobias Burnus wrote: In a --disable-libsanitizer build, I see errors such as: g++.sum:ERROR: can't read "asan_saved_library_path": no such variable [...] - Mentor

[Bug c++/97641] Wrong codegen if optimizer is enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97641 --- Comment #6 from Dmitriy Ovdienko --- This code does not work ``` #include int Parse1(char const* ptr) noexcept { int result = 0; while ('\x01' != *ptr) { result = result * 10 + *ptr++ - '0'; } return result; }

[Bug c++/97641] Wrong codegen if optimizer is enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97641 Dmitriy Ovdienko changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED

[Bug c++/97641] Wrong codegen if optimizer is enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97641 --- Comment #4 from Dmitriy Ovdienko --- It happens to 2147483646, 2147483647 and std::numeric_limits::min().

[Bug c++/97641] Wrong codegen if optimizer is enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97641 --- Comment #3 from Jakub Jelinek --- Use -fsanitize=undefined to get it diagnosed at runtime. Although, that routine doesn't handle even Parse1("2147483631\x01") etc. correctly. Just use unsigned int result = 0;

[Bug c++/97641] Wrong codegen if optimizer is enabled

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

[Bug c++/97641] Wrong codegen if optimizer is enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97641 --- Comment #1 from Dmitriy Ovdienko --- OS: Windows 10 Distribution: MSys2 (https://www.msys2.org/) Version: (Rev4, Built by MSYS2 project) 10.2.0 I tried to reproduce this issue on https://gcc.godbolt.org/. gcc (trunk) is also unable to

[Bug c++/97641] New: Wrong codegen if optimizer is enabled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97641 Bug ID: 97641 Summary: Wrong codegen if optimizer is enabled Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

Re: [PATCH v7] genemit.c (main): split insn-emit.c for compiling parallelly

Jojo R writes: > Jojo > 在 2020年10月27日 +0800 PM10:14，Richard Sandiford ，写道： >> Jojo R writes: >> > gcc/ChangeLog: >> > >> > * genemit.c (main): Print 'split line'. >> > * Makefile.in (insn-emit.c): Define split count and file >> > >> > --- >> > gcc/Makefile.in | 19 + >> > gcc/genemit.c |

[Bug c/97493] generate wrong code with "-Os -fno-toplevel-reorder -frename-registers"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97493 --- Comment #5 from suochenyao at 163 dot com --- *** I think this can be reproduced with "-fno-strict-aliasing"... I am not sure whether it can be helpful...

[Bug tree-optimization/97520] ICE in calc_stmt, at gimple-range.cc:399 with "-O1 -fno-tree-fre -ftree-vrp"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97520 --- Comment #6 from suochenyao at 163 dot com --- (In reply to suochen...@163.com from comment #5) > * > ** > I think this can be reproduced with

[Bug tree-optimization/97520] ICE in calc_stmt, at gimple-range.cc:399 with "-O1 -fno-tree-fre -ftree-vrp"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97520 --- Comment #5 from suochenyao at 163 dot com --- *** I think this can be reproduced with "-fno-strict-aliasing"... I am not sure whether it can be helpful...

Re: Implementing OpenMP 5.0 requires directive

On Fri, Oct 30, 2020 at 10:48:09PM +0800, Chung-Lin Tang wrote: > We've been going over how we should implement the requires directive, in a > bit more complete > sense than the current state (i.e. only atomic_default_mem_order working). > > For the three clauses where the specification requires

[Bug bootstrap/97622] ubsan ' unterminated quote character ''' in format

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97622 --- Comment #6 from Jakub Jelinek --- There are still 81 warnings on x86_64-linux at unique spots during bootstrap more than a year after the warning has been added, and at least several of those aren't really bugs in the code, so the question

[PATCH] libstdc++: Don't initialize from *this inside some views [PR97600]

This works around a subtle issue where instantiating the begin()/end() member of some views (as part of return type deduction) inadvertently requires computing the satisfaction value of range. This is problematic because the constraint range requires the begin()/end() member to be callable. But

Re: [PATCH] aarch64: Add backend support for expanding __builtin_memset

Sudakshina Das writes: > diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h > index > 00b5f8438863bb52c348cfafd5d4db478fe248a7..bcb654809c9662db0f51fc1368e37e42969efd29 > 100644 > --- a/gcc/config/aarch64/aarch64.h > +++ b/gcc/config/aarch64/aarch64.h > @@ -1024,16

[Bug bootstrap/97622] ubsan ' unterminated quote character ''' in format

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97622 Martin Sebor changed: What|Removed |Added Resolution|INVALID |--- Keywords|

Implementing OpenMP 5.0 requires directive

Hi Jakub, We've been going over how we should implement the requires directive, in a bit more complete sense than the current state (i.e. only atomic_default_mem_order working). For the three clauses where the specification requires that "must appear in all compilation units of a program that

  1   2   >