http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55468
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54471
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 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=gccview=revrev=193806
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54471
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650
--- Comment #14 from Georg-Johann Lay gjl at gcc dot gnu.org 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 jakub at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55428
--- Comment #5 from Andreas Kasberger kasberger at heidenhain dot de
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))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 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,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41233
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
CC||glisse at
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=gccview=revrev=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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55110
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at
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=gccview=revrev=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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 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_castCode(SHRT_MAX+1);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 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 =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 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,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-26
12:22:49 UTC ---
And to further clarify wrt your specific Comment 11, Jon, for:
#include limits.h
enum Code {
SUCCESS = 0
};
Code a =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795
--- Comment #25 from Richard Biener rguenth at gcc dot gnu.org 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)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Component|lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #17 from Jonathan Wakely redi at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466
--- Comment #1 from Jan Hubicka hubicka at ucw dot cz 2012-11-26 12:45:23 UTC
---
/export/project/git/gcc-regression-bootstrap/master/191466/bld/gcc/cc1...done.
(gdb) whatis global_options
type = data variable, no debug info
(gdb)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC|paolo.carlini at oracle dot |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org 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 paolo.carlini at oracle dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #21 from Paolo Carlini paolo.carlini at oracle dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795
--- Comment #26 from H.J. Lu hjl.tools at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #22 from Paolo Carlini paolo.carlini at oracle dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #23 from Paolo Carlini paolo.carlini at oracle dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467
Hans-Peter Nilsson hp at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54894
--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 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=gccview=revrev=193816
Log:
2012-11-26
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54735
--- Comment #15 from Richard Biener rguenth at gcc dot gnu.org 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=gccview=revrev=193816
Log:
2012-11-26
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54976
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 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=gccview=revrev=193816
Log:
2012-11-26
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54735
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54894
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
--- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org 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 jakub at gcc dot gnu.org 2012-11-26
14:37:48 UTC ---
I disagree. You can't see optimized out for aggregate var in memory which
actually has been allocated on the stack, VTA doesn't value track those (and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
--- Comment #24 from Jonathan Wakely redi at gcc dot gnu.org 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 danglin at gcc dot gnu.org 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 rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 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 =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55466
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650
--- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572
Janne Blomqvist jb at gcc dot gnu.org changed:
What|Removed |Added
CC||ian at
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572
--- Comment #6 from Janne Blomqvist jb at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465
--- Comment #5 from Fran Martinez Fadrique fmartinez at gmv dot com
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55467
Hans-Peter Nilsson hp at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55277
--- Comment #2 from Vladimir Makarov vmakarov at gcc dot gnu.org 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=gccview=revrev=193824
Log:
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245
--- Comment #7 from Diego Novillo dnovillo at gcc dot gnu.org 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=gccview=revrev=193825
Log:
Google ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641
--- Comment #8 from Georg-Johann Lay gjl at gcc dot gnu.org 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=gccview=revrev=193826
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
gustavo gustavo at atc dot ugr.es changed:
What|Removed |Added
Host||fedora 17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 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 iostream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32647
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Blocks||55277
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #19 from Larry Baker baker at usgs dot gov 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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
gustavo gustavo at atc dot ugr.es changed:
What|Removed |Added
Status|RESOLVED|NEW
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465
Juno Krahn juno.krahn at nih dot gov changed:
What|Removed |Added
CC||juno.krahn
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465
--- Comment #8 from Juno Krahn juno.krahn at nih dot gov 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465
Harald Anlauf anlauf at gmx dot de changed:
What|Removed |Added
CC||anlauf at gmx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55465
--- Comment #10 from Harald Anlauf anlauf at gmx dot de 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
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 anlauf at gmx dot de 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55471
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55472
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55475
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
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 =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55476
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
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 hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
Arthur O'Dwyer arthur.j.odwyer at gmail dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572
--- Comment #7 from Ian Lance Taylor ian at airs dot com 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 arthur.j.odwyer at gmail dot com
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 hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54572
--- Comment #8 from Ian Lance Taylor ian at airs dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53094
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
CC||glisse at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55015
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Summary|Lambda functions not found
1 - 100 of 122 matches
Mail list logo
