[Bug libfortran/20179] cannot mix C and Fortran I/O

[cvs-commit at gcc dot gnu dot org]

--- 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 : unix.c 

Log message:
PR libfortran/20179
* io/unix.c (fd_close): Add test so that we don't close()
stdout and stderr.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.231&r2=1.232
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcc&r1=1.26&r2=1.27



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179

[Bug libfortran/20179] cannot mix C and Fortran I/O

[cvs-commit at gcc dot gnu dot org]

--- 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: ChangeLog 
libgfortran/io : unix.c 

Log message:
PR libfortran/20179
* io/unix.c (fd_close): Add test so that we don't close()
stdout and stderr.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.45&r2=1.163.2.46
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.21.10.4&r2=1.21.10.5



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179

[Bug libfortran/20179] cannot mix C and Fortran I/O

[fxcoudert at gcc dot gnu dot org]

--- 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

URL|http://gcc.gnu.org/ml/fortra|
   |n/2005-05/msg00267.html |
  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet|i686-pc-linux-gnu   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179

[Bug libffi/21782] configure: error: unknown endianess

[papadopo at shfj dot cea dot fr]

--- 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 Harbison&Steele.  */
  union
  {
long l;
char c[sizeof (long)];
  } u;
  u.l = 1;
  exit (u.c[sizeof (long) - 1] == 1);
}
$ 
$ /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
/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/include -c -O2 -g -O2  conftest.c
$ echo $?
0
$ 

As far as I can understand the original error message in config.log is:

[...]
configure: In function `main':
configure:3440: error: `bogus' undeclared (first use in this function)
configure:3440: error: (Each undeclared identifier is reported only once
configure:3440: error: for each function it appears in.)
configure:3440: error: syntax error before "endian"
[...]

and it applies to:

#include "confdefs.h"
#include 
#include 
int main() {

#if !BYTE_ORDER || !BIG_ENDIAN || !LITTLE_ENDIAN
 bogus endian macros
#endif
; return 0; }

In the first test, the one that fails, none of BYTE_ORDER, BIG_ENDIAN or
LITTLE_ENDIAN are defined. The configure script then runs a second test which
doesn't fail as shown above. Somehow the configure script takes into account the
first failure.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782

[Bug c/21813] New: dead lock for ftime and strftime in multhithread C program

[sitthisc at gmail dot com]

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.
Loaded symbols for /usr/lib/64/libnsl.so.1
Reading symbols from /usr/lib/64/libsocket.so.1...done.
Loaded symbols for /usr/lib/64/libsocket.so.1
Reading symbols from /usr/lib/64/libthread.so.1...done.
Loaded symbols for /usr/lib/64/libthread.so.1
Reading symbols from /usr/lib/64/librt.so.1...done.
Loaded symbols for /usr/lib/64/librt.so.1
Reading symbols from /usr/lib/64/libm.so.1...done.
Loaded symbols for /usr/lib/64/libm.so.1
Reading symbols from /usr/lib/64/libc.so.1...done.
Loaded symbols for /usr/lib/64/libc.so.1
Reading symbols from /usr/lib/64/libdl.so.1...done.
Loaded symbols for /usr/lib/64/libdl.so.1
Reading symbols from /usr/lib/64/libmp.so.2...done.
Loaded symbols for /usr/lib/64/libmp.so.2
Reading symbols from /usr/lib/64/libaio.so.1...done.
Loaded symbols for /usr/lib/64/libaio.so.1
Reading symbols from /usr/lib/64/libmd5.so.1...done.
Loaded symbols for /usr/lib/64/libmd5.so.1
Loaded symbols for /usr/platform/SUNW,Sun-Fire-280R/lib/sparcv9/libc_psr.so.1
Reading symbols from /usr/lib/64/nss_files.so.1...done.
Loaded symbols for /usr/lib/64/nss_files.so.1
#0  0x3f618928 in __lwp_park () from /usr/lib/64/libthread.so.1
(gdb) up
#1  0x3f614544 in mutex_lock_queue () from /usr/lib/64/libthread.so.1
(gdb) up
#2  0x3f614f80 in slow_lock () from /usr/lib/64/libthread.so.1
(gdb) up
#3  0x3f05c000 in _ltzset () from /usr/lib/64/libc.so.1
(gdb) up
#4  0x3f04213c in ftime () from /usr/lib/64/libc.so.1
(gdb) up
#5  0x000186e4 in GetTime (str=0x7611 "", 
fmt=0x100032810 "%Y%m%d%H", sec=0) at util.h:62
62  ftime(&tt);

Do anybody have any Idea for solve this problem? Thank you.

Note. I'm develope a program in solaris9 with GCC 3.3.2

-- 
   Summary: dead lock for ftime and strftime in multhithread C
program
   Product: gcc
   Version: 3.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sitthisc at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21813

[Bug gcov/profile/21810] -pg causes libexpat code to crash

[oliverst at online dot de]

--- 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

[Bug driver/21814] New: Kernel commpiling segmentation fault

[edvinas at edvinas dot org]

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 error: Segmentation fault (program cc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [floppy.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.30/drivers/block'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.30/drivers/block'
make[1]: *** [_subdir_block] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.30/drivers'
make: *** [_dir_drivers] Error 2

-- 
   Summary: Kernel commpiling segmentation fault
   Product: gcc
   Version: 3.3.5
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edvinas at edvinas dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: Slackware 10.1
  GCC host triplet: ns5.tavo.net
GCC target triplet: Linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21814

[Bug c/21815] New: -E output depends on -g

[joerg dot richter at pdv-fs dot de]

$ 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 ""
# 1 ""
# 1 "a.c"

$ gcc -E -g a.c
# 1 "a.c"
# 1 "/home/jrichter//"
# 1 ""
# 1 ""
# 1 "a.c"

This in conjunction with ccache and multiple users make ccache relative 
senseless (for our environment). Even if this is closed as a non-bug please 
give me a hint where this output is coming from. (So that I can change it in 
our tree)

Failes also with GCC 3.4.3
Works with GCC 3.3.3

-- 
   Summary: -E output depends on -g
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joerg dot richter at pdv-fs dot de
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21815

[Bug libffi/21782] configure: error: unknown endianess

[ebotcazou at gcc dot gnu dot org]

--- 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
> /usr/local/gcc-3.3.6/sparc-sun-solaris2.8/include -c -O2 -g -O2  conftest.c

You have attached the wrong config.log file.  Look at the global log file, the
problem is in sparc-sun-solaris2.8/sparcv9/libffi.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782

[Bug libffi/21782] configure: error: unknown endianess

[papadopo at shfj dot cea dot fr]

--- 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.
Is there anything else I can test?

$ cat > conftest.c
main () {
  /* Are we little or big endian?  From Harbison&Steele.  */
  union
  {
long l;
char c[sizeof (long)];
  } u;
  u.l = 1;
  exit (u.c[sizeof (long) - 1] == 1);
}
$ 
$ /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
/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/include  -m64 -c -O2 -g -O2  
conftest.c
$ 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782

[Bug libffi/21782] configure: error: unknown endianess

[ebotcazou at gcc dot gnu dot org]

--- 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]: *** [configure-target-libffi] Error 1
gmake[1]: Leaving directory `/export/Plocal/GCC-3.3.6'
gmake: *** [bootstrap] Error 2

Apparently something went astray in the configure script for the 64-bit library,
while all worked fine for the 32-bit library.  There have been no changes at
toplevel or in the libffi directory since 3.3.4 was released one year ago.
I think you should give it another try.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782

[Bug libffi/21782] configure: error: unknown endianess

[ebotcazou at gcc dot gnu dot org]

--- 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

[Bug driver/21814] Kernel commpiling segmentation fault

[giovannibajo at libero dot it]

--- 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|Removed |Added

 Status|UNCONFIRMED |WAITING
   Keywords||ice-on-valid-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21814

[Bug libffi/21782] configure: error: unknown endianess

[ebotcazou at gcc dot gnu dot org]

--- 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
> /usr/local/gcc-3.3.6/sparc-sun-solaris2.8/include  -m64 -c -O2 -g -O2 
> conftest.c

That's not exactly the command line, remove the -c and run the executable.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782

[Bug libfortran/16436] gfortran TL edit descriptor failure - test f77-edit-t-in.f

[fxcoudert at gcc dot gnu dot org]

--- 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 days.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-03-17 22:07:43 |2005-05-30 10:51:19
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16436

[Bug libffi/21782] configure: error: unknown endianess

[papadopo at shfj dot cea dot fr]

--- 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

[Bug target/21812] libgcc could use some target specific optimizations

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|other   |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21812

[Bug c/21813] dead lock for ftime and strftime in multhithread C program

[pinskia at gcc dot gnu dot org]

--- 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

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21813

[Bug middle-end/21814] Kernel commpiling segmentation fault

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Severity|critical|normal
  Component|driver  |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21814

[Bug preprocessor/21815] -E output depends on -g

[pinskia at gcc dot gnu dot org]

--- 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

 Status|UNCONFIRMED |RESOLVED
  Component|c   |preprocessor
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21815

[Bug gcov/profile/21810] -pg causes libexpat code to crash

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-30 
11:36 ---
The correct URL for the bug at mingw is:


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810

[Bug libffi/21782] configure: error: unknown endianess

[papadopo at shfj dot cea dot fr]

--- 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
/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/include  -m64 -o conftest -O2 -g -O2
conftest.c
$ 
$ ./conftest
ld.so.1: ./conftest: fatal: /usr/local/lib/libgcc_s.so.1: wrong ELF class:
ELFCLASS32
Killed
$ 
$ env LD_LIBRARY_PATH=/export/Plocal/GCC-3.3.6/gcc/sparcv9 ./conftest
$ echo $?
1
$ 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782

[Bug preprocessor/21815] -E output depends on -g

[joerg dot richter at pdv-fs dot de]

--- 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 directory compiled in. 

And I think there is no reason to output this line unconditional when using -g. 
You can always use absolute paths if you really want the source path compiled 
in.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21815

[Bug libffi/21782] configure: error: unknown endianess

[ebotcazou at gcc dot gnu dot org]

--- 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
> /usr/local/gcc-3.3.6/sparc-sun-solaris2.8/include  -m64 -o conftest -O2 -g -O2
> conftest.c
> $ 
> $ ./conftest
> ld.so.1: ./conftest: fatal: /usr/local/lib/libgcc_s.so.1: wrong ELF class:
> ELFCLASS32
> Killed

Ugh.  Could you add -v to the command line?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782

[Bug libffi/21782] configure: error: unknown endianess

[papadopo at shfj dot cea dot fr]

--- 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. Once I reset LD_LIBRARY_PATH running 'conftest' works:

$ file conftest
conftest:   ELF 64-bit MSB executable SPARCV9 Version 1, dynamically 
linked, not
stripped
$ 
$ ldd conftest
libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1  - wrong ELF 
class: ELFCLASS32
libc.so.1 => /usr/lib/64/libc.so.1
libdl.so.1 =>/usr/lib/64/libdl.so.1
/usr/platform/SUNW,Sun-Blade-1000/lib/sparcv9/libc_psr.so.1
$ 
$ env ldd conftest
libgcc_s.so.1 => 
/export/Plocal/GCC-3.3.6/gcc/sparcv9/libgcc_s.so.1
libc.so.1 => /usr/lib/64/libc.so.1
libdl.so.1 =>/usr/lib/64/libdl.so.1
/usr/platform/SUNW,Sun-Blade-1000/lib/sparcv9/libc_psr.so.1
$ 
$ file -h /usr/local/lib/libgcc_s.so.1
/usr/local/lib/libgcc_s.so.1:   symbolic link to ../gcc-4.0.0/lib/libgcc_s.so.1
$ 


I assume the configure script resets LD_LIBRARY_PATH itself (otherwise it would
hardly be robust) so this is not an issue.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782

[Bug libffi/21782] configure: error: unknown endianess

[papadopo at shfj dot cea dot fr]

--- 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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782

[Bug fortran/21816] New: gfortran rejects simple, valid code

[enok at lysator dot liu dot se]

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
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: enok at lysator dot liu dot se
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21816

[Bug libffi/21782] configure: error: unknown endianess

[papadopo at shfj dot cea dot fr]

--- 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 3.3.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782

[Bug fortran/21816] gfortran rejects simple, valid code

[enok at lysator dot liu dot se]

--- 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=8991&action=view)
Testcase with valid code that fails to compile


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21816

[Bug libffi/21782] configure: error: unknown endianess

[ebotcazou at gcc dot gnu dot org]

--- 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 
> gcc
> 4.

The problem is that conftest is not supposed to depend on libgcc_s so it would
be nice to print the link command line.  Try also to add -static-libgcc to the
GCC command line.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782

[Bug fortran/21816] gfortran rejects simple, valid code

[enok at lysator dot liu dot se]

--- 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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21816

[Bug tree-optimization/21653] [4.1 Regression] gcc.dg/vect failures

[dorit at il dot ibm dot com]

--- 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 reported in PR21155 and PR21789 still remain (these PRs do 
look related, but the fix above apparently did not cover these cases).



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21653

[Bug fortran/21816] gfortran rejects simple, valid code

[enok at lysator dot liu dot se]

--- 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=8992&action=view)
Corrected testcase

Please forget the previous attachment (feel free to remove it if possible) ...

_This_ attachment contains the failing code testcase.

Thanks/
Oskar

-- 
   What|Removed |Added

Attachment #8991 is|0   |1
   obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21816

[Bug fortran/16606] gfortran error with a valid derived type definition

[pinskia at gcc dot gnu dot org]

--- 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

 CC||enok at lysator dot liu dot
   ||se


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16606

[Bug fortran/21816] gfortran rejects simple, valid code

[pinskia at gcc dot gnu dot org]

--- 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

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21816

[Bug tree-optimization/21789] [4.1 regression] ICE with -ftree-vectorize

[dorit at il dot ibm dot com]

--- 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-
05/msg02478.html resolves this problem, but it doesn't.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21789

[Bug fortran/16606] gfortran error with a valid derived type definition

[enok at lysator dot liu dot se]

--- 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 bug. ***

(In reply to comment #5)
> The problem lies with the character pointer in the derived type. Remove the 
> assignement to null and this example compiles.  Try to allocate pd and it 
> fails 
> again.  Change to to fixed length, it is OK, but bombs out again when you 
> assign something to it.  The mixture of derived types and characters seems to 
> be toxic!   CVS 20041202
> 
> (In reply to comment #4)
> > Further reduced to:
> >   TYPE n
> >  CHARACTER, POINTER :: vc => NULL()
> >   END TYPE n
> >   TYPE (n), POINTER :: pd
> > END
> > this is, I believe, indeed valid. Therefor confirmed this time.
> 
> 



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16606

[Bug tree-optimization/21817] New: [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:200

[betasoft at acc dot umu dot se]

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 http://gcc.gnu.org/bugs.html> for instructions.

giraff:~/> /scratch/dva00mkn/gcc-4.0/bin/gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: /scratch/dva00mkn/gcc-4.0.0/configure
--prefix=/scratch/dva00mkn/gcc-4.0 --disable-multilib
Thread model: posix
gcc version 4.0.0

giraff:~/edu/exjobb/src/mkexpl> cat bug.c
typedef float v4sf __attribute__((vector_size(16)));
v4sf value;
void foo(void)
{
   unsigned int band;
   for(band=0; band < 2; band++)
   {
  value += (v4sf){1e9f,1e9f,1e9f,1e9f};
   }
}

Works with 3.4.3

-- 
   Summary: [4.0 Regression] ICE in for_each_index, at tree-ssa-
loop-im.c:200
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: betasoft at acc dot umu dot se
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21817

[Bug tree-optimization/21817] [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:200

[pinskia at gcc dot gnu dot org]

--- 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

 CC||rakdver at gcc dot gnu dot
   ||org, pinskia at gcc dot gnu
   ||dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-valid-code
  Known to fail||4.0.0
  Known to work||3.4.3 4.1.0
   Last reconfirmed|-00-00 00:00:00 |2005-05-30 14:09:29
   date||
   Target Milestone|--- |4.0.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21817

[Bug java/21818] New: "Methods can't be overridden to be more private."

[timo dot lindfors at iki dot fi]

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 can't be overridden to be more private.
Method 'DoubleClickJList.init()' is not private in class 'javax.swing.JList'.
private void init() {
^
1 error

Testcase:
import javax.swing.*;
public class DoubleClickJList extends JList {
private void init() {
}
}

I am not sure if this is a bug or a feature (I have not read any official specs)
but jikes 1.22 and SUN's JVM 1.5.0 seem to compile the testcase just fine. This
means that some free software projects seem to depend on this behavior.

Version info:
gcj (GCC) 4.1.0 20050522 (experimental)
Fedora Core with linux 2.6.11-1.14_FC3

-- 
   Summary: "Methods can't be overridden to be more private."
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: timo dot lindfors at iki dot fi
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21818

[Bug SWING/21818] "Methods can't be overridden to be more private."

[pinskia at gcc dot gnu dot org]

--- 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

 Status|UNCONFIRMED |NEW
  Component|java|SWING
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-30 14:20:15
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21818

[Bug libffi/21819] New: i*86-*-gnu* not enabled in configure.ac

[ams at gnu dot org]

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
  Priority: P2
 Component: libffi
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ams at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-gnu0.3
  GCC host triplet: i686-pc-gnu0.3
GCC target triplet: i686-pc-gnu0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21819

[Bug libfortran/21820] New: Really, really, horrible IO performance

[kargl at gcc dot gnu dot org]

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
   close(1)
   end program kl

We find the following performance on multiple executions.

kargl[225] rm foo.dat
kargl[227] gfc40 -static -o z kl.f90
kargl[228] time ./z
0.11 real 0.05 user 0.05 sys
kargl[229] time ./z
   29.44 real 0.36 user28.13 sys
kargl[230] time ./z
   28.77 real 0.25 user28.07 sys
kargl[231] rm foo.dat
kargl[232] gfc41 -static -o z kl.f90
kargl[233] time ./z
0.23 real 0.06 user 0.05 sys
kargl[234] time ./z
0.11 real 0.05 user 0.06 sys
kargl[235] time ./z
0.11 real 0.03 user 0.08 sys

Here gfc40 is an unpatched gfortran from 4.0.1, and
gfc41 is a patched gfortran from HEAD.  Now, image the
performance if m = 1080 and n = 25000.  Oh, the inhumanity!

See attached patch for suggested fix.

-- 
   Summary: Really, really, horrible IO performance
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820

[Bug java/21818] "Methods can't be overridden to be more private."

[pinskia at gcc dot gnu dot org]

--- 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 JList {
private void init() {
}
}

-- 
   What|Removed |Added

  Component|SWING   |java
   Keywords||rejects-valid


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21818

[Bug other/16406] [3.4 Regression] USE_LD_AS_NEEDED undocumented

[ebotcazou at gcc dot gnu dot org]

--- 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
* configure.ac: Define HAVE_LD_AS_NEEDED only for linux.
* configure: Regenerate.
* gcc.c (init_gcc_specs): Revert earlier change.

-- 
   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
  BugsThisDependsOn||14992


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16406

[Bug libfortran/21820] Really, really, horrible IO performance

[kargl at gcc dot gnu dot org]

--- 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=8994&action=view)
patch to fix problem


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820

[Bug tree-optimization/21734] [4.1 regression] ICE: -ftree-vectorize, segfault

[dorit at il dot ibm dot com]

--- 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

[Bug libffi/21819] i*86-*-gnu* not enabled in configure.ac

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|normal  |enhancement


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21819

[Bug libffi/21782] configure: error: unknown endianess

[ebotcazou at gcc dot gnu dot org]

--- 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 --as-needed -lgcc_s_sparcv9 --no-as-needed -lc
-lgcc --as-needed -lgcc_s_sparcv9 --no-as-needed" passed to the linker.  There
are probably undefined weak symbols in conftest that resolve to symbols in
libgcc_s.  Could you run readelf --syms conftest | grep UND?

--as-needed/--no-as-needed has been introduced by the 2.15 linker and the
compiler autodetects it.  Now, because Solaris doesn't use the --eh-frame-hdr
optimization, there are probably EH-related undefined weak symbols in every
single executable.  The end result is that libgcc_s is always "needed", so the
default has effectively been switched from -static-libgcc to -shared-libgcc.
That's PR bootstrap/14992.

This has been correct in 4.x by:

2004-04-23  Alan Modra  <[EMAIL PROTECTED]>

PR bootstrap/14992
* gcc.c (init_gcc_specs): Test USE_LD_AS_NEEDED, not HAVE_LD_AS_NEEDED.
* config/linux.h (USE_LD_AS_NEEDED): Define.
* gcc/config/alpha/linux.h (USE_LD_AS_NEEDED): Define.
* gcc/config/arm/linux-elf.h (USE_LD_AS_NEEDED): Define.
* gcc/config/rs6000/linux.h (USE_LD_AS_NEEDED): Define.
* gcc/config/rs6000/linux64.h (USE_LD_AS_NEEDED): Define.
* gcc/config/sh/linux.h (USE_LD_AS_NEEDED): Define.
* gcc/config/sparc/linux.h (USE_LD_AS_NEEDED): Define.
* gcc/config/sparc/linux64.h (USE_LD_AS_NEEDED): Define.

and 3.4.x by

2004-04-18  Alan Modra  <[EMAIL PROTECTED]>

PR bootstrap/14992
* configure.ac: Define HAVE_LD_AS_NEEDED only for linux.
* configure: Regenerate.
* gcc.c (init_gcc_specs): Revert earlier change.

but not in 3.3.x.


-- 
   What|Removed |Added

  BugsThisDependsOn||14992
 Status|WAITING |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-30 14:40:07
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782

[Bug java/21821] New: MAXPATHLEN usage in [gcc]/libjava/gnu/java/nio/channels/natFileChannelImpl.cc

[ams at gnu dot org]

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 programs.

Not having MAXPATHLEN is perfectly compliant with POSIX, same goes for
MAXHOSTNAMELEN, PATH_MAX etc.

-- 
   Summary: MAXPATHLEN usage in
[gcc]/libjava/gnu/java/nio/channels/natFileChannelImpl.c
c
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ams at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
 GCC build triplet: i686-pc-gnu0.3
  GCC host triplet: i686-pc-gnu0.3
GCC target triplet: i686-pc-gnu0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21821

[Bug bootstrap/14992] --as-needed patch makes -shared-libgcc the default on some systems

[ebotcazou at gcc dot gnu dot org]

--- 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

 CC||ebotcazou at gcc dot gnu dot
   ||org
OtherBugsDependingO|16406, 21782|
  nThis||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14992

[Bug libgcj/21821] MAXPATHLEN usage in natFileChannelImpl.cc

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|java|libgcj
   Keywords||build
Summary|MAXPATHLEN usage in |MAXPATHLEN usage in
   |[gcc]/libjava/gnu/java/nio/c|natFileChannelImpl.cc
   |hannels/natFileChannelImpl.c|
   |c   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21821

[Bug libgcj/21821] MAXPATHLEN usage in natFileChannelPosix.cc

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|MAXPATHLEN usage in |MAXPATHLEN usage in
   |natFileChannelImpl.cc   |natFileChannelPosix.cc


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21821

[Bug libffi/21819] i*86-*-gnu* not enabled in configure.ac

[ams at gnu dot org]

--- 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=8995&action=view)
Add i*86-*-gnu* to configure.ac

Add GNU to the list of detected systems.

2005-05-30  Alfred M. Szmidt  <[EMAIL PROTECTED]>

* configure.ac: Detect the GNU system.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21819

[Bug libffi/21782] [3.3 Regression] configure: error: unknown endianess

[pinskia at gcc dot gnu dot org]

--- 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

 Status|NEW |RESOLVED
  Known to fail||3.3.6
  Known to work||3.4.0 3.3.3 4.0.0
 Resolution||WONTFIX
Summary|configure: error: unknown   |[3.3 Regression] configure:
   |endianess   |error: unknown endianess
   Target Milestone|--- |3.4.6


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782

[Bug libffi/21782] [3.3 Regression] configure: error: unknown endianess

[ebotcazou at gcc dot gnu dot org]

-- 
   What|Removed |Added

  BugsThisDependsOn||14992
   Target Milestone|3.4.6   |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782

[Bug tree-optimization/21155] [4.1 Regression] ICE in ssa tree check compiling crafty with -ftree-vectorize -maltivec

[dorit at il dot ibm dot com]

--- 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 error on powerpc-apple-darwin in gcc, fma3d and mesa. I don't 
see this error anymore anywhere in SPEC after applying this patch: 
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02478.html (wasn't approved yet)

> Tests gap, facerec,
> and apsi get segfaults in the compiler and resist attempts at mininizing test
> cases.

I don't see these anymore. Maybe this related to PR21639 that was recently 
solved? (after this patch:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02477.html)



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21155

[Bug libfortran/21820] Really, really, horrible IO performance

[pinskia at gcc dot gnu dot org]

--- 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

[Bug bootstrap/21782] [3.3 Regression] configure: error: unknown endianess

[ebotcazou at gcc dot gnu dot org]

--- 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

  Component|libffi  |bootstrap
  Known to fail|3.3.6   |3.3.4 3.3.5 3.3.6
  Known to work|3.4.0 3.3.3 4.0.0   |3.3.3 3.4.0 4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782

[Bug libffi/21819] i*86-*-gnu* not enabled in configure.ac

[pinskia at gcc dot gnu dot org]

--- 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.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||build
   Last reconfirmed|-00-00 00:00:00 |2005-05-30 14:51:30
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21819

[Bug libgcj/21821] MAXPATHLEN usage in libjava

[ams at gnu dot org]

--- 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

Summary|MAXPATHLEN usage in |MAXPATHLEN usage in libjava
   |natFileChannelPosix.cc  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21821

[Bug libffi/21819] i*86-*-gnu* not enabled in configure.ac

[ams at gnu dot org]

--- 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

[Bug libfortran/21820] Really, really, horrible IO performance

[sgk at troutmask dot apl dot washington dot edu]

--- 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 i686-pc-linux-gnu,
> what target are you using?
> 

i386-*-freebsd and amd64-*-freebsd.  The i386 system
is using softupdates on a UFS1 filesystem.  The amd64
system is using softupdates on a UFS2 filesystem.  This
certainly can be a OS dependent problem, and I would 
guess it may affect OpenBSD and NetBSD.

Note, the use of O_TRUNC on replacing a file should 
not hurt performance on other OS's.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820

[Bug libfortran/21820] Really, really, horrible IO performance

[pinskia at gcc dot gnu dot org]

--- 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 try it on the UFS 
partition.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820

[Bug libmudflap/21724] [gcc]/libmudflap/Makefile.am, refusing to install mf-runtime.h in includedir

[schwinge-bugzilla-gcc dot gnu dot org at nic-nac-project dot de]

-- 
   What|Removed |Added

 CC||schwinge-bugzilla-gcc dot
   ||gnu dot org at nic-nac-
   ||project dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21724

[Bug libgcj/21821] MAXPATHLEN usage in libjava

[schwinge-bugzilla-gcc dot gnu dot org at nic-nac-project dot de]

-- 
   What|Removed |Added

 CC||schwinge-bugzilla-gcc dot
   ||gnu dot org at nic-nac-
   ||project dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21821

[Bug java/21822] New: fastjar/jartool.c's usage of MAXPATHLEN

[ams at gnu dot org]

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 use the GNU C Library.

-- 
   Summary: fastjar/jartool.c's usage of MAXPATHLEN
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ams at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
 GCC build triplet: i686-pc-gnu0.3
  GCC host triplet: i686-pc-gnu0.3
GCC target triplet: i686-pc-gnu0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21822

[Bug libgcj/21822] fastjar/jartool.c's usage of MAXPATHLEN

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|java|libgcj


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21822

[Bug tree-optimization/21789] [4.1 regression] ICE with -ftree-vectorize

[dorit at il dot ibm dot com]

--- 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
(http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02478.html)
does solve this ICE (I used a compiler without Keith's patch before).



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21789

[Bug c/21823] New: MAXPATHLEN usage in [gcc]/fixincludes

[ams at gnu dot org]

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 only work on systems that use the GNU C Library.

-- 
   Summary: MAXPATHLEN usage in [gcc]/fixincludes
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ams at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-gnu0.3
  GCC host triplet: i686-pc-gnu0.3
GCC target triplet: i686-pc-gnu0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |other


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823

[Bug fastjar/21822] fastjar/jartool.c's usage of MAXPATHLEN

[pinskia at gcc dot gnu dot org]

--- 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

  Component|libgcj  |fastjar


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21822

[Bug target/21824] New: [meta-bug] bootstrap bugs for *-gnu*

[pinskia at gcc dot gnu dot org]

 

-- 
   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 org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824

[Bug target/21824] [meta-bug] bootstrap bugs for *-gnu*

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||meta-bug


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824

[Bug fastjar/21822] fastjar/jartool.c's usage of MAXPATHLEN

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||21824
  nThis||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21822

[Bug target/21824] [meta-bug] bootstrap bugs for *-gnu*

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  BugsThisDependsOn||21706, 21821, 21822, 21823
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-30 15:14:44
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824

[Bug libgcj/21821] MAXPATHLEN usage in libjava

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||21824
  nThis||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21821

[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||21824
  nThis||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823

[Bug middle-end/21706] MAXPATHLEN usage in [gcc]/gcc/tlink.c

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||21824
  nThis||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21706

[Bug libfortran/21820] Really, really, horrible IO performance

[sgk at troutmask dot apl dot washington dot edu]

--- 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 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 try it on the
> UFS partition.
> 

A little more investigate shows that this may be a mmap problem.

If foo.dat does not exist
   ktrace ./z
   kdump -f ktrace.out | grep mmap | wc -l 
   4

   If foo.dat exists, then I see
   ktrace ./z
   kdump -f ktrace.out | grep mmap | wc -l
   246054

In looking at the ktrace, I see a bunch of segments like

 95157 zCALL  mmap(0,0x2000,0x3,0x1,0x3,0,0,0)
 95157 zRET   mmap 1208418304/0x4807
 95157 zCALL  munmap(0x4807,0x2000)
 95157 zRET   munmap 0
 95157 zCALL  mmap(0,0x2000,0x3,0x1,0x3,0,0,0)
 95157 zRET   mmap 1208418304/0x4807
 95157 zCALL  munmap(0x4807,0x2000)
 95157 zRET   munmap 0
 95157 zCALL  mmap(0,0x2000,0x3,0x1,0x3,0,0,0)
 95157 zRET   mmap 1208418304/0x4807
 95157 zEvents dropped.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820

[Bug libmudflap/21724] [gcc]/libmudflap/Makefile.am, refusing to install mf-runtime.h in includedir

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||build


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21724

[Bug libmudflap/21724] [gcc]/libmudflap/Makefile.am, refusing to install mf-runtime.h in includedir

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||21824
  nThis||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21724

[Bug libfortran/19216] [4.0 only] list directed read with leading slash (NIST FM923)

[kargl at gcc dot gnu dot org]

--- 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

[Bug libfortran/21820] Really, really, horrible IO performance

[pinskia at gcc dot gnu dot org]

--- 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 (Yes working around in libgfortran is still a good idea).

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820

[Bug fastjar/13020] zip-style comments

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|libgcj  |fastjar


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13020

[Bug fortran/21825] New: Segmentation fault on 2D array initialization with reshape

[enok at lysator dot liu dot se]

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 preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
>

-- 
   Summary: Segmentation fault on 2D array initialization with
reshape
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: enok at lysator dot liu dot se
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21825

[Bug fastjar/20941] Incorrect case for META-INF with fastjar

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|libgcj  |fastjar


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20941

[Bug fastjar/21826] New: fastjar does not look to see if mkdir takes one or two arguments

[pinskia at gcc dot gnu dot org]

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 see if mkdir takes one or two
arguments
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P2
 Component: fastjar
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21826

[Bug middle-end/21597] [4.1 Regression] libgcc broken on targets with MKDIR_TAKES_ONE_ARG

[pinskia at gcc dot gnu dot org]

--- 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

[Bug AWT/17254] [java-gui-branch] Hang when resizing AWT window on Alpha

[fitzsim at redhat dot com]

--- 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

[Bug libgcj/21821] MAXPATHLEN usage in libjava

[mckinlay at redhat dot com]

--- 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 ?

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-30 15:35:43
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21821

[Bug target/21760] [4.1 Regression] Powerpc atomic builtins missing PPC405 errata

[geoffk at geoffk dot org]

--- 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  
> on PPC405 and
> now it does not.

That would be due to this patch:

2005-05-25  Paolo Carlini  <[EMAIL PROTECTED]>

 * config/cpu/alpha/atomicity.h: Use the builtins for
 atomic memory operations.
 * config/cpu/powerpc/atomicity.h: Likewise.
 * config/cpu/ia64/atomicity.h: Do not include ia64intrin.h.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21760

[Bug libgcj/21821] MAXPATHLEN usage in libjava

[cvs-commit at gcc dot gnu dot org]

--- 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 
libjava/gnu/java/nio/channels: natFileChannelPosix.cc 

Log message:
2005-05-30  Bryce McKinlay  <[EMAIL PROTECTED]>

PR libgcj/21821
* gnu/java/nio/channels/natFileChannelPosix.cc (open): Don't use
MAXPATHLEN. Format exception message using a StringBuffer instead.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3639&r2=1.3640
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/java/nio/channels/natFileChannelPosix.cc.diff?cvsroot=gcc&r1=1.6&r2=1.7



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21821

[Bug libfortran/21820] Really, really, horrible IO performance

[sgk at troutmask dot apl dot washington dot edu]

--- 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 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
> (Yes working around in libgfortran is still a good idea).

It appears to be a faulty assumption in how gfortran uses mmap.
gfortran appears to assume Linux's behavior:

   (From some version of Redhat)
   MAP_SHARED   Share this mapping with all other processes that map this
object.  Storing to the region is equivalent to writing to
the file.  The file may not actually be updated until
msync(2) or munmap(2) are called.

   (From FreeBSD)
   MAP_SHARED   Modifications are shared.

   MAP_NOSYNC   Causes data dirtied via this VM map to be flushed to
physical media only when necessary (usually by the
pager) rather than gratuitously.  Typically this pre-
vents the update daemons from flushing pages dirtied
through such maps and thus allows efficient sharing of
memory across unassociated processes using a file-
backed shared memory map.  (Much snipped, including a
big warning about ftruncate extending a file).

   (From http://www.opengroup.org/onlinepubs/7990989775/xsh/mmap.html)
   If MAP_SHARED is specified, write references change the underlying object. 

It appears that Linux's MAP_SHARED is equivalent to FreeBSD's
(MAP_SHARED | MAP_NOSYNC).  NetBSD and OpenBSD man pages do not
have the MAP_NOSYNC flag, so they may not be affected.  Note 
POSIX doesn't state anything about when and how the underlying object 
is updated.  POSIX also doesn't include a MAP_NOSYNC flag.

I've verified that the following patch works and improves
performance, but I prefer the original O_TRUNC patch because
O_TRUNC is a POSIX flag and AFAIK most OS's implement it.

Index: unix.c
===
RCS file: /cvs/gcc/gcc/libgfortran/io/unix.c,v
retrieving revision 1.26
diff -c -p -r1.26 unix.c
*** unix.c  17 May 2005 16:54:51 -  1.26
--- unix.c  30 May 2005 16:06:54 -
*** mmap_alloc (unix_stream * s, gfc_offset 
*** 622,628 
  
length = ((where - offset) & page_mask) + 2 * page_size;
  
!   p = mmap (NULL, length, s->prot, MAP_SHARED, s->fd, offset);
if (p == (char *) MAP_FAILED)
  return FAILURE;
  
--- 622,628 
  
length = ((where - offset) & page_mask) + 2 * page_size;
  
!   p = mmap (NULL, length, s->prot, MAP_SHARED | MAP_NOSYNC, s->fd, offset);
if (p == (char *) MAP_FAILED)
  return FAILURE;




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820

[Bug c++/21784] [3.4/4.0/4.1 Regression] Using vs builtin names

[cvs-commit at gcc dot gnu dot org]

--- 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 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/lookup: using14.C 

Log message:
PR c++/21784
* name-lookup.c (do_nonmember_using_decl): Ignore builtin
functions, even when the used name is not a function.

PR c++/21784
* g++.dg/lookup/using14.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4765&r2=1.4766
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcc&r1=1.120&r2=1.121
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5559&r2=1.5560
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/using14.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21784

[Bug libgcj/21821] MAXPATHLEN usage in libjava

[ams at gnu dot org]

--- 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 use of MAXPATHLEN / PATH_MAX ?

One can call realpath() with NULL for the second parameter on systems that do
not have MAXPATHLEN/PATH_MAX.  You could also use canonicalize_file_name(), but
this is a GNU C library specific function.

 -- Function: char * realpath (const char *restrict NAME, char
  *restrict RESOLVED)
...
 On systems which define `PATH_MAX'
 this means the buffer must be large enough for a pathname of this
 size.  For systems without limitations on the pathname length the
 requirement cannot be met and programs should not call `realpath'
 with anything but `NULL' for the second parameter.

 -- Function: char * canonicalize_file_name (const char *NAME)
 The `canonicalize_file_name' function returns the absolute name of
 the file named by NAME which contains no `.', `..' components nor
 any repeated path separators (`/') or symlinks.  The result is
 passed back as the return value of the function in a block of
 memory allocated with `malloc'.  If the result is not used anymore
 the memory should be freed with a call to `free'.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21821

[Bug c++/21784] [3.4/4.0/4.1 Regression] Using vs builtin names

[cvs-commit at gcc dot gnu dot org]

--- 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 : ChangeLog name-lookup.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/lookup: using14.C 

Log message:
PR c++/21784
* name-lookup.c (do_nonmember_using_decl): Ignore builtin
functions, even when the used name is not a function.

PR c++/21784
* g++.dg/lookup/using14.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.49&r2=1.4648.2.50
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.109.4.3&r2=1.109.4.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.209&r2=1.5084.2.210
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/using14.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.2.2.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21784

[Bug c++/21784] [3.4/4.0/4.1 Regression] Using vs builtin names

[mmitchel at gcc dot gnu dot org]

--- 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|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21784

[Bug middle-end/21743] Enable __builtin_clog

[mmitchel at gcc dot gnu dot org]

-- 
Bug 21743 depends on bug 21784, which changed state.

Bug 21784 Summary: [3.4/4.0/4.1 Regression] Using vs builtin names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21784

   What|Old Value   |New Value

 Status|UNCONFIRMED |NEW
 Status|NEW |ASSIGNED
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21743

[Bug c++/21784] [3.4/4.0/4.1 Regression] Using vs builtin names

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-05-30 
16:34 ---
Isn't this a 3.4 regression as well?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21784