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
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
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 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:
>> >> >>>
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
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: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
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 (
Hi,
Your patch is fine - even without this bug, introducing NULL pointer checks
before dereferencing a pointer is a good thing.
Mircea
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
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
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 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_
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
> 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
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-*.
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
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
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
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
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 ;-(
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
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
>>>
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 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
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.
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
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 );
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
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
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
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 ()
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++
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
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
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
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
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
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
> 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
40 matches
Mail list logo
