Thanks! Can you attach the patch file for the proposed change?
David
On Fri, Nov 1, 2013 at 2:08 PM, Rong Xu wrote:
> libgcov.c is the main file to generate libgcov.a. This single source generates
> 21 object files and then archives to a library. These objects are of
> very different purposes bu
The middle-end currently marks all the sync builtins as nothrow. That
is incorrect for most of them when using -fnon-call-exceptions. The
-fnon-call-exceptions option means that instructions that trap may throw
exceptions. Most of the sync builtins access memory via pointers passed
by user code.
Hi,
This patch contains two more fixes related to the multiply even/odd
problem. First, it changes the mulv4si3 pattern so that it always uses
the vmulouh (vector multiply odd halfword) instruction regardless of
endianness. The reason for this is that we are not really multiplying
halfwords, but
Hi,
This patch fixes the widening multiply high/low operations to work
correctly in the presence of the first patch of this series, which
reverses the meanings of multiply even/odd instructions. Here we
reorder the input operands to the vector merge low/high instructions.
The general rule is tha
Hi,
This patch reverses the meanings of multiply even/odd instructions for
little endian. Since these instructions use a big-endian idea of
evenness/oddness, the nominal meanings of the instructions is wrong for
little endian.
Bootstrapped and tested with the rest of the patch set on
powerpc64{,
Hi,
This set of patches addresses the problem with vector multiply even/odd
instructions in little endian mode that I incorrectly attempted to
address as part of expand_mult_highpart. (Thanks to Richard Sandiford
for setting me on the right path.)
The first patch fixes the root problem wherein t
On Nov 3, 2013, at 12:58 PM, Iain Sandoe wrote:
> The Objective C/C++ exceptions model is, currently, completely determined by
> the combination of runtime {gnu, next} and ABI {m32/V1, m64/V2}.
> OK for trunk?
Ok.
Hi,
The IVOPT in GCC has a problem that it does not use cost of auto-increment
address expression in accounting, while it retreats to cost of address
expression if auto-increment addressing mode is unavailable.
For example, on ARM target:
1) the cost of "[reg]" (which is 6) is used for address exp
On 2013-11-03 12:19, Jonathan Wakely wrote:
On 3 November 2013 09:49, Andreas Schwab wrote:
Jonathan Wakely writes:
+ {
+std::experimental::optional o { std::experimental::in_place,
0x1234ABCDF1E2D3C4 };
+auto copy = o;
+VERIFY( copy );
+VERIFY( *copy == 0x1234ABCDF1E2D3C4 )
Hello,
This patch forces options Wa, Wl, Wp, to take a mandatory argument,
which can fix the bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55651.
Tested on i686-pc-linux-gnu.
2013-11-04 Mingjie Xing
* common.opt (Wa, Wl, Wp,): Change JoinedOrMissing to Joined.
Is it OK?
Mingjie
I
> Ping. Is it ok for x86 maintainer?
I tought I already approved the x86 bits.
>
> Thanks,
> Wei Mi.
>
> On Wed, Oct 16, 2013 at 4:25 PM, Wei Mi wrote:
> >> Go ahead and consider that pre-approved. Just send it to the list with a
> >> note that I approved it in this thread.
> >>
> >> Jeff
> >
On 29/10/13 14:54, Jakub Jelinek wrote:
> +/* Return true if all imm uses of VAR are either in STMT, or
> + feed (optionally through a chain of single imm uses) GIMPLE_COND
> + in basic block COND_BB. */
> +
> +static bool
> +all_imm_uses_in_stmt_or_feed_cond (tree var, gimple stmt, basic_bloc
Hi,
my recent fix for c++/29234 fixed this one too, I'm adding the testcase
and closing the bug.
Thanks,
Paolo.
/
2013-11-03 Paolo Carlini
PR c++/52071
* g++.dg/parse/pr52071.C: New.
Index: g++.dg/parse/pr52071.C
Hi,
expand_set_or_movmem_prologue_epilogue_by_misaligned has
rtx saveddest = *destptr;
gcc_assert (desired_align <= size);
/* Align destptr up, place it to new register. */
*destptr = expand_simple_binop (GET_MODE (*destptr), PLUS,
*destptr,
Hi Ian,
On Sun, 3 Nov 2013, Iain Sandoe wrote:
> The option is apparently undocumented in the current User's manual,
> hence, there are no adjustments to documentation.
I cannot approve the patch, but if it goes in that way or a similar
one I recommend to add a short note to htdocs/gcc-4.9/chan
On 29 October 2013 10:38, Ramana Radhakrishnan wrote:
> On 10/24/13 00:04, Kugan wrote:
>>
>> Hi,
>>
>> arm testcases neon-vcond-ltgt.c and neon-vcond-unordered.c fails in
>> Linaro 4.8 branch. It is not reproducable with trunk but it can happen.
>> Both neon-vcond-ltgt.c and neon-vcond-unordered.
OK.
Jason
Hi,
I've been trying to improve the building and testing of Darwin for crosses and
native crosses.
This has thrown up a few small glitches in the Ada build stuff (that would seem
to apply to any build-host-nativeX scenario, not just darwin). I would imagine
it would be beneficial to resolve t
The Objective C/C++ exceptions model is, currently, completely determined by
the combination of runtime {gnu, next} and ABI {m32/V1, m64/V2}.
Thus, the "-fobjc-sjlj-exceptions" command line option is redundant and may be
removed.
(note that trunk clang doesn't even accept the option, although xc
On Sun, Nov 3, 2013 at 2:29 PM, Kenneth Zadeck wrote:
> Vax, seriously??? Are there any left?
Maybe. Maybe not. But there are decent VAX simulators, and Linux,
NetBSD, and OpenBSD have been ported to VAX.
Remember they were still building VAX machines in 2005, when e.g.
Alpha and HP-PA were alre
Hi,
I had a look to this very old parsing issue and having studied it a bit,
I decided that it could make sense to attack it directly, thus basing
directly on the note in Bugzilla left by Jason: enforce that the
declaration of a constructor of T actually names T! Testsuite passes
smoothly on
Hi!
On 30 Oct 2013, at 20:55, Joseph S. Myers wrote:
> On Wed, 30 Oct 2013, Tobias Burnus wrote:
>
>> On the other hand, one could use the existence of libcilkrts* as detected by
>> the patch to decide whether to link or not: If the library is there, one can
>> link – if not found, it is unlikely
Latest results for gcc 4.8.x.
-tgc
Testresults for 4.8.2
arm-unknown-linux-gnueabi
i386-pc-solaris2.9
i686-pc-linux-gnu (2)
i686-unknown-linux-gnu
mips-unknown-linux-gnu
mipsel-unknown-linux-gnu
powerpc-apple-darwin8.11.0
powerpc-unknown-linux-gnu
sparc-sun-solaris2.9
sparc64-
Hello!
Attached patch defines _SOFT_FLOAT internal define for !TARGET_80387
for all x86 targets, similar to what RTEMS has been doing. This define
can be used to disable various parts af hardware FPU support in
libgcc, when -mno-80387 a.k.a. -soft-float is in effect. Please also
see the thread, st
Vax, seriously??? Are there any left?
On Nov 3, 2013, at 5:24 AM, Richard Sandiford
wrote:
> Installed as obvious.
>
> Richard
>
>
> Index: gcc/config/vax/vax.c
> ===
> --- gcc/config/vax/vax.c2013-11-03 10:24:01.013238719
2013/11/3 Richard Sandiford :
> The __builtin_avr_insert_bits code uses a double_int to handle the mask,
> but AIUI the mask has exactly 32 bits. Is that right? If so, would it be
> OK to use "unsigned int" instead? I realise this might seem like pointless
> churn, but it would help out with the
The __builtin_avr_insert_bits code uses a double_int to handle the mask,
but AIUI the mask has exactly 32 bits. Is that right? If so, would it be
OK to use "unsigned int" instead? I realise this might seem like pointless
churn, but it would help out with the wide_int conversion.
Doing this also
On 11/03/2013 12:19 PM, Jonathan Wakely wrote:
Yes, Paolo pointed out these are failing on 32-bit targets, I've got a
patch coming. Luc is there any reason not to just replace all those
large constants with 0x1234ABCD, which fits in a long on 32-bit targets?
By the way, that's what I did/hacke
On 3 November 2013 09:49, Andreas Schwab wrote:
> Jonathan Wakely writes:
>
>> + {
>> +std::experimental::optional o { std::experimental::in_place,
>> 0x1234ABCDF1E2D3C4 };
>> +auto copy = o;
>> +VERIFY( copy );
>> +VERIFY( *copy == 0x1234ABCDF1E2D3C4 );
>> +VERIFY( o && o ==
When going through force_fit_type calls to see whether they were
extending correctly, I noticed some of the calls in VRP could be simplified.
There's no change in behaviour, it's just shorter and more efficient.
Tested on powerpc64-linux-gnu and x86_64-linux-gnu. OK to install?
Thanks,
Richard
Hello,
on i686-pc-linux-gnu the test case gcc.target/i386/intrinsics_4.c fails because
of
an internal compiler error, see PR58155.
The reason for this is that the optab CODE_FOR_movv8sf is disabled when it
should be enabled.
This happens because invoke_set_current_function_hook changes the poin
Installed as obvious.
Richard
Index: gcc/config/vax/vax.c
===
--- gcc/config/vax/vax.c2013-11-03 10:24:01.013238719 +
+++ gcc/config/vax/vax.c2013-11-03 10:24:02.308247979 +
@@ -643,7 +643,7 @@ vax_float_lite
...since I'd forgotten to update it when doing the wi:: stuff.
Installed as obvious.
Richard
Index: gcc/config/sparc/sparc.c
===
--- gcc/config/sparc/sparc.c2013-11-03 10:04:56.004019113 +
+++ gcc/config/sparc/sparc.c20
Installed as obvious.
Richard
Index: gcc/config/msp430/msp430.c
===
--- gcc/config/msp430/msp430.c 2013-11-03 10:04:56.004019113 +
+++ gcc/config/msp430/msp430.c 2013-11-03 10:19:04.928118621 +
@@ -1058,7 +1058,7 @@ msp430
Hello!
There is no point to access FP hardware for soft-float targets.
2013-11-03 Uros Bizjak
* config/i386/crtfastmath.c: Compile only for !_SOFT_FLOAT.
* config/i386/crtprec.c: Ditto.
Tested on x86_64-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: config/i386/crtfastmath.c
So, Jan, what do you think will be best solution for stage 1?
Thanks,
Igor
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Vladimir Makarov
> Sent: Monday, October 21, 2013 6:52 AM
> To: Jan Hubicka; Zamyatin, Igor; gcc-pat
Jonathan Wakely writes:
> + {
> +std::experimental::optional o { std::experimental::in_place,
> 0x1234ABCDF1E2D3C4 };
> +auto copy = o;
> +VERIFY( copy );
> +VERIFY( *copy == 0x1234ABCDF1E2D3C4 );
> +VERIFY( o && o == 0x1234ABCDF1E2D3C4 );
> + }
experimental/optional/cons/
37 matches
Mail list logo
