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
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
>
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
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
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,
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
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
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
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
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
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
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 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 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
The rest of the change is OK once you've clarified this.
Jason
> -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
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
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
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
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
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 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
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: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
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
OK, thanks.
Jason
On Wed, Dec 4, 2013 at 9:01 PM, Jakub Jelinek wrote:
>> > My memory is fuzzy about that, but I think that was my first version which
>> > didn't work, because with match_dup then it requires on the internal-fn.c
>> > side to pass 4 arguments instead of just 3. I can try again though.
>
> Weird, n
On 12/04/13 09:06, Tejas Belagod wrote:
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
The problem is that one reg rtx can span several hard registers.
E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
but it might instead repres
On Wed, Dec 04, 2013 at 08:23:22PM +0100, Uros Bizjak wrote:
> > My memory is fuzzy about that, but I think that was my first version which
> > didn't work, because with match_dup then it requires on the internal-fn.c
> > side to pass 4 arguments instead of just 3. I can try again though.
Weird,
On 12/03/2013 02:45 PM, Marek Polacek wrote:
You're right. I wanted to use cp_save_expr and/or stabilize_expr, but
that didn't work out. So I resorted to restrict the condition a bit
and only pass INDIRECT_REFs to the ubsan routine (which, after all,
has
if (!INDIRECT_REF_P (init))
retu
On 12/03/2013 02:48 PM, Iyer, Balaji V wrote:
Now, after all that I must admit that cilk_spawn could only ever see
VEC_INIT_EXPR in the context of a lambda closure initialization, and the
default behavior should always be correct for a lambda closure initialization,
so I guess I'm willing to allo
On Wed, Dec 4, 2013 at 8:07 PM, Jakub Jelinek wrote:
>> > @@ -8617,6 +8740,49 @@
>> >[(set_attr "type" "negnot")
>> > (set_attr "mode" "SI")])
>> >
>> > +;; Negate with jump on overflow.
>> > +(define_expand "negv3"
>> > + [(parallel [(set (reg:CCO FLAGS_REG)
>> > + (ne:
On Wed, Dec 4, 2013 at 5:59 PM, Kirill Yukhin wrote:
> MSVC and ICC (currently Windows version, Linux version soon) have
> dedicated intrinsics to read/set EFLAGS register ([1], [2]).
>
> Patch introduces these intrinsics and tests for them.
>
> Bootstrapped. New tests pass.
> Although gate is cl
On Wed, Dec 04, 2013 at 07:58:20PM +0100, Uros Bizjak wrote:
> > @@ -8617,6 +8740,49 @@
> >[(set_attr "type" "negnot")
> > (set_attr "mode" "SI")])
> >
> > +;; Negate with jump on overflow.
> > +(define_expand "negv3"
> > + [(parallel [(set (reg:CCO FLAGS_REG)
> > + (ne:CC
On Wed, Dec 4, 2013 at 2:44 PM, Marek Polacek wrote:
> And this is the i?86 specific part of -fsanitize=signed-integer-overflow,
> split out of the huge patch. It really is dependent on the generic
> parts, when commiting, I'll put both parts together.
>
> Uros, would you mind taking a look at th
On Wed, Dec 04, 2013 at 06:30:37PM +, Joseph S. Myers wrote:
> On Wed, 4 Dec 2013, Marek Polacek wrote:
>
> > I can, the question is whether we want that. Anyway, this is version
> > which looks for the gnu_inline attribute.
>
> If anything, I'd think it should apply to all inline functions.
On Wed, 4 Dec 2013, Marek Polacek wrote:
> I can, the question is whether we want that. Anyway, this is version
> which looks for the gnu_inline attribute.
If anything, I'd think it should apply to all inline functions. The point
of this warning is that non-static functions should be declared
On Wed, Dec 04, 2013 at 06:22:28PM +, Joseph S. Myers wrote:
> On Wed, 4 Dec 2013, Marek Polacek wrote:
>
> > In C99, one way how to deal with inline functions is to put definition
> > of the function into header:
> > inline void foo (void) { /* ... */ }
> > and put the declaration into exactl
On Wed, 4 Dec 2013, Marek Polacek wrote:
> In C99, one way how to deal with inline functions is to put definition
> of the function into header:
> inline void foo (void) { /* ... */ }
> and put the declaration into exactly one .c file, with extern keyword
> (it can also have inline keyword):
> ext
On Wed, Dec 04, 2013 at 06:55:52PM +0100, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 06:47:09PM +0100, Marek Polacek wrote:
> > In C99, one way how to deal with inline functions is to put definition
> > of the function into header:
> > inline void foo (void) { /* ... */ }
> > and put the declar
On 12/03/13 21:24, Andrew Pinski wrote:
Hi,
With ILP32, some simple usage of TLS variables causes an unrecognizable
instruction due to needing to use SImode for loading pointers from memory.
This fixes the three (tlsie_small, tlsle_small, tlsdesc_small) patterns to
support SImode for pointers.
On 04/12/13 16:05, Ian Bolton wrote:
Hi,
Currently, on ARM, you have to either call abort() or raise(SIGTRAP)
to achieve a handy crash.
This patch allows you to instead call __builtin_trap() which is much
more efficient at falling over because it becomes just a single
instruction that will trap
> On Wed, 4 Dec 2013, Ian Bolton wrote:
>
> > The main update, other than cosmetic differences, is that we've
> chosen
> > the same ARM encoding as LLVM for practical purposes. (The Thumb
> > encoding in Mark's patch already matched LLVM.)
>
> Do the encodings match what plain "udf" does in rece
On Wed, Dec 4, 2013 at 9:58 AM, Kirill Yukhin wrote:
> Hello,
> On 04 Dec 19:59, Kirill Yukhin wrote:
>> So, is it ok for trunk?
>
> Small correction. I think it is better to use
> popfql/pushfql instead of popf/pushf (however they're
> encoded equally).
>
If you define the proper type, you can u
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 sources of warnings:
>
> - the intrinsics of
Hello,
On 04 Dec 19:59, Kirill Yukhin wrote:
> So, is it ok for trunk?
Small correction. I think it is better to use
popfql/pushfql instead of popf/pushf (however they're
encoded equally).
--
Thanks, K
On Wed, Dec 04, 2013 at 09:47:36AM -0800, Cary Coutant wrote:
> > gcc/
> > 2013-11-24 Tobias Burnus
> >
> > PR debug/37132
> > * lto-streamer.h (LTO_tags): Add LTO_namelist_decl_ref.
> > * tree.def (NAMELIST_DECL): Add.
> > * tree.h (NAMELIST_DECL_ASSOCIATED_DECL): New ma
On Wed, Dec 04, 2013 at 06:47:09PM +0100, Marek Polacek wrote:
> In C99, one way how to deal with inline functions is to put definition
> of the function into header:
> inline void foo (void) { /* ... */ }
> and put the declaration into exactly one .c file, with extern keyword
> (it can also have i
OK.
Jason
On Wed, Dec 04, 2013 at 06:47:09PM +0100, Marek Polacek wrote:
> In C99, one way how to deal with inline functions is to put definition
> of the function into header:
> inline void foo (void) { /* ... */ }
> and put the declaration into exactly one .c file, with extern keyword
> (it can also have i
In C99, one way how to deal with inline functions is to put definition
of the function into header:
inline void foo (void) { /* ... */ }
and put the declaration into exactly one .c file, with extern keyword
(it can also have inline keyword):
extern void foo (void);
But in this case, we shouldn't is
> gcc/
> 2013-11-24 Tobias Burnus
>
> PR debug/37132
> * lto-streamer.h (LTO_tags): Add LTO_namelist_decl_ref.
> * tree.def (NAMELIST_DECL): Add.
> * tree.h (NAMELIST_DECL_ASSOCIATED_DECL): New macro.
> * tree.c (initialize_tree_contains_struct): Add asserts for it.
On 12/03/13 21:24, Andrew Pinski wrote:
Hi,
With ILP32 AARCH64, Pmode (DImode) != ptrmode (SImode) so the variable decl
has a mode of SImode while the register is DImode. So the target that gets
passed down to expand_builtin_thread_pointer is NULL as expand does not
know how to get a subreg f
Tejas Belagod writes:
> Richard Sandiford wrote:
>> Tejas Belagod writes:
>>> Richard Sandiford wrote:
Tejas Belagod writes:
>> The problem is that one reg rtx can span several hard registers.
>> E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
>> but it might in
On 3 December 2013 19:42, Cary Coutant wrote:
>> This patches gen_compile_unit_die to use the DW_LANG_D DWARF language
>> code for D. Is in relation to some other D language fixes that are
>> going to be submitted to gdb.
>
> Is this for a private front end? I'm not aware of any front ends that
>
On Wed, Dec 4, 2013 at 9:29 AM, Jeff Law wrote:
> On 12/04/13 09:14, H.J. Lu wrote:
>
>>> +
>>> +/* { dg-final { scan-rtl-dump "deleting noop move" "combine" { target
>>> aarch64*-*-* } } } */
>>
>>
>> Any particular reason why it doesn't work for x86?
>
> I don't think so. I'm pretty sure Tejas
On 12/04/13 09:14, H.J. Lu wrote:
+
+/* { dg-final { scan-rtl-dump "deleting noop move" "combine" { target
aarch64*-*-* } } } */
Any particular reason why it doesn't work for x86?
I don't think so. I'm pretty sure Tejas is focused on ARM platforms for
the obvious reason.
jeff
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
something for the target rather than the host. You'd need to m
On Wed, Dec 4, 2013 at 11:24 AM, Jeff Law wrote:
> Here's feedback. Install it now :-)
Works for me :) Committed.
Diego.
On Wed, 4 Dec 2013, Ian Bolton wrote:
> The main update, other than cosmetic differences, is that we've chosen
> the same ARM encoding as LLVM for practical purposes. (The Thumb
> encoding in Mark's patch already matched LLVM.)
Do the encodings match what plain "udf" does in recent-enough gas (t
On 12/04/13 06:44, Marek Polacek wrote:
This is a repost of rebased version of the signed-integer-overflow
patch, split into generic parts and i?86 parts. By i?86 parts I mean
the stuff that resides in config/i386, I haven't really tried to
untangle it more.
Except the two formatting fixes I als
On Wed, Dec 4, 2013 at 8:58 AM, 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
Hello,
MSVC and ICC (currently Windows version, Linux version soon) have
dedicated intrinsics to read/set EFLAGS register ([1], [2]).
Patch introduces these intrinsics and tests for them.
Bootstrapped. New tests pass.
Although gate is closed patch is obvious.
So, is it ok for trunk?
ChangeLog/
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 libsanitizer developers to make this
> > work, not just push ev
On Wed, Dec 4, 2013 at 8:50 AM, FX wrote:
>> I think libsanitizer should be disabled automatically if kernel or glibc are
>> too old.
>
> I think pretty much everyone agrees. But noone’s willing to put forward a
> patch,
What are the agreed-upon minimum kernel and glibc? I
can give it a try.
>
> I think libsanitizer should be disabled automatically if kernel or glibc are
> too old.
I think pretty much everyone agrees. But noone’s willing to put forward a
patch, and so far the libsanitizer maintainers have failed to even document the
requirements. (There are also binutils requirements,
On Wed, Dec 4, 2013 at 8:41 AM, Ian Lance Taylor wrote:
> On Wed, Dec 4, 2013 at 8:04 AM, FX wrote:
>>> > Well, it regresses against 4.8, so it still is a P1 regression.
>>>
>>> Does anyone care?
>>
>>
>> Well, you’re one of the maintainers of libsanitizer for GCC, so if you do
>> not care about
> 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 libsanitizer developers to make this
> work, not just push everything back on them.
You’re vastly better qualified than me to
On Wed, Dec 4, 2013 at 8:04 AM, FX wrote:
>> > Well, it regresses against 4.8, so it still is a P1 regression.
>>
>> Does anyone care?
>
>
> Well, you’re one of the maintainers of libsanitizer for GCC, so if you do not
> care about regressions in your code, it makes little sense for GCC (the whol
On 12/04/13 07:20, Diego Novillo wrote:
On Tue, Dec 3, 2013 at 6:55 PM, Gerald Pfeifer wrote:
On Thu, 28 Nov 2013, Richard Biener wrote:
Why remove ChangeLog files, web pages and comments?
I was going to complain about web pages being removed. :-)
On Thu, 28 Nov 2013, Diego Novillo wrote:
I think together with this patch, the default value for
--with-multilib-list when it is absent can be updated to "lp64,ilp32"
from "lp64" only. This will make the multi-lib default setting on
aarch64*-*-linux* consist that on aarch64*-*-elf. See gcc/config.gcc.
Thanks,
Yufeng
P.S. Copy&past
On 12/04/13 03:40, Richard Biener wrote:
On Wed, Dec 4, 2013 at 11:07 AM, Eric Botcazou wrote:
Fixed by making sure force_to_mode doesn't modify x in place.
I think that it's the way to go, force_to_mode doesn't modify its argument
except for these 2 cases. I'm not sure what the story is, bu
On Wed, Dec 4, 2013 at 8:06 AM, Tejas Belagod wrote:
> Thanks Richard. Here is a revised patch. Sorry about the delay - I was
> investigating to make sure an LRA ICE I was seeing on aarch64 was unrelated
> to this patch. I've added a test case that I expect to pass for aarch64.
> I've also added t
Hi,
Currently, on ARM, you have to either call abort() or raise(SIGTRAP)
to achieve a handy crash.
This patch allows you to instead call __builtin_trap() which is much
more efficient at falling over because it becomes just a single
instruction that will trap for you.
Two testcases have been adde
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
The problem is that one reg rtx can span several hard registers.
E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
but it might instead represent two 32-bit registers (nos. 32 and 33)
> > Well, it regresses against 4.8, so it still is a P1 regression.
>
> Does anyone care?
Well, you’re one of the maintainers of libsanitizer for GCC, so if you do not
care about regressions in your code, it makes little sense for GCC (the whole
project) to keep libsanitizer.
I’ve posted this
I'm applying the following as obvious, GCC 4.7 doesn't grok -Wpedantic.
Sorry for not testing that properly.
2013-12-04 Marek Polacek
PR c/59351
testsuite/
* gcc.dg/pr59351.c: Use -pedantic instead of -Wpedantic.
--- gcc/testsuite/gcc.dg/pr59351.c.mp3 2013-12-04 16:49:17.2328
Looks good to me, but I cannot approve it.
Yufeng
On 12/03/13 21:24, Andrew Pinski wrote:
Hi,
The arguments to --with-multilib-list for AARCH64 are exclusive but
currently is being treated as ones which are not. This causes problems in that
we get four library sets with --with-multilib-l
On 12/03/2013 02:38 PM, Jeff Law wrote:
On 12/03/13 12:25, Kenneth Zadeck wrote:
On 12/03/2013 01:52 PM, Mike Stump wrote:
On Dec 2, 2013, at 10:26 PM, Jeff Law wrote:
On 11/27/13 17:13, Cesar Philippidis wrote:
I looked into adding support for incremental DF scanning from
df*.[ch]
in combi
Hi all,
This patch series implements the new arm_neon.h intrinsics that map down to the
ARMv8-A cryptographic instructions. The instructions are considered to be part
of NEON and they can be enabled by specifying -mfpu=crypto-neon-fp-armv8 (of
course we still need the hard or softfp float ABI)
Hi all,
This is the final patch in the series, adding the documentation for the
intrinsics. Most of it is autogenerated from neon-docgen.ml and the ones that
are not are added explicitly in neon-docgen.ml so that they appear in the
generated .texi file. Not much else to say on this patch.
Ok
On Tue, Dec 3, 2013 at 6:55 PM, Gerald Pfeifer wrote:
> On Thu, 28 Nov 2013, Richard Biener wrote:
>> Why remove ChangeLog files, web pages and comments?
>
> I was going to complain about web pages being removed. :-)
>
> On Thu, 28 Nov 2013, Diego Novillo wrote:
>> -Fixes for obvious typos in Chan
On Wed, Dec 4, 2013 at 5:44 PM, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 05:28:40PM +0400, Konstantin Serebryany wrote:
>> > Well, for the kernel headers what we perhaps can do is just add
>> > libsanitizer/include/linux/ tree that will be maintained by GCC and will
>>
>> if that works for y
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, at least both clang 3.3 (from Fedora 19) and clang
3.4 r19468
On Tue, Dec 03, 2013 at 02:14:17PM -0700, Jeff Law wrote:
> Perhaps split this patch into two parts which can be reviewed
> independently, but go into the tree at the same time. The obvious
> hope would be that Uros or one of the other x86 backend folks could
> chime in on that part.
I posted the
[new subject. was: libsanitizer merge from upstream r196090]
>> .cfi is used only in tsan sources now, and tsan is not supported
>> anywhere but x86_64
>
> But the .cfi_* issue is platform independent. Whether the compiler
> decides to emit them or not depends on how it was configured, on assembl
On Wed, Dec 04, 2013 at 02:52:25PM +0100, Uros Bizjak wrote:
> On Wed, Dec 4, 2013 at 2:44 PM, Marek Polacek wrote:
> > And this is the i?86 specific part of -fsanitize=signed-integer-overflow,
> > split out of the huge patch. It really is dependent on the generic
> > parts, when commiting, I'll
On Wed, Dec 04, 2013 at 08:53:50AM +0100, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 08:49:32AM +0100, Aurelien Jarno wrote:
> > On sparc, the --with-long-double-128 option doesn't change anything for
> > a 64-bit compiler, as it always default to 128-bit long doubles. For
> > a 32/64-bit compi
On Wed, Dec 04, 2013 at 02:52:25PM +0100, Uros Bizjak wrote:
> On Wed, Dec 4, 2013 at 2:44 PM, Marek Polacek wrote:
> > And this is the i?86 specific part of -fsanitize=signed-integer-overflow,
> > split out of the huge patch. It really is dependent on the generic
> > parts, when commiting, I'll
On 12/04/2013 07:56 AM, Richard Sandiford wrote:
Richard Sandiford writes:
This patch handles multiplications using a single HWIxHWI->2HWI multiplication
on hosts that have one. This removes all uses of the slow (half-HWI) path
for insn-recog.ii. The slow path is still used 58 times for cp/pa
On Wed, Dec 4, 2013 at 2:44 PM, Marek Polacek wrote:
> And this is the i?86 specific part of -fsanitize=signed-integer-overflow,
> split out of the huge patch. It really is dependent on the generic
> parts, when commiting, I'll put both parts together.
Just a question (I will review the patch la
This is a repost of rebased version of the signed-integer-overflow
patch, split into generic parts and i?86 parts. By i?86 parts I mean
the stuff that resides in config/i386, I haven't really tried to
untangle it more.
Except the two formatting fixes I also moved various PROB_ macros into
predict.
And this is the i?86 specific part of -fsanitize=signed-integer-overflow,
split out of the huge patch. It really is dependent on the generic
parts, when commiting, I'll put both parts together.
Uros, would you mind taking a look at this?
Regtested/bootstrapped on x86_64-linux. Ok for trunk?
20
On Wed, Dec 04, 2013 at 05:28:40PM +0400, Konstantin Serebryany wrote:
> > Well, for the kernel headers what we perhaps can do is just add
> > libsanitizer/include/linux/ tree that will be maintained by GCC and will
>
> if that works for you, no objections.
I haven't tried to do that yet, so don'
On Wed, Dec 4, 2013 at 5:02 PM, Jakub Jelinek wrote:
> On Wed, Dec 04, 2013 at 04:49:22PM +0400, Konstantin Serebryany wrote:
>> I would start from kernel version and glibc version, this should cover
>> the majority of use cases.
>
> Well, for the kernel headers what we perhaps can do is just add
On Wed, 2013-12-04 at 07:13 -0600, Bill Schmidt wrote:
> On Wed, 2013-12-04 at 11:30 +0100, Richard Biener wrote:
> > On Wed, Dec 4, 2013 at 11:26 AM, Richard Biener
> > wrote:
> > > On Tue, Dec 3, 2013 at 11:04 PM, Bill Schmidt
> > > wrote:
> > >> On Tue, 2013-12-03 at 21:35 +0100, Richard Biene
On Wed, 2013-12-04 at 11:32 +, Yufeng Zhang wrote:
> On 12/04/13 10:30, Richard Biener wrote:
> > On Wed, Dec 4, 2013 at 11:26 AM, Richard Biener
> > wrote:
> >> On Tue, Dec 3, 2013 at 11:04 PM, Bill Schmidt
> >> wrote:
> >>> On Tue, 2013-12-03 at 21:35 +0100, Richard Biener wrote:
> Y
On Wed, 2013-12-04 at 11:30 +0100, Richard Biener wrote:
> On Wed, Dec 4, 2013 at 11:26 AM, Richard Biener
> wrote:
> > On Tue, Dec 3, 2013 at 11:04 PM, Bill Schmidt
> > wrote:
> >> On Tue, 2013-12-03 at 21:35 +0100, Richard Biener wrote:
> >>> Yufeng Zhang wrote:
> >>> >On 12/03/13 14:20, Richa
On Wed, 2013-12-04 at 11:26 +0100, Richard Biener wrote:
> On Tue, Dec 3, 2013 at 11:04 PM, Bill Schmidt
> wrote:
> > On Tue, 2013-12-03 at 21:35 +0100, Richard Biener wrote:
> >> Yufeng Zhang wrote:
> >> >On 12/03/13 14:20, Richard Biener wrote:
> >> >> On Tue, Dec 3, 2013 at 1:50 PM, Yufeng Zha
On Wed, Dec 04, 2013 at 04:49:22PM +0400, Konstantin Serebryany wrote:
> I would start from kernel version and glibc version, this should cover
> the majority of use cases.
Well, for the kernel headers what we perhaps can do is just add
libsanitizer/include/linux/ tree that will be maintained by G
1 - 100 of 125 matches
Mail list logo
