[Bug c++/23229] [4.0/4.1 Regression] g++ gives incorrect error message with void main() and a void function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04 13:02 --- Confirmed, weird. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC target triplet|i486-linux-gnu | Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-08-04 13:02:26 date|| Summary|g++ gives incorrect error |[4.0/4.1 Regression] g++ |message with void main() and|gives incorrect error |a void function |message with void main() and ||a void function Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23229
[Bug driver/21366] The -bundle linking option does not get processed right on darwin
--- Additional Comments From peter at pogma dot com 2005-08-04 12:52 --- New(ish) patch: http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00266.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21366
[Bug c/23228] Silly "unused variable" warning after redeclaration of a local variable
--- Additional Comments From gdr at integrable-solutions dot net 2005-08-04 12:20 --- Subject: Re: New: Silly "unused variable" warning after redeclaration of a local variable "steven at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | Maybe there are similar issues elsewhere, but this one happened | to bother me... This warning is also issed by GCC 3.3, so I guess | it is not a regression. But it's a silly warning after errors. Agreed. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23228
[Bug libfortran/22097] libgfortran build failure on mips-sgi-irix6.5
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-08-04 12:19 --- This happens again with fresh CVS (20050804). Still no idea? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22097
[Bug rtl-optimization/20969] unrolling does not take target register pressure into account.
--- Additional Comments From joern dot rennecke at st dot com 2005-08-04 12:13 --- Subject: Re: unrolling does not take target register pressure into account. steven at gcc dot gnu dot org wrote: > > > >Could you give some specific examples of assesments that 3.4 can do and 4.1 >can not? > > Of course, you could write special-case pattern matchers for specific loops, but there is no infrastructure to do some assessments in a general way. In particular, there is no strength reduction information available during unrolling. Increments of address givs can be saved by doing unrolling, but the unroller can't tell what they are. Forthermore, from the giv information we can find array accesses, which allow to make an informed guess of the maximum iteration count without profile information or explicit loop bounds. Look at sh.c:sh_adjust_unroll_max and try to figure out how to port all the #if 0'ed code to 4.1 . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20969
[Bug target/23102] extra XORs generated on i686
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-04 11:54 --- Try killing the peephole2 for this. Somebody elses cost-metric should force the constant into a register for the move ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23102
[Bug c++/23219] [4.1 Regression] ICE: Segmentation fault in decl_namespace_context
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-04 11:29 --- I have a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-08-03 18:32:52 |2005-08-04 11:29:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23219
[Bug c++/23229] New: g++ gives incorrect error message with void main() and a void function
g++ 4.0.1 gives incorrect error message with void function declaration &
implementation when using void main(). This can be demonstrated with the
following program:
--
void f1();
void main()
{
f1();
}
void f1()
{
}
The resulting error message is:
gccbug.cc:3: error: '::main' must return 'int'
gccbug.cc: In function 'void f1()':
gccbug.cc:8: error: new declaration 'void f1()'
gccbug.cc:1: error: ambiguates old declaration 'int f1()'
Granted, using void for return value of main() is an error, but so is the
resulting message.
The error message is correct with gcc 3.3.5 and 3.4.4 (debian prerelease).
Since "Reporting bugs" web page requested the environment,
gcc -v gives:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.1 (Debian 4.0.1-2)
system:
Linux maestro 2.6.12.1 #1 SMP Sun Jun 26 16:24:58 EEST 2005 i686 GNU/Linux
--
Summary: g++ gives incorrect error message with void main() and a
void function
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pvuorela at iki dot fi
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23229
[Bug c/23228] New: Silly "unused variable" warning after redeclaration of a local variable
Maybe there are similar issues elsewhere, but this one happened
to bother me... This warning is also issed by GCC 3.3, so I guess
it is not a regression. But it's a silly warning after errors.
=== t.c ===
int bar (void);
int foo (void)
{
int i;
int i;
i = bar ();
return 2*i;
}
===
$ gcc -Wall -Wextra -O2 t.c
t.c: In function 'foo':
t.c:5: error: redeclaration of 'i' with no linkage
t.c:4: error: previous declaration of 'i' was here
t.c:4: warning: unused variable 'i'
$
--
Summary: Silly "unused variable" warning after redeclaration of a
local variable
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,jsm28 at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23228
[Bug libstdc++/15910] can't compile self defined void distance(std::vector, std::vector)
--- Additional Comments From gdr at integrable-solutions dot net 2005-08-04 10:13 --- Subject: Re: can't compile self defined void distance(std::vector, std::vector) "adah at netstd dot com" <[EMAIL PROTECTED]> writes: | 1) This bug is not in libstdc++, but in the C++ compiler. yes and no. [...] | 3) To complicate the matter, all "good" compilers I know fail in this case. | However, I still believe it is the problem of the compilers. Please take ti to the C++ standard committee. The behaviour is that described by the standard. If you don't like it, have the committee change it. If you think name lookup is an easy exercise, give it a try. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15910
[Bug c++/23213] Error in Koenig Lookup causes overload resolution failure
--- Additional Comments From gdr at integrable-solutions dot net 2005-08-04 10:02 --- Subject: Re: New: Error in Koenig Lookup causes overload resolution failure "adah at netstd dot com" <[EMAIL PROTECTED]> writes: | http://groups-beta.google.com/group/comp.lang.c++.moderated/browse_thread/thread/3c449572456c8592 [...] | not quite clear on this). But I do not think it the purpose of the standard to | let something in the std namespace affect local name resolution. Maybe you | gurus here can judge better? Whether you like it or not, you have to take it to the C++ committee. It is not GCC's job to "fix" C++ standard semantics you would not like. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23213
[Bug target/19300] [4.0 Regression] PCH failures on sparc-linux
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-08-04 10:01 --- > This is the currently, 2005-08-03, latest test results I have for 3.4: > > http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00196.html > > and the gcc PCH tests that FAIL are for -m64: > > FAIL: gcc.dg/pch/static-1.c -O0 -g assembly comparison > FAIL: gcc.dg/pch/static-1.c -O0 assembly comparison > FAIL: gcc.dg/pch/static-1.c -O1 assembly comparison > FAIL: gcc.dg/pch/static-2.c -O0 -g assembly comparison > FAIL: gcc.dg/pch/static-2.c -O0 assembly comparison > FAIL: gcc.dg/pch/static-2.c -O1 assembly comparison > FAIL: gcc.dg/pch/static-3.c -O0 -g assembly comparison > FAIL: gcc.dg/pch/static-3.c -O0 assembly comparison > FAIL: gcc.dg/pch/static-3.c -O1 assembly comparison > > and from the log file, for example: > > Executing on host: /usr/local/src/branch/objdir.3.4/gcc/xgcc > -B/usr/local/src/branch/objdir.3.4/gcc/ > /usr/local/src/branch/gcc.3.4/gcc/testsuite/gcc.dg/pch/static-1.c -O0 -g -I. > -S > -m64 -o static-1.s(timeout = 600) > PASS: gcc.dg/pch/static-1.c -O0 -g (test for excess errors) > line #48 > < !#PROLOGUE# 0 > > .register %g2, #scratch > line #49 > < save%sp, -192, %sp > > .register %g3, #scratch > line #50 That's a PR of you too. A backport of 2005-04-15 David S. Miller <[EMAIL PROTECTED]> PR target/20673 * config/sparc/sparc.h (sparc_hard_reg_printed): Mark as GTY(()). is pre-approved, assuming the release manager is OK with it. -- What|Removed |Added BugsThisDependsOn||20673 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19300
[Bug rtl-optimization/15023] -frename-registers is buggy and slow
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-04 09:51 --- The liveness analysis in df.c misses the registers marked in flow.c:mark_regs_live_at_end, so that'd have to be fixed first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15023
[Bug target/19300] [4.0 Regression] PCH failures on sparc-linux
--- Additional Comments From christian dot joensson at gmail dot com 2005-08-04 09:46 --- (In reply to comment #24) > Also fixed in 3.4.5. This is the currently, 2005-08-03, latest test results I have for 3.4: http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00196.html and the gcc PCH tests that FAIL are for -m64: FAIL: gcc.dg/pch/static-1.c -O0 -g assembly comparison FAIL: gcc.dg/pch/static-1.c -O0 assembly comparison FAIL: gcc.dg/pch/static-1.c -O1 assembly comparison FAIL: gcc.dg/pch/static-2.c -O0 -g assembly comparison FAIL: gcc.dg/pch/static-2.c -O0 assembly comparison FAIL: gcc.dg/pch/static-2.c -O1 assembly comparison FAIL: gcc.dg/pch/static-3.c -O0 -g assembly comparison FAIL: gcc.dg/pch/static-3.c -O0 assembly comparison FAIL: gcc.dg/pch/static-3.c -O1 assembly comparison and from the log file, for example: Executing on host: /usr/local/src/branch/objdir.3.4/gcc/xgcc -B/usr/local/src/branch/objdir.3.4/gcc/ /usr/local/src/branch/gcc.3.4/gcc/testsuite/gcc.dg/pch/static-1.c -O0 -g -I. -S -m64 -o static-1.s(timeout = 600) PASS: gcc.dg/pch/static-1.c -O0 -g (test for excess errors) line #48 < !#PROLOGUE# 0 > .register %g2, #scratch line #49 < save%sp, -192, %sp > .register %g3, #scratch line #50 < .LLCFI1: > !#PROLOGUE# 0 line #51 < !#PROLOGUE# 1 > save%sp, -192, %sp line #52 < .loc 2 5 0 > .LLCFI1: line #53 < sethi %hi(counter.1), %g1 > !#PROLOGUE# 1 line #54 < or %g1, %lo(counter.1), %g1 > .loc 2 5 0 line #55 < mov %g1, %g2 > sethi %hi(counter.1), %g1 line #56 < ld [%g2], %g1 > or %g1, %lo(counter.1), %g1 line #57 < mov %g1, %g3 > mov %g1, %g2 line #58 < add %g1, 1, %g1 > ld [%g2], %g1 line #59 < st %g1, [%g2] > mov %g1, %g3 line #60 < sra %g3, 0, %g1 > add %g1, 1, %g1 line #61 < .loc 2 6 0 > st %g1, [%g2] line #62 < mov %g1, %i0 > sra %g3, 0, %g1 line #63 < return %i7+8 > .loc 2 6 0 line #64 < nop > mov %g1, %i0 line #65 < .LLFE3: > return %i7+8 line #66 < .size bar, .-bar > nop line #67 < .section".debug_frame" > .LLFE3: line #68 < .LLframe0: > .size bar, .-bar line #69 < .uaword .LLECIE0-.LLSCIE0 > .section".debug_frame" line #70 < .LLSCIE0: > .LLframe0: line #71 < .uaword 0x > .uaword .LLECIE0-.LLSCIE0 line #72 < .byte 0x1 > .LLSCIE0: line #73 < .asciz "" > .uaword 0x line #74 < .uleb128 0x1 > .byte 0x1 line #75 < .sleb128 -8 > .asciz "" line #76 < .byte 0xf > .uleb128 0x1 line #77 < .byte 0xc > .sleb128 -8 line #78 < .uleb128 0xe > .byte 0xf line #79 < .uleb128 0x7ff > .byte 0xc line #80 < .align 8 > .uleb128 0xe line #81 < .LLECIE0: > .uleb128 0x7ff line #82 < .LLSFDE0: > .align 8 line #83 < .uaword .LLEFDE0-.LLASFDE0 > .LLECIE0: line #84 < .LLASFDE0: > .LLSFDE0: line #85 < .uaword .LLframe0 > .uaword .LLEFDE0-.LLASFDE0 line #86 < .uaxword.LLFB2 > .LLASFDE0: line #87 < .uaxword.LLFE2-.LLFB2 > .uaword .LLframe0 line #88 < .byte 0x4 > .uaxword.LLFB2 line #89 < .uaword .LLCFI0-.LLFB2 > .uaxword.LLFE2-.LLFB2 line #90 < .byte 0xd > .byte 0x4 line #91 < .uleb128 0x1e > .uaword .LLCFI0-.LLFB2 line #92 < .byte 0x2d > .byte 0xd line #93 < .byte 0x9 > .uleb128 0x1e line #94 < .uleb128 0xf > .byte 0x2d line #95 < .uleb128 0x1f > .byte 0x9 line #96 < .align 8 > .uleb128 0xf line #97 < .LLEFDE0: > .uleb128 0x1f line #98 < .LLSFDE2: > .align 8 line #99 < .uaword .LLEFDE2-.LLASFDE2 > .LLEFDE0: line #100 < .LLASFDE2: > .LLSFDE2: line #101 < .uaword .LLframe0 > .uaword .LLEFDE2-.LLASFDE2 line #102 < .uaxword.LLFB3 > .LLASFDE2: line #103 < .uaxword.LLFE3-.LLFB3 > .uaword .LLframe0 line #104 < .byte 0x4 > .uaxword.LLFB3 line #105 < .uaword .LLCFI1-.LLFB3 > .uaxword.LLFE3-.LLFB3 line #106 < .byte 0xd > .byte 0x4 line #107 < .uleb128 0x1e > .uaword .LLCFI1-.LLFB3 line #108 < .byte 0x2d > .byte 0xd line #109 < .byte 0x9 > .uleb128 0x1e line #110 < .uleb128 0xf > .byte 0x2d line #111 < .uleb128 0x1f > .byte 0x9 line #112 < .align 8 > .uleb128 0xf line #113 < .LLEFDE2: > .uleb128 0x1f line #114 < .section".text" > .align 8 line #115 < .LLetext0: > .LLEFDE2: line #116 < .section".debug_info" > .section".text" line #117 < .uaword 0x12c > .LL
[Bug c++/23227] New: SFINAE bug
The following code refuses to compile :
struct C;
template < typename T >
struct B;
template < typename T >
struct A;
void f(const C &c);// this one is fine
void f(const B &a); // this one is fine
void f(const A &a); // this one triggers the bug
void f(double) {}
template < typename T >
struct A
{
B b;
};
int main()
{
f(1.0); // => instantiates A => instantiates B => fails.
}
---
The error message is :
instance.C: In instantiation of 'A':
instance.C:23: instantiated from here
instance.C:17: error: 'A::b' has incomplete type
instance.C:4: error: declaration of 'struct B'
I am not 100% sure it is a SFINAE bug, but it looks like one to me.
Note that if you comment the declaration of f(A), then it works.
Similarly if you comment the definition of A.
So the problem here is probably that if the definition of A is
available, then the compiler instantiates it, which triggers the
instantiation of B, which fails, but the compiler does not
recover from this instantiation as it should (following SFINAE).
There is the same problem with g++ 3.3, 3.4 and 4.0.1.
--
Summary: SFINAE bug
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sylvain dot pion at sophia dot inria dot fr
CC: gcc-bugs at gcc dot gnu dot org,sylvain dot pion at
sophia dot inria dot fr
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23227
[Bug c/23155] [4.0/4.1 Regression] Gimplification failed for union cast
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-04
09:20 ---
It's an lvalue-cast, which we no longer support as an extension. So it's ICE on
invalid and a frontend bug. The C++ frontend spits out the interesting error
pr23155.c: In function void foo5(int):
pr23155.c:7: error: no matching function for call to vx::vx(int&)
pr23155.c:1: note: candidates are: vx::vx()
pr23155.c:1: note: vx::vx(const vx&)
The following get's rejected with what should be done with the original
testcase, too:
union vx {short f[8]; int v;};
int vec;
void bar(short *);
void
foo5 (int vec)
{
bar(((union vx) vec).f);
}
pr23155.c: In function foo5:
pr23155.c:10: error: invalid use of non-lvalue array
--
What|Removed |Added
Component|middle-end |c
Keywords|ice-on-valid-code |accepts-invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23155
[Bug rtl-optimization/15023] -frename-registers is buggy and slow
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-08-04 09:04 --- I'd like to mention a known problem with -frename-registers. Quoting my analysis for another bug report: "However the underlying problem is still present and is now visible on x86-64: the register renaming pass (regrename.c) uses its own life analysis engine to compute the def-use chains. It turns out that it is less accurate than the all-purpose life analysis engine (flow.c) and, consequently, when the latter is invoked to update the global liveness info at the end of the pass, it may flag internal inconsistencies introduced because of the former. It is not immediately obvious what the best approach to solving that would be. A third life analysis engine exists (df.c) and is supposed to be modular, so we could try to plug it into regrename.c." The typical example is PR rtl-optimization/16586. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org BugsThisDependsOn||16586 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15023
[Bug c/23226] Nested function do not work on 32 bit build
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-08-04 08:07 --- This program works for me in both 32 and 64 bit mode. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23226
