--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-07-11 06:12
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from brooks at gcc dot gnu dot org 2007-07-11 06:25 ---
Subject: Bug 31823
Author: brooks
Date: Wed Jul 11 06:25:47 2007
New Revision: 126538
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126538
Log:
Backport from trunk:
PR fortran/31823
* intrinsic.texi (CMPLX):
--- Comment #6 from brooks at gcc dot gnu dot org 2007-07-11 06:34 ---
Fixed, as per the above commit.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-11 06:38 ---
Working: 2007-07-09-r126478
Failing: 2007-07-10-r126510
I believe it is due to the patch
r126509 | pault | 2007-07-10 07:11:00 +0200 (Di, 10 Jul 2007) | 28 lines
PR 32634 [...]
* module.c
--- Comment #1 from dorit at gcc dot gnu dot org 2007-07-11 06:43 ---
(In reply to comment #0)
r126521 on ppc64-linux
bootstrap fails with
r126512 passed bootstrap on powerpc64, so I guess the problem was introduced
somewhere in between
--
--- Comment #2 from eres at il dot ibm dot com 2007-07-11 06:51 ---
The problem seems to be fixed.
See - http://gcc.gnu.org/ml/gcc/2007-07/msg00352.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32726
--- Comment #2 from siarhei dot siamashka at gmail dot com 2007-07-11
07:06 ---
Tried this test with gcc 4.2.0, it also works correctly. So looks like the
problem only shows up in gcc 4.1.x
--
siarhei dot siamashka at gmail dot com changed:
What|Removed
--- Comment #7 from rguenther at suse dot de 2007-07-11 08:32 ---
Subject: Re: [4.2/4.3 Regression] Wrong code generation.
Alias and C++ virtual bases problem.
On Tue, 10 Jul 2007, dberlin at dberlin dot org wrote:
On 10 Jul 2007 15:32:51 -, rguenther at suse dot de
[EMAIL
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-11 08:33 ---
No error up to and including r126496. That leaves only Paul's patch ...
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rguenther at suse dot de 2007-07-11 08:36 ---
Subject: Re: wrong types in character array/scalar binop
On Wed, 10 Jul 2007, pinskia at gcc dot gnu dot org wrote:
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-07-10 23:36
---
I think this
--- Comment #4 from rguenther at suse dot de 2007-07-11 08:45 ---
Subject: Re: CCP removes volatile qualifiers.
On Tue, 10 Jul 2007, ramana dot radhakrishnan at celunite dot com wrote:
(In reply to comment #2)
As the decl is volatile as well this is clearly a bogus optimization.
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-11 08:46 ---
Also
http://www.lrz-muenchen.de/services/software/mathematik/gsl/fortran/index.html
fails with the same error.
(One needs to change g95) into g95|gfortran) in configure.)
--
--- Comment #15 from jv244 at cam dot ac dot uk 2007-07-11 08:52 ---
FYI, testcase is standard conforming code AFAICT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
--- Comment #1 from rask at sygehus dot dk 2007-07-11 08:53 ---
I think (1) and (2) is just the register allocator being stupid. This sort of
thing can happen when the %rax at (1) was a different pseudo register than the
%rax at (2). The register allocator is supposed to be able to tie
--- Comment #2 from paolo at gcc dot gnu dot org 2007-07-11 09:18 ---
Subject: Bug 32560
Author: paolo
Date: Wed Jul 11 09:18:39 2007
New Revision: 126542
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126542
Log:
/cp
2007-07-11 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #3 from pcarlini at suse dot de 2007-07-11 09:19 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-07-11 09:43
---
Subject: Bug 32589
Author: ebotcazou
Date: Wed Jul 11 09:43:25 2007
New Revision: 126545
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126545
Log:
PR tree-optimization/32589
*
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-07-11 09:46
---
The compiler now bootstraps, but the library still doesn't build.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-07-11 09:55
---
Trying to reduce the testcase, the following ICEs:
contains
Character (len=20) Function Up (string)
Character(len=*) string
Up =
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-07-11 10:00
---
Reduced testcase:
contains
Character (len=20) Function Up (string)
Character(len=*) string
Up = transfer(achar(iachar(transfer(string,x,1))), x)
return
end function Up
end
char.3 =
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-07-11 10:13
---
Built from
#0 build4_stat (code=ARRAY_REF, tt=0x2b468e0df750, arg0=0x2b468e0e4880,
arg1=0x2b468e0e7000, arg2=0x0, arg3=0x0)
at /space/rguenther/src/svn/pointer_plus/gcc/tree.c:3170
#1
--- Comment #4 from pixel at mandriva dot com 2007-07-11 10:23 ---
i forgot to say it doesn't occur without -O, and occurs with -O, -O2
/usr/lib/gcc/i586-mandriva-linux-gnu/4.2.1/cc1 -O fail.c
_create
Analyzing compilation unitPerforming interprocedural optimizations
Assembling
--- Comment #2 from paolo at gcc dot gnu dot org 2007-07-11 10:24 ---
Subject: Bug 30482
Author: paolo
Date: Wed Jul 11 10:23:56 2007
New Revision: 126546
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126546
Log:
2007-07-11 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #3 from pcarlini at suse dot de 2007-07-11 10:24 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-07-11 10:29
---
Subject: Bug 32713
Author: ebotcazou
Date: Wed Jul 11 10:29:17 2007
New Revision: 126547
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126547
Log:
PR tree-optimization/32713
*
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-07-11 10:31
---
The Ada compiler is alive again everywhere.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from jv244 at cam dot ac dot uk 2007-07-11 10:25 ---
(In reply to comment #16)
Trying to reduce the testcase, the following ICEs:
PR 31610 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
--- Comment #5 from irar at il dot ibm dot com 2007-07-11 10:49 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #8 from tbm at cyrius dot com 2007-07-11 12:02 ---
Created an attachment (id=13884)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13884action=view)
-fdump-tree-original, no flag
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32357
--- Comment #9 from tbm at cyrius dot com 2007-07-11 12:02 ---
Created an attachment (id=13885)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13885action=view)
-fdump-tree-original, -fdefault-integer-8
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32357
--- Comment #10 from tbm at cyrius dot com 2007-07-11 12:03 ---
Could you (or some other interested party) compile t.f90 with
-fdump-tree-original, both with and without -fdefault-integer-8, and post the
t.f90.003t.original file produced in each case? This would help us understand
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-07-11 12:29
---
The call to MVBITS is translated as a function call:
_gfortran_mvbits_i8 (C.913, C.914, C.915, i, C.916);
where all C.* (and i) variables are int8, while the library prototype for the
function is:
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32674
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-11 13:14 ---
Created an attachment (id=13886)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13886action=view)
reduced testcase
I suppose it needs some minimal DECL_UID, this is as small as I can get it
(automated). Fails
--- Comment #2 from irar at il dot ibm dot com 2007-07-11 14:50 ---
I don't get any dependence test failures on current mainline. I think they were
solved by Zdenek's rewrite of data-refs' analysis, since I can still see those
failures on autovect-branch (with old data-refs' analysis):
--- Comment #2 from pcarlini at suse dot de 2007-07-11 15:02 ---
Can't reproduce with current mainline / 4_2-branch / 4_1-branch, on
x86_64-linux.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from scovich at gmail dot com 2007-07-11 15:03 ---
(In reply to comment #1)
Confirmed, not a regression.
Also affects 4.3. Changing target
--
scovich at gmail dot com changed:
What|Removed |Added
--- Comment #3 from scovich at gmail dot com 2007-07-11 15:10 ---
This bug also causes _mm_cvtsi128_si64x() (which calls
__builtin_ia32_vec_ext_v2di) to emit suboptimal code.
// g++-4.3-070710 -mtune=core2 -O3 -S -dp
#include emmintrin.h
long vector2long(__m128i* src) { return
--- Comment #4 from matz at gcc dot gnu dot org 2007-07-11 15:37 ---
Nope.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32728
g++: Internal error: Terminated (program cc1plus)
Please submit a full bug report.
make[4]: *** [sql_yacc.o] Error 1
make[4]: Leaving directory `/usr/src/mysql-5.0.41/sql'
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory `/usr/src/mysql-5.0.41/sql'
make[2]: *** [install] Error 2
Consider the following functions:
// g++ -mtune=core2 -O3 -S -dp
void loop(int* dest, int* src, int count) {
for(int i=0; i count; i++)
dest[i] = src[i];
}
void loop_few(int* dest, int* src) { loop(dest, src, 8); }
void loop_many(int* dest, int* src) { loop(dest, src, 64); }
loop()
--- Comment #1 from scovich at gmail dot com 2007-07-11 16:36 ---
(In reply to comment #0)
// g++ -mtune=core2 -O3 -S -dp
Oops... that doesn't actually unroll loop() all, though it still peels
loop_few().
Adding -funroll-loops (supposedly enabled by -O3?) unrolls loop()
Adding
--- Comment #2 from scovich at gmail dot com 2007-07-11 16:37 ---
Regression: gcc-4.1.2 outputs the expected code for all test cases
--
scovich at gmail dot com changed:
What|Removed |Added
--- Comment #12 from kargl at gcc dot gnu dot org 2007-07-11 17:01 ---
(In reply to comment #11)
We need to make a choice between these two, and decided whether all arguments
have the same type (my preferred choice) or if some have a fixed type. In all
cases, uses of MVBITS with
--- Comment #8 from rosana07a at gmail dot com 2007-07-11 17:32 ---
Works with 4.2.1 ' making this a regression
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.1/configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--- Comment #2 from pcarlini at suse dot de 2007-07-11 18:00 ---
Yes, seems doable.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned
string.find returns results when it should not:
x=4294967295 Found:a test
x=4294967294 Found:a test
x=4294967293 Found:a test
x=4294967292 Not found
x=4294967291 Not found
x=4294967290 Not found
x=4294967289 Not found
x=4294967288 Not found
x=4294967287 Not found
x=4294967286 Not found
Also
--- Comment #1 from gnu at bluedreamer dot com 2007-07-11 18:10 ---
Created an attachment (id=13887)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13887action=view)
Source file
Example source that causes bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730
--- Comment #2 from gnu at bluedreamer dot com 2007-07-11 18:11 ---
Created an attachment (id=13888)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13888action=view)
From --save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730
--- Comment #3 from gnu at bluedreamer dot com 2007-07-11 18:11 ---
Created an attachment (id=13889)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13889action=view)
From --save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730
--- Comment #7 from pcarlini at suse dot de 2007-07-11 18:20 ---
*** Bug 32730 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2007-07-11 18:20 ---
*** This bug has been marked as a duplicate of 31401 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
$ cat pack.f90
program main
real, dimension(2,2) :: a
a = 0
print *,pack(a,logical(a0,kind=1))
end program main
$ gfortran pack.f90 ./a.out
Fortran runtime error: Funny sized logical array
$ cat unpack.f90
program main
logical(kind=1),dimension(2,2) :: mask
mask = .true.
print
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--- Comment #4 from uros at gcc dot gnu dot org 2007-07-11 18:43 ---
Subject: Bug 32661
Author: uros
Date: Wed Jul 11 18:42:44 2007
New Revision: 126557
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126557
Log:
PR target/32661
* config/i386/sse.md
--- Comment #5 from ubizjak at gmail dot com 2007-07-11 18:47 ---
(In reply to comment #3)
This might be related to bug 32708 (and therefore have a similar fix?)
Yes, DImode moves are implemented/fixed by the patch above. Your example now
compiles to:
movq(%rdi), %rax
--- Comment #2 from ubizjak at gmail dot com 2007-07-11 19:12 ---
This is due to reload. It is trying to solve following pattern
(insn:HI 25 24 28 2 pr32725.c:14 (parallel [
(set (reg:DI 75)
(and:DI (reg:DI 71)
(reg:DI 74)))
--- Comment #5 from ubizjak at gmail dot com 2007-07-11 19:20 ---
Fixed in 4.3.0.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #3 from bonzini at gnu dot org 2007-07-11 19:49 ---
First, I'm not a reload expert. :-) But it does not look like a reload bug (or
at least it is easily worked around in the machine description, methinks).
regmove should have changed that but it does not probably because
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-07-11 20:10
---
Can someone paste the output of debug_generic_stmt (to) and
debug_tree(to) at the point of failure?
(gdb) p debug_tree(to)
var_decl 0x557f7114 vn_top.181
type void_type 0x55716804 void sizes-gimplified
--- Comment #6 from scovich at gmail dot com 2007-07-11 20:27 ---
(In reply to comment #5)
SImode moves will be a bit harder, because shufps insn pattern is involved in
the vector expansion.
IIRC, shufps takes 3 cycles on Core2
(http://www.agner.org/optimize/instruction_tables.pdf),
--- Comment #4 from rask at sygehus dot dk 2007-07-11 20:45 ---
In reply to comment #2:
Reload is unable to use a register with a REG_DEAD note for an output reload.
Look at the functions find_reload_regs(), order_regs_for_reload() and
find_reg() and pay attention to how they use
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-07-11 20:47 ---
Something c++ specific, when compiled by gcc, the loop is unrolled just fine.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rakdver at gcc dot gnu dot org 2007-07-11 20:56 ---
The following patch fixes the problem; I am not quite sure why this check is
there.
Index: cfghooks.c
===
*** cfghooks.c (revision 126547)
---
| subroutine foo(a) bind(c)
|character(len=1,kind=c_char), value :: a
Has a single, scalar argument a; in C notation:
| void foo(char a)
gfortran, however, uses
| void foo(char a[])
with length one.
This causes problems on IA-64 HP-UX, see thread starting at
--- Comment #4 from jaydub66 at gmail dot com 2007-07-11 21:39 ---
Paul,
I tested your patch, and indeed it does fix the problem for me. I also checked
it for regressions, and it doesn't seem to break anthing.
Cheers,
Janus
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-07-11 21:41 ---
Created an attachment (id=13890)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13890action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32731
--- Comment #7 from steven at gcc dot gnu dot org 2007-07-11 21:42 ---
The proposed patch (http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01098.html)
breaks library compatibility. Is this intentional?
--
steven at gcc dot gnu dot org changed:
What|Removed
.17854_150(7), NMT.17854_68(8), NMT.17854_68(11),
NMT.17854_68(12)
PHI argument
NMT.17854_68
for PHI node
NMT.17854_209 = PHI NMT.17854_150(7), NMT.17854_68(8), NMT.17854_68(11),
NMT.17854_68(12)
+===GNAT BUG DETECTED==+
| 4.3.0 20070711 (experimental
--- Comment #7 from paolo at gcc dot gnu dot org 2007-07-11 21:52 ---
Subject: Bug 31027
Author: paolo
Date: Wed Jul 11 21:52:04 2007
New Revision: 126558
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126558
Log:
2007-07-11 Paolo Carlini [EMAIL PROTECTED]
PR c++/31027
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-07-11 21:54
---
I think it was decided that until 4.3 is released, we don't care about
libgfortran ABI stability
(http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00927.html)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32035
--- Comment #8 from paolo at gcc dot gnu dot org 2007-07-11 21:54 ---
Subject: Bug 31027
Author: paolo
Date: Wed Jul 11 21:54:36 2007
New Revision: 126559
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126559
Log:
2007-07-11 Paolo Carlini [EMAIL PROTECTED]
PR c++/31027
--- Comment #9 from pcarlini at suse dot de 2007-07-11 21:56 ---
Doesn't fail anymore in mainline and 4_2-branch.
--
pcarlini at suse dot de changed:
What|Removed |Added
The only way i can see this happening is if you have a truly
uninitialized variable, or there is something we have missed.
Does this function have cfun-static_chain_decl being used, and we
have a copy of that here?
It is theoretically safe to call set_ssa_to_val with to == vn_top, but
it's
--- Comment #6 from dberlin at gcc dot gnu dot org 2007-07-11 22:20 ---
Subject: Re: [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
The only way i can see this happening is if you have a truly
uninitialized variable, or there is something we have missed.
Does this
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-07-11 22:21
---
Just for the record:
The bug disappeared between 2007-06-23 and 2007-07-02.
I'd guess this was fixed by
2007-07-01 Ollie Wild [EMAIL PROTECTED]
* name-lookup.c (ambiguous_decl): Fix case when
--- Comment #14 from reichelt at gcc dot gnu dot org 2007-07-11 22:28
---
Btw, the bug disappeared on mainline between 2007-05-13 and 2007-05-26.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19910
--- Comment #3 from pcarlini at suse dot de 2007-07-11 22:37 ---
Thanks Volker.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32106
--- Comment #6 from reichelt at gcc dot gnu dot org 2007-07-11 23:04
---
Mark, I don't think the fix for this PR is complete, because the following
simplified testcase (which previously ICE'd) should compile IMHO:
=
--- Comment #4 from dougkwan at google dot com 2007-07-11 23:15 ---
Created an attachment (id=13891)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13891action=view)
Patch for fixing byte swap optimization.
I have tested this patch on i486-linux-gnu (C/C++ test suite only, full
--- Comment #12 from rob1weld at aol dot com 2007-07-12 00:55 ---
I am building on target i686-pc-linux-gnu and have not noticed this problem
with this target. It does NOT occur for a 'regular' make, only seems to
happen with this last make profiledbootstrap that I did:
We have a
--- Comment #33 from kkojima at gcc dot gnu dot org 2007-07-12 01:11
---
It seems that the patch 126418 causes an ICE for gcc.dg/asm-4.c
and the patch 126487 breaks gcc.c-torture/compile/2804-1.c
on 4.2 for SH. Both failures happen only with -O0. It looks
ia64 testresults show
While attempting to compile Xerces 2.7 on MacOS, I discovered what I think
is a bug in gcc, which I'm using for all phases of build. The c++ preprocessor
is emitting line number statements which have an inconsistent number of
arguments after the file name, e.g.:
# 1
--- Comment #1 from pitaman at austin dot rr dot com 2007-07-12 01:13
---
Created an attachment (id=13892)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13892action=view)
simple C++ input file that shows the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32734
--- Comment #2 from pitaman at austin dot rr dot com 2007-07-12 01:14
---
Created an attachment (id=13893)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13893action=view)
minor tweaking of c++ preprocessor output which fixes the problem
--
--- Comment #3 from pitaman at austin dot rr dot com 2007-07-12 01:14
---
zeus:~/projects/xerces-c-src_2_7_0 pitaman$ gcc fails.cpp
/usr/include/xercesc/util/XMLEnumerator.hpp:2: error: template with C linkage
zeus:~/projects/xerces-c-src_2_7_0 pitaman$ gcc succeeds.cpp
/usr/bin/ld:
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-12 01:25 ---
How did /usr/include/xercesc come to exist? Was it there before compiling
Xerces or did it use that as the default path for install?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32734
Test program attached.
Command line:
[EMAIL PROTECTED]:~/exp-sum-delta$ /home/mec/gcc-4.3-20070707/install/bin/g++
-v -S
-O2 -msse2 sum-delta.cc
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/mec/gcc-4.3-20070707/src/configure
--build=i686-pc-linux-
gnu
--- Comment #1 from mec at google dot com 2007-07-12 01:30 ---
Created an attachment (id=13894)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13894action=view)
Test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32735
--- Comment #2 from mec at google dot com 2007-07-12 01:31 ---
Created an attachment (id=13895)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13895action=view)
Generated code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32735
--- Comment #3 from mec at google dot com 2007-07-12 01:33 ---
Created an attachment (id=13896)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13896action=view)
Assembly code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32735
--- Comment #4 from mec at google dot com 2007-07-12 01:33 ---
Created an attachment (id=13897)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13897action=view)
Assembly code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32735
--- Comment #12 from dberlin at gcc dot gnu dot org 2007-07-12 02:20
---
Subject: Bug 32663
Author: dberlin
Date: Thu Jul 12 02:20:04 2007
New Revision: 126568
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126568
Log:
2007-07-11 Daniel Berlin [EMAIL PROTECTED]
PR
--- Comment #5 from pault at gcc dot gnu dot org 2007-07-12 04:58 ---
(In reply to comment #4)
No error up to and including r126496. That leaves only Paul's patch ...
Daniel,
Could you please revert r126496 and re-open the PR? - I can do nothing about it
for 10 days or more.
Cheers
95 matches
Mail list logo
