Re: Commit policy? Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags

On Mon, Jun 9, 2014 at 11:47 PM, Thomas Schwinge wrote: > Hi! > > On Tue, 3 Jun 2014 11:55:44 +0200, I wrote: >> Ping -- OK to commit to trunk? > > Even though several of those who I'd consider regular GCC developers do > agree with this patch (see also ), that is > no

Commit policy? Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags

Hi! On Tue, 3 Jun 2014 11:55:44 +0200, I wrote: > Ping -- OK to commit to trunk? Even though several of those who I'd consider regular GCC developers do agree with this patch (see also ), that is not enough "consensus" to consider this patch approved, right? Wouldn't

Re: config-ml.in: Robustify ac_configure_args parsing.

Hi! Ping. On Tue, 3 Jun 2014 11:57:44 +0200, I wrote: > Ping. > > > On Thu, 22 May 2014 12:58:05 +0200, I wrote: > > Ping. > > > > > > On Fri, 14 Mar 2014 12:22:29 +0100, I wrote: > > > $ ../configure --enable-foo='--enable-a=1 --enable-b=2 --enable-c=3' > > > [...] > > > $ make

Re: [RTL, i386] Use subreg instead of UNSPEC_CAST

On Tue, 19 Mar 2013, Richard Henderson wrote: I'm not fond of this, primarily because I believe the pattern should not exist at all. One year later, new try. Tweaking the pattern, I ended up with a copy of the mov pattern (the subreg is generated automatically when the modes don't match), so

Make ipa-ref somewhat less stupid

Hi, ipa-reference is somewhat stupid and builds its data sets for all variables including addressable and public one just to prune them out after all bitmaps are constructed. This used to make sense when the profile generation happened at compile time, but since ipa_ref datastructure was intrdoc

[committed] Add missing @cindex (PR c/60988)

transparent_union was missing a @cindex entry. Tested with info ./gcc/doc/gcc.info --index-search=transparent_union Committed as obvious. 2014-06-10 Marek Polacek PR c/60988 * doc/extend.texi: Add cindex for transparent_union. diff --git a/gcc/doc/extend.texi b/gcc/doc/exten

Re: RFC: C++ PATCH to remove -fabi-version=1 support

On Jun 9, 2014, at 1:46 PM, Jason Merrill wrote: > I'm updating -Wabi to allow for warnings about changes between a previous ABI > version and the currently selected one, and rather than adjust all the > warnings for -fabi-version=1 I'd like to tear it out. It has now been 10 > years since GCC

Re: libgo patch committed: Merge from revision 18783 of master

On Mon, Jun 9, 2014 at 5:36 PM, Ian Lance Taylor wrote: > There is no bug here, the control flow is just too complicated > for the compiler to sort out. I don't know why I'm > not seeing the warning [...] We have these compilation flags set: CFLAGS='-g3 -O3' CFLAGS_FOR_BUILD='-g3 -O3' CFL

[PATCH] Fix PR61375: cancel bswap optimization when value doesn't fit in a HOST_WIDE_INT

When analyzing a bitwise AND with a constant as part of a bitwise OR, the bswap pass stores the constant in a int64_t variable without checking if it fits. As a result, we get ICE when the constant is an __int128 value. This affects GCC trunk but also GCC 4.9 and 4.8 (and possibly earlier version a

[PATCH] Unchecked call to init_symbolic_number

When doing a bootstrap on x86_64-linux-gnu to test a patch I'm writing, I encountered a failure that turned out to be due to not checking the return value of init_symbolic_number in find_bswap_or_nop_load (tree-ssa-math-opts.c). The following patch fixes that and I commited it as obvious as per GCC

Re: [C++ Patch] PR 19200

I think the parser approach is more correct. On 06/09/2014 07:02 PM, Paolo Carlini wrote: !TYPE_WAS_ANONYMOUS (class_type) +&& !friend_p && constructor_name_p (unqualified_name,

Re: libgo patch committed: Merge from revision 18783 of master

And I also forgot to attach the patch. Sorry about this. On Mon, Jun 9, 2014 at 5:37 PM, Ian Lance Taylor wrote: > Forgot to CC gofrontend-dev. > > On Mon, Jun 9, 2014 at 5:36 PM, Ian Lance Taylor wrote: >> On Mon, Jun 9, 2014 at 1:12 PM, Gary Funck wrote: >>> On 06/04/14 18:28:17, Ian Lance T

Re: libgo patch committed: Merge from revision 18783 of master

Forgot to CC gofrontend-dev. On Mon, Jun 9, 2014 at 5:36 PM, Ian Lance Taylor wrote: > On Mon, Jun 9, 2014 at 1:12 PM, Gary Funck wrote: >> On 06/04/14 18:28:17, Ian Lance Taylor wrote: >>> I have committed a patch to libgo to merge from revision >>> 18783:00cce3a34d7e of the master library. >>

Re: libgo patch committed: Merge from revision 18783 of master

On Mon, Jun 9, 2014 at 1:12 PM, Gary Funck wrote: > On 06/04/14 18:28:17, Ian Lance Taylor wrote: >> I have committed a patch to libgo to merge from revision >> 18783:00cce3a34d7e of the master library. > > Based on trunk rev. 211365, we're seeing this warning: > > libgo/runtime/chan.c:484:7: erro

Re: [RFC][ARM] TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook

On 30/05/14 18:35, Ramana Radhakrishnan wrote: >> + if (!TARGET_VFP) >> +return; >> + >> + /* Generate the equivalence of : > > s/equivalence/equivalent. > > Ok with that change and if no regressions. Hi Ramana, Sorry, I missed the thumb1 part. There are no mrc/mcr versions of these inst

[C++ Patch] PR 19200

Hi, another old issue, which should be also relatively easy to fix. The problem is clear, for: struct S { struct T{}; friend void S(T); }; cp_parser_direct_declarator sees a name which matches that of a kosher constructor and sets sfk_constructor. Then things go quickly wrong because a

Re: [PATCH] C++ thunk section names

Ping. On Mon, May 19, 2014 at 11:25 AM, Sriraman Tallam wrote: > Ping. > > On Thu, Apr 17, 2014 at 10:41 AM, Sriraman Tallam wrote: >> Ping. >> >> On Wed, Feb 5, 2014 at 4:31 PM, Sriraman Tallam wrote: >>> Hi, >>> >>> I would like this patch reviewed and considered for commit when >>> Stage 1

Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations

Ping. On Mon, May 19, 2014 at 11:11 AM, Sriraman Tallam wrote: > Ping. > > On Thu, May 15, 2014 at 11:34 AM, Sriraman Tallam wrote: >> Optimize access to globals with -fpie, x86_64 only: >> >> Currently, with -fPIE/-fpie, GCC accesses globals that are extern to the >> module >> using the GOT.

Re: [PATCH] Misc Fortran OpenMP 4.0 changes (PR fortran/60928)

On Mon, Jun 09, 2014 at 11:49:50PM +0200, Tobias Burnus wrote: > I lost a bit track. Is this now complete in terms of F2003 and the only > missing bits is the support for devices and the test case for alignment? Or > is something else pending? I have still some pending questions with omp lang comm

Re: [PATCH] Misc Fortran OpenMP 4.0 changes (PR fortran/60928)

Jakub Jelinek wrote: This patch deals with various smaller things: 1) -fopenmp-simd fortran support 2) ALLOCATABLE handling fixes (e.g. copyin can't assume in OpenMP 4.0 that what it copies to has the same bounds and allocation status) 3) support for scalar ALLOCATABLE in various clauses 4) s

RFC: C++ PATCH to remove -fabi-version=1 support

I'm updating -Wabi to allow for warnings about changes between a previous ABI version and the currently selected one, and rather than adjust all the warnings for -fabi-version=1 I'd like to tear it out. It has now been 10 years since GCC 3.4. Any thoughts? commit a1a98ba5d18a57832ea1f3df1cc1f

Re: [PATCH, x86] Improves x86 permutation expand

On Mon, Jun 9, 2014 at 12:49 PM, Richard Henderson wrote: > On 06/09/2014 12:10 PM, Evgeny Stupachenko wrote: >> Nice catch. >> Patch with corresponding changes: > > Looks ok with an appropriate changelog. > It will be nice to include testcases to cover those changes. -- H.J.

Re: libgo patch committed: Merge from revision 18783 of master

On 06/04/14 18:28:17, Ian Lance Taylor wrote: > I have committed a patch to libgo to merge from revision > 18783:00cce3a34d7e of the master library. Based on trunk rev. 211365, we're seeing this warning: libgo/runtime/chan.c:484:7: error: ‘received’ may be used uninitialized in this function [-We

Re: [PATCH, i386]: Correctly handle maximum size of stringop algorithm in decide_alg

On 06/02/2014 02:32 PM, Uros Bizjak wrote: > + * config/i386/i386.c (decide_alg): Correctly handle maximum size of > + stringop algorithm. Looks good. r~

Re: [PATCH, x86] Improves x86 permutation expand

On 06/09/2014 12:10 PM, Evgeny Stupachenko wrote: > Nice catch. > Patch with corresponding changes: Looks ok with an appropriate changelog. r~

Re: RFA: Rework FOR_BB_INSNS iterators

Steven Bosscher writes: > On Sat, Jun 7, 2014 at 7:54 PM, Richard Sandiford wrote: >> The two parts of the loop condition are really handling two different >> kinds of block: ones like entry and exit that are completely empty >> and normal ones that have at least a block note. There's no real >>

Re: [PATCH, x86] Improves x86 permutation expand

Nice catch. Patch with corresponding changes: diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 8827256..0b80354 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -43185,6 +43185,80 @@ expand_vec_perm_palignr (struct expand_vec_perm_d *d) return ok; } +/* A

Re: Ping [PATCH, fortran] PR 41936 Memory leakage with allocatables and user-defined operators

Dear Dominique, Without the patch applied, trunk shows 360 bytes definitely missing in 3 blocks for the original testcase and 9 out of 92 allocs did not have corresponding frees. WIth the patch, I get: ==20527== ==20527== HEAP SUMMARY: ==20527== in use at exit: 0 bytes in 0 blocks ==20527==

Re: [PATCH, i386]: Correctly handle maximum size of stringop algorithm in decide_alg

Ping. On Mon, Jun 2, 2014 at 11:12 PM, Uros Bizjak wrote: > Hello! > > A problem was uncovered by -march=corei7 -mtune=intel -m32 with > i386/memcpy-[23] testcase in decide_alg subroutine [1]. Although the > max size of the transfer was known, the memcpy was not inlined, as > expected by the test

Re: [PATCH,MIPS] Remove unused code relating to reloading fcc

Matthew Fortune writes: > This is a small clean-up patch to remove code relating to reloading or moving > mips fcc registers. At some point in the past these registers were allocated > as part of register allocation but they are now statically allocated in the > backend in a round robin fashion. T

Re: [C++ Patch] PR 22556

OK. Jason

Re: [PATCH] proposed fix for bug # 61144

On Mon, Jun 09, 2014 at 03:40:44PM +0400, Alexander Monakov wrote: > > > On Fri, 6 Jun 2014, Rich Felker wrote: > > > On Fri, May 23, 2014 at 12:26:18PM -0600, Jeff Law wrote: > > > On 05/21/14 21:59, Rich Felker wrote: > > > >On Wed, May 21, 2014 at 11:17:53AM +0200, Richard Biener wrote: > > >

[C++ Patch] PR 22556

Hi, I believe this very old issue simply boils down to using comptypes with COMPARE_REDECLARATION instead of same_type_p (comp_array_types is careful with TYPE_DOMAINs). Tested x86_64-linux. Thanks, Paolo. /cp 2014-06-09 Paolo Carlini PR c++/22556 *

Re: [PATCH 4/5] add gcc/gdb interface files

On 06/05/14 19:54, Tom Tromey wrote: "Jakub" == Jakub Jelinek writes: Jakub> Another possibility would be to give the macros twice as many arguments Jakub> as there are parameters and just through the odd arguments away when Jakub> expanding to the template parameters. That would mean you wri

Re: [PATCH] Fix PR middle-end/61141

On 6/9/2014 12:41 PM, Jeff Law wrote: What's new is the verification after assembly output. Right. Thanks for the analysis. I know it takes significant time. Not a problem. Thanks for installing the change. Dave -- John David Anglindave.ang...@bell.net

Re: [PATCH 2/5] c_diagnostic_ignored_function hack

> "Manuel" == Manuel López-Ibáñez writes: Tom> This patch makes it possible to suppress the function-name display in Tom> a straightforward way: it adds a new global which the plugin can set Tom> to declare the name of the dummy function. Manuel> Otherwise, why not override the lang_hook its

Re: [PATCH] Trust TREE_ADDRESSABLE

> > I wonder if we want toupdate the frontends to set addressable flag with new > > sense or we want symtab to simple set addressable on all global symbols or > > invent a new flag. > > I would preffer the first case - it seems to make most sense to me. > > I think you need to explain why this cha

Re: [PATCH] Fix PR middle-end/61141

On 06/08/14 12:06, John David Anglin wrote: On 4-Jun-14, at 3:38 AM, Jeff Law wrote: On 05/24/14 12:39, John David Anglin wrote: The insns are being deleted in "final" after the assembly output has being done. So, for example, pa_output_call is never called with a delayed branch sequence con

Re: [PATCH, x86] Improves x86 permutation expand

On 06/09/2014 03:13 AM, Evgeny Stupachenko wrote: > + /* First we apply one operand permutation to the part where > + elements stay not in their respective lanes. */ > + dcopy = *d; > + if (which == 2) > +dcopy.op0 = dcopy.op1 = d->op1; > + else > +dcopy.op0 = dcopy.op1 = d->op0; >

Re: -finit-local-vars option

On 06/06/14 09:00, Florian Weimer wrote: The attached crude patch as an -finit-local-vars option to the C front end. If active, all local variables are initialized to zero. It is part of an experiment to assess the performance impact of local variable initialization. I'd expect impact to be min

Re: [PATCH] Support asan-instrumentation-with-call-threshold in GCC (second try)

Build_check_stmt is now unified for const/variable lengths but I'd still prefer to treat the use_calls case specially because calling single __asan_loadN is more space-efficient than emitting two separate calls with a length check. That is not what I meant. 1) instrument_mem_region_access/instru

Re: [C PATCH] Use inform for "near initialization for" (PR c/36446)

On Mon, 9 Jun 2014, Marek Polacek wrote: > It seems that "(near initialization for )" message should be a "note:" > message rather than error/warning. This patch changes error_at/warning > calls to inform and fixes the testsuite fallout. > > Tested x86_64-unknown-linux-gnu, ok for trunk? OK. -

Re: PR54442 build_qualified_type produces a non-canonical type

On 06/09/2014 10:32 AM, Marc Glisse wrote: On Mon, 9 Jun 2014, Jason Merrill wrote: On 06/09/2014 10:18 AM, Marc Glisse wrote: I doubt the patch can be wrong, but it may be that this is a situation that is not supposed to happen and should be fixed elsewhere? Seems likely. What is the diffe

Re: [C++11, C++14 PATCH 4/4] Support for SD-6: SG10 Feature Test Recommendations: gcc/testsuite

On 06/09/2014 10:21 AM, Ed Smith-Rowland wrote: +// TODO: Change <= to < when C++14 constexpr goes in. +#ifdef __cpp_constexpr +# if __cpp_constexpr <= 201304 +#error "__cpp_constexpr" +# endif +#endif How is this passing currently? 200704 <= 201304, so I would expect this to error.

Re: [C++11, C++14 PATCH 1/4] Support for SD-6: SG10 Feature Test Recommendations: libcpp

On 06/09/2014 10:20 AM, Ed Smith-Rowland wrote: + if (token->type == CPP_OPEN_PAREN) +{ + paren = true; + token = cpp_get_token (pfile); +} + if (token->type == CPP_STRING || token->type == CPP_HEADER_NAME) Let's add a blank line between the ifs since it's not an else if. O

Re: [C++11, C++14 PATCH 2/4] Support for SD-6: SG10 Feature Test Recommendations: gcc/c-family

On 06/09/2014 10:20 AM, Ed Smith-Rowland wrote: + if (cxx_dialect > cxx11) + { + /* Set feature test macros for C++14 */ + cpp_define (pfile, "__cpp_binary_literals=201304"); + cpp_define (pfile, "__cpp_init_captures=201304"); ... + cpp_define (pfile,

Re: [C++11, C++14 PATCH 3/4] Support for SD-6: SG10 Feature Test Recommendations: libstdc++-v3

On 9 June 2014 15:20, Ed Smith-Rowland wrote: > This is the second round of the SD-6 support series. > I believe I have answered everyones concerns. > Several test suite adjustments were added. > > Built and tested on x86_64-linux. > > OK? This libstdc++ part is OK, assuming the other parts get ap

Re: PR54442 build_qualified_type produces a non-canonical type

On Mon, 9 Jun 2014, Jason Merrill wrote: On 06/09/2014 10:18 AM, Marc Glisse wrote: I doubt the patch can be wrong, but it may be that this is a situation that is not supposed to happen and should be fixed elsewhere? Seems likely. What is the difference between the type returned from build_

Re: PR54442 build_qualified_type produces a non-canonical type

On 06/09/2014 10:18 AM, Marc Glisse wrote: I doubt the patch can be wrong, but it may be that this is a situation that is not supposed to happen and should be fixed elsewhere? Seems likely. What is the difference between the type returned from build_qualified_type (TYPE_CANONICAL and it's TYP

[C++11, C++14 PATCH 4/4] Support for SD-6: SG10 Feature Test Recommendations: gcc/testsuite

This is the second round of the SD-6 support series. I believe I have answered everyones concerns. Built and tested on x86_64-linux. OK? libstdc++: 2014-06-09 Ed Smith-Rowland <3dw...@verizon.net> Implement SD-6: SG10 Feature Test Recommendations * g++.dg/cpp1y/feat-cxx11-n

[C++11, C++14 PATCH 3/4] Support for SD-6: SG10 Feature Test Recommendations: libstdc++-v3

This is the second round of the SD-6 support series. I believe I have answered everyones concerns. Several test suite adjustments were added. Built and tested on x86_64-linux. OK? 2014-06-09 Ed Smith-Rowland <3dw...@verizon.net> Implement SD-6: SG10 Feature Test Recommendations

[C++11, C++14 PATCH 2/4] Support for SD-6: SG10 Feature Test Recommendations: gcc/c-family

This is the second round of the SD-6 support series. I believe I have answered everyones concerns. Built and tested on x86_64-linux. OK? 2014-06-09 Ed Smith-Rowland <3dw...@verizon.net> Implement SD-6: SG10 Feature Test Recommendations * c-cppbuiltin.c (c_cpp_builtins()): De

[C++11, C++14 PATCH 1/4] Support for SD-6: SG10 Feature Test Recommendations: libcpp

This is the second round of the SD-6 support series. I believe I have answered everyones concerns. Built and tested on x86_64-linux. OK? 2014-06-09 Ed Smith-Rowland <3dw...@verizon.net> Implement SD-6: SG10 Feature Test Recommendations * directives.c: Support __has_include__

PR54442 build_qualified_type produces a non-canonical type

Hello, in this PR, we end up with 3 types A, B and C such that TYPE_CANONICAL(A)=B and TYPE_CANONICAL(B)=C. I don't think that is supposed to happen. Here, build_qualified_type fills in TYPE_CANONICAL(A) by calling build_qualified_type (so get_qualified_type), which afaics isn't guaranteed to

[PATCH,MIPS] Remove unused code relating to reloading fcc

This is a small clean-up patch to remove code relating to reloading or moving mips fcc registers. At some point in the past these registers were allocated as part of register allocation but they are now statically allocated in the backend in a round robin fashion. The code for reloading them is the

[PATCH, ARM] Cortex-A9 MPCore volatile load workaround

Hi Richard, As we talked about earlier, here's a patch to add a compiler option to work around Cortex-A9 MPCore errata 761319: http://infocenter.arm.com/help/topic/com.arm.doc.uan0004a/UAN0004A_a9_read_read.pdf What the option does basically, is to scan for volatile loads during reorg, and add a d

Ping [PATCH, fortran] PR 41936 Memory leakage with allocatables and user-defined operators

Patch posted at https://gcc.gnu.org/ml/fortran/2014-05/msg00155.html. TIA Dominique

Re: [Patch, fortran] PR61406 - [4.9/4.10 Regression] ICE on ASSOCIATE construct to literal array expression

Dear Dominique, Committed to trunk as revision 211374. I decided that getting rid of the double temporary was delving too deep into the workings of trans-array.c to be worthwhile at the moment. Cheers Paul On 9 June 2014 12:05, Dominique Dhumieres wrote: > Dear Paul, > >> This was a slip up

[patch] fix minor typo in comment

Tested x86_64-linux, committed to trunk. commit 176c3be1080e0b33fe02612e015e42eb2d74cf0e Author: Jonathan Wakely Date: Mon Jun 9 10:40:47 2014 +0100 * include/tr1/beta_function.tcc: Fix spelling of include guard in comment. diff --git a/libstdc++-v3/include/tr1/beta_function.tcc b/l

Re: [patch] fix tests for AVX512

On Mon, Jun 9, 2014 at 1:34 PM, Kirill Yukhin wrote: > Hello Uroš, > On 08 Jun 11:26, Uros Bizjak wrote: >> On Tue, May 27, 2014 at 12:28 PM, Petr Murzin wrote: >> > Hi, >> > I've fixed tests for AVX512, so they could be compiled with -Werror >> > -Wall. Please have a look. >> From a quick look,

Re: [PATCH] proposed fix for bug # 61144

On Fri, 6 Jun 2014, Rich Felker wrote: > On Fri, May 23, 2014 at 12:26:18PM -0600, Jeff Law wrote: > > On 05/21/14 21:59, Rich Felker wrote: > > >On Wed, May 21, 2014 at 11:17:53AM +0200, Richard Biener wrote: > > >>On Wed, May 21, 2014 at 3:59 AM, Rich Felker wrote: > > >>>Bug # 61144 is a reg

Re: [patch] fix tests for AVX512

Hello Uroš, On 08 Jun 11:26, Uros Bizjak wrote: > On Tue, May 27, 2014 at 12:28 PM, Petr Murzin wrote: > > Hi, > > I've fixed tests for AVX512, so they could be compiled with -Werror > > -Wall. Please have a look. > From a quick look, this looks OK. Thanks, checked into trunk. Could we apply that

[Patch ARM] Remove XFmode from arm-modes.def

Hi, Marc Glisse pointed out that we had an unused XFmode in the ARM backend. RichardE says that this is an FPA legacy and that means we can remove this safely. Thus removed after a sanity check that the target builds ok. Applied to trunk as nearly obvious. regards Ramana 2014-06-09 Raman

[C PATCH] Use inform for "near initialization for" (PR c/36446)

It seems that "(near initialization for )" message should be a "note:" message rather than error/warning. This patch changes error_at/warning calls to inform and fixes the testsuite fallout. Tested x86_64-unknown-linux-gnu, ok for trunk? 2014-06-09 Marek Polacek PR c/36446 *

Re: [PATCH, x86] Improves x86 permutation expand

Right now we need to cover permutations coming from 3 loads/stores group. My case covers them. I agree that another order of pblend and pshufb covers additional cases. Good point. We can cover this in a separate patch. Asserts are ok if we exclude AVX2 in ISA checks. Is the following patch ok? d

Re: [PATCH ARM] PR/61062 Fix arm_neon.h ZIP/UZP/TRN for bigendian

Baking on trunk as of rev 211369. --Alan Ramana Radhakrishnan wrote: On Wed, May 14, 2014 at 2:52 PM, Alan Lawrence wrote: Hi, Due to differences in how the ARM C Language Extensions and gcc's vector extensions deal with indices within vectors, the __builtin_shuffle masks used to implement t

[PATCH][ARM][doc] Improve description of AArch32 CRC32 intrinsics

Hi all, The ACLE intrinsics documentation for arm can be improved a bit. Since there are potentially other ACLE intrinsics besides the CRC32 ones in the future, I moved the comment about their availability into the CRC32 intrinsics subsection. I removed the comment about the instruction form

Re: [Patch, fortran] PR61406 - [4.9/4.10 Regression] ICE on ASSOCIATE construct to literal array expression

Dear Paul, > This was a slip up on my part. The fix is obvious - OK for trunk and 4.9? The patch fixes the ICE. Any progress about the double temporary? [Book15] f90/bug% gfc pr61406.f90 -Warray-temporaries pr61406.f90:6.18: associate (n => [cos(theta), sin(theta)]) 1 Warni

Patch, fortran] PR61406 - [4.9/4.10 Regression] ICE on ASSOCIATE construct to literal array expression

Dear All, This was a slip up on my part. The fix is obvious - OK for trunk and 4.9? Cheers Paul 2014-06-09 Paul Thomas PR fortran/61406 * trans-stmt.c (trans_associate_var): Check that array constructors are constant for direct reference. 2014-06-09 Paul Thomas PR fort

Re: [PATCH] Trust TREE_ADDRESSABLE

> I wonder if we want toupdate the frontends to set addressable flag with new > sense or we want symtab to simple set addressable on all global symbols or > invent a new flag. > I would preffer the first case - it seems to make most sense to me. I think you need to explain why this change is desir

Re: [PATCH] Trust TREE_ADDRESSABLE

> > It is my fault here - I alwasy interpreted TREE_ADDRESSABLE this way and it > > seems to work for C/C++ that are the frontends I usually look into. > > But that's not true, see the obvious C testcase I attached in this thread! You are right - I never noticed the difference in cases I looked a

Re: [PATCH] Trust TREE_ADDRESSABLE

> It is my fault here - I alwasy interpreted TREE_ADDRESSABLE this way and it > seems to work for C/C++ that are the frontends I usually look into. But that's not true, see the obvious C testcase I attached in this thread! -- Eric Botcazou

Re: [PATCH] Add support for OpenMP fortran user defined reductions

On Sat, Jun 07, 2014 at 10:25:23AM +0200, Andreas Schwab wrote: > Jakub Jelinek writes: > > > I thought complex(kind=16) is normal double _Complex, isn't it? > > No, that would be complex(kind=8). Ah, I've mixed that with complex*16, which apparently is the same thing as complex(kind=8). Fixed

[Ping ^ 2] [PATCH] Fix PR 61225

Ping ^2? Thanks! -Zhenqiang On 28 May 2014 15:02, Zhenqiang Chen wrote: > Ping? > > Thanks! > -Zhenqiang > > On 22 May 2014 17:52, Zhenqiang Chen wrote: >> On 21 May 2014 20:43, Steven Bosscher wrote: >>> On Wed, May 21, 2014 at 11:58 AM, Zhenqiang Chen wrote: Hi, The patch fixe

Re: [fortran,patch] Fix Cray pointers in modules

Dear Francois-Xavier, The patch and the logic behind it, including the name dependence, is fine. OK for trunk and, I suggest, 4.9 and 4.8 after a suitable delay. Thanks! Paul On 8 June 2014 18:40, FX wrote: > The attached one-line patch fixes PR45187 > (https://gcc.gnu.org/bugzilla/show_bug.