[PATCH] c++: C++20 DR 2237, disallow simple-template-id in cdtor.

This patch implements DR 2237 which says that a simple-template-id is no longer valid as the declarator-id of a constructor or destructor; see . It is not explicitly stated but out-of-line destructors with a simple-template-id are also meant to be ill-fo

Re: [PATCH] i386: Simplify {, v}ph{add, sub{, s}{w, d} insn patterns [PR94460]

On Sat, Apr 4, 2020 at 12:41 AM Jakub Jelinek wrote: > > Hi! > > As mentioned in the previous PR94460 patch, the RTL patterns look too > large/complicated, we can simplify them by just performing two 2 arg > permutations to move the arguments into the right spots and then just > doing the plus/min

Re: libgcc patch committed: Avoid hooks in split-stack code

> I committed this patch. Works for me, thanks for the quick fix! -- Eric Botcazou

Re: libgcc patch committed: Avoid hooks in split-stack code

On Sat, Apr 4, 2020 at 1:35 PM H.J. Lu wrote: > > On Sat, Apr 4, 2020 at 1:28 PM Eric Botcazou wrote: > > > > > Hmmm, sorry about that. Which target? x86_64? It does seem that > > > glibc consolidated mmap implementations in 2.26, but even in 2.22 I > > > see definitions for __mmap. > > > > co

Re: libgcc patch committed: Avoid hooks in split-stack code

On Sat, Apr 4, 2020 at 1:28 PM Eric Botcazou wrote: > > > Hmmm, sorry about that. Which target? x86_64? It does seem that > > glibc consolidated mmap implementations in 2.26, but even in 2.22 I > > see definitions for __mmap. > commit fa872e1b6210e81e60d6029429f0a083b8eab26e Author: Adhemerval

Re: libgcc patch committed: Avoid hooks in split-stack code

> Hmmm, sorry about that. Which target? x86_64? It does seem that > glibc consolidated mmap implementations in 2.26, but even in 2.22 I > see definitions for __mmap. GNU C Library (GNU libc) stable release version 2.22 (git bbab82c25da9), by Roland McGrath et al. Copyright (C) 2015 Free Softwa

Re: libgcc patch committed: Avoid hooks in split-stack code

On Sat, Apr 4, 2020 at 10:10 AM Eric Botcazou wrote: > > > 2020-04-03 Ian Lance Taylor > > > > * generic-morestack.c: On GNU/Linux use __mmap/__munmap rather > > than mmap/munmap, to avoid hooks. > > This breaks the build of gotools for me with undefined references to __mmap > and __munmap from

[pushed] c++: Mangling of dependent conversions [PR91377]

We skip over other conversion codes when mangling expressions, we should do the same with IMPLICIT_CONV_EXPR. Tested x86_64-pc-linux-gnu, applying to trunk/9/8. gcc/cp/ChangeLog 2020-04-04 Jason Merrill PR c++/91377 * mangle.c (write_expression): Skip IMPLICIT_CONV_EXPR. ---

Re: [PATCH]Microblaze: Fixed missing save of r18 in fast_interrupt.

OK to apply. On 4/4/20 2:18 AM, Nagaraju Mekala wrote: Hello All, Fixed missing save of r18 in fast_interrupt. Register 18 is used as a clobber register, and must be stored when entering a fast_interrupt. Before this fix, register 18 was only saved if it was used directly in the interrupt fun

Re: [PATCH]Microblaze: Modified trap instruction

OK to apply. On 4/4/20 1:59 AM, Nagaraju Mekala wrote: Hello All, There is a bug in trap instruction generation. Instead of "bri 0" instruction "brki r0, -1" was used, corrected it now. ChangeLog: 2020-04-04 Nagaraju Mekala * gcc/config/microblaze/micr

Re: [PATCH v2] c++: Fix crash in gimplifier with paren init of aggregates [PR94155]

On Fri, Apr 03, 2020 at 10:39:49PM -0400, Jason Merrill via Gcc-patches wrote: > On 4/3/20 9:08 PM, Marek Polacek wrote: > > On Fri, Apr 03, 2020 at 03:01:37PM -0400, Jason Merrill via Gcc-patches > > wrote: > > > On 3/30/20 4:28 PM, Marek Polacek wrote: > > > > Here we crash in the gimplifier bec

Re: libgcc patch committed: Avoid hooks in split-stack code

> 2020-04-03 Ian Lance Taylor > > * generic-morestack.c: On GNU/Linux use __mmap/__munmap rather > than mmap/munmap, to avoid hooks. This breaks the build of gotools for me with undefined references to __mmap and __munmap from libgcc/generic-morestack.c (it is with glibc 2.22). -- Eric Botc

Re: ipa: Fix wrong code with failed propagation to builtin_constant_p [PR93940]

> sorry for that. Git is still not my friend. I managed to stash and > unstash multiple changes and mix them up. Git was clearly designed *not* to have friends if you ask me, so I cannot really blame you here. > I comitted the following fix. Thanks! -- Eric Botcazou

Re: [PATCH] c++: Refrain from using replace_placeholders in constexpr evaluation [PR94205]

On Sat, 4 Apr 2020, Jason Merrill wrote: > On 4/3/20 4:07 PM, Patrick Palka wrote: > > On Fri, 3 Apr 2020, Jason Merrill wrote: > > > > > On 4/2/20 7:40 PM, Patrick Palka wrote: > > > > + /* Prefer the outermost matching object, but don't cross > > > > + CONSTRUCTOR_PLACEHOLDER_BOUNDARY cons

Re: [PATCH v2] debug: Improve debug info of c++14 deduced return type [PR94459]

On 4/4/20 3:54 AM, Jakub Jelinek wrote: On Sat, Apr 04, 2020 at 12:08:38AM -0400, Jason Merrill wrote: http://eel.is/c++draft/dcl.spec.auto#3 says it has to appear as a decl-specifier. http://eel.is/c++draft/temp.deduct.type#8 lists the forms where a template argument can be deduced. Looks lik

[pushed] c++: Fix invalid pointer-to-member in requires [PR67825]

A recent change to cmcstl2 led to two tests failing due to this bug: our valid expression checking in the context of a requires-expression wasn't catching that an expression of member function type can only appear as the function operand of a call expression. Fixed by using convert_to_void to do t

[pushed] c++: Fix reuse of class constants [PR94453]

The testcase hit an ICE trying to expand a TARGET_EXPR temporary cached from the other lambda-expression. This patch fixes this in two ways: 1) Avoid reusing a TARGET_EXPR from another function. 2) Avoid ending up with a TARGET_EXPR at all; the use of 'p' had become >>, which doesn't make any se

Re: ipa: Fix wrong code with failed propagation to builtin_constant_p [PR93940]

> > The change 1) breaks bootstrap and 2) fails to update the ChangeLog files. Hi, sorry for that. Git is still not my friend. I managed to stash and unstash multiple changes and mix them up. I comitted the following fix. Honza diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 0221945fe6c..75e3

Re: ipa: Fix wrong code with failed propagation to builtin_constant_p [PR93940]

On Sat, Apr 4, 2020 at 5:40 AM Eric Botcazou wrote: > > > gcc/ChangeLog: > > > > 2020-04-04 Jan Hubicka > > > > PR ipa/93940 > > * ipa-fnsummary.c (vrp_will_run_p): New function. > > (fre_will_run_p): New function. > > (evaluate_properties_for_edge): Use it. > > *

Contents of PO file 'cpplib-10.1-b20200209.eo.po'

cpplib-10.1-b20200209.eo.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.

New Esperanto PO file for 'cpplib' (version 10.1-b20200209)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Esperanto team of translators. The file is available at: https://translationproject.org/latest/cpplib/eo.po (This file, 'cpplib-10.1-b2020

Re: ipa: Fix wrong code with failed propagation to builtin_constant_p [PR93940]

> gcc/ChangeLog: > > 2020-04-04 Jan Hubicka > > PR ipa/93940 > * ipa-fnsummary.c (vrp_will_run_p): New function. > (fre_will_run_p): New function. > (evaluate_properties_for_edge): Use it. > * ipa-inline.c (can_inline_edge_by_limits_p): Do not inline > !opti

Re: [PATCH] Check DECL_CONTEXT of new/delete operators.

Hi, thinking a bit of the problem, I guess we could match in addition to DECL_CONTEXT the whole inline stack of both statements and see if there are inlined new/delete operators and if so if they are always in matching pairs. The inline stack is available as for (tree block = gimple_block (call);

[PATCH] libiberty: Update D symbol demangling for latest ABI spec.

Hi, Some small improvements and clarifications have been done in the D ABI specification to remove all ambiguities found in the current grammar, this implementation now more closely resembles the spec, whilst maintaining compatibility with the old ABI. Three new rules have been added to the ABI.

Disable aggregate walking in ipa code for optimize_debug

Martin, with optimize_debug or when FRE is disabled propagating aggregates is useless since we are not going to use them. I think we should also avoid working hard on the jump functions. This patch disables it in ipa_load_from_param_agg, but I am not sure if there are other ways ipa-prop can do th

ipa: Fix wrong code with failed propagation to builtin_constant_p [PR93940]

Hi, this patch fixes wrong code on a testcase where inline predicts builtin_constant_p to be true but we fail to optimize its parameter to constant becuase FRE is not run and the value is passed by an aggregate. This patch makes the inline predicates to disable aggregate tracking when FRE is not g

[PATCH]Microblaze: Fixed missing save of r18 in fast_interrupt.

Hello All, Fixed missing save of r18 in fast_interrupt. Register 18 is used as a clobber register, and must be stored when entering a fast_interrupt. Before this fix, register 18 was only saved if it was used directly in the interrupt function. However, if the fast_interrupt function called

[PATCH]Microblaze: Modified trap instruction

Hello All, There is a bug in trap instruction generation. Instead of "bri 0" instruction "brki r0, -1" was used, corrected it now. ChangeLog: 2020-04-04 Nagaraju Mekala * gcc/config/microblaze/microblaze.md (trap): update in the pattern * gcc/test

Re: [PATCH] cselib: Don't consider SP_DERIVED_VALUE_P values as useless [PR94468]

On April 4, 2020 12:42:33 AM GMT+02:00, Jakub Jelinek wrote: >On Fri, Apr 03, 2020 at 07:42:10PM +0200, Jakub Jelinek via Gcc-patches >wrote: >> Or, to avoid the repetitive code, should I introduce >> static bool >> cselib_useless_value_p (cselib_val *v) >> { >> return (v->locs == 0 >>&&

[PATCH v2] debug: Improve debug info of c++14 deduced return type [PR94459]

On Sat, Apr 04, 2020 at 12:08:38AM -0400, Jason Merrill wrote: > http://eel.is/c++draft/dcl.spec.auto#3 says it has to appear as a > decl-specifier. > > http://eel.is/c++draft/temp.deduct.type#8 lists the forms where a template > argument can be deduced. > > Looks like you are missing arrays, poi