On 12/04/13 11:01, Richard Sandiford wrote:
Ping for this patch, which is the only one of the series that hasn't
been approved.
Thanks,
Richard
Richard Sandiford writes:
I have a patch to upgrade most genrecog warnings into errors. This patch
fixes those for tilegx. There seemed to be two s
On 12/03/13 22:28, Konstantin Serebryany wrote:
I really think that we need to disable libsanitizer on old systems
until someone volunteers to set up a proper testing process upstream.
If no one volunteers -- no one really needs it.
The right way to do this is to do feature tests rather than jus
Hi,
gcc trunk aarch64 bootstrapping fails with gas version 2.23.2 (with
error message similar to cannot compute suffix of object files) as this
particular version does not support -mabi=lp64. It succeeds with later
versions of gas that supports -mabi.
Attached patch add checking for -mabi=lp64 an
On 12/03/13 22:08, Konstantin Serebryany wrote:
We need
a) patches that we can review and apply to the llvm repository (w/o
breaking the modern systems, of course)
b) a buildbot that would run 24/7 catching regressions.
If we reach a green state for a platform X and have a buildbot for it,
keepi
The part of the configure script of the gnattools/ directory that deals with
the target parameterization is out of date. The attached patch consolidates
and cleans it up and also includes a new file for Darwin.
Tested on x86-64/Linux and SPARC/Solaris, applied on mainline and 4.8 branch.
2013
On Wed, Dec 4, 2013 at 9:28 AM, Joseph S. Myers wrote:
> On Wed, 4 Dec 2013, H.J. Lu wrote:
>
>> The kernel and glibc check should be done at the toplevel.
>> So what are the minimum kernel and glibc we want to
>> support?
>
> Checking those at toplevel is tricky in general because you're checking
Hello!
>>I can't see any place where this subreg is resolved (eg. into equiv
>> memref) before the next iteration comes around for reloading the inputs
>> and outputs of curr_insn. Or am I missing something some part of code
>> that tries reloading the subreg with different alternatives or reg cla
Based on discussions with Bernd Edlinger.. These two comments were
definitely in need to revision. Installed on the trunk.
Jeff
* expr.c (expand_assignment): Update comments.
diff --git a/gcc/expr.c b/gcc/expr.c
index 4e0e54f..2a13d8f 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -486
On 12/03/2013 07:08 PM, Iyer, Balaji V wrote:
In install_body_with_frame_cleanup for C++, I am using trees such as
TRY_CATCH_EXPR and am using a function from the cp/except.c. I didn't know how
to bring them to c-family.
I had in mind that the declaration would be in c-common.h, but each
fro
> -Original Message-
> From: Jason Merrill [mailto:ja...@redhat.com]
> Sent: Wednesday, December 4, 2013 5:39 PM
> To: Iyer, Balaji V; gcc-patches@gcc.gnu.org
> Cc: Jeff Law
> Subject: Re: _Cilk_spawn and _Cilk_sync for C++
>
> On 12/03/2013 07:08 PM, Iyer, Balaji V wrote:
> > In install
The rest of the change is OK once you've clarified this.
Jason
On 12/04/2013 05:42 PM, Iyer, Balaji V wrote:
I had in mind that the declaration would be in c-common.h, but each front
end would have a different definition in the front end directory, kind of like
how all front ends need to define "convert".
I didn't know it was an OK thing to do.
I think i
As noted in PR 52023, C11 _Alignof should return the *least* alignment
required for a type in any context - meaning that on 32-bit x86,
_Alignof (double) and _Alignof (long long) should be 4 not 8 because
of the reduced alignment inside structures. (C++11 defines alignment
requirements differently
On Nov 23, 2013, at 11:23 AM, Mike Stump wrote:
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the vax port.
>
> Ok?
OK.
As discussed late in this thread:
http://gcc.gnu.org/ml/gcc/2013-11/msg00345.html
This patch splits up the erroneous path optimization into two pieces.
One which detects NULL dereferences and isolates those paths and a
second which detects passing/returning a NULL pointer in cases where an
a
Ping.
On 2013/11/26 02:45 PM, Chung-Lin Tang wrote:
> Hi Bernd,
> I've updated the patch again, please see if it looks fit for approval
> now. Including ChangeLog again for completeness.
>
> Thanks,
> Chung-Lin
>
> 2013-11-26 Chung-Lin Tang
> Sandra Loosemore
> Based
Hello,
Here is a patch with initial ThreadSanitizer testsuite. It basically
adds several tests from upstream LLVM testsuite.
It works fine on x86_64 with patch from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188 applied.
Ok to commit or should we wait for fix for 59188?
-Maxim.
2013-12-05
Hi,
This is a fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59368 . It
adds a gcc_version variable to libsanitizer's root Makefile. Tested on
x86_64.
Ok to commit?
-Y
diff --git a/libsanitizer/Makefile.am b/libsanitizer/Makefile.am
index 6c3e5b0..dd0fc80 100644
--- a/libsanitizer/Makef
Hi,
This patch fixes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59369 by
disabling Linux-specific test on non-Linux platforms. Tested on
x86_64-apple-darwin.
Ok to commit?
-Y
diff --git a/gcc/testsuite/c-c++-common/asan/pr59063-1.c b/gcc/testsuite/c-c++-common/asan/pr59063-1.c
index a4e01f7
On Wed, Dec 04, 2013 at 04:36:58PM +1030, Alan Modra wrote:
> Maybe we should use most of BUILD_EXPORTS in the top level
> Makefile.in? What can go wrong with that? :)
I had a look at this, as it's easy to do, but I didn't find any
significant bug to justify such a change in stage3. So I've comm
On Wed, Dec 4, 2013 at 6:16 PM, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 06:09:56PM +0400, Konstantin Serebryany wrote:
>> This is a maintenance problem because we can not test if we broke
>> something during development.
>> e.g. clang doesn't seem to support -fno-dwarf2-cfi-asm
>
> It does,
Hello Uros,
On 04 Dec 20:16, Uros Bizjak wrote:
> Oh, no. We don't want assembly in this century ;)
Whoops, sorry. I was trying to do it with minimal changes.
I've implemented approach you proposed.
Batch in the bottom.
Bootstrapped. New tests pass.
Is it ok now?
ChangeLog/
* config/i38
Committed upstream:
http://llvm.org/viewvc/llvm-project?view=revision&revision=196480
On Thu, Dec 5, 2013 at 11:39 AM, Konstantin Serebryany
wrote:
> On Wed, Dec 4, 2013 at 6:16 PM, Jakub Jelinek wrote:
>> On Wed, Dec 04, 2013 at 06:09:56PM +0400, Konstantin Serebryany wrote:
>>> This is a maint
On Thu, Dec 05, 2013 at 10:18:10AM +0400, Yury Gribov wrote:
> This is a fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59368
> . It adds a gcc_version variable to libsanitizer's root Makefile.
> Tested on x86_64.
>
> Ok to commit?
> 2013-12-05 Yury Gribov
>
> PR sanitizer/59368
>
On Wed, Dec 4, 2013 at 8:58 PM, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 08:47:41AM -0800, H.J. Lu wrote:
>> > I believe this is a case where the GCC project gets more benefit from
>> > libsanitizer than libsanitizer gets from being part of the GCC
>> > project. We should work with the libs
101 - 125 of 125 matches
Mail list logo
