Hi Jakub,
The test cases gcc.dg/vect/vect-simd-clone-10.c and
gcc.dg/vect/vect-simd-clone-12.c keep failing on my i686-pc. I do not really
understand why. The problem seem to be the command line to xgcc has
-S and -o and two .c files, probably the test case is not supported at all
on this target,
Hi
On 12/gen/2014, at 01:48, Tim Shen timshe...@gmail.com wrote:
Here're 4 patches that finally led the _Compiler's instantiation and
some other optimization for compiling time.
1) Create class _ScannerBase to make _Scanner pithier. Move const
static members to src/c++11/regex.cc.
2)
On Sun, Jan 12, 2014 at 10:53:58AM +0100, Bernd Edlinger wrote:
The test cases gcc.dg/vect/vect-simd-clone-10.c and
gcc.dg/vect/vect-simd-clone-12.c keep failing on my i686-pc. I do not really
understand why. The problem seem to be the command line to xgcc has
-S and -o and two .c files,
2014/1/11 Mikael Morin mikael.mo...@sfr.fr:
Le 09/01/2014 16:30, Janus Weil a écrit :
Hi all,
the attached patch started out as an ICE-on-invalid regression fix,
but after the ICE had been fixed recently by other means, it was
degraded to a mere error-recovery improvement. It removes some
However, I don't quite see the necessity for changing the module
format (apart from the fact that it makes your patch slightly
simpler).
I think it should otherwise reading old module gives
Expected left parenthesis.
Cheers,
Dominique
On Fri, Jan 10, 2014 at 4:45 PM, Tom de Vries tom_devr...@mentor.com wrote:
On 09-01-14 13:33, Richard Biener wrote:
On Thu, 9 Jan 2014, Tom de Vries wrote:
On 09-01-14 10:16, Richard Biener wrote:
This fixes PR59715 by splitting critical edges again before
code sinking. The critical
Jeff Law l...@redhat.com wrote:
It's been so long since I did anything with our web pages, I'm not
entirely sure of proper procedures anymore.
Gerald, this look OK?
Basically. ;-)
Per http://gcc.gnu.org/codingconventions.html, should it be run time?
And add a /li at the end if the item.
If
On Fri, Jan 10, 2014 at 6:37 PM, Richard Henderson r...@redhat.com wrote:
On 01/09/2014 03:34 PM, Jakub Jelinek wrote:
2014-01-09 Jakub Jelinek ja...@redhat.com
* target-globals.c (save_target_globals): Allocate 4KB structs using
GC in payload of target_globals struct instead
On Fri, Jan 10, 2014 at 9:41 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
split_data_refs_to_components used the name_expansions affine cache
through determine_offset, and since my patch uses it even more often,
but if it returns NULL, we don't free the cache and it can contain garbage
next
This is a regression present on all active branches for 8-bit/16-bit targets
and introduced by the rewrite of build_int_cst which now truncates its output.
Tested on x86_64-suse-linux, applied on all active branches.
2014-01-12 Eric Botcazou ebotca...@adacore.com
PR ada/59772
On Sun, Jan 12, 2014 at 02:24:22PM +0100, Richard Biener wrote:
Uh. Is this also applicable to branches?
In theory yes, I don't have a testcase that can trigger it though.
I'll apply it to 4.8 soon.
2014-01-10 Jakub Jelinek ja...@redhat.com
PR tree-optimization/59745
This patch fixes the cause of the following build output during a
non-bootstrap build:
make[2]: Entering directory
`/home/patrick/code/gcc-build/x86_64-unknown-linux-gnu/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
# Early copyback; see all above for the
On Sun, Jan 12, 2014 at 02:23:21PM +0100, Richard Biener wrote:
On Fri, Jan 10, 2014 at 6:37 PM, Richard Henderson r...@redhat.com wrote:
On 01/09/2014 03:34 PM, Jakub Jelinek wrote:
2014-01-09 Jakub Jelinek ja...@redhat.com
* target-globals.c (save_target_globals): Allocate 4KB
On Sun, 12 Jan 2014 12:01:43, Jakub Jelinek wrote:
On Sun, Jan 12, 2014 at 10:53:58AM +0100, Bernd Edlinger wrote:
The test cases gcc.dg/vect/vect-simd-clone-10.c and
gcc.dg/vect/vect-simd-clone-12.c keep failing on my i686-pc. I do not really
understand why. The problem seem to be the
This patch provides for interpreting element numbers for the Altivec
vec_insert and vec_extract intrinsics as big-endian (left to right in a
vector register) when targeting a little endian machine and specifying
-maltivec=be. New test cases are added to test this functionality on
all supported
Hello,
On 11 Jan 12:42, Uros Bizjak wrote:
On Fri, Jan 10, 2014 at 5:24 PM, Jakub Jelinek ja...@redhat.com wrote:
This means you should ensure aligned_mem will be set for
CODE_FOR_avx512f_movntdqa in ix86_expand_special_args_builtin.
Fixed. Updated patch in the bottom.
Leaving the rest of
On 01/10/14 14:52, Jakub Jelinek wrote:
There is one thing I still worry about, if some target has
an insn to say sign extend or zero extend a short memory load
into HARD_REGNO_NREGS () 1 register, but the other involved
register has the only one (or fewer) hard registers available to it.
On 01/11/14 02:07, Jakub Jelinek wrote:
On Sat, Jan 11, 2014 at 05:02:26PM +0800, Bin.Cheng wrote:
I reduced the case and attached ivopt dumps with/without the patch.
It seems the patch is doing right thing and choosing better
candidates, most likely it reveals an existing bug.
I am looking
On 01/11/14 02:21, Bin.Cheng wrote:
On Sat, Jan 11, 2014 at 5:07 PM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Jan 11, 2014 at 05:02:26PM +0800, Bin.Cheng wrote:
I reduced the case and attached ivopt dumps with/without the patch.
It seems the patch is doing right thing and choosing better
On Mon, Jan 13, 2014 at 2:29 PM, Jeff Law l...@redhat.com wrote:
On 01/11/14 02:21, Bin.Cheng wrote:
On Sat, Jan 11, 2014 at 5:07 PM, Jakub Jelinek ja...@redhat.com wrote:
On Sat, Jan 11, 2014 at 05:02:26PM +0800, Bin.Cheng wrote:
I reduced the case and attached ivopt dumps with/without the
On Sun, Jan 12, 2014 at 11:21:59PM -0700, Jeff Law wrote:
--- a/gcc/ree.c
+++ b/gcc/ree.c
@@ -297,6 +297,13 @@ combine_set_extension (ext_cand *cand, rtx curr_insn,
rtx *orig_set)
else
new_reg = gen_rtx_REG (cand-mode, REGNO (SET_DEST (*orig_set)));
+ /* We're going to be
21 matches
Mail list logo
