--- 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
--- 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:
--- 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
--- 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
--- 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
--- 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
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)
--- 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
--- 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
--- 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.
--- 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
--- 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
--- 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,
--- 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
--- 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
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)
--- 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
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()
--- 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
--
--- 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
101 - 120 of 120 matches
Mail list logo
