--- Comment #2 from charlet at gcc dot gnu dot org 2007-05-04 08:26 ---
Let's assume this is fixed, as per your latest 4.3.0 results
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from charlet at gcc dot gnu dot org 2007-05-04 08:28 ---
Assuming you haven't disabled this test manually, this is fixed as per your
latest test results on 4.3.0
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from charlet at gcc dot gnu dot org 2007-05-04 08:25 ---
>From the test results you posted yesterday on 4.3.0, I assume this is fixed:
<<
=== acats tests ===
FAIL: c37215h
FAIL: cd10002
FAIL: cxh1001
Native configuration is hppa-unknown-linux-gnu
>>
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-04 08:54 ---
Subject: Bug 25071
Author: burnus
Date: Fri May 4 07:54:06 2007
New Revision: 124411
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124411
Log:
2007-05-04 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #5 from burnus at gcc dot gnu dot org 2007-05-04 08:55 ---
Note: Only the string length problem is fixed; the array storage extend still
needs to be fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25071
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-04 08:57 ---
Note: Please uncomment also the two marked lines in
gcc/testsuite/gfortran.dg/char_result_2.f90 when you fix this PR.
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gfortran.dg/char_result_2.f90?r1=124411&r2=124410&p
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-04 09:05 ---
On the mainline I get an ICE:
t.c:20: internal compiler error: in compute_antic, at tree-ssa-pre.c:1968
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #96 from jv244 at cam dot ac dot uk 2007-05-04 09:15 ---
(In reply to comment #91)
> current (i.e. this morning) mainline seems to miscompile CP2K (tested current
> CVS of CP2K).
Current SVN gfortran compiles CP2K again correctly. Closing the bug again
--
jv244 at cam d
gfortran silently trunkates lines which gives syntax errors. Especially in free
format, the truncation is usually not intended. (In fixed format is sometimes
is.)
Other compiles print a warning (such as g95, all options; syntax error
afterwards), give an error (such as NAG f95) or (silently) accep
--- Comment #41 from pcarlini at suse dot de 2007-05-04 09:41 ---
In case it wasn't clear already, many thanks Ian and everyone for fixing this
annoying issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
>From Fortran 95 standard, Annex B, B1: Deleted Features:
"H edit descriptor.
In FORTRAN 77, and for consistency also in Fortran 90, there was an alternative
form of character string edit descriptor, which had been the only such form in
FORTRAN 66; this has been deleted."
Other compiles warn:
NA
--- Comment #1 from charlet at gcc dot gnu dot org 2007-05-04 09:58 ---
Was fixed on 2006-10-31
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from charlet at gcc dot gnu dot org 2007-05-04 10:08 ---
Fixed in 4.3.0
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
Status|U
--- Comment #5 from charlet at gcc dot gnu dot org 2007-05-04 10:13 ---
install.texi would be the place to add this documentation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29157
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-05-04 10:26
---
Subject: Bug 31781
Author: fxcoudert
Date: Fri May 4 09:26:41 2007
New Revision: 124412
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124412
Log:
PR fortran/31781
* simplify.c (gfc_simpl
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-04 10:29
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-04 10:33 ---
Confirmed. Should be easy to work around.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-05-04 10:44
---
(In reply to comment #10)
> Again, I am unable to really test this, but here is a suggestion
This patch fixes the ICE, and I agree it's the right thing to do.
I retested your other patch from scratch (the one t
--- Comment #6 from charlet at gcc dot gnu dot org 2007-05-04 10:55 ---
Fixed on trunk
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
Status|N
--- Comment #1 from charlet at gcc dot gnu dot org 2007-05-04 11:22 ---
Compiles cleanly on trunk
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from charlet at gcc dot gnu dot org 2007-05-04 11:31 ---
Now compiles properly (and generates error message as expected).
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #42 from rguenth at gcc dot gnu dot org 2007-05-04 11:45
---
I put it on the tester. A testcase that does regress (simplified from
tramp3d):
template
class Vector
{
public:
Vector()
{
for (int i = 0; i < D; ++i)
new (&x_m[i]) T();
}
T& operator[](
--- Comment #4 from joseph at codesourcery dot com 2007-05-04 12:00 ---
Subject: Re: gcc segfaults on very long pointer chains
On Fri, 4 May 2007, bangerth at dealii dot org wrote:
> But seriously, while I do think that we should strive to compile even
> programs that are "weird" or "
--- Comment #43 from pcarlini at suse dot de 2007-05-04 12:03 ---
(In reply to comment #42)
> this happens in hot tramp3d loops and is a quite common idiom for initializing
> storage. To fix this we need to avoid creating the asm if the type of the
> original storage is the same as the
--- Comment #44 from pcarlini at suse dot de 2007-05-04 12:07 ---
(In reply to comment #43)
> (By the way, someone should tell the tramp3d developers that using placement
> new for a POD type like double isn't a very smart idea ;) The only tricky
> point
> for default inizialization is
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-05-04 12:10
---
Subject: Bug 31251
Author: fxcoudert
Date: Fri May 4 11:10:06 2007
New Revision: 124415
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124415
Log:
PR fortran/31251
* simplify.c (gfc_simp
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-05-04 12:31
---
RESHAPE is not simplified, because "x" has type EXPR_CONSTANT (scalar constant)
which is not accepted by the simplification routine gfc_simplify_reshape,
because it wants arguments to be EXPR_ARRAY (ie array const
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-04 12:52
---
(Side note: NEW_LINE is not an elemental function. It can be used with an array
argument, but it's different from being elemental.)
As for the bug itself, there's no reason that the argument to NEW_LINE should
be
--- Comment #45 from rguenth at gcc dot gnu dot org 2007-05-04 13:03
---
Of course in the tramp3d case the code is written in such a generic way that it
supports non-POD data members... (And yes, "upstream" has this optimized, but
tramp3d-v4.cpp is about having a gcc testcase, not perf
--- Comment #7 from tbm at cyrius dot com 2007-05-04 13:17 ---
Alexandre, can you investigate this issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31674
--- Comment #4 from charlet at gcc dot gnu dot org 2007-05-04 13:26 ---
gcc -c matter.ads no longer crashes the compiler
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from charlet at gcc dot gnu dot org 2007-05-04 13:42 ---
Compiles cleanly on trunk
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from charlet at gcc dot gnu dot org 2007-05-04 13:44 ---
Fixed on trunk:
$ gcc -c test_134.adb
test_134.adb:11:24: expected type "T1" defined at line 3
test_134.adb:11:24: found type "T1'Class" defined at line 3
test_134.adb:13:17: expected type "T1" defined at line 3
tes
--- Comment #5 from charlet at gcc dot gnu dot org 2007-05-04 14:29 ---
Closing, since it's not clear what behavior the reporter is expecting.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--
Let us consider the following code:
-
void qHash(double) {}
template
struct QSet
{
void foo()
{
qHash(T());
}
};
// void qHash(double) {} // ok if placed here
void qHash(int*) {}
int main()
{
QSet s;
s.foo(); // ok
QSet sp;
sp.foo(); // do not compile, qHash(int*) is no
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-05-04 14:36
---
I noticed after applying the patch to simplify.c the double error problem
returned. I will continue on that part. Subtle things going on here. Side
effects. At least we have the segfault resolved.
--
http:
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-04 14:40 ---
Subject: Bug 31803
Author: burnus
Date: Fri May 4 13:40:32 2007
New Revision: 124419
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124419
Log:
2007-05-04 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-04 14:46 ---
Fixed in 4.3. Not for 4.2.0. If someone has strong feelings about 4.2.1, please
reopen.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from charlet at gcc dot gnu dot org 2007-05-04 14:50 ---
Fixed on trunk:
$ gcc -c test_248687.ads
test_248687.ads:6:04: representation item appears too late
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-04 15:06
---
Reduced testcase:
integer :: l = 0
write(*,'(A,I1)') foo(), 0
contains
function foo()
character(len=l) :: foo
foo = ""
end function
end
When a function result is a string of length 0, and
--- Comment #46 from rguenth at gcc dot gnu dot org 2007-05-04 15:31
---
http://www.suse.de/~gcctest/c++bench/tramp3d/ 2nd graph from the top :(
boost ICEs:
/gcc/spec/sb-vangelis-head-64/boost_1_33_1/boost/wave/util/unput_queue_iterator.hpp:221:
warning: suggest parentheses around &&
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-05-04 16:04
---
I agree, this patch is OK for trunk Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31210
--- Comment #9 from eweddington at cso dot atmel dot com 2007-05-04 16:06
---
>From Bjoern Haase:
Hi all,
I think that we could resolve this ICE by adding an unnamed pattern like
(define_insn "*strangeMovhi"
[(set (mem:HI (plus:HI (reg:HI 28)
(const_int 1))
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-04 16:14
---
Subject: Bug 31210
Author: fxcoudert
Date: Fri May 4 15:14:07 2007
New Revision: 124428
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124428
Log:
PR libfortran/31210
* io/transfer.c (tra
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-05-04 16:20
---
Subject: Bug 31210
Author: fxcoudert
Date: Fri May 4 15:20:17 2007
New Revision: 124429
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124429
Log:
PR libfortran/31210
* gfortran.dg/zero_l
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-04 16:21
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-05-04 16:38
---
I can reproduce that ICE with 4.2.0. It's working fine with gfortran 4.3 (even
under ElectricFence and valgrind). It's not a regression from the 4.1 branch,
since you already had that problem there, as far as I un
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-04 16:40
---
Closing.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|WA
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-04 16:49
---
Also happens on i686-linux. It's a 4.1/4.2 regression, which means we could
theoretically try to fix it. I'm closing this as WONTFIX nonetheless due to the
small impact of the bug (it's triggered by invalid code)
--- Comment #47 from ian at airs dot com 2007-05-04 16:54 ---
Unfortunately there is no obvious way to avoid creating the asm if the types
are the same. The reason is that the dynamic types are different, and we don't
know the dynamic type.
Look at your original test case:
Bar *
--- Comment #48 from rguenth at gcc dot gnu dot org 2007-05-04 16:57
---
Doh, you are right. So we're back to doing it in the aliasing machinery and
with
a new tree-code I think. On IRC Danny said he "can do it" ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-05-04 17:20
---
Segafult is because sym->ts.cl is NULL coming into gfc_conv_function_call. I
suspect reshape is not getting resolved correctly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
"A function is a specification function if it is a pure function, is not a
standard intrinsic function, is not an internal function, is not a statement
function, and does not have a dummy procedure argument."
This is true for "fn" in:
function f2 (fn, i)
integer :: i, fn
character (len
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-04 17:29
---
(In reply to comment #5)
> Segafult is because sym->ts.cl is NULL coming into gfc_conv_function_call. I
> suspect reshape is not getting resolved correctly.
I've given this one a look this afternoon, and I could
--- Comment #3 from terry at chem dot gu dot se 2007-05-04 17:46 ---
While being a reasonably uncommon case, AFAICT it's a legal construct. That
is: not invalid code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31720
--- Comment #4 from terry at chem dot gu dot se 2007-05-04 17:50 ---
(I guess I should qualify that. I don't have a copy of the standard laying
around to check, but it's legal according to the Ellis, Philips and Lahey
book.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31720
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-05-04 17:51
---
The problem is transpose related. In gfc_conv_intrinsic_funcall we pull in the
symbol with gfc_get_symbol_for_expr and then do nothing with it before calling
gfc_conv_function_call. The symbol type is BT_UNKNOWN
subroutine test(cha)
implicit none
character(len=10) :: cha(:)
namelist /z/ cha
end subroutine test
See also:
gfortran.dg/namelist_14.f90
This is invalid:
"5.4 NAMELIST statement"
"C574 (R553) A namelist-group-object shall not be an assumed-size array."
Other compilers reject this:
ifo
integer(kind=1) i ! kind = 1, -128 <= i < 127
select case (i)
case (200) ! kind = 4, unreachable because of range of i
Taken from gfortran.dg/select_5.f90.
This is valid, but one should print a warning. One may also print an error
since having such a case label does not m
--- Comment #5 from kargl at gcc dot gnu dot org 2007-05-04 18:14 ---
(In reply to comment #4)
> (I guess I should qualify that. I don't have a copy of the standard laying
> around to check, but it's legal according to the Ellis, Philips and Lahey
> book.)
>
It is not valid code. The
--- Comment #6 from terry at chem dot gu dot se 2007-05-04 18:35 ---
Created an attachment (id=13507)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13507&action=view)
Revised acmod.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31720
--- Comment #7 from terry at chem dot gu dot se 2007-05-04 18:35 ---
Created an attachment (id=13508)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13508&action=view)
Revised nnh.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31720
--- Comment #8 from terry at chem dot gu dot se 2007-05-04 18:37 ---
(In reply to comment #5)
> (In reply to comment #4)
> > (I guess I should qualify that. I don't have a copy of the standard laying
> > around to check, but it's legal according to the Ellis, Philips and Lahey
> > book.
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-05-04 19:02 ---
Subject: Bug 22539
Author: dfranke
Date: Fri May 4 18:02:18 2007
New Revision: 124437
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124437
Log:
gcc/fortran:
2007-05-04 Daniel Franke <[EMAIL PROTECTED]>
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-05-04 19:34 ---
Fixed in trunk.
Due to a typo in the PR number, the commit message went to PR22539.
Sorry for that :(
As it is a regression wrt g77, this patch probably needs to be backported to
4.1/4.2. Unassigning myself for no
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.1/4.2 regression] fseek |fseek intrinsic not
|intrinsic not implemented |i
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-05-04 19:58
---
The same happens on Solaris up to and including release 9.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
character (len=4), s1
character (len=20), pointer :: p1
s1 = 'abcd'
p1 => s1(2:3)
should be rejected at compile time as len(s1(2:3)) == 2 but p1 has the length
20.
This is not detected because primary.c's match_varspec contains:
if (substring)
primary->ts.cl = NULL;
If
Test case. The comments show what NAG f95 -C=all prints at run time.
program ptr
implicit none
character(len=10), target :: s1
character(len=5), pointer :: p1
integer, volatile :: i
i = 8
! Unequal character lengths (5 and 8) in pointer assignment
p1 => s1(1:i)
call bar(s1)
contains
--- Comment #3 from jakub at gcc dot gnu dot org 2007-05-04 20:21 ---
Subject: Bug 28482
Author: jakub
Date: Fri May 4 19:21:18 2007
New Revision: 124445
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124445
Log:
PR libgomp/28482
* configure.tgt: Don't link with
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-05-04 20:24 ---
Subject: Bug 31760
Author: dfranke
Date: Fri May 4 19:24:43 2007
New Revision: 124446
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124446
Log:
gcc/fortran:
2007-05-04 Daniel Franke <[EMAIL PROTECTED]>
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-05-04 20:29 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-05-04 20:39
---
I have been chasing this around a bit, clear into decl.c and matchexp.c
Nowhere does cl get set. I wonder if there is a separate code path taken when
A is defined as a component of a derived type. Stating the o
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-05-04 20:43
---
This looks suspiciously like the problem we are hunting down in pr31197. Can
you have a look and see if its related, if not the same bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31821
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-05-04 21:32
---
Created an attachment (id=13509)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13509&action=view)
Tentative patch for this bug
Not yet fully tested, nor regtested, but it should do the deed.
--
http://
--- Comment #7 from andreast at gcc dot gnu dot org 2007-05-04 22:06
---
builds here too: sparc-sun-solaris2.8, multilib, native 32-bit.
Tests are failing due to boehm-gc stuff:
sp out of bounds
and compilation complains about:
/export/data/devel-test/gcc-svn/trunk/libjava/classpath/to
The COMPLEX intrinsic is not documented in 4.2.
--
Summary: [4.2 regression] COMPLEX not documented
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unass
--- Comment #1 from brooks at gcc dot gnu dot org 2007-05-04 22:11 ---
Created an attachment (id=13510)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13510&action=view)
Documentation patch for COMPLEX
--
brooks at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-04 22:14 ---
See also: http://gcc.gnu.org/ml/fortran/2007-05/msg00072.html
One also needs a run-time test for:
character (len=4), target :: s1
character (len=2), pointer :: p1
s1 = 'abcd'
p1 => s1(1:2)
if(s1
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-05-04 22:15
---
Here's a patch that avoids multiple evaluation of substring start and end
indices. It was tested on the testcase, also by changing the (start:) range
into a (:end) range, and also by using -fbounds-check (which ev
I've realized a strange code generation behavior I cannot explain and I think
to be a bug. It's merely about that a function calls to another one with a
parameter read from a constant array. The constant array superfluously gets
copied onto the stack.
I've attached the test code with one can repro
--- Comment #1 from theorizer at freemail dot hu 2007-05-04 22:20 ---
Created an attachment (id=13511)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13511&action=view)
the code snippet for reproducing the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31824
--- Comment #9 from burnus at gcc dot gnu dot org 2007-05-04 22:29 ---
If ts.cl->length is set to one, the test case of comment 6 works; see also
http://gcc.gnu.org/ml/fortran/2007-05/msg00072.html which contains a bogus
patch which fixes this.
As that patch messes around with length, t
# gcc -v
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: ./configure
Thread model: posix
gcc version 3.4.4
I have compiled a simple test program in C++ using stl::map.
#g++ -DDOESNT_WORK test.cpp
#./a.out
Added value
TYpe=0name = varnum0value =199
Added valu
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-04 23:05 ---
I don't think this is a bug as you changing the key from underneath of
std::map.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-04
23:10 ---
Subject: Re: config-int.h:327:1: error: "INT8_MIN" redefined
> and compilation complains about:
> /export/data/devel-test/gcc-svn/trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Messages.java:64:
> w
Dears
Valgrind reports me something shown below.
==1193== Invalid read of size 1
==1193==at 0x4023694: strcpy (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==1193==by 0x41D8837: (below main) (in /lib/libc-2.5.so)
==1193== Address 0x42F1455 is 13 bytes inside a block of size 15 f
--- Comment #1 from danglin at gcc dot gnu dot org 2007-05-04 23:43 ---
This test is no longer failing. I believe that the problem was fixed
by this change:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg02036.html
--
danglin at gcc dot gnu dot org changed:
What|Remove
--- Comment #4 from danglin at gcc dot gnu dot org 2007-05-04 23:46 ---
This test is no longer failing. I believe that this problem was
fixed by this change:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg02036.html
--
danglin at gcc dot gnu dot org changed:
What|Remov
--- Comment #3 from danglin at gcc dot gnu dot org 2007-05-04 23:48 ---
This test is no longer failing. I believe that the problem was fixed
by this change:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg02036.html
--
danglin at gcc dot gnu dot org changed:
What|Remove
--- Comment #1 from danglin at gcc dot gnu dot org 2007-05-04 23:53 ---
*** This bug has been marked as a duplicate of 30459 ***
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from danglin at gcc dot gnu dot org 2007-05-04 23:53 ---
*** Bug 31168 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30459
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
-
O0 -w -fno-show-column -c -o limits-exprparen.o
/test/gnu/gcc/gcc/gcc/testsuit
e/gcc.c-torture/compile/limits-exprparen.c(timeout = 300)
^M
Pid 2297 received a SIGSEGV for stack growth failure.^M
Possble causes:
FAIL: gcc.dg/float-range-3.c (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/float-range-3.c:10: error: 'FP_INFINITE'
undeclared (first use in this function)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/float-range-3.c:10: error: (Each
undeclar
ed identifier is reported onl
--- Comment #2 from pcarlini at suse dot de 2007-05-05 00:11 ---
You are only passing around a pointer to name and not allocating memory for the
various "C" strings, instead overwriting each time in the loop the same char
array. Well, there are also other problems in the code, like not p
--- Comment #1 from pcarlini at suse dot de 2007-05-05 00:12 ---
We need self-contained, minimal code, before taking any further action. Thanks.
--
pcarlini at suse dot de changed:
What|Removed |Added
---
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/test/gnu/
gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/warn/
multiple-overflow-warn-3.C -nostdinc++
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.
11/libstdc++-v3/include/hppa64-hp-hpux11.11
-I/test/gnu/
--- Comment #2 from brooks at gcc dot gnu dot org 2007-05-05 00:29 ---
Created an attachment (id=13512)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13512&action=view)
Documentation patch (not corrupted, this time)
--
brooks at gcc dot gnu dot org changed:
What
This occurs with a cross compilation from i386-linux to powerpc-elf. The input
parameter in r3 gets overwritten by the return value from a function call.
This only occurs when optimization is enabled (-O1 or higher). This has
something to do with unions and bit fields. A simple test case follow
--- Comment #1 from gmorain at gmail dot com 2007-05-05 00:47 ---
Created an attachment (id=13513)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13513&action=view)
Source that demonstrates the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31830
1 - 100 of 117 matches
Mail list logo
