http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60392
--- Comment #8 from Mikael Morin mikael at gcc dot gnu.org ---
Fixed on trunk.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60392
--- Comment #9 from Alexander Vogt a.vogt at fulguritus dot com ---
Thanks a lot!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60532
Bug ID: 60532
Summary: [4.9 Regression] r208573 causes Firefox build failure
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60532
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 libopus % test.ii
class A
{
~A ();
};
class B : A
{
virtual void m () = 0;
};
markus@x4 libopus % g++ -c test.ii
test.ii:5:7: internal compiler error:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60522
--- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #3)
BLOCK constructs are not allowed inside WHERE constructs.
Thus, the common function optimization should not create a BLOCK to hold
the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60532
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678
--- Comment #35 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Sat Mar 15 01:39:03 2014
New Revision: 208586
URL: http://gcc.gnu.org/viewcvs?rev=208586root=gccview=rev
Log:
PR c++/60532
PR c++/58678
* search.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60532
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60532
--- Comment #2 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Sat Mar 15 01:39:03 2014
New Revision: 208586
URL: http://gcc.gnu.org/viewcvs?rev=208586root=gccview=rev
Log:
PR c++/60532
PR c++/58678
* search.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60521
Sergei Turchanov turchanov at farpost dot com changed:
What|Removed |Added
Version|4.8.3 |4.4.7
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533
Bug ID: 60533
Summary: [4.8/4.9 regression] Error introduced by bb-reorder at
-O3
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533
--- Comment #1 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Created attachment 32354
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32354action=edit
Dump before bb-reorder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533
--- Comment #2 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Created attachment 32355
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32355action=edit
Dump after bb-reorder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525
--- Comment #9 from Richard Henderson rth at gcc dot gnu.org ---
Author: rth
Date: Sat Mar 15 03:24:11 2014
New Revision: 208587
URL: http://gcc.gnu.org/viewcvs?rev=208587root=gccview=rev
Log:
PR target/60525
* config/i386/i386.md
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533
--- Comment #4 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Created attachment 32357
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32357action=edit
Second half of test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533
--- Comment #3 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Created attachment 32356
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32356action=edit
First half of test case
Sorry, have to split the test case into two pieces; please
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525
Richard Henderson rth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
2014-03-13 22:58 GMT+04:00 Georg-Johann Lay a...@gjlay.de:
Am 03/13/2014 07:36 PM, schrieb Denis Chertykov:
2014-03-13 21:41 GMT+04:00 Georg-Johann Lay:
Am 03/13/2014 04:41 PM, schrieb Senthil Kumar Selvaraj:
On Thu, Mar 13, 2014 at 02:24:06PM +0100, Georg-Johann Lay wrote:
Problem is
On Thu, 13 Mar 2014, Cong Hou wrote:
On Thu, Mar 13, 2014 at 2:27 AM, Richard Biener rguent...@suse.de wrote:
On Wed, 12 Mar 2014, Cong Hou wrote:
Thank you for pointing it out. I didn't realized that alias analysis
has influences on this issue.
The current problem is that the
On Fri, Mar 14, 2014 at 08:52:07AM +0100, Richard Biener wrote:
Consider this fact and if there are alias checks, we can safely remove
the epilogue if the maximum trip count of the loop is less than or
equal to the calculated threshold.
You have to consider n % vf != 0, so an argument on
On Fri, 14 Mar 2014, Jakub Jelinek wrote:
On Fri, Mar 14, 2014 at 08:52:07AM +0100, Richard Biener wrote:
Consider this fact and if there are alias checks, we can safely remove
the epilogue if the maximum trip count of the loop is less than or
equal to the calculated threshold.
You
The following fixes PR60518 where split_block does not fixup
all loops that the block was a latch of (without simple latches
a latch need not belong to its loop but can be an exit block
of a nested loop).
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2014-03-14 Richard
On Thu, 13 Mar 2014, Cesar Philippidis wrote:
On 3/13/14, 2:52 AM, Richard Biener wrote:
On Thu, Mar 13, 2014 at 10:31 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Mar 13, 2014 at 1:10 AM, Cesar Philippidis
ce...@codesourcery.com wrote:
I noticed that the lto-wrapper is
This would suggest that you can use the pattern also for performing a normal
add in case the condition code is not needed afterwards but this isn't
correct for s390 31 bit where an address calculation is actually something
different.
Then you should document that by stating that the pattern
Hi!
Ping.
On Fri, 07 Mar 2014 21:21:48 +0100, I wrote:
On Fri, 15 Nov 2013 14:44:45 -0700, Aldy Hernandez al...@redhat.com wrote:
I fixed a few nits Jason pointed out off-line, and both him and Jakub
have approved the patch for trunk.
In running the final round of tests I noticed a
Hi!
$ ../configure --enable-foo='--enable-a=1 --enable-b=2 --enable-c=3'
[...]
$ make configure-zlib
config.status: creating Makefile
config.status: executing default-1 commands
../../zlib/../config-ml.in: eval: line 142: unexpected EOF while looking
for matching `''
On 14/03/14 11:02, Eric Botcazou wrote:
This would suggest that you can use the pattern also for performing a normal
add in case the condition code is not needed afterwards but this isn't
correct for s390 31 bit where an address calculation is actually something
different.
Then you should
On Fri, Mar 14, 2014 at 6:36 AM, Ryan Hill dirtye...@gentoo.org wrote:
On Mon, 18 Nov 2013 19:04:59 +0100
Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this patch switches the default for fat-lto-objects as was documented for a
while. -ffat-lto-objects doubles compilation time and often makes users
On Fri, Mar 14, 2014 at 4:05 AM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Feb 5, 2014 at 2:29 AM, Venkataramanan Kumar
venkataramanan.ku...@linaro.org wrote:
Hi Marcus,
+ ldr\\t%x2, %1\;str\\t%x2, %0\;mov\t%x2,0
+ [(set_attr length 12)])
This pattern emits an opaque sequence of
Hi Venkat
On 5 February 2014 10:29, Venkataramanan Kumar
venkataramanan.ku...@linaro.org wrote:
Hi Marcus,
+ ldr\\t%x2, %1\;str\\t%x2, %0\;mov\t%x2,0
+ [(set_attr length 12)])
This pattern emits an opaque sequence of instructions that cannot be
scheduled, is that necessary? Can we not
Index: steering.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/steering.html,v
retrieving revision 1.37
diff -c -p -r1.37 steering.html
*** steering.html 8 Dec 2013 21:04:17 - 1.37
--- steering.html 14 Mar 2014
On Fri, Mar 14, 2014 at 10:40:22AM -0400, David Edelsohn wrote:
! liJoseph Myers (CodeSourcery / Mentor Graphics) [co-Release Maanger]/li
s/Maanger/Manager/
Marek
Applied, thanks.
Jason
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
For this particular case at least.
Note that I'm not against linking against static libgcc_s for
lto-plugin. The -static-libstdc++ we use is just because during
bootstrap picking up the correct libstdc++ was deemed too hard
to
Hi,
This patch adds vdup intrinsic testcases for AArch64. those testcases
are nice to have, as it allows to reason about vdup consistency for
both LE and BE compiler flavors.
This patch covers following intrinsics:
vdup_lane_f32
vdup_lane_s[8,16]
vdup_lane_s[32,64]
vdup_n_[p,s,u][8,16]
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60508
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 208570.
2014-03-14 Vladimir Makarov vmaka...@redhat.com
PR rtl-optimization/60508
* lra-constraints.c
On Fri, 14 Mar 2014, Rainer Orth wrote:
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
For this particular case at least.
Note that I'm not against linking against static libgcc_s for
lto-plugin. The -static-libstdc++ we use is just because during
bootstrap picking up the
This patch makes sure that we set the directory prefix of
dump_base_name only once, otherwise we'd end up with invalid path,
resulting in error: could not open dump file ...
This happened because finish_options is called for every optimize
attribute and once more for command line options and every
Committed to branch dmalcolm/jit:
gcc/jit/
* libgccjit.c (is_valid_cast): Permit casts between pointer types.
* internal-api.c (convert): Report more information if this ever
occurs, and make the error occur on the playback context, so that
it makes the
On Fri, 14 Mar 2014, Marek Polacek wrote:
This patch makes sure that we set the directory prefix of
dump_base_name only once, otherwise we'd end up with invalid path,
resulting in error: could not open dump file ...
This happened because finish_options is called for every optimize
attribute
This removes the _ZNSt12system_errorC* pattern from the GLIBCXX_3.4.11
version, because it doesn't seem to be used at the moment, but inlining
changes being tested for PR ipa/58721 cause some new symbols to be
added to the library and exported with version GLIBCXX_3.4.11, which
obviously
Fix some inaccurate comments, especially the asymptotic complexity
mark: o() = \Omega().
Thanks!
--
Regards,
Tim Shen
commit 7db473c494866d071087f3e7465e36cc96a918b1
Author: tim timshe...@gmail.com
Date: Fri Mar 14 14:50:12 2014 -0400
2014-03-14 Tim Shen timshe...@gmail.com
Honza suggested that if the destructor for an abstract class can't ever
be called through the vtable, the front end could avoid referring to it
from the vtable. This patch replaces such a destructor with
__cxa_pure_virtual in the vtable.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit
On 14/03/14 14:55 -0400, Tim Shen wrote:
Fix some inaccurate comments, especially the asymptotic complexity
mark: o() = \Omega().
If all the tests pass this is OK for trunk, thanks.
N.B. the patch is fine but I don't think we usually say
@brief Class FooBar. Does some Foo and some Bar.
Hi all,
attached is a patch which implicitly sets the SAVE attribute for all
variables in the main program, as demanded by the Fortran 2008
standard. This fixes an ICE with pointer initialization (see
pointer_init_9.f90). Also a few exisiting test cases had to be changed
to accomodate for the
Janus Weil wrote:
Regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk or wait for
next stage1?
Looks good to me - and simple enough for the 4.9 trunk.
Tobias
Hi all,
I have committed the attached patch to the Fortran-CAF branch. It paves
the road to CAF sending support by declaring caf_send - and implementing
it in libcaf_single.c (as memmove). Additionally, I cleaned up the
library by handling the token in a better way (more readable - and
I forgot to attach the patch.
Tobias Burnus wrote:
Hi all,
I have committed the attached patch to the Fortran-CAF branch. It
paves the road to CAF sending support by declaring caf_send - and
implementing it in libcaf_single.c (as memmove). Additionally, I
cleaned up the library by handling
Hi
I just realized that when I committed this:
2014-01-20 François Dumont fdum...@gcc.gnu.org
* scripts/create_testsuite_files: Add testsuite/experimental in
the list of folders to search for tests.
* include/experimental/string_view
On 14/03/14 22:26 +0100, François Dumont wrote:
I forgot to commit the create_testsuite_files script. Is it still ok
to do so now ?
Yes, since this was meant to be commited earlier it's OK to commit
now (assuming it doesn't introduce any new failures) - thanks.
By the way is there an info
On Fri, Mar 14, 2014 at 12:58 AM, Richard Biener rguent...@suse.de wrote:
On Fri, 14 Mar 2014, Jakub Jelinek wrote:
On Fri, Mar 14, 2014 at 08:52:07AM +0100, Richard Biener wrote:
Consider this fact and if there are alias checks, we can safely remove
the epilogue if the maximum trip count
Oops, need to make sure dtor is non-null before looking at it...
We also might as well handle this after the dfs is done.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 142f595d2474a05c59991e8ea7a5f6712d9982ff
Author: Jason Merrill ja...@redhat.com
Date: Fri Mar 14 20:38:10 2014 -0400
The attached patch fixes this problem by first reading the next available char
to see if EOF is encountered. If so, issue the EOF error. If not use eat_line
to find the end of the line. If the end of the line is at the end of the file,
it will be caught on any subsequent attempt to read.
The
This bug report had various testcases that had to do with full loop
unrolling with non-automatic iterators and fixed boundaries, which
resulted in duplicating debug stmts in the loop for each iteration. In
some cases, the resulting executable code is none, but the debug stmts
add up to millions.
This PR is fallout from my patch from yesterday, which adjusted some of the
i386 float-int conversion patterns. In the gcc-patches message for that
change, I opined that in stage1 we should clean up all of these patterns.
Except that the existing state of affairs appears to have been too complex
On Mar 14, 2014, at 7:45 PM, Alexandre Oliva aol...@redhat.com wrote:
In some cases, the resulting executable code is none, but the debug stmts
add up to millions.
I’d like to think there is a better theoretic answer to the specific problem…
trimming random debug info I think just invites a
Hi,
You are receiving this message because you are in top 50 contributors to GCC
[1]. Congratulations!
Since you are a top contributor to GCC project it is important for you to rate
the incoming student GSOC applications. Go and register at
101 - 157 of 157 matches
Mail list logo
