http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55468
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54471
--- Comment #11 from Jakub Jelinek 2012-11-26
09:19:39 UTC ---
Author: jakub
Date: Mon Nov 26 09:19:30 2012
New Revision: 193806
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193806
Log:
PR tree-optimization/54471
* t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54471
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650
--- Comment #14 from Georg-Johann Lay 2012-11-26
09:47:18 UTC ---
A milestone of 3.0.x???
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245
--- Comment #6 from Jakub Jelinek 2012-11-26
09:49:23 UTC ---
I'd say it should be the FE's responsibility to layout all needed types, so it
should be done either somewhere when the type ARRAY_REF is created or
finalized, or in cp-gimplify
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55428
--- Comment #5 from Andreas Kasberger
2012-11-26 09:51:50 UTC ---
I found this example on
geeksforgeeks.org/forum/topic/c-structure-size-with-empty-bitfield
#define offset(a,b) (size_t)(&(((a*)(0))->b))
struct emp
{
char s:8;
char c:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469
--- Comment #3 from Tobias Burnus 2012-11-26
10:23:54 UTC ---
Didn't help. The following should work. The crucial part is "free_line". At a
glance free_saved(dtp) (here and in comment 2) seems also to be sensible, but
one should read throu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41233
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54881
--- Comment #8 from janus at gcc dot gnu.org 2012-11-26 10:30:18 UTC ---
Author: janus
Date: Mon Nov 26 10:30:12 2012
New Revision: 193809
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193809
Log:
2012-11-26 Janus Weil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54881
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55110
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54997
--- Comment #8 from janus at gcc dot gnu.org 2012-11-26 11:16:35 UTC ---
Author: janus
Date: Mon Nov 26 11:16:31 2012
New Revision: 193811
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193811
Log:
2012-11-26 Janus Weil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54997
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #8 from Paolo Carlini 2012-11-26
11:26:16 UTC ---
The warning noticed by Jon seems a latent issue unrelated to bitfields and due
to the fact to for scoped enums, the underlying type, if not explicitly
specified is if fixed to i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #9 from Paolo Carlini 2012-11-26
11:32:15 UTC ---
Or maybe it should *always* run, if the point is diagnostics: after all even if
the type is fixed why not adding to its representation the information about
the actual range of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #10 from Paolo Carlini 2012-11-26
11:36:56 UTC ---
For example, consider this variant of the PR53661 situation:
enum class Code {
SUCCESS = 0
};
Code a;
short r[] = {a};
we currently produce a -Wnarrowing warning,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #11 from Jonathan Wakely 2012-11-26
11:46:46 UTC ---
That narrowing warning seems right to me, the enum variable could have a value
out of range of short:
Code a = static_cast(SHRT_MAX+1);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #12 from Jonathan Wakely 2012-11-26
11:50:43 UTC ---
The difference from PR 53661 is that the underlying type of a scoped
enumeration is fixed, so its values are the values of (in this case) int. In PR
53661 the underlying type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #13 from Paolo Carlini 2012-11-26
12:00:17 UTC ---
But something still seems wrong to me. Why warning depending on whether 'class'
is there for the following:
enum /*class*/ Code {
SUCCESS = 0
};
Code a;
short r[] =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #14 from Paolo Carlini 2012-11-26
12:05:21 UTC ---
Anyway, the latent issue is of course with fixed underlying types: if in that
case we don't care about warning more, this issue is already fixed, very
likely. Even better ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Paolo Carlini changed:
What|Removed |Added
CC||paolo.carlini at oracle dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #16 from Paolo Carlini 2012-11-26
12:22:49 UTC ---
And to further clarify wrt your specific Comment 11, Jon, for:
#include
enum Code {
SUCCESS = 0
};
Code a = static_cast(SHRT_MAX + 1);
short r[] = {a};
we cur
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795
--- Comment #25 from Richard Biener 2012-11-26
12:24:30 UTC ---
(In reply to comment #23)
> Another problem with revision 191466 is we lost
> debug info on cl_options. With revision 191465,
> I got
>
> (gdb) whatis cl_options
> type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650
Richard Biener changed:
What|Removed |Added
Component|lto |middle-end
Version|4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #17 from Jonathan Wakely 2012-11-26
12:43:37 UTC ---
(In reply to comment #15)
> we *error* out anyway, isn't that we are only emitting a warning and only when
> we are assigning the SHRT_MAX + 1.
But isn't the error because
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466
--- Comment #1 from Jan Hubicka 2012-11-26 12:45:23 UTC
---
> /export/project/git/gcc-regression-bootstrap/master/191466/bld/gcc/cc1...done.
> (gdb) whatis global_options
> type =
> (gdb) whatis cl_options
> type =
> (gdb) whatis cl_e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Paolo Carlini changed:
What|Removed |Added
CC|paolo.carlini at oracle dot |
|com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #19 from Jonathan Wakely 2012-11-26
12:56:34 UTC ---
Clang doesn't warn for the code in comment 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #20 from Paolo Carlini 2012-11-26
13:00:08 UTC ---
Well, then we should double check whether it warns at all when bitfields are
not involved, because I don't see anything bitfield-specific about the warning.
Maybe it just warns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #21 from Paolo Carlini 2012-11-26
13:27:45 UTC ---
Uhm, actually, when the underlying type is unscoped and we already accept the
code, we warn exactly in the same way. I'm not sure if this is already clear to
everybody, definit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795
--- Comment #26 from H.J. Lu 2012-11-26 13:29:17
UTC ---
(In reply to comment #25)
> This means that somewhere there is a cl_option definition that may prevail
> that has size 1. lto_symtab_resolve_symbols is supposed to pick the
> large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55470
Bug #: 55470
Summary: Enable both ld and gold in gcc
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #22 from Paolo Carlini 2012-11-26
13:39:17 UTC ---
I mean, with the grokbitfield tweak we obtain a behavior for Comment #1 which
in terms of warnings it's just a variant of Comment #13: if we already decided
that it's fine to w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #23 from Paolo Carlini 2012-11-26
14:00:37 UTC ---
Patchlet in Comment #6 passes testing for me.
As I tried clumsily to explain, I don't think it's consistent to avoid the
warning for Comment #1 if we warn for Comment #13 sco
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467
Hans-Peter Nilsson changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54894
--- Comment #8 from Richard Biener 2012-11-26
14:26:16 UTC ---
Author: rguenth
Date: Mon Nov 26 14:26:07 2012
New Revision: 193816
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193816
Log:
2012-11-26 Richard Biener
B
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54735
--- Comment #15 from Richard Biener 2012-11-26
14:26:18 UTC ---
Author: rguenth
Date: Mon Nov 26 14:26:07 2012
New Revision: 193816
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193816
Log:
2012-11-26 Richard Biener
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54976
--- Comment #4 from Richard Biener 2012-11-26
14:26:16 UTC ---
Author: rguenth
Date: Mon Nov 26 14:26:07 2012
New Revision: 193816
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193816
Log:
2012-11-26 Richard Biener
B
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54735
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54894
Richard Biener changed:
What|Removed |Added
Known to work||4.7.2
Summary|[4.6/4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
--- Comment #8 from Marek Polacek 2012-11-26
14:29:59 UTC ---
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02095.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467
--- Comment #6 from Jakub Jelinek 2012-11-26
14:37:48 UTC ---
I disagree. You can't see for aggregate var in memory which
actually has been allocated on the stack, VTA doesn't value track those (and
can't really), there you just have a v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #24 from Jonathan Wakely 2012-11-26
14:40:20 UTC ---
I think naming the warning would make sense, so it can be disabled by people
who want to use scoped enums with bit-fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650
John David Anglin changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650
--- Comment #15 from dave.anglin at bell dot net 2012-11-26 14:58:12 UTC ---
On 11/26/2012 4:47 AM, gjl at gcc dot gnu.org wrote:
> A milestone of 3.0.x??
It seems I did this while updating the "Last reconfirmed" date. As I
understand it,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466
--- Comment #2 from Richard Biener 2012-11-26
15:57:37 UTC ---
(In reply to comment #1)
> > /export/project/git/gcc-regression-bootstrap/master/191466/bld/gcc/cc1...done.
> > (gdb) whatis global_options
> > type =
> > (gdb) whatis cl_op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466
--- Comment #3 from H.J. Lu 2012-11-26 16:36:10
UTC ---
(In reply to comment #2)
>
> >
> > Hmm, I suppose this is because we no longer merge symbols that are not part
> > of
> > symtab, but
> > used only for debugging
> >
> > H
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650
--- Comment #16 from Jakub Jelinek 2012-11-26
16:36:10 UTC ---
Created attachment 28778
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28778
gcc48-pr52650.patch
P1 for an error-recovery bug sounds way too high, those should be P4-i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572
Janne Blomqvist changed:
What|Removed |Added
CC||ian at airs dot com
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650
--- Comment #17 from dave.anglin at bell dot net 2012-11-26 16:43:18 UTC ---
On 11/26/2012 11:36 AM, jakub at gcc dot gnu.org wrote:
> P1 for an error-recovery bug sounds way too high, those should be P4-ish.
I just restored the previous set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572
--- Comment #6 from Janne Blomqvist 2012-11-26 16:46:08
UTC ---
Created attachment 28779
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28779
Patch to use libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465
--- Comment #4 from janus at gcc dot gnu.org 2012-11-26 17:08:20 UTC ---
Note: The same behavior occurs with all gfortran versions I tried (4.3, 4.6,
4.7 and trunk).
The check which rejects it is in gfc_verify_binding_labels (resolve.c).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465
--- Comment #5 from Fran Martinez Fadrique
2012-11-26 17:36:04 UTC ---
I have also tried with ekopath and g95 and both take it without a diagnostic.
I have been checking section 15.4 of the ISO standard and I have found nothing
that forbid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465
Tobias Burnus changed:
What|Removed |Added
Keywords||rejects-valid
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467
Hans-Peter Nilsson changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55277
--- Comment #2 from Vladimir Makarov 2012-11-26
18:08:50 UTC ---
Author: vmakarov
Date: Mon Nov 26 18:08:44 2012
New Revision: 193824
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193824
Log:
2012-11-26 Vladimir Makarov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
Bug #: 55471
Summary: c++ mutex does not work as expected
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245
--- Comment #7 from Diego Novillo 2012-11-26
18:35:43 UTC ---
Author: dnovillo
Date: Mon Nov 26 18:35:38 2012
New Revision: 193825
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193825
Log:
Google ref b/7500842.
2012-11-26
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641
--- Comment #8 from Georg-Johann Lay 2012-11-26
18:46:25 UTC ---
Author: gjl
Date: Mon Nov 26 18:46:12 2012
New Revision: 193826
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193826
Log:
PR testsuite/52641
* gcc.c-tor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
gustavo changed:
What|Removed |Added
Host||fedora 17
--- Comment #2 from gustavo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
Host|fedora
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
--- Comment #4 from Jonathan Wakely 2012-11-26
19:23:22 UTC ---
If you change the code to join the threads instead of leaving them running when
the program exits then the output is correct.
#include
#include
#include
#include
s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
--- Comment #5 from Jonathan Wakely 2012-11-26
19:24:38 UTC ---
Almost certainly what happens is that the mutex m gets destroyed when returning
from main, but there are threads still using it and so they can no longer lock
it.
It's unde
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32647
Uros Bizjak changed:
What|Removed |Added
Blocks||55277
--- Comment #3 from Uros Bizjak 201
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #19 from Larry Baker 2012-11-26 19:44:21
UTC ---
(In reply to comment #18)
Ian,
> You can also add linker options via the configure options
> --with-stage1-ldflags
> and --with-boot-ldflags, q.v.
So, I read what the GCC configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55472
Bug #: 55472
Summary: Linker cannot find lambda symbol
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
gustavo changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55472
--- Comment #1 from walker_643 at yahoo dot com 2012-11-26 19:48:15 UTC ---
I believe the code to be valid C++11, and, indeed it does compile, link, and
run on gcc 4.5 (as seen here http://ideone.com/VvFuMs ), but no GCC versions
4.7 - 4.8 a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465
Juno Krahn changed:
What|Removed |Added
CC||juno.krahn at nih dot gov
--- Comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55473
Bug #: 55473
Summary: quadmath.h should have extern "C" for C++ users
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465
--- Comment #8 from Juno Krahn 2012-11-26 19:55:11
UTC ---
Also, I should have mentioned that multiple interface specs used to work in Gnu
Fortran, and it still works in current Intel, Sun and Open64 Fortran compilers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465
--- Comment #10 from Harald Anlauf 2012-11-26 20:24:56
UTC ---
(In reply to comment #9)
> Well, then somebody should also complain to NAG.
> The code in comment #6 fails to compile.
And to IBM.
% xlf -qversion
IBM XL Fortran for AIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55474
Bug #: 55474
Summary: global-buffer-overflow in lto-wrapper.c
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55475
Bug #: 55475
Summary: heap-buffer-overflow in fortran/error.c
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465
--- Comment #11 from Harald Anlauf 2012-11-26 20:57:53
UTC ---
I'm also having difficulties to see how the interface definition
could be standard compatible. The F2k8 draft says:
15.5.1 Deļ¬nition and reference of interoperable procedures
A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55476
Bug #: 55476
Summary: [4.8 Regression] Bogus warning "Pointer might outlive
the pointer target"
Classification: Unclassified
Product: gcc
Version: 4.8.0
Sta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55472
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55476
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55475
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477
Bug #: 55477
Summary: [devirt] trunk fails inline-devirt tests #2 and and #3
whereas they pass in google/4_7
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55476
--- Comment #2 from janus at gcc dot gnu.org 2012-11-26 22:05:23 UTC ---
The warning obviously gets triggered because the pointer has the 'host_assoc'
attribute (due to its use in the contained subroutine):
warn = lvalue->symtree->n.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55476
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478
Bug #: 55478
Summary: [devirt] trunk fails inline-devirt test #4
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572
--- Comment #7 from Ian Lance Taylor 2012-11-26 23:02:46
UTC ---
Why are there no line numbers in the backtrace from gdb? You said you compiled
with -g. Are you sure that libbacktrace itself was compiled with -g?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #16 from Arthur O'Dwyer
2012-11-26 23:02:52 UTC ---
(Sorry for the spam.)
The corresponding Clang enhancement is
http://llvm.org/bugs/show_bug.cgi?id=14440
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572
--- Comment #8 from Ian Lance Taylor 2012-11-26 23:08:45
UTC ---
The crash within libbacktrace is occurring as it tries to read the debug info.
This is presumably a bug in libbacktrace, but I don't know what the problem is
without more in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53094
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55015
Paolo Carlini changed:
What|Removed |Added
Summary|Lambda functions not found |[4.7/4.8 Regression] Lambda
1 - 100 of 122 matches
Mail list logo