Re: [PATCH] Fix -gdwarf-5 -gsplit-dwarf ICEs (PR debug/89498)

2019-03-12 Thread Alexandre Oliva
On Mar 9, 2019, Alexandre Oliva wrote: > On Mar 9, 2019, Jakub Jelinek wrote: >> If so, then all we need is likely my patch + some documentation change, >> though not sure where exactly it should be documented, some Wiki we refer >> in include/dwarf2.def, or what? > Hmm, I was thinking of pla

Re: [PATCH] avoid assuming every type has a size (PR 89662)

2019-03-12 Thread Richard Biener
On Mon, Mar 11, 2019 at 9:16 PM Martin Sebor wrote: > > A -Warray-bounds enhancement committed last year into GCC 9 > introduced an assumption that the MEM_REF type argument has > a size. The test case submitted in PR89662 does pointer > addition on void*, in which the MEM_REF type is void*, whic

Re: RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

2019-03-12 Thread Richard Biener
On Mon, Mar 11, 2019 at 11:39 PM Steve Ellcey wrote: > > This is a proposed GCC patch that allows targets to modify the names of > the libmvec routines that get called. Currently, if you build ToT GCC > on Aarch64 and include this glibc patch: > > https://sourceware.org/ml/libc-alpha/2019

Re: [PATCH] Loop split upon semi-invariant condition (PR tree-optimization/89134)

2019-03-12 Thread Richard Biener
On Tue, Mar 12, 2019 at 7:20 AM Feng Xue OS wrote: > > This patch is composed to implement a loop transformation on one of its > conditional statements, which we call it semi-invariant, in that its > computation is impacted in only one of its branches. > > Suppose a loop as: > > void f (std:

Re: RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

2019-03-12 Thread Jakub Jelinek
On Tue, Mar 12, 2019 at 09:25:35AM +0100, Richard Biener wrote: > I think this needs to be fixed on the glibc side - if glibc advertises > > float expf (float, float) > __attribute__((simd(notinbranch),alias("__expf_finite")) > > or so then you of course have to provide an implementation that mat

Re: RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

2019-03-12 Thread Jakub Jelinek
On Tue, Mar 12, 2019 at 09:33:40AM +0100, Jakub Jelinek wrote: > On Tue, Mar 12, 2019 at 09:25:35AM +0100, Richard Biener wrote: > > I think this needs to be fixed on the glibc side - if glibc advertises > > > > float expf (float, float) > > __attribute__((simd(notinbranch),alias("__expf_finite"))

Re: [PATCH][stage1] Wrap option names in gcc internal messages with %< and %>.

2019-03-12 Thread Martin Liška
On 3/11/19 4:51 PM, Martin Sebor wrote: > On 3/11/19 2:13 AM, Martin Liška wrote: >> Hi. >> >> The patch adds a lot of option name wrapping in string format messages. I >> added a new contrib >> script (contrib/check-internal-format-escaping.py) that is parsing gcc.pot >> file and reports >> erro

[PATCH][stage1] Refactor gimple_fold_builtin_memory_op function.

2019-03-12 Thread Martin Liška
Hi. The patch is about simplification and usage of enum types. ENDP integer does not make much sense in this usage. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed after stage1 opens? Thanks, Martin 2019-03-11 Martin Liska * gimple-fold.c

[PATCH] GCOV: print {start,end}_column in JSON file and gcov-dump tool.

2019-03-12 Thread Martin Liška
Hi. This is one more enhancement of JSON intermediate format export. Apart from that, I also improved documentation of the format and gcov-dump output. Patch survives gcov.exp regression tests. I'm going to install the patch after some time. Thanks, Martin gcc/ChangeLog: 2019-03-11 Martin Lis

New target hook for function scratch registers (PR 89628)

2019-03-12 Thread Richard Sandiford
Steve Ellcey writes: > Richard, > > I don't necessarily disagree with anything in your comments and long > term I think that is the right direction, but I wonder if that level of > change is appropriate for GCC Stage 4 which is where we are now. Your > changes would require fixes in shared code,

[PATCH] s390.md and tilepro.c diagnostics bug fix (PR target/52726)

2019-03-12 Thread Jakub Jelinek
Hi! These are the only remaining cases of gcc-internal-format diagnostics using HOST_WIDE_INT_PRINT*. That is wrong because the string depends on the exact host, and xgettext doesn't handle it anyway, so in gcc.pot the messages are truncated at the spot where HOST_WIDE_INT_PRINT* appears. See al

Re: [PATCH 0/7] S/390: Rework instruction scheduling.

2019-03-12 Thread Robin Dapp
> Please adjust the year and the author in gcc/config/s390/3906.md. Ok with > that change. Changed that and also simplified the longrunning checks. gcc/ChangeLog: 2019-03-12 Robin Dapp * config/s390/s390.c (LONGRUNNING_THRESHOLD): Remove. (s390_is_fpd): Add. (s390_is

Re: [PATCH] s390.md and tilepro.c diagnostics bug fix (PR target/52726)

2019-03-12 Thread Andreas Krebbel
On 12.03.19 10:58, Jakub Jelinek wrote: > 2019-03-12 Jakub Jelinek > > PR target/52726 > * config/s390/s390.md (tabort): Use %wd instead of > HOST_WIDE_INT_PRINT_DEC in error message, reword to avoid two capital > letters and periods. > * config/tilepro/tilepro.c (

Re: [PATCH 8/8] S/390: Change test case to reflect scheduling changes.

2019-03-12 Thread Robin Dapp
This fixes a newly introduced test failure. --- 2019-03-12 Robin Dapp * gcc.target/s390/memset-1.c: Do not require stcy. diff --git a/gcc/testsuite/gcc.target/s390/memset-1.c b/gcc/testsuite/gcc.target/s390/memset-1.c index 3e201df1aed..9463a77208b 100644 --- a/gcc/testsuite/gcc.targ

[PATCH] S/390: Perform more aggressive inlining

2019-03-12 Thread Robin Dapp
Hi, this patch sets the inlining parameters for z13 and later to rather aggressive values in response to PR85103 that caused performance regressions in SPEC2006's sjeng and gobmk benchmarks. Regards Robin -- gcc/ChangeLog: 2019-03-12 Robin Dapp * config/s390/s390.c (s390_option_ov

Re: How to add %' into gfc_fatal_error

2019-03-12 Thread Martin Liška
On 3/11/19 6:23 PM, Steve Kargl wrote: > On Mon, Mar 11, 2019 at 12:07:55PM -0400, David Malcolm wrote: >> On Mon, 2019-03-11 at 15:18 +0100, Martin Liška wrote: >>> Hi. >>> >>> I would like to add %' into __gcc_gfc__ in order to handle: >>> >>> ./xgcc -B. /tmp/module.ii -Wformat -c >>> /home/marxi

[C++ Patch] PR 89571 ("[9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238")

2019-03-12 Thread Paolo Carlini
Hi, this is just an error recovery ICE but maybe we can fix it in time for 9.1.0, like c++/89488, which is somehow related. Indeed, the problem is again a !DEFERRED_NOEXCEPT_SPEC_P gcc_assert triggering where, earlier, process_subob_fn had maybe_instantiate_noexcept returning false (in c++/89

Patch ping (Re: [PATCH] ARM cmpsi2_addneg fix follow-up (PR target/89506))

2019-03-12 Thread Jakub Jelinek
On Mon, Mar 04, 2019 at 10:04:01AM +0100, Jakub Jelinek wrote: > The first one uses constraints and no C code in the output, I believe it is > actually more expensive for compile time, because if one just reads what > constrain_operands needs to do for another constraint, it is quite a lot. > I've

Re: [PATCH] Fix -gdwarf-5 -gsplit-dwarf ICEs (PR debug/89498)

2019-03-12 Thread Jakub Jelinek
On Tue, Mar 12, 2019 at 04:32:35AM -0300, Alexandre Oliva wrote: > When location lists are referenced in DW_AT_location attributes by an > absolute address in DW_FORM_sec_offset, the corresponding > DW_AT_GNU_locviews attribute can be a DW_FORM_sec_offset with an > absolute address as well. Note,

Patch ping (Re: [PATCH] Fix -gdwarf-5 -gsplit-dwarf ICEs (PR debug/89498))

2019-03-12 Thread Jakub Jelinek
On Mon, Mar 04, 2019 at 11:35:50PM +0100, Jakub Jelinek wrote: > 2019-03-04 Jakub Jelinek > > PR debug/89498 > * dwarf2out.c (size_of_die): For dw_val_class_view_list always use > DWARF_OFFSET_SIZE. > (value_format): For dw_val_class_view_list never use DW_FORM_loclistx.

Re: [Patch, Fortran] PR 89601: [8/9 Regression] [PDT] ICE: Segmentation fault (in resolve_component)

2019-03-12 Thread Janus Weil
Hi Steve, > > Technically the ICE is a regression, but since it happens on invalid > > code only, backporting is not essential IMHO (but might still be > > useful). Ok for trunk? And 8-branch? > > Looks good to me with a minor suggestion. See below. thanks for the comments. Updated patch attache

Re: [PATCH, wwwdocs] Mention -march=armv8.5-a and other new command line options for AArch64 and Arm for GCC 9

2019-03-12 Thread Kyrill Tkachov
Hi Sudi, On 2/22/19 10:45 AM, Sudakshina Das wrote: Hi This patch documents the addition of the new Armv8.5-A and corresponding extensions in the gcc-9/changes.html. As per https://gcc.gnu.org/about.html, I have used W3 Validator. Is this ok for cvs? Thanks Sudi Index: htdocs/gcc-9/changes.

Re: [PATCH] S/390: Perform more aggressive inlining

2019-03-12 Thread Andreas Krebbel
On 12.03.19 11:22, Robin Dapp wrote: > Hi, > > this patch sets the inlining parameters for z13 and later to rather > aggressive values in response to PR85103 that caused performance > regressions in SPEC2006's sjeng and gobmk benchmarks. > > Regards > Robin > > -- > > gcc/ChangeLog: > > 2019-

Re: [PATCH 0/7] S/390: Rework instruction scheduling.

2019-03-12 Thread Andreas Krebbel
On 12.03.19 11:00, Robin Dapp wrote: >> Please adjust the year and the author in gcc/config/s390/3906.md. Ok with >> that change. > > Changed that and also simplified the longrunning checks. > > gcc/ChangeLog: > > 2019-03-12 Robin Dapp > > * config/s390/s390.c (LONGRUNNING_THRESHOLD

Re: [PATCH 8/8] S/390: Change test case to reflect scheduling changes.

2019-03-12 Thread Andreas Krebbel
On 12.03.19 11:02, Robin Dapp wrote: > This fixes a newly introduced test failure. > > > --- > > 2019-03-12 Robin Dapp > > * gcc.target/s390/memset-1.c: Do not require stcy. > Ok. Thanks! Andreas

[PATCH] Fix dumping of "former thunk" info in cgraph dump

2019-03-12 Thread Martin Jambor
Hi, I have forgot to add a newline in cgraph_node dumping that I added last week (the patch to partially address PR 88235). When discussing this, we agreed with Honza that if we dump that a node is a former thunk, we should also dump the various info in the thunk sub-structure that fomrer_thunk_p

[PATCH V2] PR88497 - Extend reassoc for vector bit_field_ref

2019-03-12 Thread Kewen.Lin
Hi, As the comments from Richard and Segher (Thanks!), I've made some changes by adding some checks and extensions. *) Check whether vector type available on target machine, *) Check whether vector operation available on target machine, *) Extend the vector operation support to MULT/BIT

[PATCH, d] Committed merge with upstream dmd

2019-03-12 Thread Iain Buclaw
Hi, This patch merges the D front-end implementation with dmd upstream 7423993c9. Backports a fix for extern(C++) mangling for substituted basic types that are target-specific. Introduces a new method that currently does nothing, but could in future make use of flag_abi_version as extern(C++) in

Re: RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

2019-03-12 Thread Joseph Myers
On Tue, 12 Mar 2019, Richard Biener wrote: > It shouldn't be difficult to provide an alias from the glibc side, no? > How does x86 avoid this issue? There are static-only wrappers in libmvec_nonshared.a to work around the GCC limitation (not included in the shared library, so less efficient th

Re: How to add %' into gfc_fatal_error

2019-03-12 Thread Steve Kargl
On Tue, Mar 12, 2019 at 12:15:01PM +0100, Martin Liška wrote: > On 3/11/19 6:23 PM, Steve Kargl wrote: > > On Mon, Mar 11, 2019 at 12:07:55PM -0400, David Malcolm wrote: > >> On Mon, 2019-03-11 at 15:18 +0100, Martin Liška wrote: > >>> Hi. > >>> > >>> I would like to add %' into __gcc_gfc__ in orde

Re: [PATCH V2] PR88497 - Extend reassoc for vector bit_field_ref

2019-03-12 Thread Bill Schmidt
On 3/12/19 7:57 AM, Kewen.Lin wrote: > Hi, > > As the comments from Richard and Segher (Thanks!), I've made some > changes by adding some checks and extensions. > *) Check whether vector type available on target machine, > *) Check whether vector operation available on target machine, > *)

[GCC-8, Arm, committed] Fix availability of FP16-FP64 conversion instructions

2019-03-12 Thread Andre Vieira (lists)
Hi, Thanks Christophe! I have committed a backport of r269499 including the testism fix r269596 to gcc-8 branch in r269613. gcc/ChangeLog: 2019-03-12 Andre Vieira Backport from mainline 2019-03-08 Andre Vieira * config/arm/arm.h (TARGET_FP16_TO_DOUBLE): Add TARG

Re: How to add %' into gfc_fatal_error

2019-03-12 Thread Martin Liška
On 3/12/19 3:17 PM, Steve Kargl wrote: > On Tue, Mar 12, 2019 at 12:15:01PM +0100, Martin Liška wrote: >> On 3/11/19 6:23 PM, Steve Kargl wrote: >>> On Mon, Mar 11, 2019 at 12:07:55PM -0400, David Malcolm wrote: On Mon, 2019-03-11 at 15:18 +0100, Martin Liška wrote: > Hi. > > I wou

Re: [PATCH V2] PR88497 - Extend reassoc for vector bit_field_ref

2019-03-12 Thread Bill Schmidt
On 3/12/19 9:29 AM, Bill Schmidt wrote: > On 3/12/19 7:57 AM, Kewen.Lin wrote: >> Hi, >> >> As the comments from Richard and Segher (Thanks!), I've made some >> changes by adding some checks and extensions. >> *) Check whether vector type available on target machine, >> *) Check whether vecto

Re: [PATCH V2] PR88497 - Extend reassoc for vector bit_field_ref

2019-03-12 Thread Kewen.Lin
on 2019/3/12 下午11:22, Bill Schmidt wrote: > On 3/12/19 9:29 AM, Bill Schmidt wrote: >> On 3/12/19 7:57 AM, Kewen.Lin wrote: >>> Hi, >>> >>> As the comments from Richard and Segher (Thanks!), I've made some >>> changes by adding some checks and extensions. >>> *) Check whether vector type availa

[PATCH, PR d/87866] Committed redefine realpath as lrealpath in dmd front-end

2019-03-12 Thread Iain Buclaw
Hi, This patch is a second fix for PR d/87866, as dmd front-end function FileName::canonicalName could be called during the semantic pass of import("file") expressions, so still requires that realpath() be redefined. Bootstrapped and ran D2 testsuite on x86_64-linux-gnu. Committed to trunk as r2

Re: [PATCH] avoid assuming every type has a size (PR 89662)

2019-03-12 Thread Martin Sebor
On 3/12/19 2:20 AM, Richard Biener wrote: On Mon, Mar 11, 2019 at 9:16 PM Martin Sebor wrote: A -Warray-bounds enhancement committed last year into GCC 9 introduced an assumption that the MEM_REF type argument has a size. The test case submitted in PR89662 does pointer addition on void*, in w

[PATCH, d/87824]: x86_64-linux multilib issues

2019-03-12 Thread Uros Bizjak
Attached patch fixes libstdc++ includes for multilib d testsuite and fixes runnable/cppa.d testsuite failure with 32bit multilib on x86_64-linux-gnu. 2019-03-12 Uroš Bizjak PR d/87824 * lib/gdc.exp (gdc_include_flags): Find C++ headers by calling libstdc++v3/scripts/testsuite_flag

Re: [PATCH, d/87824]: x86_64-linux multilib issues

2019-03-12 Thread Iain Buclaw
On Tue, 12 Mar 2019 at 18:27, Uros Bizjak wrote: > > Attached patch fixes libstdc++ includes for multilib d testsuite and > fixes runnable/cppa.d testsuite failure with 32bit multilib on > x86_64-linux-gnu. > > > 2019-03-12 Uroš Bizjak > > PR d/87824 > * lib/gdc.exp (gdc_include_flags):

Re: [PATCH, d/87824]: x86_64-linux multilib issues

2019-03-12 Thread Rainer Orth
Hi Iain, > On Tue, 12 Mar 2019 at 18:27, Uros Bizjak wrote: >> >> Attached patch fixes libstdc++ includes for multilib d testsuite and >> fixes runnable/cppa.d testsuite failure with 32bit multilib on >> x86_64-linux-gnu. >> >> >> 2019-03-12 Uroš Bizjak >> >> PR d/87824 >> * lib/gdc.ex

[PATCH][RFC] Teach GIMPLE FE to build proper CFG + SSA (+ loops)

2019-03-12 Thread Richard Biener
This makes an attempt at fixing the most annoying parts of the GIMPLE FE unit testing - the lack of proper CFG preservation and hoops you need to jump through to make the CFG and SSA builders happy. Due to this the __GIMPLE specifiers takes two new flags, "cfg" for GIMPLE-with-a-CFG and "ssa" fo

C++ PATCH for c++/89686 - mixing init-capture and simple-capture in lambda

2019-03-12 Thread Marek Polacek
As Barry explained in the PR, lambda capture is one of simple-capture ...[opt] ...[opt] init-capture where init-capture requires an initializer. Here we have [...xs...] which is ill-formed as it's mingling both of these. Bootstrapped/regtested on x86_64-linux, ok for trunk? Or should I

Re: C++ PATCH for c++/89686 - mixing init-capture and simple-capture in lambda

2019-03-12 Thread Jason Merrill
On 3/12/19 3:59 PM, Marek Polacek wrote: As Barry explained in the PR, lambda capture is one of simple-capture ...[opt] ...[opt] init-capture where init-capture requires an initializer. Here we have [...xs...] which is ill-formed as it's mingling both of these. Bootstrapped/regtest

Re: C++ PATCH for c++/89686 - mixing init-capture and simple-capture in lambda

2019-03-12 Thread Marek Polacek
On Tue, Mar 12, 2019 at 04:07:56PM -0400, Jason Merrill wrote: > On 3/12/19 3:59 PM, Marek Polacek wrote: > > As Barry explained in the PR, lambda capture is one of > > > >simple-capture ...[opt] > >...[opt] init-capture > > > > where init-capture requires an initializer. Here we have >

[patch, fortran] Fix PR 66695, 77746 and 79485

2019-03-12 Thread Thomas Koenig
Hello world, the attached patch fixes three very closely related 7/8/9 regressions. The common root cause of these PRs was that , if a binding label existed, gfc_get_extern_function_decl first looked for that name in the global symbol table for that function and used its backend_decl. If there wa

Re: [PR fortran/60091, patch] - Misleading error messages in rank-2 pointer assignment to rank-1 target

2019-03-12 Thread Thomas Koenig
Hi Harald, how about the attached version? It is quite verbose and produces messages like Error: Expected list of 'lower-bound-expr:' or list of 'lower-bound-expr:upper-bound-expr' at (1) I think this way of specifying error messages +#define BOUNDS_SPEC_LIST "list of %" ... +

Re: [PATCH] Define midpoint and lerp functions for C++20 (P0811R3)

2019-03-12 Thread Joseph Myers
On Tue, 5 Mar 2019, Jonathan Wakely wrote: > The midpoint and lerp functions for floating point types come straight > from the P0811R3 proposal, with no attempt at optimization. I don't know whether P0811R3 states different requirements from the public P0811R2, but the implementation of midpoint

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

2019-03-12 Thread Joseph Myers
On Mon, 11 Mar 2019, Jonathan Wakely wrote: > +proc add_options_for_libatomic { flags } { > +if { [istarget hppa*-*-hpux*] } { > + return "$flags -L../../libatomic/.libs -latomic" > +} It's generally inappropriate to hardcode such ../../libatomic/.libs paths without making sure it'

Re: [PATCH] Define midpoint and lerp functions for C++20 (P0811R3)

2019-03-12 Thread Jonathan Wakely
On 12/03/19 22:49 +, Joseph Myers wrote: On Tue, 5 Mar 2019, Jonathan Wakely wrote: The midpoint and lerp functions for floating point types come straight from the P0811R3 proposal, with no attempt at optimization. I don't know whether P0811R3 states different requirements from the public

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

2019-03-12 Thread Jonathan Wakely
On 12/03/19 23:01 +, Joseph Myers wrote: On Mon, 11 Mar 2019, Jonathan Wakely wrote: +proc add_options_for_libatomic { flags } { +if { [istarget hppa*-*-hpux*] } { + return "$flags -L../../libatomic/.libs -latomic" +} It's generally inappropriate to hardcode such ../../libat

[PATCH, PR d/88957] Committed fix for ICE in tree_could_trap_p with -fsanitize=undefined

2019-03-12 Thread Iain Buclaw
Hi, This patch merges the D front-end implementation with dmd upstream 19b1454b5. Backports fixes for many ICEs that occurred when using the vector .array property in both CTFE and code generation passes. Bootstrapped and regression tested on x86_64-linux-gnu. Committed to trunk as r269627. --

Re: RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

2019-03-12 Thread Steve Ellcey
On Tue, 2019-03-12 at 14:17 +, Joseph Myers wrote: > > On Tue, 12 Mar 2019, Richard Biener wrote: > > > It shouldn't be difficult to provide an alias from the glibc side, no? > > How does x86 avoid this issue? > > There are static-only wrappers in libmvec_nonshared.a to work around the >

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

2019-03-12 Thread John David Anglin
On 2019-03-12 7:05 p.m., Jonathan Wakely wrote: > On 12/03/19 23:01 +, Joseph Myers wrote: >> On Mon, 11 Mar 2019, Jonathan Wakely wrote: >> >>> +proc add_options_for_libatomic { flags } { >>> +    if { [istarget hppa*-*-hpux*] } { >>> +   return "$flags -L../../libatomic/.libs -latomic" >>

Re: RFC: Patch to allow use of DECL_NAME in libmvec calls instead of DECL_ASSEMBER_NAME

2019-03-12 Thread Jakub Jelinek
On Tue, Mar 12, 2019 at 11:21:26PM +, Steve Ellcey wrote: > I like this idea. I have prototyped something, I created 'vector_asm' > as an aarch64 attribute because I couldn't find where to put global > attributes like __simd__. Does anyone know where these are listed? gcc/c-family/c-attribs.

Re: [PATCH, d/87824]: x86_64-linux multilib issues

2019-03-12 Thread Iain Buclaw
On Tue, 12 Mar 2019 at 20:57, Rainer Orth wrote: > > Hi Iain, > > > On Tue, 12 Mar 2019 at 18:27, Uros Bizjak wrote: > >> > >> Attached patch fixes libstdc++ includes for multilib d testsuite and > >> fixes runnable/cppa.d testsuite failure with 32bit multilib on > >> x86_64-linux-gnu. > >> > >>

[PATCH, d] Committed small tidy up gdc testsuite scripts

2019-03-12 Thread Iain Buclaw
Hi, This patch moves the one -fsantize=undefined test to a new ubsan test directory, guarded by check_effective_target_fsanitize_undefined. Another recent change to gdc_include_flags left one variable unused, also noticed that flags was never explicitly returned. Both have been fixed up. Change

Re: [PR fortran/60091, patch] - Misleading error messages in rank-2 pointer assignment to rank-1 target

2019-03-12 Thread Steve Kargl
On Tue, Mar 12, 2019 at 11:19:07PM +0100, Thomas Koenig wrote: > Hi Harald, > > > how about the attached version? It is quite verbose and produces > > messages like > > > > Error: Expected list of 'lower-bound-expr:' or list of > > 'lower-bound-expr:upper-bound-expr' at (1) > > I think this way

Re: [patch, fortran] Fix PR 66695, 77746 and 79485

2019-03-12 Thread Steve Kargl
On Tue, Mar 12, 2019 at 10:42:21PM +0100, Thomas Koenig wrote: > > the attached patch fixes three very closely related 7/8/9 regressions. > The common root cause of these PRs was that , if a binding label > existed, gfc_get_extern_function_decl first looked for that name > in the global symbol tab

Re: [PR fortran/87045, patch] - pointer to array of character

2019-03-12 Thread Steve Kargl
On Sun, Mar 10, 2019 at 10:19:03PM +0100, Harald Anlauf wrote: > The code in the testcase died due to a run-time bounds-check > generated slightly too early, leading to a crash for deferred > character length. Moving the character length check after the > assignment solves the issue. > > Regtests

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

2019-03-12 Thread Hans-Peter Nilsson
Regarding this sometimes-add--latomic(-in-testsuite) that is revisited: When is it appropriate to make the user add -latomic to link their program? Perhaps different answers for fortran and C++. I'm guessing "always when using any atomic construct" for C. I had a grep-look in gcc/doc before aski

Re: [PATCH] Loop split upon semi-invariant condition (PR tree-optimization/89134)

2019-03-12 Thread Feng Xue OS
Richard, Thanks for your comment. Yes, it is like kind of jump threading with knowledge of loop structure. And what is rough time for GCC 10? Regards, Feng From: Richard Biener Sent: Tuesday, March 12, 2019 4:31:49 PM To: Feng Xue OS Cc: gcc-patches@gcc.

Re: [PATCH] Fix libstdc++ tests requiring atomic support on hppa-hpux

2019-03-12 Thread Joseph Myers
On Tue, 12 Mar 2019, Hans-Peter Nilsson wrote: > When is it appropriate to make the user add -latomic to link > their program? Perhaps different answers for fortran and C++. > I'm guessing "always when using any atomic construct" for C. I think we should link with --as-needed -latomic --no-as-ne

Go patch committed: Add debugging helper function debug_go_type

2019-03-12 Thread Ian Lance Taylor
This patch to the Go frontend by Than McIntosh adds a new debugging helper function debug_go_type. This is intended to display the contents of a Type object in a way useful to debugging a run of the compiler. Prior to this the only useful alternative for debugging types was invoking the mangled_n

Go patch committed: Compare parse methods when exporting interface types

2019-03-12 Thread Ian Lance Taylor
This patch by Than McIntosh fixes the Go frontend to compare parse methods when indexing interface types for export. This change fixes a bug in which two interface types were being incorrectly commoned (considered identical) in the initial stages of writing out types to export data. The indexer d