[Bug lto/41932] LTO ICE when compiling ocaml trunk (incompatible type)
--- Comment #2 from simon_baldwin at yahoo dot com 2009-11-04 12:17 ---
I have a minimal failing case for this, I think. I'm using trunk 153803, for
what it's worth.
$ cat demo.c
typedef long intnat;
typedef intnat value;
void caml_darken (value v, value *p) { }
$ .../gcc -flto -O2 -c -O -fPIC demo.c
$ .../gcc -flto -O2 -shared -o /dev/null demo.o
lto1: internal compiler error: Segmentation fault
Though it looks to be related to the ICE, the warning
gc_ctrl.c:44:16: warning: type of 'caml_major_heap_increment' does not match
original declaration
major_gc.c:33:8: note: previously declared here
seems genuine and unrelated to me. gc_ctrl.c declares this as extern asize_t
(size_t, long unsigned), major_gc.c defines it as intnat (long).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41932
[Bug lto/41932] LTO ICE when compiling ocaml trunk (incompatible type)
--- Comment #3 from simon_baldwin at yahoo dot com 2009-11-04 12:57 ---
A bit more info from a gdb trace:
Program received signal SIGSEGV, Segmentation fault.
0x00b798ce in ipa_populate_param_decls (node=0x2b453300,
info=0x15eb768) at ../../gcc/gcc/ipa-prop.c:141
141 info-params[param_num].decl = parm;
(gdb) bt
#0 0x00b798ce in ipa_populate_param_decls (node=0x2b453300,
info=0x15eb768) at ../../gcc/gcc/ipa-prop.c:141
#1 0x00b8192a in ipa_update_after_lto_read ()
at ../../gcc/gcc/ipa-prop.c:2165
#2 0x00b7224d in ipcp_iterate_stage () at ../../gcc/gcc/ipa-cp.c:736
#3 0x00b73beb in ipcp_driver () at ../../gcc/gcc/ipa-cp.c:1258
#4 0x007ceae5 in execute_one_pass (pass=0x1515960)
at ../../gcc/gcc/passes.c:1518
#5 0x007cf191 in execute_ipa_pass_list (pass=0x1515960)
at ../../gcc/gcc/passes.c:1730
#6 0x00b6e03a in ipa_passes () at ../../gcc/gcc/cgraphunit.c:1387
#7 0x00b6e111 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1421
#8 0x004b3278 in lto_main (debug_p=0) at ../../gcc/gcc/lto/lto.c:2008
#9 0x008c5751 in compile_file () at ../../gcc/gcc/toplev.c:1049
#10 0x008c7a4c in do_compile () at ../../gcc/gcc/toplev.c:2408
#11 0x008c7afd in toplev_main (argc=12, argv=0x7fffd458)
at ../../gcc/gcc/toplev.c:2450
#12 0x004b5c93 in main (argc=12, argv=0x7fffd458)
at ../../gcc/gcc/main.c:35
(gdb) p param_num
$1 = 0
(gdb) p info-params
$2 = (struct ipa_param_descriptor *) 0x0
(gdb) p info
$3 = (struct ipa_node_params *) 0x15eb768
(gdb) p *info
$4 = {param_count = 0, params = 0x0, param_calls = 0x0, ipcp_orig_node = 0x0,
count_scale = 0, called_with_var_arguments = 0,
modification_analysis_done = 0, uses_analysis_done = 0, node_enqueued = 0}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41932
[Bug testsuite/40829] gcc.dg/vect/no-scevccp-noreassoc-outer-2.c can segv
--- Comment #1 from simon_baldwin at yahoo dot com 2009-07-27 12:08 --- Committed revision 150109. -- simon_baldwin at yahoo dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40829
[Bug testsuite/40829] New: gcc.dg/vect/no-scevccp-noreassoc-outer-2.c can segv
From gcc.dg/vect/no-scevccp-noreassoc-outer-2.c:
6 #define N 40
7 int a[200*N];
8
9 __attribute__ ((noinline)) void
10 foo (){
11 int i,j;
12 int sum,s=0;
13
14 for (i = 0; i 200*N; i++) {
15 sum = 0;
16 for (j = 0; j N; j++) {
17 sum += (i + j);
18 i++;
19 }
20 a[i] = sum; // i exceeds 8000, runs off array end
21 }
22 }
In function foo(), at line 20, variable 'i' can exceed the bounds of array 'a',
and segv is possible.
The fix may be as simple as padding array 'a', provided this does not affect
the other things that this test validates.
--
Summary: gcc.dg/vect/no-scevccp-noreassoc-outer-2.c can segv
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon_baldwin at yahoo dot com
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=40829
[Bug c++/38908] New: Unexplained 'anonymous' is used uninitialized in this function warning in cc1plus -m64
cc1plus prints
x.cc: In member function 'typename S10T::S12 S2::S5T::S13() [with T = S8
()()]':
x.cc:15: error: 'anonymous' is used uninitialized in this function
in a gcc 4.4 trunk compilation of the C++ appended below for a 64-bit target.
It's unclear what precisely is uninitialized here, and the same warning does
not appear for 32-bit targets. This warning also doesn't appear in gcc 4.3.1
or earlier.
$ cat x.cc
struct S8 { templatetypename T S8(T) { } };
templatetypename T struct S10;
templatetypename T struct S10T() { typedef T S12; typedef S8 S1(); };
templatetypename T struct S3 { };
templatetypename T struct S11 { S11(S3T); };
struct S2
{
templatetypename T operator S11T() { return S11T(S5T()); }
templatetypename T struct S5:public S3T
{
virtual typename S10T::S12 S13() {
return 0;
}
};
};
templatetypename T S11T S6(S3T) { return S11T(S3T()); }
templatetypename S12 struct S7 { typedef S12 S15(); };
struct S4
{
templatetypename T operator S11T()
{
struct S14:public S3T
{
S14(S2 x):S11_(x) { }
S11typename S7typename S10T::S12::S15 S11_;
};
return S6(S14(S11_));
}
S2 S11_;
};
struct S9
{
templatetypename F operator S11F() { return S11F(S14F(S11_)); }
templatetypename F struct S14:public S3F
{
S14(S4 x):S11_(x) { }
S11typename S10F::S1 S11_;
};
S4 S11_;
};
void S15(S11void());
void S16() { S9 x; S15(x); }
$ cc1plus -Werror -m32 -version -quiet x.cc -O1 -Wuninitialized -o /dev/null
GNU C++ (GCC) version 4.4.0 20090118 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.0.3 (Ubuntu 4.0.3-1ubuntu5), GMP version 4.2.2,
MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 3943547ae1329ecd45283a86831b8d94
$ echo $?
0
$ cc1plus -Werror -m64 -version -quiet x.cc -O1 -Wuninitialized -o /dev/null
GNU C++ (GCC) version 4.4.0 20090118 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.0.3 (Ubuntu 4.0.3-1ubuntu5), GMP version 4.2.2,
MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 3943547ae1329ecd45283a86831b8d94
cc1plus: warnings being treated as errors
x.cc: In member function 'typename S10T::S12 S2::S5T::S13() [with T = S8
()()]':
x.cc:15: error: 'anonymous' is used uninitialized in this function
$ echo $?
1
--
Summary: Unexplained 'anonymous' is used uninitialized in this
function warning in cc1plus -m64
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon_baldwin at yahoo dot com
GCC build triplet: i386-unknown-linux-gnu
GCC host triplet: i386-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38908
[Bug c++/37348] New: internal compiler error: tree check: expected var_decl, have field_decl in cp_finish_decl, at cp/decl.c:5461
The following demonstrates a (minor severity) gcc-4.4-20080829 ICE on error
recovery with invalid code. No ICE seen in gcc 4.3.1 or prior.
$ cat /tmp/bogus.cc
struct Foo {
// class Bar;
template class int f(Bar);
};
$ ./gcc/xgcc --version
xgcc (GCC) 4.4.0 20080829 (experimental)
...
$ ./gcc/xgcc -Bgcc -c -o /dev/null /tmp/bogus.cc
/tmp/bogus.cc:3: error: 'Bar' was not declared in this scope
/tmp/bogus.cc:3: internal compiler error: tree check: expected var_decl, have
field_decl in cp_finish_decl, at cp/decl.c:5461
...
--
Summary: internal compiler error: tree check: expected var_decl,
have field_decl in cp_finish_decl, at cp/decl.c:5461
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon_baldwin at yahoo dot com
GCC target triplet: i386-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37348
[Bug c++/36999] Erroneous declaration 'class ...' does not declare anything warnings possible
--- Comment #6 from simon_baldwin at yahoo dot com 2008-08-07 14:42 --- Fixed for mainline and 4.3 branch -- resolving as FIXED. -- simon_baldwin at yahoo dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36999
[Bug c++/36999] Erroneous declaration 'class ...' does not declare anything warnings possible
--- Comment #3 from simon_baldwin at yahoo dot com 2008-08-06 12:00 --- Thanks for the note. Fixed for trunk; I'm currently in the process of backporting to the 4.3 branch since the bug is there also. -- simon_baldwin at yahoo dot com changed: What|Removed |Added Known to fail||4.4.0 4.3.1 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36999
[Bug c++/36999] New: Erroneous declaration 'class ...' does not declare anything warnings possible
The following example program produces several unwarranted declaration ...
does not declare anything warnings. This problem is also present in gcc 4.3,
since this is when the warning was introduced.
File /tmp/warning.cc:
class C1 {
public: class C2 { };
};
void cf1 (class C1::C2, void*); // Should not provoke a warning
void cf2 (void*, class C1::C2);
void cf3 (C1::C2, void*);
namespace N {
enum E1 { foo };
enum E2 { bar };
template class X
class TC1 { };
template class T, class U
class TC2 : public TC1T { };
}
void
tcf1 (N::TC2enum N::E1, void* *arg1, // Should not provoke a warning
N::TC2void*, enum N::E1 *arg2,
N::TC2N::E1, void* *arg3)
{
}
void *
tcf2 (void *x)
{
return (void *)
(N::TC2enum N::E1, void* *) // Should not provoke a warning
(N::TC2void*, enum N::E1 *)
(N::TC2N::E1, void* *)
x;
}
/tmp/warning.cc:5: warning: declaration 'class C1::C2' does not declare
anything
/tmp/warning.cc:23: warning: declaration 'enum N::E1' does not declare anything
/tmp/warning.cc: In function 'void* tcf2(void*)':
/tmp/warning.cc:33: warning: declaration 'enum N::E1' does not declare anything
--
Summary: Erroneous declaration 'class ...' does not declare
anything warnings possible
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon_baldwin at yahoo dot com
GCC target triplet: i386-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36999
[Bug c++/35652] [4.1/4.2/4.3/4.4 Regression] Location information incorrect on string bounds warning
--- Comment #4 from simon_baldwin at yahoo dot com 2008-04-26 17:21 --- Closing. Location information may still not be accurate, but duplicate warnings are gone. -- simon_baldwin at yahoo dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug c++/35652] New: Location information incorrect on string bounds warning
The following demonstrates a location error in a string bounds warning message:
$ cat /tmp/c.cc
#include string
int main() {
// blank line padding, could also be code...
//
//
//
//
//
//
//
//
//
std::string s = ;
s += 'x' + y; // bogus
}
$ g++ -O2 -c /tmp/c.cc
/tmp/c.cc: In function 'int main()':
/tmp/c.cc:2: warning: offset outside bounds of constant string
/tmp/c.cc:2: warning: offset outside bounds of constant string
/tmp/c.cc:2: warning: offset outside bounds of constant string
/tmp/c.cc:2: warning: offset outside bounds of constant string
/tmp/c.cc:2: warning: offset outside bounds of constant string
/.../i686-unknown-linux-gnu/include/c++/4.3.0/bits/char_traits.h:262: warning:
offset outside bounds of constant string
/.../i686-unknown-linux-gnu/include/c++/4.3.0/bits/char_traits.h:262: warning:
offset outside bounds of constant string
The erroneous line is line 14, but g++ reports the problem (multiple times) at
line 2 and in an STL header file. The same behavior occurs in g++ 4.2.1,
4.1.1, 4.0.3, and 4.0.2. It does not occur in gcc 3.4.5.
Also, there is no warning emitted with -O0, for some reason.
--
Summary: Location information incorrect on string bounds warning
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon_baldwin at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug c++/34094] Undefined static data member in anonymous namespace can acquire a definition anyway
--- Comment #3 from simon_baldwin at yahoo dot com 2007-11-15 19:55 --- The definition's really there in 4.2.1, absent in 4.1.1: $ 4.2.1/g++ -S ns1.cc c++filt ns1.s | grep B::x movl$0, (anonymous namespace)::B::x .local (anonymous namespace)::B::x .comm (anonymous namespace)::B::x,4,4 $ 4.1.1/g++ -S ns1.cc c++filt ns1.s | grep B::x movl$0, (anonymous namespace)::B::x -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
[Bug c++/34094] New: Undefined static data member can acquire a definition anyway
The following program should fail to link, since anonymous::B::x is declared
but not defined. However, the program compiles, links, and runs with gcc 4.2.1
and with a relatively recent 4.3 snapshot.
This same program fails to build under gcc 4.1 and earlier, icc 8.1, and Comeau
test drive.
struct A {
A(void *) {}
};
namespace {
struct B : public A {
B() : A(x) {}
static int x; // declared, but never defined
};
}
int main() {
B::x = 0;
}
--
Summary: Undefined static data member can acquire a definition
anyway
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon_baldwin at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
[Bug c++/31923] g++ accepts a storage-class-specifier on a template explicit specialization
--- Comment #5 from simon_baldwin at yahoo dot com 2007-06-25 17:24 --- Indeed it can -- thanks for the reminder. Marking as FIXED. -- simon_baldwin at yahoo dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31923
[Bug c++/23689] Malformed typedef silently ignored
--- Comment #8 from simon_baldwin at yahoo dot com 2007-06-25 17:26 --- Resolved by revision 122434. -- simon_baldwin at yahoo dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23689
[Bug c++/31923] g++ accepts a storage-class-specifier on a template explicit specialization
--- Comment #2 from simon_baldwin at yahoo dot com 2007-06-14 21:29 --- Note: there's also a C++ language defect report relating to this issue, with recommendation from the CWG: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#605 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31923
[Bug c++/31923] New: g++ accepts a storage-class-specifier on a template explicit specialization
The following test program compiles without error or warning on g++ (versions 2.95.3, 3.4.5, 4.0.2, 4.1.0, 4.1.1, and 4.3-20070323): templateclass T static void F(); template static void Fint(); // Explicit specialization with storage class specifier The C++ standard seems to disallow this. From 7.1.1 - Storage class specifiers [dcl.stc], para 1: ... A storage-class-specifier shall not be specified in an explicit specialization (temp.expl.spec) or an explicit instantiation (temp.explicit) directive. I couldn't find an existing report of this, but may well have missed one. -- Summary: g++ accepts a storage-class-specifier on a template explicit specialization Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: simon_baldwin at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31923
[Bug c++/31449] New: static_cast can remove const-ness
The following const-incorrect program compiles without error on gcc 4.1.0, and
4.3.0 20070323:
class Foo {};
class Bar : public Foo {};
static const Foo *foo = 0;
static Bar *bar = static_castconst Bar*(foo); // Error, casts away const
void func(const Foo *foo) {
Bar *bar = static_castconst Bar*(foo); // Error, casts away const
}
gcc 2.95.3, 3.4.5, and 4.0.2 report errors on the commented lines above, so it
looks like a compiler regression in 4.1.0.
I looked hard through existing PRs, and couldn't find this reported elsewhere
(the closest is PR 20475, but it's concerned with 3.4.4 and the const-ness, or
otherwise, of string literals, so not the same). I'd be a little surprised if
I'm the first to see it, but it's possible...
--
Summary: static_cast can remove const-ness
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon_baldwin at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31449
[Bug c++/28774] Request for warning where const/volatile is ignored in a cast
--- Comment #7 from simon_baldwin at yahoo dot com 2007-03-12 21:48 --- PR 14710 isn't really quite the same thing as PR 28774. PR 14170 is concerned with unnecessary casts; PR 28774 is concerned with unnecessary const or volatile qualifiers within otherwise valid and perhaps necessary casts. That said, this PR really isn't all that useful, is tiny, and hasn't received a lot of support, so I'm going to withdraw it (by setting resolution to WONTFIX, which I hope will do the right thing). -- simon_baldwin at yahoo dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28774
[Bug c++/28992] New: g++ lacks the empty bodyin an if-statement warning emitted by gcc
$ cat bad_if.cc
#include stdio.h
int main() {
if (0); { /* Semicolon accidentally added between condition and brace. */
printf(Not intended to be printed\n);
}
return 0;
}
$ .../i686-unknown-linux-gnu-g++ --version
i686-unknown-linux-gnu-g++ (GCC) 4.1.0
$ .../i686-unknown-linux-gnu-g++ -W -Werror -o bad_if bad_if.cc; echo $?
0
$ .../i686-unknown-linux-gnu-g++ -xc -W -Werror -o bad_if bad_if.cc; echo $?
cc1: warnings being treated as errors
bad_if.cc: In function 'main':
bad_if.cc:4: warning: empty body in an if-statement
1
--
Summary: g++ lacks the empty bodyin an if-statement warning
emitted by gcc
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon_baldwin at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28992
[Bug c++/28774] Request for warning where const/volatile is ignored in a cast
--- Comment #2 from simon_baldwin at yahoo dot com 2006-08-24 16:53 --- You didn't miss anything. There's no bug here, just a request for a new warning message. As you note, the const-volatile qualifications in the cast have no meaning, and are completely ignored by the compiler. While it's busy ignoring them, it could note this as a warning, in case the code author really meant something different. icc warns here; this PR aims to improve agreement in warnings between g++ and icc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28774
[Bug preprocessor/23688] Compiler does not warn on selected unknown character escapes
--- Comment #3 from simon_baldwin at yahoo dot com 2006-08-18 17:51 --- Unfortunately, adding -pedantic brings in a grab-bag of other warnings that aren't currently separable. What would be useful, I think, is to have unknown escape sequences as its own -Wmumble option. That way, it's selectively available without all of the rest of -pedantic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23688
[Bug c++/28774] New: Request for warning where const/volatile is ignored in a cast
In the code fragment int i = static_castconst int(1.234); int j = static_castvolatile int(1.234); the const and volatile qualifiers in the cast are silently ignored, even with -Wall -W -pedantic. A warning from g++ for this mild infraction would be useful. -- Summary: Request for warning where const/volatile is ignored in a cast Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: simon_baldwin at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28774
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #27 from simon_baldwin at yahoo dot com 2006-05-02 21:01
---
Here's a relatively simple test case, in case anyone wants one, that reproduces
either this problem, or a very similar one. It requires a mix of compilers,
and of optimization selections, to reproduce, though. One gcc 3 compiler and
one gcc 4 one should do it.
$ cat foo.h
class Foo {
public:
virtual ~Foo() {}
virtual inline int f(int x) {
switch (x) {
case 0: return 0; break;
case 1: return 1; break;
case 2: return 2; break;// cases 0 to 2 bulk out the switch statement
case 3: return 999; break; // cases 3 and 4 can be coalesced
case 4: return 999; break;
}
return -1;
}
};
extern int g(int);
extern int h();
$ cat lib1.cc
#include foo.h
int g(int i) {
Foo f;
return f.f(i);
}
$ cat lib2.cc
#include foo.h
int h() {
Foo f;
return f.f(0) + g(0);
}
$ cat main.cc
#include foo.h
int main() {
return g(0) + h();
}
$ ./g++-3.4.5 -Wall -W -pedantic -O2 -c lib1.cc
$ ./g++-3.4.5 -Wall -W -pedantic -O0 -c lib2.cc
$ ./g++-4.1.0 -Wall -W -pedantic -o main lib1.o lib2.o main.cc
/path/to/i686-unknown-linux-gnu/bin/ld: `.gnu.linkonce.t._ZN3Foo1fEi'
referenced in section `.rodata' of lib2.o: defined in discarded section
`.gnu.linkonce.t._ZN3Foo1fEi' of lib2.o
... and so on
In this case, the ld in gcc 4.1 is version 2.16.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug c++/23689] Malformed typedef silently ignored
--- Additional Comments From simon_baldwin at yahoo dot com 2005-09-02
19:12 ---
The problem's restricted to the C++ front end only, and is common across
multiple releases and at the highest warning settings:
$ cat e.cc
typedef enum { ZERO }; // error, malformed typedef, missing identifier
typedef struct dummy {}; // ditto
$ g++-4.1 -Wall -W -pedantic -c e.cc
$ g++-4.0.1-k8 -Wall -W -pedantic -c e.cc
$ g++-3.4.1 -Wall -W -pedantic -c e.cc
$ g++-3.2.2 -Wall -W -pedantic -c e.cc
$ g++-2.95 -Wall -W -pedantic -c e.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23689
[Bug c++/23688] New: Compiler does not warn on selected unknown character escapes
Given the following short test program:
const char *s1 = \%\(\[\{; // all these are invalid escape sequences
const char *s2 = \)\]\}; // so are these
the compiler warns about the unknown escape sequences in s2 (and everything else
you can come up with), but ignores the particular sequences in s1, even though
they're just as invalid.
From section 2.13.2, paragraph 3, of the 1998 C++ Standard:
Certain nongraphic characters, the single quote ', the double quote , the
question mark ?, and the back-slash \, can be represented according to Table 5.
... If the character following a backslash is not one of those specified, the
behavior is undefined.
A warning for these four renegade unknown escapes, then, would be useful.
--
Summary: Compiler does not warn on selected unknown character
escapes
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon_baldwin at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23688
[Bug c++/23689] New: Malformed typedef silently ignored
Given the program
typedef enum { ZERO }; // error, malformed typedef, missing identifier
typedef struct dummy {}; // ditto
gcc will silently step over and apparently ignore the typedef, treating the
statement as a simple enum { ZERO }; rather than a typedef enum { ZERO }
type_name; where type_name has been accidentally omitted.
Grammatically, perhaps correct. However, a warning or error message here would
be handy.
--
Summary: Malformed typedef silently ignored
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon_baldwin at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23689
