Re: [PATCH] Fix attribute access issues

On November 23, 2019 2:03:21 AM GMT+01:00, Jakub Jelinek wrote: >Hi! > >On Thu, Nov 21, 2019 at 06:09:34PM -0700, Martin Sebor wrote: >> > > PR middle-end/83859 >> > > * c-attribs.c (handle_access_attribute): New function. >> > > (c_common_attribute_table): Add new attribute. >> > >

Re: [PATCH] Perform cfg cleanup in cse if needed (PR rtl-optimization/92610)

On November 23, 2019 2:15:36 AM GMT+01:00, Jakub Jelinek wrote: >Hi! > >cse_main which sets tem has: > if (cse_jumps_altered || recorded_label_ref) >return 2; > else if (cse_cfg_altered) >return 1; > else >return 0; >at the end, but after these two functions call it, they call

Re: [PATCH], V7, #5 of 7, Add more effective targets for the 'future' system to target-supports.

On Thu, Nov 14, 2019 at 05:56:50PM -0500, Michael Meissner wrote: > * lib/target-supports.exp > (check_effective_target_powerpc_future_ok): Do not require 64-bit > or Linux support before doing the test. Use a 32-bit constant in > PLI. You changed from 0x12345 to 0x1234,

[PATCH] Perform cfg cleanup in cse if needed (PR rtl-optimization/92610)

Hi! cse_main which sets tem has: if (cse_jumps_altered || recorded_label_ref) return 2; else if (cse_cfg_altered) return 1; else return 0; at the end, but after these two functions call it, they call also delete_trivially_dead_insns. Even when cse_main didn't need cfg changes,

[PATCH] Fix ICE with inline asm "=@cc.." (PR target/92615)

Hi! The following testcase ICEs, because ix86_md_asm_adjust emits an invalid insn that isn't matched. setcc_qi output is nonimmediate_operand and so is fine, but the problem is if we decide to do a ZERO_EXTEND, because zero_extendqidi2 output must be register_operand, but dest could be MEM as in

[PATCH] Fix attribute access issues

Hi! On Thu, Nov 21, 2019 at 06:09:34PM -0700, Martin Sebor wrote: > > > PR middle-end/83859 > > > * c-attribs.c (handle_access_attribute): New function. > > > (c_common_attribute_table): Add new attribute. > > > (get_argument_type): New function. > > > (append_access_attrs): New

Re: [PATCH] V7, #4 of 7, Add explicit (0),1 to @pcrel references

On Thu, Nov 14, 2019 at 05:51:14PM -0500, Michael Meissner wrote: > In some of my previous work, I had make a mistake forgetting that the PADDI > instruction did not allow adding a PC-relative reference to a register (you > can > either load up a PC-relative address without adding a register, or

Re: [PATCH], V7, #3 of 7, Use PADDI for 34-bit immediate adds

On Thu, Nov 14, 2019 at 05:44:42PM -0500, Michael Meissner wrote: > This patch generates PADDI to add 34-bit immediate constants on the 'future' > system, and prevents such adds from being split. I don't see that last part? Is that a remnant of a previous version of the patch? > *

Re: [PATCH], V7, #2 of 7, Use PLI to load up 32-bit SImode constants

On Thu, Nov 14, 2019 at 05:42:43PM -0500, Michael Meissner wrote: > -;; Split a load of a large constant into the appropriate two-insn > -;; sequence. > +;; Split a load of a large constant into the appropriate two-insn sequence. > On > +;; systems that support PADDI (PLI), we can use PLI to

Re: [PATCH] V7, #1 of 7, Use PLI to load up 34-bit DImode constants

On Thu, Nov 14, 2019 at 05:40:10PM -0500, Michael Meissner wrote: > --- gcc/config/rs6000/rs6000.c(revision 278173) > +++ gcc/config/rs6000/rs6000.c(working copy) > @@ -5552,7 +5552,7 @@ static int > num_insns_constant_gpr (HOST_WIDE_INT value) > { >/* signed constant

Re: [PATCH v2] Add `--with-install-sysroot=' configuration option

On Fri, 22 Nov 2019, Maciej W. Rozycki wrote: > As I recall the MIPS sysroot setup (please correct me if I got something > wrong here) was like: Yes, that's the sort of layout you get with sysroot suffixes. See gcc/config/mips/{st.h,t-st} for an example. > Then the right-hand side of

Re: [PATCH v2] Add `--with-install-sysroot=' configuration option

On Wed, 20 Nov 2019, Joseph Myers wrote: > > Thanks for your concern, however again, AFAICT this change is tangential > > to any sysroot suffix, which necessarily has to be already included in the > > multilib OS directory as given by `-print-multi-os-directory', so that it > > gets embedded

[PATCH] Don't override various Makefile variables for gnulib et al

Normally the toplevel Makefile will pass various CC=foo and other flags down to subdir Makefiles. However, for Gnulib this is a problem because Gnulib's configure specifically sets CC to something that includes a -std=gnu11 flag on some systems, and this override would set it back to CC=gcc,

[analyzer] Add sm-malloc.dot

I've found myself wanting a visualization of the state machines, so this patch adds a sm-malloc.dot, based on sm-malloc.cc Ideally we would autogenerate the .dot file somehow, but there isn't a good way to do this at this time. A .png version of this .dot file can be seen at:

Re: [PATCH] OpenACC reference count overhaul

On Sat, 9 Nov 2019 01:28:51 + Julian Brown wrote: > On Thu, 31 Oct 2019 19:11:57 +0100 > Thomas Schwinge wrote: > > > So that's not related to reference counting, needs to be discussed > > separately. > > > > ..., and while I do agree that the current code is a bit "strange" > >

[analyzer] Add -fno-semantic-interposition to PLUGIN_CFLAGS

An annoying wart with debugging the plugin is that attempts to set a breakpoint on a function set two breakpoints: on the "funcname@plt", and on the function itself, making stepping through the code more awkward than it ought to be. This patch detects for -fno-semantic-interposition at configure

Re: C++ PATCH for c++/88337 - P1327R1: Allow polymorphic typeid in constexpr

On Fri, Nov 22, 2019 at 04:14:06PM -0500, Jason Merrill wrote: > On 11/11/19 7:54 PM, Marek Polacek wrote: > > Part of P1327R1 is to allow typeid with an operand of polymorphic type in > > constexpr. I found that we pretty much support it already, the only tweak > > was to allow TYPEID_EXPR (only

[wwwdocs] Update C++ status with Belfast motions

Committed to git. Should s/http/https/ the wg21 links. Jason, do we support P1907R1? commit d59a823fb4ad2daa535d26f592274ec68b9cb4a1 Author: Marek Polacek Date: Fri Nov 22 16:49:27 2019 -0500 Update with Belfast motions. diff --git a/htdocs/projects/cxx-status.html

Re: [C/C++ PATCH] Fix up build of GCC 4.6 and earlier with GCC 9+ (PR c/90677, take 2)

On Fri, 22 Nov 2019, Jason Merrill wrote: > On 11/22/19 2:10 PM, Jakub Jelinek wrote: > > On Wed, Nov 20, 2019 at 02:01:58PM -0500, Jason Merrill wrote: > > > I would think that get_named_type should find struct or enum names that > > > have > > > been hidden by another declaration; that would

Re: [committed] [testsuite] Fix fp-int-convert-timode-1.c testism.

On Fri, 22 Nov 2019, Tamar Christina wrote: > Hi Joseph, > > > > Or do you want me to send them separately? > > > > I think it's best to fix the test now not to have the #ifdef, then if you > > have execution failures those can be addressed separately. (If you want > > to avoid the test

Re: C++ PATCH for c++/88337 - P1327R1: Allow polymorphic typeid in constexpr

On 11/11/19 7:54 PM, Marek Polacek wrote: Part of P1327R1 is to allow typeid with an operand of polymorphic type in constexpr. I found that we pretty much support it already, the only tweak was to allow TYPEID_EXPR (only created in a template) in constexpr in C++20. I also noticed this in

Re: C++ PATCH for c++/88337 - Implement P1327R1: Allow dynamic_cast in constexpr

On 11/8/19 4:24 PM, Marek Polacek wrote: After much weeping and gnashing of teeth, here's a patch to handle dynamic_cast in constexpr evaluation. While the change in the standard is trivial (see ), the change in the compiler

[Darwin, X86, testsuite] Update tests for common section use.

The tests amended here now have different code-gen with default options because, previously, the access were indirected per Darwin ABI for common accesses. The revised code-gen does not match the expected scan-asms because Darwin defaults to fPIC. For these tests, it seems that the best solution

Re: [PATCH] Fix PR92462

On 11/21/19 1:00 AM, Richard Biener wrote: > On Wed, 20 Nov 2019, Jeff Law wrote: > > Sure, but we're not being called with this but with RTL > expanded via cselib usually: > > (plus:SI (plus:SI (and:SI (symbol_ref:SI ("*.LANCHOR0") [flags 0x182]) > (const_int 3 [0x3])) >

Re: [PATCH] Fix attribute((section)) for templates

Here's a revised version of the patch. This revised version is ready for review. When GCC encounters __attribute__((section("foo"))) on a function or variable declaration, it adds an entry in the symbol table for the declaration to remember its desired section. The symbol table is separate from

Re: [C++ PATCH] Fix concepts vs. PCH (PR c++/92458, take 2)

On Fri, Nov 22, 2019 at 02:43:25PM -0500, Jason Merrill wrote: > > @@ -5358,6 +5410,18 @@ struct tree_cache_traits > > : simple_cache_map_traits, tree> { }; > > We should probably use tree_hash instead of default_hash_traits here. OK > with or without that change. Dunno, I'd say pointer_hash

Re: [C++20 PATCH] Implement P1920R1, Missing feature-test macros 2017-2019

On 11/16/19 7:38 PM, Jakub Jelinek wrote: Hi! This implements the core part of P1920R1, tested on x86_64-linux, ok for trunk if it passes full bootstrap/regtest? Jon, are you going to handle the libstdc++ side of this, assuming there is something still not done where we have the corresponding

Re: [C++ Patch] Improve build_new_op_1, cp_build_indirect_ref_1, and cp_build_modify_expr locations

On 11/22/19 10:43 AM, Paolo Carlini wrote: Hi, I would say most of the changes are straightforward or mechanical. Essentially, for build_new_op_1 and cp_build_modify_expr I'm simply consistently using the available location argument; for cp_build_indirect_ref_1 I'm adding the parameter but

Re: [C++ PATCH] Fix concepts vs. PCH (PR c++/92458, take 2)

On 11/22/19 2:08 PM, Jakub Jelinek wrote: On Wed, Nov 20, 2019 at 07:46:13PM -0500, Jason Merrill wrote: If decl_tree_cache_map will be needed in more than one spot, I'll probably need to move it to some generic header. Most of them probably need it, for code that uses the relevant features.

Re: [C/C++ PATCH] Fix up build of GCC 4.6 and earlier with GCC 9+ (PR c/90677, take 2)

On 11/22/19 2:10 PM, Jakub Jelinek wrote: On Wed, Nov 20, 2019 at 02:01:58PM -0500, Jason Merrill wrote: I would think that get_named_type should find struct or enum names that have been hidden by another declaration; that would fix this without special-casing cgraph_node. For the C++

Re: [PATCH][_GLIBCXX_DEBUG] Improve valid_range check

On 22/11/19 18:38 +0100, François Dumont wrote: Hi     I noticed that we are not checking that iterators are not singular in valid_range. Moreover __check_singular signature for pointers is not intercepting all kind of pointers in terms of qualification.     I'd like to commit it next week

Re: [PATCH] Fix type handling in undistribute_bitref_for_vector (PR tree-optimization/92618)

On November 22, 2019 3:25:05 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >The undistribute_bitref_for_vector function assumes that BIT_FIELD_REFs >with vector first argument must have always type of the vector element, >but that is not the case, BIT_FIELD_REF can extract any type with the

[PATCH][_GLIBCXX_DEBUG] Improve valid_range check

Hi     I noticed that we are not checking that iterators are not singular in valid_range. Moreover __check_singular signature for pointers is not intercepting all kind of pointers in terms of qualification.     I'd like to commit it next week but considering we are in stage 3 I need proper

Re: [PATCH v3] PR92398: Fix testcase failure of pr72804.c

Hi! On Fri, Nov 22, 2019 at 01:26:39PM +0800, luoxhu wrote: > Update the code as you wish, Thanks: The point is to make this interface easy and clear to use. So please tell me what *you* think about that, don't just do what I think may be a good solution! > *

Re: [PATCH ix86] Fix rtx_costs for flag-setting adds

On Fri, Nov 22, 2019 at 5:39 PM Bernd Schmidt wrote: > > On 11/22/19 3:04 PM, Uros Bizjak wrote: > > On Fri, Nov 22, 2019 at 1:58 PM Bernd Schmidt > > wrote: > >> > >> A patch I posted recently fixes combine to take costs of JUMP_INSNs into > >> account. That causes the pr30315 test to fail

[committed, amdgcn] Limit LDS usage

This patch changes the amount of LDS (Local Data Store) memory requested for offload kernels. This allows more teams/gangs to run on the same compute unit, increasing potential data throughput. For OpenMP we can reduce the allocation to almost nothing. This means we can have up-to 40

Re: [PATCH] fold strncmp of unterminated arrays (PR 92501)

On 11/15/19 1:15 PM, Jeff Law wrote: On 11/14/19 10:11 AM, Martin Sebor wrote: Adding tests for unsafe uses of unterminated constant char arrays in string functions exposed the limitation in strncmp folding described in PR 92501: GCC only folds strncmp calls involving nul-terminated constant 

Re: [PATCH] Make IPA-SRA follow comdat-local rules (PR 91956)

> Hi, > > this verifier error happens because first IPA-split splits a comdat > function creating a comdat local callee and then IPA-SRA comes along, > modifies the caller, makes it a local clone in the process but because > it does not set the comdat group to the original, the verifier sees a >

Re: [PATCH] ipa: Prevent materialization of clones with removed bodies (PR 92109)

> Hi, > > this bug is an interesting one. The immediate cause of the ICE is that > IPA-SRA modification phase baked into clone materialization was > expecting to see a body already changed by IPA-CP while it was actually > looking at the original function. > > That was because we were

Re: [PATCH 3/4] Set costs for jumps in combine

On Thu, Nov 21, 2019 at 08:12:05PM -0500, Paul Koning wrote: > > On Nov 21, 2019, at 7:42 PM, Segher Boessenkool > > wrote: > > > > ... > > Maybe i386 should implement the insn_cost hook as well? For most targets > > that is a lot simpler to get right than rtx_cost, but allowing memory in > >

Re: [PATCH ix86] Fix rtx_costs for flag-setting adds

On 11/22/19 3:04 PM, Uros Bizjak wrote: > On Fri, Nov 22, 2019 at 1:58 PM Bernd Schmidt wrote: >> >> A patch I posted recently fixes combine to take costs of JUMP_INSNs into >> account. That causes the pr30315 test to fail with -m32, since the cost >> of an add that sets the flags is estimated

Prevent all uses of DFP when unsupported (PR c/91985)

Code that directly uses _Decimal* types on architectures not supporting DFP is properly diagnosed ("error: decimal floating-point not supported for this target"), via a call to targetm.decimal_float_supported_p, if the _Decimal32, _Decimal64 or _Decimal128 keywords are used to access it. Use via

Re: Add a new combine pass

On Thu, Nov 21, 2019 at 08:32:14PM +, Richard Sandiford wrote: > Segher Boessenkool writes: > > It's not great if every pass invents its own version of some common > > infrastructure thing because that common one is not suitable. > > > > I.e., can this be fixed somehow? Maybe just by having

Re: [PATCH] [og9] Fix libgomp.oacc-fortran/lib-16.f90 test

On Fri, 22 Nov 2019 16:11:15 + Kwok Cheung Yeung wrote: > libgomp.oacc-fortran/lib-16.f90 in the libgomp testsuite currently > fails with: > > Program aborted. Backtrace: > #0 0x4013bf in MAIN__ > at > src/gcc-gcn-master/libgomp/testsuite/libgomp.oacc-fortran/lib-16.f90:28 > #1

[PATCH] ipa: Prevent materialization of clones with removed bodies (PR 92109)

Hi, this bug is an interesting one. The immediate cause of the ICE is that IPA-SRA modification phase baked into clone materialization was expecting to see a body already changed by IPA-CP while it was actually looking at the original function. That was because we were materializing the

Re: Add a new combine pass

On Thu, Nov 21, 2019 at 07:41:56PM +, Richard Sandiford wrote: > Nicholas Krause writes: > >> +/* The instructions we're combining, in program order. */ > >> +insn_info_rec *sequence[MAX_COMBINE_INSNS]; > > Can't we can this a vec in order to grow to lengths and just loop through > >

[PATCH] Make IPA-SRA follow comdat-local rules (PR 91956)

Hi, this verifier error happens because first IPA-split splits a comdat function creating a comdat local callee and then IPA-SRA comes along, modifies the caller, makes it a local clone in the process but because it does not set the comdat group to the original, the verifier sees a call from

[PATCH] [og9] Fix libgomp.oacc-fortran/lib-16.f90 test

libgomp.oacc-fortran/lib-16.f90 in the libgomp testsuite currently fails with: Program aborted. Backtrace: #0 0x4013bf in MAIN__ at src/gcc-gcn-master/libgomp/testsuite/libgomp.oacc-fortran/lib-16.f90:28 #1 0x4013bf in main at

Re: [PATCH, rs6000] Refactor FP vector comparison operators

Hi! On Thu, Nov 21, 2019 at 09:15:19PM +0800, Kewen.Lin wrote: > >> +;; code iterators and attributes for vector FP comparison operators: > >> +(define_code_iterator > >> + vector_fp_comparison_operator [lt le ne ungt unge unlt unle]) > > > > Can you change this name so it is clear it is just

[PATCH] PR c++/92439: Improve diagnostics for ill-formed requires-clauses

This does a much better job identifying when an expression in a requires-clause needs parentheses. Andrew Sutton 0001-PR-c-92439.patch Description: Binary data

Re: [patch,Fortran] PR 92050 - fix ICE with -fcheck=all

Just my $0.02. Backporting a patch from trunk that fixes a regression is always encouraged. It is up to the person doing the backport to determine the level of effort. If it exceeds some threshold the person can choose to not backport. For patches that fix a bug, which is not a regresssion,

Re: [committed, amdgcn] Use GFX9 granulated sgprs count correctly

Hi Andrew, On 11/22/19 3:47 PM, Andrew Stubbs wrote: --- a/gcc/config/gcn/gcn.c +++ b/gcc/config/gcn/gcn.c @@ -4922,6 +4922,14 @@ gcn_hsa_declare_function_name (FILE *file, const char *name, tree) + int granulated_sgprs; + if (TARGET_GCN3) +granulated_sgprs = (sgpr + extra_regs + 7) / 8

[committed, amdgcn] Use GFX9 granulated sgprs count correctly

I've committed the attached. The patch adjusts the GCN kernel metadata so that it is correct for GFX9 devices. The existing implementation was correct for GFX8, and seems to work on GFX9, but wasn't technically correct. -- Andrew Stubbs CodeSourcery / Mentor Graphics Use GFX9 granulated

[PATCH][Arm] Enable CLI for Armv8.6-a: armv8.6-a, i8mm and bf16

Hi all, This patch is part of a series adding support for Armv8.6-A features. It enables options including -march=armv8.6-a, +i8mm and +bf16. The +i8mm and +bf16 features are optional for Armv8.2-a and onward. Documents are at https://developer.arm.com/docs/ddi0596/latest Regtested for

Re: Ping: [PATCH V6] Extend IPA-CP to support arithmetically-computed value-passing on by-ref argument (PR ipa/91682)

> Hi Honza, > > > > > I checked update_jump_functions_after_inlining(), and found one > > suspicious place: > > > > > > for (i = 0; i < count; i++) > > > { > > > struct ipa_jump_func *dst = ipa_get_ith_jump_func (args, i); > > > if (!top) > > > { > > >

[PATCH] Fix type handling in undistribute_bitref_for_vector (PR tree-optimization/92618)

Hi! The undistribute_bitref_for_vector function assumes that BIT_FIELD_REFs with vector first argument must have always type of the vector element, but that is not the case, BIT_FIELD_REF can extract any type with the corresponding size from any other vector. So, without this patch, when it saw

[C++ PATCH] Fix ICE in build_ctor_subob_ref during replace_placeholders (PR c++/92524)

Hi! On the following testcase, replace_placeholders is called on a CONSTRUCTOR { a, [1..63] = NON_LVALUE_EXPR<42> } and call build_ctor_subob_ref in that case. The problem is that index is RANGE_EXPR and as it is not INTEGER_CST, we call build_class_member_access_expr which is not appropriate

[C/C++ PATCH] Fix up build of GCC 4.6 and earlier with GCC 9+ (PR c/90677, take 2)

On Wed, Nov 20, 2019 at 02:01:58PM -0500, Jason Merrill wrote: > I would think that get_named_type should find struct or enum names that have > been hidden by another declaration; that would fix this without > special-casing cgraph_node. For the C++ front-end, that would be > >

[C++ PATCH] Fix concepts vs. PCH (PR c++/92458, take 2)

On Wed, Nov 20, 2019 at 07:46:13PM -0500, Jason Merrill wrote: > > If decl_tree_cache_map will be needed in more than one spot, I'll probably > > need to move it to some generic header. > > Most of them probably need it, for code that uses the relevant features. > Except debug_type_map, which

Re: [PATCH ix86] Fix rtx_costs for flag-setting adds

On Fri, Nov 22, 2019 at 1:58 PM Bernd Schmidt wrote: > > A patch I posted recently fixes combine to take costs of JUMP_INSNs into > account. That causes the pr30315 test to fail with -m32, since the cost > of an add that sets the flags is estimated too high. > > The following seems to fix it.

[PATCH ix86] Fix rtx_costs for flag-setting adds

A patch I posted recently fixes combine to take costs of JUMP_INSNs into account. That causes the pr30315 test to fail with -m32, since the cost of an add that sets the flags is estimated too high. The following seems to fix it. Bootstrapped and tested on x86_64-linux, ok? Bernd *

RE: Ping: [PATCH V6] Extend IPA-CP to support arithmetically-computed value-passing on by-ref argument (PR ipa/91682)

Hi Honza, > > > I checked update_jump_functions_after_inlining(), and found one > suspicious place: > > > > for (i = 0; i < count; i++) > > { > > struct ipa_jump_func *dst = ipa_get_ith_jump_func (args, i); > > if (!top) > > { > > ipa_set_jf_unknown (dst); > >

Re: [patch,Fortran] PR 92050 - fix ICE with -fcheck=all

Hi all, I was asked to backport this fix to the GCC 9 branch – given that -fcheck=bounds is a common option and it fails with code like genecode.org. Given that ICEs with -fcheck are a regression and that the patch is not that invasive, I am inclined to accept it. Comments/(dis)approvals?

[committed] Disable epilogue loop vectorisation for vect-widen-mult-u8-*.c

vect-widen-mult-u8.c and vect-widen-mult-u8-u32.c were failing on arm-linux-gnueabihf with epilogue vectorisation because we print the expected messages twice rather than once. We could fix that either by removing the counts or by disabling epilogue loop vectorisation. The other

Re: [SVE] PR89007 - Implement generic vector average expansion

On Wed, 20 Nov 2019 at 16:54, Richard Biener wrote: > > On Wed, 20 Nov 2019, Richard Sandiford wrote: > > > Hi, > > > > Thanks for doing this. Adding Richard on cc:, since the SVE subject > > tag might have put him off. There's not really anything SVE-specific > > here apart from the testcase.

Re: [Patch, Fortran] dec comparisons - for approval

First, can you also create some news quip for your GCC 10 changes for https://gcc.gnu.org/gcc-10/changes.html ? See https://gcc.gnu.org/about.html#git for the repository to diff against. On 11/21/19 12:05 PM, Mark Eggleston wrote: Please find attached an updated version of the patch originally

Re: [PATCH] Support multi-versioning on self-recursive function (ipa/92133)

Hi, On Fri, Nov 15 2019, Feng Xue OS wrote: > Honza, > > I made some changes: do not penalize self-recursive function, and > add --param ipa-cp-min-recursive-probability, similar to recursive > inline. Please review this new one. The patch and its effect on exchange is intriguing, I only have a

[patch, openacc] Fix ICE verifying gimple

This test case causes an ICE (reformatted for email): void test(int k) { unsigned int x = 1; #pragma acc parallel loop async(x) for (int i = 0; i < k; i++) { } } t.c: In function 'test': t.c:4:9: error: invalid argument to gimple call 4 | #pragma acc parallel loop

Re: [PATCH] Multibyte awareness for diagnostics (PR 49973)

On Thu, 2019-11-21 at 21:43 -0500, David Malcolm wrote: > This is the column number as reported in the diagnostic i.e the > COL_NUM > when printing e.g. > warning: FILENAME:LINE_NUM:COL_NUM: some message > > It seems to me that PR 49973 and this patch cover two separate > things: On

[committed] Fix markup in gcc.dg/vect/vect-cond-reduc-3.c

gcc.dg/vect/vect-cond-reduc-3.c had been failing on arm-linux-gnueabihf since the test was added, because the test needs support for VEC_COND_EXPR whereas the target only supports VEC_COND_EXPRs in which all modes are the same. (I have a fix for that, but it's not really stage 3 material.)

[C++ Patch] Improve build_new_op_1, cp_build_indirect_ref_1, and cp_build_modify_expr locations

Hi, I would say most of the changes are straightforward or mechanical. Essentially, for build_new_op_1 and cp_build_modify_expr I'm simply consistently using the available location argument; for cp_build_indirect_ref_1 I'm adding the parameter but then using it in a completely

Re: [patch, fortran] Load scalar intent-in variables at the beginning of procedures

I have now filled https://gcc.gnu.org/PR92628 as ME bug to track this (i.e. honor TYPE_RESTRICT for pointer-escape analysis). Cheers, Tobias On 11/21/19 3:36 PM, Tobias Burnus wrote: On 11/21/19 3:09 PM, Richard Biener wrote: So I think what you'd need to do is make 'i' marked as

Re: [committed] [testsuite] Fix fp-int-convert-timode-1.c testism.

Hi Joseph, > > Or do you want me to send them separately? > > I think it's best to fix the test now not to have the #ifdef, then if you > have execution failures those can be addressed separately. (If you want > to avoid the test FAILing before then, an XFAIL with a comment referencing > an

Re: [PATCH] [PATCH] [ARC] Fix ARC target specific tests.

Thank you for your review. Pushed, Claudiu On Thu, Nov 21, 2019 at 9:13 PM Jeff Law wrote: > > On 11/21/19 9:35 AM, Claudiu Zissulescu wrote: > > PING > > > > On Mon, Nov 11, 2019 at 4:42 PM Claudiu Zissulescu > > wrote: > >> > >> Hi, > >> > >> Fix ARC specific tests by improving the matching