On Tue, Mar 04, 2014 at 11:11:45AM +0800, lin zuojian wrote:
Without aligning the asan stack base,this base will only 64-bit aligned in
ARM machines.
But asan require 256-bit aligned base because of this:
1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros
2.store multiple/load
Hi!
This patch attempts to fix a regression caused by the
http://gcc.gnu.org/r208220 change.
In particular, because cselib_reset_table called immediately after
cselib_preserve_only_values removes VALUEs with zero locs and thus clears
n_useless_values, if we don't remove_useless_values right away
This fixes PR60382 where the vectorizer identified a double-reduction
it cannot later re-identify properly. The only reasonable fix at this
point is to not identify that as a double-reduction.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk,
will apply to branch after
On Tue, Mar 04, 2014 at 09:04:56AM +0100, Jakub Jelinek wrote:
On Tue, Mar 04, 2014 at 11:11:45AM +0800, lin zuojian wrote:
Without aligning the asan stack base,this base will only 64-bit aligned in
ARM machines.
But asan require 256-bit aligned base because of this:
1.right shift take
Hello Uroš,
On 04 Mar 01:13, Uros Bizjak wrote:
On Tue, Mar 4, 2014 at 12:31 AM, Uros Bizjak ubiz...@gmail.com wrote:
They are all:
FAIL: gcc.target/i386/avx512pf-vscatterpf0dpd-1.c (test for excess errors)
Excess errors:
/ssd/uros/gcc-build/gcc/include/avx512pfintrin.h:108:3: error:
On Tue, Mar 04, 2014 at 04:44:57PM +0800, lin zuojian wrote:
On Tue, Mar 04, 2014 at 09:04:56AM +0100, Jakub Jelinek wrote:
On Tue, Mar 04, 2014 at 11:11:45AM +0800, lin zuojian wrote:
Without aligning the asan stack base,this base will only 64-bit aligned
in ARM machines.
But asan
On Mon, Mar 3, 2014 at 11:01 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
AIUI:
(1) The main point of http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01172.html
was that we had:
emit_move_insn (virtual_stack_vars_rtx, hard_frame_pointer_rtx);
/* This might change the
Richard Biener richard.guent...@gmail.com writes:
On Mon, Mar 3, 2014 at 11:01 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
AIUI:
(1) The main point of http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01172.html
was that we had:
emit_move_insn (virtual_stack_vars_rtx,
This merges -O options given at compile-time into a single
optimization level to be used for LTO link time (but
overridden with whatever is specified at LTO link time - unless
no optimization level is specified there). That is, it
determines a default optimization level used at LTO link time
(as
On 03/03/14 09:56, Richard Biener wrote:
Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt (revision 208249)
+++ gcc/c-family/c.opt (working copy)
@@ -1141,7 +1141,7 @@ C++ ObjC++ Optimization Var(flag_rtti) I
Generate run
On Tue, Mar 4, 2014 at 12:02 PM, Paulo J. Matos pa...@matos-sorge.com wrote:
On 03/03/14 09:56, Richard Biener wrote:
Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt (revision 208249)
+++ gcc/c-family/c.opt (working copy)
On 04/03/14 11:16, Richard Biener wrote:
It works fine on i386 for me but fails on x86_64. Please add a
/* { dg-skip-if PR-you-open { { x86_64-*-* i?86-*-* } lp64 } {
* } { } } */
to the testcase to avoid the regression in the testsuite.
Apologies, you're right. I meant x86_64 fails here
Paulo J. Matos pa...@matos-sorge.com writes:
On 04/03/14 11:16, Richard Biener wrote:
It works fine on i386 for me but fails on x86_64. Please add a
/* { dg-skip-if PR-you-open { { x86_64-*-* i?86-*-* } lp64 } {
* } { } } */
to the testcase to avoid the regression in the testsuite.
We're doing the LTO bytecode version check only for two section
types at the moment - specifically _not_ for the first section
we read. Which causes us to crash instead of reporting a
version mismatch ...
Fixed by doing the version check in the most appropriate place.
LTO bootstrapped on
On 03/03/2014 11:01 PM, Richard Sandiford wrote:
I'll run a full test overnight, but does this look like it might be
a way out, at least for 4.9?
Pretty much agree with everything you've written in this thread. I
think this patch is fine.
gcc/
* builtins.c
On Tue, 2014-03-04 12:22:12 +0100, Richard Biener rguent...@suse.de wrote:
We're doing the LTO bytecode version check only for two section
types at the moment - specifically _not_ for the first section
we read. Which causes us to crash instead of reporting a
version mismatch ...
Fixed by
Hi all!
We would like to test LeakSanitizer during our working process, but
there is no any testcase to do it in gcc at this moment . Do you think
it would make sense to add support for LeakSanitizer testing? If the
answer is positive, we can work on dg infrastructure (lsan-dg.exp,
lsan.exp)
On Tue, 4 Mar 2014, Jan-Benedict Glaw wrote:
On Tue, 2014-03-04 12:22:12 +0100, Richard Biener rguent...@suse.de wrote:
We're doing the LTO bytecode version check only for two section
types at the moment - specifically _not_ for the first section
we read. Which causes us to crash
On Tue, 4 Mar 2014, Richard Biener wrote:
On Tue, 4 Mar 2014, Jan-Benedict Glaw wrote:
On Tue, 2014-03-04 12:22:12 +0100, Richard Biener rguent...@suse.de wrote:
We're doing the LTO bytecode version check only for two section
types at the moment - specifically _not_ for the first
Committed.
commit b4039fa151c772e0994407d4dc69b0ac9cff567a
Author: Jonathan Wakely jwak...@redhat.com
Date: Tue Mar 4 12:53:35 2014 +
* MAINTAINERS: Update my email address.
diff --git a/MAINTAINERS b/MAINTAINERS
index 70c10d4..834052e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
On Tue, 4 Mar 2014, Richard Biener wrote:
We're doing the LTO bytecode version check only for two section
types at the moment - specifically _not_ for the first section
we read. Which causes us to crash instead of reporting a
version mismatch ...
Not for 4.9, but when the object is fat,
On Tue, 4 Mar 2014, Marc Glisse wrote:
On Tue, 4 Mar 2014, Richard Biener wrote:
We're doing the LTO bytecode version check only for two section
types at the moment - specifically _not_ for the first section
we read. Which causes us to crash instead of reporting a
version mismatch ...
On Tue, Mar 4, 2014 at 10:04 AM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Hello Uroš,
On 04 Mar 01:13, Uros Bizjak wrote:
On Tue, Mar 4, 2014 at 12:31 AM, Uros Bizjak ubiz...@gmail.com wrote:
They are all:
FAIL: gcc.target/i386/avx512pf-vscatterpf0dpd-1.c (test for excess errors)
Ping.
On Thu, Feb 27, 2014 at 12:32 PM, Kito Cheng kito.ch...@gmail.com wrote:
Hi all:
Sorry for repeat patch content in last mail, here is the clean version
for this patch.
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 7ca47a7..1638332 100644
--- a/gcc/config/arm/arm.h
Hi,
this regression is just an ICE on invalid, but I'm finding it somewhat
tricky. Let's see if I can explain clearly enough what I figured out so far.
The problem manifests itself when is_valid_constexpr_fn is called by
explain_invalid_constexpr_fn with a TEMPLATE_DECL (the inherited
Hi!
As discussed in the PR, the assumption that in !optimize functions
all SSA_NAMEs for a particular PARM_DECL or RESULT_DECL can be coalesced
together is wrong for -flto, if you compile with optimizations the object
file and then link with -O0 -flto, because the SSA_NAMEs can already
overlap.
This should fix ICE on insane alignment. Normally, check_user_alignment
detects e.g. alignment 1 32, but not 1 28. However, record_align
is in bits, so it's actually 8 * (1 28) and that's greater than
INT_MAX. This patch rejects such code.
In the middle hunk, we should give up when an error
Hi!
With some -march=/-mtune= flags even i?86/x86_64 has BRANCH_COST 1 and
various tests fail, furthermore ssa-ifcombine-ccmp* apparently fail on e.g.
s390* or some arm variants.
This patch tries to fix that up.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2014-03-04
Hi,
I have been accidentally not testing -m32 for the last few weeks, so I
missed some compatibility issues with recent tests. vector long
produces 2x64 vectors for -m64, but 4x32 vectors for -m32. This caused
some of the tests to fail on the AIX tester. For compatibility across
both, I need
Hi Ilmir,
thanks for the update.
Ilmir Usmanov wrote:
I'd use integer instead of INTEGER as it is not a 'reserved' word
OpenMP implementation uses capital letters, so, perhaps, we also
should do this, for consistency?
Fine with me - I don't feel strong about it.
OpenACC 1.0 support to
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Marek Polacek
Sent: Wednesday, February 19, 2014 8:39 AM
To: Iyer, Balaji V
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Properly check for _Cilk_spawn in return stmt
Ilmir Usmanov:
OpenACC 1.0 support to fortran FE -- core.
+ case OMP_LIST_USE_DEVICE:
+ if (n-sym-attr.allocatable)
+ gfc_error (ALLOCATABLE object '%s' of polymorphic type
+ in %s clause at %L, n-sym-name, name,
code-loc);
That
On Tue, Mar 4, 2014 at 1:13 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Mar 4, 2014 at 12:31 AM, Uros Bizjak ubiz...@gmail.com wrote:
The new gcc.target/i386/prefetchwt1-1.c test currently FAILs on Solaris
9/x86:
FAIL: gcc.target/i386/prefetchwt1-1.c (test for excess errors)
Excess
The following patch addresses the common (?) issue of people
omitting -flto from the linker command-line which gets more
severe with GCC 4.9 where slim LTO objects are emitted by
default. The patch simply _always_ arranges for the linker
plugin to be used, so if there are any (slim) LTO
On 2014.03.04 at 13:00 +0100, Richard Biener wrote:
The following patch addresses the common (?) issue of people
omitting -flto from the linker command-line which gets more
severe with GCC 4.9 where slim LTO objects are emitted by
default. The patch simply _always_ arranges for the
This merges -O options given at compile-time into a single
optimization level to be used for LTO link time (but
overridden with whatever is specified at LTO link time - unless
no optimization level is specified there). That is, it
determines a default optimization level used at LTO link
PR c++/60033
* pt.c (retrieve_specialization): When retrieving a capture pack from a
generic lambda, remove the lambda's own template argument list prior to
fetching the specialization.
PR c++/60033
* g++.dg/cpp1y/pr60033.C: New testcase.
---
Committed to branch dmalcolm/jit:
gcc/jit/
* libgccjit.h (gcc_jit_type_get_volatile): New.
* libgccjit.map (gcc_jit_type_get_volatile): New.
* libgccjit.c (gcc_jit_type_get_volatile): New.
* libgccjit++.h (gccjit::type::get_volatile): New.
* internal-api.c
Richard Sandiford rdsandif...@googlemail.com writes:
Andrew Bennett andrew.benn...@imgtec.com writes:
Hi,
I have noticed that a patch was placed in bugzilla to do this change, but it
does not appear to have been pushed. I was wondering if anyone could comment
why this is the case?
The
PR c++/60393
* parser.c (cp_parser_parameter_declaration_clause): Move generic
function template unwinding on error into a move general location, ...
(cp_parser_error): ... here.
PR c++/60393
* g++.dg/cpp1y/pr60393.C: New testcase.
---
Committed to branch dmalcolm/jit:
gcc/jit/
* internal-api.c (gcc::jit::recording::memento_of_get_pointer::
accepts_writes_from): Avoid segfaulting when the argument is not
of pointer type.
* internal-api.h (gcc::jit::recording::accepts_writes_from): Add
an
We shouldn't give a hard error about a qualified-id in a function-local
declarator when we're parsing tentatively. Easy enough to fix by
marking the declarator as erroneous when we see the problem.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit a758d04379a1bd0752bdcee9695a6d0d953a59ac
In C++11, copy-list-initialization by explicit constructor is an error,
even for the default constructor. But this combined with the change of
aggregate initialization to use {} for any missing initializers means
that well-formed C++03 code becomes ill-formed in C++11. Until the
committee
I've added an initial Porting to GCC 4.9 page at
http://gcc.gnu.org/gcc-4.9/porting_to.html
So far it only contains a couple of C++ changes that caused some
failures during mass rebuilds, other additions are welcome.
--- /dev/null 2014-02-20 09:50:47.841935984 +
+++ porting_to.html
On Tue, Feb 18, 2014 at 8:58 PM, Richard Henderson r...@redhat.com wrote:
On 02/16/2014 03:59 PM, Nathaniel Smith wrote:
Yes, but the problem is that depending on what the user intends to do
after forking, our pthread_atfork handler might help or it might hurt,
and we don't know which.
Ilmir Usmanov wrote:
OpenACC 1.0 fortran FE support -- translation to GENERIC.
--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -1850,6 +1850,21 @@ trans_code (gfc_code * code, tree cond)
...
+ case EXEC_OACC_PARALLEL:
+ case EXEC_OACC_PARALLEL_LOOP:
+case
Ilmir Usmanov wrote:
OpenACC 1.0 fortran FE support -- tests.
I have browsed through those patches and haven't spotted anything;
however, I have not carefully checked against the OpenACC spec nor
really checked every patch. But at a glance, it looks okay.
Tobias
Hi,
I have summited a patch in this ml.But the difficult part may be the
code formatting.I am using vim as my editor.
--
Regards
lin zuojian.
The GNU glibc qsort function will call malloc in some cases. That makes
it unsuitable for libbacktrace, which is intended to work when called
from a signal handler. This patch changes libbacktrace to use an
internal qsort function.
I'm posting this for comments in case anybody sees anything
On Tue, Mar 4, 2014 at 10:34 PM, Ian Lance Taylor i...@google.com wrote:
The GNU glibc qsort function will call malloc in some cases. That makes
it unsuitable for libbacktrace, which is intended to work when called
from a signal handler. This patch changes libbacktrace to use an
internal
On Tue, Mar 4, 2014 at 8:03 PM, Patrick Palka patr...@parcs.ath.cx wrote:
On Tue, Mar 4, 2014 at 10:34 PM, Ian Lance Taylor i...@google.com wrote:
The GNU glibc qsort function will call malloc in some cases. That makes
it unsuitable for libbacktrace, which is intended to work when called
from
On Wed, Mar 05, 2014 at 11:31:59AM +0800, lin zuojian wrote:
Hi,
I have summited a patch in this ml.But the difficult part may be the
code formatting.I am using vim as my editor.
I'm not sure what you asking for here. But to learn how to format
your code, I think just look at the GCC
On Wed, Mar 05, 2014 at 07:28:35AM +0100, Marek Polacek wrote:
On Wed, Mar 05, 2014 at 11:31:59AM +0800, lin zuojian wrote:
Hi,
I have summited a patch in this ml.But the difficult part may be the
code formatting.I am using vim as my editor.
I'm not sure what you asking for here.
I'm not sure what you asking for here. But to learn how to format
your code, I think just look at the GCC source code and model your
code after that.
I am not understanding the standard.For example,should I use \t
instead of space?Should I use 4 spaces as indent or 2?
My understanding
Am 04.03.2014 13:30, schrieb Markus Trippelsdorf:
What is missing is a big fat warning in
http://gcc.gnu.org/gcc-4.9/changes.html that one should use the gcc
binutils wrappers (gcc-ar, etc.) when building projects with LTO.
Is this enough? Or should the autoconf macros changed to look
On Wed, Mar 05, 2014 at 10:56:39AM +0400, Yury Gribov wrote:
I'm not sure what you asking for here. But to learn how to format
your code, I think just look at the GCC source code and model your
code after that.
I am not understanding the standard.For example,should I use \t
instead
That is not true. The indentation style is:
http://www.gnu.org/prep/standards/standards.html#Formatting
...
The above also mentions particular options
for GNU indent which set various rules.
Ah, good to know. So, are contributors expected to run indent on their
changes before sending patches?
On Wed, Mar 05, 2014 at 11:29:07AM +0400, Yury Gribov wrote:
That is not true. The indentation style is:
http://www.gnu.org/prep/standards/standards.html#Formatting
...
The above also mentions particular options
for GNU indent which set various rules.
Ah, good to know. So, are
58 matches
Mail list logo
