[Bug tree-optimization/34563] noinline function call being removed

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-12-23 04:18 ---
So we have:
 if (ii (_double_.fp))
   ss = 0;
 cvt (_double_.fp, &ss);

ss is always set via cvt (and cvt is inlined), so we dce the first setting of
ss and that in turns dce the function call to ii as it is pure.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|noinline function being |noinline function call being
   |inlined |removed


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

[Bug tree-optimization/34563] noinline function being inlined

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2007-12-23 04:05 ---
Revisions 130556 for native and 131139 for cris-elf.


-- 


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

[Bug tree-optimization/34563] noinline function being inlined

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2007-12-23 04:04 ---
Created an attachment (id=14808)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14808&action=view)
Compile with -O2


-- 


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

[Bug tree-optimization/34563] New: noinline function being inlined

[hp at gcc dot gnu dot org]

With -O2, the function ii, called from function m in the attached file, is
inlined, despite the noinline attribute. There is an outlined ii emitted, but
no call to it in function m.  The code is an failed attempt to synthesize a
test-case for another bug (though for the record the failure isn't just because
of the inlining). Not being able to trivially stop inlining for otherwise
trivial calls is troublesome in this case, while possibly a mere wart for real
code.


-- 
   Summary: noinline function being inlined
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu, cris-axis-elf


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[bdavis at gcc dot gnu dot org]

--- Comment #15 from bdavis at gcc dot gnu dot org  2007-12-23 03:07 ---
the test cases are great...but they show too many bugs !!  can't decide whether
to go for the 'grand unified solution' or just hit them one at a time :)


--bud


-- 


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

[Bug fortran/34559] Regression 4.3: ICE using REPEAT on string literals

[dfranke at gcc dot gnu dot org]

--- Comment #4 from dfranke at gcc dot gnu dot org  2007-12-22 22:19 ---
Fixed in trunk. Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/34559] Regression 4.3: ICE using REPEAT on string literals

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2007-12-22 22:18 ---
Subject: Bug 34559

Author: dfranke
Date: Sat Dec 22 22:18:28 2007
New Revision: 131139

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131139
Log:
gcc/fortran:
2007-12-22  Daniel Franke  <[EMAIL PROTECTED]>

PR fortran/34559
* simplify.c (gfc_simplify_repeat): Added safeguard for empty string
literals.

gcc/testsuite:
2007-12-22  Daniel Franke  <[EMAIL PROTECTED]>

PR fortran/34559
* gfortran.dg/repeat_6.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/repeat_6.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/34560] Regression 4.3: I/O internal read: END expected, but no failure

[tkoenig at gcc dot gnu dot org]

-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-12-22 20:35:26 |2007-12-22 21:57:25
   date||


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

[Bug middle-end/34562] New: FAIL: g++.dg/other/first-global.C scan-assembler _GLOBAL__I_foobar

[danglin at gcc dot gnu dot org]

Instead of _GLOBAL__I_foobar, we have _GLOBAL__I_65535_0_foobar.
This arises as follows:

(gdb) p (char *)$r26
$1 = 0x7eff0bc8 "I_65535_0"
(gdb) bt
#0  get_file_function_name (
type=0x49 )
at ../../gcc/gcc/tree.c:6716
#1  0x004b7db0 in cgraph_build_static_cdtor (which=73 'I', body=0x7ae59660,
priority=65535) at ../../gcc/gcc/cgraphunit.c:1474
#2  0x004b8348 in build_cdtor (ctor_p=1 '\001', cdtors=0x7ae592e8, len=1)
at ../../gcc/gcc/cgraphunit.c:236
#3  0x004baf8c in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:306
#4  0x000e7664 in cp_write_global_declarations ()
at ../../gcc/gcc/cp/decl2.c:3429
#5  0x003bb72c in toplev_main (argc=1074132200, argv=0x4005f5f8)
at ../../gcc/gcc/toplev.c:1055
#6  0x00200f8c in main (argc=2130643912, argv=0x6) at ../../gcc/gcc/main.c:35

Should the test be changed to also allow a constructor with priority and
counter in the name?


-- 
   Summary: FAIL: g++.dg/other/first-global.C scan-assembler
_GLOBAL__I_foobar
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa2.0w-hp-hpux11.11
  GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11


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

[Bug fortran/34556] Rejects valid with bogus error message: parameter initalization

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2007-12-22 21:25 ---
Confirmed.

Simplified testcase:

  integer :: a(2,2) = reshape( (/ max((/ 1,2 /), (/ 3,4 /)), (/4,5/) /),
(/2,2/))
end

It seems that the array-valued MAX is crucial here. If removed or replaced by a
scalar-valued MAX, it works as expected. OTOH, removing RESHAPE works as well.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-12-22 21:25:55
   date||


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

[Bug bootstrap/34561] Cannot build compiler for Mac Intel under Leopard

[rogermc at iinet dot net dot au]

--- Comment #1 from rogermc at iinet dot net dot au  2007-12-22 21:07 
---
Created an attachment (id=14807)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14807&action=view)
config.log


-- 


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

[Bug bootstrap/34561] New: Cannot build compiler for Mac Intel under Leopard

[rogermc at iinet dot net dot au]

Model Identifier:   Macmini1,1
 Processor Name:Intel Core Duo
Mac OS X 10.5.1 (Leopard)

SVN Revision: 131138

Following is my record of my attempt and final success in building gcc:

../gcc/configure
make

produced error:
at
/bin/sh ../../../../gcc/libgcc/../mkinstalldirs x86_64
mkdir x86_64
/gcc-devel2/build/./gcc/xgcc -B/gcc-devel2/build/./gcc/

ld: warning in /usr/lib/dylib1.10.5.o, file is not of required architecture
ld: symbol dyld_stub_binding_helper not defined (usually in
crt1.o/dylib1.o/bundle1.o)
collect2: ld returned 1 exit status
make[5]: *** [libgcc_s.dylib] Error 1

Build fails to find
/Developer/SDKs/MacOSX10.5.sdk/usr/lib
required for apparent access to the files:
crt1.o,  dylib1.o, bundle1.o

Attempts to overcome error:

LDFLAGS=-L/Developer/SDKs/MacOSX10.5.sdk/usr/lib
export LDFLAGS
FLAGS_FOR_TARGET=-B/Developer/SDKs/MacOSX10.5.sdk/usr/lib
export LDFLAGS
../gcc/configure

Checked config.log:
LDFLAGS='-L/Developer/SDKs/MacOSX10.5.sdk/usr/lib'
LDFLAGS_FOR_BUILD='-L/Developer/SDKs/MacOSX10.5.sdk/usr/lib'

FLAGS_FOR_TARGET doesn't include -B/Developer/SDKs/MacOSX10.5.sdk/usr/lib

Manually added
 -B/Developer/SDKs/MacOSX10.5.sdk/usr/lib/
to
FLAGS_FOR_TARGET
of  build/Makefile

make

Error:
libtool: link: ( cd ".libs" && rm -f "libgcj-tools.la" && ln -s
"../libgcj-tools.la" "libgcj-tools.la" )
/bin/sh ./libtool --tag=GCJ --mode=link /gcc-devel2/build/gcc/gcj  ...

ld: could not find entry point "start" (perhaps missing crt1.o)
collect2: ld returned 1 exit status
make[5]: *** [jv-convert] Error 1

Added
 -B/Developer/SDKs/MacOSX10.5.sdk/usr/lib
to
GCJFLAGS
of
build/i386-apple-darwin9.1.0/libjava/testsuite/Makefile

Following these changes, the build ran to completion.


-- 
   Summary: Cannot build compiler for Mac Intel under Leopard
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rogermc at iinet dot net dot au


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

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include

[dje at watson dot ibm dot com]

--- Comment #15 from dje at watson dot ibm dot com  2007-12-22 20:52 ---
Subject: Re:  AIX g++ -D_LARGE_FILES fails to compile #include  

> tcoleman at autowares dot com writes:

Tom> Does G++ really have to be either one way or the other?  Can't it also
include
Tom> conditional code to check for _LARGE_FILES?  Maybe I'm missing something
here.

GNU libc does not use _LARGE_FILE to distinguish large offsets in
32-bit file I/O.  Why would the GCC libstdc++ community be interested in
complicating its header files with AIX-specific checks?


-- 


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

[Bug fortran/34560] Regression 4.3: I/O internal read: END expected, but no failure

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2007-12-22 20:40 ---
Simplified test case:

$ cat eof.f90 
program main
  character(len=2) :: line
  character(len=1) :: a(3)
  line = 'ab'
  read (line,'(A)',end=99) a
  stop
  99 continue 
end program main
$ gfortran -g eof.f90 
$ gdb ./a.out
GNU gdb 6.6.90.20070912-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1".
(gdb) r
Starting program: /tmp/a.out 

Program received signal SIGSEGV, Segmentation fault.
0xb7da6665 in memcpy () from /lib/i686/cmov/libc.so.6
(gdb) bt
#0  0xb7da6665 in memcpy () from /lib/i686/cmov/libc.so.6
#1  0xb7f493a4 in *_gfortrani_read_sf (dtp=0xbfd46074, length=0xbfd45dd8, 
no_error=0) at ../../../../gcc/trunk/libgfortran/io/transfer.c:169
#2  0xb7f49574 in *_gfortrani_read_block (dtp=0xbfd46074, length=0xbfd45dd8)
at ../../../../gcc/trunk/libgfortran/io/transfer.c:318
#3  0xb7f47328 in *_gfortrani_read_a (dtp=0xbfd46074, f=0x8050568, 
p=0xbfd461a7 "·ÈaÔ¿9\207\004\b\001", length=1)
at ../../../../gcc/trunk/libgfortran/io/read.c:248
#4  0xb7f4ad4e in formatted_transfer_scalar (dtp=0xbfd46074, 
type=BT_CHARACTER, p=0xbfd461a7, len=1, size=1)
at ../../../../gcc/trunk/libgfortran/io/transfer.c:1121
#5  0xb7f4b81e in formatted_transfer (dtp=0xbfd46074, type=BT_CHARACTER, 
p=0xbfd461a5, kind=1, size=1, nelems=3)
at ../../../../gcc/trunk/libgfortran/io/transfer.c:1366
#6  0xb7f484de in *_gfortran_transfer_array (dtp=0xbfd46074, desc=0xbfd46188, 
kind=1, charlen=1) at ../../../../gcc/trunk/libgfortran/io/transfer.c:1518
#7  0x080486d1 in main () at eof.f90:5


-- 


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

[Bug fortran/34559] Regression 4.3: ICE using REPEAT on string literals

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2007-12-22 20:40 ---
Fixed.

Index: simplify.c
===
--- simplify.c  (revision 131122)
+++ simplify.c  (working copy)
@@ -3128,7 +3128,9 @@ gfc_simplify_repeat (gfc_expr *e, gfc_ex
   if (e->expr_type != EXPR_CONSTANT)
 return NULL;

-  if (len || mpz_sgn (e->ts.cl->length->value.integer) != 0)
+  if (len ||
+  (e->ts.cl->length &&
+   mpz_sgn (e->ts.cl->length->value.integer)) != 0)
 {
   const char *res = gfc_extract_int (n, &ncop);
   gcc_assert (res == NULL);


(not yet regression tested, obviously)


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org


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

[Bug fortran/34560] Regression 4.3: I/O internal read: END expected, but no failure

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2007-12-22 20:35 ---
Confirmed.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-12-22 20:35:26
   date||


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

[Bug fortran/34559] Regression 4.3: ICE using REPEAT on string literals

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2007-12-22 20:31 ---
Confirmed.

Simplified test case:

$ cat npr.f90 
program main
  print *, repeat ("", 3)
end program main
$ gfortran npr.f90 
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-12-22 20:31:59
   date||


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

[Bug target/20366] AIX g++ -D_LARGE_FILES fails to compile #include

[tcoleman at autowares dot com]

--- Comment #14 from tcoleman at autowares dot com  2007-12-22 20:18 ---
(In reply to comment #12)

I don't see it as so much a matter of "focus".  

A lot of applications test for _LARGE_FILES in the C library and will set it as
a configuration option if supported.  As far as straight C goes, there's no
problem with gcc on AIX.

But if _LARGE_FILES is set, the fact that g++ can't compile C++ applications
using cstdio on AIX is a source of both frustration and annoyance.

Does G++ really have to be either one way or the other?  Can't it also include
conditional code to check for _LARGE_FILES?  Maybe I'm missing something here.


-- 


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

[Bug fortran/34560] New: Regression 4.3: I/O internal read: END expected, but no failure

[burnus at gcc dot gnu dot org]

The following program should print "OK". This is a regression as gfortran 4.1.3
and 4.2.2 print "OK" and not "FAIL" as gfortran 4.3.0.

(Found using the Fortran Company Fortran 90 Test Suite (Lite), Version 1.4)

implicit none
integer :: i
! NAME_FIELD is an internal file.
CHARACTER * 80 :: NAME_FIELD
integer::name_array(17)=0
do i=1,16
  write(name_field(5*i-4:5*i),"(i5)")i
end do
! If the array NAME_ARRAY has more than 16 elements,
!   an end-of-file condition will occur and the statement
!   labeled 98 will be executed next.
READ (NAME_FIELD, 100, END=98) NAME_ARRAY
100 FORMAT (16I5)
97 print*,'FAIL - expected END=98'
stop
98 print*,'OK'
end


-- 
   Summary: Regression 4.3: I/O internal read: END expected, but no
failure
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 32834
 nThis:


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

[Bug libfortran/34540] cshift, eoshift, kind=1 and kind=2 arguments...

[jvdelisle at gcc dot gnu dot org]

--- Comment #15 from jvdelisle at gcc dot gnu dot org  2007-12-22 19:22 
---
Thomas, hope you don't mind me taking this over.  This last bug is a different
problem all together.  I am hoping we don't have to redesign the
implementation.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|tkoenig at gcc dot gnu dot  |jvdelisle at gcc dot gnu dot
   |org |org
 Status|REOPENED|ASSIGNED


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

[Bug fortran/34559] New: Regression 4.3: ICE using REPEAT on string literals

[burnus at gcc dot gnu dot org]

==27207== Invalid read of size 4
==27207==at 0x46E5F6: gfc_simplify_repeat (simplify.c:3131)
==27207==by 0x42AE72: do_simplify (intrinsic.c:3180)
==27207==by 0x42BD39: gfc_intrinsic_func_interface (intrinsic.c:3446)
==27207==by 0x45FCA9: gfc_resolve_expr (resolve.c:1629)
==27207==by 0x461BD3: resolve_operator (resolve.c:2854)

! Regression. ICE on valid code
! Works with 4.1.2 and 4.2.2, but fails with 4.3.0
! (segmentation fault).
!
! Found using the Fortran Company Fortran 90 Test Suite (Lite),
! Version 1.4
program npr
implicit none
print *, "a" // repeat ("", 3) // repeat ("xxx", 0) // &
repeat ("string", 4)
end program npr


-- 
   Summary: Regression 4.3: ICE using REPEAT on string literals
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 32834
 nThis:


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

[Bug fortran/34558] New: Regression 4.3: ICE with same TYPE in both program and interface

[burnus at gcc dot gnu dot org]

The following program uses an excessive amount of memory, which causes the
segmentation fault. valgrind shows:

==27188== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==27188==  Access not within mapped region at address 0x7FE001700
==27188==at 0x427539: gfc_compare_derived_types (interface.c:365)
==27188== Invalid write of size 8
==27188==at 0x4A1E348: _vgnU_freeres (in
/usr/lib64/valgrind/amd64-linux/vgpreload_core.so)
==27188==  Address 0x7fe001f70 is on thread 1's stack
==27188== Stack overflow in thread 1: can't grow stack to 0x7FE001F70

! Regression. ICE on valid code.
! The following works with 4.1.3 and 4.2.2, but fails
! (segmentation fault) with 4.3.0.
!
! Found using the Fortran Company Fortran 90 Test Suite (Lite),
! Version 1.4
program error
  implicit none
  type node
sequence
type(node), pointer :: next
  end type
  type(node), pointer :: list

  interface
subroutine insert(ptr)
  implicit none
  type node
sequence
type(node), pointer :: next
  end type
  type(node), pointer :: ptr
end subroutine insert
  end interface
  allocate (list);
end program error


-- 
   Summary: Regression 4.3: ICE with same TYPE in both program and
interface
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 32834
 nThis:


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

[Bug fortran/34557] New: Rejects valid: EQUIVALENCE of character substrings

[burnus at gcc dot gnu dot org]

! Rejects valid. EQUIVALENCE of substrings; fails with 4.[1-3].x with:
!
!EQUIVALENCE (A (2,1) (1:1), B (1) (2:3), C (3:5))
!   1
!Error: Syntax error in EQUIVALENCE statement at (1)
!
! Found using the Fortran Company Fortran 90 Test Suite (Lite),
! Version 1.4
CHARACTER A(2,2)*2, B(2)*3, C*5
EQUIVALENCE (A (2,1) (1:1), B (1) (2:3), C (3:5))
end


-- 
   Summary: Rejects valid: EQUIVALENCE of character substrings
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 32834
 nThis:


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

[Bug fortran/34556] New: Rejects valid with bogus error message: parameter initalization

[burnus at gcc dot gnu dot org]

! Rejects-valid. Fails with gfortran 4.1, 4.2 and 4.3
! For 4.3 the error message is:
!
!(/ linem, nplam /) )
! 1
!Error: Invalid character in name at (1)
!
! Found using the Fortran Company Fortran 90 Test Suite (Lite),
! Version 1.4
module splitprms
  integer, parameter  :: nplam = 3 ! # of plans to expand TABs
  integer, parameter  :: linem = 132 ! max. line length
  integer, parameter  :: ncntm = 39 ! max. # cont. lines
  integer, parameter, dimension (linem, nplam) :: nxttab =  &
  reshape ( &
   (/ max( (/ (6+3*((i-6+3)/3), i= 1,linem),&
  (6+2*((i-6+2)/2), i= 1,linem) /), &
   (/ (6, i= 1, 2*linem) /)),   &
  (/  (i, i= 1,linem) /) /),&
(/ linem, nplam /) )
end module splitprms


-- 
   Summary: Rejects valid with bogus error message: parameter
initalization
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 32834
 nThis:


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

[Bug c++/33802] g++ says `z' is used uninitialized but this is not true

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2007-12-22 18:02 ---
(In reply to comment #1)
> Created an attachment (id=14366)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14366&action=view) [edit]
> (Big) testcase that allows to reproduce
> 
I can't compile the testcase with cc1plus 4.3 revision 130379. I get a lot of
warnings and a few errors. Perhaps I need to include something else ?


Anyway, the relevant SSA is:


 # BLOCK 195, starting at line 37941
  # PRED: 194 (true)
:;
  #   VUSE ;
  [/home/manuel/src/pr33802.C : 37941] z.1689D.225422_240 = zD.225363;
  [/home/manuel/src/pr33802.C : 37941] *toD.225359_119 = z.1689D.225422_240;
  [/home/manuel/src/pr33802.C : 37942] D.225423_241 = rD.225364_141;
  goto  ();
  # SUCC: 213 (fallthru)

Wuninitialized cannot handle virtual operands, so it doesn't understand that z
could have been initialized. Funny enough, this is exactly the opposite of bug
179 but both SSA dumps look very similar. I really don't understand why we warn
in one case and not in the other.

By the way, what does 

  #   VUSE ;

exactly means? I cannot find any other mention of zD.225363_219.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-12-22 18:02:52
   date||


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

[Bug middle-end/24306] [4.0 Regression] va_arg gets confused when skipping over certain zero-sized types with -msse

[howarth at nitro dot med dot uc dot edu]

--- Comment #18 from howarth at nitro dot med dot uc dot edu  2007-12-22 
17:51 ---
For tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o-c_compat_y_tst.o on
powerpc-apple-darwin9 at -m64, the failing line in t026_test.h is...

T(2468,float a;long double b;Tchar c;Tal8llong
d;,F(2468,a,3100.906250,83925.484375)F(2468,b,-156603.906250,244908.156250)F(2468,c,99U,35U)F(2468,d,5510104998541940327LL,8962187912153613792LL))


-- 


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

[Bug fortran/34549] cshifting by a real value

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2007-12-22 17:47 ---
Fixed on trunk.  Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/34549] cshifting by a real value

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2007-12-22 17:44 ---
Subject: Bug 34549

Author: tkoenig
Date: Sat Dec 22 17:43:54 2007
New Revision: 131136

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131136
Log:
2007-12-22  Thomas Koenig  <[EMAIL PROTECTED]>

PR fortran/34549
* check.c (gfc_check_cshift):  Add check that shift is
type INTEGER.

2007-12-22  Thomas Koenig  <[EMAIL PROTECTED]>

PR fortran/34549
* cshift_shift_real_1.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/cshift_shift_real_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/24306] [4.0 Regression] va_arg gets confused when skipping over certain zero-sized types with -msse

[howarth at nitro dot med dot uc dot edu]

--- Comment #17 from howarth at nitro dot med dot uc dot edu  2007-12-22 
17:37 ---
For tmpdir-gcc.dg-struct-layout-1/t016 c_compat_x_tst.o-c_compat_y_tst.o on
powerpc-apple-darwin9 at -m64, the failing line in t016_test.h is...

T(1604,char a;TE7 b;enum E6 c;unsigned int d;long int e;char f[6];float g;short
int atal16 h;int *
i;,F(1604,a,76U,30U)F(1604,b,e7_m2147483647,e7_m2147483645)F(1604,c,e6_2,e6_2)F(1604,d,3007045619U,3425526240U)F(1604,e,7127725064803830888LL,2212588498547332024LL)F(1604,f[4],64U,30U)F(1604,g,-67359.484375,-251776.203125)F(1604,h,17064,8859)F(1604,i,(int
*)&intarray[89], (int *)&intarray[249]))


-- 


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

[Bug middle-end/24306] [4.0 Regression] va_arg gets confused when skipping over certain zero-sized types with -msse

[howarth at nitro dot med dot uc dot edu]

--- Comment #16 from howarth at nitro dot med dot uc dot edu  2007-12-22 
17:16 ---
For tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o on
powerpc-apple-darwin9 at -m64, the failing line in t008_test.h is...

T(1234,double a;signed char atal16 b;union{unsigned int d;struct{}e;}c;short
int f;unsigned char
g;,F(1234,a,-125234.421875,-6063.015625)F(1234,b,-105,88)F(1234,c.d,3504478143U,3116938342U)F(1234,f,-15109,-23068)F(1234,g,236U,127U))


-- 


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

[Bug target/29524] [4.2/4.3 Regression] Too much RAM used: __clz_tab[] linked

[j at uriah dot heep dot sax dot de]

--- Comment #15 from j at uriah dot heep dot sax dot de  2007-12-22 17:15 
---
(In reply to comment #14)

> Note that the use of clz for the avr is avoided by using avr-libc's math
> library.

Not confirmed.  A simple test program using a floating point number:

#include 
#include 

volatile floata;

int main (void) 
{
 a=ADCH; 
}

results in 256 bytes of RAM allocation for __clz_tab[].


-- 


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

[Bug middle-end/24306] [4.0 Regression] va_arg gets confused when skipping over certain zero-sized types with -msse

[howarth at nitro dot med dot uc dot edu]

--- Comment #15 from howarth at nitro dot med dot uc dot edu  2007-12-22 
16:56 ---
For tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o on
powerpc-apple-darwin9 at -m64, the line in t005_test.h that causes the testcase
failure is...

T(998,df a;Talllong b:BQN(20);long long int c:BQN(1);TE4 d:19;long int
e;,F(998,a,140017.484375,-160009.218750)B(998,b,-303431,345440)B(998,c,0,0)B(998,d,e4_253,e4_2)F(998,e,3562377756672343063LL,5761410617366885841LL))


-- 


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

[Bug tree-optimization/34465] [4.3 Regression] incorrect sharing of tree nodes

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.3.0


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

[Bug middle-end/24306] [4.0 Regression] va_arg gets confused when skipping over certain zero-sized types with -msse

[howarth at nitro dot med dot uc dot edu]

--- Comment #14 from howarth at nitro dot med dot uc dot edu  2007-12-22 
16:41 ---
For tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o on
powerpc-apple-darwin9 at -m64, the two lines in t003_test.h that cause the
failure are...

T(693,double atal2 a;Tal16long b;short int
c;struct{}d;,F(693,a,-9109.968750,89665.703125)F(693,b,-2780362564512530142LL,-188249301918206LL)F(693,c,29451,-6341))

and

T(760,float a;long double b;unsigned long int c;signed char
d;,F(760,a,-218391.812500,-167965.062500)F(760,b,-122404.406250,-90172.859375)F(760,c,2933687826322174624ULL,14862826394269793540ULL)F(760,d,55,64))


-- 


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

[Bug libfortran/34540] cshift, eoshift, kind=1 and kind=2 arguments...

[jvdelisle at gcc dot gnu dot org]

--- Comment #14 from jvdelisle at gcc dot gnu dot org  2007-12-22 16:39 
---
No, I checked the original case for pr33317 and it segfaults on compilation
with the change in comment #13.  This means the testcase optional_dim_2.f90 is
not sufficient.  I will fix that along the way here.


-- 


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

[Bug libfortran/34540] cshift, eoshift, kind=1 and kind=2 arguments...

[jvdelisle at gcc dot gnu dot org]

--- Comment #13 from jvdelisle at gcc dot gnu dot org  2007-12-22 16:28 
---
This is surprising!  If I get rid of the hack that was needed before for
optional_dim_2.f90 :

Index: iresolve.c
===
--- iresolve.c  (revision 131133)
+++ iresolve.c  (working copy)
@@ -590,12 +590,6 @@ gfc_resolve_cshift (gfc_expr *f, gfc_exp

   if (dim != NULL)
 {
-  if (dim->expr_type != EXPR_CONSTANT &&
dim->symtree->n.sym->attr.optional)
-   {
- /* Mark this for later setting the type in gfc_conv_missing_dummy. 
*/
- dim->representation.length = shift->ts.kind;
-   }
-  else
{
  gfc_resolve_dim_arg (dim);
  /* Convert dim to shift's kind to reduce variations.  */

The new case passes (for cshift and I would presume eoshift) and the
optional_dim_2.f90 passes and I see no apparent regressions.  Still testing.

This means something got fixed somewhere else. I also checked this on
ppc64-linux with the same result.


-- 


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

[Bug libfortran/34540] cshift, eoshift, kind=1 and kind=2 arguments...

[jvdelisle at gcc dot gnu dot org]

--- Comment #12 from jvdelisle at gcc dot gnu dot org  2007-12-22 16:04 
---
This latest issue is not a regression so I changed the summary.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.3 Regression] cshift,|cshift, eoshift, kind=1 and
   |eoshift, kind=1 and kind=2  |kind=2 arguments...
   |arguments...|


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

[Bug bootstrap/34555] configure: error: `CXX' has changed since the previous run:

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2007-12-22 15:47 ---
I just noticed I forgot to remove previous build.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug bootstrap/34555] New: configure: error: `CXX' has changed since the previous run:

[danglin at gcc dot gnu dot org]

This is the second time I have seen this.  It's with
make -j4 bootstrap

...
checking whether the /home/dave/gnu/gcc-4.3/objdir/./gcc/xgcc
-B/home/dave/gnu/gcc-4.3/objdir/./gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/include -isystem
/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/sys-include linker
(/home/dave/gnu/gcc-4.3/objdir/./gcc/collect-ld) supports shared libraries...
yes
checking whether -lc should be explicitly linked in... configure: loading cache
./config.cache
configure: error: `CXX' has changed since the previous run:
configure:   former value:  /home/dave/gnu/gcc-4.3/objdir/./gcc/g++
-B/home/dave/gnu/gcc-4.3/objdir/./gcc/ -nostdinc++ 
-L/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/src
-L/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/src/.libs
-B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/include -isystem
/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/sys-include
configure:   current value: /home/dave/gnu/gcc-4.3/objdir/./gcc/g++
-B/home/dave/gnu/gcc-4.3/objdir/./gcc/ -nostdinc++ -nostdinc++
-I/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/hppa-linux
-I/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include
-I/home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/testsuite/util
-L/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/src
-L/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/src/.libs
-B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/include -isystem
/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/sys-include
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm ./config.cache' and start
over
no
...
make[1]: *** [configure-target-boehm-gc] Error 1
make[1]: *** Waiting for unfinished jobs
...
make[1]: Leaving directory `/home/dave/gnu/gcc-4.3/objdir'
make: *** [bootstrap] Error 2


-- 
   Summary: configure: error: `CXX' has changed since the previous
run:
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


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

[Bug libfortran/34540] [4.3 Regression] cshift, eoshift, kind=1 and kind=2 arguments...

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2007-12-22 15:00 
---
I get a segfault.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug bootstrap/34481] stage3-intl: error: C compiler cannot create executables

[andry at inbox dot ru]

--- Comment #2 from andry at inbox dot ru  2007-12-22 13:56 ---
(In reply to comment #1)
> can you try not building in the source directory and use an building 
> directory?
> 
The same.
May be i missed something to install?
Here my list of components which i checked when installing cygwin:
  - [Bin] All->Devel->gcc-g++: C++ compiler
  - [Bin] All->Devel->make: The GNU version of the 'make' utility
  - [Bin] All->Devel->perl-ExtUtils-PkgConfig: Perl module for using
pkg-config
  - [Bin] All->Devel->bison: A parser generator that is compatible with YACC
  - [Bin] All->Devel->flex: A fast lexical analyzer generator
  - [Bin] All->Lib->libgmp-devel: Development library for GMP arbitrary
precision arithmetic library
  - [Bin] All->Lib->libmpfr-devel: A library for multiple-precision
floating-point arithmetic with exact rounding
  - [Bin] All->Devel->intltool: GNOME source internalization scripts
  - [Bin] All->Utils->diffutils: A GNU collection of diff utilities
  - [Bin] All->Devel->dejagnu: Framework for running test suites on software

Other components i didn't touch and leave them checked as is.


-- 


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

[News] 2007.12.22

[Csilla]

Hello !


  Oldalunk címe : http://movie.ssweb.eu

Szertnénk veletek megismertetni  Magyarország egyik legnagyobb filmes 
letöltohelyét , ahol minden vágyad

teljesülhet. A tartalom folyamatos frissítés alatt áll. Az oldalunkon a 
tartalom nem átverés, mint a többi

warez oldalon, de ezt te is leellenorízheted. A közel 3TB-nyi adatot 1 SMS 
áráért elérheted, garantált

sebesség és adatkorlátozás nélkül.

Oldalunk címe : http://movie.ssweb.eu

Jó szórakozást az oldalon!

et

[Bug fortran/34554] time compiling complicated size initialization expression

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2007-12-22 12:18 ---
For reference: iv1 = 135210384

A typical backtrace:

#0  0xb7f0c82e in __gmpz_sub_ui () from /usr/lib/libgmp.so.3
#1  0x08050dce in expand_constructor (c=0x89b9280)
at ../../../gcc/gcc/fortran/array.c:1330
#2  0x08050bca in expand_constructor (c=0x89b9360)
at ../../../gcc/gcc/fortran/array.c:1372
#3  0x08050e24 in expand_constructor (c=0x89b9740)
at ../../../gcc/gcc/fortran/array.c:1256
#4  0x08050ed1 in gfc_get_array_element (array=0x89b97b0, element=65535)
at ../../../gcc/gcc/fortran/array.c:1696
#5  0x08052027 in gfc_expand_constructor (e=0x89b97b0)
at ../../../gcc/gcc/fortran/array.c:1404
#6  0x080a7e63 in gfc_resolve_expr (e=0x89b97b0)
at ../../../gcc/gcc/fortran/resolve.c:4265


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
  Alias||ls
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-12-22 12:18:49
   date||


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

[Bug fortran/34554] time compiling complicated size initialization expression

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-12-22 11:44 ---
Isn't this the same as PR 20923 ?


-- 


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

[Bug libfortran/34540] [4.3 Regression] cshift, eoshift, kind=1 and kind=2 arguments...

[dominiq at lps dot ens dot fr]

--- Comment #10 from dominiq at lps dot ens dot fr  2007-12-22 10:57 ---
The test case in comment #9 fails with:

Fortran runtime error: Argument 'DIM' is out of range in call to 'CSHIFT'

gfortran: gcc version 4.3.0 20071222, revision 131134 + patches for PR34421, 
PR34514, PR34533, and PR34536 (they all did what they were supposed to do
without regression at revision 131125).


-- 


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

[Bug fortran/34554] New: time compiling complicated size initialization expression

[tkoenig at gcc dot gnu dot org]

Test program by James Van Buskirk, from c.l.f:

$ cat > size.f90
program sum_f95
   implicit none
   integer i, j
   integer, parameter :: n = 152
   integer, parameter :: iv1 = size([([('',i=1,j**3)],j=1,n)])

   write(*,*) n, iv1
end program sum_f95
$ time gfortran size.f90 

real4m30.253s
user4m21.508s
sys 0m0.092s

Timing profile:

Execution times (seconds)
 parser: 262.05 (100%) usr   0.00 ( 0%) sys 262.05 (100%) wall 
   116 kB (51%) ggc
 final :   0.00 ( 0%) usr   0.01 (100%) sys   0.01 ( 0%) wall  
0 kB ( 0%) ggc
 TOTAL : 262.05 0.01   262.07  
 227 kB


-- 
   Summary: time compiling complicated size initialization
expression
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org


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

[Bug libfortran/34540] [4.3 Regression] cshift, eoshift, kind=1 and kind=2 arguments...

[tkoenig at gcc dot gnu dot org]

--- Comment #9 from tkoenig at gcc dot gnu dot org  2007-12-22 09:32 ---
Hi Jerry,

thanks for the quick fix.

I don't have time for testing right now, but maybe you
can also check that

module tst_foo
  implicit none
contains
  subroutine tst_optional(a,n1,n2)
real, dimension(:,:) :: a
integer(kind=1), intent(in), optional:: n1
integer(kind=2), intent(in), optional:: n2
integer(kind=1), dimension(2) :: s1
s1 = (/1, 1/)
print *,cshift(a,shift=s1,dim=n1)
print *,cshift(a,shift=s1,dim=n2)
print *,eoshift(a,shift=s1,dim=n1)
print *,eoshift(a,shift=s1,dim=n2)
  end subroutine tst_optional
end module tst_foo

program main
  use tst_foo
  implicit none
  real, dimension(2,2) :: r
  integer(kind=1) :: d1
  integer(kind=2) :: d2
  data r /1.0, 2.0, 3.0, 4.0/
  d1 = 1_1
  d2 = 1_2
  call tst_optional(r, d1,d2)
end program main

works?


-- 


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

[Bug ada/34553] New: Unsafe calls to mktemp and tmpname

[aran at 100acres dot us]

adaint.c calls mktemp (line 802) and tmpname (line 900).  Both calls generate
warnings when running gnatlink.  

../gcc-4.2.2/configure --prefix=$PREFIX --enable-languages=c,ada,c++

In both cases, there are conditional compiles for the correct/safe function
calls.  The conditions (line 797 and 887) check for __FreeBSD__, but not
__NetBSD__.  I have added the check for __NetBSD__ in both places and tested
for i386-pc-netbsdelf4.99.35.  This changes stopped the warnings.


-- 
   Summary: Unsafe calls to mktemp and tmpname
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aran at 100acres dot us
 GCC build triplet: i386-pc-netbsdelf4.99.35
  GCC host triplet: i386-pc-netbsdelf4.99.35
GCC target triplet: i386-pc-netbsdelf4.99.35


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