Re: [PATCH] Fix complex lowering (PR middle-end/68146, PR tree-optimization/69155)

On Thu, 14 Jan 2016, Jakub Jelinek wrote: > Hi! > > During complex lowering, we were walking bbs in bb index # order, which > means sometimes we could visit SSA_NAME uses before visiting definitions. > Also, even if we walk in rpo order as the following patch does, sometimes > we need to first

Re: [PATCH, ARM] PR68674 Fix LTO support for neon builtin and error catching (ping)

Hi Christian, On 14/01/16 12:37, Christian Bruel wrote: Here is the rebased patch after the #pragma GCC target warning fixes. I also disabled the builtins initialisations when float-abi is solft as you suggested This is ok with a couple of nits below addressed: +/* Set up all the NEON

RE: [PATCH][MIPS] Migrate reduction optabs in mips-ps-3d.md

> -Original Message- > From: Matthew Fortune [mailto:matthew.fort...@imgtec.com] > Sent: Thursday, January 14, 2016 5:49 AM > To: Alan Lawrence; Moore, Catherine > Cc: gcc-patches@gcc.gnu.org > Subject: RE: [PATCH][MIPS] Migrate reduction optabs in mips-ps-3d.md > > Alan Lawrence

[PATCH] Fix PR69117

I am currently testing the following patch to fix PR69117 where during value-numbering we end up using SSA name info (points-to info in this case but also range-info in general) from the value leader which may be defined under different conditions than the use is. The only fix I can think of

Re: [PATCH] Fix math transformation on targets without c99 math functions

On 14/01/16 15:02, Andre Vieira (lists) wrote: Unfortunately c99_functions is a very wide net. For instance, newlib supports the ceill, but doesn't support wscanf_s nor any bounds checking function I think. wscanf_s is not c99 (it is in the optional annex k of c11, which is likely to be

Re: [PATCH] Tidy: remove reduc_xxx_optab migration code

On 14/01/16 12:22, Richard Biener wrote: On Thu, Jan 14, 2016 at 11:26 AM, Alan Lawrence wrote: If/when mips-ps-3d.md is moved from reduc_* to reduc_*_scal optabs (patch here: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00311.html ), there will be no uses of the old

[PATCH 3/9] S/390: Get rid of Y constraint in rotate patterns.

This patch introduces substitution patterns to add PLUS const_int, and AND operands to patterns and uses this to rewrite the existing rotate pattern. gcc/ChangeLog: 2016-01-14 Andreas Krebbel * config/s390/predicates.md (addrreg_or_constint_operand)

[PATCH] Fix PR c++/68936

With my fix for PR c++/21802 I changed build_min_non_dep_call_vec() to additionally retain the KOENIG_LOOKUP_P flag of the non-dependent expression that's been built. This change was a little too general though, since retaining the KOENIG_LOOKUP_P flag is only necessary for

Re: C PATCH to enhance array bounds diagnostics (PR c/69262)

On 01/14/2016 03:29 AM, Marek Polacek wrote: This PR is a request for better array bounds diagnostics. The C++ FE says "multidimensional array must have bounds for all dimensions except the first", and we can do something similar in the C FE. Bootstrapped/regtested on x86_64-linux, ok for

Re: [PATCH, testsuite]: Disable gcc.dg/pr61441 where issignaling is not available

On 01/14/2016 07:45 AM, Uros Bizjak wrote: 2016-01-14 Uros Bizjak * lib/target-supports.exp (check_effective_target_issignaling): New procedure. * gcc.dg/pr61441.c: Require issignaling effective target. Tested on x86_64-linux-gnu, CentOS 5.11 and Fedora 23.

Re: [PATCH] Fortran testsuite fix from Francois

On 01/14/2016 07:35 AM, Jakub Jelinek wrote: Hi! I've bootstrapped/regtested on x86_64-linux and i686-linux the following fix from Francois that has been sitting in the PR for a few months. The problem is that the testcase assumed that the last real_kind has maximum precision and maximum range.

Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe.

On 07/01/16 17:47 +0100, Torvald Riegel wrote: The attached patch makes some exceptions transaction-safe, as require by the Transactional Memory TS. I believe I addressed all feedback for the previous version of this patch (in particular, there are now more safety checks for preconditions for

Re: [PATCH] Fix PR c++/68936

OK. Jason

Re: [PATCH] Handle BUILT_IN_GOACC_PARALLEL in ipa-pta

Hi! On Fri, 8 Jan 2016 09:16:55 +0100, Richard Biener wrote: > On Wed, 16 Dec 2015, Tom de Vries wrote: > > On 10/12/15 14:14, Tom de Vries wrote: > > > > On Thu, 3 Dec 2015, Tom de Vries wrote: > > > > > Essentially we have two situations: > > > > > - in the host compiler,

Re: [PATCH] Handle BUILT_IN_GOACC_PARALLEL in ipa-pta

On Thu, 14 Jan 2016, Thomas Schwinge wrote: > Hi! > > On Fri, 8 Jan 2016 09:16:55 +0100, Richard Biener wrote: > > On Wed, 16 Dec 2015, Tom de Vries wrote: > > > On 10/12/15 14:14, Tom de Vries wrote: > > > > > On Thu, 3 Dec 2015, Tom de Vries wrote: > > > > > > Essentially

C PATCH to enhance array bounds diagnostics (PR c/69262)

This PR is a request for better array bounds diagnostics. The C++ FE says "multidimensional array must have bounds for all dimensions except the first", and we can do something similar in the C FE. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2016-01-14 Marek Polacek

[PATCH 3/4 v2] Enhance SCEV to follow copies of SSA_NAMEs.

(Previous message: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02159.html) On Sat, Dec 26, 2015 at 18:58 PM, Richard Biener wrote: >> I'm not sure whether adding a pass_copy_prop is the right thing here, but >> since >> loop-header-copying can create such

Re: [gomp4, PR68977, Committed] Don't gimplify in ssa mode if seen_error in oacc_xform_loop

On Wed, Jan 13, 2016 at 9:04 PM, Tom de Vries wrote: > Hi, > > At r231739, there was an ICE when checking code generated by > oacc_xform_loop, in case the source contained an error. > > Due to seen_error (), gimplification during oacc_xform_loop bailed out, and > an

Re: [PATCH][MIPS] Migrate reduction optabs in mips-ps-3d.md

On 07/01/16 12:47, Alan Lawrence wrote: Here's an updated version, also covering the min/max patterns I missed before. I've now managed to do some testing with a stage 1 compiler, by compiling all tests in gcc.dg/vect at -O2 -ftree-vectorize -mips3d -march=mips64r2 -mabi=n32 $x -ffast-math

RE: [PATCH][MIPS] Migrate reduction optabs in mips-ps-3d.md

Alan Lawrence writes: > On 07/01/16 12:47, Alan Lawrence wrote: > > Here's an updated version, also covering the min/max patterns I missed > before. > > I've now managed to do some testing with a stage 1 compiler, by > > compiling all tests in gcc.dg/vect at -O2

Re: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation

On 01/13/2016 01:10 AM, Jeff Law wrote: I'm going to focus on adpcm for the moment, in particular adpcm_coder. It appears the key blocks are: Looking at adpcm_decoder we have the same idiom as in adpcm_coder: if (bufferstep_79 != 0) goto ; else goto ; ;;succ: 6 [50.0%]

Re: [PATCH][PR tree-optimization/69270] Exploit VRP information in DOM

On Thu, Jan 14, 2016 at 8:38 AM, Jeff Law wrote: > > As noted in the BZ, DOM does not exploit VRP information to create > additional equivalences in the arms of conditionals. > > This can cause DOM to miss relatively simple optimizations that show up in > the adpcm benchmark as

[PATCH] Tidy: remove reduc_xxx_optab migration code

If/when mips-ps-3d.md is moved from reduc_* to reduc_*_scal optabs (patch here: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00311.html ), there will be no uses of the old reduc_* optabs remaining. This patch removes those optabs and the migration path. Bootstrapped + check-gcc + check-g++ on

Re: [PATCH 4/2] S/390 test case fixes.

On Mon, Jan 11, 2016 at 11:46:21AM +0100, Dominik Vogt wrote: > The following two patches fix some test cases for S/390. Patch 4: Adapt the test pattern in bind_c_array_params_2.f90 to S/390 assemply output. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany gcc/testsuite/ChangeLog

Commit: Try harder to run ARM neon testcases

Hi Guys Whilst checking PR 69194 I noticed that the new testcase (gcc.target/arm/pr69194.c) was not being run with a Linux hosted toolchain configured as --target=arm-eabi. Investigating further I found that the check_effective_target_arm_neon_ok_nocache proc in target_supports.exp was

Re: [PATCH 3/4 v2] Enhance SCEV to follow copies of SSA_NAMEs.

On Thu, Jan 14, 2016 at 11:29 AM, Alan Lawrence wrote: > (Previous message: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02159.html) > On Sat, Dec 26, 2015 at 18:58 PM, Richard Biener > wrote: > >>> I'm not sure whether adding a pass_copy_prop

Re: [hsa merge 03/10] HSA libgomp plugin

On Wed, Jan 13, 2016 at 06:39:28PM +0100, Martin Jambor wrote: > the patch below adds the HSA-specific plugin for libgomp. The plugin > implements the interface mandated by libgomp and takes care of finding > any available HSA devices, finalizing HSAIL code and running it on > HSA-capable GPUs. >

Re: [hsa merge 08/10] HSAIL BRIG description header file

On Wed, Jan 13, 2016 at 06:39:33PM +0100, Martin Jambor wrote: > the following patch adds a BRIG (binary representation of HSAIL) > representation description. It is within a single header file > describing the binary structures and constants of the format. > > The file comes from the HSA

Re: [committed][trans-mem, aa64, arm, ppc, s390] Fixing PR68964

On 13 January 2016 at 18:17, Richard Henderson wrote: > On 01/12/2016 08:53 AM, Richard Henderson wrote: >> >> The problem in this PR is that we never got around to flushing out the >> vector >> support for transactions for anything but x86. My goal here is to make >> this as >>

[PATCH] S/390: Add missin full stop in option description.

The attached patch fixes a test failure because of a missing full stop at the end of an S/390 option help text. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany gcc/ChangeLog * config/s390/s390.opt (mtune): Add full stop. >From 6d4de7bb9ff9643b4cf3c967ea5ccfd1591d0799 Mon Sep 17

Re: [hsa merge 05/10] OpenMP lowering/expansion changes (gridification)

On Wed, Jan 13, 2016 at 06:39:30PM +0100, Martin Jambor wrote: > @@ -726,14 +730,14 @@ struct GTY((tag("GSS_OMP_CONTINUE"))) >tree control_use; > }; > > -/* GIMPLE_OMP_SINGLE, GIMPLE_OMP_TEAMS, GIMPLE_OMP_ORDERED */ > +/* GIMPLE_OMP_SINGLE, GIMPLE_OMP_ORDERED */ I think in this patch

Re: [hsa merge 07/10] IPA-HSA pass

On Wed, Jan 13, 2016 at 06:39:32PM +0100, Martin Jambor wrote: > + cgraph_node *clone = node->create_virtual_clone > + (vec (), NULL, NULL, "hsa"); Nicer formatting would be cgraph_node *clone = node->create_virtual_clone (vec (),

Re: [PATCH, i386, AVX512] PR target/69228: Restrict default masks for prefetch gathers/scatters instructions.

Now bootstrapped and regtested against GCC v5. OK for 5-branch thus? Regards, Alexander On Wed, Jan 13, 2016 at 03:41:26PM +0300, Kirill Yukhin wrote: > Hello Sasha, > On 12 Jan 14:57, Alexander Fomin wrote: > > This patch addresses PR target/69228. Expanding non-mask builtins > > for prefetch

Re: [PATCH] Tidy: remove reduc_xxx_optab migration code

On Thu, Jan 14, 2016 at 11:26 AM, Alan Lawrence wrote: > If/when mips-ps-3d.md is moved from reduc_* to reduc_*_scal optabs (patch > here: > https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00311.html ), there will be no > uses of the old reduc_* optabs remaining. This patch

Re: [hsa merge 01/10] Configury changes and new options

On Wed, Jan 13, 2016 at 06:39:26PM +0100, Martin Jambor wrote: > Hi, > > this patch contains changes to the configuration mechanism and offload > bits, so that users can build compilers with HSA support. > > It is a re-post of > https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00714.html, which,

Re: [hsa merge 06/10] Pass manager changes

On Wed, Jan 13, 2016 at 06:39:31PM +0100, Martin Jambor wrote: > Hi, > > the pass manager changes required for HSA have already been committed > to trunk so all that remains are these additions to the pass pipeline. > > This bit has already been approved by Richi in >

Re: Commit: Try harder to run ARM neon testcases

Hi Christian, * gcc.target/arm/attr-neon.c: Use dg-add-options to add the command line options necessary to enable Neon support. is this last one needed ? the __attribute__ ((target("fpu=neon"))) is here to test without -mfpu=neon. So we are losing something here. Ah, good point.

[PATCH] Avoid simplifying RTL expressions in too large integral modes (PR target/68269)

Hi! This PR is an ICE while expand_field_assignment attempts to "simplify" some (zero_extract:DI (subreg:DI (reg:OI ...) 0) (const_int 32) (const_int 0)) or what on ia64. The problem is that ia64 and various other backends add various very large integral modes (OI in this case, but x86_64 even

Re: [hsa merge 09/10] Majority of the HSA back-end

On Wed, Jan 13, 2016 at 06:39:34PM +0100, Martin Jambor wrote: > +struct function_linkage_pair > +{ > + function_linkage_pair (tree decl, unsigned int off): I would have expected a space before :, or better yet on the next line: function_linkage_pair (tree decl, unsigned int off) :

Re: [openacc] implicit non-scalars data mapping in kernels

On 01/13/16 17:44, Jakub Jelinek wrote: On Wed, Jan 13, 2016 at 11:35:08PM +0100, Marek Polacek wrote: On Wed, Jan 13, 2016 at 02:29:21PM -0800, Cesar Philippidis wrote: --- a/gcc/gimplify.c +++ b/gcc/gimplify.c @@ -5994,6 +5994,11 @@ oacc_default_clause (struct gimplify_omp_ctx *ctx, tree

Re: [hsa merge 05/10] OpenMP lowering/expansion changes (gridification)

Hi Martin, while addressing Jakub's feedback can you also fix the typos below? (noticed because I needed to reuse those hunks in gomp-nvptx) On Wed, 13 Jan 2016, Martin Jambor wrote: > +/* Return a target argument consisiting of DEVICE identifier, value > identifier > + ID, and the actual

[PATCH] Fix complex lowering (PR middle-end/68146, PR tree-optimization/69155)

Hi! During complex lowering, we were walking bbs in bb index # order, which means sometimes we could visit SSA_NAME uses before visiting definitions. Also, even if we walk in rpo order as the following patch does, sometimes we need to first use SSA_NAMEs before their definitions are lowered at

[PATCH] Fortran testsuite fix from Francois

Hi! I've bootstrapped/regtested on x86_64-linux and i686-linux the following fix from Francois that has been sitting in the PR for a few months. The problem is that the testcase assumed that the last real_kind has maximum precision and maximum range. That is usually the case, but is not the case

[PATCH 7/9] S/390: Get rid of Y constraint in vector.md.

This finally removes the Y constraint from the vector patterns while folding some of them using a code iterator. gcc/ChangeLog: 2016-01-14 Andreas Krebbel * config/s390/subst.md (SUBST mode iterator): Add ashiftrt. (DSI_VI): New mode iterator.

[PATCH 5/9] S/390: Get rid of Y constraint in arithmetic right shift patterns.

The arithmetic shift patterns set also the condition code. This adds more substitution potential. Depending on whether the actual result or the CC output will be used 3 different variants of each of these patterns are needed. This multiplied with the PLUS and the AND operands from the earlier

[PATCH][ARM][4.9 backport] Fix PR target/68648

Hi all, This the 4.9 backport of https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00708.html. The gcc change is the same, but the testcase is put into gcc.dg/torture rather than gcc.c-torture/execute. This is because the testcase actually requires a -std=gnu99, and adding a dg-options in

[PATCH 9/9] S/390: Disallow SImode in s390_decompose_address

After Y is never used anymore with SImode operands we can finally disallow SImode (if != Pmode) in s390_decompose_address. In fact that was the whole point of the patch series. gcc/ChangeLog: 2016-01-14 Andreas Krebbel * config/s390/s390.c

Re: Problematic 'target teams' libgomp tests

On Thu, Jan 14, 2016 at 07:08:23PM +0300, Alexander Monakov wrote: > On Thu, 14 Jan 2016, Jakub Jelinek wrote: > > That is weird, because c is also a firstprivate var in target and > > (implicitly) shared in teams, so if omp lowering/expansion is not buggy, > > you should see the exactly same

[PATCH 0/9] S/390 rework shift count handling

On S/390 we have address style shift counts. So it is possible to have a reg + const_int shift count. To address this it appeared to be convenient to really handle this as address operand. For that reason the "Y" constraint used for shift counts is an extra memory constraint. Unfortunately a

reject decl with incomplete struct/union type in check_global_declaration()

Hi, For test-case containing only the following declaration: static struct undefined_struct object; gcc rejects it at -O0 in assemble_variable() with error "storage size of is unknown", however no error is reported when compiled with -O2. AFAIU that happens because at -O2, analyze_function()

[PATCH 2/9] S/390: Add disabled insn attribute

So far whenever we wanted to disable an alternative we have used mode attributes emitting constraints matching an earlier alternative assuming that due to this the later alternative will never be chosen. With this patch a `disabled' attribute is defined which can be used to explicitly disable an

[doc, 5/n] invoke.texi: add new "Program Instrumentation Options" section

This patch consolidates the documentation of GCC options that add runtime profiling, error checking, or other instrumentation into a single section. Currently these are scattered all over, variously classified as debugging options, code generation options, optimization options, etc. Here is

Re: [PATCH] fix #69277 - [6 Regression] ICE mangling a flexible array member

On 01/14/2016 05:02 PM, Martin Sebor wrote: On 01/14/2016 03:51 PM, Jakub Jelinek wrote: On Thu, Jan 14, 2016 at 03:46:26PM -0700, Martin Sebor wrote: c++/69277 reports an ICE when mangling a template specialization involving flexible array member. Debugging the problem revealed that GCC

[PATCH, rs6000] Add support for __builtin_cpu_is() and __builtin_cpu_supports()

This patch adds support for __builtin_cpu_init(), __builtin_cpu_is() and __builtin_cpu_supports() builtins for PowerPC. We use the same API as the x86* builtins of the same name. These builtins uses the new GLIBC 2.23 feature where we store the AT_PLATFORM, AT_HWCAP and AT_HWCAP2 values in the

Re: [PATCH] Fix PR c++/21802 (two-stage name lookup fails for operators

On Thu, 14 Jan 2016, Ryan Burn wrote: Also caused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69091 Thanks for the heads up, I was not aware I had caused this regression.

Re: Ping: check initializer to be zero in .bss-like sections

On 01/12/2016 03:01 AM, Jan Beulich wrote: On 10.12.15 at 08:21, wrote: Just like gas, which has recently learned to reject such initializers, gcc shouldn't accept such either. --- The only question really is whether the new test case should be limited to certain targets - I haven't been able

[PATCH] fix #69277 - [6 Regression] ICE mangling a flexible array member

c++/69277 reports an ICE when mangling a template specialization involving flexible array member. Debugging the problem revealed that GCC (prior to the ICE), due to treating flexible array members the same as zero-length arrays, produced the wrong mangling for the former. The attached patch

[PATCH] sanitize paths used in regular expression

This patch fixes a small problem when running 'make check' from a path that includes "++". When such paths get used as a regular expression, that sequence would cause a runtime error. That is prevented here by escaping that character. gcc/testsuite/lib/ * prune.exp

Re: [PATCH] sanitize paths used in regular expression

On Jan 14, 2016, at 4:54 PM, Zachary T Welch wrote: > This patch fixes a small problem when running 'make check' from a path > that includes "++". When such paths get used as a regular expression, > that sequence would cause a runtime error. That is prevented here by >

Re: [PATCH] fix #69277 - [6 Regression] ICE mangling a flexible array member

On 01/14/2016 07:52 PM, Jeff Law wrote: On 01/14/2016 05:02 PM, Martin Sebor wrote: On 01/14/2016 03:51 PM, Jakub Jelinek wrote: On Thu, Jan 14, 2016 at 03:46:26PM -0700, Martin Sebor wrote: c++/69277 reports an ICE when mangling a template specialization involving flexible array member.

Re: [PATCH 1/3] Fix logic bug in Cilk Plus array expansion

On Thu, 14 Jan 2016, Jeff Law wrote: On 01/10/2016 08:55 PM, Patrick Palka wrote: On Mon, Jan 4, 2016 at 1:35 PM, Jeff Law wrote: On 01/02/2016 04:26 PM, Patrick Palka wrote: On Sat, Jan 2, 2016 at 3:21 AM, Jakub Jelinek wrote: On Fri, Jan 01, 2016 at

[PATCH/RFC] PR48344: Fix unrecognizable insn error when gcc command line specifies -fstack-limit-register=r2

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48344 for the original problem report. The error resulted because gcc's processing of command-line options within gcc initialization code originally preceded the processing of target-specific configuration hooks. In the unpatched gcc

[doc, 4/n] invoke.texi: there is no part 4

Part 4 of this series was originally intended to move the section "Using Precompiled Headers" from invoke.texi to extend.texi. But, as I started to dig around to decide exactly where its should go, I didn't see a good place to put it there, either -- extend.texi is still very disorganized.

Re: [PATCH][PR tree-optimization/69270] Exploit VRP information in DOM

On 01/14/2016 11:27 AM, Jeff Law wrote: Apart from what Jakub said we have constant_boolean_node for this, true_val = constant_boolean_node (true, TREE_TYPE (op0)); Will update. Thanks. Here's the patch which uses constant_boolean_node and verifies the type is unsigned when it has a

Re: [cilkplus] Fix cilk_spawn gimplification bug (PR cilkplus/69048)

On Thu, Jan 14, 2016 at 02:57:06PM -0700, Jeff Law wrote: > On 01/14/2016 02:19 PM, Ryan Burn wrote: > >This patch adds a missing cleanup point to cilk_spawn expressions to > >prevent an ICE when calling functions that return types with > >non-trivial destructors. > > > >Bootstrapped and

Re: [cilkplus] Fix cilk_spawn gimplification bug (PR cilkplus/69048)

On Thu, Jan 14, 2016 at 05:41:25PM -0500, Ryan Burn wrote: > > The > > /* The statement containing the spawn expression might create temporaries > > with > > line is (1 char) too long, so you want to reformat that comment. > > > > Jakub > > Are you sure? It passed the

Re: [openacc] implicit non-scalars data mapping in kernels

On 01/14/2016 06:18 AM, Nathan Sidwell wrote: > On 01/13/16 17:44, Jakub Jelinek wrote: >> On Wed, Jan 13, 2016 at 11:35:08PM +0100, Marek Polacek wrote: >>> On Wed, Jan 13, 2016 at 02:29:21PM -0800, Cesar Philippidis wrote: --- a/gcc/gimplify.c +++ b/gcc/gimplify.c @@ -5994,6

Re: [openacc] implicit non-scalars data mapping in kernels

On Thu, Jan 14, 2016 at 03:02:28PM -0800, Cesar Philippidis wrote: > > Is this a case of the Fortran FE OpenACC bits not annotating some > > artificial object correctly? > > I don't think it's specific to fortran. You can have reference types in > c++ too. Actually, Jakub's comment reminded me to

[PATCH] add test for c++/68490 - error initializing a structure with a flexible array member

Among the bugs fixed by the flexible array patch (r231665) was c++/68490. I forgot to include a test for this bug in the commit so I'm adding it via the attached patch. (Please let me know if adding new passing tests is considered trivial and I don't need to request approval for such things.)

Re: [hsa merge 08/10] HSAIL BRIG description header file

Jakub Jelinek writes: > On Wed, Jan 13, 2016 at 06:39:33PM +0100, Martin Jambor wrote: >> the following patch adds a BRIG (binary representation of HSAIL) >> representation description. It is within a single header file >> describing the binary structures and constants of the

Re: [cilkplus] Fix cilk_spawn gimplification bug (PR cilkplus/69048)

On Thu, Jan 14, 2016 at 5:34 PM, Jakub Jelinek wrote: > On Thu, Jan 14, 2016 at 02:57:06PM -0700, Jeff Law wrote: >> On 01/14/2016 02:19 PM, Ryan Burn wrote: >> >This patch adds a missing cleanup point to cilk_spawn expressions to >> >prevent an ICE when calling functions that

Re: [PATCH] fix #69277 - [6 Regression] ICE mangling a flexible array member

On Thu, Jan 14, 2016 at 03:46:26PM -0700, Martin Sebor wrote: > c++/69277 reports an ICE when mangling a template specialization > involving flexible array member. Debugging the problem revealed > that GCC (prior to the ICE), due to treating flexible array > members the same as zero-length

Re: [PATCH] Fix PR c++/21802 (two-stage name lookup fails for operators)

Also caused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69091 On Wed, Dec 16, 2015 at 4:46 PM, Markus Trippelsdorf wrote: > On 2015.12.14 at 19:34 -0500, Jason Merrill wrote: >> OK. > > This patch caused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68936 > > -- > Markus

[committed] PR rtl-opt/69014 -- doloop conversion bug

The test case gets mis-compiled on arm, because cse1 unifies a comparison across an extended basic block, then the doloop_end pattern clobbers the shared comparison. Fixing this is relatively easy -- notice if the doloop_end pattern that gets emitted clobbers anything that's live at the end

Re: [PATCH] fix #69277 - [6 Regression] ICE mangling a flexible array member

On 01/14/2016 03:51 PM, Jakub Jelinek wrote: On Thu, Jan 14, 2016 at 03:46:26PM -0700, Martin Sebor wrote: c++/69277 reports an ICE when mangling a template specialization involving flexible array member. Debugging the problem revealed that GCC (prior to the ICE), due to treating flexible

[PATCH] powerpc: Add some XFAILs to 20050603-3.c (PR68803)

In r230167 I made this testcase be tested on 64-bit as well, since it now works. That was a tad optimistic for powerpc64le though. For now, XFAIL it there. Is this okay for trunk? Tested the testcase manually on powerpc64-linux and powerpc64le-linux (that is, I ran "make check-gcc-c -k

Re: [PATCH] PR preprocessor/69177 and PR c++/68819: libcpp fallbacks and -Wmisleading-indentation (v2)

On 01/08/2016 02:40 PM, David Malcolm wrote: Jakub had some concern about the use of sorry, so here's a revised version of the patch, with the following changes: - fixed the comment issues noted above. - changed from a "sorry" to an "inform" (as per Jakub), passing in the pertinent

[patch] libstdc++/69240 generic operator!= for random number distributions

How do people feel about this approach to solving PR 69240? The bug is that we don't define operator!= for RND::param_type, where RND is any of random number distributions in or . Rather than tediously defining it for every param_type I've added this: namespace __random_not_eq { // Derive

[PATCH 8/9] S/390: Use define_subst for the setmem patterns.

While trying to get rid of the Y constraint in the setmem patterns I noticed that for these patterns it isn't even a problem since these always only use the constraint with a Pmode match_operand. But while being at it I've tried to fold some of the patterns a bit. gcc/ChangeLog: 2016-01-14

Re: [PATCH] powerpc: Add some XFAILs to 20050603-3.c (PR68803)

On 01/14/2016 11:23 AM, Segher Boessenkool wrote: In r230167 I made this testcase be tested on 64-bit as well, since it now works. That was a tad optimistic for powerpc64le though. For now, XFAIL it there. Is this okay for trunk? Tested the testcase manually on powerpc64-linux and

Re: [patch] libstdc++/69240 generic operator!= for random number distributions

On Thu, 14 Jan 2016, Jonathan Wakely wrote: How do people feel about this approach to solving PR 69240? The bug is that we don't define operator!= for RND::param_type, where RND is any of random number distributions in or . Rather than tediously defining it for every param_type I've added

Re: [cilkplus] Fix cilk_spawn gimplification bug (PR cilkplus/69048)

On 01/14/2016 03:34 PM, Jakub Jelinek wrote: On Thu, Jan 14, 2016 at 02:57:06PM -0700, Jeff Law wrote: On 01/14/2016 02:19 PM, Ryan Burn wrote: This patch adds a missing cleanup point to cilk_spawn expressions to prevent an ICE when calling functions that return types with non-trivial

Re: [patch] libstdc++/69240 generic operator!= for random number distributions

On Thu, 14 Jan 2016, Jonathan Wakely wrote: On 14/01/16 20:13 +0100, Marc Glisse wrote: I didn't think about it much, but I am worried that __random_not_eq will accidentally become an associated namespace for more classes than we would expect. Yes, it would be an associated namespace for

[cilkplus] Fix cilk_spawn gimplification bug (PR cilkplus/69048)

This patch adds a missing cleanup point to cilk_spawn expressions to prevent an ICE when calling functions that return types with non-trivial destructors. Bootstrapped and regression tested on x86_64-linux. 2015-01-14 Ryan Burn PR c++/69048 * cilk.c

Re: [patch] libstdc++/69240 generic operator!= for random number distributions

On 14/01/16 20:41 +, Jonathan Wakely wrote: On 14/01/16 20:57 +0100, Marc Glisse wrote: Once you constrain, you could even use 'std' as the associated namespace ;-) True! And std is already an associated namespace of the standard distributions, so we wouldn't be making ADL look anywhere

Re: [PATCH 3/3] [RFC] Treat a gimplification failure as an internal error

On 01/10/2016 08:20 PM, Patrick Palka wrote: On Thu, Dec 31, 2015 at 10:40 AM, Patrick Palka wrote: This patch makes it so that a gimplification failure is considered to be an internal error under normal circumstances, so that we otherwise avoid silently generating wrong

[PATCH][RFC][Offloading] Fix PR68463

Hi! Here is my attempt to fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68463 This patch does 2 things: I) lto-plugin doesn't claim files which contain offload sections, but don't contain LTO sections. Instead, it writes names of files with offloading to the temporary file and passes it to

[committed] Followup for pr68962; and pr69272

Predictably, I must have tweaked the patch after testing on x86. Re-tested and committed. r~ PR c/69272 PR tree-opt/68964 * trans-mem.c (tm_log_emit_stmt): Fix unit size to bit size. * tree.c (build_tm_vector_builtins): Use builtin_decl_explicit_p

Re: [patch] libstdc++/69240 generic operator!= for random number distributions

On 14/01/16 20:57 +0100, Marc Glisse wrote: Once you constrain, you could even use 'std' as the associated namespace ;-) True! And std is already an associated namespace of the standard distributions, so we wouldn't be making ADL look anywhere additional.

Re: [patch] libstdc++/69240 generic operator!= for random number distributions

On 14/01/16 21:22 +0100, Daniel Krügler wrote: If there were an __is_direct_base_of intrinsic (or is there?), it seems to me that there would be no need for all these specializations (each one nearly taking as much space as the explicit inline definition of operator!) and there could be a single

[PATCH 8/9] S/390: Use define_subst for the setmem patterns.

While trying to get rid of the Y constraint in the setmem patterns I noticed that for these patterns it isn't even a problem since these always only use the constraint with a Pmode match_operand. But while being at it I've tried to fold some of the patterns a bit. gcc/ChangeLog: 2016-01-14

Re: [patch] libstdc++/69240 generic operator!= for random number distributions

On 14/01/16 20:43 +, Jonathan Wakely wrote: On 14/01/16 21:22 +0100, Daniel Krügler wrote: If there were an __is_direct_base_of intrinsic (or is there?), it seems to me that there would be no need for all these specializations (each one nearly taking as much space as the explicit inline

Re: [patch] libsanitizer

On 13.01.16 18:39, Bernd Schmidt wrote: On 01/11/2016 07:37 PM, Andreas Tobler wrote: +# Do a configure time check for -ldl +AC_CHECK_LIB(dl, dlsym, + [link_sanitizer_common="-lrt $link_sanitizer_common"]) + I'll give it a test run. If that works (with -ldl instead of -lrt) it's ok. It

Re: [patch] libstdc++/69240 generic operator!= for random number distributions

On 14/01/16 20:46 +, Jonathan Wakely wrote: On 14/01/16 20:43 +, Jonathan Wakely wrote: On 14/01/16 21:22 +0100, Daniel Krügler wrote: If there were an __is_direct_base_of intrinsic (or is there?), it seems to me that there would be no need for all these specializations (each one

Re: Correct GCC Internals doc for loop_depth

On 01/10/2016 06:24 AM, Nicklas Bo Jensen wrote: Hi, In the GCC Internals documentation the loop depth is documented incorrectly. From git commit 9e3536f4f it is accessed through a function, not a field. Please install this patch to reflect this. Best, Nicklas 2017-01-10 Nicklas Bo Jensen

[PATCH 4/9] S/390: Get rid of Y constraint in left and logical right shift patterns.

With this patch the substitution patterns added earlier are used for the logical right shift and all the left shift patterns. 2016-01-14 Andreas Krebbel * config/s390/s390.md ("*di3_31", "*3") ("*di3_31_and", "*3_and"): Merge into single

Re: [PATCH 1/3] Fix logic bug in Cilk Plus array expansion

On 01/10/2016 08:55 PM, Patrick Palka wrote: On Mon, Jan 4, 2016 at 1:35 PM, Jeff Law wrote: On 01/02/2016 04:26 PM, Patrick Palka wrote: On Sat, Jan 2, 2016 at 3:21 AM, Jakub Jelinek wrote: On Fri, Jan 01, 2016 at 10:06:34PM -0700, Jeff Law wrote:

Re: [PATCH][PR tree-optimization/69270] Exploit VRP information in DOM

On 01/14/2016 02:47 AM, Richard Biener wrote: On Thu, Jan 14, 2016 at 8:38 AM, Jeff Law wrote: As noted in the BZ, DOM does not exploit VRP information to create additional equivalences in the arms of conditionals. This can cause DOM to miss relatively simple optimizations

Re: [patch] libstdc++/69240 generic operator!= for random number distributions

2016-01-14 20:21 GMT+01:00 Jonathan Wakely : > We could constrain the generic operator== and operator!= to only match > types that we want it to match, e.g. by having a type trait that is > true for all our distributions and their parameter types. That would > mean adding a

Re: [PATCH] Fortran testsuite fix from Francois

Dear Jakub, Thanks for that. OK by me too. Paul On 14 January 2016 at 18:36, Jeff Law wrote: > On 01/14/2016 07:35 AM, Jakub Jelinek wrote: >> >> Hi! >> >> I've bootstrapped/regtested on x86_64-linux and i686-linux the following >> fix >> from Francois that has been sitting in

  1   2   >