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

On 12/1/18 1:15 AM, Jeff Law wrote: > 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

Re: [PATCH, Fortran] pad char to int conversions with spaces instead of zeros (legacy)

On 12/6/18 2:33 AM, Jakub Jelinek wrote: On Wed, Dec 05, 2018 at 06:27:00PM -0800, Jerry DeLisle wrote: I disagree completely. I assume the idea of -fdec-pad-with-spaces is to accomodate some old dec fortran code. The only reason to use some other character is if someone is writing new dec

Re: Fortran patches

On Thu, Dec 06, 2018 at 05:21:32PM -0800, Steve Kargl wrote: > > Here's an alternative patch that would reject a subroutine > with an alternate return dummy argument with the bind(c) > attributes. I'm still trying to determine if the code > should be legal. The c.l.f thread I started isn't

Re: [PATCH] PR86957

On 12/05/2018 03:33 AM, Thomas Schwinge wrote: Hi! Sorry for my late follow-up; had a lot of catch up to do back then. On Thu, 27 Sep 2018 11:47:31 +0200, Richard Biener wrote: On Mon, Sep 24, 2018 at 9:14 PM Indu Bhagat wrote: Done. Attached is updated patch. Patch is tested on x86_64

Re: Fortran patches

On Thu, Dec 06, 2018 at 02:08:54PM -0500, Fritz Reese wrote: > On Wed, Dec 5, 2018 at 7:03 PM Steve Kargl > > > > > RE: > > > >PR fortran/88139 > > > >* dump-parse-tree.c (write_proc): Alternate return. > > > I dissent with this patch. The introduced error is meaningless and, as >

Re: [doc,committed] clarify docs for function attribute "const"

On 12/3/18 11:04 PM, Sandra Loosemore wrote: On 12/3/18 2:47 PM, Martin Sebor wrote: [snip] Attached is my proposed update.  The user's email suggested going into a lot of detail that I'm not sure would be helpful.  I think it's safer to keep it simple than to try to carefully outline tricky

Re: [PATCH, driver specs][2] Put -flto-partition= on the collect2 c/l

Hi This got stuck in my stack of patches for LTO debug support, and I forgot to ping it… > On 22 Aug 2018, at 14:20, Richard Biener wrote: > > On Wed, Aug 22, 2018 at 2:56 PM Iain Sandoe wrote: >> >> >>> On 20 Aug 2018, at 11:01, Richard Biener wrote: >>> >>> On Sat, Aug 18, 2018 at 9:00

[C++ Patch] [PR c++/88146] do not crash synthesizing inherited ctor(...)

This patch started out from the testcase in PR88146, that attempted to synthesize an inherited ctor without any args before a varargs ellipsis and crashed while at that, because of the unguarded dereferencing of the parm type list, that usually contains a terminator. The terminator is not there

[C++ PATCH] [PR c++/87814] undefer deferred noexcept on tsubst if request

tsubst_expr and tsubst_copy_and_build are not expected to handle DEFERRED_NOEXCEPT exprs, but if tsubst_exception_specification takes a DEFERRED_NOEXCEPT expr with !defer_ok, it just passes the expr on for tsubst_copy_and_build to barf. This patch arranges for tsubst_exception_specification to

Re: [committed] Add test for PR85770.

On Wed, Dec 05, 2018 at 05:41:49PM -0700, Jeff Law wrote: > > PR85770 is fixed by Segher's combiner patch to avoid combining hard > regs. Presumably it helps because it gives the allocators more freedom. > > I'm adding the testcase from the PR to the regression suite. > > Jeff > commit

Re: [PATCH][RFC] Poison bitmap_head->obstack

On 12/5/18 7:58 AM, Richard Biener wrote: On Wed, 5 Dec 2018, Jeff Law wrote: On 12/4/18 6:16 AM, Richard Biener wrote: This tries to make bugs like that in PR88317 harder to create by introducing a bitmap_release function that can be used as pendant to bitmap_initialize for non-allocated

Re: [PATCH] [PR86823] retain deferred access checks from outside firewall

On Dec 5, 2018, Jason Merrill wrote: > Hmm, I'm uncomfortable with how this depends on the specific > implementation of tentative_firewall. *nod* > What do you think of this alternate approach (untested other than with > the testcase)? If that won't drop any other deferred access checks that

Re: [PATCH] Disable -fipa-ra for naked functions (PR target/85593)

On 12/6/18 4:34 PM, Jakub Jelinek wrote: > Hi! > > The only documented supported content of naked functions is basic asm > statement(s). Those don't have clobbers though, so we should ignore > naked functions for IPA-RA; if they are written the only supported way, > they will appear not to

[PATCH] Disable -fipa-ra for naked functions (PR target/85593)

Hi! The only documented supported content of naked functions is basic asm statement(s). Those don't have clobbers though, so we should ignore naked functions for IPA-RA; if they are written the only supported way, they will appear not to clobber any registers at all and IPA-RA will then assume

[committed] Fix OpenMP handling of character allocatable scalars (PR fortran/88377)

Hi! Apparently the length decls corresponding to allocatable scalars with character type are also GFC_DECL_GET_SCALAR_ALLOCATABLE; the OpenMP clause handling code was relying on those to have POINTER_TYPEs, but the lengths are integrals and should be handled normally. Bootstrapped/regtested on

[C++ PATCH] Fix make_temporary_var_for_ref_to_temp (PR c++/86669)

On Wed, Dec 05, 2018 at 09:50:56PM +0100, Jakub Jelinek wrote: > On Wed, Dec 05, 2018 at 03:49:26PM -0500, Jason Merrill wrote: > > On 11/28/18 3:42 AM, Jakub Jelinek wrote: > > > Whenever we need to clone a cdtor (either because the target doesn't > > > support > > > aliases the way we need,

Re: [PATCH] handle function pointers in __builtin_object_size (PR 88372)

On 12/6/18 2:26 PM, Jakub Jelinek wrote: On Thu, Dec 06, 2018 at 01:21:58PM -0700, Martin Sebor wrote: Bug 88372 - alloc_size attribute is ignored on function pointers points out that even though the alloc_size attribute is accepted on function pointers it doesn't have any effect on Object Size

Re: Fortran patches

On Thu, Dec 06, 2018 at 08:02:43PM +0100, Thomas Koenig wrote: > >>> PR fortran/88139 > >>> * dump-parse-tree.c (write_proc): Alternate return. > >> I dissent with this patch. The introduced error is meaningless and, as > >> mentioned by comment #3 in the PR, avoiding the ICE in

Re: [PATCH, OpenACC] Enable GOMP_MAP_FIRSTPRIVATE_INT for OpenACC

On Tue, 4 Dec 2018 15:27:12 +0100 Jakub Jelinek wrote: > On Thu, Sep 20, 2018 at 07:38:04PM -0400, Julian Brown wrote: > > 2018-09-20 Cesar Philippidis > > Julian Brown > > > > gcc/ > > * omp-low.c (maybe_lookup_field_in_outer_ctx): New function. > >

Re: [PATCH, PPC/Darwin] Fix long double symbol exports.

On Dec 6, 2018, at 11:52 AM, Iain Sandoe wrote: > > During 8.x, the rs6000 target-specific mangling was reorganised which > uncovered > a long-standing bug in Darwin’s mangling for ‘IBM’ long double. Now the > symbols > are correctly mangled, and we end up with a bunch of test link fails. >

Re: [PATCH 0/6, OpenACC, libgomp] Async re-work

On Thu, 6 Dec 2018 22:22:46 + Julian Brown wrote: > On Thu, 6 Dec 2018 21:42:14 +0100 > Thomas Schwinge wrote: > > > [...] > > ..., where the "Invalid read of size 8" happens, and which > > eventually would try to "free (tgt)" again, via > > libgomp/target.c:gomp_unmap_tgt: > > > >

Re: [PATCH 0/6, OpenACC, libgomp] Async re-work

On Thu, 6 Dec 2018 21:42:14 +0100 Thomas Schwinge wrote: > [...] > ..., where the "Invalid read of size 8" happens, and which eventually > would try to "free (tgt)" again, via libgomp/target.c:gomp_unmap_tgt: > > attribute_hidden void > gomp_unmap_tgt (struct target_mem_desc *tgt) >

Re: C++ patch ping

On 12/4/18 9:47 AM, Jakub Jelinek wrote: Hi! I'd like to ping PR87506 - https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01758.html You've acked the patch with the asserts but that FAILs as mentioned in the above mail. The following has been bootstrapped/regtested and works, can it be

Re: [PATCH] handle function pointers in __builtin_object_size (PR 88372)

On Thu, Dec 06, 2018 at 01:21:58PM -0700, Martin Sebor wrote: > Bug 88372 - alloc_size attribute is ignored on function pointers > points out that even though the alloc_size attribute is accepted > on function pointers it doesn't have any effect on Object Size > Checking. The reporter, who is

RFC: libiberty PATCH to disable demangling of ancient mangling schemes

On Thu, Dec 6, 2018 at 11:14 AM Jason Merrill wrote: > > Looks good to me. Independently, do you see a reason not to disable the > old demangler entirely? Like so. Does anyone object to this? These mangling schemes haven't been relevant in decades. commit

C++ PATCH for c++/88136, -Wdeprecated-copy too noisy

-Wdeprecated-copy does find some real bugs, but it also complains about a lot of reasonable code for which the implicitly declared copy ctor/op= are fine oven though the class has a user-defined destructor: this situation is only problematic if the destructor releases resources held in one of the

RFA: PATCH to add pp command to gdbinit.in

Since pvt was removed, it's bugged me that to pretty-print a vec I needed to write out "call debug($)". So this patch adds a generic command "pp" to print anything handled by a debug overload. OK for trunk? commit 2dd2501e3abbd9d0b70119534fa5a93e957432bf Author: Jason Merrill Date: Tue Nov 20

Re: [PATCH 6/6, OpenACC, libgomp] Async re-work, nvptx changes

Hi Chung-Lin! On Tue, 25 Sep 2018 21:11:58 +0800, Chung-Lin Tang wrote: > Hi Tom, > this patch removes large portions of plugin/plugin-nvptx.c, since a lot of it > is > now in oacc-async.c now. The new code is essentially a NVPTX/CUDA-specific > implementation > of the new-style

Re: [PATCH 0/6, OpenACC, libgomp] Async re-work

Hi Chung-Lin! On Tue, 25 Sep 2018 21:09:49 +0800, Chung-Lin Tang wrote: > This patch is a re-organization of OpenACC asynchronous queues. Thanks! > The previous style of implementation > was essentially re-defining the entire async API inside the plugin-interface, > and relaying all such >

Re: [PATCH] Fix VRP with -fno-delete-null-pointer-checks (PR c/88367)

On Thu, Dec 06, 2018 at 01:08:34PM -0700, Jeff Law wrote: > > I hope we can still say that pointer wrapping even with > > -fno-delete-null-pointer-checks is UB, so this patch differentiates between > > positive offsets (in ssizetype), negative offsets (in ssizetype) and zero > > offsets and

[PATCH] handle function pointers in __builtin_object_size (PR 88372)

Bug 88372 - alloc_size attribute is ignored on function pointers points out that even though the alloc_size attribute is accepted on function pointers it doesn't have any effect on Object Size Checking. The reporter, who is implementing the feature in Clang, wants to know if by exposing it under

[PATCH] Testcase for PR 88297 and minor fixes

Thanks to Martin we now have a test that exercises (cp) cloning machinery during the WPA stage of LTO. Also, during debugging I found that print_all_lattices would trigger an assert if I tried to call it inside decide_whether_version_node. Finally I've attached some comment spelling fixes as a

Re: [PATCH] Fix VRP with -fno-delete-null-pointer-checks (PR c/88367)

On 12/5/18 11:45 PM, Jakub Jelinek wrote: > Hi! > > If we consider -fno-delete-null-pointer-checks as a way to support e.g. AVR > and other targets which can validly place objects at NULL rather than a way > to workaround UBs in code, I believe the following testcase must pass if > there is e.g.

[PATCH, PPC/Darwin] Fix long double symbol exports.

Hi, During 8.x, the rs6000 target-specific mangling was reorganised which uncovered a long-standing bug in Darwin’s mangling for ‘IBM’ long double. Now the symbols are correctly mangled, and we end up with a bunch of test link fails. This patch adds the necessary subset of the Linux long double

Re: Fortran patches

On Thu, Dec 06, 2018 at 02:08:54PM -0500, Fritz Reese wrote: > On Wed, Dec 5, 2018 at 7:03 PM Steve Kargl > wrote: > > > > On Wed, Dec 05, 2018 at 04:48:28PM -0500, Fritz Reese wrote: > [...] > > > RE: > > > > PR fortran/88228 > > > > * expr.c (check_null, check_elemental): Work

Re: C++ PATCH for c++/88373, wrong parse error with ~

On 12/6/18 11:33 AM, Marek Polacek wrote: This patch fixes a bogus parse error with ~ in a template-argument-list. We have S> and cp_parser_template_argument just tries to parse each argument as a type, id-expression, etc to see what sticks. When it sees ~value, it tries to parse it

Re: [C++ Patch] Three additional bitfield diagnostic tweaks (a regression fix included)

On 12/6/18 12:23 PM, Paolo Carlini wrote: Hi, On 06/12/18 16:11, Jason Merrill wrote: 2- Unfortunately I have to fix another buglet I recently introduced, completely similar to c++/88222 fixed by Marek. Well, at least we will not print anymore an empty '' when the unqualified_id is null

[PATCH, committed] Fix PR libstdc++/64883

Hi I applied the following as discussed with Jonathan on the PR and IRC, will back port to 8.x and 7.x in due course. Some of Darwin's headers use always_inline so don't test that Because Darwin system headers use always_inline rather than __always_inline__ the libstdc++ test

Re: Fortran patches

On Thu, Dec 06, 2018 at 08:02:43PM +0100, Thomas Koenig wrote: > Hi Steve, > > >>> PR fortran/88139 > >>> * dump-parse-tree.c (write_proc): Alternate return. > >> I dissent with this patch. The introduced error is meaningless and, as > >> mentioned by comment #3 in the PR,

Re: Fortran patches

On Wed, Dec 5, 2018 at 7:03 PM Steve Kargl wrote: > > On Wed, Dec 05, 2018 at 04:48:28PM -0500, Fritz Reese wrote: [...] > > RE: > > > PR fortran/88228 > > > * expr.c (check_null, check_elemental): Work around -fdec and > > > initialization with logical operators operating

Re: Fortran patches

Hi Steve, PR fortran/88139 * dump-parse-tree.c (write_proc): Alternate return. I dissent with this patch. The introduced error is meaningless and, as mentioned by comment #3 in the PR, avoiding the ICE in dump-parse-tree is not directly the issue. The code should be rejected in

Re: [PATCH v2 0/2] asm qualifiers (PR55681) and asm inline

On Thu, Dec 06, 2018 at 07:15:20PM +0100, Jakub Jelinek wrote: > On Thu, Dec 06, 2018 at 12:10:56PM -0600, Segher Boessenkool wrote: > > On Sun, Dec 02, 2018 at 04:38:16PM +, Segher Boessenkool wrote: > > > v2, with the input from Joseph taken into account. > > > > > > This is the same "asm

Another patch for PR88282

  Here is another solution for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88282   less hackish than original one.   The patch was bootstrapped and tested on x86/x86-64/ppc64/aarch64.   Committed as rev. 266862. Index: ChangeLog

Re: [PATCH v2 0/2] asm qualifiers (PR55681) and asm inline

On Thu, 6 Dec 2018, Jakub Jelinek wrote: > Not sure if in the backport we shouldn't keep accepting with warning like > before const asm and not do the changes of accepting in any order except > perhaps for the inline keyword in there? Indeed, I think it's best to keep accepting const and

Re: [PATCH v2 0/2] asm qualifiers (PR55681) and asm inline

On Thu, Dec 06, 2018 at 12:10:56PM -0600, Segher Boessenkool wrote: > On Sun, Dec 02, 2018 at 04:38:16PM +, Segher Boessenkool wrote: > > v2, with the input from Joseph taken into account. > > > > This is the same "asm inline" patch as before, but now preceded by a > > patch that makes all

Re: [PATCH v2 0/2] asm qualifiers (PR55681) and asm inline

Hi all, On Sun, Dec 02, 2018 at 04:38:16PM +, Segher Boessenkool wrote: > v2, with the input from Joseph taken into account. > > This is the same "asm inline" patch as before, but now preceded by a > patch that makes all orderings of volatile/goto/inline valid, all other > type qualifiers

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

On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton wrote: > > Is the patch OK with you ? Yes, thanks. Ian

Remove bogus test line from vect-over-widen-23.c

I'd cut-&-paste vect-over-widen-23.c in an attempt to get the target reuirements right, but by doing so carried over an unwanted test for shifts. Tested on arm-none-eabi and committed as obvious. Richard 2018-12-06 Richard Sandiford gcc/testsuite/ *

Re: [RFC PATCH] Coalesce host to device transfers in libgomp

On Thu, Dec 06, 2018 at 06:54:20PM +0100, Thomas Schwinge wrote: > On Thu, 6 Dec 2018 18:18:56 +0100, Jakub Jelinek wrote: > > On Thu, Dec 06, 2018 at 06:01:48PM +0100, Thomas Schwinge wrote: > > > While reviewing Chung-Lin's > > >

Re: [RFC PATCH] Coalesce host to device transfers in libgomp

Hi Jakub! On Thu, 6 Dec 2018 18:18:56 +0100, Jakub Jelinek wrote: > On Thu, Dec 06, 2018 at 06:01:48PM +0100, Thomas Schwinge wrote: > > While reviewing Chung-Lin's > > "[PATCH 4/6, > > OpenACC, libgomp] Async re-work, libgomp/target.c

Re: [PATCH 4/6, OpenACC, libgomp] Async re-work, libgomp/target.c changes

On Thu, Dec 06, 2018 at 06:21:16PM +0100, Thomas Schwinge wrote: > On Tue, 25 Sep 2018 21:11:24 +0800, Chung-Lin Tang > wrote: > > Hi Jakub, > > This part has changes to 'struct goacc_asyncqueue*' arguments to various > > memory copying/mapping functions. To lessen the amount of code changes new

Re: [C++ Patch] Three additional bitfield diagnostic tweaks (a regression fix included)

Hi, On 06/12/18 16:11, Jason Merrill wrote: 2- Unfortunately I have to fix another buglet I recently introduced, completely similar to c++/88222 fixed by Marek. Well, at least we will not print anymore an empty '' when the unqualified_id is null because the field is unnamed. -   

Re: [PATCH 4/6, OpenACC, libgomp] Async re-work, libgomp/target.c changes

Hi Jakub! On Tue, 25 Sep 2018 21:11:24 +0800, Chung-Lin Tang wrote: > Hi Jakub, > This part has changes to 'struct goacc_asyncqueue*' arguments to various > memory copying/mapping functions. To lessen the amount of code changes new > 'gomp_map/unmap_vars_async' > functions names are used (with

Re: [RFC PATCH] Coalesce host to device transfers in libgomp

On Thu, Dec 06, 2018 at 06:01:48PM +0100, Thomas Schwinge wrote: > While reviewing Chung-Lin's > "[PATCH 4/6, > OpenACC, libgomp] Async re-work, libgomp/target.c changes", I noticed the > following unrelated hunk. Is that intentional or

Re: [RFC PATCH] Coalesce host to device transfers in libgomp

Hi Jakub! While reviewing Chung-Lin's "[PATCH 4/6, OpenACC, libgomp] Async re-work, libgomp/target.c changes", I noticed the following unrelated hunk. Is that intentional or just an oversight that it hasn't been included in your

C++ PATCH for c++/88373, wrong parse error with ~

This patch fixes a bogus parse error with ~ in a template-argument-list. We have S> and cp_parser_template_argument just tries to parse each argument as a type, id-expression, etc to see what sticks. When it sees ~value, it tries to parse it using cp_parser_class_name (because of the ~),

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

On 12/4/18 11:56 AM, Nick Clifton wrote: OK, revised (v5) patch attached. Is this version acceptable to all ? Looks good to me. Independently, do you see a reason not to disable the old demangler entirely? Jason

Re: [PATCH 10/10] Port testsuite to GCN

On 26/11/2018 21:13, Mike Stump wrote: On Nov 26, 2018, at 12:04 PM, Mike Stump wrote: I'll Ok the signal one, if you prefer it over a dummy signal routine. Though, would be nice for you to add signal if possible/reasonable. Oh, and my long term thinking on signal is that logically, it's

[committed] PR testsuite/86540, twiddle for aarch64

As outlined in the PR, the aarch64 has a non-default value for CASE_VALUES_THRESHOLD which changes decisions in switch lowering. Those changes in switch lowering can expose additional jump threads later in the pipeline which cause heartburn for a couple tests. I looked at all the other ports

Re: [PATCH 10/10] Port testsuite to GCN

I finally got back to investigating this On 21/11/2018 01:00, Jeff Law wrote: --- a/gcc/testsuite/gcc.dg/gimplefe-28.c +++ b/gcc/testsuite/gcc.dg/gimplefe-28.c @@ -1,5 +1,5 @@ /* { dg-do compile { target sqrt_insn } } */ -/* { dg-options "-fgimple -O2" } */ +/* { dg-options "-fgimple -O2

Re: [C++ Patch] Three additional bitfield diagnostic tweaks (a regression fix included)

On 12/6/18 5:49 AM, Paolo Carlini wrote: Hi, I'm bundling together 3 more. In attachment order: 1- Since we decided to explicitly print the wrong type, I suppose we want to consistently do that in templates too. OK. 2- Unfortunately I have to fix another buglet I recently introduced,

Re: [PATCH] v3: C++: improvements to diagnostics using %P (more PR c++/85110)

On 12/6/18 10:38 AM, David Malcolm wrote: On Wed, 2018-12-05 at 19:49 -0500, Jason Merrill wrote: On 12/3/18 5:54 PM, David Malcolm wrote: [...] Thanks for the review. Here's a v3 of the patch; comments inline below. diff --git a/gcc/cp/call.c b/gcc/cp/call.c index ee099cc..cfc5641 100644

[PATCH] v3: C++: improvements to diagnostics using %P (more PR c++/85110)

On Wed, 2018-12-05 at 19:49 -0500, Jason Merrill wrote: > On 12/3/18 5:54 PM, David Malcolm wrote: [...] Thanks for the review. Here's a v3 of the patch; comments inline below. > > diff --git a/gcc/cp/call.c b/gcc/cp/call.c > > index ee099cc..cfc5641 100644 > > --- a/gcc/cp/call.c > > +++

[PATCH][RFC] Associate constant offsets next to symbol

This massages the GIMPLE reassoc pass to associate constant offsets into a invariant base. For one of the testcases in PR63184 this does i.0_1 = i; _2 = i.0_1 * 4; _3 = (sizetype) _2; - _4 = _3 + 4; - _5 = [1] + _4; + _4 = _3; + _5 = [(void *) + 8B] + _4; this performs sth that

Re: [PATCH, OpenACC, 7/8] Multi-dimensional dynamic array support for OpenACC data clauses, libgomp support

On Thu, Dec 06, 2018 at 10:19:43PM +0800, Chung-Lin Tang wrote: > > Why do you call the non-contiguous arrays dynamic arrays? Is that some > > OpenACC term? > > I'd also prefix those with gomp_ and it is important to make it clear what > > is the ABI type shared with the compiler and what are

Re: [PATCH, OpenACC, 7/8] Multi-dimensional dynamic array support for OpenACC data clauses, libgomp support

Hi Jakub, thanks for the swift review a few weeks ago, and apologies I haven't been able to respond sooner. On 2018/10/16 9:13 PM, Jakub Jelinek wrote:>> +/* Dynamic array related data structures, interfaces with the compiler. */ + +struct da_dim { + size_t base; + size_t length; + size_t

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

On 12/6/18 6:00 AM, Christophe Lyon wrote: > On Thu, 6 Dec 2018 at 00:11, Jeff Law wrote: >> >> On 11/29/18 4:43 PM, Martin Sebor wrote: >>> On 11/29/18 4:07 PM, Jeff Law wrote: On 11/29/18 1:34 PM, Martin Sebor wrote: > On 11/16/2018 02:07 AM, Richard Biener wrote: >> On Fri, Nov

CES International 2019 - Attendees List

Hi, This is Christin Braun, have I caught you in the middle of anything? Purpose for my email is that I see you are Exhibiting at CES International 2019. I just wanted to know your interests in acquiring the Attendees/Visitors list of CES International 2019 (The International Consumer

Re: Add a loop versioning pass

Richard Biener writes: >> > The pass contains an awful lot of heuristics :/ Like last year >> > with the interchange pass I would suggest to rip most of it out >> > and first lay infrastructure with the cases you can positively >> > identify without applying heuristics or "hacks" like stripping

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

On Thu, 6 Dec 2018 at 00:11, Jeff Law wrote: > > On 11/29/18 4:43 PM, Martin Sebor wrote: > > On 11/29/18 4:07 PM, Jeff Law wrote: > >> On 11/29/18 1: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: > >

Re: add taishanv110 pipeline scheduling

Hi Wu, I notice you CC'ed the arm maintainers. This is an aarch64 patch as the arm (aarch32) and aarch64 ports are separate in GCC. I've added the aarch64 maintainers on CC for you. On 06/12/18 01:31, wuyuan (E) wrote: Hi ARM maintainers: The taishanv110 core uses generic pipeline

Re: [PATCH] Fix VRP with -fno-delete-null-pointer-checks (PR c/88367, take 2)

On Thu, 6 Dec 2018, Jakub Jelinek wrote: > On Thu, Dec 06, 2018 at 10:05:15AM +0100, Richard Biener wrote: > > Note I wonder if with -fwrapv-pointer NULL automatically becomes a > > valid address? Or is only wrapping around half of the address > > space UB? > > Hadn't thought about

Re: [Patch 4/4][Aarch64] v2: Implement Aarch64 SIMD ABI

Steve Ellcey writes: > This is a patch 4 to support the Aarch64 SIMD ABI [1] in GCC. > > It defines a new target hook targetm.check_part_clobbered that > takes a rtx_insn and checks to see if it is a call to a function > that may clobber partial registers.  It returns true by default, > which

[PATCH] Fix VRP with -fno-delete-null-pointer-checks (PR c/88367, take 2)

On Thu, Dec 06, 2018 at 10:05:15AM +0100, Richard Biener wrote: > Note I wonder if with -fwrapv-pointer NULL automatically becomes a > valid address? Or is only wrapping around half of the address > space UB? Hadn't thought about -fwrapv-pointer, I guess we (especially with

Re: [Patch 3/4][Aarch64] v2: Implement Aarch64 SIMD ABI

LGTM, just minor stuff. Steve Ellcey writes: > +/* Return true if the instruction is a call to a SIMD function, false > + if it is not a SIMD function or if we do not know anything about > + the function. */ > + > +static bool > +aarch64_simd_call_p (rtx_insn *insn) > +{ > + rtx symbol; >

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

Hi Ian, Is the patch OK with you ? Cheers Nick

Re: [PATCH] Restore aarch64 support for asm ("# %a0" : : "i" (0)) (PR target/87598)

Jakub Jelinek writes: > Hi! > > As mentioned in the PR, aarch64 used to allow VOIDmode CONST_INTs > as %aN operands, but r255230 started ICEing on it and r257907 turned > that ICE into error (output_operand_lossage). > > The following patch restores the previous behavior, by allowing such >

Re: [PATCH, Fortran] pad char to int conversions with spaces instead of zeros (legacy)

On 06/12/2018 10:33, Jakub Jelinek wrote: On Wed, Dec 05, 2018 at 06:27:00PM -0800, Jerry DeLisle wrote: I disagree completely. I assume the idea of -fdec-pad-with-spaces is to accomodate some old dec fortran code. The only reason to use some other character is if someone is writing new dec

[C++ Patch] Three additional bitfield diagnostic tweaks (a regression fix included)

Hi, I'm bundling together 3 more. In attachment order: 1- Since we decided to explicitly print the wrong type, I suppose we want to consistently do that in templates too. 2- Unfortunately I have to fix another buglet I recently introduced, completely similar to c++/88222 fixed by Marek.

Re: [PATCH, Fortran] pad char to int conversions with spaces instead of zeros (legacy)

On Wed, Dec 05, 2018 at 06:27:00PM -0800, Jerry DeLisle wrote: > I disagree completely. I assume the idea of -fdec-pad-with-spaces is to > accomodate some old dec fortran code. The only reason to use some other > character is if someone is writing new dec fortran code, which is implying >

Re: [PATCH, Fortran] pad char to int conversions with spaces instead of zeros (legacy)

On 04/12/2018 17:04, Fritz Reese wrote: On Tue, Dec 4, 2018 at 10:12 AM Jakub Jelinek wrote: Just a couple of random comments. -fdec-pad-with-spaces option name doesn't look right, because it doesn't say what the option affects. So perhaps have transfer in the option name? [...] Wouldn't

[PATCH] Adjust PR63184 testcases

Committed. 2018-12-06 Richard Biener PR middle-end/63184 * c-c++-common/pr19807-2.c: Try link only on x86, add xfailed optimized dump scanning. * c-c++-common/pr19807-3.c: Likewise. diff --git a/gcc/testsuite/c-c++-common/pr19807-2.c

Re: [PATCH, Fortran] pad char to int conversions with spaces instead of zeros (legacy)

On 04/12/2018 15:11, Jakub Jelinek wrote: On Tue, Dec 04, 2018 at 02:47:25PM +, Mark Eggleston wrote: Here is a patch to considered for incorporation into gfortran adding to its legacy support. It pads character to integer conversions using spaces instead of zeros when enabled. The pad

Re: [PATCH][RFC] Poison bitmap_head->obstack

On Wed, 5 Dec 2018, Jeff Law wrote: > On 12/5/18 7:58 AM, Richard Biener wrote: > > On Wed, 5 Dec 2018, Jeff Law wrote: > > > >> On 12/4/18 6:16 AM, Richard Biener wrote: > >>> > >>> This tries to make bugs like that in PR88317 harder to create by > >>> introducing a bitmap_release function that

Re: [PATCH] Fix VRP with -fno-delete-null-pointer-checks (PR c/88367)

On Thu, 6 Dec 2018, Jakub Jelinek wrote: > Hi! > > If we consider -fno-delete-null-pointer-checks as a way to support e.g. AVR > and other targets which can validly place objects at NULL rather than a way > to workaround UBs in code, I believe the following testcase must pass if > there is e.g.

Re: [PATCH] Don't optimize successive divs if there is also a mod with the same last arg (PR tree-optimization/85726)

On Thu, 6 Dec 2018, Jakub Jelinek wrote: > Hi! > > This is my proposal for fixing this PR, just a heuristics when optimizing > successive divides might not be a good idea (first testcase), and includes > Marc's testcases which showed cases where optimizing successive divides is a > good idea

Re: [PATCH] Handle clobber stmts in convert_nonlocal_reference_stmt (PR fortran/88304)

On Thu, 6 Dec 2018, Jakub Jelinek wrote: > Hi! > > The following patch handles clobber stmts the same how we handle them in > convert_local_reference_stmt, if it is the clobber with decl on the lhs and > that lhs needs to be replaced by a field inside of a structure, the clobber > is replaced by

Re: [patch,openacc] Propagate independent clause for OpenACC kernels pass

On Wed, 5 Dec 2018, Julian Brown wrote: > On Tue, 4 Dec 2018 14:55:03 +0100 > Richard Biener wrote: > > > On Tue, 4 Dec 2018, Jakub Jelinek wrote: > > > > > On Mon, Dec 03, 2018 at 11:40:39PM +, Julian Brown wrote: > > > > Jakub asked in the following email at the time of the patch > > >

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

On 30 November 2018 10:47:45 CET, "Martin Liška" wrote: >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