2007/9/6, Kaveh R. GHAZI [EMAIL PROTECTED]:
(Sorry, first one bounced from gcc@ because it was over 400k)
Hi Jan,
On sparc-sun-solaris2.10, I'm getting new bootstrap failures in stage2
complaining several times about rtl sharing. I've included four .i files
for modules that ICEed during
Dominique Dhumieres wrote:
In comment #7 of PR0, Richard Guenther asked the following question
I cannot answer:
Btw, is it mandated by the fortran standard to pass a scalar as array
reference?
Does anyone knows the answer? or should it be asked on comp.lang.fortran?
Here, it looks
On 9/7/07, Tim Prince [EMAIL PROTECTED] wrote:
Dominique Dhumieres wrote:
In comment #7 of PR0, Richard Guenther asked the following question
I cannot answer:
Btw, is it mandated by the fortran standard to pass a scalar as array
reference?
Does anyone knows the answer? or should
Salut Dominique, moin Richard, hello all,
(Answering Richard's question from PR0.)
Dominique Dhumieres wrote:
Btw, is it mandated by the fortran standard to pass a scalar as array
reference?
Does anyone knows the answer? or should it be asked on comp.lang.fortran?
The standard
2007/9/7, Christian Joensson [EMAIL PROTECTED]:
2007/9/6, Kaveh R. GHAZI [EMAIL PROTECTED]:
(Sorry, first one bounced from gcc@ because it was over 400k)
Hi Jan,
On sparc-sun-solaris2.10, I'm getting new bootstrap failures in stage2
complaining several times about rtl sharing. I've
Does anyone knows the answer? or should it be asked on comp.lang.fortran?
It's very specific to the problem at hand, so I doubt c.l.f could give
us much input on that. As I understand, in this case, it actually is
the right thing to do.
FX
In comment #7 of PR0, Richard Guenther asked the following question
I cannot answer:
Btw, is it mandated by the fortran standard to pass a scalar as array
reference?
Does anyone knows the answer? or should it be asked on comp.lang.fortran?
TIA
Dominique
At revision 128228, the patch enables me to go from stage1 to stage3, but
bootstrap
still fails with:
libtool: compile: /opt/gcc/darwin_buildw/gcc/gcj
-B/opt/gcc/darwin_buildw/powerpc-apple-darwin8/ppc64/libjava/
-B/opt/gcc/darwin_buildw/gcc/ -fclasspath=
This is now PR0 handled by Richard Guenther.
Dominique
On Thu, 6 Sep 2007, Jan Hubicka wrote:
Ah, I see.
The attached patch seems to work on my testcase too.
Honza
Index: reorg.c
===
--- reorg.c (revision 128145)
+++ reorg.c (working copy)
@@ -3863,17 +3863,6 @@
Hi,
On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote:
Summary
===
We are closing in on Stage 3, previously announced for September 10th.
At this point, I'm not aware of any reason to delay that date. Are
there any Stage 2 patches that people don't think will be submitted
At revision 128228, the patch enables me to go from stage1 to stage3, but
bootstrap
still fails with:
libtool: compile: /opt/gcc/darwin_buildw/gcc/gcj
-B/opt/gcc/darwin_buildw/powerpc-apple-darwin8/ppc64/libjava/
-B/opt/gcc/darwin_buildw/gcc/ -fclasspath=
This second patch also allows bootstrap to complete on my sparc box.
Thanks for testing and good news,
I will commit the patch
Honza
Thanks,
--Kaveh
--
Kaveh R. Ghazi[EMAIL PROTECTED]
Hi
My builds on i386-pc-solaris2.10 have failed again once the SCCVN patch
was re-applied:
$ make bootstrap-lean ...
[ ... snip ... ]
make[2]: Entering directory `/export/home/arth/gnu/gcc-0907'
make[3]: Entering directory `/export/home/arth/gnu/gcc-0907'
rm -f stage_current
make[3]: Leaving
Hi,
when trying to analyse dynamically allocated objects in C++, I came
across the need to identify results of the new operator (at least the
non-overridden standard one) as malloc-allocated. The cleanest
approach would probably be to mark the new operator function with the
malloc
Snapshot gcc-4.3-20070907 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070907/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Fri, 7 Sep 2007, Martin Jambor wrote:
Index: libstdc++-v3/libsupc++/new
===
--- libstdc++-v3/libsupc++/new(revision 128207)
+++ libstdc++-v3/libsupc++/new(working copy)
@@ -92,7 +92,8 @@
* Placement new
On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
Hi,
when trying to analyse dynamically allocated objects in C++, I came
across the need to identify results of the new operator (at least the
non-overridden standard one) as malloc-allocated. The cleanest
approach would probably be
On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
[ giving operator new the malloc property ]
On Fri, Sep 07, 2007 at 06:30:33PM -0700, Chris Lattner wrote:
It is unclear whether this is safe. Nothing in the standard AFAIK
requires the operator new be implemented in terms of malloc, and
Joe Buck [EMAIL PROTECTED] writes:
| On Sep 7, 2007, at 1:53 PM, Martin Jambor wrote:
| [ giving operator new the malloc property ]
|
| On Fri, Sep 07, 2007 at 06:30:33PM -0700, Chris Lattner wrote:
| It is unclear whether this is safe. Nothing in the standard AFAIK
| requires the operator
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-07 09:57 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from uberlord at gentoo dot org 2007-09-07 12:22 ---
Created an attachment (id=14167)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14167action=view)
Always define __sparc64__ if __arch64__
This is patch based on the netbsd-elf.h file and seems to work just file.
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-09-07 12:13 ---
Btw, is it mandated by the fortran standard to pass a scalar as array
reference?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-09-07 14:14 ---
Both testcases no longer fail for me on the trunk - do you remember the
revision
you had them reduced on?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32575
--- Comment #3 from zippel at gcc dot gnu dot org 2007-09-07 14:00 ---
This now fixed on trunk with r128191/r128208.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13021
--- Comment #18 from dominiq at lps dot ens dot fr 2007-09-07 13:49 ---
FX,
Please don't take my comment on the test suite personally.
I think the PR should be resolved as WONTFIX for the reasons you explain and
the test case should fail on the platform on which it fails.
For the
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-09-07 12:47
---
(In reply to comment #7)
Btw, is it mandated by the fortran standard to pass a scalar as array
reference?
As far as I understand, in this case, it actually is the right thing to do.
--
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-09-07 12:06
---
(In reply to comment #16)
This way to fix the problem shakes the (little) confidence I have in the test
suite!
You're, as always, welcome to improve it! (both by submitting code and general
ideas to make it
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-09-07 11:58 ---
Subject: Bug 0
Author: rguenth
Date: Fri Sep 7 11:57:57 2007
New Revision: 128240
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128240
Log:
2007-09-07 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #16 from dominiq at lps dot ens dot fr 2007-09-07 11:42 ---
This way to fix the problem shakes the (little) confidence I have in the test
suite!
Would not it be better to let the tests fail for the mentionned platforms until
a (real) fix is found (as it is done for
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-07 10:46 ---
Subject: Bug 33321
Author: burnus
Date: Fri Sep 7 10:46:49 2007
New Revision: 128238
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128238
Log:
2007-09-07 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-07 10:46 ---
Subject: Bug 33321
Author: burnus
Date: Fri Sep 7 10:45:50 2007
New Revision: 128237
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128237
Log:
2007-09-07 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from ubizjak at gmail dot com 2007-09-07 10:42 ---
Similar to PR26449, which was _not_ fixed properly (so please don't mark this
one as a duplicate). The problem that was misteriously fixed for one testcase
just resurfaced again. Some info is also in PR32123.
Proposed
--- Comment #1 from tbm at cyrius dot com 2007-09-07 14:11 ---
Created an attachment (id=14168)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14168action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[ Forwarded from http://bugs.debian.org/440378 ]
Frank Lichtenheld reported the following bug in gcc from trunk while compiling
the Linux kernel:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O mxb.i
drivers/media/video/mxb.c: In function 'mxb_ioctl':
drivers/media/video/mxb.c:925:
--- Comment #5 from danglin at gcc dot gnu dot org 2007-09-07 14:57 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00084.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33273
--- Comment #3 from danglin at gcc dot gnu dot org 2007-09-07 14:55 ---
*** This bug has been marked as a duplicate of 33273 ***
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
(Split off from PR 31154.)
The following is accepted but invalid (without using IMPORT t):
module x
implicit none
type t
integer :: i
end type t
interface
type(t) function bar()
end function
end interface
end
--
Summary: User-defined type as function result in an
Overview
=
When compiling the simple file which is attached to this report, I get the
following message suggesting that I report it here:
compiler_error.cc:18: internal compiler error: in lower_regimplify, at
omp-low.c:4251
Steps to reproduce
Compile the attached
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v
3/src -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/g
nu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/
--- Comment #4 from danglin at gcc dot gnu dot org 2007-09-07 14:55 ---
*** Bug 2 has been marked as a duplicate of this bug. ***
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steigers at phys dot ethz dot ch 2007-09-07 14:42
---
Created an attachment (id=14170)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14170action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #2 from tbm at cyrius dot com 2007-09-07 14:11 ---
Here's a smaller testcase:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O mxb.c
mxb.c: In function 'mxb_probe':
mxb.c:30: error: unrecognizable insn:
(insn 10 9 11 3 mxb.c:29 (parallel [
(set
--- Comment #28 from rguenth at gcc dot gnu dot org 2007-09-07 14:03
---
I'm closing this as fixed as I don't see the failure any more.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-07 16:16 ---
You are missing a semicolon (;) after the definition of template class RPGVec
and SUCCES is not defined. After I fix those two issues the program compiles.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
#include string.h
#define MEM_COPY(from,to,size) memcpy((to),(from),(size))
#define MEMCOPY(from,to,n_items,type) \
MEM_COPY((char *)(from),(char *)(to),(unsigned)(n_items)*sizeof(type))
template typename T class RPGVec
{
public:
virtual int Copy( RPGVecT Vin);
}
template typename T int
--- Comment #4 from tromey at gcc dot gnu dot org 2007-09-07 15:26 ---
Fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from steigers at phys dot ethz dot ch 2007-09-07 14:41
---
Created an attachment (id=14169)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14169action=view)
Source code which fails to compile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-07 10:47 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-09-07 10:32 ---
Caused bootstrap miscompare on i?86.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-09-07 10:31 ---
Subject: Bug 32586
Author: rguenth
Date: Fri Sep 7 10:31:09 2007
New Revision: 128236
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128236
Log:
2007-09-07 Richard Guenther [EMAIL PROTECTED]
--- Comment #1 from danglin at gcc dot gnu dot org 2007-09-07 16:54 ---
Subject: Bug 33286
Author: danglin
Date: Fri Sep 7 16:54:38 2007
New Revision: 128249
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128249
Log:
PR target/33286
* gthr-posix.h
configure for a FreeBSD/Sparc64 target now forces a default value of ultrasparc
for -mcpu. This means that the default target defines are never used, one of
which is __sparc64__ as needed by a lot of FreeBSD sources. As such, gcc-4
cannot build FreeBSD/Sparc64.
--
Summary: FreeBSD
--- Comment #2 from hubicka at gcc dot gnu dot org 2007-09-07 16:05 ---
Apparently it is, it should get out as _U_Qfeq.
I was fixing similar problem yesterday. Perhaps it works now on updated tree?
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-09-07 12:00 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-07 15:54 ---
possibly a fallout of the optabs change?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-07 11:45 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dorit at gcc dot gnu dot org 2007-09-07 15:00 ---
Subject: Bug 33299
Author: dorit
Date: Fri Sep 7 15:00:11 2007
New Revision: 128242
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128242
Log:
PR tree-optimization/33299
* tree-vect-transform.c
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-07 10:24 ---
Through this:
else if (ref
flag_strict_aliasing
TREE_CODE (ref) != INDIRECT_REF
!MTAG_P (alias)
base
(TREE_CODE (base) != INDIRECT_REF
||
--- Comment #7 from ubizjak at gmail dot com 2007-09-07 10:20 ---
Fixed on mainline.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #6 from uros at gcc dot gnu dot org 2007-09-07 10:18 ---
Subject: Bug 32821
Author: uros
Date: Fri Sep 7 10:17:46 2007
New Revision: 128235
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128235
Log:
PR tree-optimization/32821
* tree_if_conv.c
--- Comment #2 from ubizjak at gmail dot com 2007-09-07 09:28 ---
Also ICEs on i686-pc-linux-gnu with -msse2.
The problem is again in:
--cut here--
rtx
expand_simple_binop (enum machine_mode mode, enum rtx_code code, rtx op0,
rtx op1, rtx target, int unsignedp,
--- Comment #2 from danglin at gcc dot gnu dot org 2007-09-07 17:18 ---
Fixed by change.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from aph at gcc dot gnu dot org 2007-09-07 17:19 ---
Should be fixed now on EABI.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
copy of http://gcc.gnu.org/ml/fortran/2007-09/msg00121.html:
I have done some investigation about the recent failure of
gfortran.dg/c_char_tests.f03. First the failure disappears with -fno-inline or
-fno-inline-functions:
[karma] f90/bug% gfc c_char_tests_db.f03 -O3 -fno-inline
--- Comment #49 from ebotcazou at gcc dot gnu dot org 2007-09-07 07:08
---
The bug has been fixed by
2005-05-08 Julian Brown [EMAIL PROTECTED]
H.J. Lu [EMAIL PROTECTED]
Paul Brook [EMAIL PROTECTED]
* configure.ac: Set ld_vers_major, ld_vers_minor
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-07 15:02 ---
(In reply to comment #2)
This accept-invalid bug is now tracked as PR4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31154
--- Comment #4 from pcarlini at suse dot de 2007-09-07 17:35 ---
Feedback not forthcoming
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-07 10:10 ---
We have
Pointed-to sets for pointers in sub0
my_char_ref_1, name memory tag: NMT.30, is dereferenced, points-to vars: {
my_char }
and
Aliased symbols
my_char, UID D.871, char, is addressable, direct reads: 0,
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-07 10:06 ---
The problem is that DCE2 deletes the my_char = 121; store because aliasing
thinks the array reference doesn't alias the scalar:
;; Function sub0 (sub0)
sub0 ()
{
char[1:1] my_char_ref;
char D.874;
char
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-09-07 17:54
---
Harold,
As a work around, try putting a LF at the end of the last line of the input
file. I am honing on on this, but don't have it yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33307
--- Comment #5 from kargl at gcc dot gnu dot org 2007-09-07 16:12 ---
If this is case 2
real x
x = huge(1.0)
x = nearest(x,1.0)
end
and this is case 1
real x
x = nearest(huge(1.0),1.0)
end
then the answers are
BTW is it normal that gfortran_nearest_r4 (3.4...4e+38,
--- Comment #4 from dominiq at lps dot ens dot fr 2007-09-07 08:45 ---
I think the standard is very clear on that. Quoting F2003 13.7:
A program is prohibited from invoking an intrinsic procedure under
circumstances where a value to be returned in a subroutine argument or
function
--- Comment #2 from test dot 007 at seznam dot cz 2007-09-07 07:40 ---
(In reply to comment #1)
I'm ashamed.
I still believe the code shouldn't compile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33314
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-07 07:33 ---
Subject: Bug 33303
Author: burnus
Date: Fri Sep 7 07:33:26 2007
New Revision: 128229
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128229
Log:
2007-09-07 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-07 07:33 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from raviprakashg at hotmail dot com 2007-09-07 18:40
---
Thank you,
The problem was found to be MEM_COPY was in a different #ifdef loop in my
application that caused the error.
Thank you for your input.
--
raviprakashg at hotmail dot com changed:
What
When I compile the module listed below using the September 6 snapshot version
of gfortran, I get the following message:
c.f90: In function 'local_cum_nc_chisq':
c.f90:15: internal compiler error: in gfc_finish_var_decl, at
fortran/trans-decl.c:510
Please submit a full bug report,
with
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-09-07 18:55 ---
Subject: Bug 32586
Author: rguenth
Date: Fri Sep 7 18:55:15 2007
New Revision: 128251
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128251
Log:
2007-09-07 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-09-07 18:55 ---
Fixed again.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from andreast at gcc dot gnu dot org 2007-09-07 18:59
---
Patch here:
http://gcc.gnu.org/ml/java-patches/2007-q3/msg00235.html
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
The GNU gfortran compiler points at the wrong place for the error in a format
when that format is expressed as a literal argument to the FMT keyword in a
READ statement. The message is:
read (11,fmt='(q,a)',end=9) len, rec
1
Warning: Unexpected element in
This test
case responds with correct answers for optimization level -O0 but fails at
higher optimization levels. The test case was derived from MPICH2 test
f90_rma/baseattrwinf90.f90 or the corresponding f77_rma/baseattrwinf.f .
cat bug2867.f90
! Derived from MPICH2 test
cat bug.ii
void* operator new(unsigned long, void* __p) { }
struct auto_ptr {
int* p;
~auto_ptr() { delete p; }
};
typedef void* T;
struct vector {
void push_back(const T __x) {
::new(0) T(__x);
insert(__x);
}
void
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-09-07 20:16
---
Subject: Bug 33307
Author: jvdelisle
Date: Fri Sep 7 20:16:05 2007
New Revision: 128253
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128253
Log:
2007-09-07 Jerry DeLisle [EMAIL PROTECTED]
PR
The following idiom causes unnecessary runtime
overhead:
$ cat compare.f90
function foo(a,b,c,d)
logical :: foo
integer, intent(in):: a,b,c,d
foo = all((/ a, b, c /) /= d)
end function foo
$ gfortran -fdump-tree-optimized -O3 -S compare.f90
The *.optimized file shows
bb 2:
D.521 =
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-09-07 20:23
---
Subject: Bug 33307
Author: jvdelisle
Date: Fri Sep 7 20:23:40 2007
New Revision: 128254
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128254
Log:
2007-09-07 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-09-07 20:27
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33307
--- Comment #3 from andreast at gcc dot gnu dot org 2007-09-07 20:49
---
Right now all of the targets I test on do not complain anymore about this
failures. So, 'WORKSFORME'
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pda at freeshell dot org 2007-09-07 20:52 ---
Sorry for the long delay in replying, I've been on vacation. I'm giving you
the output from xgcc -v, but have been unable to trap the core dump with gdb.
I even spent some time writing a little program that did the cc1
--- Comment #1 from kargl at gcc dot gnu dot org 2007-09-07 21:03 ---
(In reply to comment #0)
ftn -o x -O2 bug2867.f90
aprun -n 1 ./x
Got incorrect value for WIN_SIZE ( 140733193389056 , should be
1024 )
Got wrong value for WIN_DISP_UNIT ( 140733193388036 , should
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33341
--- Comment #2 from daney at gcc dot gnu dot org 2007-09-07 21:16 ---
Created an attachment (id=14171)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14171action=view)
Proposed patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33324
--- Comment #3 from daney at gcc dot gnu dot org 2007-09-07 21:30 ---
I might as well accept the bug as I am testing the fix...
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
/boost/xpressive/proto/matches.hpp:409:
internal compiler error: in dependent_type_p, at cp/pt.c:15081
[I'm pressing commit now, I hope I'll have a chance to attach the .ii file and
the full GCC output later]
--
Summary: ICE for gcc version 4.3.0 20070907 (experimental) (GCC
--- Comment #1 from maurizio dot vitale at polymath-solutions dot com
2007-09-07 21:52 ---
Created an attachment (id=14172)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14172action=view)
stdout and stderr from gcc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33342
--- Comment #2 from maurizio dot vitale at polymath-solutions dot com
2007-09-07 21:57 ---
Created an attachment (id=14173)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14173action=view)
The preprocessed source causing the ICE
file gzipped to comply w/ bugzilla size limits.
--
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-09-07
22:05 ---
Subject: Re: Segmentation fault bootstrapping on HP-UX 11.11
As mentioned before, I'm able to bootstrap with HP's compiler, so if this
information doesn't help you I'll just assume there's a problem
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-07 22:33 ---
Confirmed. FRE is guilty:
Replaced D.1654 with ap$p_12(ab) in D.1669_9 = D.1654;
from:
SCC consists of: D.1654_35
Value numbering D.1654_35 stmt = D.1654 = tmp_4;
No store match
Value numbering store D.1654 to
1 - 100 of 122 matches
Mail list logo
