[PATCH] Add missing noexpect causes in tuple for move functions

This adds the remainging noexcept causes required for this cause to meet the spec as dicussed last year and documented here: http://cplusplus.github.io/LWG/lwg-active.html#2899. Signed-off-by: Nicholas Krause --- libstdc++-v3/include/std/tuple | 4 1 file changed, 4 insertions(+) diff --gi

Re: [PATCH] Fix PR64242

On 11/29/18 12:26 PM, Wilco Dijkstra wrote: > Fix PR64242 - the middle end expansion for long jmp updates the > hard frame pointer before it reads the new stack pointer. This > results in a corrupted stack pointer if the jmp buffer is a local. > The obvious fix is to insert a temporary. > > AArch

Re: C++ PATCH to implement C++20 P0634R3, Down with typename!

On Wed, Nov 28, 2018 at 05:09:23PM -0500, Jason Merrill wrote: > On 11/12/18 10:27 AM, Marek Polacek wrote: > > This patch implements C++20 P0634R3, Down with typename! > > > > which makes 'typename' optional in several contexts

Re: [PATCH] Add missing noexpect causes in tuple for move functions

On Sat, 1 Dec 2018 at 01:05, Nicholas Krause wrote: > > This adds the remainging noexcept causes required for this cause > to meet the spec as dicussed last year and documented here: > http://cplusplus.github.io/LWG/lwg-active.html#2899. I don't see how this change is sufficient; the noexcept-spe

[committed] Fix style issue pointed out by Bernhard in my recent change

Bernhard pointed out that we should be using machine_mode rather than enum machine_mode in one of my patches. I guess old habits die hard. Anyway, this trivial patch fixes the nit. I'll try to remember to start omitting the "enum" "class" and "struct" thingies more appropriately :-) j

Re: [PATCH] Introduce --param logical-op-non-short-circuit (PR testsuite/85368)

On 11/30/18 1:50 PM, Jakub Jelinek wrote: > Hi! > > Until we stop depending on BRANCH_COST and LOGICAL_OP_NON_SHORT_CIRCUIT > macros at least for early GIMPLE, I'm afraid the current state for the > testsuite is terrible, on some targets it is enough to use > -mbranch-cost={1,2} to pick either of

Re: [PATCH] Comparison with an enum should mention enum value.

On 11/30/18 2:49 AM, Martin Liška wrote: > Hi. > > This is one more clean up of the transition that I've just tested > on x86_64-linux-gnu. > > I'm planning to install it once I'll come back from vacation (27/12). > > Thanks, > Martin > > gcc/ChangeLog: > > 2018-11-29 Martin Liska > >

Re: [PATCH] Avoid weird integral types in reassoc range opts (PR tree-optimization/88274)

On 11/30/18 1:44 PM, Jakub Jelinek wrote: > Hi! > > The following patch makes sure that we don't use weird integral types > (either ones which have smaller precision than corresponding mode's > precision, or ones like C++ -fstrict-enum enumeral types which have > normal precision, but smaller TYPE

Re: [PATCH v5] Repeat jump threading after combine

On 11/28/18 11:57 PM, Ilya Leoshkevich wrote: > Repost of v4: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02067.html > > Bootstrapped and regtested on x86_64-redhat-linux, s390x-redhat-linux > and ppc64le-redhat-linux. > > Consider the following RTL: > > (insn (set (reg 65) (if_then_else (eq %

Re: [PATCH] minor FDO profile related fixes

On 11/9/18 7:12 PM, Indu Bhagat wrote: > Changelog entry attached. Sorry about that. > > Comments inline. > > Thanks > > On 11/09/2018 04:23 PM, Jeff Law wrote: >> On 11/7/18 5:49 PM, Indu Bhagat wrote: >>> diff --git a/gcc/coverage.c b/gcc/coverage.c >>> index 599a3bb..7595e6c 100644 >>> --- a/

Re: [PATCH] Added information about inline assembler in stack calculations (.su files)

On 11/26/18 7:02 AM, Torbjorn SVENSSON wrote: > Hi, > > Attached is a small patch that, in case of inline assembler code, > indicates that the function stack usage is uncertain due to inline > assembler. > > The test suite are using "nop" as an assembler instruction on all > targets, is this a

Re: [PATCH] Improve combiner's find_split_point (PR target/54589)

On Thu, Nov 29, 2018 at 04:36:01PM -0600, Segher Boessenkool wrote: > Hi Jakub, > > On Thu, Nov 29, 2018 at 10:49:21PM +0100, Jakub Jelinek wrote: > > The following patch attempts to improve find_split_point inside of > > complex MEM addresses, if the target supports REG + REG + const > > addressi

Re: [RS6000] num_insns_constant ICE

On Fri, Nov 30, 2018 at 06:16:40PM +1030, Alan Modra wrote: > On Thu, Nov 29, 2018 at 01:52:34PM -0600, Segher Boessenkool wrote: > > On Sun, Nov 25, 2018 at 10:49:12PM +1030, Alan Modra wrote: > > > + while (nregs-- > 0) > > > +{ > > > + int ins = num_insns_constant_gpr (value); > > > >

Re: [PATCH] Add missing noexpect causes in tuple for move functions

On 2018-11-30 6:12 p.m., Ville Voutilainen wrote: > On Sat, 1 Dec 2018 at 01:05, Nicholas Krause wrote: >> >> This adds the remainging noexcept causes required for this cause >> to meet the spec as dicussed last year and documented here: >> http://cplusplus.github.io/LWG/lwg-active.html#2899. >

[doc, rfc] document __builtin_setjmp and __builtin_longjmp

I have written a new patch for PR 59039 to address more of the comments there, as well as my own complaints about the draft patch attached to the issue. I'd like to get some feedback on this one before I commit it. -Sandra 2018-11-30 Sandra Loosemore PR c/59039 gcc/ * doc/extend.texi (

[PATCH] Partial fix for asan on big endian targets (PR sanitizer/88289)

On Fri, Nov 30, 2018 at 12:44:04PM +0100, Martin Liška wrote: > Ok, I'm sending updated version of the patch. I factored out the shadow memory > byte emission into a class, it's responsible for underlying flushing and > guarantees > that stores are 4B aligned (when beginning of stack vars is prope

Re: [PING #4][PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028)

On Fri, Nov 30, 2018 at 3:02 AM Jeff Law wrote: > > On 11/29/18 4:43 PM, Martin Sebor wrote: > >> The fallout on existing tests is minimal. What's more concerning is > >> that it doesn't actually pass the new test from Martin's original > >> submission. We get bogus warnings. > >> > >> At least

Re: [PATCH] clarify comments for implicit_p flag for built-ins

On Wed, Nov 28, 2018 at 7:18 PM Martin Sebor wrote: > > On 11/28/18 6:35 AM, Richard Biener wrote: > > On Tue, Nov 27, 2018 at 3:52 AM Martin Sebor wrote: > >> > >> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01759.html > >> > >> If there are no objections or suggestions for tweaks I'll c

Re: [PING #4][PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028)

On Fri, Nov 30, 2018 at 09:04:56AM +0100, Richard Biener wrote: > So, let's suppose we delay folding of (builtin [string]) calls to some > first special pass that also diagnoses those issues. One obvious > place to place this pass would be where we now do the > early object-size pass. In fact we

Re: [PATCH] asm non-code template parts (alternative to asm inline)

On Fri, 30 Nov 2018, Richard Biener wrote: > > Ping - as I think this approach addresses the root of the problem, I > > wouldn't > > like it to be forgotten. > > I agree this is also useful but it addresses another issue (that may appear to > be related). asm inline is really a hint to the inlin

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

Hi Ian, *sigh* it is always the way. You post a patch and five minutes later you find a bug in it. In this case it turned out that I had forgotten that gcc has its own copy of the libiberty sources, so the bootstrap test that I had run did not use the patched sources. Doh. When I did

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

Hi Scott, > Thank you for looking into this Nick. I've been staring at a few of these > CVEs off-and-on for a few days, and the following CVEs all look like > duplicates: > > CVE-2018-17985: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 > CVE-2018-18484: https://gcc.gnu.org/bugzilla/show_b

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

On Fri, Nov 30, 2018 at 08:38:48AM +, Nick Clifton wrote: > Also - Tom and Pedro have raised the issue that the patch introduces > a new static variable to the library that is not thread safe. I am > not sure of the best way to address this problem. Possibly the > variable could be ma

Re: [PATCH 1/5][libbacktrace] Factor out backtrace_vector_free

On 29-11-18 19:17, Ian Lance Taylor wrote: > On Thu, Nov 29, 2018 at 4:33 AM, Tom de Vries wrote: >> On 29-11-18 00:26, Ian Lance Taylor wrote: >>> On Wed, Nov 28, 2018 at 3:15 PM, Tom de Vries wrote: this patch factors out new function backtrace_vector_free. Bootstrapped and

Re: [PATCH 1/4][libbacktrace] Test check_PROGRAMS without mmap

On 29-11-18 19:26, Ian Lance Taylor wrote: > On Fri, Nov 23, 2018 at 12:47 PM, Tom de Vries wrote: >> [ was: [PATCH 1/2][libbacktrace] Handle realloc returning NULL if size == 0 ] >> >> On Thu, Nov 22, 2018 at 01:35:43PM +0100, Tom de Vries wrote: >>> Hi, >>> >>> Build and tested on x86_64, with m

Re: [PATCH 4/4][libbacktrace] Add tests for unused formats

On 29-11-18 19:28, Ian Lance Taylor wrote: > On Fri, Nov 23, 2018 at 12:56 PM, Tom de Vries wrote: >> >> When building libbacktrace, we typically use elf.c, and don't build pecoff.c, >> xcoff.c or unknown.c >> >> Add testcases that use unused format to ensure that we also build and >> test those o

[PATCH] Improve predictions for hot and cold labels ([[likely]], [[unlikely]]).

Hi. This patch is a reaction to Jason's commit where he introduced new C++ attributes. First I would like to align cold/hot to __builtin_expect, so I adjusted probability and made the predictors first match predictors. Second I fixed how we consider the predictors in switch statements, so that

[PATCH] Comparison with an enum should mention enum value.

Hi. This is one more clean up of the transition that I've just tested on x86_64-linux-gnu. I'm planning to install it once I'll come back from vacation (27/12). Thanks, Martin gcc/ChangeLog: 2018-11-29 Martin Liska * builtins.c (expand_movstr): Compare with RETURN_BEGIN. *

Re: [PATCH] Adjust offsets for present data clauses

On 2018/7/21 6:07 AM, Cesar Philippidis wrote: This is another old gomp4 patch that corrects a bug where the runtime was passing the wrong offset for subarray data to the accelerator. The original description of this patch can be found here

[PATCH] Restrict vector extension to use 128bit vectors (PR testsuite/88265).

Hi. This is about restriction of vector width on x86_64 target in order to match expected _ZGVbN4v_* glibc vector functions. Ready for trunk? Martin gcc/testsuite/ChangeLog: 2018-11-30 Martin Liska PR testsuite/88265 * gfortran.dg/simd-builtins-1.f90: Restrict to 128b vecto

Re: [PATCH, libstdc++] Uniform container erasure for c++20.

On 29/11/18 12:05 -0500, Ed Smith-Rowland wrote: On 11/26/18 6:18 AM, Jonathan Wakely wrote: On 24/11/18 13:54 -0500, Ed Smith-Rowland wrote: All, I's very late but uniform container erasure is, I think, the last little tidbit to graduate from fundamentals/v2 to std at the last meeting.  I t

Re: RFC (branch prediction): PATCH to implement P0479R5, [[likely]] and [[unlikely]].

Hi Jason. Just small nits I noticed for: cat test4.C int a, b, c; void __attribute__((noinline)) bar() { if (a == 123) [[likely]] c = 5; else [[likely]] b = 77; } int main() { bar (); return 0; } $ g++ test4.C -c test4.C: In function ‘void bar()’: test4.C:8:16: warning: both br

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

Hi Jakub, >> Also - Tom and Pedro have raised the issue that the patch introduces >> a new static variable to the library that is not thread safe. I am >> not sure of the best way to address this problem. Possibly the >> variable could be made thread local ? Are there any other static >

Re: [PATCH] Restrict vector extension to use 128bit vectors (PR testsuite/88265).

On Fri, Nov 30, 2018 at 11:16:21AM +0100, Martin Liška wrote: > This is about restriction of vector width on x86_64 target in order > to match expected _ZGVbN4v_* glibc vector functions. If you want to test just that, then just add -mno-avx instead of -mavx2 -mno-avx512f -mprefer-vector-width=128.

Re: [PATCH, libstdc++, C++20] Implement P0457R2 String Prefix and Suffix Checking.

On 29/11/18 21:35 -0500, Ed Smith-Rowland wrote: Greetings, This patch implements starts_with and ends_with for basic_string and basic_string_view for C++20. This was on my TODO list, thanks for taking care of it. +#if __cplusplus > 201703L + bool + starts_with(basic_string_view<_

[PATCH] Fix PR88274

Another inconsistency with -fstrict-enums handling of VRP. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2018-11-30 Richard Biener PR tree-optimization/88274 * tree-vrp.c (ranges_from_anti_range): Fix handling of TYPE_MIN/MAX_VALUE. Index:

Re: [PATCH] Adjust offsets for present data clauses

On Fri, 30 Nov 2018 17:55:17 +0800 Chung-Lin Tang wrote: > On 2018/7/21 6:07 AM, Cesar Philippidis wrote: > > This is another old gomp4 patch that corrects a bug where the > > runtime was passing the wrong offset for subarray data to the > > accelerator. The original description of this patch can

Re: [PATCH, libstdc++] Uniform container erasure for c++20.

On Fri, 30 Nov 2018 at 12:25, Jonathan Wakely wrote: > Yes, that's exactly what I had in mind (and what I expect to get > proposed for C++20 in the near future). > > What does everyone else think, should we go ahead and do this? Yes, if we are confident that's what will be in C++20. > The point

[PATCH] Add constructor parsing to the GIMPLE FE

I failed to come up with ways using generic vector code to create specific GIMPLE the vectorizer creates so the following fills in the missing parsing of constructors in the GIMPLE FE. Notably aggregate assignments from empty constructors was also missing. (the special case of clobbers still is)

Re: [PATCH, libstdc++] Uniform container erasure for c++20.

On 30/11/18 12:40 +0200, Ville Voutilainen wrote: On Fri, 30 Nov 2018 at 12:25, Jonathan Wakely wrote: Yes, that's exactly what I had in mind (and what I expect to get proposed for C++20 in the near future). What does everyone else think, should we go ahead and do this? Yes, if we are confid

[C++ Patch] Use FUNC_OR_METHOD_TYPE_P in cp/

Hi, as promised in the exchange with Marek, I'm sending the straightforward patch, likely for next Stage 1. Tested x86_64-linux, as usual. Thanks, Paolo. 2018-11-30 Paolo Carlini * call.c (build_call_a): Use FUNC_OR_METHOD_TYPE_P. * cp-gimplify.c (cp_

Re: [PATCH] Come up with --param asan-stack-small-redzone (PR sanitizer/81715).

On 11/29/18 5:46 PM, Jakub Jelinek wrote: > On Thu, Nov 29, 2018 at 05:37:11PM +0100, Martin Liška wrote: >> 0x10007fff7b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x10007fff7b10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x10007fff7b20: 00 00 00 00 00 00 00 00 00 00 00 0

Re: [PATCH] PR libstdc++/67843 set shared_ptr lock policy at build-time

Firstly thanks a lot for working on this. On 28/11/2018 12:49, Jonathan Wakely wrote: > On 28/11/18 12:30 +, Jonathan Wakely wrote: >> 3) We could change libstdc++'s configure to automatically override >> --with-libstdcxx-lock-policy for arm-linux so it always uses "atomic" >> (because we kn

[PATCH] OpenACC reference count consistency checking

This is a trunk-compatible version of the patch posted here: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02365.html I understand it may not be suitable for committing (especially not outside stage 1 -- though it's "obviously harmless" in its dormant state), but it might be helpful for review

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

On 11/30/2018 08:26 AM, Nick Clifton wrote: > Hi Pedro, Hi Tom, > >> Pedro> E.g., in GDB, loading big binaries, demangling is very high >> Pedro> in profiles, and so we've kicked around the desire to parallelize >> Pedro> it > > I did consider this, but I encountered two problems: > > 1. I wan

Re: [PATCH] Come up with --param asan-stack-small-redzone (PR sanitizer/81715).

On Fri, Nov 30, 2018 at 12:44:04PM +0100, Martin Liška wrote: > Ok, I'm sending updated version of the patch. I factored out the shadow memory > byte emission into a class, it's responsible for underlying flushing and > guarantees > that stores are 4B aligned (when beginning of stack vars is prope

Re: [patch,openacc] Fix acc_shutdown issue

On Thu, 20 Sep 2018 10:05:30 -0700 Cesar Philippidis wrote: > Attached is an old gomp4 patch that allegedly fixes an shutdown > runtime issue involving OpenACC accelerators. Unfortunately, the > original patch didn't include a test case, nor did it generate any > regressions in the libgomp testsu

[PATCH] [MIPS] GCC: Fix Loongson3 LLSC Errata

In some older Loongson3 processors there is a LL/SC errata that can cause the CPU to deadlock occasionally. The details are very complicated. We find a way to work around this errata by a) adding a sync before ll/lld instruction, b) adding a sync before branch target that between ll and sc. The as

Re: [RS6000] PowerPC64 soft-float

On Fri, Nov 30, 2018 at 06:28:28PM +1030, Alan Modra wrote: > On Thu, Nov 29, 2018 at 12:15:06PM -0600, Segher Boessenkool wrote: > > On Sun, Nov 25, 2018 at 10:50:27PM +1030, Alan Modra wrote: > > > This patch aims to prevent long sequences loading soft-float > > > constants. For 32-bit, it makes

Re: [PATCH] asm non-code template parts (alternative to asm inline)

On Fri, Nov 30, 2018 at 9:33 AM Alexander Monakov wrote: > > On Fri, 30 Nov 2018, Richard Biener wrote: > > > Ping - as I think this approach addresses the root of the problem, I > > > wouldn't > > > like it to be forgotten. > > > > I agree this is also useful but it addresses another issue (that

Re: [PATCH 2/2] asm inline

On Tue, Oct 30, 2018 at 6:31 PM Segher Boessenkool wrote: > > The Linux kernel people want a feature that makes GCC pretend some > inline assembler code is tiny (while it would think it is huge), so > that such code will be inlined essentially always instead of > essentially never. > > This patch

[PATCH] Use proper location for tls_init function (PR c++/88263).

Hi. The PR is about a function (__tls_init) that ends before it begins (from line point of view). The patch uses location of a variable where we first create the function declaration. I'm not much familiar with C++ FE, but it works. Survives bootstrap and regression test on ppc64le-linux-gnu. Re

[PATCH] Call decl_default_tls_model with a proper type (PR gcov-profile/88279).

Hi. This is quite obvious fix where I mixed type and variable when calling decl_default_tls_model. I'm testing the patch on x86_64-linux-gnu. Ready for trunk? Thanks, Martin gcc/ChangeLog: 2018-11-30 Alexander Monakov PR gcov-profile/88279 * tree-profile.c (init_ic_make_glo

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

Hi, On Fri, 30 Nov 2018, Nick Clifton wrote: > Not without modifying the current demangling interface. The problem is > that the context structure is created for each invocation of a > demangling function (from outside the library), and no state is > preserved across demangling calls. Thus i

Re: [PATCH][RFC] Extend locations where to seach for Fortran pre-include.

On 11/27/18 2:40 PM, Martin Liška wrote: > On 11/26/18 7:44 PM, Joseph Myers wrote: >> On Mon, 26 Nov 2018, Martin Liška wrote: >> I don't see how this version ensures that NATIVE_SYSTEM_HEADER_DIR is properly sysrooted. Note there's add_sysrooted_prefix separate from add_prefix (

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

Nick Clifton writes: > I did consider just having a fixed limit, that the user cannot change, but > I thought that this might be rejected by reviewers. (On the grounds that > different limits are appropriate to different execution environments). > Note - enabling or disabling the recursion limit

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

On Fri, Nov 30, 2018 at 05:55:52AM -0800, Ian Lance Taylor wrote: > Nick Clifton writes: > > > I did consider just having a fixed limit, that the user cannot change, but > > I thought that this might be rejected by reviewers. (On the grounds that > > different limits are appropriate to different

Re: [PATCH, ARM] Improve robustness of -mslow-flash-data

Hi Thomas, On 19/11/18 17:56, Thomas Preudhomme wrote: Hi, Current code to handle -mslow-flash-data in machine description files suffers from a number of issues which this patch fixes: 1) The insn_and_split in vfp.md to load a generic floating-point constant via GPR first and move it to VFP re

Re: [PATCH][GCC][ARM] Ensure dotproduct is only enabled on armv8 neon

On 11/23/18 5:01 PM, Sam Tebbs wrote: > Hi all, > > Currently on AArch32, invoking with -march=armv8.2-a+dotprod -mfpu=neon > incorrectly enables armv7 dotproduct. This patch restricts dotproduct to armv8 > to correct the issue. > > When using a float ABI different from that of the host platform,

Re: [PATCH][GCC][ARM] Ensure dotproduct is only enabled on armv8 neon

On 23/11/18 17:01, Sam Tebbs wrote: Hi all, Currently on AArch32, invoking with -march=armv8.2-a+dotprod -mfpu=neon incorrectly enables armv7 dotproduct. This patch restricts dotproduct to armv8 to correct the issue. When using a float ABI different from that of the host platform, including /

Re: [PATCH, libfortran] PR 88137 Initialize backtrace state once

On 11/29/18 11:37 PM, Janne Blomqvist wrote: PING! LGTM, OK and thanks Jerry (for the GCC-7 branch, I'll commit it after the 7.4 release) On Thu, Nov 22, 2018 at 11:17 AM Janne Blomqvist wrote: From backtrace.h for backtrace_create_state: Calling this function allocates resources

Re: [PATCH 1/4][libbacktrace] Test check_PROGRAMS without mmap

>> As far as I know libbacktrace does not currently rely on using GNU >> make. I'd rather not add that dependency for this purpose (I don't >> mind adding this kind of testing but to me this seems only of mild >> interest--I expect that all significant libbacktrace users have mmap). >> You should

Re: [PATCH 4/4][libbacktrace] Add tests for unused formats

On Fri, Nov 30, 2018 at 1:06 AM, Tom de Vries wrote: > On 29-11-18 19:28, Ian Lance Taylor wrote: >> On Fri, Nov 23, 2018 at 12:56 PM, Tom de Vries wrote: >>> >>> When building libbacktrace, we typically use elf.c, and don't build >>> pecoff.c, >>> xcoff.c or unknown.c >>> >>> Add testcases that

Re: [PATCH][GCC][ARM] Ensure dotproduct is only enabled on armv8 neon

On 30/11/2018 14:19, Kyrill Tkachov wrote: > > On 23/11/18 17:01, Sam Tebbs wrote: >> Hi all, >> >> Currently on AArch32, invoking with -march=armv8.2-a+dotprod -mfpu=neon >> incorrectly enables armv7 dotproduct. This patch restricts dotproduct >> to armv8 >> to correct the issue. >> >> When using

Re: [PATCH] Call decl_default_tls_model with a proper type (PR gcov-profile/88279).

> Hi. > > This is quite obvious fix where I mixed type and variable > when calling decl_default_tls_model. > > I'm testing the patch on x86_64-linux-gnu. > > Ready for trunk? > Thanks, > Martin > > gcc/ChangeLog: > > 2018-11-30 Alexander Monakov > > PR gcov-profile/88279 > * tr

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

Michael Matz writes: > On Fri, 30 Nov 2018, Nick Clifton wrote: > >> Not without modifying the current demangling interface. The problem is >> that the context structure is created for each invocation of a >> demangling function (from outside the library), and no state is >> preserved across

Re: [patch,openacc] C, C++ OpenACC wait diagnostic change

Hi Julian! On Fri, 28 Sep 2018 14:17:42 +0100, Julian Brown wrote: > On Wed, 26 Sep 2018 14:08:37 -0700 > Cesar Philippidis wrote: > > > On 09/26/2018 12:50 PM, Joseph Myers wrote: > > > On Wed, 26 Sep 2018, Cesar Philippidis wrote: > > > > > >> Attached is an old patch which updated the C

Re: [PATCH] v3: C/C++: add fix-it hints for missing '&' and '*' (PR c++/87850)

On Tue, 2018-11-20 at 17:39 -0700, Martin Sebor wrote: > > +void test_2 (void) > > +{ > > + takes_int_ptr(ivar); /* { dg-warning "" "" { target c } } */ > > + /* { dg-error "" "" { target c++ } .-1 } */ > > + /* { dg-message "possible fix: take the address with '&'" "" { > > target *-*-* } .-2 }

Re: [PATCH][AArch64][2/3] Correct type attribute for mul and mneg instructions

On 28/11/18 16:37, James Greenhalgh wrote: On Mon, Nov 26, 2018 at 11:36:43AM -0600, Kyrill Tkachov wrote: Hi all, In the AAarch64 ISA the MUL and MNEG instructions are actually aliases of MADD and MSUB. Therefore they should have the type attribute mla, rather than mul, which should only b

Re: [PING #4][PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028)

On 11/30/18 12:57 AM, Richard Biener wrote: On Thu, Nov 29, 2018 at 9:34 PM Martin Sebor wrote: On 11/16/2018 02:07 AM, Richard Biener wrote: On Fri, Nov 16, 2018 at 4:12 AM Martin Sebor wrote: Ping: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01818.html Please let me know if there is s

[committed] Fix ICE in substring locations from macros in header files (PR preprocessor/88257)

PR preprocessor/88257 reports an ICE on gcc.dg/format/pr78304.c when compiled using g++: void test (const char *msg) { printf ("size: %" PRIu32 "\n", msg); } due to mismatching files (and line maps) between linemap_resolve_location and expand_location_to_spelling_point when PRIu32 is defined in

Re: [PATCH, libstdc++, C++20] Implement P0457R2 String Prefix and Suffix Checking.

On 11/30/18 5:33 AM, Jonathan Wakely wrote: On 29/11/18 21:35 -0500, Ed Smith-Rowland wrote: Greetings, This patch implements starts_with and ends_with for basic_string and basic_string_view for C++20. This was on my TODO list, thanks for taking care of it. +#if __cplusplus > 201703L +

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v3]

Hi Guys, >> I think it would be fine to have a large fixed limit plus a flag to >> disable the limit. Great - in which case please may I present version 3 of the patch. In this version: * The cplus_demangle_set_recursion_limit() function has been removed and instead a new constant - DEMA

Re: [PATCH][AArch64][2/3] Correct type attribute for mul and mneg instructions

On Fri, 2018-11-30 at 15:37 +, Kyrill Tkachov wrote: > > In thunderx2t99.md the reservation changes from thunderx2t99_mul to > thunderx2t99_madd. > > Steve, can you share whether the AArch64 MUL and MNEG instructions > really do have different latencies and reservations from MADD and > MSUB >

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v3]

Hi! Just spelling nitpicking. On Fri, Nov 30, 2018 at 05:41:35PM +, Nick Clifton wrote: > + order to dmangle truely complicated names, but it also leaves the tools truly? Multiple times. > +The @option{-r} option is a snyonym for the synonym? Multiple times. Jakub

Re: RFA/RFC: Add stack recursion limit to libiberty's demangler [v3]

On 11/30/2018 05:41 PM, Nick Clifton wrote: > @@ -4693,10 +4694,21 @@ > demangle_nested_args (struct work_stuff *work, const char **mangled, >string *declp) > { > + static unsigned long recursion_level = 0; >string* saved_previous_argument; >int result; >int s

Re: [wwwdocs] [PATCH]introduce new -flive-patching master option into gcc9

On 11/30/18 10:03 AM, Qing Zhao wrote: > Hi, > > This is the patch for update https://gcc.gnu.org/gcc-9/changes.html > to include the introducing of new > option > -flive-patching into gcc9. > > Okay for commit? OK jeff

Re: [PATCH, libfortran] PR 88137 Initialize backtrace state once

Hi! On Thu, 22 Nov 2018 11:17:24 +0200, Janne Blomqvist wrote: > From backtrace.h for backtrace_create_state: > >Calling this function allocates resources that can not be freed. >There is no backtrace_free_state function. The state is used to >cache information that is expensive to

Re: [PATCH, libfortran] PR 88137 Initialize backtrace state once

On Fri, Nov 30, 2018 at 9:07 PM Thomas Schwinge wrote: > Hi! > > On Thu, 22 Nov 2018 11:17:24 +0200, Janne Blomqvist < > blomqvist.ja...@gmail.com> wrote: > > From backtrace.h for backtrace_create_state: > > > >Calling this function allocates resources that can not be freed. > >There is n

Re: [PATCH] Use proper location for tls_init function (PR c++/88263).

OK.

Re: [PATCH] Adjust offsets for present data clauses

Hi Julian! On Fri, 30 Nov 2018 10:37:09 +, Julian Brown wrote: > > On 2018/7/21 6:07 AM, Cesar Philippidis wrote: > > > This is another old gomp4 patch that corrects a bug where the > > > runtime was passing the wrong offset for subarray data to the > > > accelerator. The original descriptio

[PATCH,RFC] PR target/61976 PowerPC & AIX parameter passing

This patch corrects the manner in which single element structures are passed. The implementation always has been wrong and did not match the AIX ABI. The AIX ABI specifies that aggregates are passed by values in GPRs, but GCC passes small floating point aggregates in FPRs. The PPC64 BE ELFv1 Linux

Re: [PATCH, OpenACC 2.5, libgomp] Add *_async versions of runtime library API functions

Hi! On Mon, 10 Sep 2018 10:22:17 -0700, Cesar Philippidis wrote: > On 09/10/2018 08:04 AM, Chung-Lin Tang wrote: > > Index: libgomp/openacc_lib.h > > I don't see a test case for this. Right. (Better test coverage would be desirable generally.) > I believe that openacc_lib.h is used > by fixe

[PATCH] Avoid weird integral types in reassoc range opts (PR tree-optimization/88274)

Hi! The following patch makes sure that we don't use weird integral types (either ones which have smaller precision than corresponding mode's precision, or ones like C++ -fstrict-enum enumeral types which have normal precision, but smaller TYPE_MAX_VALUE or larger TYPE_MIN_VALUE), because the cons

[committed] Support multiple OpenACC wait clauses

Hi! I ran into this while working on something else, and it turned into a prerequisite. Committed to trunk in r266684: commit ba688147af7632d7e1c420c98f2d301f7b9e427c Author: tschwinge Date: Fri Nov 30 20:39:08 2018 + Support multiple OpenACC wait clauses Support for this is

[committed] Clean up Fortran OpenACC wait clause handling

Hi! commit 3e3de40a5ab21d72f08071a7a40120dd05608cc1 Author: tschwinge Date: Fri Nov 30 20:39:18 2018 + Clean up Fortran OpenACC wait clause handling "wait" can be deduced from "wait_list". gcc/fortran/ * gfortran.h (struct gfc_omp_clauses): Remove

[PATCH] Introduce --param logical-op-non-short-circuit (PR testsuite/85368)

Hi! Until we stop depending on BRANCH_COST and LOGICAL_OP_NON_SHORT_CIRCUIT macros at least for early GIMPLE, I'm afraid the current state for the testsuite is terrible, on some targets it is enough to use -mbranch-cost={1,2} to pick either of the setting, but other targets, while they implement -

[C++ PATCH] Fix C++ parser endless diagnostics on CPP_PRAGMA_EOL (PR c++/88258)

Hi! The following testcase endlessly diagnoses a syntax error. The problem is that the various C++ parser routines to skip tokens until something happily skip over CPP_PRAGMA that starts a pragma line, but always stop at CPP_PRAGMA_EOL, but the caller expect them to stop at something different. T

[committed] Add testcase for already fixed PR debug/85550

Hi! The following testcase has been fixed by Nathan with r266158 aka PR debug/88006 and PR debug/87462. In order to close the PR, I've tested following testcase on x86_64-linux and i686-linux and committed to trunk. 2018-11-30 Jakub Jelinek PR debug/85550 * g++.dg/debug/dwarf

Re: [PATCH, OpenACC] Properly handle wait clause with no arguments

Hi Chung-Lin! On Wed, 07 Nov 2018 20:13:29 +0100, Thomas Schwinge wrote: > On Thu, 30 Aug 2018 21:27:22 +0800, Chung-Lin Tang > wrote: > > Hi, this patch properly handles OpenACC 'wait' clauses without arguments, > > making it an equivalent of "wait all". > > (current trunk basically discard

Re: [patch,openacc] use existing local variable in cp_parser_oacc_enter_exit_data

Hi! On Thu, 29 Nov 2018 21:33:37 +, Julian Brown wrote: > On Wed, 26 Sep 2018 11:21:33 -0700 > Cesar Philippidis wrote: > > > This is an old gomp4 patch that updates the location of the clause for > > acc enter/exit data. Apparently, it didn't impact any test cases. Is > > this OK for trun

[committed] [PR88288, OpenACC, libgomp] Adjust offsets for present data clauses

Hi! On Fri, 30 Nov 2018 17:55:17 +0800, Chung-Lin Tang wrote: > On 2018/7/21 6:07 AM, Cesar Philippidis wrote: > > This is another old gomp4 patch The patch as posted here contains additional changes compared to the original patch. I removed these additional changes. The Fortran test case inc

Re: [PATCH v3] Make function clone name numbering independent.

Hi, On 2018-11-30 2:25 a.m., Richard Biener wrote: > + unsigned &clone_number = lto_clone_numbers->get_or_insert ( > + IDENTIFIER_POINTER (DECL_NAME (decl))); >name = maybe_rewrite_identifier (name); >symtab->change_decl_assembler_name (decl, > - clone_function_name_numbered ( >

[PATCH] Add *vec_concatv4sf_0 and *vec_concatv4si_0 insns (PR target/88278)

Hi! As mentioned in the PR, while in vec_concatv2df or vec_concatv2di we have alternatives where the lower half is low 64-bit part of a xmm reg or 64-bit memory and upper half is zero using movq/vmovq (or movq2dq), for vec_concatv4sf and vec_concatv4si we don't have anything similar, although the

Re: [PATCH, libfortran] PR 88137 Initialize backtrace state once

On Fri, Nov 30, 2018 at 9:29 PM Janne Blomqvist wrote: > On Fri, Nov 30, 2018 at 9:07 PM Thomas Schwinge > wrote: > >> Hi! >> >> On Thu, 22 Nov 2018 11:17:24 +0200, Janne Blomqvist < >> blomqvist.ja...@gmail.com> wrote: >> > From backtrace.h for backtrace_create_state: >> > >> >Calling this

Re: [patch,openacc] Fix infinite recursion in OMP clause pretty-printing, default label

On Thu, 29 Nov 2018 21:25:33 + Joseph Myers wrote: > On Thu, 29 Nov 2018, Julian Brown wrote: > > > On Thu, 20 Sep 2018 10:08:51 -0700 > > Cesar Philippidis wrote: > > > > > Apparently, Tom ran into an ICE when we were adding support for > > > new clauses back in the gomp-4_0-branch days

Patch to fix PR88179

  The following patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88179   The patch was successfully bootstrapped and tested on x86-64.    Committed as rev. 266682. Index: ChangeLog === --- ChangeLog (revision 266681) +++ C

Re: [patch,openacc] Fix infinite recursion in OMP clause pretty-printing, default label

On Fri, Nov 30, 2018 at 09:35:45PM +, Julian Brown wrote: > How's this? (Obvious, but re-tested anyway.) > > Thanks, > > Julian > > ChangeLog > > gcc/ > * tree-pretty-print.c (dump_omp_clause): Make default case > gcc_unreachable. Ok, thanks. > diff --git a/gcc/tree-pretty-pri

Re: [patch,openacc] Fix infinite recursion in OMP clause pretty-printing, default label

On Fri, 30 Nov 2018, Julian Brown wrote: > ChangeLog > > gcc/ > * tree-pretty-print.c (dump_omp_clause): Make default case > gcc_unreachable. OK. -- Joseph S. Myers jos...@codesourcery.com

[PATCH] v4: C/C++: add fix-it hints for missing '&' and '*' (PR c++/87850)

On Tue, 2018-11-20 at 22:23 +, Joseph Myers wrote: > On Tue, 20 Nov 2018, David Malcolm wrote: > > > Should I do: > > You should do whatever is appropriate for the warning in > question. But if > what's appropriate for the warning in question includes types that > are > compatible but not

  1   2   >