Hi,
This is a ping for: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01328.html
OK for the trunk? Thanks.
Hi!
I've committed following cherry-pick from upstream. It is not a fully
solution for that PR, but does not hurt and let us move to other
libsanitizer build failures on aarch64 (and with those fixed/worked around
just to find out that asan doesn't work at all on aarch64).
2015-01-19 Jakub Jeli
On Fri, Jan 16, 2015 at 8:42 PM, Bernd Edlinger
wrote:
> Hi,
>
> On Fri, 16 Jan 2015 21:25:42, Dmitry Vyukov wrote:
>>
>> This is just a copy from llvm repo, right?
>> Looks good to me.
>>
>
> Thanks.
>
> Yes I found these test case in the llvm tree, and just adapted them
> to work in the gcc test
Long story short. Tsan has a logical data race the core of data race
detection algorithm. The race is not a bug, but a deliberate design
decision that makes tsan considerably faster. So ironically, if the
race memory accesses happen almost simultaneously, tsan can miss the
race.
Thus we have sleeps
Patch ping: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02258.html
Any comments, Richard? Thanks.
On Mon, Jan 19, 2015 at 12:43:39PM +0400, Dmitry Vyukov wrote:
> Hi Bernd,
>
> Yes, that email is marked in my inbox. Sorry for not answering earlier.
>
> I can't really make my mind on this. I would mildly prefer sleep's (if
> they work reliably!).
Sleeps by definition should not be reliable, n
On Thu, Jan 15, 2015 at 8:18 AM, Mike Stump wrote:
> On Jan 14, 2015, at 3:50 AM, Tejas Belagod wrote:
>> As agreed here (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971), please
>> can I reverse Andrew's patch
>> out(https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02916.html)?
>
> Ok.
>
> Unl
Status
==
The trunk is now in "Stage 4" which means it is open for regression
and documentation fixes only, like if it were a release branch.
Please concentrate on getting P1 bugs fixed and provide help in
confirming and analyzing UNCONFIRMED bugs. For non-primary,
non-secondary targets imp
On Fri, Jan 16, 2015 at 7:47 PM, David Malcolm wrote:
> On Thu, 2015-01-15 at 22:50 +0100, Richard Biener wrote:
>> On January 15, 2015 9:05:59 PM CET, David Malcolm
>> wrote:
>> >Release managers: given that this only touches the jit, and that the
>> >jit
>> >is off by default, any objections i
2015-01-16 19:58 GMT+03:00 Jeff Law :
> On 01/16/15 04:04, Ilya Enkovich wrote:
>>
>> Hi,
>>
>> Currently compiler emits an error in case of not instrumented call to
>> instrumented alwyas_inline function. It happens because when we inline
>> there is only instrumented version of function availabl
On 17/01/15 15:18, Gerald Pfeifer wrote:
On Friday 2015-01-09 15:24, Andreas Tobler wrote:
Committed. (r219388) Thanks.
Can this also go into the GCC 4.9 branch? That is (and will be
for a while) the latest release stream and the patch is pretty
much isolated to FreeBSD.
Also a note for the
Ian Lance Taylor writes:
> @@ -83,7 +83,7 @@
> #else /* !defined(USE_LIBFFI_CLOSURES) */
>
> void
> -makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl)
> +makeFuncFFI(const struct __go_func_type *ftyp, void *impl)
> {
>runtime_panicstring ("libgo built without FFI does
On 14/01/15 22:59, Richard Henderson wrote:
On 12/15/2014 07:36 AM, Jiong Wang wrote:
+ char buf[64];
+ uint64_t val = ((uint64_t) 1) << UINTVAL (operands[1]);
+ sprintf (buf, "tst\t%%0, %"PRId64, val);
+ output_asm_insn (buf, operands);
+ return "\t%l2";
Better to
On Mon, Jan 19, 2015 at 10:28:47AM +, Jiong Wang wrote:
> On 14/01/15 22:59, Richard Henderson wrote:
> >On 12/15/2014 07:36 AM, Jiong Wang wrote:
> >>+ char buf[64];
> >>+ uint64_t val = ((uint64_t) 1) << UINTVAL (operands[1]);
> >>+ sprintf (buf, "tst\t%%0, %"PRId64, val);
> >>+ outpu
On Mon, 12 Jan 2015, Richard Biener wrote:
>
> This "fixes" PR64535 by changing the fixed object size emergency pool
> to a variable EH object size (but fixed arena size) allocator. Via
> combining the dependent and non-dependent EH arenas this should allow
> around 600 bad_alloc throws in OOM s
On 19/01/15 10:34, Jakub Jelinek wrote:
On Mon, Jan 19, 2015 at 10:28:47AM +, Jiong Wang wrote:
On 14/01/15 22:59, Richard Henderson wrote:
On 12/15/2014 07:36 AM, Jiong Wang wrote:
+ char buf[64];
+ uint64_t val = ((uint64_t) 1) << UINTVAL (operands[1]);
+ sprintf (buf,
> What is aarch64 specific on the testcase?
The number of if-then-else's required to get the compiler to generate
branch sequences rather than the tbnz instruction.
Ramana
Hi Gerald,
> this feels a little too small for an announcement on our home
> page, but would you mind adding something to gcc-5/changes.html?
Sure.
> (Or suggest some wording for that page and I'll take care.)
Something like the attached patch ?
wwwdocs/htdocs/gcc-5/
* changes
On Mon, Jan 19, 2015 at 10:52:14AM +, Ramana Radhakrishnan wrote:
> > What is aarch64 specific on the testcase?
>
>
> The number of if-then-else's required to get the compiler to generate
> branch sequences rather than the tbnz instruction.
That doesn't mean the same testcase couldn't be te
On Sat, 17 Jan 2015, Kugan wrote:
>
> This patch propagate value range wrapps attribute and save this to
> SSA_NAME.
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 9b7695d..832c35d 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -103,6 +103,9 @@ struct value_range_d
tree min;
tree
> From: Andrew Pinski [mailto:pins...@gmail.com]
> Sent: Friday, January 16, 2015 6:03 PM
> >
> > +/* Defined in config/aarch64/fma_steering.c. */
> > +
> > +void
> > +aarch64_register_fma_steering (void);
>
>
> This is really bad form. Can you add a header file for this
> declaration and mayb
Ian Lance Taylor writes:
> On Thu, Jan 15, 2015 at 8:30 AM, Rainer Orth
> wrote:
>>
>> Apart from that, bootstrap fails in gotools: due to the use of
>> -static-libgo, all commands there fail to link since the socket
>> functions are missing. It seems like $LIBS from libgo needs to be added
>>
On 16 December 2014 at 11:26, Yangfei (Felix) wrote:
> The v3 patch attached fixed this minor issue. Thanks.
> +2014-12-13 Felix Yang
> + Haijian Zhang
> +
> + * gcc.target/aarch64/advsimd-intrinsics/compute-ref-data.h
> + (buffer_float64x2, buffer_pad_float64x2): New
On 16 January 2015 at 16:54, Kyrill Tkachov wrote:
> 2014-01-16 Kyrylo Tkachov
>
> PR target/64448
> * config/aarch64/aarch64-simd.md (aarch64_simd_bsl_internal):
> Match xor-and-xor RTL pattern.
OK /Marcus
On 19/01/15 08:53, Andrew Pinski wrote:
On Thu, Jan 15, 2015 at 8:18 AM, Mike Stump wrote:
On Jan 14, 2015, at 3:50 AM, Tejas Belagod wrote:
As agreed here (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971), please can
I reverse Andrew's patch
out(https://gcc.gnu.org/ml/gcc-patches/2014-1
Hi,
Even though I have bootstrapped and tested the autoprefetch patch before
checking it in, I missed the -mcpu=cortex-a15 setting, so I bootstrapped
without autoprefetch model being active. Turning the autoprefetch on revealed
an interesting bootstrap miscompare problem. I'm sorry I didn't s
On 17/01/15 23:09 -0800, Tim Shen wrote:
Bootstrapped and tested in trunk, but I guess it'll fit 4.9 branch
well. I'll do another test for 4.9 if it's appropriate to commit.
Thanks!
--
Regards,
Tim Shen
PR libstdc++/64649
* include/bits/regex.tcc (regex_traits<>::lookup_coll
On 17/01/15 16:06 -0800, Tim Shen wrote:
On Fri, Jan 16, 2015 at 4:12 AM, Jonathan Wakely wrote:
In that case, why bother using a unique_ptr initially, if it will just
have to allocate a shared_ptr control block later anyway? It's better
to use make_shared to reduce the number of allocations, i
On 16/01/15 23:38 +, Jonathan Wakely wrote:
This defines the C++11 header and adds the wstring_convert
and wbuffer_convert utilities.
I've discovered that wasn't the last piece of the C++11 library, there
were new constructors taking std::string added to std::locale and all
the std::xxx_by
On 16 January 2015 at 17:52, Christophe Lyon wrote:
>> OK provided, as per the previous couple, that we don;t regression or
>> introduce new fails on aarch64[_be] or aarch32.
>
> This patch shows failures on aarch64 and aarch64_be for vmax and vmin
> when the input is -NaN.
> It's a corner case,
On Mon, Jan 19, 2015 at 01:27:17PM +, Jonathan Wakely wrote:
> On 16/01/15 23:38 +, Jonathan Wakely wrote:
> >This defines the C++11 header and adds the wstring_convert
> >and wbuffer_convert utilities.
>
> I've discovered that wasn't the last piece of the C++11 library, there
> were new
On 16 January 2015 at 18:12, Christophe Lyon wrote:
> On 16 January 2015 at 16:20, Tejas Belagod wrote:
>> On 13/01/15 15:18, Christophe Lyon wrote:
>>>
>>>
>>> * gcc.target/aarch64/advsimd-intrinsics/vldX_dup.c: New file.
>>>
> Thanks, I should mention that this test fails on aarch64_b
On Mon, 19 Jan 2015, Maxim Kuvyrkov wrote:
> The underlying problem is that the order in which elements of ready_list are
> compared matters to the final result. This is because rank_for_schedule
> sorting heuristic establishes a partial order on the set of instructions,
> and it can happen that w
On 13 January 2015 at 15:18, Christophe Lyon wrote:
>
> * gcc.target/aarch64/advsimd-intrinsics/vmlX.inc: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vmla.c: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vmls.c: New file.
OK with the the vmlx poly ops dropped
On 13 January 2015 at 15:18, Christophe Lyon wrote:
>
> * gcc.target/aarch64/advsimd-intrinsics/vmlX_lane.inc: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vmla_lane.c: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vmls_lane.c: New file.
OK with Tejas' comment
On 16 January 2015 at 11:17, Jiong Wang wrote:
> exactly, thanks, we should use FAIL although DONE and FAIL work the same in
> this scenario.
>
> I checked their definition, FAIL always return the initial value of _val
> which is NULL,
> while DONE stop and return generated insns which for this p
On Jan 19, 2015, at 4:34 PM, Alexander Monakov wrote:
> On Mon, 19 Jan 2015, Maxim Kuvyrkov wrote:
>> The underlying problem is that the order in which elements of ready_list are
>> compared matters to the final result. This is because rank_for_schedule
>> sorting heuristic establishes a partial
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vmlXl.inc: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vmlal.c: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vmlsl.c: New file.
OK /Marcus
On 16 January 2015 at 18:10, Christophe Lyon wrote:
> On 16 January 2015 at 16:58, Tejas Belagod wrote:
>> On 13/01/15 15:18, Christophe Lyon wrote:
>>> * gcc.target/aarch64/advsimd-intrinsics/vshuffle.inc: New file.
>>> * gcc.target/aarch64/advsimd-intrinsics/vtrn.c: New file.
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vmlXl_lane.inc: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vmlal_lane.c: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vmlsl_lane.c: New file.
OK /Marcus
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vmlXl_n.inc: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vmlal_n.c: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vmlsl_n.c: New file.
OK /Marcus
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vqdmlXl.inc: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vqdmlal.c: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vqdmlsl.c: New file.
OK /Marcus
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vqdmlXl_lane.inc: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vqdmlal_lane.c: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vqdmlsl_lane.c: New file.
OK /Marcus
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vqdmlXl_n.inc: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vqdmlal_n.c: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vqdmlsl_n.c: New file.
OK /Marcus
On 16 January 2015 at 18:06, Tejas Belagod wrote:
>> +
>> +void vsri_extra(void)
>> +{
>> +/* Test cases with maximum shift amount (this amount is different
>> + * from vsli. */
>> +
>
>
> Nit. Comment Formatting. Similarly, few other places.
>
> Otherwise, LGTM.
>
> Tejas.
>
w.r.t the u
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vXXXl.inc: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vsubl.c: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vaddl.c: Use code from
> vXXXl.inc.
OK /Marcus
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vXXXw.inc: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vsubw.c: New file.
> * gcc.target/aarch64/advsimd-intrinsics/vaddw.c: Use code from
> vXXXw.inc.
OK /Marcus
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vmovn.c: New file.
OK /Marcus
On 19/01/15 02:48 +0200, Ville Voutilainen wrote:
Minor additions:
- add a comment to the #endif for the c++14 #if
- fix the doc comments to talk about reverse iterators
Thanks, I like the new comments more.
This passes the testsuite.
Posted during stage3 so OK for trunk.
diff --git a/lib
This fixes PR64313 - the match-and-simplify machinery has a hard
time re-doing the "magic" trick of re-using builtins in the matched IL
and thus fails to generate calls to builtins that are not marked
as builtin_decl_implicit_p.
The following patch fixes this by remembering whether the user
has d
On 01/15/2015 12:35 PM, Richard Biener wrote:
On Thu, Jan 15, 2015 at 12:29 PM, Jakub Jelinek wrote:
On Thu, Jan 15, 2015 at 12:17:44PM +0100, Richard Biener wrote:
On Thu, Jan 15, 2015 at 12:10 PM, Jakub Jelinek wrote:
Hi!
I ran into -Werror=maybe-uninitialized errors during profiledbootst
rs6000_output_function_epilogue performs a series of string comparisons
on language_string, with a
gcc_unreachable ();
if the language_string is unrecognized.
This leads to failure of any attempt to use libgccjit on rs6000, since
jit/dummy-frontend.c has:
#define LANG_HOOKS
Hi,
this is a second patch dealing with finalization-related regressions,
after the one I submitted yesterday
(https://gcc.gnu.org/ml/fortran/2015-01/msg00109.html), which btw is
also still waiting for review ...
This patch fixes an invalid memory reference inside the finalizer
routine (at runtim
While looking at PR target/64532- I realized we haven't documented all
the register constraints. I'm not documenting the other immediate
constraints as it is not clear to me how much of that is actually useful
yet and I don't have the time this afternoon to clean this up.
Built documentation a
On Mon, Jan 19, 2015 at 01:53:06AM -0500, Hans-Peter Nilsson wrote:
> On Mon, 8 Dec 2014, Segher Boessenkool wrote:
>
> > A lot of old user code clobbers the carry bit without telling the compiler
> > about it. This used to just work, because the compiler never used the bit
> > outside of a singl
On Monday 2015-01-19 11:56, Olivier Hainque wrote:
> Something like the attached patch ?
>
> wwwdocs/htdocs/gcc-5/
>
> * changes.html (Operating Systems section): Mention support
> of VxWorks MILS.
This looks sweet, thank you!
Gerald
On 16/01/15 15:06, Maxim Kuvyrkov wrote:
> @@ -1874,7 +1889,8 @@ const struct tune_params arm_cortex_a15_tune =
>true, true, /* Prefer 32-bit encodings.
> */
>true, /* Prefer Neon for
> stringops. */
>8,
On Jan 19, 2015, at 12:47 AM, Dmitry Vyukov wrote:
> Long story short. Tsan has a logical data race the core of data race
> detection algorithm. The race is not a bug, but a deliberate design
> decision that makes tsan considerably faster.
Could you please quantify that for us? Also, what lockle
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vmul_lane.c: New file.
>
OK /Marcus
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vmul_n.c: New file.
OK /Marcus
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vmull.c: New file.
OK /Marcus
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vmull_lane.c: New file.
OK /Marcus
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vmull_n.c: New file.
OK /Marcus
On 19/01/15 11:33 +0100, Richard Biener wrote:
On Mon, 12 Jan 2015, Richard Biener wrote:
This "fixes" PR64535 by changing the fixed object size emergency pool
to a variable EH object size (but fixed arena size) allocator. Via
combining the dependent and non-dependent EH arenas this should al
On Mon, Jan 19, 2015 at 03:44:20PM +0100, Martin Liška wrote:
> There's a bunch of another places that emit false positives. With following
> patch,
> I am able to run profiledbootstrap on x86_64-linux-pc and ppc64-linux-pc.
I don't know what we consider standard and where we allow warnings and t
The Library Fundamentals TS says
std::experimental::bad_optional_access should have a default
constructor, but we only support construction from strings.
This removes the unused and non-standard std::string constructor and
adds the required default constructor.
Tested x86_64-linux, *not* committ
On Jan 19, 2015, at 12:43 AM, Dmitry Vyukov wrote:
> I can't really make my mind on this. I would mildly prefer sleep's (if
> they work reliably!).
Let me state it more forcefully. sleeps are not now, nor in the history of
computing ever been a synchronization primitive, except for hard real ti
On Mon, Jan 12, 2015 at 05:30:46PM +, Andrew Pinski wrote:
> On Mon, Jan 12, 2015 at 7:52 AM, Kyrill Tkachov
> wrote:
> > Hi all,
> >
> > As raised in https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01237.html and
> > discussed in that thread, using __builtin_sqrt for vsqrt_f64 may end up in a
On 19 January 2015 at 14:29, Marcus Shawcroft
wrote:
> On 16 January 2015 at 17:52, Christophe Lyon
> wrote:
>
>>> OK provided, as per the previous couple, that we don;t regression or
>>> introduce new fails on aarch64[_be] or aarch32.
>>
>> This patch shows failures on aarch64 and aarch64_be fo
On 19/01/15 15:44, James Greenhalgh wrote:
On Mon, Jan 12, 2015 at 05:30:46PM +, Andrew Pinski wrote:
On Mon, Jan 12, 2015 at 7:52 AM, Kyrill Tkachov wrote:
Hi all,
As raised in https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01237.html and
discussed in that thread, using __builtin_sqrt fo
On Jan 19, 2015, at 5:41 AM, Maxim Kuvyrkov wrote:
> In A < B < C < A case all A, B and C are normal instructions. It is a
> pre-existing condition. When compiling without debug information we have
> ready list "A, B, C". When compiling with debug information, we have ready
> list "A, B, C,
On 12/31/2014 06:26 AM, Joseph Myers wrote:
> On Mon, 29 Dec 2014, Chen Gang S wrote:
>
>> And in honest, this year what I have done is really not quite well, next
>> year I should be improved: should scanning Bugzilla and try to fix the
>> existing issues (just like another members' suggestions t
Hello.
Following patch correctly handles filtered removed items, where we forgot
to check that a cgraph node is deleted or not. Apart from that, logic
in the function was rewritten and is much more understandable what's going on.
Tested on x86_64-linux-pc.
Ready for installation?
Thanks,
Martin
> On Jan 19, 2015, at 16:06 , Gerald Pfeifer wrote:
> This looks sweet, thank you!
My pleasure, just checked-in. Thanks for your note and feedback :-)
We declare atomic_init() but then never define it, I assume that's
just an accident.
Although the standard says this function is non-atomic, the simplest
fix at this stage is just to do an atomic store (when we get to stage
1 again I'd like to make the function a friend of std::__atomic_base<>
so
When I patched the triviality test for volatile types, I missed two cases:
1) volatile members in a class should make the class non-trivial.
2) a volatile class type should itself be non-trivial.
(based on [basic.types]/9, [class]/6, [class.copy]/12 and [class.copy]/25)
I haven't completed testing
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vqdmulh.c: New file.
OK /Marcus
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vqdmulh_lane.c: New file.
OK /Marcus
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vqdmulh_n.c: New file.
OK /Marcus
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vqdmull.c: New file.
OK /Marcus
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vqdmull_lane.c: New file.
OK
/Marcus
On 13 January 2015 at 15:18, Christophe Lyon wrote:
> * gcc.target/aarch64/advsimd-intrinsics/vqdmull_n.c: New file.
OK /Marcus
On 13 January 2015 at 15:17, Christophe Lyon wrote:
> This patch series is a follow-up of the conversion of my existing
> testsuite into DejaGnu. It does not yet cover all the tests I wrote,
> but I chose to post this set to have a chance to have it accepted
> before stage 4. I will have 35 more f
On 19 January 2015 at 15:43, Christophe Lyon wrote:
> On 19 January 2015 at 14:29, Marcus Shawcroft
> wrote:
>> On 16 January 2015 at 17:52, Christophe Lyon
>> wrote:
>>
OK provided, as per the previous couple, that we don;t regression or
introduce new fails on aarch64[_be] or aarch32
This is the last missing piece of the C++14 library, as proposed in
http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2013/n3657.htm
Tested x86_64-linux, *not* committed.
commit 99d7d1ebce9f290220966e138ef9b9e741878917
Author: Jonathan Wakely
Date: Mon Jan 19 17:05:34 2015 +
Impleme
Fix a crash due to missing a format string in a printf-style call,
when printing a string literal that contains formatting characters.
Seen on aarch64, where the patch takes jit.sum to:
# of expected passes7514
and no failures.
Committed to trunk as r219851.
gcc/jit/ChangeLog
On 19 January 2015 at 09:17, Richard Biener wrote:
>
> Status
> ==
>
> The trunk is now in "Stage 4" which means it is open for regression
> and documentation fixes only, like if it were a release branch.
>
> Please concentrate on getting P1 bugs fixed and provide help in
> confirming and analy
> Hello.
>
> Following patch correctly handles filtered removed items, where we forgot
> to check that a cgraph node is deleted or not. Apart from that, logic
> in the function was rewritten and is much more understandable what's going on.
>
> Tested on x86_64-linux-pc.
> Ready for installation?
On Fri, Jan 16, 2015 at 11:14:42AM +, Ramana Radhakrishnan wrote:
>
>
> On 16/01/15 10:20, Marcus Shawcroft wrote:
> > On 15 January 2015 at 09:50, James Greenhalgh
> > wrote:
> >
> >> 2015-01-15 James Greenhalgh
> >>
> >> * config/arm/cortex-a57.md: New.
> >> * config/a
On Fri, Jan 16, 2015 at 03:34:30PM +, Ramana Radhakrishnan wrote:
> On Fri, Jan 16, 2015 at 3:06 PM, James Greenhalgh
> wrote:
> > On Fri, Jan 16, 2015 at 10:20:40AM +, Marcus Shawcroft wrote:
> >> On 15 January 2015 at 09:50, James Greenhalgh
> >> wrote:
> >>
> >> > 2015-01-15 James Gr
Hi,
looks like the __bases extensions need some work as regards error
checking / recovery but this specific ICE on invalid seems easy and safe
to fix: check that TYPE_BINFO isn't null and handle the possibility of
vector->length () null during error recovery.
Tested x86_64-linux.
Thanks,
Pa
On Mon, Jan 19, 2015 at 12:32 PM, Jonathan Wakely wrote:
> I would like to commit these two patches which complete the C++11
> library implementation:
I would definitely be in favor.
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01694.html
Just a nit. Why wouldn't you check the value of the
On 19 January 2015 at 18:05, Ulrich Drepper wrote:
>> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01694.html
>
> Just a nit. Why wouldn't you check the value of the variable after
> the assignment in the test case?
Umm, just because I'm dumb? :-)
I'll make that change to my local branch, thanks
On Sat, Jan 17, 2015 at 7:34 PM, Uros Bizjak wrote:
> On Sat, Jan 17, 2015 at 12:19 AM, Ian Lance Taylor wrote:
>
>>> You should also revert alpha specific change to
>>> libgo/go/testing/quick/quick_test.go, please see [1] and [2].
>>>
>>> [1] https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00038.h
On Mon, Jan 19, 2015 at 05:32:39PM +, Jonathan Wakely wrote:
> I would like to commit these two patches which complete the C++11
> library implementation:
>
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01694.html
> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01648.html
>
> And this one t
On 01/19/2015 10:11 AM, Uros Bizjak wrote:
> Attached is a more conservative v2 patch that conditionally enables
> fixup code when FFI_TARGET_HAS_COMPLEX_TYPE is not defined.
>
> Tested on x86_64-linux-gnu {-m32} without regressions.
I don't think this version should be required.
For x86, FFI_TA
On Jan 19, 2015, at 6:05 PM, Richard Earnshaw wrote:
> On 16/01/15 15:06, Maxim Kuvyrkov wrote:
>> @@ -1874,7 +1889,8 @@ const struct tune_params arm_cortex_a15_tune =
>> true, true, /* Prefer 32-bit encodings.
>> */
>> true,
On Jan 19, 2015, at 6:48 PM, Mike Stump wrote:
> On Jan 19, 2015, at 5:41 AM, Maxim Kuvyrkov wrote:
>> In A < B < C < A case all A, B and C are normal instructions. It is a
>> pre-existing condition. When compiling without debug information we have
>> ready list "A, B, C". When compiling wi
Hello.
This is fix for PR64668, where I did a wrong assumption about an arguments
of OBJ_TYPE_REF tree type.
I've been testing the patch on x86_64-linux-pc, ready after it finishes?
Thanks,
Martin
>From 54840c592a866eca0a535cdda3714b4251042153 Mon Sep 17 00:00:00 2001
From: mliska
Date: Mon, 1
Hi,
this patch fixes the Ada bootstrap under cygwin-32. See PR ada/64640.
Boot-strapped successfully under cygwin-32/XP.
OK for trunk?
Thanks
Bernd.
2015-01-19 Bernd Edlinger
PR ada/64640
* adaint.c: Handle __CYGWIN__ like __MINGW32
1 - 100 of 155 matches
Mail list logo
