http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56114
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56111
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-26
10:36:19 UTC ---
What happens if we simply #undef at the beginning of complex and nothing
else? It seems to me that complex is the *real* place where such a macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
--- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-26
10:38:23 UTC ---
BTW, I agree with Jason that we shouldn't optimize these vtable reads. When
this hit libstdc++, it could hit very well any other C++ shared library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56111
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56111
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
Component|c++ |libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53893
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52819
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56111
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-26
11:11:24 UTC ---
Ok, I understand. Looks like, however, we are back to my original observation
in PR54112 that in C++03 mode we have less constraints and with more
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107
--- Comment #14 from janus at gcc dot gnu.org 2013-01-26 11:31:24 UTC ---
(In reply to comment #13)
(In reply to comment #12)
Here is an updated version of Mikael's patch, which is free of testsuite
regressions.
Indeed, it was
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56111
--- Comment #6 from Marc Glisse glisse at gcc dot gnu.org 2013-01-26 11:35:52
UTC ---
(In reply to comment #5)
Ok, I understand. Looks like, however, we are back to my original observation
in PR54112 that in C++03 mode we have less
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56116
Bug #: 56116
Summary: failed to build ARM native compiler by ARM cross
compiler
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48659
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||ktietz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56117
Bug #: 56117
Summary: [4.8 Regression] ICE: in cselib_subst_to_values, at
cselib.c:1853 with -O2 -fsched2-use-superblocks and
__builtin_prefetch()
Classification:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55270
--- Comment #2 from Antoine Balestrat antoine.balestrat at gmail dot com
2013-01-26 14:10:57 UTC ---
Still reproducible as of 4.8.0 20130125.
Started with http://gcc.gnu.org/viewcvs?view=revisionrevision=185913
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55270
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56114
--- Comment #3 from Alexander Kobets akobets at mail dot ru 2013-01-26
14:30:42 UTC ---
(In reply to comment #2)
Proposed patch:
It is correcting this code, but break another. For example (-mcmodel=large):
--cut here--
long* p1;
long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56114
--- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2013-01-26 15:08:35
UTC ---
Well, following patch won't break then:
--cut here--
Index: i386.md
===
--- i386.md
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56117
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56116
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56115
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56113
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56112
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56113
--- Comment #3 from Kangkook aixer77 at gmail dot com 2013-01-26 15:40:43 UTC
---
Hi, Richard
Thanks a lot for your advice. I will definitely try gcc 4.8 and let you know
about the result.
Btw, I also tested it from the 64-bit env. but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107
--- Comment #15 from janus at gcc dot gnu.org 2013-01-26 16:10:40 UTC ---
Created attachment 29279
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29279
patch v3
Here is a new patch, which does some further cleanup, such as removing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107
--- Comment #16 from janus at gcc dot gnu.org 2013-01-26 16:16:13 UTC ---
(In reply to comment #15)
Created attachment 29279 [details]
patch v3
Forgot to mention: Still regtests cleanly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54663
--- Comment #3 from eager at gcc dot gnu.org 2013-01-26 16:53:50 UTC ---
Author: eager
Date: Sat Jan 26 16:53:45 2013
New Revision: 195488
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195488
Log:
gcc: PR target/54663
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56114
--- Comment #5 from Alexander Kobets akobets at mail dot ru 2013-01-26
16:54:50 UTC ---
(In reply to comment #4)
Well, following patch won't break then:
Yes, thank you.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56116
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-26
17:01:34 UTC ---
I have just recently built an aarch64 native compiler. Though not the same as
an arm-linux-gnu compiler but it works.
Can you provide your
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55905
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56118
Bug #: 56118
Summary: No constant propagation in vector field assignment
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56119
Bug #: 56119
Summary: Allows static member definition of template class in
namespace not enclosing this class
Classification: Unclassified
Product: gcc
Version: 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56118
--- Comment #1 from Marc Glisse glisse at gcc dot gnu.org 2013-01-26 17:57:13
UTC ---
Note that the case I am most interested in is actually when r is not
initialized:
__m128d r;
gimple_assign real_cst, BIT_FIELD_REF r, 64, 0,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56119
--- Comment #1 from Sergey zhurxx at gmail dot com 2013-01-26 18:13:48 UTC ---
Created attachment 29281
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29281
Preprocessed source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
--- Comment #23 from Jan Hubicka hubicka at ucw dot cz 2013-01-26 18:32:15
UTC ---
I must say I'm surprised by the gimple-fold.c test, I'd really expect
additional DECL_VISIBILITY (decl) != VISIBILITY_DEFAULT .
Another alternative to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56116
--- Comment #3 from Denis Onischenko denis.onischenko at gmail dot com
2013-01-26 18:46:56 UTC ---
Created attachment 29282
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29282
output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56116
--- Comment #4 from Denis Onischenko denis.onischenko at gmail dot com
2013-01-26 18:53:02 UTC ---
configuration options for cross-compiler (printed by ./gcc -v):
Using built-in specs.
COLLECT_GCC=./gcc
Target: arm-unknown-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55056
--- Comment #7 from Jan Kratochvil jan.kratochvil at redhat dot com
2013-01-26 20:28:45 UTC ---
Workarounded with XFAIL for the GDB testsuite:
http://sourceware.org/ml/gdb-patches/2013-01/msg00655.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56116
--- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-26
20:51:51 UTC ---
checking whether sbrk is declared... no
That is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55887
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55984
Paul Thomas pault at gcc dot gnu.org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |pault at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047
Paul Thomas pault at gcc dot gnu.org changed:
What|Removed |Added
CC||pault at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55887
--- Comment #3 from janus at gcc dot gnu.org 2013-01-26 21:21:38 UTC ---
This patch fixes the ICE in comment 0:
Index: gcc/fortran/trans-decl.c
===
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107
--- Comment #17 from Mikael Morin mikael at gcc dot gnu.org 2013-01-26
22:47:28 UTC ---
(In reply to comment #14)
Are procedure dummy arguments mutually exclusive with non-NULL procedure
interface, so that there is no dummy ambiguity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107
--- Comment #18 from Mikael Morin mikael at gcc dot gnu.org 2013-01-26
23:08:34 UTC ---
(In reply to comment #15)
Here is a new patch, which does some further cleanup, such as removing the
'formal' and 'formal_ns' members of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47115
David Edelsohn dje at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56113
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
--- Comment #24 from Jason Merrill jason at gcc dot gnu.org 2013-01-27
01:44:49 UTC ---
(In reply to comment #21)
I must say I'm surprised by the gimple-fold.c test, I'd really expect
additional DECL_VISIBILITY (decl) !=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56120
Bug #: 56120
Summary: built-in SIMD with statement expression causes ICE: in
iterative_hash_expr, at tree.c:6990 when optimization
is on
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047
--- Comment #17 from Paul Thomas pault at gcc dot gnu.org 2013-01-27 07:09:12
UTC ---
Author: pault
Date: Sun Jan 27 07:09:06 2013
New Revision: 195492
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195492
Log:
2013-01-27 Paul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789
--- Comment #5 from Paul Thomas pault at gcc dot gnu.org 2013-01-27 07:09:12
UTC ---
Author: pault
Date: Sun Jan 27 07:09:06 2013
New Revision: 195492
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195492
Log:
2013-01-27 Paul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56112
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-27
07:15:39 UTC ---
Bother. Now it's annoying to go back to the various options (some aren't even
discussed in Bugzilla entries). Maybe you did a bit of that already
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55984
--- Comment #7 from Paul Thomas pault at gcc dot gnu.org 2013-01-27 07:18:29
UTC ---
Author: pault
Date: Sun Jan 27 07:18:22 2013
New Revision: 195493
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195493
Log:
2013-01-27 Paul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047
Paul Thomas pault at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56112
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-27
07:32:59 UTC ---
I guess we could have in __detail the specialization that submitter proposed to
add to stl_function.h as primary.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55984
Paul Thomas pault at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789
--- Comment #6 from Paul Thomas pault at gcc dot gnu.org 2013-01-27 07:37:40
UTC ---
Sorry, the apparent fix in comment#5 is just noise. The real fix is on its way
today.
Paul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56120
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
58 matches
Mail list logo