> From: Jakub Jelinek [mailto:ja...@redhat.com]
> > n->size = n1.size;
> > + for (i = 0, mask = 0xff; i < n->size; i++, mask <<= 8)
>
> This should be mask <<= BITS_PER_UNIT for consistency.
Indeed.
>
> And, as has been said earlier, the testcase should be a runtime testcase
> (in gcc
When using Cilk Plus (-fcilkplus), it makes sense to automatically link
the run-time library (-lcilkrts).
This patch mimics libgomp by adding a .spec file; I am not 100% sure
whether the .spec file is needed, but the pthread tests in libgomp imply
that it makes sense. (libgomp also checks for
On Mon, 3 Mar 2014, Richard Sandiford wrote:
> AIUI:
Reading back the references don't yield any dissenting
flash-backs, FWIW.
So, a (use fp) then a (clobber fp)? That was probably just too
weird for me to think of, much like a hypercorrect ending of the
previous clause. :)
Thanks for dealing w
Richard wrote:
> The thread seems to have died down,
> so should I go ahead and install it?
Looks like all reviews were more or less positive...
-Y
A comment in arm/sync.md notes "We should consider issuing a inner
shareability zone barrier here instead." Here is my first attempt
at a patch to emit weaker memory barriers. Three instructions seem
to be relevant for user mode code on my Cortex A9 Linux box:
dmb ishst, dmb ish, dmb sy
I belie
On Mon, 10 Mar 2014, Ian Bolton wrote:
> OK for trunk or stage 1?
OK for trunk with the ChangeLog entry fixed (it's in c-family/ChangeLog,
so no gcc/c-family/ in the entry itself, and the date should be in
-mm-dd format).
--
Joseph S. Myers
jos...@codesourcery.com
Tested on x86_64-suse-linux, applied on the mainline.
2014-03-10 Eric Botcazou
* gcc-interface/Make-lang.in (ADA_DEPFILES): Fix typo.
--
Eric BotcazouIndex: gcc-interface/Make-lang.in
===
--- gcc-interface/Make-lang.in
The problem was that we were failing to call convert_for_arg_passing
when the default argument is a CONSTRUCTOR. I wasn't sure why I had
added the CONSTRUCTOR special case in the first place, and looked back
in git blame to see when it had come in...and found that it dated back
to a Cygnus G++
Committed to branch dmalcolm/jit:
Attempting to repeatedly compile with optimizations on within one
process would, under some circumstances, lead to a segfault the second
time in, here:
#0 splay_tree_delete (sp=0x0) at ../../src/libiberty/splay-tree.c:353
#1 0x777f104f in propagate ()
Ok.
David
On Mon, Mar 10, 2014 at 1:28 PM, Teresa Johnson wrote:
> This patch adds dummy references to libgcov for the symbols accessed
> via weak references from application code to ensure they are resolved
> at link time. Passes regression tests. Ok for google-4_8?
>
> Thanks,
> Teresa
>
> 201
This patch adds dummy references to libgcov for the symbols accessed
via weak references from application code to ensure they are resolved
at link time. Passes regression tests. Ok for google-4_8?
Thanks,
Teresa
2014-03-10 Teresa Johnson
Google ref b/13338320.
* libgcov-driver.c: Add dummy r
Committed to branch dmalcolm/jit:
gcc/jit/
* libgccjit++.h (gccjit::context::new_rvalue): Make these
methods const.
(gccjit::context::zero): Likewise.
(gccjit::context::one): Likewise.
(gccjit::function::get_param): Likewise.
---
gcc/jit/libgccjit++.h | 28
Hello!
During libjava build, following warning is reported:
../../../gcc-svn/branches/gcc-4_8-branch/libjava/java/lang/natObject.cc:932:27:
warning: suggest parentheses around comparison in operand of '|'
[-Wparentheses]
JvAssert(he -> address == address | LOCKED );
Gimple function dumps contain the types of parameters, but not of the
return type.
The attached patch fixes this omission; here's an example of the
before/after diff:
$ diff -up /tmp/pr23401.c.004t.gimple.old /tmp/pr23401.c.004t.gimple.new
--- /tmp/pr23401.c.004t.gimple.old 2014-03-10 13:40:0
Committed to branch dmalcolm/jit:
Error-handling in the C API works by returning NULL when an error
occurs (and setting an error on the context), and handling NULL inputs
by immediately returning NULL (setting another error). Hence the
presence of a NULL indicates some kind of error has occurred.
On Mon, Mar 10, 2014 at 10:53:27AM -0700, Ian Lance Taylor wrote:
> On Mon, Mar 10, 2014 at 10:42 AM, Uros Bizjak wrote:
> >
> > Attached patch is what I plan to commit to mainline soon. Ian, does it
> > look OK to you?
> >
> > 2014-03-10 Uros Bizjak
> >
> > * crtstuff.c (frame_dummy): Use
On Mon, Mar 10, 2014 at 10:42 AM, Uros Bizjak wrote:
>
> Attached patch is what I plan to commit to mainline soon. Ian, does it
> look OK to you?
>
> 2014-03-10 Uros Bizjak
>
> * crtstuff.c (frame_dummy): Use void **jcr_list temporary
> variable to avoid array subscript is above array b
On Mon, Mar 10, 2014 at 11:27 AM, Uros Bizjak wrote:
>>> > Well, better is non-obvious, while it is smaller (which is good for
>>> > initialization and thus rarely executed code), the common case is that
>>> > *jcr_list is 0 (gcj is used rarely these days) and for the common case it
>>> > is
>>>
This patch fixes PR59586.
The segfault is caused by NULL arguments passed to compute_deps by
loop_level_carries_dependences.
This causes an assignment of NULL values to the no_source parameters
of compute_deps.
They are passed to subtract_commutative_associative_deps and dereferenced.
However, thi
Rainer Orth writes:
> It does use the host compiler for me, too.
>
>> but maybe _that_ is the issue for you? (see also how it uses
>> -static-libgcc, for me it doesn't even depend on libgcc_s)
>
> But as you can see above, libtool, being its usual helpful self, simply
> drops -static-libgcc ;-(
We diagnose problems with template headers in push_template_decl, but
this testcase was skirting around the different places where we call
that function. Fixed thus.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5b5dadf2538f7684232cd72bd14ed1cdce2b0788
Author: Jason Merrill
Date: S
Hi!
On Fri, 7 Mar 2014 14:44:25 +0400, Ilmir Usmanov wrote:
> Hi Tobias!
>
> Thanks a lot for your review!
Yes, indeed, thanks for working together on improving the patches!
> OK for gomp4 branch?
For avoidance of doubt, once Tobias is fine with them, these patches are
good to go into gomp-4
Richard Biener writes:
> Ouch. But as lto-plugin is a host module it should link against
> the host libgcc, no? During stage1, that is. So the question is
> why does it use the gcc/ compiler?
>
> For me it's using the host gcc:
>
> gcc -DHAVE_CONFIG_H -I. -I/space/rguenther/tramp3d/trunk/l
On 03/10/2014 03:51 PM, Roman Gareev wrote:
I am slightly surprised why this change is necessary. Roman, can you shade some
light on this change.
No worries, just follow the pattern Jakub proposed.
The patch submission was generally of very high quality.
Tobias
Thank you for your comment!
2014-03-10 20:26 GMT+06:00 Jakub Jelinek :
> On Mon, Mar 10, 2014 at 03:23:22PM +0100, Tobias Grosser wrote:
>> >+++ b/gcc/testsuite/gfortran.dg/graphite/graphite.exp
>> >@@ -44,6 +44,7 @@ set interchange_files [lsort [glob -nocomplain
>> >$srcdir/$subdir/interchange-*.
> I am slightly surprised why this change is necessary. Roman, can you shade
> some light on this change.
>
>
>> # Vectorizer tests, to be run or compiled, depending on target
>> capabilities.
>> if [check_vect_support_and_set_flags] {
>> diff --git a/gcc/testsuite/gfortran.dg/graphite/paralle
On Mon, 10 Mar 2014, Jakub Jelinek wrote:
> Hi!
>
> From the comments on gcc-patches and from what the then block does
> I think only FUNCTION_DECLs were meant to be handled this way, but as the
> testcase shows we can trigger it even with VAR_DECLs.
>
> Fixed thusly, bootstrapped/regtested on x
On Sat, 8 Mar 2014, Rainer Orth wrote:
> Richard Biener writes:
>
> > 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_
Hi!
>From the comments on gcc-patches and from what the then block does
I think only FUNCTION_DECLs were meant to be handled this way, but as the
testcase shows we can trigger it even with VAR_DECLs.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2014-03-10 J
On Mon, Mar 10, 2014 at 03:23:22PM +0100, Tobias Grosser wrote:
> >+++ b/gcc/testsuite/gfortran.dg/graphite/graphite.exp
> >@@ -44,6 +44,7 @@ set interchange_files [lsort [glob -nocomplain
> >$srcdir/$subdir/interchange-*.\[f
> > set scop_files[lsort [glob -nocomplain
> >$srcdir/$subdir/sc
I worked with Roman on this patch and believe it is technically correct.
Some tiny comments inline.
Tobias
On 03/08/2014 10:57 AM, Roman Gareev wrote:
This patch fixes the following bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59586.
I would write PR59586. This should make this patch sh
Hi,
Your patch is fine - even without this bug, introducing NULL pointer checks
before dereferencing a pointer is a good thing.
Mircea
IVOPTs asks for unsigned types of random integral types, but
OFFSET_TYPEs are not handled in unsigned_type_for. The following
fixes that.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2014-03-10 Richard Biener
PR middle-end/60474
* tree.c (
On Mon, Mar 10, 2014 at 11:14 AM, Jakub Jelinek wrote:
>> > Well, better is non-obvious, while it is smaller (which is good for
>> > initialization and thus rarely executed code), the common case is that
>> > *jcr_list is 0 (gcj is used rarely these days) and for the common case it
>> > is
>> > o
Hi,
In common.opt, -ffp-contract=fast is set as the default for GCC. But
then it gets disabled in c-family/c-opts.c if you are using ISO C
(e.g. with -std=c99).
The reason for this patch is that if you have also specified
-funsafe-math-optimizations (or -Ofast or -ffast-math) then it is
likely y
On Mon, Mar 10, 2014 at 11:10:05AM +0100, Uros Bizjak wrote:
> > Well, better is non-obvious, while it is smaller (which is good for
> > initialization and thus rarely executed code), the common case is that
> > *jcr_list is 0 (gcj is used rarely these days) and for the common case it is
> > one in
On Mon, Mar 10, 2014 at 8:49 AM, Jakub Jelinek wrote:
> On Sun, Mar 09, 2014 at 10:38:25PM +0100, Uros Bizjak wrote:
>> On Sun, Mar 9, 2014 at 6:31 PM, Jakub Jelinek wrote:
>> > On Sun, Mar 09, 2014 at 09:41:59AM -0700, Ian Lance Taylor wrote:
>> >> >>> Attached patch avoids a bunch of:
>> >> >>>
Hi,
When I investigating PR60363 which is caused by previous patch for PR60280,
I found there is a latent bug in remove_forwarder_block_with_phi because GCC
doesn't update loop's latch information. Without this patch, cfgcleanup
facility will remove and rebuild the loop structure, resulting in los
On Mar 9, 2014, at 3:45 AM, Ulrich Drepper wrote:
> On Sat, Mar 8, 2014 at 8:30 PM, Mike Stump wrote:
>> Are they any plans to change the default language for C++?
>
> Probably problematic for compatibility reasons. But how about adding
> c++1, g++11, and c++14, and g++14 wrappers similar to c9
On Sun, Mar 09, 2014 at 10:38:25PM +0100, Uros Bizjak wrote:
> On Sun, Mar 9, 2014 at 6:31 PM, Jakub Jelinek wrote:
> > On Sun, Mar 09, 2014 at 09:41:59AM -0700, Ian Lance Taylor wrote:
> >> >>> Attached patch avoids a bunch of:
> >> >>>
> >> >>> ../../../gcc-svn/trunk/libgcc/crtstuff.c: In functi
40 matches
Mail list logo
