On 12/24/2015 12:57 PM, Patrick Palka wrote:
So instead, this patch
takes the easier route and just adds preparatory logic to decay these
dependent array parameter types where necessary so that by the time
unify() is called it will be looking at two decayed T * types. There
only seem to be
In this testcase, the exception specification for the implicitly-defined
copy constructor for Foo depends on which function<...> constructor it
calls; when figuring that out we consider the template constructor as a
possible candidate, and substituting into the default template argument
ends
This check is not relevant anymore. Removing.
gcc/ChangeLog:
2015-12-24 hiraditya
* sese.h (bb_in_region): Remove dead code.
---
gcc/sese.h | 14 --
1 file changed, 14 deletions(-)
diff --git a/gcc/sese.h b/gcc/sese.h
index 99df354..f7e5570 100644
---
On Dec 22, 2015, at 3:24 AM, Richard Earnshaw (lists)
wrote:
>
>> In theory what I want to be able to do is build all the listed targets
>> and run a single test on them so that we can build these skip/xfail
>> lists much easier.
>>
>> I've done it a few times by hand
On Dec 22, 2015, at 8:00 AM, Alan Lawrence wrote:
> On 21/12/15 15:33, Bill Schmidt wrote:
>>>
>>> Not on a stage1 compiler - check_p8vector_hw_available itself requires being
>>> able to run executables - I'll check on gcc112. However, both look like
>>> they're
>>>
On Thu, Dec 24, 2015 at 04:53:30PM +0200, Janne Blomqvist wrote:
> On Thu, Dec 24, 2015 at 1:18 AM, Steve Kargl
> wrote:
> > On Thu, Dec 24, 2015 at 12:29:02AM +0200, Janne Blomqvist wrote:
> >>
> >> the GFortran random number generator (RANDOM_NUMBER and
On Dec 22, 2015, at 9:13 AM, Peter Bergner wrote:
> PR target/68772
No, this is wrong. Compare to 68872 in the subject line.
> * config/rs6000/rs6000.h (ASM_CPU_SPEC): For -mcpu=powerpc64le,
> pass %(asm_cpu_power8)/-mpwr8.
> *
GFortran's scanner appears to go into an infinite loop if you try to
pass a directory to 'include'. This patch will check for a directory
using stat() after fopen() has verified its existence.
I'm assuming stat() will be OK to call here since add_path_to_list uses
it. I've only been able to
Description:
2015-12-11 Tsvetkova Alexandra
* libmpxwrap/mpx_wrappers.c (__mpx_wrapper_memmove): separate
case for size of pointer.
On Thu, Dec 24, 2015 at 2:21 PM, Aleksandra Tsvetkova
wrote:
> This patch was tested on spec2000,
> On December 23, 2015 5:58:07 PM GMT+01:00, Uros Bizjak
> wrote:
> >On Wed, Dec 23, 2015 at 2:39 PM, Richard Biener
> > wrote:
> >> On December 23, 2015 10:39:17 AM GMT+01:00, Uros Bizjak
> > wrote:
> >>>Hello!
> >>>
> >>>There
This version changes the test cases to fix failures on some platforms, by
rewriting the initializers so that they aren't pushed out to the constant pool.
gcc/ChangeLog:
* tree-ssa-scopedtables.c (avail_expr_hash): Hash MEM_REF and ARRAY_REF
using get_ref_base_and_extent.
On December 24, 2015 11:15:52 AM GMT+01:00, Jan Hubicka wrote:
>> On December 23, 2015 5:58:07 PM GMT+01:00, Uros Bizjak
> wrote:
>> >On Wed, Dec 23, 2015 at 2:39 PM, Richard Biener
>> > wrote:
>> >> On December 23, 2015 10:39:17 AM
gcc/ChangeLog:
2015-12-24 hiraditya
* graphite-sese-to-poly.c (build_loop_iteration_domains): Use ref
instead of value.
* sese.c (invariant_in_sese_p_rec): Use const ref instead of value.
(scalar_evolution_in_region): Same
* sese.h
Here's a new version that fixes the gcc.dg/guality/pr54970.c failures seen on
aarch64 and powerpc64. Prior to SRA handling constant pool decls,
-fdump-tree-esra-details (at -O1 -g) had shown:
:
a = *.LC0;
# DEBUG a$0 => MEM[(int[3] *)&*.LC0]
a$4_3 = MEM[(int[3] *)&*.LC0 + 4B];
# DEBUG
This patch was tested on spec2000, spec2006 and make check. It fixes
regression on vortex.
2015-12-11 Tsvetkova Alexandra
* libmpxwrap/mpx_wrappers.c (mpx_pointer): New type.
diff --git a/libmpx/mpxwrap/mpx_wrappers.c b/libmpx/mpxwrap/mpx_wrappers.c
old mode
On 23/12/15 18:35 +0100, Torvald Riegel wrote:
It's possible we can make this work for the old ABI too, but this is
OK for now. The old ABI always uses COW strings, but that's what the
code you've written deals with anyway.
OK. I would have to write the wrappers for the new strings too then,
On 23/12/15 15:56 -0500, Jason Merrill wrote:
On 12/23/2015 12:35 PM, Torvald Riegel wrote:
+//#if !defined (HAVE_ELF_STYLE_WEAKREF)
Can I assume weak refs to be supported, or how do I check for whether
they are? What's your preference?
G++ does support targets without weak symbols, but I
On Thu, Dec 24, 2015 at 12:57 PM, Richard Biener
wrote:
> On December 24, 2015 11:15:52 AM GMT+01:00, Jan Hubicka
> wrote:
>>> On December 23, 2015 5:58:07 PM GMT+01:00, Uros Bizjak
>> wrote:
>>> >On Wed, Dec 23, 2015 at 2:39 PM,
On Thu, Dec 24, 2015 at 11:15 AM, Jan Hubicka wrote:
>> On December 23, 2015 5:58:07 PM GMT+01:00, Uros Bizjak
>> wrote:
>> >On Wed, Dec 23, 2015 at 2:39 PM, Richard Biener
>> > wrote:
>> >> On December 23, 2015 10:39:17 AM
On Thu, Dec 24, 2015 at 1:18 AM, Steve Kargl
wrote:
> On Thu, Dec 24, 2015 at 12:29:02AM +0200, Janne Blomqvist wrote:
>>
>> the GFortran random number generator (RANDOM_NUMBER and RANDOM_SEED
>> intrinsics) has a number of issues that the attached preliminary
20 matches
Mail list logo