[Patch, libgomp, committed] F2015 fix for testsuite/libgomp.fortran/pr34020.f90 (was: [Patch, Fortran] Add library support for coarray's atomic intrinsics)

Dominique Dhumieres wrote: This probably caused /opt/gcc/work/libgomp/testsuite/libgomp.fortran/pr34020.f90:16.24: call atomic_add(lhs, rhs) 1 Error: ATOM argument at (1) to intrinsic function atomic_add shall be an integer of ATOMIC_INT_KIND I have fixed the

Re: [PATCH] PR C++/60209 - Declaration of user-defined literal operator cause error

OK. Jason

Patch for constexpr variable templates

Here is a patch that expands on Gabriel Dos Reis's initial var-template patch ( https://gcc.gnu.org/ml/gcc-patches/2013-03/msg01295.html ). I just noticed now that those patches were committed to a branch, so if need be I can resubmit the patch with Gaby's changes not included. The purpose of

Re: [PATCH] libstdc++: add uniform on sphere distribution

On Sat, Jul 12, 2014 at 10:00 PM, Ulrich Drepper wrote: > The patch is tested against the current tree without causing additional > problems. > > OK? Ignore the values.cc test case, it's a left-over from copying existing tests and modifying them for a new distribution. This test does not apply t

[PATCH] libstdc++: add uniform on sphere distribution

Ed's submission of the logistic regression distribution caused problems for me because, like Ed, I have changes to the header in my tree for a long time. Time to submit them. This first one is a new distribution. It generates coordinates for random points on a unit sphere in arbitrarily many di

Re: [patch] Hide the caret for -Wstack-usage

On 12 July 2014 03:39, Eric Botcazou wrote: >> Your patch hides the caret but the location still points to the >> closing brace (so if you use an IDE like emacs this is where you will >> go). >> >> Is there a location for the definition? Could we store/pass one to this >> point? >> >> Otherwise, w

[Patch, Fortran] Add library support for coarray's atomic intrinsics

This probably caused /opt/gcc/work/libgomp/testsuite/libgomp.fortran/pr34020.f90:16.24: call atomic_add(lhs, rhs) 1 Error: ATOM argument at (1) to intrinsic function atomic_add shall be an integer of ATOMIC_INT_KIND Dominique

Re: [RFC][ARM] TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook

> > - if (!TARGET_VFP) > -return; > + if (!TARGET_VFP || TARGET_THUMB1) > +return default_atomic_assign_expand_fenv (hold, clear, update); > > You don't need to call default function here. It is empty, the > documentation says: > > "The default implementation leaves all three expressio

[PATCH] PR preprocessor/23827 - standard C++ should not have hex float preprocessing tokens

Greetings, This old bug involved C++98 accepting hex floats without complaint. I also split the error messages between C and C++ like in the recent PR 61389 patch. Bootstrapped and tested clean on x86_64-linux. OK? libcpp/ 2014-07-12 Edward Smith-Rowland <3dw...@verizon.net> PR

[Patch, Fortran, committed] Fix Fortran bug affecting MinGW-w64, only

64bit Windows is special as "long" is only 32bit wide - while pointers are 64bit and, hence, wider. Another special code is gfortran's array descriptor. Its "dtype" field is of type ptrdiff_t and it stores the array rank and type in the first 6 bits and uses the remaining size to store the byt

Re: [Bug fortran/61780] [4.8/4.9/4.10 Regression] Wrong code when shifting elements of a multidimensional array

Dear All, Committed to trunk as revision 212486. Cheers Paul On 12 July 2014 20:52, Tobias Burnus wrote: > Dear Paul, > > the patch attached to the PR looks good to me for GCC 4.8, 4.9 and 4.10. For > 4.9.1 vs. 4.9.2, it's Jakub's call. > > Tobias > > > Paul Richard Thomas wrote: >> >> Dear

Re: [Patch, Fortran] Update atomics support for TS18508

Dear Tobias, OK for trunk. Thanks for the patch. Paul On 11 July 2014 23:30, Tobias Burnus wrote: > This patch updates the atomic support for TS18508, namely: > – The atomic intrinsics now take a STAT= argument > – Add the new atomics atomic_{add,and,or,xor} and their fetch variants > atomic_f

Re: [Patch, Fortran] Add library support for coarray's atomic intrinsics

Dear Tobias, That's good for trunk. Thanks for the patch. Paul On 12 July 2014 17:05, Tobias Burnus wrote: > This patch is relative to the still unreviewed patch > https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00864.html > > With this patch, all of Fortran 2008's and TS18508's atomics should b

C++ PATCH for c++/61288 (valgrind error with ?:)

We shouldn't indirect through conv2/conv3 after the obstack_free. Tested x86_64-pc-linux-gnu, applying to trunk. commit 6e4f0317fabeefaac3107707112f433ddb673062 Author: Jason Merrill Date: Fri Jul 11 17:20:32 2014 -0400 PR c++/61288 * call.c (build_conditional_expr_1): Avoid reading

[PATCH] PR C++/60209 - Declaration of user-defined literal operator cause error

PING! Support operator"" ""(...) per CWG 1473. This brings full string parsing to literal operator declarations including string chunk concatenation and appropriate errors. Bootstrapped and tested on x86_64-linux. OK? I'm less sure if this is appropriate for 4.9 even when it opens. cp/

[PATCH] Generate canonical infinity for the Motorola extended real format

This patch fixes encode_ieee_extended_motorola to generate the canonical infinity matching the bit pattern generated by the fpu (in the Motorola variant of the extended real format the integer bit is ignored on input and cleared on output, unlike the Intel variant). This fixes the ieee/copysign[12

[Patch, Fortran] Add library support for coarray's atomic intrinsics

This patch is relative to the still unreviewed patch https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00864.html With this patch, all of Fortran 2008's and TS18508's atomics should be supported with both -fcoarray=single and =lib (with libcaf_single). Still missing is the support in the MPI and G

[GSoC] generation of Gimple code from isl_ast_node_user

I've attached the patch, which contains generation of Gimple code from isl_ast_node_user. I think that it would be better to add motivation for the following line from the original source: if (GBB_BB (gbb) == ENTRY_BLOCK_PTR_FOR_FN (cfun)) { isl_ast_expr_free (user_expr); return next_e;

Re: [patch] Hide the caret for -Wstack-usage

> Your patch hides the caret but the location still points to the > closing brace (so if you use an IDE like emacs this is where you will > go). > > Is there a location for the definition? Could we store/pass one to this > point? > > Otherwise, would it be appropriate to point to the declaration

Re: [GSoC] generation of Gimple loops with empty bodies

On x86_64-apple-darwin13, the test gcc.dg/graphite/isl-codegen-loop-dumping.c gives an ICE with -m32 after r212455. The backtrace is * thread #1: tid = 0xdac306, 0x000100523c52 cc1`fold_binary_loc(loc=0, code=MINUS_EXPR, type=0x, op0=0x000142c09bd0, op1=0x000142c1b048

[PATCH 2/3, Cilk+] Fix for PR61455

Hi! This patch adds correct handling of declarations whit initializations that contain array notation. It fixes ICE in PR61455. Regtested for x86_64 (along with the first patch in the chain). Ok for trunk/4.9? Thanks, Igor gcc/c-family/ChangeLog: 2014-07-08  Igor Zamyatin  PR midd

[PATCH 1/3, Cilk+] Fix for PR61455

Hi! This simple change fixes the issue with printing of error message (happened in unprintable_error routine of the PR's test) Regtested with the next patch of this chain. Ok for trunk/4.9? Thanks, Igor gcc/cp/Changelog: 2014-07-08  Igor Zamyatin  * cp-array-notation.c (expand_an_in_m

Re: [PATCH] Generate more efficient memory barriers for LEON3

> That was an error on my side. The wrong memory model had gotten cached > in a generated make script. Lets drop membar_leon3 also then :) Fine with me but, on second thoughts, if a mere "stb" is a #StoreLoad memory barrier for LEON3, doesn't this simply mean that the memory model of the LEON3 i

Re: [patch 1/4] change specific int128 -> generic intN

> > What are GET_MODE_BITSIZE and GET_MODE_PRECISION for PSImode? > > It *should* be 20 and 20 for msp430. But GET_MODE_BITSIZE returns 32, > because it's a macro that does GET_MODE_SIZE * BITS_PER_UNIT, so it > cannot return 20. No, it should not be 20, mode sizes are multiple of the unit, you'

[PATCH, i386]: Optimize ix86_atomic_assign_expand_fenv a bit

Hello! Attached patch optimizes ix86_atomic_assign_expand_fenv by using register form of "fnstsw %ax" instead of "fnstsw ". This way a memory RW cycle is removed for a temporary. 2014-07-12 Uros Bizjak * config/i386/i386-builtin-types.def: Add USHORT_FTYPE_VOID. Remove VOID_FTYPE_PUSH

Re: [RFC][ARM] TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook

Hello! > 2014-06-10 Kugan Vivekanandarajah > > * config/arm/arm.c (arm_atomic_assign_expand_fenv): call > default_atomic_assign_expand_fenv for TARGET_THUMB1. > (arm_init_builtins) : Initialize builtins __builtins_arm_set_fpscr and > __builtins_arm_get_fpscr only when !TARGET_THUMB1. > * config