[Bug rtl-optimization/93040] New: gcc doesn't optimize unaligned accesses to a 16-bit value on the x86 as well as it does a 32-bit value (or clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93040
Bug ID: 93040
Summary: gcc doesn't optimize unaligned accesses to a 16-bit
value on the x86 as well as it does a 32-bit value (or
clang)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: miles at gnu dot org
Target Milestone: ---
Given the following code:
unsigned short get_unaligned_16 (unsigned char *p)
{
return p[0] | (p[1] << 8);
}
unsigned int get_unaligned_32 (unsigned char *p)
{
return get_unaligned_16 (p) | (get_unaligned_16 (p + 2) << 16);
}
unsigned int get_unaligned_32_alt (unsigned char *p)
{
return p[0] | (p[1] << 8) | (p[2] << 16) | (p[3] << 24);
}
... Clang/LLVM (trunk, but it has the same results many versions back)
generates the following very nice output:
get_unaligned_16: # @get_unaligned_16
movzx eax, word ptr [rdi]
ret
get_unaligned_32: # @get_unaligned_32
mov eax, dword ptr [rdi]
ret
get_unaligned_32_alt: # @get_unaligned_32_alt
mov eax, dword ptr [rdi]
ret
Whereas gcc (trunk but ditto) generates:
get_unaligned_16:
movzx eax, BYTE PTR [rdi+1]
sal eax, 8
mov edx, eax
movzx eax, BYTE PTR [rdi]
or eax, edx
ret
get_unaligned_32:
movzx eax, BYTE PTR [rdi+3]
sal eax, 8
mov edx, eax
movzx eax, BYTE PTR [rdi+2]
or eax, edx
movzx edx, BYTE PTR [rdi+1]
sal eax, 16
mov ecx, edx
movzx edx, BYTE PTR [rdi]
sal ecx, 8
or edx, ecx
movzx edx, dx
or eax, edx
ret
get_unaligned_32_alt:
mov eax, DWORD PTR [rdi]
ret
Notice that in the "get_unaligned_32_alt" version, gcc _does_ detect
that this is really an unaligned access to a 32-bit integer and
reduces it to a single instruction on the x86, as that architecture
supports unaligned accesses.
However the 16-bit version, "get_unaligned_16", and get_unaligned_32
derived from that, it just uses the component bit-munching operations.
It does seem curious that gcc manages the 32-bit case, but fails on
the 16-bit case...
I tested gcc on godbolt.com, and Clang locally (and on godbolt).
Flags used:
-O2 -march=skylake
-Os and -O3 yield the same results.
Versions:
gcc (Compiler-Explorer-Build) 10.0.0 20191220 (experimental)
clang version 10.0.0 (https://github.com/llvm/llvm-project.git
b4dfa74a5d80b3602a5315fac2ef5f98b0e63708)
[Bug tree-optimization/51680] g++ 4.7 fails to inline trivial template stuff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680 --- Comment #22 from miles at gnu dot org --- This seems to have been fixed a long time ago (all the examples in the comment yield the "right" result). Can somebody close this bug?
[Bug lto/56775] New: -flto and -fprofile-generate together result in a link-time internal compiler error (in "add_symbol_to_partition")
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56775 Bug #: 56775 Summary: -flto and -fprofile-generate together result in a link-time internal compiler error (in "add_symbol_to_partition") Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@gnu.org If I compile my program with _both_ options "-flto" and "-fprofile-generate", I get a link-time compile error. Using either "-flto" or "-fprofile-generate" _separately_ seems to work correctly. Compiler version is: g++ (Debian 20130316-1) 4.8.0 20130316 (experimental) [trunk revision 196694] I'm not exactly sure how to cut this down...trivial test cases don't seem to have the same problem. A transcript of the final link (the options passed when compiling each object file are similar, minus libraries etc): % make V=1 EXTRA_COMPILE_FLAGS=-fprofile-generate make all-am make[1]: Entering directory `/home/miles/src/snogray/snogray' g++-snapshot -O3 -fomit-frame-pointer -flto -ffast-math -march=native -mfpmath=sse -g -std=c++11 -Wall -Wextra -Winit-self -Wdouble-promotion -pedantic-errors -Wno-long-long -fprofile-generate -fno-finite-math-only -ftrapping-math -fno-associative-math -ffunction-sections -pthread -Wl,--icf=all -o snogray snogray.o recover-image.o libsnoglua.a libsnograw.a liblpeg.a -L/usr//lib -lluajit-5.1 libsnogrdrive.a libsnogloaders.a -l3ds libsnogmat.a libsnogsurf.a libsnoglight.a libsnogrender.a libsnogtex.a libsnogspace.a libsnogscene.a libsnogimagecli.a libsnogimage.a -lpng12 -pthread -lIlmImf -lz -lImath -lHalf -lIex -lIlmThread -ljpeg -lnetpbm libsnogcolor.a libsnogcli.a libsnogutil.a lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. lto-wrapper: g++ returned 1 exit status /usr/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status make[1]: *** [snogray] Error 1 make[1]: Leaving directory `/home/miles/src/snogray/snogray' make: *** [all] Error 2
[Bug c++/50477] New: -Wunused-parameter should not warn about virtual method declarations with bodies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50477
Bug #: 50477
Summary: -Wunused-parameter should not warn about virtual
method declarations with bodies
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org
In the following code:
struct X { virtual void f (int a) { } };
One gets a warning from -Wunused-parameter, "unused parameter 'a'".
While this is understandable, I think it's undesirable -- clearly the parameter
'a' will often be used by overrides of X::f, and the parameter name 'a' serves
a valuable documentation purpose here, even if it's not strictly required.
The basic problem of course, is that in this case, f is both a virtual method
declaration which covers overriding methods as well, and a definition of X's
definition of it.
One can avoid this by defining X::f outside the class definition, but for
trivial definitions like the above, this would seem like annoying make-work if
done only to shut up -Wunused-parameter.
My current method of avoiding the warning is to comment out the parameter name:
virtual void f (int /* a */) { }
but this again seems like an annoying wart, rather than natural code -- it's
both less readable (especially when the parameter has a funny type like a
function pointer) and yields a slightly confusing inconsistency ("why do
comment-out some method parameter names but not others?!" "oh it's just to shut
up -Wunused-parameter... :(").
Anyway, the current behavior seems wrong to me; I think -Wunused-parameter
shoul d stay silent for method virtual definitions inside the class definition.
[If this were a very rare scenario, I suppose I wouldn't care about the need to
work around it, but it seems to happen all the time for me...]
Thanks,
-Miles
[Bug c++/50477] -Wunused-parameter should not warn about virtual method declarations with bodies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50477
--- Comment #2 from miles at gnu dot org 2011-09-22 22:34:01 UTC ---
(In reply to comment #1)
> Having a name vs having correct documentation is the best way. Also you can
> use the attribute unused in C++ now.
Sorry, I'm not sure I understand your first sentence. [Of course these methods
also have proper documentation, but that doesn't mean it's OK for the code to
be obfuscated; _both_ should be readable and clear.]
Yeah, you can use an "unused" attribute (or various other methods), but the
problem is that they all uglify the code. This would be acceptable if it were
a rare case, or one where adding an unused attribute actually provided useful
information -- such as in a _separate_ method definition, where the fact that
the argument is unused is notable.
However my experience is that this case is not rare at all, and in fact, I find
it very common for the root of a class hierarchy to provide trivial/no-op
default definitions for methods that are given more complicated definitions in
subclasses.
Moreover, adding an "unused" attribute actually seems _harmful_ in this case
(in the sense of "confusing"), because it's not just a definition of a
particular class's method body, it's a method declaration that applies to all
the subclasses too. So if a user sees "attribute ((unused))" next to an
argument in the declaration, a natural question might be "wait, what? am I not
supposed to use this argument in my subclass definitions??"
[If it were a human, a better criteria than just "virtual method with body
defined in class" might include "... and also an obviously trivial definition"
(e.g., {} or {return true;}, etc); but I'm not sure it's reasonable to ask the
compiler to look at that kind of thing...]
[Bug c++/50477] -Wunused-parameter should not warn about virtual method declarations with bodies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50477 --- Comment #4 from miles at gnu dot org 2011-09-23 08:59:47 UTC --- It's different because unlike most function/method definitions, this is _two_ things together -- a virtual method declaration, which pertains to this class and all subclasses, and a method definition, which only instead only really pertains to this class. Note that if you separate the definition and the declaration, there's no issue -- the definition can have the parameter name omitted, or use the "unused" attribute, and it makes perfect sense, both to the compiler, and to readers. But if one uses the inline definition, there's no way to separate these two uses; the compiler still understands of course; it's readers who are inconvenienced, because they see code obfuscation intended for the _definition_ when they read the code to see the _declaration_. If it were a simple function (or an out-of-line method definition, or a non-virtual method), I'd happily use attribute "unused" (or whatever), because it clearly does apply to the definition, and indeed makes the code more readable by documenting something. It's only in this case where two different things are mixed together that I'm uncomfortable doing so. I'm not denying that there are many ways to make the compiler happy; my complaint is that they all make the code less readable, and I think readability is important.
[Bug c++/50671] New: NSDMI not parsed correctly for multiple-data-member declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50671
Bug #: 50671
Summary: NSDMI not parsed correctly for multiple-data-member
declarations
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org
The new NSDMI support seems to work generally, but the following gives a syntax
error:
struct X { int i = 3, j = 4; };
$ g++-snapshot -c -std=c++0x i.cc
i.cc:1:21: error: expected ';' before ',' token
It certainly seems like this _should_ be valid code, and the clang trunk
compiles it fine.
If I split the declaration, like "struct X { int i = 3; int j = 4; }", gcc
compiles it as expected.
$ g++-snapshot --version
g++ (Debian 20111008-1) 4.7.0 20111008 (experimental) [trunk revision 179709]
Thanks,
-miles
[Bug c++/53287] New: "self-initialization" warning doesn't seem to work for non-primitive types...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53287
Bug #: 53287
Summary: "self-initialization" warning doesn't seem to work for
non-primitive types...
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org
Gcc has a warning "-Winit-self" which is supposed to warn about cases like "int
x = x;"
It seems to work properly for primitive types, but emits no warnings for
classes.
E.g., the following:
struct S { S (); S (const S &); int i; };
extern void g (const S &);
void f ()
{
S x = x;
g (x);
}
compiles without warnings:
$ g++-snapshot -c x.cc -O2 -Wall -Wextra -Winit-self
$ g++-snapshot --version
g++ (Debian 20120501-1) 4.8.0 20120501 (experimental) [trunk revision
187013]
Replacing the definition of "S" with "typedef int S;", results in the expected
warning: "warning: 'x' is used uninitialized in this function
[-Wuninitialized]", although the warning-flag referenced in the message
("-Wuninitialized") seems a bit odd, as it's clearly -Winit-self that controls
this -- removing -Winit-self from the command-line (but keeping -Wall and
-Wextra) eliminates the warning...
Thanks,
-miles
[Bug c++/51666] New: NSDMI parse fails for template'd intializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51666
Bug #: 51666
Summary: NSDMI parse fails for template'd intializer
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org
The following code:
template
struct tuple
{
tuple(T, U) { }
};
struct Y
{
tuple tt = tuple{1, 2}; // *error*
};
Fails with a parse error in gcc 4.7 20111210:
$ g++-snapshot -c -std=c++11 nsdmi3.cc
nsdmi3.cc:9:36: error: expected unqualified-id before 'int'
nsdmi3.cc:9:31: error: wrong number of template arguments (1, should be 2)
nsdmi3.cc:2:9: error: provided for 'template struct tuple'
$ g++-snapshot --version
g++ (Debian 20111210-1) 4.7.0 20111210 (experimental) [trunk revision
182188]
Thanks,
-miles
[Bug c++/51680] New: g++ 4.7 fails to inline trivial template stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680
Bug #: 51680
Summary: g++ 4.7 fails to inline trivial template stuff
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org
Given the following source code (and options "-O2 -S"):
extern void process (float);
template
void process_fun_at (const Fun &fun, T x)
{
process (fun (x));
}
static float add1 (float x)
{
return x + 1;
}
void test (float i)
{
process_fun_at (add1, i);
}
g++ 4.6 (and clang++ 3.0) produce the obvious output, inlining the template
function "process_fun_at", and the function "add1":
.globl test(float)
test(float):
addss.LC0(%rip), %xmm0
jmp process(float)
.LC0:
.long1065353216
.ident "GCC: (Debian 4.6.2-9) 4.6.2"
However g++ 4.7 produces much more awkward code, inlining nothing:
add1(float):
addss.LC0(%rip), %xmm0
ret
void process_fun_at(float ( const&)(float), float):
subq $8, %rsp
call *%rdi
addq $8, %rsp
jmp process(float)
.globl test(float)
test(float):
movl add1(float), %edi
jmp void process_fun_at(float (
const&)(float), float)
.LC0:
.long1065353216
.ident "GCC: (Debian 20111210-1) 4.7.0 20111210 (experimental)
[trunk revision 182188]"
If I add the keyword "inline" to the declaration of the "process_fun_at"
template function, then g++ 4.7 inlines everything and produces the same result
as 4.6.
However my impression is that given such very simple input, it should do this
inlining automatically.
g++ version is:
(Debian 20111210-1) 4.7.0 20111210 (experimental) [trunk revision 182188]
Thanks,
-miles
[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680 --- Comment #2 from miles at gnu dot org 2011-12-27 13:54:38 UTC --- Hmm, I dunno, my impression is that people expect that template'd code is, in general "more inlined" -- templates are often used kind of as macro replacement in C++ -- especially for very trivial cases like this one...
[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680
--- Comment #6 from miles at gnu dot org 2011-12-28 01:04:05 UTC ---
Well, it's just an impression ... :]
I think one reason is that unlike normal functions, template functions are
implicitly sort of "local" (by necessity), in that they can have a definition
in many compilation units without causing a link conflict. To get this effect
for normal functions, one must use the "static" or "inline" keywords -- so the
impression (rightly or wrongly) is that template functions definitions are like
one of those.
... and of course if a [normal] function definition has "static" or "inline"
attached, gcc does do inlining differently. As I mentioned in my original
report, gcc 4.6, seems to treat template functions this way w/r/t inlining, as
if they were static.[*]
On another note, I'd kinda expect gcc these days to be making pretty reasonable
decisions about inlining even without hints; that's why I'm surprised at
behavior of my example, where the functions involved are so trivial that
inlining seems almost always a good bet...
[*] For instance, here's a "normal function" version of my example: extern
void process (float);
void process_fun_at (float (&fun)(float), float x)
{
process (fun (x));
}
static float add1 (float x)
{
return x + 1;
}
void test (float i)
{
process_fun_at (add1, i);
}
gcc 4.6 will compile this differently if "process_fun_at" is declared "static";
if it's static, everything gets inlined, otherwise, nothing is inlined. gcc
4.6 completely inlines the original template example with no special
declaration for the "process_fun_at" template function, meaning it's being
treated kind of like it's static for inlining purposes.
gcc 4.7 compiles the normal-function example the same as gcc 4.6 for both
static and non-static cases, but _doesn't_ inline the template version by
default. So if nothing else, this is a change in behavior from gcc 4.6;
whether it's good or bad I dunno.
[and yeah, I know inlining heuristics are a big ball of hair that nobody wants
to mess with if they can help it sorry :]
Thanks,
-miles
[Bug tree-optimization/51680] g++ 4.7 fails to inline trivial template stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680
--- Comment #18 from miles at gnu dot org 2013-01-09 05:35:35 UTC ---
Is this considered fixed yet? Given the following example, the latest Debian
trunk snapshot ("4.8.0 20121120 (experimental) [trunk revision 193662]", using
flags "-O2") seems to do a good job inlining this code well, even with many
calls (whereas 4.7 does not, once the number of calls goes beyond 3-4 or so):
extern void process (float);
template
void process_fun_at (const Fun &fun, T x)
{
process (fun (x));
}
static float add1 (float x)
{
return x + 1;
}
void test0 (float i) { process_fun_at (add1, i); }
void test1 (float i) { process_fun_at (add1, i); }
void test2 (float i) { process_fun_at (add1, i); }
void test3 (float i) { process_fun_at (add1, i); }
void test4 (float i) { process_fun_at (add1, i); }
void test5 (float i) { process_fun_at (add1, i); }
void test6 (float i) { process_fun_at (add1, i); }
void test7 (float i) { process_fun_at (add1, i); }
void test8 (float i) { process_fun_at (add1, i); }
void test9 (float i) { process_fun_at (add1, i); }
void test10 (float i) { process_fun_at (add1, i); }
void test11 (float i) { process_fun_at (add1, i); }
void test12 (float i) { process_fun_at (add1, i); }
void test13 (float i) { process_fun_at (add1, i); }
void test14 (float i) { process_fun_at (add1, i); }
void test15 (float i) { process_fun_at (add1, i); }
void test16 (float i) { process_fun_at (add1, i); }
void test17 (float i) { process_fun_at (add1, i); }
void test18 (float i) { process_fun_at (add1, i); }
void test19 (float i) { process_fun_at (add1, i); }
[Bug c++/43812] New: compiling .cc file with -fwhole-program results in ICE, in ipcp_iterate_stage, at ipa-cp.c:760
The compiler is actually from the debian "gcc-snapshot" package, version
20100414-1. The same error occurs using the debian g++-4.5 package (version
4.5-20100404-1).
The same error occurs for many source-files in my program, so I've just picked
one.
I will attach the pre-processed source-file after I submit the bug. With the
pre-processed source file in /tmp/local-surface-pp.cc, I compiled with the
following commands:
$ LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:
$
PATH=/usr/lib/gcc-snapshot/bin:/home/soft1/miles/bin:/usr/local/bin:/usr/games:/usr/bin:/bin:/usr/sbin:/sbin:.
$ export PATH LD_LIBRARY_PATH
$ g++ -v -fwhole-program -pthread -O3 -fomit-frame-pointer -ffast-math
-march=native -mfpmath=sse -g -std=c++0x -Wall -Wextra -fno-finite-math-only
-ftrapping-math -fno-associative-math -c local-surface-pp.cc
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20100414-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --disable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-gold --with-plugin-ld=ld.gold --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.5-snap/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.5-snap
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.5-snap
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --with-arch-32=i486 --with-tune=generic --disable-werror
--enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.0 (Debian 20100414-1)
COLLECT_GCC_OPTIONS='-v' '-fwhole-program' '-pthread' '-O3'
'-fomit-frame-pointer' '-ffast-math' '-mfpmath=sse' '-g' '-std=c++0x' '-Wall'
'-Wextra' '-fno-finite-math-only' '-ftrapping-math' '-fno-associative-math'
'-c' '-shared-libgcc'
/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.5.0/cc1plus -quiet -v
-D_GNU_SOURCE -D_REENTRANT local-surface-pp.cc -march=core2 -mcx16 -msahf
-msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param
l2-cache-size=6144 -mtune=core2 -quiet -dumpbase local-surface-pp.cc
-mfpmath=sse -auxbase local-surface-pp -g -O3 -Wall -Wextra -std=c++0x -version
-fwhole-program -fomit-frame-pointer -ffast-math -fno-finite-math-only
-ftrapping-math -fno-associative-math -o /tmp/ccxxX99K.s
GNU C++ (Debian 20100414-1) version 4.5.0 (x86_64-linux-gnu)
compiled by GNU C version 4.5.0, GMP version 4.3.2, MPFR version
2.4.2-p1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.5.0/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.5.0/../../../../include/c++/4.5.0
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.5.0/../../../../include/c++/4.5.0/x86_64-linux-gnu
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.5.0/../../../../include/c++/4.5.0/backward
/usr/local/include
/usr/lib/gcc-snapshot/include
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.5.0/include
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.5.0/include-fixed
/usr/include
End of search list.
GNU C++ (Debian 20100414-1) version 4.5.0 (x86_64-linux-gnu)
compiled by GNU C version 4.5.0, GMP version 4.3.2, MPFR version
2.4.2-p1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: b5bba9b3a42b8bffe7d64192a699586c
local-surface.cc:37:1: internal compiler error: in ipcp_iterate_stage, at
ipa-cp.c:760
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
--
Summary: compiling .cc file with -fwhole-program results in ICE,
in ipcp_iterate_stage, at ipa-cp.c:760
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: miles at gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43812
[Bug c++/43812] compiling .cc file with -fwhole-program results in ICE, in ipcp_iterate_stage, at ipa-cp.c:760
--- Comment #1 from miles at gnu dot org 2010-04-20 05:59 --- The bug system won't let me attach the file, so I've got to find someplace to stash it: "The file you are trying to attach is 1367 kilobytes (KB) in size. Non-patch attachments cannot be more than 1000 KB." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43812
[Bug c++/43812] compiling .cc file with -fwhole-program results in ICE, in ipcp_iterate_stage, at ipa-cp.c:760
--- Comment #2 from miles at gnu dot org 2010-04-20 06:52 --- Created an attachment (id=20434) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20434&action=view) "local-surface-pp.cc", gzipped the uncompressed version of this file was too large to attach [note that the actual source file is very small, but various system headers really bloat things up, so it wasn't obvious how to cut down the size...] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43812
[Bug lto/62179] New: undefined reference linking failure when combining "extern template"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62179 Bug ID: 62179 Summary: undefined reference linking failure when combining "extern template" Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: miles at gnu dot org
[Bug lto/62179] undefined reference linking failure when combining "extern template"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62179 --- Comment #2 from miles at gnu dot org --- Sorry, that got submitted accidentally (it turns out that RET in the web page Summary text-box is bound to "submit"!) I'm not sure how to delete a bogus report... ^^; Could you delete that? [I updated my copy of gcc and it seems the bug I was going to report _may_ have been fixed but I'm running into other problems so I'm not sure yet.] Thanks, -miles 2014年8月19日火曜日、rguenth at gcc dot gnu.orgさんは書きました: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62179 > > Richard Biener changed: > >What|Removed |Added > > > Status|UNCONFIRMED |WAITING >Last reconfirmed||2014-08-19 > Ever confirmed|0 |1 > > --- Comment #1 from Richard Biener --- > Waiting for ... the bugreport? Testcase? > > -- > You are receiving this mail because: > You reported the bug. >
[Bug c++/48749] New: internal compiler error: tree check: expected field_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48749 Summary: internal compiler error: tree check: expected field_decl Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@gnu.org Created attachment 24088 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24088 source code demonstrating bug Compile the attached code with g++, and: $ g++-snapshot -c ,barf.i.cc ,barf.i.cc: In member function 'virtual T CylinderMapTex::eval(const TexCoords&) const': ,barf.i.cc:46:16: internal compiler error: tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:5885 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. $ g++-snapshot --version g++ (Debian 20110419-1) 4.7.0 20110419 (experimental) [trunk revision 172699] Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Thanks, -miles
[Bug tree-optimization/45978] [4.6/4.7 Regression] bogus "array subscript is above array bounds" warning in extremely simple code with no loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45978 --- Comment #5 from miles at gnu dot org 2011-05-20 04:09:01 UTC --- Hmm, I'm not getting this warning anymore ... is the bug fixed? [version "g++ (Debian 20110519-1) 4.7.0 20110519 (experimental) [trunk revision 173903]"] Thanks, -Miles
[Bug middle-end/45978] New: bogus "array subscript is above array bounds" warning in extremely simple code with no loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45978
Summary: bogus "array subscript is above array bounds" warning
in extremely simple code with no loops
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org
Created attachment 22021
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22021
C++ source file illustrating bug
[I don't know if the "component:" field is correct, but there doesn't seem to
be a "I don't know" option]
There are many bugs in gcc's bugzilla related to bogus array-bounds warnings,
but most of them seem to involve loops and other situations that may need
non-trivial analysis by the compiler.
However the attached C++ source file ("tt.cc") seems to be almost trivial; it
contains no loops at all, and all array references use a constant (and valid)
index, but it nonetheless elicits an "array subscript is above array bounds"
warning from the compiler. As far as I can figure, the warning is bogus.
Compilation looks like:
$ g++-snapshot -O3 -S -Wall -Wextra tt.cc
tt.cc: In function 'Z test()':
tt.cc:15:21: warning: array subscript is above array bounds [-Warray-bounds]
Version info:
$ g++-snapshot --version
g++ (Debian 20101009-1) 4.6.0 20101009 (experimental) [trunk revision
165234]
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
"g++-snapshot" just invokes g++ from Debian's gcc-snapshot package, which is a
somewhat recent trunk snapshot.
["tt.cc" is as minimal as I can get it -- moving, eliminating, or changing any
field in any of the structures seems to silence the warning.]
Thanks,
-Miles
[Bug libstdc++/46207] New: std::atomic::store(...) fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46207
Summary: std::atomic::store(...) fails to compile
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org
The following program:
#include
std::atomic non_const_int_pointer;
void non_const_set (int *value)
{
non_const_int_pointer.store (value, std::memory_order_release);
}
#ifndef SUPPRESS_CONST
std::atomic const_int_pointer;
void const_set (const int *value)
{
const_int_pointer.store (value, std::memory_order_release);
}
#endif
compiled with options "-O2 -march=native -std=c++0x", gives an error and fails
to compile because of the call to "const_int_pointer.store" (see error log
below).
However, the program compiles successfully if I add "-DSUPPRESS_CONST" to the
compiler options -- the call of "non_const_int_pointer.store" does not seem to
cause any problems.
Error log:
$ g++-snapshot --version
g++ (Debian 20101016-1) 4.6.0 20101016 (experimental) [trunk revision 165538]
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++-snapshot -O2 -march=native -std=c++0x -S al.cc
In file included from al.cc:1:0:
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/atomic:
In member function 'void std::atomic<_Tp*>::store(_Tp*, std::memory_order)
[with _Tp = const int, std::memory_order = std::memory_order]':
al.cc:13:60: instantiated from here
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/atomic:145:9:
error: invalid conversion from 'const void*' to 'void*' [-fpermissive]
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/atomic_2.h:99:5:
error: initializing argument 1 of 'void
std::__atomic2::atomic_address::store(void*, std::memory_order)' [-fpermissive]
$ g++-snapshot -DSUPPRESS_CONST -O2 -march=native -std=c++0x -S al.cc
$
[Bug tree-optimization/46507] New: std::tuple missed optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507
Summary: std::tuple missed optimization
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org
My understanding is that std::tuple should offer largely the same optimization
opportunities as std::pair (while being more flexible).
However gcc-4.6 seems to miss some optimizations with std::tuple that it
doesn't with pair.
E.g. the following code ("tp.cc"):
start
#include
#include
struct A
{
virtual void f () const;
};
void arg_tuple_test (const std::tuple &t)
{
std::get<0>(t).f ();
}
void extern_tuple_test ()
{
extern const std::tuple &t;
std::get<0>(t).f ();
}
void arg_pair_test (const std::pair &t)
{
t.first.f ();
}
end
compiled with:
g++-snapshot -std=c++0x -O2 -march=amdfam10 -S tp.cc
results in the following assembly:
arg_tuple_test(std::tuple const&):
movq(%rdi), %rax
movq(%rax), %rax
jmp*%rax
extern_tuple_test():
movqt(%rip), %rdi
movq(%rdi), %rax
movq(%rax), %rax
jmp*%rax
arg_pair_test(std::pair const&):
jmpA::f() const
.ident"GCC: (Debian 20101114-1) 4.6.0 20101114 (experimental) [trunk
revision 166728]"
It seems like all of these functions should use a direct jump to A::f, but the
tuple versions do not.
Note that when I tried this same test yesterday, on a different machine (but
the same compiler version), "extern_tuple_test" (but not "arg_tuple_test")
_did_ result in a direct jump to A::f! So maybe something funny is going on...
Thanks,
-Miles
[Bug tree-optimization/46507] std::tuple missed optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507
--- Comment #2 from miles at gnu dot org 2010-11-16 19:06:02 UTC ---
> Note that when I tried this same test yesterday, on a different machine (but
> the same compiler version), "extern_tuple_test" (but not "arg_tuple_test")
> _did_ result in a direct jump to A::f! So maybe something funny is going
> on...
Actually this is wrong: the version of "extern_tuple_test" which worked
yesterday was really this:
void extern_tuple_test ()
{
extern const std::tuple t;
std::get<0>(t).f ();
}
resulting in:
extern_tuple_test():
movl$t, %edi
jmpA::f() const
Still, it seems like "arg_tuple_test" (and the previous version of
"extern_tuple_tst") should also received the same optimization.
[Bug c++/46701] New: internal compiler error: in build_data_member_initialization, at cp/semantics.c:5503
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46701
Summary: internal compiler error: in
build_data_member_initialization, at
cp/semantics.c:5503
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org
I don't know if this is the same as the other ICEs in
build_data_member_initialization, but it's at a different line number anyway...
Compiler version is:
g++ (Debian 20101128-1) 4.6.0 20101128 (experimental) [trunk revision 167220]
Here's the un-preprocessed source (preprocessed source attached):
#include
#include
void f (const std::string &name, const std::string &val)
{
std::map::value_type (name, val);
}
Compiled with:
g++-snapshot -c -std=c++0x ,oink.cc
yields:
In file included from
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_algobase.h:65:0,
from
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/char_traits.h:41,
from
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/string:42,
from ,oink.cc:1:
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:
In constructor 'constexpr std::pair<_T1, _T2>::pair(const _T1&, const _T2&)
[with _T1 = const std::basic_string, _T2 = std::basic_string]':
,oink.cc:6:66: instantiated from here
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:102:35:
internal compiler error: in build_data_member_initialization, at
cp/semantics.c:5503
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Thanks,
-miles
[Bug c++/46701] internal compiler error: in build_data_member_initialization, at cp/semantics.c:5503
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46701 --- Comment #1 from miles at gnu dot org 2010-11-29 04:25:03 UTC --- Created attachment 22559 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22559 preprocessed source showing crash Generated with: g++-snapshot -E -std=c++0x
[Bug c++/46701] internal compiler error: in build_data_member_initialization, at cp/semantics.c:5503
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46701 --- Comment #2 from miles at gnu dot org 2010-11-29 04:30:16 UTC --- BTW, sorry about the duplicate bugs. Bugzilla complains about not being able to autodetect the attachment content-type, and says "hit BACK and try again" -- but doesn't mention that the bug was submitted anyway! [and of course there doesn't actually seem to be anyway to specify the content-type of an attachment on the new-bug page...]
[Bug c++/46697] New: internal compiler error: in build_data_member_initialization, at cp/semantics.c:5503
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46697
Summary: internal compiler error: in
build_data_member_initialization, at
cp/semantics.c:5503
Product: gcc
Version: 4.6.0
Status: RESOLVED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org
miles at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||DUPLICATE
I don't know if this is the same as the other ICEs in
build_data_member_initialization, but it's at a different line number anyway...
Compiler version is:
g++ (Debian 20101128-1) 4.6.0 20101128 (experimental) [trunk revision 167220]
Here's the un-preprocessed source (preprocessed source attached):
#include
#include
void f (const std::string &name, const std::string &val)
{
std::map::value_type (name, val);
}
Compiled with:
g++-snapshot -c -std=c++0x ,oink.cc
yields:
In file included from
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_algobase.h:65:0,
from
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/char_traits.h:41,
from
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/string:42,
from ,oink.cc:1:
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:
In constructor 'constexpr std::pair<_T1, _T2>::pair(const _T1&, const _T2&)
[with _T1 = const std::basic_string, _T2 = std::basic_string]':
,oink.cc:6:66: instantiated from here
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:102:35:
internal compiler error: in build_data_member_initialization, at
cp/semantics.c:5503
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Thanks,
-miles
--- Comment #1 from miles at gnu dot org 2010-11-29 05:14:29 UTC ---
(I accidentally filed the same bug multiple times, so I'm marking all but one
as duplicates)
*** This bug has been marked as a duplicate of bug 46701 ***
[Bug c++/46701] internal compiler error: in build_data_member_initialization, at cp/semantics.c:5503
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46701 --- Comment #3 from miles at gnu dot org 2010-11-29 05:14:29 UTC --- *** Bug 46697 has been marked as a duplicate of this bug. ***
[Bug c++/46701] internal compiler error: in build_data_member_initialization, at cp/semantics.c:5503
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46701 --- Comment #4 from miles at gnu dot org 2010-11-29 05:14:53 UTC --- *** Bug 46698 has been marked as a duplicate of this bug. ***
[Bug c++/46698] New: internal compiler error: in build_data_member_initialization, at cp/semantics.c:5503
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46698
Summary: internal compiler error: in
build_data_member_initialization, at
cp/semantics.c:5503
Product: gcc
Version: 4.6.0
Status: RESOLVED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org
miles at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||DUPLICATE
I don't know if this is the same as the other ICEs in
build_data_member_initialization, but it's at a different line number anyway...
Compiler version is:
g++ (Debian 20101128-1) 4.6.0 20101128 (experimental) [trunk revision 167220]
Here's the un-preprocessed source (preprocessed source attached):
#include
#include
void f (const std::string &name, const std::string &val)
{
std::map::value_type (name, val);
}
Compiled with:
g++-snapshot -c -std=c++0x ,oink.cc
yields:
In file included from
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_algobase.h:65:0,
from
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/char_traits.h:41,
from
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/string:42,
from ,oink.cc:1:
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:
In constructor 'constexpr std::pair<_T1, _T2>::pair(const _T1&, const _T2&)
[with _T1 = const std::basic_string, _T2 = std::basic_string]':
,oink.cc:6:66: instantiated from here
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:102:35:
internal compiler error: in build_data_member_initialization, at
cp/semantics.c:5503
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Thanks,
-miles
--- Comment #1 from miles at gnu dot org 2010-11-29 05:14:53 UTC ---
(I accidentally filed the same bug multiple times, so I'm marking all but one
as duplicates)
*** This bug has been marked as a duplicate of bug 46701 ***
[Bug c++/46699] New: internal compiler error: in build_data_member_initialization, at cp/semantics.c:5503
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46699
Summary: internal compiler error: in
build_data_member_initialization, at
cp/semantics.c:5503
Product: gcc
Version: 4.6.0
Status: RESOLVED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org
miles at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||DUPLICATE
I don't know if this is the same as the other ICEs in
build_data_member_initialization, but it's at a different line number anyway...
Compiler version is:
g++ (Debian 20101128-1) 4.6.0 20101128 (experimental) [trunk revision 167220]
Here's the un-preprocessed source (preprocessed source attached):
#include
#include
void f (const std::string &name, const std::string &val)
{
std::map::value_type (name, val);
}
Compiled with:
g++-snapshot -c -std=c++0x ,oink.cc
yields:
In file included from
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_algobase.h:65:0,
from
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/char_traits.h:41,
from
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/string:42,
from ,oink.cc:1:
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:
In constructor 'constexpr std::pair<_T1, _T2>::pair(const _T1&, const _T2&)
[with _T1 = const std::basic_string, _T2 = std::basic_string]':
,oink.cc:6:66: instantiated from here
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:102:35:
internal compiler error: in build_data_member_initialization, at
cp/semantics.c:5503
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Thanks,
-miles
--- Comment #1 from miles at gnu dot org 2010-11-29 05:15:18 UTC ---
(I accidentally filed the same bug multiple times, so I'm marking all but one
as duplicates)
*** This bug has been marked as a duplicate of bug 46701 ***
[Bug c++/46701] internal compiler error: in build_data_member_initialization, at cp/semantics.c:5503
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46701 --- Comment #5 from miles at gnu dot org 2010-11-29 05:15:18 UTC --- *** Bug 46699 has been marked as a duplicate of this bug. ***
[Bug c++/46701] internal compiler error: in build_data_member_initialization, at cp/semantics.c:5503
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46701 --- Comment #6 from miles at gnu dot org 2010-11-29 05:15:43 UTC --- *** Bug 46700 has been marked as a duplicate of this bug. ***
[Bug c++/46700] New: internal compiler error: in build_data_member_initialization, at cp/semantics.c:5503
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46700
Summary: internal compiler error: in
build_data_member_initialization, at
cp/semantics.c:5503
Product: gcc
Version: 4.6.0
Status: RESOLVED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org
miles at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||DUPLICATE
I don't know if this is the same as the other ICEs in
build_data_member_initialization, but it's at a different line number anyway...
Compiler version is:
g++ (Debian 20101128-1) 4.6.0 20101128 (experimental) [trunk revision 167220]
Here's the un-preprocessed source (preprocessed source attached):
#include
#include
void f (const std::string &name, const std::string &val)
{
std::map::value_type (name, val);
}
Compiled with:
g++-snapshot -c -std=c++0x ,oink.cc
yields:
In file included from
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_algobase.h:65:0,
from
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/char_traits.h:41,
from
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/string:42,
from ,oink.cc:1:
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:
In constructor 'constexpr std::pair<_T1, _T2>::pair(const _T1&, const _T2&)
[with _T1 = const std::basic_string, _T2 = std::basic_string]':
,oink.cc:6:66: instantiated from here
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_pair.h:102:35:
internal compiler error: in build_data_member_initialization, at
cp/semantics.c:5503
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Thanks,
-miles
--- Comment #1 from miles at gnu dot org 2010-11-29 05:15:43 UTC ---
(I accidentally filed the same bug multiple times, so I'm marking all but one
as duplicates)
*** This bug has been marked as a duplicate of bug 46701 ***
[Bug c++/49605] New: -Wdelete-non-virtual-dtor is not picky enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49605
Summary: -Wdelete-non-virtual-dtor is not picky enough
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@gnu.org
In the following program:
struct X
{
~X ();
virtual void meth ();
};
void d ()
{
X x;
}
"g++-snapshot -c -O2 -Wall nvdtor.cc" yields a warning:
nvdtor.cc: In function 'void d()':
nvdtor.cc:9:5: warning: deleting object of polymorphic class type 'X' which has
non-virtual destructor might cause undefined behaviour
[-Wdelete-non-virtual-dtor]
But it looks to me like the behavior in this case isn't undefined at all -- the
object being destroyed is stack-allocated, so gcc knows exactly what the actual
object type is; it's not possible for it to be a subclass of X.
Thanks,
-miles
[Bug c++/49605] -Wdelete-non-virtual-dtor is not picky enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49605
--- Comment #3 from miles at gnu dot org 2011-07-01 13:25:23 UTC ---
Here's another test case which is closer to the real code that prompted this
bug report:
struct X
{
~X ();
virtual void meth () = 0;
};
struct Y : X
{
~Y ();
virtual void meth ();
};
void d ()
{
Y y;
}
Thanks,
-miles
[Bug bootstrap/34045] gcc does not build on Debian etch AMD64
--- Comment #4 from miles at gnu dot org 2007-11-11 00:54 --- Wouldn't it be nice if the configure script caught this sort of thing automatically? It's obviously going to be a very common problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34045
