--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30
06:10 ---
Subject: Bug 21761
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-30 06:10:06
Modified files:
gcc: ChangeLog
--- Additional Comments From geoffk at gcc dot gnu dot org 2005-05-30
06:13 ---
Should work now, but please verify.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30
07:38 ---
Subject: Bug 20179
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-30 07:38:36
Modified files:
libgfortran: ChangeLog
libgfortran/io :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30
07:42 ---
Subject: Bug 20179
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-30 07:42:38
Modified files:
libgfortran:
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-30
07:45 ---
Patch for first part of the problem applied. Keeping open according to comments
#8 to #11.
--
What|Removed |Added
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-05-30
07:50 ---
This program builds just fine:
$ cat conftest.c
main () {
/* Are we little or big endian? From HarbisonSteele. */
union
{
long l;
char c[sizeof (long)];
} u;
u.l = 1;
exit
When I use a ftime function in a multhithread program, sometime it will stop
and
all thread that use this function will wait for a mutex lock. The information
from
GDB are following:-
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/64/libnsl.so.1...done.
--- Additional Comments From oliverst at online dot de 2005-05-30 07:56
---
Filed a bug report on the MinGW project page:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
gcc -D__KERNEL__ -I/usr/src/linux-2.4.30/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe
-mpreferred-stack-boundary=2 -march=athlon-nostdinc -iwithprefix include
-DKBUILD_BASENAME=floppy -c -o floppy.o floppy.c
gcc: Internal
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/tools/pkg/gcc/4.0.0 --enable-
languages=c,c++ --disable-threads
Thread model: single
gcc version 4.0.0
$ touch a.c
$ gcc -E a.c
# 1 a.c
# 1 built-in
# 1 command line
# 1 a.c
$ gcc -E -g
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
09:00 ---
$ /export/Plocal/GCC-3.3.6/gcc/xgcc -B/export/Plocal/GCC-3.3.6/gcc/
-B/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/bin/
-B/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/lib/ -isystem
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-05-30
09:35 ---
In the 64-bit case, again none of BYTE_ORDER, BIG_ENDIAN or LITTLE_ENDIAN are
defined. As far as I can understand, the configure script stops there and
doesn't run additional tests as in the 32-bit case.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
09:38 ---
checking whether byte ordering is bigendian... cross-compiling...
unknown
checking to probe for byte ordering... guessing bigendian ...
unknown
configure: error: unknown endianess - sorry
gmake[1]: ***
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
09:40 ---
I think you should give it another try.
rm -r sparc-sun-solaris2.8/libffi
rm -r sparc-sun-solaris2.8/sparcv9/libffi
gmake all-target-libffi
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782
--- Additional Comments From giovannibajo at libero dot it 2005-05-30
10:34 ---
As explained in the URL printed by GCC, we need the preprocessed source. Also
notice that 3.3.6 is out and the 3.3 branch is now unsupported. You may want to
switch to a newer GCC.
--
What
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
10:38 ---
$ /export/Plocal/GCC-3.3.6/gcc/xgcc -B/export/Plocal/GCC-3.3.6/gcc/
-B/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/bin/
-B/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/lib/ -isystem
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-30
10:51 ---
I'm beginning to see what happens here. It's arising from many small errors in
the library code (bad handling of bytes_left and active fields).
I will probably come up with a nice patch in the next few
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-05-30
11:13 ---
This has to be the command line.
All I did was copying/pasting from the config.log file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782
--
What|Removed |Added
Component|other |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21812
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
11:25 ---
Not a GCC bug, please report this to your libc provider (most likely glibc).
--
What|Removed |Added
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Severity|critical
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
11:34 ---
This is expected behaviour as you need the current directory for debugging.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
11:36 ---
The correct URL for the bug at mingw is:
https://sourceforge.net/tracker/index.php?
func=detailaid=1211187group_id=2435atid=102435
--
What|Removed |Added
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-05-30
11:39 ---
I tried anyway:
$ /export/Plocal/GCC-3.3.6/gcc/xgcc -B/export/Plocal/GCC-3.3.6/gcc/
-B/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/bin/
-B/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/lib/ -isystem
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-05-30
11:41 ---
Well, but I want all generated objects to be the same between our developers.
This makes an extremly good cache hit rate with ccache. We arranged with it
that we don't have the current/source
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
12:22 ---
$ /export/Plocal/GCC-3.3.6/gcc/xgcc -B/export/Plocal/GCC-3.3.6/gcc/
-B/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/bin/
-B/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/lib/ -isystem
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-05-30
12:43 ---
We're heading in the wrong direction.
I don't see how '-v' can help. The problem is just that LD_LIBRARY_PATH contains
/usr/local/lib which contains a link to the 32-bit libgcc_s.so.1 library of gcc
4.
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-05-30
12:44 ---
(In reply to comment #20)
$ env ldd conftest
Instead it should read:
env LD_LIBRARY_PATH=/export/Plocal/GCC-3.3.6/gcc/sparcv9 ldd conftest
I don't know what went wrong while copying/pasting.
--
gfortran4 -c /home/oskeno/src/edge/solver/basic/tst.f90
In file /home/oskeno/src/edge/solver/basic/tst.f90:2
TYPE TTYPE
1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
--
Summary: gfortran rejects simple, valid code
Product: gcc
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-05-30
12:59 ---
See:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/Makefile.am#rev1.40
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/Makefile.in#rev1.51
These changes must somehow be related to my problems with gcc
--- Additional Comments From enok at lysator dot liu dot se 2005-05-30
13:00 ---
Created an attachment (id=8991)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8991action=view)
Testcase with valid code that fails to compile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21816
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
13:01 ---
We're heading in the wrong direction.
I don't see how '-v' can help. The problem is just that LD_LIBRARY_PATH
contains
/usr/local/lib which contains a link to the 32-bit libgcc_s.so.1 library of
--- Additional Comments From enok at lysator dot liu dot se 2005-05-30
13:02 ---
(From update of attachment 8991)
MODULE TSTMOD
TYPE TTYPE
INTEGER, POINTER :: P =NULL()
END TYPE TTYPE
TYPE(TTYPE), POINTER :: TP
END MODULE TSTMOD
--
--- Additional Comments From dorit at il dot ibm dot com 2005-05-30 13:04
---
These failures should have been fixed after this:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02756.html
With the fix above I no longer see these testcase failures on powerpc-apple-
darwin, but the ICEs
--- Additional Comments From enok at lysator dot liu dot se 2005-05-30
13:05 ---
Created an attachment (id=8992)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8992action=view)
Corrected testcase
Please forget the previous attachment (feel free to remove it if possible) ...
_This_
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
13:08 ---
*** Bug 21816 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
13:08 ---
*** This bug has been marked as a duplicate of 16606 ***
--
What|Removed |Added
--- Additional Comments From dorit at il dot ibm dot com 2005-05-30 13:10
---
Confirmed, this is most likely the same as PR 21653.
Indeed looks related, but a patch that fixed PR21653 did not fix this PR. I
also checked if the follow-on fix - http://gcc.gnu.org/ml/gcc-patches/2005-
--- Additional Comments From enok at lysator dot liu dot se 2005-05-30
13:27 ---
If CHARACTER is replaced by INTEGER the result is the same. Thus, it is not
CHARACTER type pointers that causes the problem.
(In reply to comment #6)
*** Bug 21816 has been marked as a duplicate of this
giraff:~/edu/exjobb/src/mkexpl /scratch/dva00mkn/gcc-4.0/bin/gcc bug.c -O -c
bug.c: In function 'foo':
bug.c:4: internal compiler error: in for_each_index, at tree-ssa-loop-im.c:200
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
14:09 ---
Confirmed, also happens on i686-pc-linux-gnu.
Also this looks like a latent bug on the mainline.
--
What|Removed |Added
Steps to reproduce:
1. Compile they attached testcase with gcj -C DoubleClickJList.java
Expected results:
1. DoubleClickJList.class is created and no errors are shown.
Actual results:
$ /home/lindi/installdir-2005-05-22/gcc/bin/gcj -C DoubleClickJList.java
DoubleClickJList.java:3: error: Methods
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
14:20 ---
Confirmed, this is just namespace spilling in the library.
--
What|Removed |Added
i*86-*-gnu* not enabled in configure.ac, which makes configure fail if you try
to compile libffii on GNU.
--
Summary: i*86-*-gnu* not enabled in configure.ac
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Consider the following program:
program kl
integer i,j,k
integer, parameter :: m = 1000, n = 387
real x(m,n)
x = 1.e0
inquire(iolength=k) (x(i,1), i=1, m)
open(unit=1, file='foo.dat', access='direct', recl=k)
do j = 1, n
write(1,rec=j) (x(i,j), i=1, n)
end do
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
14:33 ---
Nope, I am wrong, this is a front-end bug:
copper:~cat t/JList.java
package t;
public class JList
{
void init(){}
}
copper:~cat DoubleClickJList.java
import t.JList;
public class DoubleClickJList extends
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
14:33 ---
Alan, am I mistaken or did you document on the 3.4 branch something that is only
in 4.x? AFAICS PR bootstrap/14992 has been solved differently on that branch:
PR bootstrap/14992
*
--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-30 14:33
---
Created an attachment (id=8994)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8994action=view)
patch to fix problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820
--- Additional Comments From dorit at il dot ibm dot com 2005-05-30 14:35
---
I can't reproduce this ICE with mainline snapshot from today. (I was able to
reproduce it a few days ago, but not anymore).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21734
--
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21819
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
14:40 ---
Aaah... You mean adding '-v' to 'xgcc', not to 'conftest' itself. My wrong.
Yup, sorry for being too vague.
Please find the output of the following command attached.
The problem stems from -lgcc
Please do not use MAXPATHLEN, it is a arbitrary limit, and is not
defined on GNU. Currently this makes libjava (gcc 4.0.0) unbuildable on GNU
since [gcc]/libjava/gnu/java/nio/channels/natFileChannelImpl.cc assumes that
MAXPATHLEN is defined. Please do not use these kind of limits in GNU
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
14:40 ---
Someone forgot that the HAVE_LD_AS_NEEDED patch had also been put on the 3.3
branch, so the silent switch from -static-libgcc to -shared-libgcc is present on
that branch too. See PR bootstrap/21782.
--
--
What|Removed |Added
Component|java|libgcj
Keywords||build
Summary|MAXPATHLEN usage in
--
What|Removed |Added
Summary|MAXPATHLEN usage in |MAXPATHLEN usage in
|natFileChannelImpl.cc |natFileChannelPosix.cc
--- Additional Comments From ams at gnu dot org 2005-05-30 14:42 ---
Created an attachment (id=8995)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8995action=view)
Add i*86-*-gnu* to configure.ac
Add GNU to the list of detected systems.
2005-05-30 Alfred M. Szmidt [EMAIL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
14:44 ---
Since 3.3.6 is the last release of 3.3.x, closing as will not fix.
--
What|Removed |Added
--
What|Removed |Added
BugsThisDependsOn||14992
Target Milestone|3.4.6 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782
--- Additional Comments From dorit at il dot ibm dot com 2005-05-30 14:47
---
crafty_bug.c:31: internal compiler error: tree check: expected ssa_name, have
var_decl in is_old_name, at tree-into-ssa.c:467
SPEC CPU2000 tests gcc, crafty, and mesa all get this ICE.
I've seen this
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
14:49 ---
I cannot reproduce this on either powerpc-darwin or i686-pc-linux-gnu, what
target are you using?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
14:49 ---
The bottom line of all this mess is that you shouldn't use Binutils 2.15 or
above with GCC 3.3.4, 3.3.5 or 3.3.6.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
14:51 ---
When the mail lists are back up and working, could you send your patch to
gcc-patches@ and java-
[EMAIL PROTECTED]
Also I think the check for -gnu* should go after the linux as linux-gnu will
match too.
--- Additional Comments From ams at gnu dot org 2005-05-30 14:53 ---
[gcc]/libjava/java/io/natFilePosix.cc is also broken due to the usage of
MAXPATHLEN.
--
What|Removed |Added
--- Additional Comments From ams at gnu dot org 2005-05-30 14:55 ---
Will do. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21819
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2005-05-30 14:58 ---
Subject: Re: Really, really, horrible IO performance
On Mon, May 30, 2005 at 02:49:04PM -, pinskia at gcc dot gnu dot org wrote:
I cannot reproduce this on either powerpc-darwin or
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
15:00 ---
(In reply to comment #3)
Note, the use of O_TRUNC on replacing a file should
not hurt performance on other OS's.
On powerpc-darwin I am using HFS+.
Hmm, I think I should drag my firewire drive out and
--
What|Removed |Added
CC||schwinge-bugzilla-gcc dot
||gnu dot org at nic-nac-
--
What|Removed |Added
CC||schwinge-bugzilla-gcc dot
||gnu dot org at nic-nac-
The way MAXPATHLEN is used in jartool.c is wrong, instead of defining a bogus
value on platforms that do not have MAXPATHLEN defined (i.e. GNU) one should try
and use getcwd as follows:
char *dir = getcwd (NULL, 0);
instead of passing a buffer and a size.
This will only work on systems that
--
What|Removed |Added
Component|java|libgcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21822
--- Additional Comments From dorit at il dot ibm dot com 2005-05-30 15:08
---
I also checked if the follow-on fix - http://gcc.gnu.org/ml/gcc-patches/2005-
05/msg02478.html resolves this problem, but it doesn't.
Actually, I think the patch above
The way MAXPATHLEN is used in fixincludes (server.c and fixincl.c) is wrong,
instead of defining a bogus value on platforms that do not have MAXPATHLEN
defined (i.e. GNU) one should try and use getcwd as follows:
char *dir = getcwd (NULL, 0);
instead of passing a buffer and a size.
This will
--
What|Removed |Added
Component|c |other
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
15:10 ---
You should report this to the up stream as GCC just merges with fastjar see the
README in fastjar
directory.
--
What|Removed |Added
--
Summary: [meta-bug] bootstrap bugs for *-gnu*
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: build
Severity: minor
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot
--
What|Removed |Added
Keywords||meta-bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824
--
What|Removed |Added
OtherBugsDependingO||21824
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21822
--
What|Removed |Added
BugsThisDependsOn||21706, 21821, 21822, 21823
Status|UNCONFIRMED |NEW
Ever Confirmed|
--
What|Removed |Added
OtherBugsDependingO||21824
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21821
--
What|Removed |Added
OtherBugsDependingO||21824
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823
--
What|Removed |Added
OtherBugsDependingO||21824
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21706
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2005-05-30 15:15 ---
Subject: Re: Really, really, horrible IO performance
On Mon, May 30, 2005 at 03:00:41PM -, pinskia at gcc dot gnu dot org wrote:
Note, the use of O_TRUNC on replacing a file
--
What|Removed |Added
Keywords||build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21724
--
What|Removed |Added
OtherBugsDependingO||21824
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21724
--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-30 15:17
---
FX,
Can you commit the testcase and close this PR?
steve
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19216
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
15:20 ---
I see the same thing on powerpc-darwin but it seems like on freebsd, it is
actually paging in the
memory which seems wrong, I almost want to say you should report it to freebsd
as their performance
bug
--
What|Removed |Added
Component|libgcj |fastjar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13020
The following code causes segmentation fault with gfortran
PROGRAM TST
CHARACTER(2), PARAMETER :: ETYPE(2,2) =
RESHAPE((/ 'a1','b1','a2','b2' /),(/2,2/))
END PROGRAM TST
gfortran4 -c tst.f90
tst.f90:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with
--
What|Removed |Added
Component|libgcj |fastjar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20941
On i386-mingw32, there is another one of those:
../../gcc/fastjar/jartool.c: In function 'extract_jar':
../../gcc/fastjar/jartool.c:1770: error: too many arguments to function 'mkdir'
Looks like MKDIR_TAKES_ONE_ARG is not defined as it should be.
--
Summary: fastjar does not look to
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
15:29 ---
(In reply to comment #2)
Looks like MKDIR_TAKES_ONE_ARG is not defined as it should be.
Which I filed as PR 21826.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21597
--- Additional Comments From fitzsim at redhat dot com 2005-05-30 15:32
---
There were some changes in how AWT threading works (as well as many other
changes) recently. Can you retry your test and post the results here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17254
--- Additional Comments From mckinlay at redhat dot com 2005-05-30 15:35
---
Its easy to fix this for natFileChannelImpl.cc.
For natFilePosix.cc it is not so simple - is there a portable alternative to
realpath() that does not require the use of MAXPATHLEN / PATH_MAX ?
--
--- Additional Comments From geoffk at geoffk dot org 2005-05-30 15:37
---
Subject: Re: [4.1 Regression] Powerpc atomic builtins missing PPC405 errata
On 29/05/2005, at 6:40 PM, dje at gcc dot gnu dot org wrote:
This is a regression because libstdc++ previously worked correctly
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30
16:14 ---
Subject: Bug 21821
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-30 16:02:40
Modified files:
libjava: ChangeLog
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2005-05-30 16:20 ---
Subject: Re: Really, really, horrible IO performance
On Mon, May 30, 2005 at 03:20:18PM -, pinskia at gcc dot gnu dot org wrote:
I see the same thing on powerpc-darwin but it seems
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30
16:21 ---
Subject: Bug 21784
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-30 16:20:29
Modified files:
gcc/cp : ChangeLog name-lookup.c
--- Additional Comments From ams at gnu dot org 2005-05-30 16:23 ---
(In reply to comment #2)
Its easy to fix this for natFileChannelImpl.cc.
Thank you for fixing it!
For natFilePosix.cc it is not so simple - is there a portable alternative to
realpath() that does not require the
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30
16:29 ---
Subject: Bug 21784
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-30 16:29:05
Modified files:
gcc/cp :
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-30
16:31 ---
Fixed in 4.0.1.
--
What|Removed |Added
Status|ASSIGNED
1 - 100 of 165 matches
Mail list logo
