--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-07-07 06:22
---
We have addressed this in previous bug reports. Any unit can be accessed as
formatted or unformatted if one chooses to do so, this is why we answer yes.
In other words, it is allowed
This should not be
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-07-07 07:32
---
Subject: Bug 32232
Author: mmitchel
Date: Sat Jul 7 07:31:54 2007
New Revision: 126435
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126435
Log:
PR c++/32232
* pt.c
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-07-07 07:36
---
Fixed in 4.3.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Hello,
there seems to be a problem compiling the attached source file with sh-elf-gcc:
/home/mstein/sim/sh-elf/build/./gcc/xgcc -B/home/mstein/sim/sh-elf/build/./gcc/
-nostdinc -B/home/mstein/sim/sh-elf/build/sh-elf/newlib/ -isystem
/home/mstein/sim/sh-elf/build/sh-elf/newlib/targ-include
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-07-07 07:46
---
Created an attachment (id=13862)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13862action=view)
preprocessed source file from gcc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32664
--- Comment #1 from ubizjak at gmail dot com 2007-07-07 08:22 ---
This is fixed in gcc-4.3:
_Z3fooPyPKyy:
movq%rdx, %rax
mulq(%rsi)
movq%rdx, (%rdi)
ret
_Z3fooPyPKyyy:
andq(%rsi), %rcx
movq%rcx, %rax
mulq
--- Comment #2 from ubizjak at gmail dot com 2007-07-07 08:23 ---
Compiles OK in 4.3.0.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Known to work|
--- Comment #3 from uros at gcc dot gnu dot org 2007-07-07 09:23 ---
Subject: Bug 32660
Author: uros
Date: Sat Jul 7 09:23:04 2007
New Revision: 126438
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126438
Log:
PR target/32660
Backport from mainline.
*
--- Comment #4 from ubizjak at gmail dot com 2007-07-07 09:24 ---
Confirmed, still regression on 4.2 branch.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2007-07-07 09:25 ---
Confirmed, not a regression.
--
ubizjak at gmail dot com changed:
What|Removed |Added
While experimenting with testcases from PR31320, I hit this:
$ cat alloc.f90
TYPE :: x
INTEGER, ALLOCATABLE :: a(:)
END TYPE
TYPE(x) :: a
a = x((/ 1, 2, 3 /))
a = x((/ a%a, 4 /))
end
$ gfortran-svn -g -Wall -fdump-tree-original allocatable.f90 ./a.out
Segmentation fault
$ valgrind
--- Comment #2 from kkojima at gcc dot gnu dot org 2007-07-07 10:42 ---
This is same on sh4-unknown-linux-gnu. A reduced testcase
long long
foo (long long u)
{
return u;
}
fails on sh4 with -fnon-call-exceptions.
It looks that it started to fail after the patch
r126403 | uros |
--- Comment #10 from reichelt at gcc dot gnu dot org 2007-07-07 10:43
---
This fix ported PR 31780 back to the 4.2 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31338
--- Comment #3 from reichelt at gcc dot gnu dot org 2007-07-07 10:47
---
The ICE is now also present on the 4.2 branch.
Most likely caused by the patch for PR 31338.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from reichelt at gcc dot gnu dot org 2007-07-07 10:59
---
Mark, is there any reason, you added the exectuable flag?
If not, would you mind removing it?
Propchange: trunk/gcc/testsuite/g++.dg/init/new20.C
('svn:executable' added)
--
reichelt at gcc dot
--- Comment #13 from reichelt at gcc dot gnu dot org 2007-07-07 11:07
---
The testcase indeed doesn't crash on mainline (i686-pc-linux-gnu) anymore.
It still crashes on the 4.2 branch, though.
Given that the testcase disappeared and reappeared on mainline the problem
might
still be
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-07 13:27 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-07 13:32 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor
--- Comment #8 from srm at schokokeks dot org 2007-07-07 13:37 ---
crystalspace also has a bug report for this
(http://www.crystalspace3d.org/trac/CS/ticket/210)
as mentioned there, one could try this
http://www.crystalspace3d.org/trac/CS/ticket/258 which is using a special
branch for
--- Comment #1 from hjl at lucon dot org 2007-07-07 14:31 ---
Revision 126198 is good and revision 126338 is bad.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32663
--- Comment #2 from hjl at lucon dot org 2007-07-07 14:47 ---
Revision 126286 is good.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32663
--- Comment #3 from scovich at gmail dot com 2007-07-07 14:55 ---
While it's nice that the new optimization framework can eliminate the redundant
IMUL instruction(s), why were they being generated in the first place?
Compiling the simpler foo() without optimizations gives:
--- Comment #3 from danglin at gcc dot gnu dot org 2007-07-07 15:09 ---
I don't know. I haven't been able to bootstrap hppa64-hp-hpux11.11 since
the dataflow merge. The following two tests are failing on
hppa2.0w-hp-hpux11.11 (revision 126397):
FAIL:
--- Comment #3 from hjl at lucon dot org 2007-07-07 15:14 ---
Revision 126328 is good.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32663
--- Comment #4 from hp at gcc dot gnu dot org 2007-07-07 15:17 ---
In reply to comment #4: confirmed. I've now confirmed that it is commit 126198
that exposed this bug, so I'll remove all other people from CC. You're very
welcome to add yourself back, of course. :) Richi, if you can
--- Comment #5 from rguenther at suse dot de 2007-07-07 15:24 ---
Subject: Re: [4.3 regression] 25_algorithms/search_n/iterator.cc:
pch-related verify_ssa failure
On Sat, 7 Jul 2007, hp at gcc dot gnu dot org wrote:
--- Comment #4 from hp at gcc dot gnu dot org 2007-07-07
--- Comment #4 from hjl at lucon dot org 2007-07-07 15:35 ---
I verified that this patch:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00323.html
causes this regression. It only happens for 32bit target.
--
hjl at lucon dot org changed:
What|Removed
--- Comment #6 from hp at gcc dot gnu dot org 2007-07-07 15:44 ---
Failing pass:
#4 0x00738bbf in execute_one_pass (pass=0xca6280) at
/home/hp/regress126198/gcc/gcc/passes.c:1147
(gdb) p *pass
$1 = {name = 0xafff81 store_copyprop, gate = 0x848c70 gate_store_copy_prop,
execute
abi_check is failing on hppa-unknown-linux-gnu with Debian lenny (libc6
2.5-9):
=== libstdc++-v3 check-abi Summary ===
# of added symbols: 74
# of missing symbols:22
# of incompatible symbols: 23
using: baseline_symbols.txt
FAIL: abi_check
I've
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-07
15:55 ---
Subject: Re: New: FAIL: abi_check
I've seen this with 4.2.1 and 4.3.0.
Attached is the output log (probably somewhat out of order).
Dave
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot
--- Comment #7 from hp at gcc dot gnu dot org 2007-07-07 15:56 ---
Created an attachment (id=13864)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13864action=view)
one of the dumps generated with -fdump-tree-store_copyprop-vops-blocks
-fdump-tree-store_ccp-vops-blocks
--
--- Comment #8 from hp at gcc dot gnu dot org 2007-07-07 15:57 ---
Created an attachment (id=13865)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13865action=view)
the other dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
--- Comment #9 from hp at gcc dot gnu dot org 2007-07-07 16:00 ---
Using the patch in comment #5 applied on 126197 causes the same failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
--- Comment #4 from rask at sygehus dot dk 2007-07-07 16:08 ---
In reply to comment #1:
If you're splitting a multiword subreg (such as %rbx:%rcx) after reload, then
the prologue/epilogue code has no way of knowing that all use of %rbx is later
optimized away. I don't know if this is
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-07-07 16:13
---
So the bogus replacement happens in store_copyprop (function
_ZSt10__search_nIN10__gnu_test24forward_iterator_wrapperIiEEiiET_S3_S3_T0_RKT1_St20forward_iterator_tag)
for a (yet) mysterious reason it replaces in
--- Comment #11 from hp at gcc dot gnu dot org 2007-07-07 16:15 ---
Created an attachment (id=13866)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13866action=view)
dump with -fdump-tree-store_copyprop-vops-blocks-details
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-07-07 16:35
---
I will have a look
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rob1weld at aol dot com 2007-07-07 16:41 ---
A bug report has been filed with 'hal'.
What had happened was that CIL had optimized away, in some cases, and created
incorrect code in other cases; based on what it read of the GCC 4.3 sources. It
then fed the C2C back
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-07-07 16:48
---
This is a regression against 4.2. It looks like its not making it through the
parser. Hmm.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from hjl at lucon dot org 2007-07-07 16:54 ---
Before the change, PRE generates:
# prephitmp.165_1394 = PHI storetmp.156_472(127), storetmp.156_452(130)
# prephitmp.165_1395 = PHI storetmp.156_1216(127), storetmp.156_466(130)
# nlast_26 = PHI 0(127), nlast_442(130)
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-07 17:02 ---
Related to (or a dup of) PR 31926.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-07-07 17:04
---
So the problem is that we detect
PHI node __i$D47460$SharedInfo_92 copy-of chain: __i$D47460$SharedInfo_92 -
__i$D47460$SharedInfo_40 - SR.1030_31 - SR.1030_31 [COPY]
but later replace with
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-07-07 17:23
---
The following creates a similar copy chain, but still chooses the right one to
copy from.
struct Foo {
int x;
};
void use(int);
void foo(struct Foo *p, int q)
{
int a = p-x;
int b, c;
p-x = a;
if
--- Comment #5 from rask at sygehus dot dk 2007-07-07 17:26 ---
s/multiword subreg/multiword hard reg/g and s/comment #2/comment #3/g in
comment #4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32662
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|pch |tree-optimization
Target Milestone|---
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
|
This code generates a warning when run with valgrind:
#include vector
using namespace ::std;
struct X {
double values[10];
};
int main()
{
vectorX x;
x.push_back(X());
for (vectorX::iterator i=x.begin();i!=x.end();++i) {
*i = *(x.end()-1);
}
return 0;
}
g++ test.cpp -o foo
--- Comment #10 from rob1weld at aol dot com 2007-07-07 18:05 ---
I compiled the program I was working on using GCC 4.2 that was configured using
the option --enable-concept-checks and one file would not compile; giving
this error:
/usr/include/c++/4.2/bits/boost_concept_check.h: In
--- Comment #1 from pcarlini at suse dot de 2007-07-07 18:19 ---
Interesting: mainline is not affected by the problem. I would guess thanks to
fixing libstdc++/29286 ???
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-07-07 18:19
---
I have confirmed that this problem occurred after the iso_c_binding merge and
is not part of the initial merge itself. That narrows it down quite a bit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32644
--- Comment #1 from patchapp at dberlin dot org 2007-07-07 18:25 ---
Subject: Bug number PR29876
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00645.html
--
--- Comment #11 from pcarlini at suse dot de 2007-07-07 18:27 ---
One comment, to avoid wasting time (I don't have the time to understand why the
old library-simulation of concept checks is discussed in a C++ PR): for sure we
are not going to enable by default the simulated concept
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-07-07 19:07 ---
Salvatore, could you please recheck this one? I can not observe any problems,
neither on dt_bnd.f90 nor on the reduced testcase.
$ gfortran-svn -g -fbounds-check dt_bnd.f90 ./a.out
[snipped output]
$ valgrind
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-07-07 19:16
---
Subject: Bug 32232
Author: mmitchel
Date: Sat Jul 7 19:16:09 2007
New Revision: 126443
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126443
Log:
PR c++/32232
* pt.c
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-07-07 19:16
---
Fixed in 4.2.1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from mark at codesourcery dot com 2007-07-07 19:18 ---
Subject: Re: [4.1/4.2/4.3 regression] ICE with invalid use
of new
reichelt at gcc dot gnu dot org wrote:
--- Comment #10 from reichelt at gcc dot gnu dot org 2007-07-07 10:59
---
Mark, is there any
--- Comment #1 from ghazi at gcc dot gnu dot org 2007-07-07 19:26 ---
Here's a testcase:
int foo1 (float fp)
{
return __builtin_isnan (fp);
}
int foo2 (float fp)
{
return __builtin_isnan ((double)fp);
}
int foo3 (double fp)
{
return __builtin_isnan (fp);
}
int foo4 (long
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-07-07 19:26
---
The ICE is occurring in the gimplifier; it appears not to handle expressions
with type error_mark_node. Either we should not gimplify anything after an
error occurs, or it must be made more robust.
I'm thinking
The type-generic builtins apply the default variadic promotions to their
arguments before handing them off to the middle-end for processing. This is
bad because e.g. __builtin_isnan(f), where f is a float, gets turned into
__builtin_isnan((double)f).
In most cases, the cast to double merely
--- Comment #6 from aesok at gcc dot gnu dot org 2007-07-07 19:30 ---
Subject: Bug 31331
Author: aesok
Date: Sat Jul 7 19:30:37 2007
New Revision: 126446
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126446
Log:
PR target/31331
* config/avr/avr.c
--- Comment #6 from hjl at lucon dot org 2007-07-07 19:35 ---
If I revert
- if (lhsval)
+ if (lhsval vuse_equiv (lhsval, stmt))
the regression is gone. I suspected that the original code:
if (lhsval)
{
set_value_handle (newt,
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-07-07 19:35
---
I do think that the error is bogus.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
--- Comment #7 from aesok at gcc dot gnu dot org 2007-07-07 19:37 ---
Fixed.
--
aesok at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from aesok at gcc dot gnu dot org 2007-07-07 19:39 ---
Subject: Bug 31331
Author: aesok
Date: Sat Jul 7 19:39:36 2007
New Revision: 126447
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126447
Log:
PR target/31331
* config/avr/avr.c
--- Comment #7 from dberlin at gcc dot gnu dot org 2007-07-07 20:07 ---
Subject: Re: [4.3 regression]: revision 126369 went into an infinite loop
On 7 Jul 2007 19:35:01 -, hjl at lucon dot org
[EMAIL PROTECTED] wrote:
--- Comment #6 from hjl at lucon dot org 2007-07-07
--- Comment #8 from hjl at lucon dot org 2007-07-07 20:08 ---
I am testing this patch:
--- gcc/tree-ssa-pre.c.bad 2007-07-07 08:18:31.0 -0700
+++ gcc/tree-ssa-pre.c 2007-07-07 12:48:47.0 -0700
@@ -3362,7 +3362,8 @@ make_values_for_stmt (tree stmt, basic_b
--- Comment #9 from dberlin at gcc dot gnu dot org 2007-07-07 20:09 ---
(In reply to comment #8)
I am testing this patch:
--- gcc/tree-ssa-pre.c.bad 2007-07-07 08:18:31.0 -0700
+++ gcc/tree-ssa-pre.c 2007-07-07 12:48:47.0 -0700
@@ -3362,7 +3362,8 @@
--- Comment #7 from danglin at gcc dot gnu dot org 2007-07-07 20:30 ---
There is some dependency on the pointer plus merge. After the merge,
Steve's testcase fails with the stage1 compiler as previously shown.
Before the merge, the test doesn't fail. However, the GCC build still
fails
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-07 20:39 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-07
22:02 ---
Subject: Re: [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f objeRO
The REG_DEAD problem is a red herring. The notes are recomputed
after the sched1
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-07-07 22:12
---
Created an attachment (id=13867)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13867action=view)
Patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-07-07 22:21
---
I've attached a patch which fixes this bug in an obvious way.
Since complex types are arithmetic types in GNU C++, we should allow standard
conversions to them from integers, just as we do for all other
--- Comment #22 from dberlin at gcc dot gnu dot org 2007-07-07 22:23
---
Subject: Bug 23488
Author: dberlin
Date: Sat Jul 7 22:23:26 2007
New Revision: 126449
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126449
Log:
2007-07-07 Daniel Berlin [EMAIL PROTECTED]
Revert
Hi,
I note that the above problem has been reported before by others. I am getting
the same error message when trying to build gcc and gfortran (v.4.2.0) under
cygwin. Has there been any resolution of this problem?
Any help would be much appreciated.
Dilano Saldin
--- Comment #2 from Raimund dot Merkert at baesystems dot com 2007-07-07
22:36 ---
This may be an old bug and may have crept in between 3.3.3 and 3.4.0 (latter
has it, former doesn't)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #9 from zadeck at naturalbridge dot com 2007-07-07 22:40
---
Subject: Re: [4.3 Regression] checking for suffix of
object files... configure: error: cannot compute suffix of f object files:
cannot compile
dave at hiauly1 dot hia dot nrc dot ca wrote:
--- Comment #8
--- Comment #8 from pcarlini at suse dot de 2007-07-07 22:44 ---
Hi Mark. First, I can point you to C++/21210. In that occasion (see in
particular Comment #3) we struggled with the issue quite a bit (if I remember
correctly we tried to avoid adding constructors...) then you came up with
--- Comment #9 from mark at codesourcery dot com 2007-07-07 22:51 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with complex type conversion
pcarlini at suse dot de wrote:
--- Comment #8 from pcarlini at suse dot de 2007-07-07 22:44 ---
Hi Mark.
--- Comment #10 from pcarlini at suse dot de 2007-07-07 22:57 ---
(In reply to comment #9)
Ah, thanks for finding the old PR. In looking at the mail threads, I
fail to find my magic solution. :-( Do you have a pointer to it?
Well, that PR is *closed as fixed*. Maybe at the time I
The following piece of code is rejected:
program tfe
implicit none
real ,dimension(1:4) :: x
real ,dimension(0:3) :: y
real ,dimension(-1:2) :: z
call sub(x(:))
call sub(y(:))
call sub(z(:))
contains
subroutine sub(a)
implicit none
real,dimension(1:4) :: a
end subroutine sub
--- Comment #6 from patchapp at dberlin dot org 2007-07-07 23:20 ---
Subject: Bug number PR32644
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00660.html
--
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-07
23:30 ---
Subject: Re: [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f obje
suggest a way that we could accommodate this?
Prior to reload being completed, I
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-07-08 00:05
---
Subject: Bug 32644
Author: jvdelisle
Date: Sun Jul 8 00:05:27 2007
New Revision: 126450
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126450
Log:
2007-07-07 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-07-08 00:09
---
Subject: Bug 32644
Author: jvdelisle
Date: Sun Jul 8 00:09:20 2007
New Revision: 126451
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126451
Log:
2007-07-07 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-07-08 00:10
---
Fixed on trunk. Closing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from zadeck at naturalbridge dot com 2007-07-08 00:57
---
Subject: Re: [4.3 Regression] checking for suffix of
object files... configure: error: cannot compute suffix of f object files:
cannot compile
dave at hiauly1 dot hia dot nrc dot ca wrote:
--- Comment
i686-pc-linux-gnu build fails with
libtool: link: /exp/ldroot/dodes/i686-gcc-orig/gcc/gcj
-B/exp/ldroot/dodes/i686-gcc-orig/i686-pc-linux-gnu/libjava/
-B/exp/ldroot/dodes/i686-gcc-orig/gcc/ -ffloat-store -fomit-frame-pointer -Usun
-g -O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-07-08 02:20
---
Subject: Bug 32554
Author: jvdelisle
Date: Sun Jul 8 02:20:10 2007
New Revision: 126456
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126456
Log:
2007-07-07 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-07-08 02:24
---
Subject: Bug 32554
Author: jvdelisle
Date: Sun Jul 8 02:24:37 2007
New Revision: 126457
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126457
Log:
2007-07-07 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-08
02:29 ---
Subject: Re: [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f objeRO
Why can't you put something in the prologue that sets the reg and has an
unspec
--- Comment #13 from zadeck at naturalbridge dot com 2007-07-08 02:41
---
Subject: Re: [4.3 Regression] checking for suffix of
object files... configure: error: cannot compute suffix of f object files:
cannot compile
dave at hiauly1 dot hia dot nrc dot ca wrote:
--- Comment
GCC crashed when I was compiling the Wormux game version 0.8alpha1.
The GCC report:
g++ -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/SDL -D_GNU_SOURCE=1
-D_REENTRANT -DINSTALL_DATADIR=\/usr/share/games/wormux\
-DINSTALL_LOCALEDIR=\/usr/share/locale\
--- Comment #1 from kmikc dot cvb at gmail dot com 2007-07-08 03:52 ---
Created an attachment (id=13868)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13868action=view)
File that contains the error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32671
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-08 04:02 ---
The bug is not reproducible, so it is likely a hardware or OS problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32671
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-08
05:12 ---
Subject: Re: [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f objeRO
There is nothing magical about the entry block defs except that they are
all
98 matches
Mail list logo
