--- Comment #2 from gcc at portuosus dot com 2009-09-02 06:15 ---
This works in 4.4.1 and 3.4.6 and 4.1.2:
//redux2.cc
#include string
#include vector
struct C
{
templatetypename Element, typename Allocator,
--- Comment #3 from gcc at portuosus dot com 2009-09-02 06:44 ---
My bad.
redux2.cc *does* work in the actual code from which it was reduced.
--
gcc at portuosus dot com changed:
What|Removed |Added
--- Comment #4 from gcc at portuosus dot com 2009-09-02 06:48 ---
redux2.cc (and actual code from which it was derived) works with 3.4.6 and
4.1.2 and 4.4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41223
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #6 from drangon dot mail at gmail dot com 2009-09-02 06:54
---
The cross compiler doesn't has problem, but the native compiler has problem.
I will rebuilt the whole cross compiler and native compiler with the newest
source to see the problem still exist or not.
--
--- Comment #5 from yimingli0126 at 163 dot com 2009-09-02 06:59 ---
(In reply to comment #4)
Actually, a library issue, invalid, still library.
Many thanks for your reply.
Yes, it could be a library issue and this problem occurred since v4.3.x.
MSVC 8.0/9.0 doesn't have this
--- Comment #1 from mkuvyrkov at gcc dot gnu dot org 2009-09-02 07:34
---
This is fixed on trunk.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from mkuvyrkov at gcc dot gnu dot org 2009-09-02 07:37
---
If you'd like to backport the fix, it is in revision
http://gcc.gnu.org/viewcvs?view=revisionrevision=149663
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36070
--- Comment #11 from burnus at gcc dot gnu dot org 2009-09-02 09:46 ---
I just downloaded CPMD and built it under gfortran 4.4.1 and 4.5.0 (revision
151047) without trouble.
gcc version 4.5.0 20090528 (experimental) [trunk revision 147953] (SUSE
Linux)
Could you try with a
--- Comment #6 from paolo dot carlini at oracle dot com 2009-09-02 09:48
---
Note: probably the old behavior will be restored in 4.5 as a side effect of
other changes, but this type of code plays very risky games and even if it
compiles, can well lead to wrong runtime behavior. Thus I
--- Comment #7 from yimingli0126 at 163 dot com 2009-09-02 10:33 ---
Thanks.
I have added explicit copy constructors both Inner(Inner const) and
Inner(Inner) to the class Inner, which are superior to template class
IStream Inner (IStream) when the complier decides which should be
--- Comment #6 from amylaar at gcc dot gnu dot org 2009-09-02 12:18 ---
Note that I discovered this bug in the milepost code only after single-stepping
through the SIMD co-processor code to find out what was going wrong.
A match_dup is only effective when an instruction is recognized,
--- Comment #7 from amylaar at gcc dot gnu dot org 2009-09-02 12:27 ---
(In reply to comment #0)
3.1. For my needs, I have patched loop-invariant.c by adding the following
function to explicitly record all CLOBBER references from INSN that match USE
references:
static void
--- Comment #8 from amylaar at gcc dot gnu dot org 2009-09-02 12:35 ---
Somehow bugzilla keeps eating some of the text I put in the Target: field.
My target settings were:
--target=arc-elf32 --with-extra-target-list='mxp-elf'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41188
At revision 151318 bootstrap fails on powerpc-apple-darwin9 (see also
http://gcc.gnu.org/ml/gcc-regression/2009-09/msg00015.html) with:
info --split-size=500 --split-size=500 compare
rm -f stage_current
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning:
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-02 13:15 ---
This is likely due to r151311, hence added Alexandre Oliva in the CC list.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-09-02
13:33 ---
Does this also effect i*86-apple-darwin* and x86_64-apple-darwin*?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
trying '-fvar-tracking-assignments' with current trunk on CP2K, I get the
following ICE:
gfortran -c -fvar-tracking-assignments -O2 -ffast-math -funroll-loops
-ftree-vectorize -march=native -ffree-form -D__GFORTRAN -D__FFTSG -D__FFTW3
-D__LIBINT -I/ext/software/64/gfortran-suite/include
=/data03/vondele/gcc_trunk/build/
Thread model: posix
gcc version 4.5.0 20090902 (experimental) [trunk revision 151319] (GCC)
COLLECT_GCC_OPTIONS='-c' '-fvar-tracking-assignments' '-O2' '-ffast-math'
'-funroll-loops' '-ftree-vectorize' '-v'
/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown
--- Comment #3 from dominiq at lps dot ens dot fr 2009-09-02 13:40 ---
Does this also effect i*86-apple-darwin* and x86_64-apple-darwin*?
I don't know since I did not updated trunk on my macbook. I am waiting for the
mess be sorted out before doins so.
--
--- Comment #2 from jv244 at cam dot ac dot uk 2009-09-02 13:43 ---
reduced testcase:
SUBROUTINE block_15_1_1_1(kbd,kbc,kad,kac,pbd,pbc,pad,pac,prim,scale)
INTEGER, PARAMETER :: dp=8
REAL(KIND=dp) :: kbd(1*1), kbc(1*1), kad(15*1), kac(15*1), pbd(1*1),
pbc(1*1),
--- Comment #7 from drangon dot mail at gmail dot com 2009-09-02 13:48
---
I recompile the whole toolchain using today's newest code, the same result,
cross compiler runs fine, native compiler runs crash.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211
On Linux/ia32, revision 151313 gave:
FAIL: gcc.c-torture/compile/pr40753.c -O3 -g (internal compiler error)
FAIL: gcc.c-torture/compile/pr40753.c -O3 -g (test for excess errors)
FAIL: gcc.dg/guality/example.c -O0 (test for excess errors)
FAIL: gcc.dg/guality/example.c -O1 (test for excess
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41226
--- Comment #1 from jakub at gcc dot gnu dot org 2009-09-02 14:19 ---
Only pr40753.c is a regression, the rest are new tests. And guality tests are
very much expected to FAIL when -fvar-tracking-assignments isn't enabled (to be
enabled in SVN today), or if you don't have very latest
There are interoperability issues with
integer :: single_variable
COMMON /name/ single_variable
and C. Currently, gfortran generates the equivalent to
struct { int single_variable }
however - at least with BIND(C) - it should be compatible to
int single_variable
That's what
--- Comment #2 from joseph at codesourcery dot com 2009-09-02 14:39 ---
Subject: Re: [4.5 regression] Revision 151313 caused many
regressions on trunk
On Wed, 2 Sep 2009, jakub at gcc dot gnu dot org wrote:
Only pr40753.c is a regression, the rest are new tests. And guality tests
16:29 stage3-gcc/plugin.o
The stage2 plugin.o was built with
/vol/gcc/obj/gcc-4.5.0-20090902/10-gcc/./prev-gcc/xgcc
-B/vol/gcc/obj/gcc-4.5.0-20090902/10-gcc/./prev-gcc/
-B/vol/gcc/i386-pc-solaris2.10/bin/ -B/vol/gcc/i386-pc-solaris2.10/bin/
-B/vol/gcc/i386-pc-solaris2.10/lib/ -isystem
/vol/gcc
--- Comment #1 from ro at gcc dot gnu dot org 2009-09-02 14:44 ---
Created an attachment (id=18466)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18466action=view)
preprocessed plugin.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41228
--- Comment #2 from ro at gcc dot gnu dot org 2009-09-02 14:44 ---
Created an attachment (id=18467)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18467action=view)
stage2 plugin.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41228
--- Comment #3 from ro at gcc dot gnu dot org 2009-09-02 14:45 ---
Created an attachment (id=18468)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18468action=view)
stage3 plugin.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41228
--- Comment #4 from aoliva at gcc dot gnu dot org 2009-09-02 14:52 ---
Hello, Dominique, thanks for the report.
Would you please run:
# /path/to/srcdir/contrib/compare-debug --preserve stage[23]-gcc/intl.o
and let me know what it outputs. Comparing the objdump output for both
--- Comment #8 from ro at gcc dot gnu dot org 2009-09-02 14:59 ---
Subject: Bug 41169
Author: ro
Date: Wed Sep 2 14:58:50 2009
New Revision: 151331
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151331
Log:
PR libfortran/41169
* inclhack.def (irix_complex): New
--- Comment #9 from ro at gcc dot gnu dot org 2009-09-02 15:01 ---
Fixed for 4.5.0.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from dominiq at lps dot ens dot fr 2009-09-02 15:07 ---
Would you please run:
[karma] gcc/darwin_buildw% ../_gcc_clean/contrib/compare-debug --preserve
stage2-gcc/intl.o stage3-gcc/intl.o
strip: symbols referenced by relocation entries that can't be stripped in:
--- Comment #4 from jakub at gcc dot gnu dot org 2009-09-02 15:14 ---
bootstrap-debug intentionally compares (stripped) -g compiled objects with
(stripped) -g0 compiled objects.
Please provide info requested in:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224#c4
--
jakub at gcc
--- Comment #6 from aoliva at gcc dot gnu dot org 2009-09-02 15:22 ---
Thanks. Clearly stripping like that isn't going to be enough, and it's not
just a matter of skipping a few initial bytes with a timestamp or somesuch.
Oh well... Back to the drawing board. Unless we can find some
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2009-09-02
15:25 ---
Subject: Re: [4.5 regression] Solaris 10/x86 comparison failure after VTA
merge
jakub at gcc dot gnu dot org writes:
bootstrap-debug intentionally compares (stripped) -g compiled objects with
--- Comment #3 from ami_stuff at o2 dot pl 2009-09-02 15:32 ---
GCC 4.5.0 (20090827) - additional move.l compared to GCC 4.4.2 (20090825):
#NO_APP
.text
.even
.globl _MUL64
_MUL64:
movem.l #16128,-(sp)
move.l 28(sp),a0
move.l 32(sp),a1
--- Comment #7 from ami_stuff at o2 dot pl 2009-09-02 15:42 ---
GCC 4.5.0 (20090827): 888KB
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41095
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-09-02 15:54 ---
(In reply to comment #0)
I was able to re-produce and fix the error using the reduced test
case but the testcase given in the description - c43205b - does not
fail for me anywhere.
Looks like the new SRA is not
--- Comment #7 from dominiq at lps dot ens dot fr 2009-09-02 16:11 ---
I had a look at contrib/compare-debug: neither 'objcopy' nor 'strip --help'
works on darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
--- Comment #9 from shcherbakov at daad-alumni dot de 2009-09-02 16:12
---
This change is incorrect because a register ceases to be a loop invariant
if it is clobbered.
Agreed. Tested your patch. Works fine for me.
Is there any way to know, from which version will the patch be
--- Comment #19 from vmakarov at redhat dot com 2009-09-02 16:14 ---
As I wrote, implementing register pressure-sensitive insn scheduling needs to
look at all insns (ready or not) with resolved dependencies. In an extreme
cases, such insns could b 10-100 more than the ready ones.
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-09-02
16:15 ---
(In reply to comment #7)
I had a look at contrib/compare-debug: neither 'objcopy' nor 'strip --help'
works on darwin.
I'll test gcc trunk on x86_64-apple-darwin10 tonight to make sure that we don't
--- Comment #6 from aoliva at gcc dot gnu dot org 2009-09-02 16:18 ---
Thanks, Rainer. Could I ask for your help in coming up with a minimal testcase
that, compiled with both -g and -g0, fails the contrib/compare-debug test? I
see no other alternative than to test whether something
--- Comment #10 from amylaar at gcc dot gnu dot org 2009-09-02 16:22
---
(In reply to comment #9)
Is there any way to know, from which version will the patch be included in gcc
releases?
If a patch is installed with a suitable PR marker in the log entry, you will
get notification
--- Comment #9 from aoliva at gcc dot gnu dot org 2009-09-02 16:23 ---
Thanks, Dominique. These won't matter, they only help if .eh_frame is the only
difference. Would you please help Rainer in bug 41228 come up with a testcase
that, compiled with -g and -g0, will fail the
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2009-09-02
16:30 ---
Subject: Re: [4.5 regression] Solaris 10/x86 comparison failure after VTA
merge
aoliva at gcc dot gnu dot org writes:
Thanks, Rainer. Could I ask for your help in coming up with a minimal
testcase
--- Comment #10 from dominiq at lps dot ens dot fr 2009-09-02 16:39 ---
For the hello test in comment #7 of pr41228 I get:
[karma] gcc/darwin_buildw% ../_gcc_clean/contrib/compare-debug --preserve
hello-g0.o hello-g.o
hello-g0.o.stripped hello-g.o.stripped differ: char 23, line 2
--- Comment #20 from lucier at math dot purdue dot edu 2009-09-02 16:52
---
Vlad:
Thank you for your reply.
The times I reported are for -fschedule-insns without -fpressure-sched.
The times with the addition of -fpressure-sched are not much greater than
with -fschedule-insns by
--- Comment #21 from vmakarov at redhat dot com 2009-09-02 17:11 ---
I see. I though you compared '-fschedule-insns' and '-fschedule-insns
-fsched-pressure'.
Your numbers shows the same as I reported for SPEC2000. The -fsched-pressure
adds upto 3% compiler time (for power6) on x86
--- Comment #8 from jakub at gcc dot gnu dot org 2009-09-02 17:21 ---
If Solaris strip reorders the sections, I'm afraid either we have to compare
one section by one, or somehow force them to be reordered in the same order, or
give up on bootstrap-debug on Solaris when not using GNU
--- Comment #22 from lucier at math dot purdue dot edu 2009-09-02 17:24
---
The output of gprof on this example is at
http://www.math.purdue.edu/~lucier/bugzilla/11/gprof.out.gz
Everything that takes more than a second is
Each sample counts as 0.01 seconds.
% cumulative self
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2009-09-02
17:24 ---
a testcase:
int main(void) { try { throw 0; } catch (int) { } return 0; }
About analysis, it will take some time. I think it is better to file a bug
right away then to wait results.
--
--- Comment #11 from mrs at apple dot com 2009-09-02 17:41 ---
dwarfdump exists on 10.5 and 10.6. Not sure if that would help at all (I've
not been following what people are doing).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41224
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-09-02 18:03 ---
Hi,
I have committed the patch as revision 151345 after another
bootstrap/testing. Unfortunately I forgot to annotate them with this
PR number in the change log and so the commits did not appear here
current trunk:
gfortran -cpp -c -fvar-tracking-assignments -O2 bug.f90
bug.f90: In function cp_fm_triangular_multiply:
bug.f90:1:0: error: expected an SSA_NAME object
bug.f90:1:0: error: in statement
# DEBUG istat = stat.0
bug.f90:1:0: internal compiler error: verify_ssa failed
Please submit a
I suppose this PR is a bit premature, but after the VTA merge using
-fvar-tracking-assignments with -flto
$ cat seg.c
void foo() {
int hex = 0x4;
}
$ ./xgcc -B. seg.c -flto -fvar-tracking-assignments -c
r...@avarice:~/gcc/lto/x86-build/gcc$ ./xgcc -B. seg.o -flto -shared
In file
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-02 19:31 ---
I will have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-09-02
19:54 ---
(In reply to comment #8)
If Solaris strip reorders the sections, I'm afraid either we have to compare
one section by one, or somehow force them to be reordered in the same order,
or
give up on
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-09-02
19:57 ---
(In reply to comment #11)
dwarfdump exists on 10.5 and 10.6. Not sure if that would help at all (I've
not been following what people are doing).
Mike,
Can you find out if the darwin's strip
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-02 20:13 ---
You need to include -fvar-tracking-assignments in the final link as well. I
guess we need to either special-case it or drop debug stmts on stream-in if
-fvta is not set.
--
rguenth at gcc dot gnu dot org
--- Comment #13 from mrs at apple dot com 2009-09-02 20:17 ---
Subject: Re: [4.5 Regression] Bootstrap broken on powerpc-apple-darwin9 at
revision 151318
On Sep 2, 2009, at 12:57 PM, howarth at nitro dot med dot uc dot edu
wrote:
--- Comment #12 from howarth at nitro dot med
--- Comment #10 from dominiq at lps dot ens dot fr 2009-09-02 20:27 ---
I wonder if this could be the same reason that the comparison of stage2
and stage3 fails on powerpc-apple-darwin9 (PR41224)?
I don't think so, strip (if it does anything) is leaving DWARF stuff in the *.o
files.
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-02 20:30 ---
Hmm, dropping the stmt looks like it would be a hack. Alex - if I just set
flag_var_tracking_assignments to 1 if I encounter a GIMPLE_DEBUG during read-in
I get
t.c: In function 'foo':
t.c:1:6: error:
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-02 20:34 ---
Dropping the stmts works for at least the testcase, but it looks ugly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41230
--- Comment #21 from mrs at apple dot com 2009-09-02 20:37 ---
The patch in #19 is wrong. If you configure a x86-ppc64 compile, it would
want to use -m32, which is wrong. We experimented with a change like that in
#20 and it resulted in failures; I can't imagine any good coming from
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-02 20:55 ---
Note that in general you have to repeat all options on the link command line,
otherwise you are building with -O0 there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41230
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2009-09-02
21:44 ---
I should clarify that the proposed change in comment 20 only triggers if the
host is x86_64-apple-darwin* (which would be the case once the config,guess
change goes in) and will in that case only add -m32
--- Comment #6 from bergner at gcc dot gnu dot org 2009-09-02 21:47 ---
My patch solved the problem, but was very very neutral wrt SPEC2000 scores.
Vlad's idea of moving update_equiv_regs() into its own pass before sched1 makes
sense to me and seems to produce better performing code
--- Comment #1 from rwild at gcc dot gnu dot org 2009-09-02 21:55 ---
patch at http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00190.html.
BTW, please don't use Subject says it all messages, the subject may be
changed in a bug report, that makes it difficult for later readers. Thanks.
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2009-09-02
21:41 ---
Mike,
The fix in comment 20 originated from your email to me...
On Aug 28, 2009, at 8:48 AM, Jack Howarth wrote:
Can you take a look at PR41180 (specifically
comment 9). I think we should propose a
--- Comment #2 from paolo dot carlini at oracle dot com 2009-09-02 22:03
---
Thanks for fixing this small but annoying issue. By the way, my subjects are
perfect as they are, thus your point is moot ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41220
--- Comment #3 from rwild at gcc dot gnu dot org 2009-09-02 22:03 ---
Subject: Bug 41220
Author: rwild
Date: Wed Sep 2 22:03:32 2009
New Revision: 151351
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151351
Log:
Fix 'make clean' to remove stamp-host file in
--- Comment #4 from rwild at gcc dot gnu dot org 2009-09-02 22:09 ---
Fixed.
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2009-09-02
22:22 ---
We could also add (as a separate patch) a change identical to what Apple uses
in their gcc which only triggers on the i[[3456789]]86-*-darwin* host and
target but this should be unnecessary after the
--- Comment #6 from rmansfield at qnx dot com 2009-09-02 22:50 ---
(In reply to comment #5)
Note that in general you have to repeat all options on the link command line,
otherwise you are building with -O0 there.
Yep, I realize that. I just came across this crash by accidentally
Hello,
this is my first bug report, so please don't be harsh with me in case i did
something wrong.
I'm on Ubuntu Jaunty i386, with all the packages installed from and updated to
the most recent version of the official repositories. I'm trying to build for
that system too (no cross-compiling).
+
+0x: Compile Unit: length = 0x02fe version = 0x0002 abbr_offset =
0x addr_size = 0x08 (next CU at 0x0302)
+
+0x000b: TAG_compile_unit [1] *
+ AT_producer( GNU C 4.5.0 20090902 (experimental) )
+ AT_language( DW_LANG_C89 )
+ AT_name
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2009-09-02
23:37 ---
Mike,
I double checked and using tentative_cc doesn't results in a failure in
configure at...
checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... yes
checking for
--- Comment #26 from mrs at apple dot com 2009-09-03 00:20 ---
First, config.guess is orthogonal to the entire discussion, because of that, we
never need to mention it again.
Next, we do a case analysis of every combination of host/target and build
We
engineer each case to work as
This program
class Source;
class Dest;
struct converter
{
converter(Source *s) {}
templateclass D operator D*();
};
Dest* f(Source* s) { return converter(s); }
when compiled by several different versions of g++ (I tried 4.3.4 and 4.4.1;
the person who asked me to reduce the
gcc version 4.5.0 20090902 (experimental) [trunk revision 151353] (GCC)
$ cat ice.i
void malloc_init() {
char *cptr;
char buf[1];
int tmbd = atoi(cptr);
if (tmbd 0)
tmbd = (tmbd = 124) ? tmbd : 124;
else
tmbd = 0;
sprintf(buf, %d\n, tmbd);
}
$ ./xgcc -B. -O1 ice.i -c ice.i
--- Comment #27 from howarth at nitro dot med dot uc dot edu 2009-09-03
00:56 ---
Mike,
Regarding passing -m32 within the x86_64 host case, I was considering the
case of trying to cross compile the i686-apple-darwin10 target on the
x86_64-apple-darwin10 host. While this sounds
--- Comment #2 from lucier at math dot purdue dot edu 2009-09-03 02:37
---
I thought Vlad's scheduling/register allocation patch here
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg3.html
which solves PR24319, might fix this problem, but it does not.
--
I am unsure if this is due to host/target, build, or unrelated to triplets
altogether.
Configure in Stage 2 gcc fails to determine to proper -E flag for the g++
preprocessor (in a 3-Stage build ../prev-gcc/g++ doesn't exist, so it shouldn't
report anything), and instead reports an odd /lib/cpp.
--- Comment #3 from aoliva at gcc dot gnu dot org 2009-09-03 05:35 ---
It was revision 151312 that brought the new failures, actually. 151313 turned
the run-time failures into expected failures, but it did nothing to the cast of
pointer to integer of different size that affects x86_32.
From
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d710371aed91e75f#
The following program is invalid. This is diagnosed at compile time by ifort,
test.f90(19): error #6832: This passed length character name has been used in
an invalid context. [BIGFUNC]
character(i)
89 matches
Mail list logo
