--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-05-11 06:08
---
(In reply to comment #7)
> FX: Fixing gfortran's error recovery is not the answer to this PR,
> but to the other one.
Yes, I know. Since this PR was already used for tracking the ICE, I planned on
opening a new P
Reported by Harald Anlauf:
---
Hi,
the IMPORT statement of Fortran2003 is not yet implemented.
Trying to use it provokes an ICE:
module gfcbug29_import
integer, parameter :: dp = kind (1d0)
interface
subroutine foo (x)
import :: dp
real (kind=dp) ::
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-05-11 05:39
---
> I can disable section anchors for Ada, similar to Objective C and Objective
> C++, but this failure likely means that there is a bug in the Trees generated
> by GNU Ada.
It's only a wild guess until someone fir
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-11 02:58 ---
This is a bug in libtool, look here:
/bin/sh ../libtool --tag=CC --mode=link gcc -pthread
-I/opt/gnome/include/glib-2.0 -I/opt/gnome/lib/glib-2.0/include -Wall -O2 -g
-Wall -fprofile-generate -o libflow.la -rpath
--- Comment #4 from hpj at copyleft dot no 2006-05-11 02:53 ---
Created an attachment (id=11437)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11437&action=view)
Build with -fprofile (breaks).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27545
--- Comment #3 from hpj at copyleft dot no 2006-05-11 02:53 ---
Created an attachment (id=11436)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11436&action=view)
Build without -fprofile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27545
--- Comment #2 from hpj at copyleft dot no 2006-05-11 02:52 ---
Yes, it's building with -fPIC and building/linking with -fprofile-generate.
Without -fprofile-generate, it all builds fine. I'm using libtool. I'm
attaching logs of builds with and without -fprofile-generate so you have all
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-11 02:43 ---
Can you make sure that the library is still building with -fPIC, if it is not,
then this is not a bug.
And can you make sure that the library is linking with -fprofile-generate, if
it is not, then this is not a bug.
I'm working on a shared library, and would like to build it with
-fprofile-generate information generated from tests that are built with the
library, so I can apply it with -fprofile-use. However, when I build the
library with CFLAGS='-O2 -g -fprofile-generate', it fails to link the tests
with the
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-11 02:16 ---
PR 27544 is about a missing docs for an attribute for RS6000, altivec.
PR 27543 is about ms_struct attribute on rs6000/PowerPC as it just says x86
supports it which is no longer true.
--
pinskia at gcc dot gnu do
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27544
It was added by:
http://gcc.gnu.org/ml/gcc-patches/2004-01/msg0.html
But it was not documented. Zem no longer works at Apple now either.
--
Summary: [4.0/4.1/4.2 Regression] attribute altivec is not
documented
Product: gcc
Version: 4.2.0
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27543
According to:
http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html#Type-Attributes
ms_struct is now support for also for the RS6000 back-end.
--
Summary: [4.2 Regression] attribute ms_struct is now also for
rs6000 but not documented
Product: gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27542
When the ms_struct pragma was implemented, Documention was not added for it.
--
Summary: [4.2 Regression] the ms_struct pragma is not documented
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: documentation
Severity: norm
--- Comment #12 from sje at cup dot hp dot com 2006-05-10 22:54 ---
I believe the patch checked in for this defect is causing
g++.old-deja/g++.other/static14.C and
g++.old-deja/g++.other/static20.C to fail.
--
sje at cup dot hp dot com changed:
What|Removed
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-05-10 22:46 ---
> Is there really a standard for this or just an extension of OpenMP?
I'm not sure whether I understand the question.
Directive wise it is OpenMP augmented by a single directive: "shareable".
This
--- Comment #12 from pluto at agmk dot net 2006-05-10 22:36 ---
following reduced testcase works with libstdc++ and segv with stlport.
#include
#include
struct A { };
int main()
{
std::list< A* > l;
std::vector< A* > v( l.end(), l.end() );
return 0;
}
g++ test
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 22:09 ---
Is there really a standard for this or just an extension of OpenMP?
Though this is useful a little bit for the Cell where you don't really have a
distrubuted machine but the memory will be distributed though.
--
Currently, GCC only supports OpenMP on shared-memory systems.
It would be nice if it could be extended to support OpenMP via the ethernet,
infiniband etc. (distributed-memory systems).
There exists (at least) one implementation of distributed-memory OpenMP: The
Intel Compilers 9.1's Cluster OpenMP
--- Comment #7 from anlauf at gmx dot de 2006-05-10 21:53 ---
(In reply to comment #5)
> *** Bug 27487 has been marked as a duplicate of this bug. ***
Well, first of all I have to admit that I am only a Fortran user.
But PR 27487 is only a duplicate because Tobias changed the
subject of
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-05-10 21:43
---
Now, this is "fixed" at the moment (but still invalid code), but I have a "fix"
that will "break" it again.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-10 21:36
---
Below is a patch for this ICE. I suspect that there a lots more ICEs lurking in
dump-parse-tree.c, which looks like it's not really written to be fed with
incomplete structures (as might happen during error recove
--- Comment #1 from dje at gcc dot gnu dot org 2006-05-10 21:33 ---
I can disable section anchors for Ada, similar to Objective C and Objective
C++, but this failure likely means that there is a bug in the Trees generated
by GNU Ada.
--
dje at gcc dot gnu dot org changed:
--- Comment #6 from patchapp at dberlin dot org 2006-05-10 21:31 ---
Subject: Bug number PR c++/27315
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/2006-05/msg00361.html
--
http://gcc.gnu.org/bugzil
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2006-05-10
21:28 ---
Subject: Re: [4.2 Regression] libgomp bootstrap failure on Tru64 UNIX V4.0F
pinskia at gcc dot gnu dot org writes:
> PR 26161 might had fixed this.
No, the problem persists as of 20060503.
Raine
Current mainline fails to bootstrap on IRIX 5.3:
configure: error: Pthreads are required to build libgomp
make[1]: *** [configure-target-libgomp] Error 1
Environment:
System: IRIX lyra 5.3 11091812 IP22 mips
host: mips-sgi-irix5.3
build: mips-sgi-irix5.3
target: mips-sgi-irix5.3
configured wi
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-10 20:49 ---
This is confirmed, this is an interaction between stack slots and
-mpreferred-stack-boundary= which is what -Os sets. This is not a regression.
Maybe the real question is why are you using -Os for code with SSE in
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-10 20:44 ---
The SYSV x86 ABI says the stack is aligned 4 byte aligned. Remember the SYSV
x86 ABI was done before MMX or SSE was around or even thought about back in the
486 days (and maybe even before then).
--
http://gcc.
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-05-10 20:41 ---
This has nothing to do with the C standard or even standard code. This is
inline-asm constraint which is failing and the inline-asm in the code is wrong.
This is a bug in the code so report it to Linux instead of h
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 20:39 ---
First so what darwin aligns the stack by default to 16bytes (that is demanded
by their ABI since their ABI is newer than GNU/Linux's). GNU/Linux follows the
SYSV x86 ABI which is documented, maybe you cannot find it
--- Comment #8 from malitzke at metronets dot com 2006-05-10 20:17 ---
Well Fellas: Either have the Steering Committee revise the
Invitation to participate in testing; quoted iselectively below.
Or,have a member from the Steering Committe ask me to refrain
from further participation. I,
--- Comment #10 from flash at pobox dot com 2006-05-10 20:08 ---
PalmSource bug #126750.
--
flash at pobox dot com changed:
What|Removed |Added
CC|
FAIL: gcc.c-torture/execute/941014-2.c execution, -O1
FAIL: gcc.c-torture/execute/941014-2.c execution, -O2
FAIL: gcc.c-torture/execute/941014-2.c execution, -Os
--
Summary: gcc.c-torture/execute/941014-2.c FAILs
Product: gcc
Version: unknown
Statu
FAIL: gcc.c-torture/execute/20030128-1.c execution, -O1
FAIL: gcc.c-torture/execute/20030128-1.c execution, -O2
FAIL: gcc.c-torture/execute/20030128-1.c execution, -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/20030128-1.c execution, -O3 -g
FAIL: gcc.c-torture/execute/20030128-1.c execut
The g++ compiler for i386 target assumes that the stack is aligned by 16 when
storing xmm registers to the stack. However, the stack is not aligned when
compiling with option -Os (or with the Intel compiler). A misaligned memory
operand to an XMM instruction causes a general protection exception. A
$ /tmp/cvs/gcc-test-r113398/Build/./gcc/xgcc
-B/tmp/cvs/gcc-test-r113398/Build/./gcc/
-B/tmp/cvs/gcc-test-r113398/Build/root/powerpc64-suse-linux/bin/
-B/tmp/cvs/gcc-test-r113398/Build/root/powerpc64-suse-linux/lib/ -isystem
/tmp/cvs/gcc-test-r113398/Build/root/powerpc64-suse-linux/include -isystem
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-05-10 19:42 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-05-10 19:41 ---
Subject: Bug 27532
Author: rguenth
Date: Wed May 10 19:41:46 2006
New Revision: 113682
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113682
Log:
2006-05-10 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 19:06 ---
Oh, this is no longer a regression as -fsee is not enabled by default in newer
versions of 4.2 (a day after it was enabled by default for -O3, it was turned
off to fix some regressions at -O3).
--
pinskia at gcc
/*
ICE using gcc-4.2-20060506 on x86_64-unknown-linux-gnu
Regression from gcc-4.1.0
Source cut down from gmp-4.2.1/tests/refmpf.c
% gcc-4.2-20060506 -O3 -c foo.c
foo.c: In function âfooâ:
foo.c:27: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed so
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-05-10 18:27 ---
Subject: Bug 27470
Author: tkoenig
Date: Wed May 10 18:26:51 2006
New Revision: 113680
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113680
Log:
2005-05-10 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--- Comment #29 from pinskia at gcc dot gnu dot org 2006-05-10 17:48
---
Since Honza's patch to emit static and inline functions at -O0, this now fails
with BOOTCFLAGS as -O0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from aph at gcc dot gnu dot org 2006-05-10 17:41 ---
Xref: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191211
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12257
--- Comment #2 from kazu at gcc dot gnu dot org 2006-05-10 17:35 ---
Just checked in a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #1 from kazu at gcc dot gnu dot org 2006-05-10 17:35 ---
Subject: Bug 24949
Author: kazu
Date: Wed May 10 17:35:24 2006
New Revision: 113675
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113675
Log:
PR target/24949
* config/m68k/m68k.md (ashrdi_const
--- Comment #1 from kazu at gcc dot gnu dot org 2006-05-10 17:00 ---
Could you submit a preprocessed testcase?
Many of us do not have m68k hardware that can be used for bootstrap.
Thanks,
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-10 16:55
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-10 16:52
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #4 from kazu at gcc dot gnu dot org 2006-05-10 16:49 ---
Assigning to Volker as he posted a patch.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janis at gcc dot gnu dot org 2006-05-10 16:03 ---
The test passes on both of my nightly builds now, so I'm closing this.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from ksharenkov at ya dot ru 2006-05-10 15:58 ---
I have tried to create simple test case (about 200 rows) where I tried to
reproduce key code fragments. In simple test case leak not reproduced. But I
have easy reproduced it with very small application based on main projec
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 15:47 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-05-10 15:46
---
*** Bug 27534 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-10 15:46 ---
It is an object type. An array is an object type.
*** This bug has been marked as a duplicate of 14557 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Attempting to pass a pointer to a va_list variable to a function expecting such
a pointer causes a warning about passing a pointer of incompatible type.
[EMAIL PROTECTED] ~/work/ffdev $ gcc -v -save-temps -ansi -pedantic -Wall -W -O
-c t.c
Reading specs from /usr/lib/gcc/powerpc-unknown-linux-gnu
--- Comment #5 from pluto at agmk dot net 2006-05-10 15:26 ---
(In reply to comment #0)
> The code
>
> inline int almost_equal(float a, float b, int maxUlps = 16) {
> int intDiff = *(reinterpret_cast(&a)) -
> *(reinterpret_cast(&b));
if you really need such castin
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||link-failure
Target Milestone|--- |4.2.0
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-10 15:10 ---
Just to explain why "&"a"[0] + 2B" is valid gimple:
&"a"[0] is a gimple invariant and likewise for 2b. Therefor the two sides of
the Plus expression are going to valid for it. Therefor valid gimple.
--
http://g
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-10 15:06 ---
(In reply to comment #5)
> To A Pinski
> While I am _not_ a C lawyer, the following seems pertinent:
Why do you think this is related to the C standard?
>
> 1 __FUNCTION__ is _not_ a predefined macro. However __fu
--- Comment #6 from kazu at gcc dot gnu dot org 2006-05-10 15:00 ---
The combiner seems to be doing something strange:
(insn 13 12 16 2 (set (reg:HI 21)
(eq:HI (cc0)
(const_int 0 [0x0]))) 237 {*bstzhireg} (nil)
(nil))
(insn 16 13 17 2 (set (cc0)
(reg:HI
--- Comment #96 from reichelt at gcc dot gnu dot org 2006-05-10 14:59
---
*** Bug 27533 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-10 14:59
---
As Pawel already pointed out:
Your code is brokan as you are violating the aliasing rules.
Please read about this in the non-bug section of http://gcc.gnu.org/bugs.html :
"Casting does not work as expected when op
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:58
---
Subject: Bug 20460
Author: fxcoudert
Date: Wed May 10 14:58:48 2006
New Revision: 113672
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113672
Log:
PR fortran/20460
* resolve.c (gfc_resolv
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-05-10
14:58 ---
(In reply to comment #2)
> Very odd; I do nightly builds of mainline on two different systems. On one of
> them this failure stopped on 20060430 and on the other it stopped on 20060503,
> but failed on 2
--- Comment #6 from dje at gcc dot gnu dot org 2006-05-10 14:56 ---
The section anchors feature does not like "__FUNCTION__" or "__func__" as an
inlined asm argument.
Also, "some rs6000 work" is not very informative or useful.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-05-10 14:56
---
I have a patch that needs PR27529 fixed first, that needs PR27532 fixed first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27039
--- Comment #3 from ulrich dot lauther at siemens dot com 2006-05-10 14:55
---
Created an attachment (id=11435)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11435&action=view)
same as before, but stdio.h expanded
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27533
--- Comment #2 from ulrich dot lauther at siemens dot com 2006-05-10 14:53
---
Created an attachment (id=11434)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11434&action=view)
Complete tiny example exposing the problem
I submit this version that includes stdio.h for readability,
--- Comment #1 from pluto at agmk dot net 2006-05-10 14:51 ---
you're violating the aliasing rules, so use -fno-strict-aliasing option.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27533
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:51
---
Subject: Bug 24549
Author: fxcoudert
Date: Wed May 10 14:51:26 2006
New Revision: 113671
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113671
Log:
PR fortran/24549
* parse.c (reject_state
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-10 14:48 ---
Looks more like a typo in tree-object-size.c:plus_expr_object_size
Index: tree-object-size.c
===
*** tree-object-size.c (revision 113669)
--- tree-obj
The code
inline int almost_equal(float a, float b, int maxUlps = 16) {
int intDiff = *(reinterpret_cast(&a)) -
*(reinterpret_cast(&b));
printf("intDiff %d\n",intDiff);
return intDiff;
}
gives different results when compiled with and without -O2
(yes, floats are involved,
--- Comment #5 from malitzke at metronets dot com 2006-05-10 14:43 ---
To A Pinski
While I am _not_ a C lawyer, the following seems pertinent:
1 __FUNCTION__ is _not_ a predefined macro. However __func__ a predefined
identifier and I will take this up with the kernel people. However, e
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-10 14:37 ---
CCP produces this tree since forever.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:37
---
*** Bug 27487 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-10 14:37
---
This is a duplicate of PR24549 (it's fixed by the same one-line patch).
*** This bug has been marked as a duplicate of 24549 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
Reduced testcase from gcc.dg/builtin-object-size-1.c:
void abort(void);
int main (void)
{
void *b = L"abcd";
if (__builtin_object_size (b + 2, 0) != sizeof (L"abcd") - 2)
abort ();
return 0;
}
now, CCP propagates the "constant" &L"abcd"[0] to the addition stmt:
b_1 = &"a"[0];
D.152
--- Comment #5 from kazu at gcc dot gnu dot org 2006-05-10 14:21 ---
Reduced down to:
extern void bar (int);
int
foo (int a, int b)
{
int c = a == b;
if (c)
bar (c);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27477
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #3 from jjcogliati-r1 at yahoo dot com 2006-05-10 13:54 ---
(In reply to comment #1)
> Confirmed. Though sometimes I wonder if this is an over use of printf style
> debugging.
>
Well, I have a fortran program. It ran fine for the first 10 and a half
hours. Then it died
--- Comment #3 from tbm at cyrius dot com 2006-05-10 13:52 ---
Created an attachment (id=11433)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11433&action=view)
assembler with -O2 (fails) - .LL226 is not defined
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
--- Comment #7 from patchapp at dberlin dot org 2006-05-10 13:52 ---
Subject: Bug number PR25514
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/2006-04/msg00958.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from tbm at cyrius dot com 2006-05-10 13:52 ---
Created an attachment (id=11432)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11432&action=view)
assembler with -O1 (works)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
--- Comment #1 from tbm at cyrius dot com 2006-05-10 13:51 ---
Created an attachment (id=11431)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11431&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
I get a "undefined reference to `.LL226'" error when compiling RCS with -O2 on
sparc using gcc 4.2. This problem goes away when I use -O2. The assembler
output shows that .LL226 is referenced but not defined anywhere. I'll attach
the .i file and the .s file with -O1 (works) and -O2 (fails). Unf
--- Comment #3 from christophe dot gengembre at paris dot ensam dot fr
2006-05-10 13:49 ---
the bug is trigged in Subroutine RecupValLuesDsCmdLC.
A .f source file with only Subroutine RecupValLuesDsCmdLC code trigger the
error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27521
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-05-10
12:59 ---
I think that it is not correct to emit an ICE on this one. The patch below
emits an error and bails out.
I will submit in the next 24hours.
Paul
Index: gcc/fortran/symbol.c
===
--- Comment #3 from ksharenkov at ya dot ru 2006-05-10 12:48 ---
Ok, i will try to create a short program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27530
--- Comment #5 from sebastian dot pop at cri dot ensmp dot fr 2006-05-10
12:32 ---
Created an attachment (id=11430)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11430&action=view)
first shot at fixing this
didn't tested the patch, other than with RUNTESTFLAGS="tree-ssa.exp"
and
--- Comment #3 from sebastian dot pop at cri dot ensmp dot fr 2006-05-10
12:26 ---
Created an attachment (id=11429)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11429&action=view)
fix
proposed fix. I didn't tested it other than making sure it fixed the bug.
--
http://gcc.g
--- Comment #2 from pcarlini at suse dot de 2006-05-10 12:10 ---
Chris is right. Certainly we are not aware of any problem in that code, in
particular the 3.4.5 version, very close to the original HP/SGI code and very
well tested from that point of view (at least). Please provide a self-
--- Comment #1 from P dot Schaffnit at access dot rwth-aachen dot de
2006-05-10 11:34 ---
Sorry, I missed it before, but this could definitly be a dupplicate of 19777.
Philippe
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27524
--- Comment #1 from chris at bubblescope dot net 2006-05-10 11:31 ---
Can you provide a complete program which demonstrates this link? I've tried
looking at the code in question myself, and cannot observe a memory leak
myself.
--
chris at bubblescope dot net changed:
What
Hello.
We have Client/server socket application (multiple clients and servers).
Servers are multiplatform can be compiled for Windows (MSVC) and for Linux
(GCC).
Recently we detected memory leak in one of kinde of our servers. At the start
it uses only 15m (that is normally). Then it slowly grows
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-05-10 11:03 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-10 10:22 ---
Subject: Bug 27302
Author: rguenth
Date: Wed May 10 10:22:39 2006
New Revision: 113670
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113670
Log:
2006-05-10 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #2 from christophe dot gengembre at paris dot ensam dot fr
2006-05-10 08:28 ---
Created an attachment (id=11427)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11427&action=view)
source that triggered the error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27521
1 - 100 of 105 matches
Mail list logo
