Hi Vladimir:
This patch has a discusses with you in May 2014, this patch is about
the caller-save register store and restore instruction generation, the
current LRA implementation will miss caller-save store/restore
instruction if need one more instruction.
You said you will investigate for this
On Tue, Dec 16, 2014 at 6:37 PM, Bin.Cheng wrote:
> On Thu, Nov 13, 2014 at 1:54 PM, Bin Cheng wrote:
>> Hi,
>> As commented at https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00684.html,
>> this is a simple patch enabling neon memset inlining on
>> cortex-a53/cortex-a57 in AArch32 mode.
>>
>> Test
Another fix for a non-regression FAIL. See the elaborate comment for
MIPS, updated to cover mmix-knuth-mmixware.
* gcc.dg/debug/debug-1.c: Pass -fno-if-conversion for
mmix-knuth-mmixware for the same reason as for MIPS.
* gcc.dg/debug/debug-2.c: Ditto.
Index: gcc.dg/debug
Failed ever since added for non-scheduling targets due to:
/x/gcc/testsuite/gcc.dg/pr42629.c:1:0: warning: instruction scheduling not
supported on this target machine
Committed as obvious.
* gcc.dg/pr42629.c: Only pass scheduling options on scheduling targets.
Index: pr42629.c
==
This is another in my series of boring tech-writer patches to the GCC
user documentation.
I noticed that the documentation for several recently-added command-line
options (e.g., the -fsanitize options) was written in the future tense
rather than the present. Generally, future tense is only ap
On Sun, 4 Jan 2015 13:57:38, Mike Stump wrote:
>
> On Jan 4, 2015, at 1:48 PM, Bernd Edlinger wrote:
>> I would need a way to link the test case two helper functions, that are not
>> compiled with -fsanitize=thread
>
> /* { dg-additional-sources “tsan-helper.c" } */
>
> might be one step forward
On Jan 4, 2015, at 11:44 AM, Bernd Edlinger wrote:
> On Sun, 4 Jan 2015 20:16:58, Jakub Jelinek wrote:
>>
>> On Sun, Jan 04, 2015 at 11:07:31AM -0800, Mike Stump wrote:
>>> On Jan 4, 2015, at 9:00 AM, Bernd Edlinger
>>> wrote:
It is due to a race condition in tsan itself, it cannot decide
On Jan 4, 2015, at 1:48 PM, Bernd Edlinger wrote:
> I would need a way to link the test case two helper functions, that are not
> compiled with -fsanitize=thread
/* { dg-additional-sources “tsan-helper.c" } */
might be one step forward to do that. I don’t know off hand about the options.
I t
On Sun, 4 Jan 2015 11:04:34, Mike Stump wrote:
>
> Ah, even more curious. So, for testing, it would be best if we had a way to
> synchronize the threads so that they reliably can show what you want to show,
> and reliably pick which thread will run first and which second and so on. The
> proble
Dear Tobias,
I have done a clean bootstrap with your patch and run
make -k check-gfortran RUNTESTFLAGS="caf.exp --target_board=unix'{-m32,-m64}’"
without regression.
Thanks,
Dominique
> Le 4 janv. 2015 à 19:57, Tobias Burnus a écrit :
>
> Attached is a regtested patch, which fixes the issu
On 10.12.2014 17:37, Patrick Wollgast wrote:
> Ping.
>
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03368.html
>
> On 27.11.2014 10:42, Patrick Wollgast wrote:
>> On 12.11.2014 19:40, Kai Tietz wrote:
>>> TerminateProcess is actually bad, as it doesn't call any of the atexit
>>> handlers. You
Hi,
On Sun, 4 Jan 2015 20:16:58, Jakub Jelinek wrote:
>
> On Sun, Jan 04, 2015 at 11:07:31AM -0800, Mike Stump wrote:
>> On Jan 4, 2015, at 9:00 AM, Bernd Edlinger wrote:
>>> It is due to a race condition in tsan itself, it cannot decide which access
>>> was the
>>> previous one and which was th
(CC'ing build machinery maintainers, maybe I should have done this initially)
Am 2014-12-31 um 11:45 schrieb Janne Blomqvist:
> On Fri, Dec 19, 2014 at 2:56 PM, Michael Haubenwallner
> wrote:
>> On the way to prepare some (aix) libtool patch for toplevel libtool.m4
>> I've discovered that differe
On Sun, Jan 04, 2015 at 11:07:31AM -0800, Mike Stump wrote:
> On Jan 4, 2015, at 9:00 AM, Bernd Edlinger wrote:
> > It is due to a race condition in tsan itself, it cannot decide which access
> > was the
> > previous one and which was the second one, but our tsan tests are not meant
> > as
> > a
On Sun, Jan 04, 2015 at 11:04:34AM -0800, Mike Stump wrote:
> On Jan 3, 2015, at 3:20 AM, Bernd Edlinger wrote:
> > Yes, but all other tsan test cases call sleep(1) too.
>
> Ick. The problem is pushing bugs to obscure them without fixing them, makes
> the system inherently less good.
>
> If th
On Jan 4, 2015, at 9:00 AM, Bernd Edlinger wrote:
> It is due to a race condition in tsan itself, it cannot decide which access
> was the
> previous one and which was the second one, but our tsan tests are not meant as
> a functional test of the tsan runtime library, they are only meant to test
On Jan 3, 2015, at 3:20 AM, Bernd Edlinger wrote:
> Yes, but all other tsan test cases call sleep(1) too.
Ick. The problem is pushing bugs to obscure them without fixing them, makes
the system inherently less good.
If there is already one bug that documents the problem that the sleep cures
th
Attached is a regtested patch, which fixes the issue. Additionally, the
variable visibility (TREE_PUBLIC) is now depending on the private
attribute (copied from the module var generation) and I mark the tree as
DECL_NONALIASED. The former I also did for proc-pointers, which is an
unrelated patc
On January 4, 2015 3:57:07 PM CET, "H.J. Lu" wrote:
>On Sun, Jan 4, 2015 at 3:37 AM, Richard Biener
> wrote:
>> On January 3, 2015 10:48:47 PM CET, "H.J. Lu"
>wrote:
>>>On Sat, Jan 3, 2015 at 12:58 PM, John David Anglin
>>> wrote:
On 2015-01-03, at 3:18 PM, H.J. Lu wrote:
> On Sat,
Aehm, sorry,
that's the sporadic failure, I mentioned:
https://gcc.gnu.org/ml/gcc-regression/2015-01/msg00041.html
New failures:
FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C -O2 execution test
New passes:
https://gcc.gnu.org/ml/gcc-regression/2015-01/msg00044.html
New failures:
New passes:
Hi,
Revision 219076
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=219076
caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64485
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64481
--
H.J.
On Sun, Jan 4, 2015 at 3:37 AM, Richard Biener
wrote:
> On January 3, 2015 10:48:47 PM CET, "H.J. Lu" wrote:
>>On Sat, Jan 3, 2015 at 12:58 PM, John David Anglin
>> wrote:
>>> On 2015-01-03, at 3:18 PM, H.J. Lu wrote:
>>>
On Sat, Jan 3, 2015 at 12:10 PM, John David Anglin
>> wrote:
> On
This test is failing on hpux.
Tested x86_64-linux, committed to trunk.
commit 481c7cee8f24798d859a619c955a721846e86742
Author: Jonathan Wakely
Date: Sun Jan 4 13:45:28 2015 +
PR libstdc++/64483
* testsuite/18_support/exception_ptr/64241.cc: Use
dg-require-atomic-builtins.
Hi Jakub,
I think I have found a reasonable test case, see the attached patch file.
The use case is: a class that destroys an owned thread in the destructor.
The destructor sets the vptr again to thread::vptr but this should
_not_ trigger a diagnostic message, when the vptr does not really change
Hi Janus, hi Paul, hi Tobias,
Janus: During code review, I found that I had the code in
gfc_get_len_component() duplicated. So I now reintroduced and documented the
routine making is more commonly usable and added more documentation. The call
sites are now simplify.c (gfc_simplify_len) and trans-e
On January 3, 2015 10:48:47 PM CET, "H.J. Lu" wrote:
>On Sat, Jan 3, 2015 at 12:58 PM, John David Anglin
> wrote:
>> On 2015-01-03, at 3:18 PM, H.J. Lu wrote:
>>
>>> On Sat, Jan 3, 2015 at 12:10 PM, John David Anglin
> wrote:
On 2015-01-03, at 2:48 PM, H.J. Lu wrote:
> On Sat, Jan 3,
* configure.ac: Use OBJCOPY for OBJCOPY_FOR_TARGET.
* configure: Regenerate.
diff --git a/configure.ac b/configure.ac
index 6d208b0..7205026 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,6 +1,6 @@
# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
-# 20
> On Jan 4, 2015, at 1:35 AM, Bin.Cheng wrote:
>
>> On Sun, Jan 4, 2015 at 6:55 AM, Andrew Pinski wrote:
>>> On Mon, Nov 24, 2014 at 1:32 PM, Jeff Law wrote:
On 11/22/14 21:20, Andrew Pinski wrote:
Hi,
The problem here is here is that OBJCOPY is not being set to the
>
On Sun, Jan 4, 2015 at 6:55 AM, Andrew Pinski wrote:
> On Mon, Nov 24, 2014 at 1:32 PM, Jeff Law wrote:
>> On 11/22/14 21:20, Andrew Pinski wrote:
>>>
>>> Hi,
>>>The problem here is here is that OBJCOPY is not being set to the
>>> newly built objcopy when compiling libgo. This patch adds
>>>
29 matches
Mail list logo
