--- Comment #4 from jb at gcc dot gnu dot org 2005-11-16 06:53 ---
Right. I think I know how to fix this bug, and it shouldn't be too hard.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #16 from tedoc2000 at gmail dot com 2005-11-16 02:10 ---
Okay.. So it turns out that having my version of libiconv.a in
/opt/OPSWbuildtools/1.0.1/lib causes the problem.
I compiled it --enable-static --disable-dynamic with gcc 3.3.2..
Seeing if not doing that helps.
As I men
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-16 02:07
---
This almost need to go to the standards committee for how to deal with this
(and maybe instead the IA64 ABI mailing list as we just follow that ABI for
C++).
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from aldyh at gcc dot gnu dot org 2005-11-16 02:01 ---
I'll take a look at this.
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #11 from mronell at alumni dot upenn dot edu 2005-11-16 02:01
---
If placement using new into shared memory allows process independent memory
referencing, other software tools (including allocators) can be developed.
This request asks, can placement into shared memory b
--- Comment #4 from sabre at nondot dot org 2005-11-16 01:47 ---
> Without more information, this bug
> does not contain much information
I listed three specific areas that can be improved. If you'd like me to close
this and open 3 bugs I can. In addition there are many other places t
--- Comment #15 from reichelt at gcc dot gnu dot org 2005-11-16 01:24
---
Taking care of the backport to the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #15 from ian at airs dot com 2005-11-16 01:09 ---
Does it bother us that legal ISO C programs are not permitted to say &a[-1]?
You are permitted to take the address of the element immediately after the
array, but you aren't permitted to take the address of the element before
--- Comment #16 from amodra at bigpond dot net dot au 2005-11-16 01:05
---
Fixed mainline and 4.0
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
--- Comment #15 from amodra at gcc dot gnu dot org 2005-11-16 01:04 ---
Subject: Bug 23392
Author: amodra
Date: Wed Nov 16 01:03:58 2005
New Revision: 107060
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107060
Log:
PR rtl-optimization/23392
* regrename.c (enum
--- Comment #14 from amodra at gcc dot gnu dot org 2005-11-16 00:22 ---
Subject: Bug 23392
Author: amodra
Date: Wed Nov 16 00:22:15 2005
New Revision: 107059
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107059
Log:
PR rtl-optimization/23392
* regrename.c (enum
Following code should print the runtime error, shouldn't it? This test is taken
from http://ftp.cac.psu.edu/pub/ger/fortran/test
$ cat test.f90
subroutine foo(y)
character(len=20) :: y
y = 'hello world'
end
program test
character(len=10) ::
--- Comment #1 from steven at gcc dot gnu dot org 2005-11-15 23:58 ---
There is no way we can diagnose this.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mrs at apple dot com 2005-11-15 23:56 ---
radr://4329536
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9726
Following code fails to report the runtime error. The program goes into
infinite loop.
$ cat test.f90
program modify_by_include
implicit none
integer i
do i = 1, 10
call dangerous_inclusion
write(*,'(a,i0)') ' i = ', i
end do
contains
subroutine dangerous_inclusi
--- Comment #1 from steven at gcc dot gnu dot org 2005-11-15 23:15 ---
Show me one compiler that catches this. HP doesn't, and Intel doesn't.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from pcarlini at suse dot de 2005-11-15 22:38 ---
To be sure we don't confuse two issues here (see also my #7), all the
containers
are already able to use shared memory allocators such as libmm:
http://www.ossp.org/pkg/lib/mm/
(via a very lightweight wrapper). This is
--- Comment #4 from dje at gcc dot gnu dot org 2005-11-15 22:27 ---
Patch
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc
--- Comment #20 from pcarlini at suse dot de 2005-11-15 22:16 ---
About the optimization issue, maybe we should file a separate enhancement PR,
if there isn't already one. Really, we should be able to optimize well any
variant of this kind of code.
--
http://gcc.gnu.org/bugzilla/sho
This test is taken from
http://ftp.cac.psu.edu/pub/ger/fortran/test/
$ cat test.f90
MODULE all_sub
PRIVATE
PUBLIC :: test1,test2
CONTAINS
SUBROUTINE test1(a,n)
IMPLICIT NONE
INTEGER,INTENT(in) :: n
REAL,INTENT(out), DIMENSION(n) :: a
REAL :: b
WRITE(*,*) 'Problem with inte
--- Comment #9 from et at ihear dot com 2005-11-15 22:10 ---
This cripples virtual inheritance for fine-grain parallel processing. There
should at least be a compiler option for process-independent referencing,
because admittedly, this would slow down dereferencing. Or maybe a operator n
--- Comment #19 from mmitchel at gcc dot gnu dot org 2005-11-15 22:10
---
There are only two choices: either __imag__ is an lvalue, and the code in
Comment #1 is valid, or __imag__ is not an lvalue, and the compiler should
issue an error.
Nobody wants to see a warning about an uninitia
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-15 22:03 ---
Created an attachment (id=10245)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10245&action=view)
reduced testcase
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24883
/usr/lib/gcc/s390-suse-linux/4.1.0/cc1 -fpreprocessed reo.i -quiet -dumpbase
reo.i -m31 -mesa -march=g5 -ansi -auxbase reo -O2 -Wall -Wpointer-arith
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wredundant-decls -Wnested-externs -Wundef -ansi -version -fomit-frame-pointer
-fno-st
--- Comment #18 from pcarlini at suse dot de 2005-11-15 22:00 ---
(In reply to comment #16)
> Here is the current patch so for libstdc++ (I did not test it yet):
Before patching this and that in the runtime library, don't you believe that:
1- If, as Mark said, (__imag__ t) is an lvalue,
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-11-15 21:57
---
(In reply to comment #13)
> It's nice to see that PR bouncing between you all. Although I don't know
> anything about C++, I want to add my non-constructive comment to this
> discussion: I don't understand how a bu
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-15 21:51
---
Here is the current patch so for libstdc++ (I did not test it yet):
Index: include/std/std_complex.h
===
--- include/std/std_complex.h (revision 106
--- Comment #9 from dnovillo at gcc dot gnu dot org 2005-11-15 21:50
---
(In reply to comment #8)
> Will take a look shortly.
>
I stand by my analysis in #5. The Fortran FE is lying to the middle end.
There is no field 'ktbuf' in this structure.
--
dnovillo at gcc dot gnu dot org
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu
2005-11-15 21:49 ---
Subject: Re: [gfortran, 4.1.0 regression] Arithmetic overflow during
compilation
> Comment #5 from martin
> ~/tmp>gfortran -c -fdump-parse-tree huge.f90
>
>Namespace: A-Z: (UNKNOWN 0)
>procedure
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-15 21:42
---
(In reply to comment #14)
> There is nothing wrong with the code in Comment #1; __imag__ is an
> lvalue-yielding operator. If, for some reason, we wanted to make __imag__
> yield an rvalue, then this code would be
--- Comment #15 from tedoc2000 at gmail dot com 2005-11-15 21:27 ---
Okay so it wasn't the --with-local-prefix.
It was the fact that I used --prefix=/opt/OPSWbuildtools/1.0.1.
If I use a directory that doesn't already exist then I get my desired results.
So that makes us ask. "Well what
--- Comment #5 from martin at mpa-garching dot mpg dot de 2005-11-15 21:16
---
~/tmp>gfortran -c -fdump-parse-tree huge.f90
Namespace: A-Z: (UNKNOWN 0)
procedure name = mod1
symtree: gndp_max Ambig 0
symbol gndp_max (REAL 8)(PARAMETER UNKNOWN-INTENT UNK
--- Comment #4 from martin at mpa-garching dot mpg dot de 2005-11-15 21:09
---
> The code works for me on amd64-*-freebsd. Can
> you compile the failing code with -fdump-parse-tree
> and post both mod1.mod and the parse-tree?
Will do tomorrow.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #3 from martin at mpa-garching dot mpg dot de 2005-11-15 21:09
---
(In reply to comment #2)
> It fails on powerpc64-linux with both -m32 and -m64 for current trunk,
> 4.0 branch, and GCC 4.0.0. Since it's Fortran 90 code it's not really
> a regression.
Well, it worked for
--- Comment #5 from pcarlini at suse dot de 2005-11-15 21:07 ---
This PR can now be closed, basing on up to date comments from John David Anglin
([EMAIL PROTECTED]), which indicate that now shared versions of libgcc
are
built on both 32 and 64-bit ports. He also remarks that "it's techni
--
pcarlini at suse dot de changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24882
This meta-bug tracks work on a new, ABI-breaking, basic_string implementation.
Currently, we have refactored code in v7-branch which includes two alternative
base classes: one doesn't use reference counting, is optimized for short
strings and includes (simulated) move constructor and assignment ope
--- Comment #9 from drow at gcc dot gnu dot org 2005-11-15 20:58 ---
Subject: Re: [4.1 regression] invalid register in debug info
On Thu, Oct 20, 2005 at 08:35:59AM -, rth at gcc dot gnu dot org wrote:
> Well, the ideal fix is to make use of the dwarf3 DW_OP_call_frame_cfa
> direct
This is to track this proposal for enhancement:
http://gcc.gnu.org/ml/libstdc++/2005-11/msg00184.html
--
Summary: Lazy facet instantiation
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
--- Comment #3 from amodra at bigpond dot net dot au 2005-11-15 20:35
---
Fixed mainline.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
St
--- Comment #2 from amodra at gcc dot gnu dot org 2005-11-15 20:33 ---
Subject: Bug 24096
Author: amodra
Date: Tue Nov 15 20:33:48 2005
New Revision: 107041
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107041
Log:
PR fortran/24096
* trans-types.c (gfc_init_kind
--- Comment #2 from laurent at guerby dot net 2005-11-15 20:22 ---
Confirmed on x86_64-linux and x86-linux. On x86 svn 4.0.3 and 4.1 gnat1 grows
memory above 1GB and I had to kill the processes. 3.3.5 does not have the
issue. On x86_64 gnat1 segfault immediately.
--
laurent at guerby
--- Comment #2 from janis at gcc dot gnu dot org 2005-11-15 20:16 ---
It fails on powerpc64-linux with both -m32 and -m64 for current trunk,
4.0 branch, and GCC 4.0.0. Since it's Fortran 90 code it's not really
a regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24875
--- Comment #1 from kargl at gcc dot gnu dot org 2005-11-15 20:11 ---
The code works for me on amd64-*-freebsd. Can
you compile the failing code with -fdump-parse-tree
and post both mod1.mod and the parse-tree?
--
kargl at gcc dot gnu dot org changed:
What|Removed
Explicit conversion from a numeric integer Type to Integer causes a crash of
gcc
when the type is defined with a Size representation clause.
The bug disappears if the representation clause is removed or
if the range begins with 0.
Environment:
System: Linux simone 2.6.12.051101 #1 Tue Nov 1 17:19
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-15 19:45 ---
Confirmed, but minor since a lot of the other fortran implemenations don't
detect it either.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janis at gcc dot gnu dot org 2005-11-15 19:34 ---
A regression hunt identified the following patch from Janne Blomqvist:
http://gcc.gnu.org/viewcvs?view=rev&rev=104662
r104662 | bdavis | 2005-09-26 20:24:45 + (Mon, 26 Sep 2005) | 28 lines
--
janis at gcc dot
--- Comment #25 from olle at cb dot uu dot se 2005-11-15 19:27 ---
(In reply to comment #24)
Seems that the basic difference between the working case (the preliminary
work around) and the final fix is that
in the working case there are two occasions of "-L./" in the linking command
in
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-15 19:24 ---
(define_insn "sse3_mwait"
[(unspec_volatile [(match_operand:SI 0 "register_operand" "a")
(match_operand:SI 1 "register_operand" "c")]
UNSPECV_MWAIT)]
"TARGET_SSE3"
"mwai
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-11-15 19:23
---
There is nothing wrong with the code in Comment #1; __imag__ is an
lvalue-yielding operator. If, for some reason, we wanted to make __imag__
yield an rvalue, then this code would be rejected with an error; under
--- Comment #16 from reichelt at gcc dot gnu dot org 2005-11-15 19:19
---
Now also fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #18 from reichelt at gcc dot gnu dot org 2005-11-15 19:18
---
Now also fixed on the 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-15 19:17 ---
Confirmed and not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from daney at gcc dot gnu dot org 2005-11-15 19:16 ---
Fixed by committed patch.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from reichelt at gcc dot gnu dot org 2005-11-15 19:14
---
Subject: Bug 19253
Author: reichelt
Date: Tue Nov 15 19:14:21 2005
New Revision: 107037
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107037
Log:
PR c++/19253
PR c++/22172
Backpor
--- Comment #17 from reichelt at gcc dot gnu dot org 2005-11-15 19:14
---
Subject: Bug 22172
Author: reichelt
Date: Tue Nov 15 19:14:21 2005
New Revision: 107037
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107037
Log:
PR c++/19253
PR c++/22172
Backpor
It seems that SSE3 _mm_monitor instrinsic doesn't work too well with
64bit.
[EMAIL PROTECTED] function]$ cat x.c
#include
#include
static void
foo (char *p)
{
_mm_monitor(p, 0, 0);
}
main()
{
char *p = (char *)&foo;
int fail = 1;
int i;
for (i = 0; i < 20; i++) {
if
--- Comment #9 from daney at gcc dot gnu dot org 2005-11-15 19:11 ---
Subject: Bug 15430
Author: daney
Date: Tue Nov 15 19:11:53 2005
New Revision: 107036
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107036
Log:
PR libgcj/15430
* gnu/java/net/natPlainSocketImpl
This test is taken from, http://ftp.cac.psu.edu/pub/ger/fortran/test/test10.for
$ cat test.f90
INTEGER X, Y, SUBA
EXTERNAL SUBA
X=-1
Y=-2
CALL ANY(SUBA,X,Y)
WRITE(*,*)'Did NOT catch this error'
PAUSE
STOP
END
SUBROUTIN
--- Comment #28 from uweigand at gcc dot gnu dot org 2005-11-15 18:31
---
Just one additional comment: the patch from comment #10 was rejected,
maybe because it required changes to the core gimplifier.
However, I've tested just the Ada front-end pieces from that patch,
and this *alread
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-11-15 17:57
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-11-15 17:52
---
Subject: Bug 24667
Author: mmitchel
Date: Tue Nov 15 17:52:34 2005
New Revision: 107032
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107032
Log:
PR c++/24667
* typeck.c (check_for_casting
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-11-15 17:50
---
Subject: Bug 24667
Author: mmitchel
Date: Tue Nov 15 17:50:43 2005
New Revision: 107031
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107031
Log:
PR c++/24667
* typeck.c (check_for_casting
--- Comment #11 from mmitchel at gcc dot gnu dot org 2005-11-15 17:44
---
Subject: Bug 24687
Author: mmitchel
Date: Tue Nov 15 17:44:28 2005
New Revision: 107030
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107030
Log:
PR c++/24687
* g++.dg/template/crash43.C:
--- Comment #24 from olle at cb dot uu dot se 2005-11-15 17:27 ---
(In reply to comment #20)
> Could people check if the problem was indeed fixed where reported?
I did try the new suggested fix on tru64 5.1B on an Alpha. It gets past the
previous error pointb ut it fails later on while
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2005-11-15 16:55
---
It's nice to see that PR bouncing between you all. Although I don't know
anything about C++, I want to add my non-constructive comment to this
discussion: I don't understand how a bug which has a C-only testcase
--- Comment #5 from krebbel at gcc dot gnu dot org 2005-11-15 16:47 ---
The only difference my patch brought is different behaviour
of mark_set_1 if it is called under wrong! conditions. Will
say that only in case somebody calls mark_set_1 clobbering a reg which
is live afterwards - we
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-15 16:47
---
(In reply to comment #9)
> Certainly, the test-case in Comment #1 does depend on libstdc++ at all.
> Let's fix this.
The testcase in comment #1 shows the issue with what libstdc++ is doing. Since
complex is sca
--- Comment #11 from pcarlini at suse dot de 2005-11-15 16:39 ---
(In reply to comment #10)
> And my comment in #6 still holds for this bug. I think libstdc++ should
> rethink about this.
libstdc++ can rething anything, in principle, but if you change the component
to libstdc++, nobody
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-15 16:31
---
Hold on, in C99, complex is a scaler type so libstdc++ is using a GCC extension
over what C99 requires which causes this.
And my comment in #6 still holds for this bug. I think libstdc++ should
rethink about this
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-15 16:24 ---
The orginal testcase was fixed for 4.0.0 by:
2005-01-23 Steven Bosscher <[EMAIL PROTECTED]>
PR rtl-optimization/19464
* tree-optimize.c (init_tree_optimization_passes): Add one more
copyren
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-15 16:19 ---
(In reply to comment #1)
> "1000" is a signed integer constant, so b*1000 is a signed integer too. I
> guess the warning is ok, then.
That is only true for unsigned multiplication and signed when overflow is
undefin
--- Comment #5 from trt at acm dot org 2005-11-15 15:43 ---
Since fold() is increasingly used for internal speculative computations, I
think it should avoid issuing warnings as false positives are too likely. So
perhaps this warning belongs in parser_build_binary_op() in c-typeck.c
Sim
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-15 15:38
---
(In reply to comment #13)
> (In reply to comment #12)
> > specify --with-local-prefix=/opt/OPSWbuildtools/1.0.1
> > Am I missing something?
> Yes it sounds like it is picking up the wrong header otherwise.
s/heade
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-15 15:38
---
(In reply to comment #12)
> specify --with-local-prefix=/opt/OPSWbuildtools/1.0.1
> Am I missing something?
Yes it sounds like it is picking up the wrong header otherwise.
--
pinskia at gcc dot gnu dot org cha
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-15 15:22 ---
I think this is a dup of bug 24569 which was fixed for 4.0.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24874
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-15 15:15 ---
*** Bug 24870 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-15 15:15 ---
*** This bug has been marked as a duplicate of 23400 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #15 from rakdver at gcc dot gnu dot org 2005-11-15 14:27
---
Subject: Bug 24762
Author: rakdver
Date: Tue Nov 15 14:27:48 2005
New Revision: 107017
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107017
Log:
PR rtl-optimization/24762
* except.c (dw2_b
--- Comment #4 from charlet at gcc dot gnu dot org 2005-11-15 14:10 ---
Fixed.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from charlet at gcc dot gnu dot org 2005-11-15 14:09 ---
Fixed.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #23 from charlet at gcc dot gnu dot org 2005-11-15 14:08
---
Fixed.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
Status|W
--- Comment #3 from charlet at gcc dot gnu dot org 2005-11-15 14:04 ---
Subject: Bug 15604
Author: charlet
Date: Tue Nov 15 14:03:56 2005
New Revision: 107006
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107006
Log:
2005-11-14 Ed Schonberg <[EMAIL PROTECTED]>
Jav
--- Comment #8 from charlet at gcc dot gnu dot org 2005-11-15 13:59 ---
Subject: Bug 23732
Author: charlet
Date: Tue Nov 15 13:59:02 2005
New Revision: 106980
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106980
Log:
PR ada/23732
* gnatvsn.ads (Library_Version):
--- Comment #22 from charlet at gcc dot gnu dot org 2005-11-15 13:51
---
Subject: Bug 18434
Author: charlet
Date: Tue Nov 15 13:51:09 2005
New Revision: 106950
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106950
Log:
2005-11-14 Robert Dewar <[EMAIL PROTECTED]>
E
--
uros at kss-loka dot si changed:
What|Removed |Added
CC|uros at kss-loka dot si |
AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si
ata/martin/mygmp
Thread model: posix
gcc version 4.1.0 20051115 (experimental)
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.1.0/f951 huge.f90
-quiet -dumpbase huge.f90 -mtune=pentiumpro -auxbase huge -version -o
/tmp/ccjkyE0d.s
GNU F95 version 4.1.0 20051115 (experimental) (i686-pc-li
--- Comment #1 from christof at petig-baender dot de 2005-11-15 12:53
---
Created an attachment (id=10243)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10243&action=view)
the failing program (ManuProcEntity.ii.gz)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24874
--- Comment #3 from steven at gcc dot gnu dot org 2005-11-15 12:53 ---
Note that we would still like to know what target you are configuring for. If
you can copy-and-paste the first, say, 10 lines of output from your configure,
that would be most helpful.
--
steven at gcc dot gnu do
--- Comment #2 from steven at gcc dot gnu dot org 2005-11-15 12:51 ---
As a work-around, configure with --disable-libmudflap, you don't need that
library anyway, it is an instrumentation library for memory access violations
for C and C++, so you don't need it for gfortran.
--
steven
g++ -g ManuProcEntity.ii
ManuProcEntity.cc:35: internal compiler error: in add_AT_specification, at
dwarf2out.c:4903
omitting -g makes the compilation work.
--
Summary: ICE: in add_AT_specification, at dwarf2out.c:4903
Product: gcc
Version: 4.0.2
St
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2005-11-15 12:31
---
(In reply to comment #6)
> The two attached files will change the behavior so that included files are
> processed as described in comment #2. I have not checked the results
> extensively.
You should really attach
--- Comment #5 from pcarlini at suse dot de 2005-11-15 12:31 ---
(In reply to comment #4)
> Unfortunately I cannot perform such test because it would require changing
> stdlibc++ on many machines.
Out of curiosity: why many and not just one (and optionally, of course, along
the existing
--- Comment #4 from l_heldt at poczta dot onet dot pl 2005-11-15 12:26
---
Unfortunately I cannot perform such test because it would require changing
stdlibc++ on many machines.
My solution to this problem is setting GLIBCXX_FORCE_NEW variable before
starting application.
--
http:
--- Comment #3 from steven at gcc dot gnu dot org 2005-11-15 12:20 ---
It would be useful to to either have separate bugs for these issues, or to list
them all in the audit trail of this bug. Without more information, this bug
does not contain much information, it's more like an FYI ins
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2005-11-15 12:14
---
(In reply to comment #7)
> We should bump the library file's version number.
Could we get a gcc-admin script to change the library's version everyday with
version numbers like 0.0.20051115 and so on?
--
http
--- Comment #3 from pcarlini at suse dot de 2005-11-15 12:02 ---
> 2- Otherwise, a lock in _M_reclaim_block only when __block->_M_thread_id !=
>__thread_id. At the same time has to be changed _M_reserve_block too,
>however, and it's tricky to do that without locking at every sing
--- Comment #7 from debian-gcc at lists dot debian dot org 2005-11-15
11:42 ---
PR23750 is related
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23732
--- Comment #6 from charlet at adacore dot com 2005-11-15 11:22 ---
Subject: Re: [ada] Library_Version still at 4.0 ?
> what about soext in gcc41/gcc/ada/Makefile.in?
> there is still soext = .so
> is ada abi compatible in gcc 3.3 ... 4.1 ?
You seem to be confused: soext is about the
--- Comment #5 from pluto at agmk dot net 2005-11-15 11:16 ---
what about soext in gcc41/gcc/ada/Makefile.in?
there is still soext = .so
is ada abi compatible in gcc 3.3 ... 4.1 ?
--
pluto at agmk dot net changed:
What|Removed |Added
-
1 - 100 of 114 matches
Mail list logo
