[Bug middle-end/42794] PRE produces illegal PHI node
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-18 23:57 --- But really, test up to date 4.4 branch or mainline. Thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42794
[Bug bootstrap/42785] error: impossible constraint in 'asm'
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-01-19 00:10 --- driver-i386.c should not be included if you are compiling for a PPC host/build really. So it is a problem of you misconfiguring GCC really and nothing else. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42785
[Bug c/42787] Failed to make all-target
--- Comment #5 from monaka at monami-software dot com 2010-01-19 00:11 --- There are no GTY tags in t-h8300.h and t-m32r.h. Is this an indirect cause? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42787
[Bug bootstrap/42785] error: impossible constraint in 'asm'
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-01-19 00:13 --- More to the point, use lipo to combine the gcc drivers after the fact to get a dual arch executable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42785
[Bug fortran/42353] [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2010-01-19 00:25 --- Obviously we do not have the original test case added to the testsuite so we can catch these things. I added gfcbug96d.f90 to the testsuite, thinking it was the same issue as gfcbug96.f90. Lets just reopen this PR, noting that the various cases listed have differing issues and that we need to add test cases for each in the test suite. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
[Bug middle-end/42169] [4.4/4.5 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
--- Comment #2 from danglin at gcc dot gnu dot org 2010-01-19 01:01 --- Still present in revision 155956. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
[Bug c/42795] New: false statement has no effect message
I apologize for not knowing much about GCC bug filing, like the triplet info
requested above. I am using a GCC 4.3.4 with the following configuration:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.4/./configure --prefix=/usr
Thread model: posix
gcc version 4.3.4 (GCC)
It's compiled on a Mandriva 2007.0 Linux system with glibc-2.4-7 from Mandriva.
The compiler flags used in compiling this were -O3 -funroll-loops.
The following statement has the purpose of scanning some array elements until
the condition isn't met, and then the variable i has the info I want. So this
is not a statement with no effect because it's found something. Below the
statement are two console lines showing GCC's error message.
if ((i prunecap) (deep 1)) /* Trim lemons early */
{ /* remove with slope test, saving at least prunecap */
for (i; (((max - Tree[i].score) i) (i = margin)); i--);
}
gnuchess.c: In function âBackPruneâ:
gnuchess.c:1021: warning: statement with no effect
Thought you'd like to know.
--
Summary: false statement has no effect message
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jrt at worldlinc dot net
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: I586-Mandriva-Linux?
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42795
[Bug c/42795] false statement has no effect message
--- Comment #1 from jrt at worldlinc dot net 2010-01-19 01:22 --- I used inaccurate phrasing. I should have said that The compiler flags used in compiling THE FOLLOWING were -O3 -funroll-loops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42795
[Bug c/42795] false statement has no effect message
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-01-19 02:14 --- gnuchess.c:1021: warning: statement with no effect This warning is correct as: i; has no effect. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42795
[Bug fortran/42353] [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...
--- Comment #23 from jvdelisle at gcc dot gnu dot org 2010-01-19 02:37 --- Janus, reassigning to myself. I think I see a problem in the error checking logic and I have a tentative patch that has regression tested fine. I want to think a bit about whether I an fixing this correctly. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|janus at gcc dot gnu dot org|jvdelisle at gcc dot gnu dot ||org Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
[Bug bootstrap/42785] error: impossible constraint in 'asm'
--- Comment #5 from monaka at monami-software dot com 2010-01-19 02:42 --- (In reply to comment #3) driver-i386.c should not be included if you are compiling for a PPC host/build really. So it is a problem of you misconfiguring GCC really and nothing else. I see what you want to say, but. The another viewpoint: In i386-driver.c, there is decided by #ifdef __GNUC__ which host_detect_local_cpu (dummy or not) is used In i386.h, there is decided by #if defined(__i386__) || defined(__x86_64__) if it defines EXTRA_SPEC_FUNCTIONS . They are inconsistent, right? P.S. Thanks for your information about lipo. I know about it and I've already released binary distributions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42785
[Bug bootstrap/42785] error: impossible constraint in 'asm'
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-01-19 02:45 --- They are inconsistent, right? No because i386-driver.c is only supposed to be compiled with a x86 or x86_64 compiler. Really the file could have #if !defined(__i386__) !defined(__x86_64__) #error This should only be compiled with an x86 compiler #endif And still be correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42785
[Bug c/42795] false statement has no effect message
--- Comment #3 from jrt at worldlinc dot net 2010-01-19 02:58 --- So setting a variable as the coder desires is no effect? Some would disagree. A statement that really would not have an effect would be: if (theworldis notenough); The comparison indicated here perhaps is performed, but there is no result to subsequently use, no variable changed. What I reported is not the genuine no effect condition I just described here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42795
[Bug c/42795] false statement has no effect message
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-01-19 03:01 ---
(In reply to comment #3)
So setting a variable as the coder desires is no effect? Some would disagree.
A statement that really would not have an effect would be:
if (theworldis notenough);
No that is not is being warned about. The statement that is being warned about
is just i; which is the same inside a for statement as it is outside one.
Both are statements have no effect as it does nothing.
Take:
void f(int i)
{
i;
}
Do you think that should be warned about? That is the exact same thing which
is being warned about when you have:
void f(int i)
{
for(i; ; )
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42795
[Bug c/42795] false statement has no effect message
--- Comment #5 from jrt at worldlinc dot net 2010-01-19 03:15 --- Ahhh, i see. It appears that i is not assigned at the start of the loop. I assigned it just before the loop, so the loop starts at the correct value. I tried doing the assignment with an otherwise useless variable, don't recall what messages resulted in that try. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42795
[Bug c/42796] New: ICE on building libstdc++-v3
libstdc++-v3/config.log is: configure: In function 'void foo()': configure:14896:1: error: in basic block 2: configure:14896:1: error: flow control insn inside a basic block (jump_insn 36 35 37 2 (parallel [ (set (pc) (if_then_else (ne:HI (reg:HI 2 r2) (const_int 0 [0x0])) (label_ref 40) (pc))) (clobber (reg:BI 16 carry)) ]) -1 (nil) - 40) configure:14896:1: internal compiler error: in rtl_verify_flow_info_1, at cfgrtl.c:2013 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: ICE on building libstdc++-v3 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: monaka at monami-software dot com GCC build triplet: i386-apple-darwin10.2.0 GCC host triplet: i386-apple-darwin10.2.0 GCC target triplet: xstormy16-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42796
[Bug lto/42762] ICE in get_resolution() when compiling a C++ program with -flto -fuse-linker-plugin
--- Comment #1 from espindola at gcc dot gnu dot org 2010-01-19 04:45 --- The problem is coming from DECL_FUNCTION_PERSONALITY (expr) = lto_input_tree (ib, data_in); This reads in __gxx_personality_v0 as an external function and we try to add it to the symbol table. If using the linker plugin this fails because there is no reference to __gxx_personality_v0 in the symbol table. Two options: * There should be an undefined reference and we are missing it in produce_symtab * There should not be an undefined reference. In this case maybe DECL_FUNCTION_PERSONALY should not be set or we should be ignoring it in this case for some reason I don't think there should be an undefined reference to the personality in this test. The produced assembly never mentions a personality function... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42762
[Bug c++/42797] New: call of overloaded 'allocator()' is ambiguous
On Linux x86_64
g++ --version:
g++ (Debian 20100117-1) 4.5.0 20100117 (experimental) [trunk revision 155979]
Compiling with:
g++ -O2 -g -std=c++0x -c test.cpp
The following program:
#include vector
#include map
struct Foo {
Foo() {}
templatetypename Tp
Foo(Tp *p) {}
};
void foo() {
std::map int, std::vectorFoo the_map;
the_map[1] = std::vectorFoo();
}
Produces the below error. However, it *doesn't* produce an error if compiled
without the -g switch (nor with -O1 instead of -O2).
In file included from /usr/include/c++/4.5.0/bits/move.h:38:0,
from /usr/include/c++/4.5.0/bits/stl_pair.h:60,
from /usr/include/c++/4.5.0/bits/stl_algobase.h:66,
from /usr/include/c++/4.5.0/vector:61,
from test.cpp:1:
/usr/include/c++/4.5.0/type_traits: In constructor 'std::vector_Tp,
_Alloc::vector(std::vector::size_type, const value_type, const
allocator_type) [with _Tp = Foo, _Alloc = std::allocatorFoo,
std::vector::size_type = long unsigned int, value_type = Foo, allocator_type =
std::allocatorFoo]':
/usr/include/c++/4.5.0/type_traits:224:67: instantiated from 'const bool
std::__is_constructible_helperstd::vectorFoo, const int::__value'
/usr/include/c++/4.5.0/type_traits:235:5: instantiated from
'std::is_constructiblestd::vectorFoo, const int'
/usr/include/c++/4.5.0/bits/stl_map.h:451:11: instantiated from here
/usr/include/c++/4.5.0/type_traits:224:67: error: call of overloaded
'allocator()' is ambiguous
/usr/include/c++/4.5.0/bits/allocator.h:103:7: note: candidates are:
std::allocator_Tp::allocator(const std::allocator_Tp) [with _Tp = Foo,
std::allocator_Tp = std::allocatorFoo]
/usr/include/c++/4.5.0/bits/allocator.h:101:7: note:
std::allocator_Tp::allocator() [with _Tp = Foo]
/usr/include/c++/4.5.0/type_traits:224:67: error: call of overloaded
'allocator()' is ambiguous
/usr/include/c++/4.5.0/bits/allocator.h:103:7: note: candidates are:
std::allocator_Tp::allocator(const std::allocator_Tp) [with _Tp = Foo,
std::allocator_Tp = std::allocatorFoo]
/usr/include/c++/4.5.0/bits/allocator.h:101:7: note:
std::allocator_Tp::allocator() [with _Tp = Foo]
/usr/include/c++/4.5.0/type_traits:218:2: error: call of overloaded
'allocator()' is ambiguous
/usr/include/c++/4.5.0/bits/allocator.h:103:7: note: candidates are:
std::allocator_Tp::allocator(const std::allocator_Tp) [with _Tp = Foo,
std::allocator_Tp = std::allocatorFoo]
/usr/include/c++/4.5.0/bits/allocator.h:101:7: note:
std::allocator_Tp::allocator() [with _Tp = Foo]
--
Summary: call of overloaded 'allocator()' is ambiguous
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: foom at fuhm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42797
[Bug fortran/42772] [4.5 Regression] ICE at fold-const.c:10033
--- Comment #6 from pault at gcc dot gnu dot org 2010-01-19 06:04 --- Ah, I was being stupid; now I see what test case 2 actually is. duuh, I did not think to go to comment #10! My patch that was just posted does indeed fix this, so I'll take it on. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-01-16 22:16:01 |2010-01-19 06:04:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42772
[Bug c++/42797] call of overloaded 'allocator()' is ambiguous
--- Comment #1 from foom at fuhm dot net 2010-01-19 06:15 --- Error also occurs with: g++ -O1 -fipa-sra -g -std=c++0x -c test.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42797
