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 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) Make _Compiler
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, pr
2014/1/11 Mikael Morin :
>
>
> 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 rather
> 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 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 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 at the end if the item.
If anything else n
On Fri, Jan 10, 2014 at 6:37 PM, Richard Henderson wrote:
> On 01/09/2014 03:34 PM, Jakub Jelinek wrote:
>> 2014-01-09 Jakub Jelinek
>>
>> * target-globals.c (save_target_globals): Allocate < 4KB structs using
>> GC in payload of target_globals struct instead of allocating them on
>
On Fri, Jan 10, 2014 at 9:41 PM, Jakub Jelinek 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 time we pe
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
PR ada/59772
* gcc-interface/cuin
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
> >
> > PR tree-optimization/59745
> > * tree-p
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 rational
On Sun, Jan 12, 2014 at 02:23:21PM +0100, Richard Biener wrote:
> On Fri, Jan 10, 2014 at 6:37 PM, Richard Henderson wrote:
> > On 01/09/2014 03:34 PM, Jakub Jelinek wrote:
> >> 2014-01-09 Jakub Jelinek
> >>
> >> * target-globals.c (save_target_globals): Allocate < 4KB structs
> >> using
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 vec
Hello,
On 11 Jan 12:42, Uros Bizjak wrote:
> On Fri, Jan 10, 2014 at 5:24 PM, Jakub Jelinek 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 review to
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.
Consi
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 into
On 01/11/14 02:21, Bin.Cheng wrote:
On Sat, Jan 11, 2014 at 5:07 PM, 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
On Mon, Jan 13, 2014 at 2:29 PM, Jeff Law wrote:
> On 01/11/14 02:21, Bin.Cheng wrote:
>>
>> On Sat, Jan 11, 2014 at 5:07 PM, 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.
>>>
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
21 matches
Mail list logo
