Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

On 1/31/20 11:06 PM, David Malcolm wrote: > On Fri, 2020-01-31 at 16:59 +, Bernd Edlinger wrote: >> Hi, >> >> this is patch is heavily based on David's original patch here: >> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01409.html >> >> and addresses Jakub's review comments here: >> https:/

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

Hi Segher, On 2/1/20 2:32 AM, Segher Boessenkool wrote: > On Fri, Jan 31, 2020 at 11:38:04PM +, Bernd Edlinger wrote: >> On 1/31/20 11:54 PM, Segher Boessenkool wrote: >>> about most, which caused me to open PR93168, is TERM=screen (which is >>> what tmux uses), so at least exclude that one?

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

On Fri, Jan 31, 2020 at 11:38:04PM +, Bernd Edlinger wrote: > On 1/31/20 11:54 PM, Segher Boessenkool wrote: > > about most, which caused me to open PR93168, is TERM=screen (which is > > what tmux uses), so at least exclude that one? And doing all this > > Definitely, if the situation with tm

Re: [PATCH] V12 patch #5 of 14, Make -mpcrel default for -mcpu=future on little endian Linux 64-bit systems

Hi! On Thu, Jan 09, 2020 at 07:40:08PM -0500, Michael Meissner wrote: > * config/rs6000/linux64.h (PREFIXED_ADDR_SUPPORTED_BY_OS): Set to > 1 to enable prefixed addressing if -mcpu=future. > (PCREL_SUPPORTED_BY_OS): Set to 1 to enable PC-relative addressing > if -mcpu=futur

patch, fortan] PR83113 Bogus "duplicate allocatable attribute" error for submodule character function

I've attached on updated patch for PR83113. The now removes the ICE when a duplicate DIMENSION attribute is specified in a submodule function. The patch reg tests cleanly. OK to commit? Note that this patch doesn't check that the attributes of duplicate declarations in a submodule function ar

[PATCH] c++: Fix ICE on invalid alignas in a template [PR93530]

This fixes an ICE taking place in cp_default_conversion because we got a SCOPE_REF that doesn't have a type and so checking INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P (TREE_TYPE (exp)) will crash. This happens since the recent Joseph's change in decl_attributes whereby we don't skip C++11 attributes o

[committed] nios2: Support for GOT-relative DW_EH_PE_datarel encoding.

On nios2-linux-gnu, there has been a long-standing bug in C++ exception handling that sometimes resulted in link errors like ../nios2-linux-gnu/bin/ld: FDE encoding in /tmp/cccfpQ2l.o(.eh_frame) prevents .eh_frame_hdr table being created when building some shared libraries or PIE executables. T

Re: [PATCH] gcc: Add new configure options to allow static libraries to be selected

* Iain Sandoe [2020-01-31 20:18:58 +]: > Hello Andrew, > > Andrew Burgess wrote: > > > Here's a cleaned up version of the previous patch I posted. If Iain > > reports this fixes the regressions he saw then I will push this. > > I applied this to r10-6364 and tested on a bunch of Darwin p

[COMMITTED] c++: Fix sizeof VLA lambda capture.

sizeof a VLA type is not a constant in C or the GNU C++ extension, so we need to capture the VLA even in unevaluated context. For PR60855 we stopped looking through a previous capture, but we also need to capture the first time the variable is mentioned. Tested x86_64-pc-linux-gnu, applying to tr

[RFC PATCH] __builtin_escape/__builtin_bless

Hi Richard and Joseph, for discussion: here is my simple patch for __builtin_escape/__builtin_bless. Maybe it does something stupid.  Best, Martin diff --git a/gcc/builtins.c b/gcc/builtins.c index e4a8694054e..d0046135213 100644 --- a/gcc/builtins.c +++ b/gcc/builtins.c @@ -6014,6 +6014,31

Re: [PATCH] V12 patch #4 of 14, Optimize adjusting PC-relative vector addresses

Hi! On Thu, Jan 09, 2020 at 07:34:31PM -0500, Michael Meissner wrote: > +static rtx > +adjust_vec_address_pcrel (rtx addr, rtx element_offset, rtx base_tmp) > +{ > + rtx new_addr = NULL; You don't need this variable, you can just return the value directly in every case, and then you don't need a

[PATCH] fortran: Fix up TYPE_ARG_TYPES of procs with scalar VALUE optional args [PR92305]

Hi! The following patch fixes -FAIL: libgomp.fortran/use_device_addr-1.f90 -O0 execution test -FAIL: libgomp.fortran/use_device_addr-2.f90 -O0 execution test that has been FAILing for several months on powerpc64le-linux. The problem is in the Fortran FE, which adds the artificial arguments f

Re: [PATCH] V12 patch #3 of 14, Improve address validation in rs6000_adjust_vec_address

Hi! On Thu, Jan 09, 2020 at 07:27:58PM -0500, Michael Meissner wrote: > * config/rs6000/rs6000.c (reg_to_non_prefixed): Add forward > reference. FWIW, it is better to just reorder the code, in most cases. > (hard_reg_and_mode_to_addr_mask): Delete, no longer used. Just "Delete

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

On 1/31/20 11:54 PM, Segher Boessenkool wrote: > Hi! > > Thanks for working on this. > > On Fri, Jan 31, 2020 at 04:59:02PM +, Bernd Edlinger wrote: >> I will try to improve the patch a bit, and hope you are gonna like >> it. I agree that this feature is fine, and should be enabled by >> d

[COMMITTED 2/2] c++: Reduce memory consumption for arrays of non-aggregate type.

The remaining low-hanging fruit for improvement on memory consumption in the 14179 testcase was the duplication of the CONSTRUCTOR for the array by reshape_init. This patch changes reshape_init to reuse a single constructor for an array of non-aggregate type such as the one in the testcase. Teste

[COMMITTED 1/2] c++: Reduce memory consumption for large static arrays.

PR14179 and the C counterpart PR12245 are about memory consumption of very large file-scope arrays. Recently, location wrappers increased memory consumption significantly: in an array of integer constants, each one will have a location wrapper, which added up to over 500MB in the 14179 testcase.

Re: [PATCH] diagnostics: Add options to control the column units [PR49973] [PR86904]

Thanks for taking a look, sorry about that, it's my first new option :). I will add in the next iteration. -Lewis On Fri, Jan 31, 2020 at 5:45 PM Joseph Myers wrote: > > This seems to be missing invoke.texi documentation for the new options. > > -- > Joseph S. Myers > jos...@codesourcery.com

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

Hi! Thanks for working on this. On Fri, Jan 31, 2020 at 04:59:02PM +, Bernd Edlinger wrote: > I will try to improve the patch a bit, and hope you are gonna like > it. I agree that this feature is fine, and should be enabled by > default, and just if it is positively clear that it won't work,

Re: [PATCH] diagnostics: Add options to control the column units [PR49973] [PR86904]

This seems to be missing invoke.texi documentation for the new options. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] libgfortran: Fix and simplify IO locking [PR92836]

On Fri, Jan 31, 2020 at 3:38 PM Janne Blomqvist wrote: > > Simplify IO locking in libgfortran. The new IO implementation avoids > accessing units without locks, as seen in PR 92836. It also avoids > lock inversion (except for a corner case wrt namelist query when > reading from stdin and outputt

[committed] analyzer: fix ICE with 'const void *' (PR 93457)

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to master as r10-6386-g6775172431a8e6f0d20ac0c4946d6b5db2f46450. gcc/analyzer/ChangeLog: PR analyzer/93457 * region-model.cc (make_region_for_type): Use VOID_TYPE_P rather than checking against void_type_

[committed] analyzer: fix ICE handling void-type (PR 93373)

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to master as r10-6385-g09bea5845a50189b093e7fa8d5b840da702197d4. gcc/analyzer/ChangeLog: PR analyzer/93373 * region-model.cc (ASSERT_COMPAT_TYPES): Convert to... (assert_compat_types): ...this, and bail w

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

On Fri, 2020-01-31 at 16:59 +, Bernd Edlinger wrote: > Hi, > > this is patch is heavily based on David's original patch here: > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01409.html > > and addresses Jakub's review comments here: > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01412.html >

Re: [PING^4][PATCH 0/4] Fix library testsuite compilation for build sysroot

On Tue, 21 Jan 2020, Maciej W. Rozycki wrote: > I'll give your proposal a shot and I'm lucky enough to have a build > configuration where I can have no compiler preinstalled, so at least I can > check if testing with your change applied correctly picks the newly built > uninstalled compiler in

Re: [rfc PATCH] rs6000: Updated constraint documentation

On Fri, Jan 31, 2020 at 10:56:10AM -0600, Bill Schmidt wrote: > On 1/31/20 9:42 AM, Segher Boessenkool wrote: > >On Fri, Jan 31, 2020 at 08:49:21AM -0600, Bill Schmidt wrote: > >>>+(define_register_constraint "wa" > >>>"rs6000_constraints[RS6000_CONSTRAINT_wa]" > >>>+ "A VSX register (VSR), @code{

Re: [PATCH] diagnostics: Add options to control the column units [PR49973] [PR86904]

On Fri, Jan 31, 2020 at 3:32 PM David Malcolm wrote: > > On Fri, 2020-01-31 at 14:31 -0500, Lewis Hyatt wrote: > > Hello- > > > > Here is the second patch that I mentioned when I submitted the other > > related > > patch (which is awaiting review): > > https://gcc.gnu.org/ml/gcc-patches/2020-01/ms

Re: [PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

Hi Andrew, I just saw your patch here: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01474.html Re: [PATCH] gcc: Add new configure options to allow static libraries to be selected Note: the artefacts in my patch below seem to be a missing re-generated gcc/configure from your patch? Is that rig

Re: [PATCH] diagnostics: Add options to control the column units [PR49973] [PR86904]

On Fri, 2020-01-31 at 14:31 -0500, Lewis Hyatt wrote: > Hello- > > Here is the second patch that I mentioned when I submitted the other > related > patch (which is awaiting review): > https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01626.html. Sorry about that; I'm v. busy with analyzer bugs right

Re: [PATCH] gcc: Add new configure options to allow static libraries to be selected

Hello Andrew, Andrew Burgess wrote: Here's a cleaned up version of the previous patch I posted. If Iain reports this fixes the regressions he saw then I will push this. I applied this to r10-6364 and tested on a bunch of Darwin platforms. AFAICT, the configuration now reports consistent va

patch to fix PR91333

The following patch fixes   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91333 The patch was successfully bootstrapped and tested on x86-64. The patch changes order of putting colorable allocnos on the stack and consequently changes order of assigning hard registers to the allocnos (they all

[committed] analyzer: fix ICE getting void return value (PR 93379)

PR analyzer/93379 reports an ICE within region_model::update_for_return_superedge when writing the returned svalue_id to the lhs of the call_stmt The root cause is that this analyzer code assumed that for any call with a non-NULL gimple_call_lhs, the called fndecl would have non-void return type,

[committed] analyzer: fix ICE with pointers between stack frames (PR 93438)

PR analyzer/93438 reports an ICE when merging two region_models in which an older stack frame has a local pointing to a local in a more recent stack frame. stack older frame int *: "ow" --+ | newer frame | int: "pk" <---+ The root cause is that the st

[PATCH] diagnostics: Add options to control the column units [PR49973] [PR86904]

Hello- Here is the second patch that I mentioned when I submitted the other related patch (which is awaiting review): https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01626.html. This second patch is based on top of the first one and it closes out PR49973 and PR86904 by adding the new option -fdiagno

Re: [PATCH] adjust object size computation for union accesses and PHIs (PR 92765)

Attached is a reworked patch since the first one didn't go far enough to solve the major problems. The new solution relies on get_range_strlen_dynamic the same way as the sprintf optimization, and does away with the determine_min_objsize function and calling compute_builtin_object_size. To minim

Re: [Patch] Inline optimization for tanh(x)/sinh(x) -> 1.0/cosh(x)

I took the required steps. The patch is attached to this email, I hope I got it right this time. I did not forward the patch to gcc-patches the first time, sorry for the inconvenience. Thank you for your attention, Vitor. in gcc/ChangeLog: 2020-01-28 Vitor Guidi * match.pd: New subs

Re: [PATCH][GCC][middle-end] Fix logical shift truncation (PR91838)

On Fri, Jan 31, 2020 at 10:12:08AM +, Tamar Christina wrote: > 2020-01-31 Tamar Christina > > PR 91838 > * simplify-rtx.c (simplify_binary_operation_1): Update LSHIFTRT case > to truncate if allowed or reject combination. > > gcc/testsuite/ChangeLog: > > 2020-01-31 Tama

[PATCH] c++: Partially implement P1042R1: __VA_OPT__ wording clarifications [PR92319]

Hi! I've noticed we claim in cxx-status.html that we implement P1042R1, but it seems we don't implement any of the changes from there. The following patch implements just the change that __VA_OPT__ determines whether to expand to nothing or the enclosed tokens no longer based on whether there were

[COMMITTED] aarch64: Add Armv8.6 SVE bfloat16 support

This patch adds support for the SVE intrinsics that map to Armv8.6 bfloat16 instructions. This means that svcvtnt is now a base SVE function for one type suffix combination; the others are still SVE2-specific. This relies on a binutils fix: https://sourceware.org/ml/binutils/2020-01/msg00450

[COMMITTED] aarch64: Fix SVE PCS failures for BE & ILP32

This patch should (finally!) give clean test results for aarch64-sve-pcs.exp for all {be,le}{lp64,ilp32} combinations. The *_128.c tests require aarch64_little_endian because they test for fixed-length 128-bit code, whereas -msve-vector-bits=128 still generates VLA code for big-endian. Some tests

Re: [PATCH] V12 patch #2 of 14, Refactor rs6000_adjust_vec_address & rs6000_split_vec_extract_var

Hi! On Thu, Jan 09, 2020 at 07:04:10PM -0500, Michael Meissner wrote: > 2020-01-09 Michael Meissner > > * config/rs6000/rs6000.c (get_vector_offset): New helper function > to calculate the offset in memory from the start of a vector of a > particular element. Add code to kee

Re: [PATCH] simplify-rtx: Extend (truncate (*extract ...)) fold [PR87763]

On Thu, 2020-01-30 at 17:54 +, Richard Sandiford wrote: > Jeff Law writes: > > On Wed, 2020-01-29 at 19:18 +, Richard Sandiford wrote: > > > Andreas Schwab writes: > > > > On Jan 27 2020, Richard Sandiford wrote: > > > > > > > > > * simplify-rtx.c (simplify_truncation): Extend sign

[PATCH] Fix -ffast-math flags handling inconsistencies

Hello, we've noticed some inconsistencies in how the component flags of -ffast-math are handled, see the discussion on the GCC list starting here: https://gcc.gnu.org/ml/gcc/2020-01/msg00365.html This patch fixes those inconsistencies. Specifically, there are the following changes: 1. Some comp

[PATCH] Add --with-diagnostics-urls configuration option and GCC_URLS/TERM_URLS env var

Hi, this is patch is heavily based on David's original patch here: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01409.html and addresses Jakub's review comments here: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01412.html So I hope you don't mind, when I pick up this patch since there was not

Re: [rfc PATCH] rs6000: Updated constraint documentation

On 1/31/20 9:42 AM, Segher Boessenkool wrote: Hi Bill, Thanks a lot for looking at this! :-) On Fri, Jan 31, 2020 at 08:49:21AM -0600, Bill Schmidt wrote: +(define_register_constraint "wa" "rs6000_constraints[RS6000_CONSTRAINT_wa]" + "A VSX register (VSR), @code{vs0}@dots{}@code{vs63}. Eith

Re: [GCC][PATCH][AArch64] ACLE intrinsics for BFCVTN, BFCVTN2 (AArch64 AdvSIMD) and BFCVT (AArch64 FP)

Delia Burduv writes: > [...] > diff --git a/gcc/config/aarch64/arm_bf16.h b/gcc/config/aarch64/arm_bf16.h > index > 3759c0d1cb449a7f0125cc2a1433127564d66622..fb2150e1d60a590046e2c034422021aafc721e23 > 100644 > --- a/gcc/config/aarch64/arm_bf16.h > +++ b/gcc/config/aarch64/arm_bf16.h > @@ -28,5 +

Re: [GCC][PATCH][AArch64] ACLE intrinsics bfmmla and bfmlal for AArch64 AdvSIMD

Sure, here it is. I'll do that for the other patch too. Thanks, Delia On 1/31/20 3:37 PM, Richard Sandiford wrote: > Delia Burduv writes: >> Thank you, Richard! >> >> Here is the updated patch. The test that checks for errors when bf16 is >> disabled is in the bfcvt patch. > > Looks good. Just

[committed, amdgcn] Fix conditional add LRA failure

This patch fixes an ICE in testcase gfortran.dg/assumed_rank_bounds_3.f90. The ICE is "unable to generate reloads" and is caused by LRA wanting to use the same match constraint for two distinct operands. It would be nice if LRA could choose not to do that (given that the alternative allows mu

Re: [rfc PATCH] rs6000: Updated constraint documentation

Hi Bill, Thanks a lot for looking at this! :-) On Fri, Jan 31, 2020 at 08:49:21AM -0600, Bill Schmidt wrote: > >+(define_register_constraint "wa" > >"rs6000_constraints[RS6000_CONSTRAINT_wa]" > >+ "A VSX register (VSR), @code{vs0}@dots{}@code{vs63}. Either a @code{d} > >+ or a @code{v} regi

Re: [GCC][PATCH][AArch64] ACLE intrinsics bfmmla and bfmlal for AArch64 AdvSIMD

Delia Burduv writes: > Thank you, Richard! > > Here is the updated patch. The test that checks for errors when bf16 is > disabled is in the bfcvt patch. Looks good. Just a couple of very minor things... > > Cheers, > Delia > > gcc/ChangeLog: > > 2019-11-06 Delia Burduv > > * config

Re: [GCC][PATCH][AArch32] ACLE intrinsics bfloat16 vmmla and vfma for AArch32 AdvSIMD

Here is the updated patch. The changes are minor, so let me know if there is anything else to fix or if it can be committed. Thank you, Delia On 1/30/20 2:55 PM, Kyrill Tkachov wrote: > Hi Delia, > > > On 1/28/20 4:44 PM, Delia Burduv wrote: >> Ping. >>

[Patch,committed][Fortran] Disable front-end optimization for OpenACC atomic (PR93462)

The OpenACC code !$acc atomic write a = f(n) - f(n) got -ffrontend-optimize'd such that it ICEed in gfc_trans_omp_atomic. The same issue occurred for OpenMP in PR 92977 and was solved by disabling the optimization for EXEC_OMP_ATOMIC. This patch does now the same for OpenACC (EXEC_OACC_ATOMIC

Re: [GCC][PATCH][AArch64] ACLE intrinsics for BFCVTN, BFCVTN2 (AArch64 AdvSIMD) and BFCVT (AArch64 FP)

Sorry for the confusion, what I meant to say was: This patch adds the Armv8.6-a ACLE intrinsics for bfcvtn, bfcvtn2 and bfcvt as part of the BFloat16 extension. (https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/intrinsics) The intrinsics are declared in arm_bf16.h and arm_n

Re: [rfc PATCH] rs6000: Updated constraint documentation

On 1/30/20 6:17 PM, Segher Boessenkool wrote: This is my current work-in-progress version. There still are rough edges, and not much is done for the output modifiers yet, but it should be in much better shape wrt the user manual now. The internals manual also is a bit better I think. md.texi

Re: [PATCH] V12 patch #1 of 14, add gcc_asserts for rs6000_adjust_vec_address

Hi! On Thu, Jan 09, 2020 at 06:52:05PM -0500, Michael Meissner wrote: > 2020-01-09 Michael Meissner > > * config/rs6000/rs6000.c (rs6000_adjust_vec_address): Add some > gcc_asserts. > + /* All insns should use the 'Q' constraint (address is a single > register) > + if t

Re: [PATCH, ivopts] Fix fast-math-pr55281.c ICE

On 31/01/2020 08:09, Richard Biener wrote: On Thu, Jan 30, 2020 at 3:09 PM Andrew Stubbs wrote: How about this? I've only tested it on the one testcase, so far, but it works for that. OK to commit (following a full test)? OK. X86_64 bootstrap and test showed no issues. Nor amdgcn build an

Re: [GCC][PATCH][AArch64] ACLE intrinsics bfmmla and bfmlal for AArch64 AdvSIMD

Thank you, Richard! Here is the updated patch. The test that checks for errors when bf16 is disabled is in the bfcvt patch. Cheers, Delia gcc/ChangeLog: 2019-11-06 Delia Burduv * config/aarch64/aarch64-simd-builtins.def (bfcvtn): New built-in function. (bfcvtn_q

Re: [PATCH] Add OpenACC acc_get_property support for AMD GCN

Hi Frederik! On 2020-01-31T13:17:52+0100, "Harwath, Frederik" wrote: > On 30.01.20 17:08, Thomas Schwinge wrote: > >> I understand correctly that the only reason for: >> >> On 2020-01-29T10:52:57+0100, "Harwath, Frederik" >> wrote: >>> * testsuite/libgomp.oacc-c-c++-common/acc_get_propert

*ping* Re: [Patch][Fortran] Fix to strict associate check (PR93427)

*ping* after 4 days. On 1/27/20 2:49 PM, Tobias Burnus wrote: Semantically, there is an issue when the function name is used both for recursively calling and as result variable. Hence, one should only use one own's function name – in context of function calls – if one has a separate result var

Re: [PATCH] [amdgcn] Scale number of threads/workers with VGPR usage

On 31/01/2020 13:56, Kwok Cheung Yeung wrote: The GCN architecture has 4 SIMD units per compute unit, with 256 VGPRs per SIMD unit. OpenMP threads or OpenACC workers must be distributed across the SIMD units, with each thread/worker fitting entirely within a single SIMD unit. VGPRs are shared b

[PATCH, i386]: Fix TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL handling.

The reason for TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL on AMD target is only insn size, as advised in e.g. Software Optimization Guide for the AMD Family 15h Processors [1], section 7.1.2, where it is said: --quote-- 7.1.2 Reduce Instruction SizeOptimization Reduce the size of instructions when pos

[PATCH] [amdgcn] Scale number of threads/workers with VGPR usage

The GCN architecture has 4 SIMD units per compute unit, with 256 VGPRs per SIMD unit. OpenMP threads or OpenACC workers must be distributed across the SIMD units, with each thread/worker fitting entirely within a single SIMD unit. VGPRs are shared by the kernels running in a SIMD unit, so we can

Re: [GCC][BUG][Aarch64][ARM] (PR93300) Fix ICE due to BFmode placement in GET_MODES_WIDER chain.

Stam Markianos-Wright writes: > On 1/30/20 10:01 AM, Richard Sandiford wrote: >> Stam Markianos-Wright writes: >>> On 1/29/20 12:42 PM, Richard Sandiford wrote: Stam Markianos-Wright writes: > Hi all, > > This fixes: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93300

Re: [PATCH][GCC][middle-end] Fix logical shift truncation (PR91838)

Hi Segher, The 01/31/2020 12:13, Segher Boessenkool wrote: > Hi! > > On Fri, Jan 31, 2020 at 10:12:08AM +, Tamar Christina wrote: > > This fixes a fall-out from a patch I had submitted two years ago which > > started > > allowing simplify-rtx to fold logical right shifts by offsets a followe

[PATCH] libgfortran: Fix and simplify IO locking [PR92836]

Simplify IO locking in libgfortran. The new IO implementation avoids accessing units without locks, as seen in PR 92836. It also avoids lock inversion (except for a corner case wrt namelist query when reading from stdin and outputting to stdout), making it easier to verify correctness with tools

Re: [PATCH, v3] coroutines: Fix ICE on invalid (PR93458).

On 1/30/20 9:43 AM, Iain Sandoe wrote: Hi Nathan, however. …. also, what if you find something, but it's not a type template? … I’ve switched the complain off on lookup_qualified_name and now check for a type template. I'm not sure that's helpful. I think you should still complain on the

[PATCH] tree-optimization/91123 - restore redundant store removal

Redundant store removal in FRE was restricted for correctness reasons. The following extends correctness fixes required to memcpy/aggregate copy translation. The main change is that we no longer insert references rewritten to cover such aggregate copies into the hashtable but the original one.

[PATCH] tree-optimization/92819 restrict new vector CTOR canonicalization

The PR shows that code generation ends up pessimized by the new canonicalization rules that end up nailing do-not-care elements to specific values making it hard to generate good code later. The temporary solution is to avoid this for the cases we also obviously know the canonicalization will crea

Re: [PATCH] doc: clarify the situation with pointer arithmetic

On Fri, Jan 31, 2020 at 1:05 PM Uecker, Martin wrote: > > Am Freitag, den 31.01.2020, 09:02 +0100 schrieb Richard Biener: > > On Thu, Jan 30, 2020 at 6:09 PM Uecker, Martin > > wrote: > > > > > > Am Donnerstag, den 30.01.2020, 16:50 + schrieb Michael Matz: > > > > Hi, > > > > > > > > On Thu,

Re: [PATCH] Add OpenACC acc_get_property support for AMD GCN

Hi Thomas, On 30.01.20 17:08, Thomas Schwinge wrote: > I understand correctly that the only reason for: > > On 2020-01-29T10:52:57+0100, "Harwath, Frederik" > wrote: >> * testsuite/libgomp.oacc-c-c++-common/acc_get_property-aux.c >> (expect_device_properties): Split function into ...

Re: [PATCH][GCC][middle-end] Fix logical shift truncation (PR91838)

Hi! On Fri, Jan 31, 2020 at 10:12:08AM +, Tamar Christina wrote: > This fixes a fall-out from a patch I had submitted two years ago which started > allowing simplify-rtx to fold logical right shifts by offsets a followed by b > into >> (a + b). > > However this can generate inefficient code w

Re: [PATCH] doc: clarify the situation with pointer arithmetic

Am Freitag, den 31.01.2020, 09:02 +0100 schrieb Richard Biener: > On Thu, Jan 30, 2020 at 6:09 PM Uecker, Martin > wrote: > > > > Am Donnerstag, den 30.01.2020, 16:50 + schrieb Michael Matz: > > > Hi, > > > > > > On Thu, 30 Jan 2020, Uecker, Martin wrote: > > > > > > > > guarantees face ser

Re: PATCH bugzila request Bug 92146 gm2: the brig, fortran, go and D frontends are missing lang_register_spec_functions

Gaius Mulley writes: > Hi Martin and Matthias, > > as requested here are the lang_register_spec_functions for brig, > fortran, go and D: ah correction here is the fortran lang_register_spec_functions patch: 12-patches Description: fortran lang_register_spec_function regards, Gaius

PATCH bugzila request Bug 92146 gm2: the brig, fortran, go and D frontends are missing lang_register_spec_functions

Hi Martin and Matthias, as requested here are the lang_register_spec_functions for brig, fortran, go and D: 15-patches Description: lang register for go 14-patches Description: lang register for brig 13-patches Description: lang register for D 13-patches Description: lang register for fo

[committed, amdgcn] Zero-initialise masked load destinations

This is one of those things I don't know why we didn't notice sooner. The patch ensures that unused lanes in masked vector loads are zero-initialized, as per the internals manual. This fixes an execution failure in testcase gfortran.dg/assumed_rank_1.f90. When investigating the bug I got confu

Re: [Patch] Inline optimization for tanh(x)/sinh(x) -> 1.0/cosh(x)

On Fri, Jan 31, 2020 at 12:06 PM Marc Glisse wrote: > > On Thu, 30 Jan 2020, Vitor Guidi wrote: > > >> + /* Simplify tanh (x) / sinh (x) -> 1.0 / cosh (x). */ > >> + (simplify > >> + (rdiv (TANH @0) (SINH @0)) > >> + (rdiv {build_one_cst (type);} (COSH @0))) > > The existing > > (simplify >

Re: [Patch] Inline optimization for tanh(x)/sinh(x) -> 1.0/cosh(x)

On Thu, 30 Jan 2020, Vitor Guidi wrote: + /* Simplify tanh (x) / sinh (x) -> 1.0 / cosh (x). */ + (simplify + (rdiv (TANH @0) (SINH @0)) + (rdiv {build_one_cst (type);} (COSH @0))) The existing (simplify (rdiv (SINH:s @0) (COSH:s @0)) (TANH @0)) has :s (which AFAIK are ignored beca

Re: [PATCH] libstdc++: Always return a sentinel from __gnu_test::test_range::end()

On 29/01/20 11:24 -0500, Patrick Palka wrote: On Wed, 29 Jan 2020, Patrick Palka wrote: On Wed, 29 Jan 2020, Jonathan Wakely wrote: On 21/01/20 17:26 -0500, Patrick Palka wrote: It seems that in practice std::sentinel_for is always true, and so the Doh, good catch. test_range container do

[PATCH][GCC][middle-end] Fix logical shift truncation (PR91838)

Hi All, This fixes a fall-out from a patch I had submitted two years ago which started allowing simplify-rtx to fold logical right shifts by offsets a followed by b into >> (a + b). However this can generate inefficient code when the resulting shift count ends up being the same as the size of the

Re: [PATCH 2/2] analyzer: avoid use of fold_build2

On Thu, Jan 30, 2020 at 5:19 PM David Malcolm wrote: > > Various places in the analyzer use fold_build2, test the result, then > discard it. It's more efficient to use fold_binary, which avoids > building and GC-ing a redundant tree for the cases where folding fails. If these are all true intege

Re: [PATCH 2/2] analyzer: avoid use of fold_build2

On Thu, Jan 30, 2020 at 08:19:18PM -0500, David Malcolm wrote: > gcc/analyzer/ChangeLog: > * constraint-manager.cc (range::constrained_to_single_element): > Replace fold_build2 with fold_binary. Remove unnecessary newline. > (constraint_manager::get_or_add_equiv_class): Replace f

Re: [PATCH] calls.c: refactor special_function_p for use by analyzer (v2)

On Thu, Jan 30, 2020 at 08:32:25PM -0500, David Malcolm wrote: > gcc/analyzer/ChangeLog: > * analyzer.cc (is_named_call_p): Replace tests for fndecl being > extern at file scope and having a non-NULL DECL_NAME with a call > to maybe_special_function_p. > * function-set.cc (f

Re: [PATCH 1/2] analyzer: further fixes for comparisons between uncomparable types (PR 93450)

On Thu, Jan 30, 2020 at 08:19:17PM -0500, David Malcolm wrote: > gcc/analyzer/ChangeLog: > PR analyzer/93450 > * constraint-manager.cc > (constraint_manager::get_or_add_equiv_class): Only compare constants > if their types are compatible. > * region-model.cc (constant_

Re: [PATCH] Add OpenACC acc_get_property support for AMD GCN

Hi! On 2020-01-30T16:45:39+, Andrew Stubbs wrote: > On 30/01/2020 16:08, Thomas Schwinge wrote: >> Andrew and Frederik, thanks for your emails reminding/educating me about >> 'snprintf' as well as this HSA fixed-size buffer API. There doesn't >> happen to be something available in the HSA AP

Re: [PATCH, ivopts] Fix fast-math-pr55281.c ICE

On Thu, Jan 30, 2020 at 3:09 PM Andrew Stubbs wrote: > > On 30/01/2020 13:49, Richard Biener wrote: > > On Thu, Jan 30, 2020 at 2:04 PM Bin.Cheng wrote: > >> > >> On Thu, Jan 30, 2020 at 8:53 PM Andrew Stubbs > >> wrote: > >>> > >>> On 29/01/2020 08:24, Richard Biener wrote: > On Tue, Jan

Re: [Patch] Inline optimization for tanh(x)/sinh(x) -> 1.0/cosh(x)

On Fri, Jan 31, 2020 at 12:53 AM Vitor Guidi wrote: > > Hi. > > This patch adds a new optimization to avoid the redundant calculation > tanh(x)/sinh(x) by replacing it for 1.0/cosh(x), for all cases where x is a > double, a long double or a float. > > There should be no need for numerical stabilit

Re: [PATCH] doc: clarify the situation with pointer arithmetic

On Thu, Jan 30, 2020 at 6:09 PM Uecker, Martin wrote: > > Am Donnerstag, den 30.01.2020, 16:50 + schrieb Michael Matz: > > Hi, > > > > On Thu, 30 Jan 2020, Uecker, Martin wrote: > > > > > > guarantees face serious implementation difficulties I think > > > > so the only alternative to PVNI (whi