[Bug other/47395] New: the tree code WIDEN_MULT_MINUS_EXPR has a mismatching name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47395 Summary: the tree code WIDEN_MULT_MINUS_EXPR has a mismatching name Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: adam@streamnovation.com the lowercase name has a "plus" where it should be "minus". At least I think, because it breaks my code quite well. DEFTREECODE (WIDEN_MULT_MINUS_EXPR, "widen_mult_plus_expr", tcc_expression, 3) fortunately it is trivial to correct, and doesn't cause real problems in GCC itself.
[Bug middle-end/47496] New: HAS_DECL_ASSEMBLER_NAME_P and DECL_ASSEMBLER_NAME has some incosistency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47496 Summary: HAS_DECL_ASSEMBLER_NAME_P and DECL_ASSEMBLER_NAME has some incosistency Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: adam@streamnovation.com The following code would hit gcc_unreachable if DECL_ASSEMBLER_NAME_SET_P(expr) is NULL, which seems valid if DECL_IGNORED_P is true. if (HAS_DECL_ASSEMBLER_NAME_P(expr)) return DECL_ASSEMBLER_NAME(expr); It would be more consistent if DECL_ASSEMBLER_NAME returns NULL in this special case. So DECL_ASSEMBLER_NAME should check DECL_IGNORED_P too. The other case is when the assembler name hasn't been set yet and DECL_IGNORE_P is false. It is unclear which counts as a bogus call to DECL_ASSEMBLER_NAME and which is not.
[Bug middle-end/47638] New: sanity check error message is wrong in expand_one_var
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47638
Summary: sanity check error message is wrong in expand_one_var
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: adam@streamnovation.com
in cfgexpand.c expand_one_var can give an error message like:
"error: size of variable ‘var’ is too large"
which is very wrong and misleading if DECL_SIZE(var) is actually =0
I modified the line like this:
error ("size of variable %q+D is too large, size: %i", var,
DECL_SIZE_UNIT(var));
and got:
error: size of variable ‘var’ is too large, size: 0
DECL_SIZE(var) = 0 can happen when the type layout is missing.
the fix is obvious, we need another error message for this case.
[Bug middle-end/47638] sanity check error message is wrong in expand_one_var
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47638 --- Comment #3 from Ádám Rák 2011-02-08 00:54:50 UTC --- I agree, DECL_SIZE(var) == 0 should be an ICE, with sometime like "layout error" or missing layout for variable.
[Bug bootstrap/46039] New: GCC 4.6 fails to bootstrap or compile at all with gold linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46039 Summary: GCC 4.6 fails to bootstrap or compile at all with gold linker Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: adam@streamnovation.com Created attachment 22056 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22056 preprocessed version of the conftest which hangs When GCC starts configuring the libstdc++, it runs the conftest: "checking whether a statically linked program can dlopen itself..." which hangs. I tried gcc-4.3 and gcc-4.4 and gcc-4.6 as a compiler for the conftest and all hanged when I used gold. in order to reproduce the bug: gcc -o conftest -g -O2 -Wl,--export-dynamic -static conftest.ii.c -ldl gold version: GNU gold (GNU Binutils for Debian 2.20.1-system.20100303) 1.9
[Bug c++/18635] use of uninitialised reference accepted in C++ front end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635
Ádám Rák changed:
What|Removed |Added
CC||adam.rak at streamnovation
||dot com
--- Comment #8 from Ádám Rák 2010-11-26
00:30:17 UTC ---
in g++-4.6 (and maybe all before) this bug can be even more troublesome:
struct AA
{
int &a;
AA() : a(a)
{
}
};
int main()
{
AA aa;
cout << &aa.a << endl;
return 0;
}
compiled without a warning even with
g++ main.cpp -O3 -Wall -pedantic -Wextra -Winit-self -Wuninitialized
And in -O0 it prints some address, probably the address of the reference as
suggested before. But in -O1..3 it prints a 0, which means we made an
nullreference.
The practical problem is that because of this, the code can be easily messed up
like this:
class AA
{
...int &aaa;
AA(int& ) : aaa(aaa) {...
A single typo and the compiled does really strange things, the segfault is best
case, sometimes the reference points a valid address. It is very hard to debug
too. And when the programmer checks the code he/she can naively think that the
compiler should check it, so "why bother checking whether they are spelled
exactly the same?"
The old testcase was a bit harder to do accidentally, this one can happen more
easily. A self-init warning might enough to clue the programmer if this
happens. An error would be better if we are sure this is invalid.
[Bug c++/18635] use of uninitialised reference accepted in C++ front end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18635 --- Comment #14 from Ádám Rák 2010-11-27 13:45:03 UTC --- (In reply to comment #13) > There are lots of ways to put your program into an invalid state. > > Of course there's "no point" to doing it, and noone's asking for the code to > *work* > > The question is whether the compiler is expected to diagnose the code and > reject it. If we cannot decide, we should at least give a verbose warning, included into -Wall.
