--- Comment #7 from dberlin at gcc dot gnu dot org 2007-07-24 07:16 ---
Didn't you commit the shared bitmap fix?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
--- Comment #1 from debian-gcc at lists dot debian dot org 2007-07-24
07:21 ---
glibc 2.6 related? unreproducible with a glibc downgraded to 2.5
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32853
--- Comment #139 from jv244 at cam dot ac dot uk 2007-07-24 07:22 ---
(In reply to comment #138)
> I'll
> start a new test with current trunk.
Tue Jul 24 06:32:19 UTC 2007 (revision 126866) is also passing the test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-07-24 07:30 ---
Subject: Bug 32723
Author: rguenth
Date: Tue Jul 24 07:30:47 2007
New Revision: 126867
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126867
Log:
2007-07-24 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-07-24 07:31 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #140 from pault at gcc dot gnu dot org 2007-07-24 07:45 ---
(In reply to comment #139)
> (In reply to comment #138)
> > I'll
> > start a new test with current trunk.
> Tue Jul 24 06:32:19 UTC 2007 (revision 126866) is also passing the test.
You were right about the options
--- Comment #8 from dorit at gcc dot gnu dot org 2007-07-24 07:50 ---
Subject: Bug 31776
Author: dorit
Date: Tue Jul 24 07:50:10 2007
New Revision: 126868
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126868
Log:
2007-07-23 Dorit Nuzman <[EMAIL PROTECTED]>
merge revi
--- Comment #7 from patchapp at dberlin dot org 2007-07-24 07:55 ---
Subject: Bug number PR31205
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/msg01709.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #141 from jv244 at cam dot ac dot uk 2007-07-24 08:44 ---
(In reply to comment #140)
> You were right about the options: "-O3 -ffast-math -march=native" triggers the
> crash on PIV/Cygwin_NT, whereas "-O1" does not. I'll retry latter with
> -march=native, which I suspect fr
--- Comment #13 from patchapp at dberlin dot org 2007-07-24 08:45 ---
Subject: Bug number PR32867
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/msg01713.html
--
http://gcc.gnu.org/bugzilla/s
I have 3 global register variables, 1 pointer to a struct and 2 unsigned
integers. Next I have 2 functions, each working on the pointer and on one of
the integers. The generated output looks strange in the first place, and is
dependant on the order of the two functions in the input .c file.
--
--- Comment #4 from dorit at gcc dot gnu dot org 2007-07-24 08:50 ---
> i'm wondering if this could be related to a problem we're seeing with
> segfaults
> caused by misaligned movdqa instructions in zlib compiled with
> -ftree-vectorize.
A fix for PR25413 was committed to mainline.
R
--- Comment #1 from ecd at brainaid dot de 2007-07-24 08:51 ---
Created an attachment (id=13955)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13955&action=view)
Input file to trigger the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32874
--- Comment #2 from ecd at brainaid dot de 2007-07-24 08:52 ---
Created an attachment (id=13956)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13956&action=view)
Input file to trigger the problem with order of functions reversed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #3 from ecd at brainaid dot de 2007-07-24 08:52 ---
Created an attachment (id=13957)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13957&action=view)
Output number 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32874
--- Comment #4 from ecd at brainaid dot de 2007-07-24 08:53 ---
Created an attachment (id=13958)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13958&action=view)
Output number 2 (function order reversed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32874
--- Comment #5 from dorit at gcc dot gnu dot org 2007-07-24 08:53 ---
(In reply to comment #4)
> I just tried to reproduce this bug on IA64 Linux (and HP-UX) with ToT sources
> (version 126242) and was not able to. Can anyone else reproduce this with ToT
> sources?
does the fact that n
--- Comment #5 from ecd at brainaid dot de 2007-07-24 08:54 ---
Command line to compile the samples:
gcc -Wall -O2 -ffixed-i0 -ffixed-i1 -ffixed-i2 -ffixed-i3
-fno-strict-aliasing-fno-delayed-branch -fno-reorder-blocks
-fno-optimize-sibling-calls -Wa,-Av9a -I. -D_GNU_S
write(6,*) (/(S1(i),i=1,3,-1)/)
CONTAINS
FUNCTION S1(i)
CHARACTER(LEN=1) :: S1
INTEGER :: I
S1="123456789"(i:i)
END FUNCTION S1
END
--
Summary: Not Implemented: complex character array constructor
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
--- Comment #4 from dorit at gcc dot gnu dot org 2007-07-24 08:59 ---
Just for the record - as we discussed last week, there are two ways to solve
this problem - either have LIM leave behind it cleaner code (smthing like
copy-prop + dce to eliminate the extra copy stmts), or improve the
--- Comment #13 from dorit at gcc dot gnu dot org 2007-07-24 09:05 ---
David, can you confirm that this PR can now be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413
--- Comment #4 from paolo at gcc dot gnu dot org 2007-07-24 09:18 ---
Subject: Bug 30535
Author: paolo
Date: Tue Jul 24 09:18:39 2007
New Revision: 126871
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126871
Log:
/cp
2007-07-24 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #5 from pcarlini at suse dot de 2007-07-24 09:20 ---
Fixed for 4.2.2.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from dominiq at lps dot ens dot fr 2007-07-24 09:31 ---
The regression occured between revisions 123612 and 123624, see:
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg00300.html
http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg00311.html
The most likely candidate is
--- Comment #6 from burnus at gcc dot gnu dot org 2007-07-24 09:42 ---
I believe this is fixed by PR30940.
The first example gives:
Warnung: Actual argument contains too few elements for dummy argument 'i' (4/6)
at (1)
The second example:
Warnung: Character length of actual argument sh
--- Comment #6 from brian dot sidebotham at gmail dot com 2007-07-24 10:05
---
I can successfully build gcc cvs if I have the install dir in my $PATH so I
expect this is my fault. Apologies for taking up anyone's time!
--
brian dot sidebotham at gmail dot com changed:
W
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-24 10:09 ---
Error message:
fatal error: gfc_todo: Not Implemented: complex character array constructors
compilation terminated.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-24 10:11 ---
The problem seems to be a backend one(?). What happens is that for
signed char return_sc (signed char sc)
{
return sc;
}
the return value is now zero-extended instead of sign-extended (the sign
extension was don
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-24 10:13 ---
The following is a function that is now differently compiled on both x86_64 and
i686:
signed char return_sc (signed char *sc)
{
return *sc;
}
--
rguenth at gcc dot gnu dot org changed:
What|Rem
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-24 10:25 ---
So, my final conclusion would be that this is a testsuite bug because whether
we do zero or sign extension for returns in a register does not matter for
valid uses of this return value.
--
rguenth at gcc dot gnu
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-24 10:27 ---
Index: return_sc.c
===
--- return_sc.c (revision 126678)
+++ return_sc.c (working copy)
@@ -30,7 +30,7 @@ int main (void)
sc < (signed char) 127
--- Comment #2 from paolo at gcc dot gnu dot org 2007-07-24 11:08 ---
Subject: Bug 32561
Author: paolo
Date: Tue Jul 24 11:08:27 2007
New Revision: 126873
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126873
Log:
/cp
2007-07-24 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #3 from paolo at gcc dot gnu dot org 2007-07-24 11:08 ---
Subject: Bug 29001
Author: paolo
Date: Tue Jul 24 11:08:27 2007
New Revision: 126873
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126873
Log:
/cp
2007-07-24 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #3 from pcarlini at suse dot de 2007-07-24 11:09 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from pcarlini at suse dot de 2007-07-24 11:09 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-24 11:20 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01709.html
See also PR 31205.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32842
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-24 11:47 ---
The 32bit psABI specifies Integral Arguments as 'Functions pass all
integer-valued
arguments as words, expanding or padding signed or unsigned bytes and
halfwords as needed'. For return values the best I can find is
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-07-24 12:09 ---
You may only access union members through the union, not through other
pointers.
GCC is perfectly valid in caching n->next in the first example. So, for
comment #4, it is true that &u.a.n.next == &u.b.n.prev, but yo
--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-24 13:05 ---
(In reply to comment #1)
> ... We actually had both options in the vectorizer for a while
> (guarded by ADJUST_IN_EPILOG hard-coded #define), however we didn't know how
> to
> choose between the two options (cost wise
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-24 13:28 ---
The following patch works for the original example; it also works in principle
for the additional example, but there the error message is printed three times.
Index: gcc/fortran/expr.c
===
--- Comment #9 from burnus at gcc dot gnu dot org 2007-07-24 13:31 ---
Daniel, could you update the bug status; e.g. mark it as fixed or write what
still needs to be done.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
integer,private :: i
namelist /c/ i
is correctly diagnosed as invalid: "PRIVATE symbol '%s' cannot be member of
PUBLIC namelist at %L"; however, for derived types this fails. Note that NAG
f95 only gives an error for "B" and not for "A":
Error: mod.f90, line 14: PUBLIC NAMELIST /B/ has member T2
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-24 13:45 ---
Paul, any plans to get the fix from comment #3 into trunk?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-24 13:49 ---
Index: resolve.c
===
--- resolve.c (revision 126873)
+++ resolve.c (working copy)
@@ -7040,6 +7044,13 @@ resolve_fl_namelist (gfc_symbol *sym)
/*
While making GCC 3.4.6 I am Getting the following error
*
ERROR
*
creating config.h
config.h is unchanged
echo timestamp > cstamp-h
cp ./libgnuintl.h libintl.h
cc -c -g -DHAVE_CONFIG_H
--- Comment #3 from tromey at gcc dot gnu dot org 2007-07-24 14:31 ---
Fixed in 4.3.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCO
--- Comment #5 from tromey at gcc dot gnu dot org 2007-07-24 14:33 ---
Can you try running ecj with -help or something like that?
I'm wondering whether it works at all.
Perhaps the bootstrap java interpreter is broken on your machine,
or something like that.
--
tromey at gcc dot gnu
--- Comment #6 from tromey at gcc dot gnu dot org 2007-07-24 14:34 ---
Yeah, I've seen problems like this as well on occasion.
I'm not sure what to do about them however.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from tromey at gcc dot gnu dot org 2007-07-24 14:36 ---
Sorry I missed this for so long.
Please submit these patches to the java-patches mailing list.
Thanks.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tromey at gcc dot gnu dot org 2007-07-24 14:36 ---
FYI -- please submit patches to the java-patches mailing list.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32846
Executing on host: /home/dave/gnu/gcc-4.3/objdir/./gcc/g++ -shared-libgcc
-B/hom
e/dave/gnu/gcc-4.3/objdir/./gcc -nostdinc++
-L/home/dave/gnu/gcc-4.3/objdir/hppa
-linux/libstdc++-v3/src
-L/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/
src/.libs -B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/
--- Comment #9 from rask at sygehus dot dk 2007-07-24 14:56 ---
This is not fully fixed yet. Compile these two functions with -O2
-fdump-tree-original:
void test5_1(int e)
{
if ((e >> 31) & 64)
foo();
}
typedef int myint;
void test5_2(myint e)
{
if ((e >> 31) & 64)
foo();
--- Comment #10 from rask at sygehus dot dk 2007-07-24 15:00 ---
Created an attachment (id=13959)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13959&action=view)
Patch to fix testcase when int isn't exactly 32 bits
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21137
--- Comment #1 from pcarlini at suse dot de 2007-07-24 15:00 ---
I think there is no reason to categorize as libstdc++: almost nothing changed
in the library in that timespan (and definitely nothing related) and, AFAICS,
all the other targets are fine. Also, I would suggest adding to the
gfortran has:
irand() - g77
rand() - g77
random_number() - Fortran 90
The algorithm used is different.
Expected:
- State something about the used algorithm
- Point rand() users to random_number() as this algorithm is seemingly better.
(or make at least clear(er) that the algorithms are differ
--- Comment #2 from cvs-commit at developer dot classpath dot org
2007-07-24 15:27 ---
Subject: Bug 32862
CVSROOT:/cvsroot/classpath
Module name:classpath
Changes by: Tom Tromey 07/07/24 15:26:36
Modified files:
. : ChangeLog
java/uti
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-24
15:40 ---
Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test
> I think there is no reason to categorize as libstdc++: almost nothing changed
> in the library in that timespan (and definitely nothin
--- Comment #10 from chris at cdnorthamerica dot com 2007-07-24 15:51
---
It doesn't seem to fail using g++ 4.2. Fix or fluke?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29517
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-24 15:55 ---
This seems to be fixed at least with the patches I have pending.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The following program comes - as PR 32842 - from Lawrie Schonfeld's
ISO_VARYING_STRING testsuite. Note this bug remains after the patch for PR
32842 has been applied.
The dump shows:
_gfortran_deallocate (res.chars.data
op_assign_vs_ch (&res, (char[1:10] *) &char_a[5]{lb: 1 sz: 1}, 1);
_gfo
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-24 15:57 ---
This seems to be fixed with the patches I have pending.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from danglin at gcc dot gnu dot org 2007-07-24 16:01 ---
The program is segfaulting when compiled at -O2. It doesn't fail at
-O0 or -O1. I added -static to make debugging easier.
Starting program:
/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/testsuite/16020.xg
--- Comment #3 from jb at gcc dot gnu dot org 2007-07-24 16:03 ---
Confirmed.
Gfortran should IMHO not do any inlining itself, rather somehow tell the
middle-end when inlining is allowed, and let the middle-end optimizer decide
when to actually inline.
--
jb at gcc dot gnu dot org c
--- Comment #3 from klra67 at freenet dot de 2007-07-24 16:10 ---
Subject: Re: Sort of vector of template class fails
Am Montag, 23. Juli 2007 23:55 schrieb pinskia at gcc dot gnu dot org:
> This is correct, you need to mark operator< as taking a const this
> variable. Like:
> boo
The following testcase is AFAICT legal:
subroutine foo ()
integer, pointer :: p => NULL()
contains
pure function bar (a)
integer, intent(in) :: a
integer :: bar
bar = a
end function bar
end subroutine foo
gfortran refuses to compile it, complaining
pure-escape.f90:2.23:
inte
8.0.min.ii:15: error: non-trivial conversion at assignment
struct
{
X:: * const __pfn;
long int __delta;
} * const *
struct
{
X:: * const __pfn;
long int __delta;
} * const &
__ptr = __ptr.24
which is gimplified from the INIT_EXPR
__ptr = (struct
{
X:: * const __pfn;
long int
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-24 16:19 ---
Created an attachment (id=13960)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13960&action=view)
testcase (slightly reduced from tr1/3_function_objects/function/8.cc)
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-24 16:20 ---
Created an attachment (id=13961)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13961&action=view)
Reduced test case
Reduced test case which does not depend anymore on external files.
Coredumps with gfortran, wo
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-24
16:25 ---
Subject: Re: Exception handling not thread-safe on AIX5.x and HP-UX
> It doesn't seem to fail using g++ 4.2. Fix or fluke?
There were some changes to config/pa/hpux-unwind.h in 2006 that
improved unwindi
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-24 16:28 ---
./cc1plus -fpreprocessed 8.0.min.ii -quiet -dumpbase 8.cc -auxbase 8 -version
-fmessage-length=0 -o /dev/null -std=c++0x -fstrict-aliasing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32882
--- Comment #1 from jb at gcc dot gnu dot org 2007-07-24 16:30 ---
Confirmed, thought the documentation for RANDOM_NUMBER already mentions that it
uses KISS, so this applies only to the legacy intrinsics.
--
jb at gcc dot gnu dot org changed:
What|Removed
When this code is run with : valgrind --tool=memcheck a.out 5 it produces quite
a few errors. I confirmed this with 4.2.0. The problem is not present in 3.2.2.
Valgrind version is 3.2.3:
#include
using namespace std;
int main()
{
set c;
c.insert(1);
c.insert(2);
c.insert(3);
c.insert(
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-24 16:33 ---
Created an attachment (id=13962)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13962&action=view)
testcase (more reduced)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32882
--- Comment #1 from Raimund dot Merkert at baesystems dot com 2007-07-24
16:40 ---
If I replace *i with ++i, I get basically the same result. It has struck me as
weird that this would be the "preferred way" according to Scott Myers, but
looking at the implementation bits/stl_iterator.h,
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-24 16:44 ---
> Confirmed, thought the documentation for RANDOM_NUMBER already mentions that
> it
> uses KISS, so this applies only to the legacy intrinsics.
Is KISS clear enough? If yes then it indeed only applies to RAND().
ht
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-24 16:45 ---
Subject: Bug 32778
Author: dfranke
Date: Tue Jul 24 16:45:32 2007
New Revision: 126881
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126881
Log:
gcc/fortran:
2007-07-24 Daniel Franke <[EMAIL PROTECTED]>
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-24 16:49 ---
Closing as fixed.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #2 from pcarlini at suse dot de 2007-07-24 16:54 ---
This code is invalid, as Carl Barron, Greg Herlihy and others explained very
carefully in that thread.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-07-24 16:57
---
Subject: Bug 32867
Author: dfranke
Date: Tue Jul 24 16:57:02 2007
New Revision: 126882
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126882
Log:
gcc/fortran:
2007-07-24 Daniel Franke <[EMAIL PROTECTED]>
--- Comment #15 from dfranke at gcc dot gnu dot org 2007-07-24 16:59
---
Changed the title to reflect the actual problem.
Closing as fixed.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32877
Using the following invalid program, one gets an ICE
NAG f95: Assignment to Z in PURE procedure BAR
gfortran: segmentation fault.
subroutine foo ()
integer :: z
contains
pure function bar (a)
integer, intent(in) :: a
integer :: bar
z = 45 ! <<<
bar = a
end function
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-24 17:22 ---
Confirmed.
The problem is that gfc_pure(NULL) is called and thus
sym = gfc_current_ns->proc_name;
is used as procedure symbol, which is "bar" and not "foo".
The following patch fixes this, but I have not regteste
--- Comment #4 from danglin at gcc dot gnu dot org 2007-07-24 17:27 ---
(gdb) p _M_iterators
$20 = (__gnu_debug::_Safe_iterator_base *) 0xd4820
(gdb) p *_M_iterators
$21 = {_M_sequence = 0x0, _M_version = 0, _M_prior = 0x0, _M_next = 0x0}
(gdb) p _M_const_iterators
$19 = (__gnu_debug::_S
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-24 17:33 ---
Seemingly the error is detected and only on writing the error the segmentation
fault occurs:
==494== Invalid read of size 8
==494==at 0x41D398: show_locus (error.c:171)
==494==by 0x41D29D: error_print (error.
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-24 18:28 ---
Others cannot reproduce it (on i686 & x86_64), but here I can with gfortran-4.1
& 4.2 of SUSE, with the vanilla 4.2 and with 4.3.
The problem is for whatever reason the "&code->expr->where" argument to
gfc_error(). I
Hi,
I was trying to compile my Openmp parallel code, and see the effects of turning
of f of some optimization parameters. I get an internal compiler error. The
whole error is attached below.
miner-02:/files4/berkin/kmeans % make OPTFLAGS="-O3 -fno-unit-at-a-time -v
-save-temps"
/files4/berkin/gc
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-24 18:29 ---
>"/usr/include/iso/stddef_iso.h", line 62: invalid type combination
What target are you trying to build on?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from boz283 at ece dot northwestern dot edu 2007-07-24
18:36 ---
Created an attachment (id=13963)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13963&action=view)
The intermediate file for the problematic source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #6 from tbm at cyrius dot com 2007-07-24 18:37 ---
(In reply to comment #5)
> does the fact that no one has responded yet means that this failure cannot be
> reproduced anymore?
I'll try next week and let you know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-24 18:39 ---
Is there a reason why you are using -fno-unit-at-a-time ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32885
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-07-24 18:41
---
Changed the title as init expressions are not restricted to the previously
named function.
The following is a list of items I am aware of that need to be done before init
expressions are complete:
TODO for F95, 7
--- Comment #3 from hjl at lucon dot org 2007-07-24 18:42 ---
It should be fixed by
http://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00744.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32852
--- Comment #3 from boz283 at ece dot northwestern dot edu 2007-07-24
18:49 ---
I was trying to see how different optimizations effect execution speed of the
application, i.e. trying to see if removing that compiler optimization
increases/decreases the execution time. Currently i am try
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-24 18:53 ---
This is a translation bug:
msgid "Cannot assign to variable '%s' in PURE procedure at %L"
msgstr "In PURE-Prozedur bei %L kann nicht an Variable »%s« zugewiesen werden"
As %L / %s is reverted, gfortran crashes.
Sol
--- Comment #1 from jb at gcc dot gnu dot org 2007-07-24 19:06 ---
Confirmed. Also, st_sprintf could be directly replaced by s(n)printf.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from pbrook at gcc dot gnu dot org 2007-07-24 19:11 ---
You can use -mpreferred-stack-boundary=2 to disable this feature if you know
you're never going to need the additional stack alignment.
The compiler has know way of knowing whet the rest of your application does, so
--- Comment #8 from pault at gcc dot gnu dot org 2007-07-24 19:15 ---
Subject: Bug 31205
Author: pault
Date: Tue Jul 24 19:15:27 2007
New Revision: 126885
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126885
Log:
2007-07-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/31
--- Comment #4 from pault at gcc dot gnu dot org 2007-07-24 19:15 ---
Subject: Bug 32842
Author: pault
Date: Tue Jul 24 19:15:27 2007
New Revision: 126885
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126885
Log:
2007-07-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/31
--- Comment #5 from pault at gcc dot gnu dot org 2007-07-24 19:16 ---
Subject: Bug 32842
Author: pault
Date: Tue Jul 24 19:16:36 2007
New Revision: 126886
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126886
Log:
2007-07-24 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/31
1 - 100 of 139 matches
Mail list logo
