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
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
> > 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'
> 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
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
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
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
> 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
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;
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
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
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/
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
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
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
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
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
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
>
> - 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
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
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
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
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
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
OK.
Jason
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
26 matches
Mail list logo
