[Bug c/96460] Warn about signed modulo that is converted to unsigned value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96460 --- Comment #4 from Florian Weimer --- (In reply to Eric Gallager from comment #3) > There already is a warning from -Wsign-conversion for it: It's for the conversion, not the modulo. My hypothesis is that for the modulo, the warning is much

[Bug c++/96515] New: [concepts] Segfault on ill-formed pack expansions in requires-expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96515 Bug ID: 96515 Summary: [concepts] Segfault on ill-formed pack expansions in requires-expression Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal

Re: [RS6000] PR96493, powerpc local call linkage failure

On Thu, Aug 06, 2020 at 05:34:03PM -0500, Segher Boessenkool wrote: > > +/* { dg-do run } */ > > +/* { dg-options "-mdejagnu-cpu=powerpc64 -O2" } */ > > That is not a -mcpu= value you should ever use. Please just pick a real > existing CPU, maybe p7 or p8 since this requires ELFv2 anyway? Or,

[Bug target/96493] powerpc local call linkage failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493 --- Comment #3 from CVS Commits --- The master branch has been updated by Alan Modra : https://gcc.gnu.org/g:f8ac30f1653ff69706c35af6d725f1d330600f11 commit r11-2603-gf8ac30f1653ff69706c35af6d725f1d330600f11 Author: Alan Modra Date: Thu Aug

[Bug fortran/96486] get_environment_variable fails for zero-length values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #18 from kargl at gcc dot gnu.org --- Created attachment 49015 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49015=edit Bring get_environment_variable almost to F2018 conformance * check.c (gfc_check_get_environment_variable):

Re: [PATCH/RFC] options: Make --help= to emit values post-overrided

Hi Segher! Thanks for the comments! on 2020/8/7 上午6:04, Segher Boessenkool wrote: > Hi! > > On Thu, Aug 06, 2020 at 08:37:23PM +0800, Kewen.Lin wrote: >> When I was working to update patch as Richard's review comments >> here https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551474.html， >>

[Bug middle-end/39398] verify_flow_info failed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39398 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #4

[Bug tree-optimization/96514] New: [9/10/11 Regression] ICE: verify_flow_info failed (error: control flow in the middle of basic block 3)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96514 Bug ID: 96514 Summary: [9/10/11 Regression] ICE: verify_flow_info failed (error: control flow in the middle of basic block 3) Product: gcc Version: 11.0 Status:

[Bug c/96513] New: building terminated with -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96513 Bug ID: 96513 Summary: building terminated with -O3 Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[PATCH] bb-reorder: Remove a misfiring micro-optimization (PR96475)

When the compgotos pass copies the tail of blocks ending in an indirect jump, there is a micro-optimization to not copy the last one, since the original block will then just be deleted. This does not work properly if cleanup_cfg does not merge all pairs of blocks we expect it to. 2020-08-07

A problem with DECL_FIELD_OFFSET in something I declared

This problem is from my structure reorganization optimization optimization code (simplified and cleaned to illustrate the problem. Here's what happening below at the high level >From the user program: typedef struct type type_t; struct type { double x; double y; }: I'll be creating:

[Bug tree-optimization/96512] wrong code generated with avx512 intrinsics in some cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96512 --- Comment #1 from N Schaeffer --- Created attachment 49014 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49014=edit even simpler bug demonstrator

[Bug tree-optimization/96512] New: wrong code generated with avx512 intrinsics in some cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96512 Bug ID: 96512 Summary: wrong code generated with avx512 intrinsics in some cases Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal

[Bug target/96493] powerpc local call linkage failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493 --- Comment #2 from Alan Modra --- Yes, it is a bug present in any gcc version supporting pcrel.

[Bug fortran/96486] get_environment_variable fails for zero-length values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #17 from Steve Kargl --- On Thu, Aug 06, 2020 at 08:33:12PM +, jussilehtola at fedoraproject dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 > > --- Comment #16 from Susi Lehtola --- > Yes, then I installed

Re: RFC: Monitoring old PRs, new dg directives

On Aug 6, 2020, at 7:01 AM, Nathan Sidwell wrote: > >> XFAIL: g++.dg/foo.C -std=c++17 (internal compiler error) >> PASS: g++.dg/foo.C -std=c++17 (test for excess errors) >> Which one of these would you not like to see? > > Neither of these is solving the issue. How do I find the ICES that

mmix: fix gcc.dg/loop-9.c by more accurate move insns

Committed. It looks like gcc.dg/loop-9.c kind-of works as sentinel for sane move-instruction generation for a port. Looking at the FAIL: gcc.dg/loop-9.c scan-rtl-dump loop2_invariant "Decided" FAIL: gcc.dg/loop-9.c scan-rtl-dump loop2_invariant "without introducing a new temporary register" it

Re: [PATCH][testsuite] Add gcc.dg/ia64-sync-5.c

On Aug 6, 2020, at 5:23 AM, Tom de Vries wrote: > > There currently is no sync_char_short-enabled run test that tests > __sync_val_compare_and_swap. > > OK for trunk? Ok.

[Bug c++/96511] New: Incorrect placement-new warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96511 Bug ID: 96511 Summary: Incorrect placement-new warning Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475 --- Comment #6 from Segher Boessenkool --- I have a patch (since yesterday; just no time to send it :-/ )

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Hi! On Thu, Aug 06, 2020 at 10:31:27AM +0200, Richard Biener wrote: > Jeff might be, but with the intended purpose (ROP mitigation AFAIU) > it would be nice for other target maintainers to chime in (Segher for > power maybe) for the question below... It would be nice if this described anywhere

[Bug c++/96510] New: Unexpected constexpr deallocation error after implicit conversion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96510 Bug ID: 96510 Summary: Unexpected constexpr deallocation error after implicit conversion Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal

[Bug c/96460] Warn about signed modulo that is converted to unsigned value

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96460 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org

[Bug c/96468] Warn when an empty while loop could have been a do-while

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96468 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org ---

Re: RFC: Monitoring old PRs, new dg directives

On Thu, Aug 06, 2020 at 10:01:37AM -0400, Nathan Sidwell wrote: > On 8/5/20 7:29 PM, Marek Polacek wrote: > > On Wed, Aug 05, 2020 at 11:03:08AM -0400, Nathan Sidwell wrote: > > > On 8/4/20 8:54 PM, Marek Polacek via Gcc-patches wrote: > > > > On Tue, Aug 04, 2020 at 03:33:23PM -0700, Mike Stump

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #7 from John Paul Adrian Glaubitz --- > I'd be really grateful for advice on how to test and improve this. Is there a > test suite somewhere that I've missed? Ideally, one that works with a free > simulator? Probably best to ask

gcc-8-20200806 is now available

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

Re: [RS6000] PR96493, powerpc local call linkage failure

Hi! On Thu, Aug 06, 2020 at 10:58:18PM +0930, Alan Modra wrote: > This corrects current_file_function_operand, an operand predicate used > to determine whether a symbol_ref is safe to use with the local_call > patterns. Calls between pcrel and non-pcrel code need to go via > linker stubs. In

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Hi, Richard, > On Aug 5, 2020, at 4:35 PM, Qing Zhao via Gcc-patches > wrote: > > >> >> + continue; >> + if (fixed_regs[regno]) >> + continue; >> + if (is_live_reg_at_exit (regno)) >> + continue; >> >> How can a call-used reg be live at exit? > >

Re: [PATCH/RFC] options: Make --help= to emit values post-overrided

Hi! On Thu, Aug 06, 2020 at 08:37:23PM +0800, Kewen.Lin wrote: > When I was working to update patch as Richard's review comments > here https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551474.html， > I noticed that the options "-Q --help=params" don't show the final values > after target

Re: GCC 10.2: Spurious(?) stringop-overflow warning (not strlen/strcpy/etc.)

On 8/6/20 2:14 PM, Martin Sebor wrote: On 8/3/20 10:58 PM, Paul Smith wrote: On Mon, 2020-08-03 at 17:02 -0600, Martin Sebor wrote: If the code is designed to treat Node sort of like a struct with a flexible array member I would suggest to make that explicit by adding a zero-element array

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

On Thu, Aug 06, 2020 at 10:37:43AM +0200, Richard Biener wrote: > OK, so -fzero-call-used-regs is a ROP mitigation technique. To me > it sounded more like a mitigation against information leaks which > then would be highly incomplete w/o spill slot clearing. Like > we had that discussion on

[Bug fortran/96486] get_environment_variable fails for zero-length values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #16 from Susi Lehtola --- Yes, then I installed missing libgfortran debuginfos and the backtrace shortened to #0 0x401267 in zerolen_value at /tmp/readvar2.f90:17 #1 0x4012c4 in main at /tmp/readvar2.f90:22

[Bug libstdc++/96484] Horrible performance of std::read_symlink

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

[Bug libstdc++/96484] Horrible performance of std::read_symlink

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96484 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8b692f8b4c0e47bc8e11d9c3ab83049f68b2edbc commit r8-10390-g8b692f8b4c0e47bc8e11d9c3ab83049f68b2edbc Author: Jonathan

[Bug libstdc++/96484] Horrible performance of std::read_symlink

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96484 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f86f80dbccece356fa5ca7e1fd4dc581cc6a1cc4 commit r9-8787-gf86f80dbccece356fa5ca7e1fd4dc581cc6a1cc4 Author: Jonathan Wakely

[Bug libstdc++/96484] Horrible performance of std::read_symlink

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96484 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8b7e7fcb5fff8255122a8fa94109f7ae05aeaa81 commit r10-8581-g8b7e7fcb5fff8255122a8fa94109f7ae05aeaa81 Author: Jonathan

Re: [PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

On Thu, 6 Aug 2020, Maciej W. Rozycki via Gcc-patches wrote: > Given that for the `riscv64-linux-gnu' target and the ilp32d multilib > glibc currently fails to link against libgcc.a built at -O0 I first ran > reference testing with target libraries built at -O2, but comparing that > to

Re: GCC 10.2: Spurious(?) stringop-overflow warning (not strlen/strcpy/etc.)

On 8/3/20 10:58 PM, Paul Smith wrote: On Mon, 2020-08-03 at 17:02 -0600, Martin Sebor wrote: If the code is designed to treat Node sort of like a struct with a flexible array member I would suggest to make that explicit by adding a zero-element array member to Node and using it to access other

Re: [PATCH] libgccjit: Add new gcc_jit_context_new_blob entry point

On Mon, 2020-08-03 at 10:07 +0200, Andrea Corallo wrote: > David Malcolm writes: > > > On Fri, 2020-07-24 at 18:05 -0400, David Malcolm via Gcc-patches wrote: > > > > [...] > > > >> I haven't thought this through in detail, and I'm not sure exactly > >> how > >> it would work for arbitrary

[Bug libstdc++/96161] istream::ignore sets eofbit too soon

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96161 --- Comment #3 from Jonathan Wakely --- See also g:4e39f563c0cd25401f689c2093cb8c13692156ef

[Bug c++/96497] Compare std::variant with int using C++20 <=> is not a constant expression

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

Re: std::vector code cleanup fixes optimizations

On 06/08/20 21:30 +0200, François Dumont via Libstdc++ wrote: I wonder if following the application of this patch we shouldn't bump versioned namespace through _GLIBCXX_BEGIN_NAMESPACE_VERSION ? Definitely not. Unless it is still considered as experimental. Yes, it is. And it doesn't

Re: [PATCH] Rewrite get_size_range for irange API.

On 8/6/20 8:53 AM, Aldy Hernandez via Gcc-patches wrote: [Martin, does this sound reasonable to you?] It mostly makes sense to me except one part: The following patch converts get_size_range to the irange API, thus removing the use of VR_ANTI_RANGE. This was a bit tricky because of the

Re: std::vector code cleanup fixes optimizations

I wonder if following the application of this patch we shouldn't bump versioned namespace through _GLIBCXX_BEGIN_NAMESPACE_VERSION ? Unless it is still considered as experimental. François On 31/07/20 11:03 pm, François Dumont wrote: On 17/07/20 12:36 pm, Jonathan Wakely wrote: On 16/12/19

Re: std:vec for classes with constructor?

On 06/08/20 19:58 +0200, Aldy Hernandez wrote: On 8/6/20 6:30 PM, Jonathan Wakely wrote: On 06/08/20 16:17 +0200, Aldy Hernandez wrote: On 8/6/20 12:48 PM, Jonathan Wakely wrote: On 06/08/20 12:31 +0200, Richard Biener wrote: On Thu, Aug 6, 2020 at 12:19 PM Jonathan Wakely wrote: On

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 06/08/20 12:45 -0600, Martin Sebor via Libstdc++ wrote: On 8/6/20 10:00 AM, Jonathan Wakely wrote: On 06/08/20 09:17 -0600, Martin Sebor via Libstdc++ wrote: Sorry.  I don't see this exercise as a complete waste of time (but I understand why it feels like that to you). What it highlights

[Bug c++/85282] CWG 727 (full specialization in non-namespace scope)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2019-09-08 00:00:00 |2020-8-6 --- Comment #11 from

[Bug c++/96489] Three way comparison operator failure to synthesize traditional comparitors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96489 --- Comment #8 from Jonathan Wakely --- (In reply to DV Henkel-Wallace from comment #7) > Thanks. That is clear. > > BTW FWIW, defining <=> myself and then defining == default does appear to do > what I want (i.e. I don't have to use. =

[Bug tree-optimization/96509] out of bounds access silently makes a bounded loop infinite with inlining

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96509 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Summary|out of

Re: [PATCH] Implement P0966 std::string::reserve should not shrink

On 30/07/20 16:39 +0100, Jonathan Wakely wrote: On 30/07/20 15:29 +0100, Jonathan Wakely wrote: On 12/05/19 21:22 +, Andrew Luo wrote: It's been a while, but thought I'd check in again now that GCC 9 has been branched, and master is now on GCC 10. I've merged my changes with the latest

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 8/6/20 10:00 AM, Jonathan Wakely wrote: On 06/08/20 09:17 -0600, Martin Sebor via Libstdc++ wrote: Sorry.  I don't see this exercise as a complete waste of time (but I understand why it feels like that to you). What it highlights is the fact that the warning infrastructure we have in place

[Bug tree-optimization/96509] New: out of bounds access makes a bounded loop infinite with inlining

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96509 Bug ID: 96509 Summary: out of bounds access makes a bounded loop infinite with inlining Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal

[committed] libstdc++: Do not set eofbit eagerly in operator>>(istream&, char(&)[N])

Similar to the bugs I fixed recently in istream::ignore, we incorrectly set eofbit too often in operator>>(istream&, string&) and operator>>(istream&. char(&)[N]). We should only set eofbit if we reach EOF but would have kept going otherwise. If we've already extracted the maximum number of

[Bug target/96191] aarch64 stack_protect_test canary leak

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:6a3f3e08723063ea2dadb7ddf503f02972a724e2 commit r11-2598-g6a3f3e08723063ea2dadb7ddf503f02972a724e2 Author: Richard Sandiford

[Bug tree-optimization/96146] VRP turns a terminating loop into an infinite loop

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

Re: [PATCH] Power10: Add BRH, BRW, BRD support.

On Tue, Aug 04, 2020 at 10:40:15PM -0400, Michael Meissner wrote: > The power10 processor adds 3 new instructions (BRH, BRW, BRD) that byte swaps > half-words, words, and double-words within a GPR register. The brh insn reverses the bytes in each of four 16-bit words in a GPR, but this patch only

Re: VEC_COND_EXPR optimizations v2

On Thu, 6 Aug 2020, Christophe Lyon wrote: Was I on the right track configuring with --target=arm-none-linux-gnueabihf --with-cpu=cortex-a9 --with-fpu=neon-fp16 then compiling without any special option? Maybe you also need --with-float=hard, I don't remember if it's implied by the 'hf'

[Bug c++/96223] DR 1787 and indeterminate values in constexpr context

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96223 Marek Polacek changed: What|Removed |Added Keywords|rejects-valid | Assignee|unassigned at gcc

Re: std:vec for classes with constructor?

On 8/6/20 6:30 PM, Jonathan Wakely wrote: On 06/08/20 16:17 +0200, Aldy Hernandez wrote: On 8/6/20 12:48 PM, Jonathan Wakely wrote: On 06/08/20 12:31 +0200, Richard Biener wrote: On Thu, Aug 6, 2020 at 12:19 PM Jonathan Wakely wrote: On 06/08/20 06:16 +0100, Richard Sandiford wrote:

[Bug c++/96223] DR 1787 and indeterminate values in constexpr context

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96223 Richard Smith changed: What|Removed |Added CC||richard-gccbugzilla@metafoo

[PATCH] c++: constraints and address of template-id

When resolving the address of a template-id, we need to drop functions whose associated constraints are not satisfied, as per [over.over]. We do so in resolve_address_of_overloaded_function, but not in resolve_overloaded_unification or resolve_nondeduced_context, which seems like an oversight.

[PATCH] c++: Improve RANGE_EXPR optimization in cxx_eval_vec_init

This patch eliminates an exponential dependence in cxx_eval_vec_init on the array dimension of a VEC_INIT_EXPR when the RANGE_EXPR optimization applies. This is achieved by using a single constructor_elt (with index RANGE_EXPR 0...max-1) per dimension instead of two constructor_elts (with index 0

[committed] libstdc++: Fix unnecessary allocations in read_symlink [PR 96484]

libstdc++-v3/ChangeLog: PR libstdc++/96484 * src/c++17/fs_ops.cc (fs::read_symlink): Return an error immediately for non-symlinks. * src/filesystem/ops.cc (fs::read_symlink): Likewise. Tested x86_64-linux. Committed to trunk. Backports to follow. commit

[Bug libstdc++/96484] Horrible performance of std::read_symlink

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96484 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6a13a4e3f29fc4ce5eff96d74ba965c9fdc02184 commit r11-2597-g6a13a4e3f29fc4ce5eff96d74ba965c9fdc02184 Author: Jonathan Wakely Date:

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 06/08/20 14:14 +0100, Jonathan Wakely wrote: On 05/08/20 16:31 -0600, Martin Sebor via Libstdc++ wrote: On 8/5/20 3:25 PM, Jonathan Wakely wrote: P0487R1 resolved LWG 2499 for C++20 by removing the operator>> overloads that have high risk of buffer overflows. They were replaced by

[Bug c++/96501] [C++11] Should warn when classes only have copy constructor defined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96501 --- Comment #2 from Jonathan Wakely --- Also, how would users suppress this warning for cases where it's not wanted? Plenty of classes don't need a move constructor because moving is not more efficient than copying, but they don't want a

[Bug middle-end/96508] New: missing warning for invalid calls to builtins from inline functions defined in system headers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96508 Bug ID: 96508 Summary: missing warning for invalid calls to builtins from inline functions defined in system headers Product: gcc Version: 11.0 Status: UNCONFIRMED

[Bug c++/96489] Three way comparison operator failure to synthesize traditional comparitors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96489 --- Comment #7 from DV Henkel-Wallace --- Thanks. That is clear. BTW FWIW, defining <=> myself and then defining == default does appear to do what I want (i.e. I don't have to use. = default with both operators). I saw that cppreference

[Bug c++/96501] [C++11] Should warn when classes only have copy constructor defined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96501 --- Comment #1 from Jonathan Wakely --- (In reply to Nuno Lopes from comment #0) > I see a lot of old code that has copy constructors defined, but not move > constructors. This pessimizes code since the definition of the copy > constructor hides

[Bug c++/96507] New: Feature request: improve "-Waddress" (or equivalent) for function references inside structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96507 Bug ID: 96507 Summary: Feature request: improve "-Waddress" (or equivalent) for function references inside structs Product: gcc Version: unknown Status: UNCONFIRMED

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96475 --- Comment #5 from Mikael Pettersson --- I can't reproduce on {ppc64le, ppc64, aarch64, m68k, x86_64}-linux-gnu, they all inline the dispatcher at the end of each handler, w/ gcc-10.2.0 -O2. However, for sparc64 gcc-10.2.0 -O2 does end each

[Bug libstdc++/93502] std::regex_match uses stack space proportional to input string length

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93502 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned

[Bug libstdc++/86164] std::regex crashes when matching long lines

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

Re: std:vec for classes with constructor?

On 06/08/20 16:17 +0200, Aldy Hernandez wrote: On 8/6/20 12:48 PM, Jonathan Wakely wrote: On 06/08/20 12:31 +0200, Richard Biener wrote: On Thu, Aug 6, 2020 at 12:19 PM Jonathan Wakely wrote: On 06/08/20 06:16 +0100, Richard Sandiford wrote: Andrew MacLeod via Gcc-patches writes: On

[Bug target/96506] ICE when using an MMA type as a function param

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96506 Peter Bergner changed: What|Removed |Added Last reconfirmed||2020-08-06

[Bug target/96506] New: ICE when using an MMA type as a function param

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96506 Bug ID: 96506 Summary: ICE when using an MMA type as a function param Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug ipa/96505] New: attribute access effect lost after inlining

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96505 Bug ID: 96505 Summary: attribute access effect lost after inlining Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa

[Bug fortran/96486] get_environment_variable fails for zero-length values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #15 from Steve Kargl --- On Thu, Aug 06, 2020 at 08:42:20AM +, jussilehtola at fedoraproject dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 > > --- Comment #13 from Susi Lehtola --- > The gdb output is the

[Bug fortran/93671] gfortran 8-10 ICE on intrinsic assignment to allocatable derived-type component of coarray

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

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 06/08/20 09:17 -0600, Martin Sebor via Libstdc++ wrote: Sorry. I don't see this exercise as a complete waste of time (but I understand why it feels like that to you). What it highlights is the fact that the warning infrastructure we have in place is far from optimal for C++ in general (with

[Bug fortran/96486] get_environment_variable fails for zero-length values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486 --- Comment #14 from Steve Kargl --- On Thu, Aug 06, 2020 at 08:03:29AM +, markeggleston at gcc dot gnu.org wrote: > (In reply to kargl from comment #6) > > I do note there are other problems with get_environment_variable. > > It looks to

[Bug c++/96504] New: [coroutines] test failures with glibc-2.32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96504 Bug ID: 96504 Summary: [coroutines] test failures with glibc-2.32 Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug ipa/96503] New: attribute alloc_size effect lost after inlining

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96503 Bug ID: 96503 Summary: attribute alloc_size effect lost after inlining Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug target/96493] powerpc local call linkage failure

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493 --- Comment #1 from Peter Bergner --- We will want this backported to GCC 10 too, correct?

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Aug 6, 2020, at 3:37 AM, Richard Biener wrote: > > On Wed, 5 Aug 2020, Qing Zhao wrote: > From The SECURE project and GCC in GCC Cauldron 2018: Speaker: Graham Markall The SECURE project is a 15 month program funded by Innovate UK, to take well

[Bug ipa/96502] New: attribute malloc effect lost after inlining

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96502 Bug ID: 96502 Summary: attribute malloc effect lost after inlining Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa

Re: gcc __attribute__

On Thu, Aug 06, 2020 at 04:15:10PM +0100, Philip R Brenan via Gcc wrote: > Hi *GCC*: > > On page: > > https://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Function-Attributes.html > > you show the attribute coming after the parameter list. But when I try > this, I get the following: That manual is for

[Bug c++/96500] enum of underlying type bool does not accept enumerators with integer constant values other than 0 and 1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96500 Florian Weimer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/96446] ICE when spilling an MMA accumulator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96446 Peter Bergner changed: What|Removed |Added Target Milestone|--- |10.3 --- Comment #5 from Peter Bergner

Re: [PATCH] rs6000: Don't ICE when spilling an MMA accumulator

On 8/5/20 6:06 PM, Segher Boessenkool wrote: > You can just say > >&& reload_completed >&& !(fpr_reg_operand (operands[0], PXImode) && operands[1] == const0_rtx) > > afaics? Agreed. I made that change and retested which was clean. > Okay (for trunk, and later 10) with or without such

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 8/6/20 8:45 AM, Jonathan Wakely via Libstdc++ wrote: On 06/08/20 15:01 +0100, Jonathan Wakely wrote: On 06/08/20 15:26 +0200, Jakub Jelinek via Libstdc++ wrote: On Thu, Aug 06, 2020 at 02:14:48PM +0100, Jonathan Wakely wrote:  template    __attribute__((__nonnull__(2),

gcc __attribute__

Hi *GCC*: On page: https://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Function-Attributes.html you show the attribute coming after the parameter list. But when I try this, I get the following: #include void __attribute__ ((noreturn)) aaa() // OK {exit(0); } void bbb() __attribute__

[Bug target/96446] ICE when spilling an MMA accumulator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96446 --- Comment #4 from CVS Commits --- The master branch has been updated by Peter Bergner : https://gcc.gnu.org/g:9c376d1c166e7c8b10bba6f1675d2471ffe8447f commit r11-2595-g9c376d1c166e7c8b10bba6f1675d2471ffe8447f Author: Peter Bergner Date:

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 06/08/20 08:56 -0600, Martin Sebor via Libstdc++ wrote: For this specific use case, I saw __istream_extract defined as an ordinary (non-template) function in a .tcc file in the patch so I thought it was out of line. If it's inline It's overloaded. One is a function template defined inline,

Re: std:vec for classes with constructor?

On 8/6/20 4:35 PM, Richard Biener wrote: On Thu, Aug 6, 2020 at 4:17 PM Aldy Hernandez wrote: On 8/6/20 12:48 PM, Jonathan Wakely wrote: On 06/08/20 12:31 +0200, Richard Biener wrote: On Thu, Aug 6, 2020 at 12:19 PM Jonathan Wakely wrote: On 06/08/20 06:16 +0100, Richard Sandiford

Re: [committed] libstdc++: Replace operator>>(istream&, char*) [LWG 2499]

On 8/6/20 7:30 AM, Jonathan Wakely via Libstdc++ wrote: On 06/08/20 14:14 +0100, Jonathan Wakely via Libstdc++ wrote: On 05/08/20 16:31 -0600, Martin Sebor via Libstdc++ wrote: On 8/5/20 3:25 PM, Jonathan Wakely wrote: P0487R1 resolved LWG 2499 for C++20 by removing the operator>> overloads

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Aug 6, 2020, at 3:31 AM, Richard Biener wrote: > > On Wed, 5 Aug 2020, Qing Zhao wrote: > >> Hi, Richard, >> >> Thanks a lot for your careful review and detailed comments. >> >> >>> On Aug 4, 2020, at 2:35 AM, Richard Biener >> > wrote: >>> >>> I have a

[PATCH] Rewrite get_size_range for irange API.

[Martin, does this sound reasonable to you?] The following patch converts get_size_range to the irange API, thus removing the use of VR_ANTI_RANGE. This was a bit tricky because of the gymnastics we do in get_size_range to ignore negatives and all that. I didn't convert the function for

[Bug c++/96500] enum of underlying type bool do not

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

  1   2   3   >