--- Comment #11 from guillaume dot melquiond at ens-lyon dot fr 2005-11-25
08:31 ---
Your testcases are too minimal. The issue lies in the diagnostic, when there is
a compilation error involving an anonymous enumeration. In the original
bug-report, GCC was trying to delete a file
In the following program, the pointer association is not allowed.
However, I can compile successfully, and get no output after the execution.
I think this is wrong behavior.
program ptrtest
implicit none
integer a(4)
a(1:4) = 1
contains
subroutine foo(m)
integer, target :: m(*)
In the following program, pointer association is not allowd.
But I can compile successfully, and get the output of random character
string whose length is 999.
I think this is wrong behavior.
program char_array_const
implicit none
character(len=999), pointer :: p
character(len=12), target
In the following program, the run-time error should occur.
at the second allocation.
But I can successfully executed the program.
And at the second allocation, memory leak is also occur.
I think this is wrong behavior.
program alloc_test
implicit none
integer, allocatable :: a(:)
--- Comment #12 from rearnsha at gcc dot gnu dot org 2005-11-25 10:09
---
Subject: Re: [4.2 Regression] Build failure on
sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
On Fri, 2005-11-25 at 02:51, joseph at codesourcery dot com wrote:
It
does not address the
SAXNotSupportedException.java:0: internal compiler error: Segmentation fault
--
Summary: GCC Java not compile
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: java
--- Comment #16 from jakub at gcc dot gnu dot org 2005-11-25 11:31 ---
Created an attachment (id=10336)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10336action=view)
unit.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
--- Comment #17 from jakub at gcc dot gnu dot org 2005-11-25 11:32 ---
Created an attachment (id=10337)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10337action=view)
unit.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
--- Comment #18 from jakub at gcc dot gnu dot org 2005-11-25 11:42 ---
From the files I got in private mail it seems that weakref attribute doesn't
work on darwin. But I haven't managed to convince my powerpc64-linux
- powerpc-apple-darwin8.3.0 cross to actually generate any
[forwarded from http://bugzilla.ubuntu.com/show_bug.cgi?id=18478]
seen with cpp 4.0 and 4.1, changed from 3.4
Compare:
$ echo blabla | cpp-3.4 -P
blabla
$ echo blabla | cpp-4.0 -P
blabla
$
--
Summary: cpp prepends 2 extraneous empty lines when run with -P
Product: gcc
--- Comment #13 from jsm28 at gcc dot gnu dot org 2005-11-25 12:57 ---
Subject: Bug 24998
Author: jsm28
Date: Fri Nov 25 12:57:02 2005
New Revision: 107502
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107502
Log:
PR middle-end/24998
* config/sparc/sparc.c
[EMAIL PROTECTED]:~/src cat t.f90
subroutine a
call f(g)
contains
function g(x)
x =0.
end function g
end subroutine a
[EMAIL PROTECTED]:~/src gcc/build/gcc/f951 -quiet t.f90
t.f90: In function 'g':
t.f90:5: warning: Function return value not set
[EMAIL PROTECTED]:~/src
This is not
--- Comment #14 from andreast at gcc dot gnu dot org 2005-11-25 14:36
---
results with patch-part applied for sparc:
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg01172.html
Thanks!!!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
--- Comment #1 from pda at freeshell dot org 2005-11-25 14:53 ---
I attempted to build 3.4.4 in the same way afterwards, and got exactly the same
error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25025
--- Comment #18 from reichelt at gcc dot gnu dot org 2005-11-25 14:59
---
Subject: Bug 9278
Author: reichelt
Date: Fri Nov 25 14:59:09 2005
New Revision: 107508
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107508
Log:
PR c++/9278
* decl.c (grokparms): Do not
--- Comment #19 from reichelt at gcc dot gnu dot org 2005-11-25 15:07
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-25 15:09
---
Confirmed.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-25 15:11
---
Confirmed.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-25 15:13
---
Confirmed.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-25 15:37
---
Confirmed.
A few comments:
Since the subroutine foo isn't called, we can't expect any output. If,
however, we add a the line
call foo(a)
after the line
a(1:4) = 1
we still don't get any output (or, to be
--- Comment #11 from reichelt at gcc dot gnu dot org 2005-11-25 15:45
---
I removed the dead code as discussed in comment #8 and later:
http://gcc.gnu.org/ml/gcc-cvs/2005-11/msg01213.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15938
--- Comment #42 from pluto at agmk dot net 2005-11-25 16:04 ---
(In reply to comment #40)
it also builds on i486. unfortunately amd64 fails on a-except even with -O0.
(...)
stage1/xgcc -Bstage1/ -B/usr/x86_64-pld-linux/bin/ -c -march=x86-64 -O2 -ggdb
-gnatpg -gnata -g -O0 \
--- Comment #4 from aph at gcc dot gnu dot org 2005-11-25 16:18 ---
Subject: Bug 25016
Author: aph
Date: Fri Nov 25 16:18:17 2005
New Revision: 107509
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107509
Log:
2005-11-25 Andrew Haley [EMAIL PROTECTED]
PR libgcj/25016
--- Comment #5 from aph at gcc dot gnu dot org 2005-11-25 16:31 ---
Subject: Bug 25016
Author: aph
Date: Fri Nov 25 16:31:09 2005
New Revision: 107510
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107510
Log:
2005-11-25 Andrew Haley [EMAIL PROTECTED]
PR libgcj/25016
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2005-11-25
16:50 ---
(In reply to comment #18)
Jakub,
I exactly the same failures here on gcc 4.1 branch for the gcc and g++
testsuite as are
reported at http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg01154.html.
--- Comment #20 from jakub at gcc dot gnu dot org 2005-11-25 17:05 ---
It needs to be fixed, gthr*.h relies on it. __attribute__((weeakref)) is
supposed to work on all targets that support the weak attribute and darwin
is one of them, either through .weakref assembler directive (very
--- Comment #6 from aph at gcc dot gnu dot org 2005-11-25 17:20 ---
Subject: Bug 25016
Author: aph
Date: Fri Nov 25 17:20:09 2005
New Revision: 107511
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107511
Log:
2005-11-25 Andrew Haley [EMAIL PROTECTED]
PR libgcj/25016
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2005-11-25
17:36 ---
Jakub,
Shouldn't you add Geoffrey Keating to the cc for this bug as he does the
cctools releases. FYI, I am using his last 590.12 cctools release
(http://gcc.gnu.org/ml/gcc/2005-10/msg01218.html)
Building an avr cross compiler from gcc-4_1-branch of today fails with:
checking for --enable-version-specific-runtime-libs... no
checking whether to enable maintainer-specific portions of Makefiles... no
Configuring in avr/libssp
configure: creating cache ./config.cache
checking build system
--- Comment #8 from rep dot nop at aon dot at 2005-11-25 19:02 ---
updated patch:
http://gcc.gnu.org/ml/fortran/2005-11/msg00612.html
ACK by stevenb:
http://gcc.gnu.org/ml/fortran/2005-11/msg00631.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21302
The program
program test
integer :: fh = 71
open(fh, file=f, form='unformatted', status='unknown')
! close(fh)
open(fh, file=f, form='unformatted', status='unknown')
end program
fails with
At line 5 of file file-status-old.f90
Fortran runtime error: OPEN
--- Comment #11 from guilhem at kaffe dot org 2005-11-25 19:10 ---
I feel a potential race condition in this patch. What happens in that case ?
thread 2:
= PlainSocketImpl.accept
= enters _Jv_select
thread 1:
= shutdown socket
= close socket
thread 3:
= create another socket
--- Comment #5 from bonzini at gnu dot org 2005-11-25 19:12 ---
Another failure from glibc's tests is more severe: __DBL_MAX__ * __DBL_MAX__ -
__DBL_MAX * __DBL_MAX__ is turned into an INF rather than a NAN (as would
happen on most targets) or zero (as would happen on x87 because it
--- Comment #6 from bonzini at gnu dot org 2005-11-25 19:13 ---
CCing Eric since he recently had problems with ia64 fma
(http://gcc.gnu.org/ml/gcc/2005-10/msg01036.html).
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #1 from jb at gcc dot gnu dot org 2005-11-25 19:13 ---
Also, g77 (and pathscale and ifort) support reopening files with
status='unknown'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25036
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2005-11-25
19:21 ---
One other note. I tried a build of gcc 4.1 branch with MACOSX_DEPLOYMENT_TARGET
set to 10.4 as well since that causes libtool to use '-undefined
dynamic_lookup' instead of '-undefined suppress' when
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-11-25 19:24
---
Is there still a problem here?
If so, please indicate what steps are required to reproduce it.
Otherwise, let's close this PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25009
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2005-11-25 19:44
---
I am reopening this PR because I recieved information that the behavior is a
pre F90 feature commonly used before array triplet notation was introduced. I
also found that it is supported in g77. So we
When running the testsuite on x86_64-linux-gnu with the following RUNTESTFLAGS:
RUNTESTFLAGS=--target_board=unix/\{-m64,-m32\}
gcc.target/i386/asm-1.c fails as -m64 is passed last so that -m32 -m64 is
passed to the compiler which makes the test fails as it is expecting to be in
32bit mode.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-25 20:14 ---
Can you attach the source you are trying to compile?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-25 20:15 ---
*** This bug has been marked as a duplicate of 23751 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-25 20:15 ---
*** Bug 25033 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-25 20:17 ---
This is not a bug, cpp is wrong tool for languages which don't support extra
white spaces.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-25 20:19 ---
waiting for a short testcase and/or see if it has been fixed already.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-25 20:23
---
*** Bug 25014 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 2005-11-25 20:23 ---
This is a dup of bug 16372 which was fixed in 3.4.2.
*** This bug has been marked as a duplicate of 16372 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-25 20:27 ---
How did you configure GCC?
From using google it sounds like you configured GCC to use the GNU binutils but
it is using the native toolchain instead.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-25 20:28 ---
Actually IIRC libssp has some issues with cross compiling which needs to be
fixed, anyways the workaround is --disable-libssp.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-25 20:31 ---
actually there is no demangling in the C++ front-end. What is usually is
giving is just a friendly version of the string (there is a way to do this but
I don't know how).
Now the demangler might need to be
--- Comment #2 from jb at gcc dot gnu dot org 2005-11-25 20:39 ---
Patch here: http://gcc.gnu.org/ml/fortran/2005-11/msg00677.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25036
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-25 20:40 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #23 from pinskia at gcc dot gnu dot org 2005-11-25 20:51
---
Ok, the problem is that GTHREAD_USE_WEAK is not being defined to 0 as
config/darwin.h defines it to 0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from pinskia at gcc dot gnu dot org 2005-11-25 20:53
---
This is not really a target issue fully and what libgfortran or gthr.h does is
incorrect. I wonder how libstdc++ works correctly but not libgfortran does.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
--- Comment #25 from pinskia at gcc dot gnu dot org 2005-11-25 20:54
---
Note libobjc is fine as it does:
#include config.h
#include tconfig.h
#include coretypes.h
#include tm.h
#include defaults.h
so it gets the correct define. Now to figure out why libstdc++ works.
--
--- Comment #26 from pinskia at gcc dot gnu dot org 2005-11-25 21:01
---
The reason why libstdc++ works is because there is a define in the config
header for libstdc++ for GTHREAD_USE_WEAK being defined as 0. So this is a
libgfortran failure only.
--
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-25 21:09
---
Hmm, we should picking up GTHREAD_USE_WEAK from pa/som.h.
Could you attach the preprocessed source (with -g3) for thrd-objc.c from
libobjc?
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-25 21:11 ---
Hmm, GTHREAD_USE_WEAK should be zero so that this should not matter at all.
Did someone forget to include the tm.h file or a different file for this code?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24831
--- Comment #3 from mark at gcc dot gnu dot org 2005-11-25 21:16 ---
http://gcc.gnu.org/ml/java-patches/2005-q4/msg00218.html
contains a workaround for this issue.
The override files can be removed when this bug is closed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24938
I get a runtime error on the following simple program:
cat simple.f
program junk
read(5,'(2i9)') i1,i2
write(6,*) i1,i2
end
gfortran simple.f
./a.out
1,1
At line 2 of file simple.f
Fortran runtime error: Bad value during integer read
Contrary to that:
g77 simple.f
./a.out
--- Comment #27 from pinskia at gcc dot gnu dot org 2005-11-25 21:27
---
This effects more than Darwin, this also effects HPUX, openbsd, and cygwin.
./pa/pa64-hpux.h:#define GTHREAD_USE_WEAK 0
./pa/som.h:#define GTHREAD_USE_WEAK 0
./darwin.h:#define GTHREAD_USE_WEAK 0
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-25
21:36 ---
Subject: Re: [4.1/4.2 regression] gthr-dce.h:77: error: expected expression
before '{' token
Hmm, GTHREAD_USE_WEAK should be zero so that this should not matter at all.
Did someone forget to include the
--- Comment #3 from iwan at irs dot phy dot nrc dot ca 2005-11-25 21:39
---
Created an attachment (id=10339)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10339action=view)
A one line change that seems to fix Bug 24268
Have tested the change on several large fortran 77 source
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-25
21:49 ---
Subject: Re: [4.1/4.2 Regression] libobjc testsuite failures
Could you attach the preprocessed source (with -g3) for thrd-objc.c from
libobjc?
Here it is.
Dave
--- Comment #12 from dave at
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2005-11-25
21:54 ---
Andrew,
Sorry if this is a stupid question, but how does this PR relate to the
fact that...
gcc.dg/attr-weakref-1.c
gcc.dg/weak/weak-14.c
...fail on Darwin_8.3.0? Are they associated problems?
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-11-25 22:00
---
Confirmed on 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from geoffk at gcc dot gnu dot org 2005-11-25 22:06 ---
Some comments:
1. There is no need to use weak symbols for pthreads on Darwin. There's no
separate pthread library like on some other OSs.
2. Some older versions of Darwin do not support weak symbols *at all*.
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-25 22:08
---
gthdr.h is wrong, it should not be using asm(pthread_create) (etc.) here at
all
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-25 22:11 ---
Since GTHREAD_USE_WEAK and/or SUPPORTS_WEAK is false, we should not do the
asm(xxx) shit which is causing all of the issues.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from mark at gcc dot gnu dot org 2005-11-25 22:31 ---
Subject: Bug 24938
Author: mark
Date: Fri Nov 25 22:30:53 2005
New Revision: 107522
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107522
Log:
* standard.omit.in: Remove javax/rmi, org/omg, gnu/CORBA and
--- Comment #2 from rth at gcc dot gnu dot org 2005-11-25 22:38 ---
No, this isn't a failure of the demangler. Nor do ever expect these
functions to ever be demangled. That they contain the original function
name at all is merely an aid to us the compiler developer.
I don't see that
--- Comment #30 from andreast at gcc dot gnu dot org 2005-11-25 22:43
---
does this work for others too? Or do I miss a linux 'feature' ?
Index: io/io.h
===
--- io/io.h (revision 107496)
+++ io/io.h (working copy)
--- Comment #31 from jakub at gcc dot gnu dot org 2005-11-25 22:52 ---
libgfortran shouldn't be using gcc private headers, libobjc is getting rid of
that dependency as well, see libobjc_noheaders branch.
--
jakub at gcc dot gnu dot org changed:
What|Removed
In the attached example the interface I declares I.blah(). The abstract class A
then implements I but doesn't define the method nor re-declares it as abstract.
Given these definitions both javac and gcj accept calling blah() using an A
reference. Obviously you need to derive a non-abstract class
--- Comment #1 from michele at focuseek dot com 2005-11-25 23:01 ---
Created an attachment (id=10341)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10341action=view)
A test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25040
--- Comment #32 from howarth at nitro dot med dot uc dot edu 2005-11-25
23:03 ---
Andreas,
The undefined symbols under Darwin_8.3.0 occur as follows...
___gthrw_pthread_mutex_lock
rand.o
random.o
unix.o
unit.o
___gthrw_pthread_mutex_trylock
unix.o
unit.o
--- Comment #2 from pcarlini at suse dot de 2005-11-25 23:31 ---
More interesting work to do:
http://gcc.gnu.org/ml/libstdc++/2005-11/msg00241.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24693
The file 'rksuite_90.f90' from the archive 'rksuite_90.tar' from www.netlib.org
or http://math.la.asu.edu/~eric/mat420/rksuite_90.tar produces an internal
compiler error:
$ gfortran41 -c rksuite_90.f90
rksuite_90.f90: In function 'interpolate_r1':
rksuite_90.f90:2646: internal compiler
Compile the following test (reduced from
gcc.dg/torture/fp-int-convert-float128.c) on i686-pc-linux-gnu with -O -mmmx.
It gives an ICE
z.c: In function 'main':
z.c:9: internal compiler error: in cgraph_local_info, at cgraph.c:525
Please submit a full bug report,
with preprocessed source if
--- Comment #1 from kargl at gcc dot gnu dot org 2005-11-26 00:11 ---
How are you building this? If I fix and run the make_rk script
for all possibilities, I get a 16000+ line program.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-26 00:48 ---
Hmm, IFC does the same thing as gfortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25030
--- Comment #5 from mark at gcc dot gnu dot org 2005-11-26 00:48 ---
Subject: Bug 24938
Author: mark
Date: Sat Nov 26 00:48:29 2005
New Revision: 107534
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107534
Log:
* standard.omit.in: Remove javax/rmi, org/omg, gnu/CORBA and
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-26 00:50 ---
IFC allows this by default but errors out with -e90 so confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-11-26 01:25 ---
Subject: Bug 25022
Author: ghazi
Date: Sat Nov 26 01:25:20 2005
New Revision: 107535
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107535
Log:
PR middle-end/25022
* builtins.c
--- Comment #3 from ghazi at gcc dot gnu dot org 2005-11-26 01:31 ---
Subject: Bug 25022
Author: ghazi
Date: Sat Nov 26 01:31:54 2005
New Revision: 107536
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107536
Log:
PR middle-end/25022
* builtins.c
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2005-11-26 01:35
---
-fdump-tree-original: See below. What is this unprintable character? Is that
right?
MAIN__ ()
{
int4 i2;
int4 i1;
{
struct __st_parameter_dtquireY dt_parm.0;
dt_parm.0.common.filename =
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-26 01:38 ---
This has been fixed now with:
2005-11-09 Eric Botcazou [EMAIL PROTECTED]
* function.c (assign_stack_local_1): Issue an error message if
the frame size overflows in the signed target arithmetics.
--- Comment #33 from howarth at nitro dot med dot uc dot edu 2005-11-26
02:27 ---
The patch in the Patch URL seems to resolve the symbol problems. I am seeing a
failure in the fgetc_# and fputc_# gfortran tests now due to timeouts. However
I saw those as well when I regressed out the
--- Comment #2 from kargl at gcc dot gnu dot org 2005-11-26 02:49 ---
Reduce test case.
module z
type b
character(len=80) :: r(10)
end type b
contains
subroutine a(c)
type(b), intent(inout), target :: c
write (c%r,(a)) death
end subroutine a
end
-20051125/libgfortran/intrinsics/string_intrinsics.c:95
95memmove (dest, src, srclen);
(gdb) s
Current language: auto; currently c
88if (srclen = destlen)
(gdb) s
99 }
(gdb) s
*__gfortran_copy_string (destlen=5, dest=0xb298 \217?\217?a???, srclen=5,
src=0x2fbc 12345
I found an ICE in debian gcc-4.0_4.0.2-4 when building rsplib and about five
other packages. I've reduced it to a short file which follows. It fails with no
special options.
| [EMAIL PROTECTED]:/build/buildd/wkg$ gcc buggy.c
| buggy.c: In function 'buggy':
| buggy.c:17: internal compiler error:
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-26 03:26 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-26 03:27 ---
Fixed at least on the 4.1 branch and the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from joseph at codesourcery dot com 2005-11-26 03:55
---
Subject: Patch for ia64-hpux problems
This patch fixes the ia64-hpux problems with my __floatun* patch. It adds
a full set of C implementations of __floatunsi* which should also be
usable to solve the
--- Comment #5 from sayle at gcc dot gnu dot org 2005-11-26 04:07 ---
Subject: Bug 21309
Author: sayle
Date: Sat Nov 26 04:06:57 2005
New Revision: 107537
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107537
Log:
PR middle-end/21309
* expmed.c
--- Comment #3 from haymaker at mail dot utexas dot edu 2005-11-26 06:03
---
(In reply to comment #1)
How are you building this? If I fix and run the make_rk script
for all possibilities, I get a 16000+ line program.
I built it with the r1 option ($make_rk r1) for 1D array
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-26 07:19 ---
(In reply to comment #1)
I can reproduce this 3.3.3 and 3.4.3. However, 4.0.0 doesn't have the
problem.
Are you working on this? It lools like the bug has been there for a while.
I'm inclined to postponed untill
--- Comment #6 from gdr at gcc dot gnu dot org 2005-11-26 07:28 ---
Fixed in 4.1 and higher. Will not fix in 3.4.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from gdr at gcc dot gnu dot org 2005-11-26 07:35 ---
(In reply to comment #2)
(In reply to comment #1)
(In reply to comment #0)
There should be a defined but not used warning.
Why, this is a constant array so it is removed right?
Never mind, but I can
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
1 - 100 of 106 matches
Mail list logo
