Re: [PATCH] Add define_insn_and_split for combine to detect x < 123U ? -1 : 0 (PR target/88425)

On Tue, Dec 11, 2018 at 08:44:00AM +0100, Uros Bizjak wrote: > > --- gcc/config/i386/i386.md.jj 2018-11-22 10:40:31.179683319 +0100 > > +++ gcc/config/i386/i386.md 2018-12-10 11:24:49.785830186 +0100 > > @@ -17195,6 +17195,24 @@ (define_insn "*x86_movcc_0_m1_neg" > > (set_attr "mode" "")

Re: [PATCH] Make LTO tests that require recent binutils UNSUPPORTED with older ones (PR lto/86004)

Hi Jakub, > As mentioned in the PR, older binutils (like 2.25) complain on these tests > when using -r that: > plugin needed to handle lto object > The following patch introduces an effective target and guards those tests on > a linker with this issue fixed. > > Regtested on x86_64-linux and

Re: [PATCH] Add define_insn_and_split for combine to detect x < 123U ? -1 : 0 (PR target/88425)

On Tue, Dec 11, 2018 at 8:27 AM Jakub Jelinek wrote: > > Hi! > > For the following testcase (x < 123U ? -1U : 0) we emit worse code than for > (x < y ? -1U : 0). That is because the generic code canonicalizes x < 123U > comparisons into x <= 122U. For this particular case, we want LTU though, >

[PATCH] Make LTO tests that require recent binutils UNSUPPORTED with older ones (PR lto/86004)

Hi! As mentioned in the PR, older binutils (like 2.25) complain on these tests when using -r that: plugin needed to handle lto object The following patch introduces an effective target and guards those tests on a linker with this issue fixed. Regtested on x86_64-linux and i686-linux, plus

[PATCH] Add define_insn_and_split for combine to detect x < 123U ? -1 : 0 (PR target/88425)

Hi! For the following testcase (x < 123U ? -1U : 0) we emit worse code than for (x < y ? -1U : 0). That is because the generic code canonicalizes x < 123U comparisons into x <= 122U. For this particular case, we want LTU though, as that sets carry and we can then just sbb. The following patch

[C PATCH] Fix ubsan -fsanitize=float-cast-overflow ICE (PR sanitizer/88426)

Hi! The following testcase ICEs since the c_save_expr removal. Unlike other spots where we use save_expr and potentially pass that to function ubsan calls, in this case we weren't calling c_fully_fold and c_fully_fold_internal unfortunately doesn't recurse into CALL_EXPRs, so the gimplifier then

Re: [PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

On Mon, Dec 10, 2018 at 04:30:11PM -0700, Martin Sebor wrote: > Some of my testing exposed a minor problem in GCC 9's validation > of the type of function parameters referred to by attribute > positional arguments. Whereas GCC 8 accepts all C integer types, > including enumerated types, such as:

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

On Mon, Dec 10, 2018 at 05:33:19PM -0700, Jeff Law wrote: > >> where di.num_comps is just strlen (mangled) * 2. Without any analysis > >> whatsoever, bumping the "recursion" limit will just mean we can process 1.5 > >> times long names. Either we need more precise analysis on what we are > >>

[committed] [PR tree-optimization/80520] Throttle path splitting slightly.

This is a pre-req for fixing 80520. Essentially the goal here is to keep the key code in this form: [ ... ] if (_20 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 531502203]: _18 = _25 ^ 2567483615; [local count: 1063004407]: # prephitmp_49 = PHI <_25(3),

[wwwdocs] gcc-4.7/changes.html -- simplify reference to OpenMP

At first I was going to change http to https for this link, but given this is GCC 4.7, simply using a textual reference feels safer. Applied. Gerald Index: gcc-4.7/changes.html === RCS file:

[libstdc++,doc] Update reference to epubcheck in libstdc++ docs

Committed. Gerald 2018-12-10 Gerald Pfeifer * doc/xml/manual/documentation_hacking.xml: Update reference to epubcheck. Index: libstdc++-v3/doc/xml/manual/documentation_hacking.xml === ---

[Committed] PR fortran/87922 -- Additional checks for ASYNCHRONOUS

I've committed the attached patch to trunk and branch-8. ChangeLogs on trunk record wrong PR number. I fix those someday. 2018-12-10 Steven G. Kargl PR fortran/87922 * io.c (gfc_match_open): Additional checks on ASYNCHRONOUS. 2018-12-10 Steven G. Kargl PR

C++ PATCH for c++/86608, reading constexpr volatile variable

A template-argument for a non-type template-parameter shall be a converted constant expression. But an lvalue-to-rvalue conversion applied to a volatile glvalue is not allowed to be part of the evaluation of a constant expression. So this test should be rejected. The non_const_var_error tweaks

Re: [PATCH AutoFDO/4]Fix profile count computation/propagation.

On Thu, Nov 8, 2018 at 6:33 AM Jeff Law wrote: > > On 10/31/18 12:34 AM, bin.cheng wrote: > > Hi, > > This patch fixes AutoFDO breakage on trunk. The main reason for breakage > > is AutoFDO > > relies on standalone edge count computing and propagating profile > > count/probability info > > on

[committed] avoid -Wrestrict on structs copies with unknown offset and constant size (PR 86196)

A fix for pr85753 I committed back in may introduced a subtle logic error that cause false positives for copies involving unknown offsets into non-array objects. The attached patch corrects this mistake. I have committed it as obvious in r266967 after verifying it on x86_64-linux. The

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

On 12/10/18 8:34 AM, Jason Merrill wrote: > On Mon, Dec 10, 2018 at 10:10 AM Jakub Jelinek wrote: >> On Mon, Dec 10, 2018 at 02:52:39PM +, Michael Matz wrote: >>> On Fri, 7 Dec 2018, H.J. Lu wrote: >>> >> On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton wrote: >>> >>> Is the patch

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

On Mon, Dec 10, 2018 at 1:55 PM Jakub Jelinek wrote: > > On Mon, Dec 10, 2018 at 10:20:24AM -0800, Ian Lance Taylor wrote: > > > I think it is a bad idea to use the same macro and value for both the > > > recursion limit and essentially stack limit. For the latter, it should > > > actually

[PATCH] accept all C integer types in function parameters referenced by alloc_align (PR 88363)

Some of my testing exposed a minor problem in GCC 9's validation of the type of function parameters referred to by attribute positional arguments. Whereas GCC 8 accepts all C integer types, including enumerated types, such as: enum AllocAlign { Align16 = 16, Align32 = 32 }; __attribute__

Re: [committed] hppa: Add target support infrastructure for D front end

On 2018-12-09 5:19 p.m., Iain Buclaw wrote: > Thanks! Shouldn't this be made available to all hppa* configurations > though? Or just conservatively adding it for now. I was just being conservative.  It took a couple of days to add the linux details for libphobos and I'm more familiar with it.

Re: PR88346, Inconsistent list of CPUs supported by the rs6000 backend after r266502

Hi Alan, Let's ask David? (Cc:ed). Strange that no one noticed powerpc64 before; titan and rs64 aren't so strange though ;-) Segher On Fri, Dec 07, 2018 at 09:00:39PM +1030, Alan Modra wrote: > This patch removes the %e error for AIX, since it seems there has been > no attempt to keep

libbacktrace integration for _GLIBCXX_DEBUG mode

Hi     Here is the integration of libbacktrace to provide the backtrace on _GLIBCXX_DEBUG assertions.     I decided to integrate it without impacting the build scripts. Users just need to install libbacktrace and once done _GLIBCXX_DEBUG will look for it and start using it if supported. The

[PATCH 3/4] c/c++, asm: Use nicer error for const and restrict

Not all qualifiers are asm qualifiers. We can talk about that in a nicer way than just giving a generic parser error. This also adds two testcases for C++, that previously were for C only. 2018-12-10 Segher Boessenkool c/ * c-parser.c (c_parser_asm_statement) : Give a more

[PATCH 4/4] c++, asm: Do not handle any asm-qualifiers in top-level asm

Previously, "volatile" was allowed. Changing this simplifies the code, makes things more regular, and makes the C and C++ frontends handle this the same way. 2018-12-10 Segher Boessenkool cp/ * parser.c (cp_parser_asm_definition): Do not allow any asm qualifiers on top-level

[PATCH 2/4] c/c++, asm: Use nicer error for duplicate asm qualifiers

Also as suggested by Jason. Segher 2018-12-10 Segher Boessenkool c/ * c-parser.c (c_parser_asm_statement): Keep track of the location each asm qualifier is first seen; use that to give nicer "duplicate asm qualifier" messages. Delete 'quals" variable, instead pass

[PATCH 0/4] c/c++, asm: Various updates

This ties up some loose ends, and adds some more testcases. Tested on powerpc64-linux {-m32,-m64}. Is this okay for trunk? Segher Segher Boessenkool (4): c/c++, asm: Write the asm-qualifier loop without "done" boolean c/c++, asm: Use nicer error for duplicate asm qualifiers c/c++, asm:

[PATCH 1/4] c/c++, asm: Write the asm-qualifier loop without "done" boolean

As suggested by Jason. Segher 2018-12-10 Segher Boessenkool c/ * c-parser.c (c_parser_asm_statement): Rewrite the loop to work without "done" boolean variable. cp/ * parser.c (cp_parser_asm_definition): Rewrite the loop to work without "done" boolean

Re: [PATCH 1/4] introduce struct strlen_data_t into gimple-fold

Jeff, is there something you are expecting me to change in response to this or have you just not gotten around to reviewing the rest? Martin On 11/28/18 9:26 PM, Jeff Law wrote: On 11/25/18 5:05 PM, Martin Sebor wrote: If so, then I think we need to look for a better name than MAXSIZE and

Re: [PATCH] PR86957

On 12/06/2018 05:54 PM, Indu Bhagat wrote: 2. I do however see other tests (a total of 23) which are have regressed from PASS --> UNRESOLVED. A diff is attached. Each one of them is due to "Error/Warning threshold exceeded: 1 0 (max. 1 3)" False alarm. Looks like there is some

Re: [PATCH] Delete powerpcspe

On Mon, Dec 10, 2018 at 06:25:31PM +, Andrew Jenner wrote: > Sorry for the slow response on this, I was on vacation last week. > > On 03/12/2018 21:48, Jakub Jelinek wrote: > >I'd give the maintainers the last week to act if they don't want this > >to happen and if nothing happens, commit it.

[Committed] PR fortran/88269 -- Check for missing UNIT/NEWUNIT

The attach patch has been coommitted to 7-branch, 8-branch, and trunk after successful regression testing. 2018-12-10 Steven G. Kargl PR fortran/88269 * io.c (io_constraint): Update macro. If locus line buffer is NULL, use gfc_current_locus in error messages.

C++ PATCH for c++/88216, ICE with class type in non-type template parameter

Here we were crashing in cxx_eval_constant_expression: 4600 /* We can only get here in checking mode via 4601 build_non_dependent_expr, because any expression that 4602 calls or takes the address of the function will have 4603 pulled a

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

> On Mon, Dec 10, 2018 at 02:09:50PM +, Mark Eggleston wrote: > > > > On 06/12/2018 10:20, Mark Eggleston wrote: > > > > Yes. Mark, you'll need to also patch iresolve.c (gfc_resolve_transfer) > > > > to affect non-constant resolution. > > > Thanks for the hint. > > > > I've looked at

Re: [PATCH] [RFC] PR target/52813 and target/11807

On понеделник, 10 декември 2018 г. 11:21:53 EET Richard Sandiford wrote: > Dimitar Dimitrov writes: > > I have tested this fix on x86_64 host, and found no regression in the C > > and C++ testsuites. I'm marking this patch as RFC simply because I don't > > have experience with other

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

On Mon, Dec 10, 2018 at 10:20:24AM -0800, Ian Lance Taylor wrote: > > I think it is a bad idea to use the same macro and value for both the > > recursion limit and essentially stack limit. For the latter, it should > > actually compute expected stack size > > (i.e. di.num_comps * sizeof

Re: [PATCH] Delete powerpcspe

Sorry for the slow response on this, I was on vacation last week. On 03/12/2018 21:48, Jakub Jelinek wrote: I'd give the maintainers the last week to act if they don't want this to happen and if nothing happens, commit it. PR81084 lists all the reasons why it should be removed when it is

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

On Mon, Dec 10, 2018 at 7:35 AM Jakub Jelinek wrote: > > On Mon, Dec 10, 2018 at 03:26:18PM +, Nick Clifton wrote: > > >> My current suggestion > > >> is to raise the limit to 2048, which allows the libiberty patch to > > >> pass. But do you have a feel for how much is a realistic limit ? >

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

On Mon, Dec 10, 2018 at 02:09:50PM +, Mark Eggleston wrote: > > On 06/12/2018 10:20, Mark Eggleston wrote: > > > Yes. Mark, you'll need to also patch iresolve.c (gfc_resolve_transfer) > > > to affect non-constant resolution. > > Thanks for the hint. > > I've looked at gfc_resolve_transfer

Re: [gofrontend-dev] Re: libgo patch committed: Add precise stack scan support

On Mon, Dec 10, 2018 at 1:41 AM Matthias Klose wrote: > On 06.12.18 00:09, Ian Lance Taylor wrote: > > This libgo patch by Cherry Zhang adds support for precise stack > > scanning to the Go runtime. This uses per-function stack maps stored > > in the exception tables in the language-specific

[PATCH, i386]: Fix PR88418, ICE in extract_insn

Hello! For vector modes we have to use vector_operand predicate, which rejects unaligned operands for non-avx targets. 2018-12-10 Uros Bizjak PR target/88418 * config/i386/i386.c (ix86_expand_sse_cmp): For vector modes, check operand 1 with vector_operand predicate.

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

On Mon, Dec 10, 2018 at 03:26:18PM +, Nick Clifton wrote: > >> My current suggestion > >> is to raise the limit to 2048, which allows the libiberty patch to > >> pass. But do you have a feel for how much is a realistic limit ? > > > > For recursion limit I think that is fine. > > For just

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

On Mon, Dec 10, 2018 at 10:10 AM Jakub Jelinek wrote: > On Mon, Dec 10, 2018 at 02:52:39PM +, Michael Matz wrote: > > On Fri, 7 Dec 2018, H.J. Lu wrote: > > > > > > > On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton wrote: > > > > > > > > > > > > Is the patch OK with you ? > > > > > > > > > > >

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

Hi David, > Apologies in advance if this has been covered, as I've only been half- > watching this thread, but is it always the case that the recursion > depth can be bounded by some scalar multiple of the number of > characters in the name? Probably, but the point of this patch is to add a

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

Hi Jakub, >> My current suggestion >> is to raise the limit to 2048, which allows the libiberty patch to >> pass. But do you have a feel for how much is a realistic limit ? > > For recursion limit I think that is fine. > For just stack size limit, I think it is extremely small. > I see that in

[PATCH] Make test for Filesystem TS actually use the Filesystem TS

This test was copied from 27_io/filesystem/path/query/is_absolute.cc but should have been modified to test the path type from the TS instead of std::filesystem::path. * testsuite/experimental/filesystem/path/query/is_absolute.cc: Fix test to use TS, not C++17. Tested

Re: [PATCH 01/10] Fix IRA ICE.

On 08/12/2018 16:23, Jeff Law wrote: On 12/8/18 5:14 AM, Richard Sandiford wrote: Andrew Stubbs writes: On 21/11/2018 00:47, Jeff Law wrote: This seems like a really gross hack and sets an expectation that generating registers in the target after IRA has started is OK. It is not OK. THe

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

On Mon, 2018-12-10 at 14:52 +, Michael Matz wrote: > Hi, > > On Fri, 7 Dec 2018, H.J. Lu wrote: > > > > > On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton > > > > wrote: > > > > > > > > > > Is the patch OK with you ? > > > > > > This caused: > > > > > >

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

On Mon, Dec 10, 2018 at 03:12:53PM +, Nick Clifton wrote: > Hi Michael, > > > I think this points toward the limit being _much_ too low. > > Fair enough - several other people have said this as well. So > I have proposed an alternative patch instead. My current suggestion > is to raise the

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

Hi Michael, > I think this points toward the limit being _much_ too low. Fair enough - several other people have said this as well. So I have proposed an alternative patch instead. My current suggestion is to raise the limit to 2048, which allows the libiberty patch to pass. But do you have

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

On Mon, Dec 10, 2018 at 02:52:39PM +, Michael Matz wrote: > On Fri, 7 Dec 2018, H.J. Lu wrote: > > > > > On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton wrote: > > > > > > > > > > Is the patch OK with you ? > > > > > > > > > > This caused: > > > > > >

Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536

Hi, On Fri, 7 Dec 2018, H.J. Lu wrote: > > > On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton wrote: > > > > > > > > Is the patch OK with you ? > > > > > > > This caused: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 > > > > Here is the fix. OK for trunk? I think this points

Re: [PATCH] Improve overhead of tree-affine.c a bit

On Mon, 10 Dec 2018, Kyrill Tkachov wrote: > Hi Richard, > > On 10/12/18 13:44, Richard Biener wrote: > > > > When working on PR63184 I noticed that tree-affine.c is still one of > > the gimple_assign_rhs_to_tree callers and does so quite aggressively > > for no good reason. The following

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

On 06/12/2018 10:20, Mark Eggleston wrote: Yes. Mark, you'll need to also patch iresolve.c (gfc_resolve_transfer) to affect non-constant resolution. Thanks for the hint. I've looked at gfc_resolve_transfer regarding handling of padding when a character variable is passed to transfer

Re: [PATCH] Improve overhead of tree-affine.c a bit

Hi Richard, On 10/12/18 13:44, Richard Biener wrote: When working on PR63184 I noticed that tree-affine.c is still one of the gimple_assign_rhs_to_tree callers and does so quite aggressively for no good reason. The following restricts it to the cases we handle in tree_to_aff_combination,

[PATCH] Improve overhead of tree-affine.c a bit

When working on PR63184 I noticed that tree-affine.c is still one of the gimple_assign_rhs_to_tree callers and does so quite aggressively for no good reason. The following restricts it to the cases we handle in tree_to_aff_combination, axing one unreachable case. It also makes sure to cache

[committed] Fix gcc.target/i386/pr87955.c testcase

Hi! The testcase doesn't emit expected diagnostics on i?86, because the default is -mfpmath=387 there and so the function is perfectly inlinable. The following patch makes sure we compile the testcase with -msse2 -mfpmath=sse everywhere, so it succeeds (or FAILs with the ipa-inline.c change

Re: [PATCH] hppa: Add libphobos support

On 2018-12-09 6:10 p.m., Iain Buclaw wrote: > On Sun, 9 Dec 2018 at 21:16, John David Anglin wrote: >> The attached change implements a first cut at libphobos support on >> hppa/glibc/linux. Test >> results are here: >> . >> >> Okay?

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

On 06/12/18 14:36 -0800, Mike Stump wrote: 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

[PATCH] Fix PR88427

The following restores behavior to before my r266557 fix for symbolic ranges, avoiding the ICE. Bootstrap & regtest running on x86_64-unknown-linux-gnu. Richard. 2018-12-10 Richard Biener PR tree-optimization/88427 * vr-values.c (vr_values::extract_range_from_phi_node):

[PATCH] Fix PR88415

The following fixes gimple_assign_set_rhs_with_ops to transfer EH info so that the stale stmts are not left in the EH tables. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2018-12-10 Richard Biener PR middle-end/88415 * gimple.c

Re: [PATCH] Fix *ivdep* tests on SPARC etc. (PR testsuite/88369, take 2)

Hi Jakub, > As mentioned in the PR, another testcase was missed, this patch modifies > that one too. Ok for trunk? > > 2018-12-10 Jakub Jelinek > > PR testsuite/88369 > * gcc.dg/vect/vect-ivdep-1.c: Prune versioning for alignment messages. > * gcc.dg/vect/vect-ivdep-2.c:

[PATCH, libphobos] Committed fix modify immutable error on Solaris

Hi, This is another Solaris backport from druntime 2.079, fixing a build error in the core.thread module. Bootstrapped and tested on i386-pc-solaris2.11. Committed to trunk as r266950. -- Iain --- diff --git a/libphobos/libdruntime/core/thread.d b/libphobos/libdruntime/core/thread.d index

[PATCH] Fix *ivdep* tests on SPARC etc. (PR testsuite/88369, take 2)

On Thu, Dec 06, 2018 at 08:07:30AM +0100, Jakub Jelinek wrote: > On (at least some of these) tests and on some targets, GCC prints messages > like: > ./cc1 -quiet -O3 -fopt-info-vec-optimized -mvis vect-ivdep-1.c > vect-ivdep-1.c:11:3: optimized: loop vectorized using 8 byte vectors >

Re: [PATCH] [RFC] PR target/52813 and target/11807

Dimitar Dimitrov writes: > I have tested this fix on x86_64 host, and found no regression in the C > and C++ testsuites. I'm marking this patch as RFC simply because I don't > have experience with other architectures, and I don't have a setup to > test all architectures supported by GCC. > >

[testsuite] Small tweak for Visium

Tested on visium-elf and x86_64-suse-linux, applied on mainline and 8 branch. 2018-12-10 Eric Botcazou * c-c++-common/patchable_function_entry-decl.c: Pass -mcpu=gr6 for Visium and remove other specific handling. * c-c++-common/patchable_function_entry-default.c:

Add missing def of TARGET_VXWORKS_HAVE_CTORS_DTORS for VxWorksAE

Hello, The attached patch fixes an oversight from https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01432.html where a new VxWorks ports control macro was introduced, and the * config/vxworksae.h: Also define TARGET_VXWORKS_HAVE_CTORS_DTORS. part was missing from what was checked in.

Re: [PR 88214] Check that an argument is pointer before attempting agg jf construction from it

On Fri, Dec 7, 2018 at 3:59 PM Martin Jambor wrote: > > Hi, > > ICE in PR 88214 happens because a type-mismatch in K C code makes > IPA-CP analysis call ao_ref_init_from_ptr_and_size on an integer > SSA_NAME, this function in turn constructs a temporary MEM_REF based on > that integer SSA_NAME

[C++ Patch] Add location_t parameter to grokvardecl

Hi, the other day I noticed that we weren't getting right the first location of pr53037-4.C, for a variable, whereas the next one, for a function, was Ok. Indeed, we were passing a location only to grokfndecl. In other terms, I found a good empirical reason to move the declaration of the

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

On 2018/12/7 04:57 AM, Thomas Schwinge wrote>> --- a/libgomp/plugin/plugin-nvptx.c +++ b/libgomp/plugin/plugin-nvptx.c +struct goacc_asyncqueue * +GOMP_OFFLOAD_openacc_async_construct (void) +{ + struct goacc_asyncqueue *aq += GOMP_PLUGIN_malloc (sizeof (struct goacc_asyncqueue)); +

Don't try to use libgcc-unwind.map with --disable-shared (PR bootstrap/65725)

When configuring with --disable-shared, Solaris bootstrap with the system ld fails since libgcc-unwind.map is missing. This is no wonder, given that the file is only generated with --enable-shared. The following patch, from the PR, fixes this. Bootstrapped on amd64-pc-solaris2.11, installed on

Re: [PATCH, og8] Add OpenACC 2.6 `acc_get_property' support

On 2018/12/6 2:16 AM, Maciej W. Rozycki wrote: AFAIK, things like strlen are already available in iso_c_binding, in forms like "C_strlen". Can you check again if that 'openacc_c_string' module is really necessary? Any pointers please? I can't see `c_strlen' or any equivalent interface