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
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?
> 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 t
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
> >
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
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 f
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 for t
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 GC
On Tue, Mar 4, 2014 at 8:03 PM, Patrick Palka wrote:
> On Tue, Mar 4, 2014 at 10:34 PM, Ian Lance Taylor 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 patc
On Tue, Mar 4, 2014 at 10:34 PM, Ian Lance Taylor 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 qsort function.
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 wron
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.
On Sat, Mar 1, 2014 at 2:19 AM, Richard Biener
wrote:
> On Fri, Feb 28, 2014 at 7:23 PM, H.J. Lu wrote:
>> On Fri, Feb 28, 2014 at 9:42 AM, H.J. Lu wrote:
>>> On Fri, Feb 28, 2014 at 9:25 AM, H.J. Lu wrote:
On Fri, Feb 28, 2014 at 8:11 AM, H.J. Lu wrote:
> On Fri, Feb 28, 2014 at 2:09
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
gcc/testsuite/gfortran.dg/
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 EXEC_OACC_E
On Tue, Feb 18, 2014 at 8:58 PM, Richard Henderson 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. Consider these t
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
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 dec
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
A
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 a
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.
---
gcc/cp/parser
Richard Sandiford writes:
> Andrew Bennett 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 bugzilla URL is the following:
>>
>> ht
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 (
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.
---
gcc/cp
>
> 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
> 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
>
> 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) L
On Tue, Mar 4, 2014 at 1:13 AM, Uros Bizjak wrote:
> On Tue, Mar 4, 2014 at 12:31 AM, Uros Bizjak 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 errors:
/v
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
> -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 s
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
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!
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 Ja
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
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.
A
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
templa
Ping.
On Thu, Feb 27, 2014 at 12:32 PM, Kito Cheng 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
> +++ b/gcc/co
On Tue, Mar 4, 2014 at 10:04 AM, Kirill Yukhin wrote:
> Hello Uroš,
> On 04 Mar 01:13, Uros Bizjak wrote:
>> On Tue, Mar 4, 2014 at 12:31 AM, Uros Bizjak wrote:
>> > They are all:
>> >
>> > FAIL: gcc.target/i386/avx512pf-vscatterpf0dpd-1.c (test for excess errors)
>> > Excess errors:
>> > /ssd/ur
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 mis
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, could
Committed.
commit b4039fa151c772e0994407d4dc69b0ac9cff567a
Author: Jonathan Wakely
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
@@ -198,7 +198,7 @@
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 wrote:
> > >
> > > We're doing the LTO bytecode version check only for two section
> > > types at the moment - specifically _not_ for the first sectio
On Tue, 4 Mar 2014, Jan-Benedict Glaw wrote:
> On Tue, 2014-03-04 12:22:12 +0100, 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 rep
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, 2014-03-04 12:22:12 +0100, 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 ...
>
> Fixed by doing the
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 link
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 objects
o
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 (expand_builtin_setjmp_r
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 x86_64
"Paulo J. Matos" 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.
>>
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 fai
On Tue, Mar 4, 2014 at 12:02 PM, Paulo J. Matos 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)
>> @@ -114
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 tim
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
(a
Richard Biener writes:
> On Mon, Mar 3, 2014 at 11:01 PM, Richard Sandiford
> 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 m
On Mon, Mar 3, 2014 at 11:01 PM, Richard Sandiford
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 hard frame pointer
Thanks Jakub
--
Regards
lin zuojian
On Tue, Mar 04, 2014 at 10:15:31AM +0100, Jakub Jelinek wrote:
> 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:
>
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.
> > >
Hello Uroš,
On 04 Mar 01:13, Uros Bizjak wrote:
> On Tue, Mar 4, 2014 at 12:31 AM, Uros Bizjak 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: the
> > l
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 shif
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 testi
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 (
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/lo
63 matches
Mail list logo
