Hi all!
Here is the patch which forces ASan to ignore alignment of memory
access. It increases ASan overhead but it's still useful because some
programs like linux kernel often cheat with alignment which may cause
false negatives.
--Marat
gcc/ChangeLog:
2014-11-14 Marat Zakirov
* asan.
> Please rephrase the comment along the lines of my previous suggestion.
> This wording is too complex IMO.
The patch containing the updated comment (which also keeps within 72 columns)
is below.
Ok to commit?
Regards,
Andrew
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index
Hi,
This change goes along with the change to the GOARCH setting in gccgo
for ppc64le which will be done in gofrontend. The description for that
change is here:
https://groups.google.com/forum/#!topic/gofrontend-dev/ocEttrpsw-s
This change has been bootstrapped and tested along with the abo
bootstrap-ubsan on gcc112 shows a couple of signed integer overflows:
config/rs6000/constraints.md:143:33: runtime error: signed integer overflow:
9223372036854775807 + 32768 cannot be represented in type 'long int'
config/rs6000/predicates.md:396:22: runtime error: signed integer overflow:
9223
On Fri, Nov 14, 2014 at 11:13 AM, Jan Hubicka wrote:
> Hi,
> this patch kills lto's code to rebuilt DECL_FUNCTION_SPECIFIC_TARGET from
> target
> attributes. This code was never complete and it should be no-op now when we
> save
> tehe target nodes.
> It also makes free_land_data_in_decl to act
On Wed, Nov 19, 2014 at 04:24:25PM +0100, Markus Trippelsdorf wrote:
> ;; Return 1 if op is a constant integer valid for addition
> @@ -827,7 +827,7 @@
> (define_predicate "mask_operand"
>(match_code "const_int")
> {
> - HOST_WIDE_INT c, lsb;
> + unsigned HOST_WIDE_INT c, lsb;
>
>c =
On Sat, Nov 15, 2014 at 11:15 PM, Jan Hubicka wrote:
> Hi,
> late in GCC 4.9 development we broke the feature that ltrans stages do not
> read all
> functions in ahead. This is because of late IPA passes that do not like to
> see functions
> without IPA transformations applied. I was originall
On Wed, Nov 19, 2014 at 04:24:25PM +0100, Markus Trippelsdorf wrote:
> --- a/gcc/config/rs6000/constraints.md
> +++ b/gcc/config/rs6000/constraints.md
> @@ -140,7 +140,7 @@
> (define_constraint "I"
>"A signed 16-bit constant"
>(and (match_code "const_int")
> - (match_test "(unsigned
On 19 November 2014 14:32, Wilco Dijkstra wrote:
> Hi Jiong,
>
> Can you commit this please?
>
> 2014-11-19 Wilco Dijkstra
>
> * gcc/config/aarch64/aarch64.c (generic_regmove_cost):
> Increase FP move cost (PR61915).
>
Use the proper format for referring to PR's in the Changelo
On Wed, Nov 19, 2014 at 04:41:49PM +0100, Marek Polacek wrote:
> > - HOST_WIDE_INT c, lsb;
> > + unsigned HOST_WIDE_INT c, lsb;
> >
> >c = INTVAL (op);
>
> Shouldn't you use UINTVAL then?
That doesn't really matter here. It looks a bit cleaner, of course.
I wouldn't spend too much time
A testcase is added for all targets as I think it's a middle-end
issue. And sorry for not being able to simplify it.
arm-none-eabi has been test on the model, no new issues. bootstrapping
and regression tested on x86, no new issues.
Is it Okay to commit?
Yes. Thanks very much for working on i
On Wed, Nov 19, 2014 at 09:01:35AM -0600, Lynn A. Boger wrote:
> + "powerpc-*-*" {
> + set goarch "ppc"
> }
> + "powerpc64-*-*" {
> + set goarch "ppc64"
> + }
> + "powerpc64le-*-*" {
> + set goarch "ppc64le"
> + }
I don't think th
Ping.
-Maxim
Original Message
Subject: [PATCH] Fix libbacktrace and libiberty tests fail on sanitized
GCC due to wrong link options.
Date: Wed, 05 Nov 2014 19:48:06 +0400
From: Maxim Ostapenko
To: GCC Patches
CC: Yury Gribov , Jakub Jelinek
, Slava Garbuzov
H
Hi Tim,
On 11/19/2014 08:27 AM, Tim Shen wrote:
On Tue, Nov 18, 2014 at 11:19 AM, Paolo Carlini
wrote:
Jonathan lately is following your work much better than me, but naively
seems weird that _M_begin is non-const and _M_end is const, a different type
anyway.
Hmm. The current regex_search alg
On 19/11/14 16:01, Ramana Radhakrishnan wrote:
A testcase is added for all targets as I think it's a middle-end
issue. And sorry for not being able to simplify it.
arm-none-eabi has been test on the model, no new issues. bootstrapping
and regression tested on x86, no new issues.
Is it Okay to co
On Wed, Nov 19, 2014 at 10:24 AM, Markus Trippelsdorf
wrote:
> bootstrap-ubsan on gcc112 shows a couple of signed integer overflows:
> The fix was tested on powerpc64-unknown-linux-gnu.
> OK for trunk?
>
> Thank you.
>
> 2014-11-19 Markus Trippelsdorf
>
> * config/rs6000/constraints.md
On 11/19/14 07:58, Richard Henderson wrote:
This is the middle-end and C front end parts of the gccgo related
patch set first posted here.
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01009.html
I've re-tested these patches in isolation and have committed them
to mainline. I'm currently su
On 13/11/14 21:35, Andrew Stubbs wrote:
On 12/11/14 11:15, Richard Biener wrote:
Please find a better way to communicate possibly_undefined_stmt than
enlarging struct loop. Like associating it with the niter bound
we record (so you can also have more than one).
Unfortunately, the bounds get r
On 12 November 2014 17:47, Charles Baylis wrote:
> On 12 November 2014 15:35, Alan Lawrence wrote:
>> Nice! One nit - can the extra "tree" argument be a "const_tree" ? - I'll
>> defer to the maintainers on the use of C++ default arguments in the AArch64
>> backend. But LGTM.
>
> Thanks, good catc
On 2014.11.19 at 11:20 -0500, David Edelsohn wrote:
> On Wed, Nov 19, 2014 at 10:24 AM, Markus Trippelsdorf
> wrote:
> > bootstrap-ubsan on gcc112 shows a couple of signed integer overflows:
>
> > The fix was tested on powerpc64-unknown-linux-gnu.
> > OK for trunk?
> >
> > Thank you.
> >
> > 2014
On Wed, Nov 19, 2014 at 04:32:43PM +, Andrew Stubbs wrote:
> + if (warning_at (gimple_location (elt->stmt),
> + OPT_Waggressive_loop_optimizations,
> + "Loop exit may only be reached after
> undefined behaviour.
On 19/11/14 11:20, Richard Henderson wrote:
On 10/31/2014 03:51 PM, Renlin Li wrote:
+(define_expand "v2di3"
+ [(parallel [
+(set (match_operand:V2DI 0 "register_operand" "")
+(MAXMIN:V2DI (match_operand:V2DI 1 "register_operand" "")
+ (match_operand:V2DI 2 "register
Of the calls to aarch64_simd_lane_bounds that remain in aarch64-simd.md:
aarch64_get_lanedi
aarch64_im_lane_boundsi
aarch64_ld{2,3,4}_lane
I'll handle the first two. Do we have a plan for ld2/3/4 ?
--Alan
Marcus Shawcroft wrote:
On 12 November 2014 17:47, Charles Baylis wrote:
On 12 November
On 19 November 2014 16:42, Alan Lawrence wrote:
> Of the calls to aarch64_simd_lane_bounds that remain in aarch64-simd.md:
> aarch64_get_lanedi
> aarch64_im_lane_boundsi
> aarch64_ld{2,3,4}_lane
>
> I'll handle the first two. Do we have a plan for ld2/3/4 ?
I'm happy to do those
Charles
On 19 November 2014 16:48, Charles Baylis wrote:
> On 19 November 2014 16:42, Alan Lawrence wrote:
>> Of the calls to aarch64_simd_lane_bounds that remain in aarch64-simd.md:
>> aarch64_get_lanedi
>> aarch64_im_lane_boundsi
>> aarch64_ld{2,3,4}_lane
>>
>> I'll handle the first two. Do we have a p
On 11/19/14 03:46, David Malcolm wrote:
This commit updates jit.exp so that if RUN_UNDER_VALGRIND is present
in the environment, all of the built client code using libgccjit.so is
run under valgrind, with --leak-check=full.
Hence:
RUN_UNDER_VALGRIND= make check-jit
will run all jit testcases
On 11/19/14 03:46, David Malcolm wrote:
Fix this leak:
160 bytes in 5 blocks are definitely lost in loss record 154 of 228
at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5D75D4F: xrealloc (xmalloc.c:177)
by 0x4DE1710: void
va_heap::reserve(vec*
On 11/19/14 03:46, David Malcolm wrote:
This fixes various leaks of vec buffers seen via valgrind within jit
(both recording and playback).
Various vec<> within jit::recording are converted to auto_vec<>.
Various playback::wrapper subclasses containing vec<> gain a finalizer
so they can release
On 11/19/14 04:47, Richard Biener wrote:
On Wed, Nov 19, 2014 at 11:46 AM, David Malcolm wrote:
Valgrind complains about uninitialized data within sparseset_bit_p.
Provide a suppression file to silence these warnings.
Valgrind requires suppression files for C++ code to use the mangled
names, s
On 11/19/14 03:46, David Malcolm wrote:
gcc/testsuite/ChangeLog:
PR jit/63854
* jit.dg/test-fuzzer.c (fuzzer_init): Free malloced buffers.
(make_random_function): Free ff->locals.
OK.
jeff
On 11/19/14 07:58, Richard Henderson wrote:
As opposed to always being a decl. This is a prerequisite
to allowing the static chain to be loaded for indirect calls.
* targhooks.c (default_static_chain): Remove check for
DECL_STATIC_CHAIN.
* config/moxie/moxie.c (moxie_
On Wed, 2014-11-19 at 09:57 -0700, Jeff Law wrote:
> On 11/19/14 03:46, David Malcolm wrote:
> > This commit updates jit.exp so that if RUN_UNDER_VALGRIND is present
> > in the environment, all of the built client code using libgccjit.so is
> > run under valgrind, with --leak-check=full.
> >
> > He
On Wed, 2014-11-19 at 10:09 -0700, Jeff Law wrote:
> On 11/19/14 04:47, Richard Biener wrote:
> > On Wed, Nov 19, 2014 at 11:46 AM, David Malcolm wrote:
> >> Valgrind complains about uninitialized data within sparseset_bit_p.
> >> Provide a suppression file to silence these warnings.
> >>
> >> Val
On Wed, 19 Nov 2014, Chen Gang wrote:
> OK, thanks, what you said sounds reasonable to me. We need '(' and ')'
> for negative members, and "LL" for the members which is larger than 32
> bits.
I don't think LL is a good idea when not needed - quite possibly some of
the macros are expected or requ
On 11/19/14 10:11, David Malcolm wrote:
Thanks - though the patch I posted uses the contrib/valgrind.supp file,
which I added before seeing the --enable-valgrind-annotations configure
option that does a better job of this. So I'll revise it to remove that
suppression file (and add some usage no
On 11/19/14 07:58, Richard Henderson wrote:
And, at the same time, allow indirect calls to have a static chain.
We'll always eliminate the static chain if we can prove it's unused.
* calls.c (prepare_call_address): Allow decl or type for first arg.
(expand_call): Pass type to p
As briefly discussed with Marcus yesterday, I'm attaching two patches
to enable a mode accurate instruction selection and scheduling on the
APM X-Gene 1.
Ok for master?
-Philipp.
Philipp Tomsich (2):
Core definition for APM XGene-1 and associated cost-table.
Pipeline model for APM XGene-1
To keep this change separately buildable from the pipeline model,
this patch directs the APM XGene-1 to use the generic scheduling
model.
---
gcc/ChangeLog| 7 +++
gcc/config/aarch64/aarch64-cores.def | 1 +
gcc/config/aarch64/aarch64-tune.md | 2 +-
gcc/config/aarc
---
gcc/ChangeLog | 6 +
gcc/config/aarch64/aarch64.md | 4 +-
gcc/config/arm/xgene1.md | 739 ++
3 files changed, 748 insertions(+), 1 deletion(-)
create mode 100644 gcc/config/arm/xgene1.md
diff --git a/gcc/ChangeLog b/gcc/Change
Hi,
New revision of Intel ISA reference [1] has new instructions:
Clwb, pcommit and new flavors of AVX512. Patch bellow adds them.
I understand that stage 1 is closed, however those changes shouldn't
affect anything outside if i386 backend. And are extremely unlikely to
break existing functionalit
On 11/19/14 07:58, Richard Henderson wrote:
We need to be able to set the static chain on a few calls within the
Go runtime, so expose this with __builtin_call_with_static_chain.
* c-family/c-common.c (c_common_reswords): Add
__builtin_call_with_static_chain.
* c-famil
OK.
Jason
On Wed, 19 Nov 2014, David Malcolm wrote:
> There's no clean way to release them: retrofitting logic to decide if
> we're dealing with a string literal vs a dynamically-allocated buffer
> (and if something else is pointing to said buffer) is messy and
> error-prone; they are also unconnected to th
Hi Philipp,
The new -mcpu option needs documenting in invoke.texi and a note to
wwwdocs in changes.html would be nice too.
Kyrill
On 19/11/14 17:32, Philipp Tomsich wrote:
To keep this change separately buildable from the pipeline model,
this patch directs the APM XGene-1 to use the generic
To keep this change separately buildable from the pipeline model,
this patch directs the APM XGene-1 to use the generic scheduling
model.
v2: Revised to document -mcpu=xgene1 in invoke.texi
---
gcc/ChangeLog| 8 +++
gcc/config/aarch64/aarch64-cores.def | 1 +
gcc/conf
On 11/19/14 07:15, Ilya Enkovich wrote:
--
2014-11-19 Ilya Enkovich
* Makefile.def: Add libmpx.
* configure.ac: Add libmpx.
* Makefile.in: Regenerate.
* configure: Regenerate.
gcc/
2014-11-19 Ilya Enkovich
* gcc.c (LIBMPX_LIBS): New.
(LIB
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Tony Wang
>
>
> Hi all,
>
> The bug is reported at
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846, and it’s about the
> problem that
> when exception handler is involved in the function, then
> _U
Hi Philipp,
Some comments inline
On 19/11/14 17:32, Philipp Tomsich wrote:
---
gcc/ChangeLog | 6 +
gcc/config/aarch64/aarch64.md | 4 +-
gcc/config/arm/xgene1.md | 739 ++
3 files changed, 748 insertions(+), 1 deletion(-)
On Wed, Nov 19, 2014 at 03:58:50PM +0100, Richard Henderson wrote:
> As opposed to always being a decl. This is a prerequisite
> to allowing the static chain to be loaded for indirect calls.
>
> * targhooks.c (default_static_chain): Remove check for
> DECL_STATIC_CHAIN.
>
Hi Philipp,
One more comment...
On 19/11/14 17:32, Philipp Tomsich wrote:
@@ -4211,3 +4211,5 @@
;; Atomic Operations
(include "atomics.md")
+
+(include "../arm/xgene1.md")
Do you expect to add arm support for this core? If so, you should wire
it up there as well.
If not, I think Andrew
A few other comments.
On Wed, Nov 19, 2014 at 9:32 AM, Philipp Tomsich
wrote:
> ---
> gcc/ChangeLog | 6 +
> gcc/config/aarch64/aarch64.md | 4 +-
> gcc/config/arm/xgene1.md | 739
> ++
> 3 files changed, 748 insertions(+), 1 dele
> I opened:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63963
I am testing the following. This hunk apparently slipped from my earlier patch
Index: tree-streamer-out.c
===
--- tree-streamer-out.c (revision 217668)
+++ tree-stre
2014-11-19 20:55 GMT+03:00 Jeff Law :
> On 11/19/14 07:15, Ilya Enkovich wrote:
>
>> --
>> 2014-11-19 Ilya Enkovich
>>
>> * Makefile.def: Add libmpx.
>> * configure.ac: Add libmpx.
>> * Makefile.in: Regenerate.
>> * configure: Regenerate.
>>
>> gcc/
>>
>> 2014-11-
> On Fri, Nov 14, 2014 at 11:13 AM, Jan Hubicka wrote:
nz
> > Hi,
> > this patch kills lto's code to rebuilt DECL_FUNCTION_SPECIFIC_TARGET from
> > target
> > attributes. This code was never complete and it should be no-op now when
> > we save
> > tehe target nodes.
> > It also makes free_land_
Hi!
I've bootstrapped/regtested this patch for Manuel (just small formatting
changes from me), and committed to trunk.
2014-11-19 Manuel López-Ibáñez
Jakub Jelinek
PR driver/36312
PR driver/63837
* gcc.c (process_command): Don't check for input/output
I've committed the cut-down version of the gimple statement subclasses
work to svn trunk [specifically the gimple-classes-v2-option-3 git
branch, having bootstrapped®rested it on x86_64-unknown-linux-gnu
(Fedora 20)].
This is the the 89-patch kit from
https://gcc.gnu.org/ml/gcc-patches/2014-04/
On 11/19/14 06:12, Richard Biener wrote:
PR63677 shows that late complete unrolling can expose quite some memory
CSE opportunities
Yes, we saw the same thing with unrolling in RTL. So this is not a
surprise at all.
(and followup simplifications) which we fail to
exploit because currently
On 11/19/14 03:46, David Malcolm wrote:
We weren't cleaning up the context, pass_manager or dump_manager.
An earlier version of the context and pass_manager classes had them
allocated in the GC-heap, but they were moved to the system heap
before that patch was committed; they were never cleaned
On 11/13/2014 10:47 AM, Andrew Pinski wrote:
On Thu, Nov 13, 2014 at 9:42 AM, Sandra Loosemore
wrote:
On 11/13/2014 10:27 AM, Richard Earnshaw wrote:
On 13/11/14 17:05, Ramana Radhakrishnan wrote:
On Thu, Nov 13, 2014 at 4:55 PM, Sandra Loosemore
wrote:
This patch to the AArch64 back end
I forgot to mention that i have no write privileges, please commit
this for me if it's OK
On Wed, Nov 12, 2014 at 5:45 PM, mliska wrote:
> gcc/ChangeLog:
>
> 2014-11-13 Martin Liska
>
> * bb-reorder.c (mark_bb_visited): New fibonacci_heap is used.
> (find_traces): Likewise.
> (find_traces_1_round): Likewise.
This caused:
https://gcc.gnu.org/bugzilla/show_bu
On Nov 19, 2014, at 4:24 AM, Richard Biener wrote:
> On Wed, 19 Nov 2014, Jakub Jelinek wrote:
>> For TARGET_SUPPORTS_WIDE_INT == 0 should be hopefully ok. Not sure
>> about TARGET_SUPPORTS_WIDE_INT != 0, can it express any generic_wide_int, or
>> is it still bound to wide_int (i.e. MAX_BITSIZE_M
On Wed, Nov 19, 2014 at 10:11 AM, Jan Hubicka wrote:
>> On Fri, Nov 14, 2014 at 11:13 AM, Jan Hubicka wrote:
> nz
>> > Hi,
>> > this patch kills lto's code to rebuilt DECL_FUNCTION_SPECIFIC_TARGET from
>> > target
>> > attributes. This code was never complete and it should be no-op now when
>>
On Wed, Nov 19, 2014 at 8:16 AM, Paolo Carlini wrote:
> Good. To be clear, not having carefully analyzed whatsoever, my point was
> more about changing _M_end too, to non-const, than about not touching
> _M_begin. Would that make sense?
Currently we never mutate _M_end. I *believe* that we still
On Wed, 2014-11-19 at 09:57 -0700, Jeff Law wrote:
> On 11/19/14 03:46, David Malcolm wrote:
> > This commit updates jit.exp so that if RUN_UNDER_VALGRIND is present
> > in the environment, all of the built client code using libgccjit.so is
> > run under valgrind, with --leak-check=full.
> >
> > He
2014-11-19 19:42 GMT+01:00 Tim Shen :
> On Wed, Nov 19, 2014 at 8:16 AM, Paolo Carlini
> wrote:
>> Good. To be clear, not having carefully analyzed whatsoever, my point was
>> more about changing _M_end too, to non-const, than about not touching
>> _M_begin. Would that make sense?
>
> Currently w
On Nov 19, 2014, at 4:07 AM, Jakub Jelinek wrote:
>
> For TARGET_SUPPORTS_WIDE_INT == 0 should be hopefully ok. Not sure
> about TARGET_SUPPORTS_WIDE_INT != 0, can it express any generic_wide_int, or
> is it still bound to wide_int (i.e. MAX_BITSIZE_MODE_ANY_INT rounded up)
> precision? Mike?
Hi,
On 11/19/2014 07:43 PM, Daniel Krügler wrote:
2014-11-19 19:42 GMT+01:00 Tim Shen :
On Wed, Nov 19, 2014 at 8:16 AM, Paolo Carlini wrote:
Good. To be clear, not having carefully analyzed whatsoever, my point was
more about changing _M_end too, to non-const, than about not touching
_M_begi
Sorry. I ran 'make check-go' assuming it ran both m32 and m64 on a
ppc64 machine. I'll fix and retest.
On 11/19/2014 10:08 AM, Segher Boessenkool wrote:
On Wed, Nov 19, 2014 at 09:01:35AM -0600, Lynn A. Boger wrote:
+ "powerpc-*-*" {
+ set goarch "ppc"
}
+ "pow
We can't rely on valp continuing to be a pointer into the hash table
slot. I fixed that earlier for the store, but forgot to fix the return
statement as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit dfac7dd2d46c5c0f52f6138c68d7e926d90f99be
Author: jason
Date: Wed Nov 19 19:03:
On 19 November 2014 16:51, Marcus Shawcroft wrote:
>
> In the meantime could you respin the patch to drop the default args
> and pass explicit NULL ?
Done.
Charles Baylis
PR target/63870
* config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args): Pass
expression
On Nov 19, 2014, at 5:51 AM, FX wrote:
> The attached patch fixes 23 asan testsuite failures on x86_64-apple-darwin14,
> where the backtrace features e.g. wrap_malloc instead of interceptor_malloc.
> So I adjusted the dg-output patterns to match.
>
> OK to commit to trunk?
Ok. If anyone has a
As discussed in the PR, the problem here is that when running gfortran,
the __builtin_object_size decl isn't available, because c-family's
c_define_builtins wasn't called. One way how to fix this is to build
the __builtin_object_size decl in initialize_sanitizer_builtins, if
needed. Alternatively
On 11/19/2014 02:50 AM, Bernd Schmidt wrote:
@@ -8417,6 +8926,9 @@ expand_omp_target (struct omp_region *region)
/* Add the new function to the offload table. */
vec_safe_push (offload_funcs, child_fn);
+ /* Add the new function to the offload table. */
+ vec_safe_pu
On 11/19/2014 01:12 PM, David Malcolm wrote:
(A) could become:
greturn *stmt = gsi->as_a_greturn ();
(B) could become:
stmt = gsi->dyn_cast ();
if (!stmt)
or:
stmt = gsi->dyn_cast_gcall ();
if (!stmt)
or maybe:
stmt = gsi->is_a_gcall ();
if (!stmt)
An earlier ver
Kyrill,
The XGene-cores all support AArch32.
We plan to wire this up, but I’d like to merge this as-is (i.e. without wiring
it up for AArch32) initially, as we haven’t done the same amount of QA on these
with AArch32 as with AArch64.
Do you have any issue with this going into the config/arm-dir
On Wed, Nov 19, 2014 at 10:54 AM, Paolo Carlini
wrote:
> I was just aiming for consistency, from a very, very, general point of view.
Not a problem. Thank you actually, since it's obviously good for us :)
--
Regards,
Tim Shen
On 11/19/14 03:46, David Malcolm wrote:
Valgrind showed a leak of 1640 bytes per iteration of one of the jit
testcases (I think this is per-function in a compile):
8,200 bytes in 5 blocks are definitely lost in loss record 214 of 223
at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_me
Another change that's required is (something like) the following. For
ptx, we need to know whether to output something as a .func (callable
from ptx code) or a .kernel (callable from the host). That means we need
to mark the kernel functions somehow in omp-low.c, and the following
does that by
On Wed, Nov 19, 2014 at 10:04 AM, Jakub Jelinek wrote:
> On Wed, Nov 19, 2014 at 03:58:50PM +0100, Richard Henderson wrote:
>> As opposed to always being a decl. This is a prerequisite
>> to allowing the static chain to be loaded for indirect calls.
>>
>> * targhooks.c (default_static_cha
On 11/19/14 03:46, David Malcolm wrote:
This fixes three leaks in IPA seen in jit testcases with valgrind:
This one:
96 bytes in 4 blocks are definitely lost in loss record 102 of 205
at 0x4A0645D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5D76447: xmalloc (
On Wed, 2014-11-19 at 09:59 -0700, Jeff Law wrote:
> On 11/19/14 03:46, David Malcolm wrote:
> > Fix this leak:
> >
> > 160 bytes in 5 blocks are definitely lost in loss record 154 of 228
> > at 0x4A0645D: malloc (in
> > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> > by 0x5D75D
On 15-11-14 13:14, Tom de Vries wrote:
Don't allow flto-partition=balance for fopenacc
Unsubmitted. This works around a compilation problem for
libgomp/testsuite/libgomp.oacc-c-c++-common/asyncwait-2.c that I ran into on
our internal dev branch. I'll investigate whether I can repro
On 11/19/2014 11:44 AM, Bernd Schmidt wrote:
> I'm attaching the patch in the form in which I've made it work locally,
> plus Cesar's patch which is needed on top of it. Julian, you'll probably
> want to look for that patch since it also included testsuite changes.
> Cesar - have a look over this
On 19/11/14 16:39, Marek Polacek wrote:
On Wed, Nov 19, 2014 at 04:32:43PM +, Andrew Stubbs wrote:
+if (warning_at (gimple_location (elt->stmt),
+OPT_Waggressive_loop_optimizations,
+"Loop exit may on
Hello!
Carry flag checks from overflow tests can propagate into FP cmove
instructions. However, while "c" and "nc" suffixes are allowed as
suffixes in integer cmove insns, they are not allowed in FP cmove
insns. Patch generates equivalent "b" and "nb" suffixes for FP mode.
2014-11-19 Uros Bizjak
Hi,
after Martin's ipa-cp reorg, get_binfo_at_offset is finally used only
for lookup of base at given offset (not to walk into fields that it
used to do too even if it is not documented and old BINFO code in
ipa-cp relied on it.)
This also allows us to drop BINFOs that are not important for
debug o
On November 19, 2014 8:26:23 PM CET, Andrew MacLeod wrote:
>On 11/19/2014 01:12 PM, David Malcolm wrote:
>
>>
>> (A) could become:
>>
>>greturn *stmt = gsi->as_a_greturn ();
>>
>> (B) could become:
>>
>>stmt = gsi->dyn_cast ();
>>if (!stmt)
>
>> or:
>>
>>stmt = gsi->dyn_cast_gcall
Updated patch:
Index: gcc/testsuite/go.test/go-test.exp
===
--- gcc/testsuite/go.test/go-test.exp (revision 217768)
+++ gcc/testsuite/go.test/go-test.exp (working copy)
@@ -241,7 +241,11 @@ proc go-set-goarch { } {
if
Hello!
libcpp/lex.c includes "../gcc/config/i386/cpuid.h", and is picked up
by the system compiler during stage1. Recently, cpuid.h was changed to
account for %ebx changes and now uses "b" asm constraint for i686 even
with __PIC__.
Attached patch solves this issue by including system for GCC < 5
On 11/19/2014 03:43 PM, Richard Biener wrote:
On November 19, 2014 8:26:23 PM CET, Andrew MacLeod wrote:
On 11/19/2014 01:12 PM, David Malcolm wrote:
(A) could become:
greturn *stmt = gsi->as_a_greturn ();
(B) could become:
stmt = gsi->dyn_cast ();
if (!stmt)
or:
stmt = g
On November 19, 2014 10:09:56 PM CET, Andrew MacLeod
wrote:
>On 11/19/2014 03:43 PM, Richard Biener wrote:
>> On November 19, 2014 8:26:23 PM CET, Andrew MacLeod
> wrote:
>>> On 11/19/2014 01:12 PM, David Malcolm wrote:
>>>
(A) could become:
greturn *stmt = gsi->as_a_greturn ()
Here's an updated patch with Kyrill's and Andrew's comments integrated.
I left the file in the config/arm-directory, as XGene-family is capable of
executing ARMv7 and we will wire this into the 32bit backend in the near
future (moving it now would just cause another move in the near future).
We
Jakub Jelinek writes:
> On Wed, Nov 19, 2014 at 09:59:45AM +0100, Richard Biener wrote:
>> > OImode/XImode on i?86/x86_64 are not <= MAX_BITSIZE_MODE_ANY_INT, because
>> > they are never used for integer arithmetics (and there is no way
>> > to represent all their values in RTL if not using CONST_
On Wed, Nov 19, 2014 at 10:38:57AM -0800, Mike Stump wrote:
> On Nov 19, 2014, at 4:24 AM, Richard Biener wrote:
> > On Wed, 19 Nov 2014, Jakub Jelinek wrote:
> >> For TARGET_SUPPORTS_WIDE_INT == 0 should be hopefully ok. Not sure
> >> about TARGET_SUPPORTS_WIDE_INT != 0, can it express any gener
In some cases we were accepting in constant-expressions const variables
of non-integral type, which is not correct; variables of non-integral
type must be marked constexpr to be usable in constant expressions.
When fixing this we need to preserve the optimization that lets us use
such constant
On Wed, Nov 19, 2014 at 08:52:40PM +0100, Bernd Schmidt wrote:
> Another change that's required is (something like) the following. For ptx,
> we need to know whether to output something as a .func (callable from ptx
> code) or a .kernel (callable from the host). That means we need to mark the
> ker
In this testcase we found ourselves trying to evaluate the address of a
CONSTRUCTOR and didn't have an object for the CONSTRUCTOR to associate
with. Fixed by handling lvalue uses of TARGET_EXPR properly. And then
we needed to fix handling of REFERENCE_TYPE parameters in the new call
mechanism
> Ok. If anyone has a better idea, feel free to suggest it.
Thanks, committed along with the same trivial patch for
g++.dg/asan/large-func-test-1.C.
FX
2014-11-19 Francois-Xavier Coudert
PR sanitizer/63939
* g++.dg/asan/large-func-test-1.C: Ajust dg-output.
Index: g++.d
Alessandro Fanfarillo wrote:
The sum of the three indexes, k, j and i returns a wrong image index.
Fixed as confirmed off list by the attached patch.
I intent to commit it as obvious once building and regtesting has
finally finished.
Comments are nontheless welcome.
Tobias
* trans-expr.c
101 - 200 of 231 matches
Mail list logo
