[Bug fortran/34004] Accepts invalid: Ambigiuous interface with subroutine.

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2008-04-20 07:31 ---
Note: Fortran 2008 is better in this regard:

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ff402a68a17d2be9

Here is the relevant text from the current draft, 08-007r2.
Reference is sec. 12.4.3.4.5, par. 3.
[Begin quote]
Two dummy arguments are distinguishable if:
* One is a procedure and the other is a data object,
[End of quote] 


-- 


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

[Bug driver/35916] problem running GCC under Vista with relocated directory

[brian at dessent dot net]

--- Comment #6 from brian at dessent dot net  2008-04-20 08:28 ---
Subject: Re:  problem running GCC under Vista with relocated 
 directory

As pointed out in ,
config/mh-mingw contains BOOT_CFLAGS += -D__USE_MINGW_ACCESS.  Does this
setting get applied only when building gcc, or does it apply to target
libraries too?  Because there are places in libiberty (e.g.
make-relative-prefix.c) where access() is called, and so libiberty needs
to be built with -D__USE_MINGW_ACCESS if it is to contain the Vista
workaround.

If the above host fragment only applies to gcc, then I think it will
still be necessary to override BOOT_CFLAGS and CFLAGS when invoking
make.

Brian


-- 


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

[Bug driver/35916] problem running GCC under Vista with relocated directory

[brian at dessent dot net]

--- Comment #7 from brian at dessent dot net  2008-04-20 08:44 ---
Subject: Re:  problem running GCC under Vista with relocated 
 directory

er, I mean s/target library/host library/


-- 


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

[Bug fortran/35983] New: C_LOC in derived type constructor gives weird result

[fxcoudert at gcc dot gnu dot org]

$ cat a.f90 
program main
   use ISO_C_BINDING
   implicit none
   type, bind(C) :: descr
  type(C_PTR) :: address
   end type descr
   type(descr) :: DD
   double precision, target :: buf(1)

   buf = (/ 0 /)
   DD = descr(c_loc(buf))
   print *, transfer(DD%address, 0_c_intptr_t), &
 transfer(c_loc (buf), 0_c_intptr_t)
end program main

$ gfortran a.f90 && ./a.out
   0 -1073744200


-- 
   Summary: C_LOC in derived type constructor gives weird result
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org


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

[Bug fortran/35983] C_LOC in derived type constructor gives weird result

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-04-20 11:40 ---
Confirm. While for
   type(c_ptr) :: cptr
   cptr = c_loc(buf)

the dump is:
  void * D.910;
  D.910 = (void *) &buf;
  dd.address = D.910;

Your structure constructor,  DD = descr(c_loc(buf)),  gives:
  struct descr descr.2;
  descr.2.address = 0B;


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-04-20 11:40:52
   date||


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

[Bug ada/35984] New: Illegal program not detected, RM 4.6(24/2)

[ludovic at ludovic-brenta dot org]

package pak1 is
   type T1 is interface;
   type T2 is tagged null record;
   x1: access T1'Class;
   x2: T2 := T2(T2'class(x1.all));  --OK
   x3: T2 := T2(x1.all);--ERROR: not a valid type conversion
end pak1;

The declaration of x2 is a legal type conversion, because x1.all
and T2'class both have class-wide types, so RM 4.6(21/2) applies.

But the declaration of x3 isn't a legal type conversion because
T2 isn't classwide, so RM 4.6(24/2) applies instead, which doesn't
offer any reason for this to be legal.

GCC 4.3 fails to diagnose the violation of 4.6(24/2), instead
warning about null access values:

gcc-4.3 -c -gnat05 pak1.ads
pak1.ads:5:26: warning: null value not allowed here
pak1.ads:5:26: warning: "Constraint_Error" will be raised at run time
pak1.ads:6:17: warning: null value not allowed here
pak1.ads:6:17: warning: "Constraint_Error" will be raised at run time

Here, gcc seems to propagate x1's null value even before considering
whether the type conversions are legal.


-- 
   Summary: Illegal program not detected, RM 4.6(24/2)
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ludovic at ludovic-brenta dot org


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

[Bug c++/35985] New: [4.1/4.2/4.3/4.4 regression] ICE with pointer to member function as base

[reichelt at gcc dot gnu dot org]

The following invalid testcase triggers an ICE since GCC 4.0.0:


template struct A : T {};

struct B;

A a;


bug.cc: In instantiation of 'A':
bug.cc:5:   instantiated from here
bug.cc:1: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]

Before we got an error message that wasn't quite accurate:

bug.cc: In instantiation of `A':
bug.cc:5:   instantiated from here
bug.cc:1: error: duplicate base type `void (B::*)()' invalid


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] ICE with pointer to member
function as base
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/35985] [4.1/4.2/4.3/4.4 regression] ICE with pointer to member function as base

[reichelt at gcc dot gnu dot org]

--- Comment #1 from reichelt at gcc dot gnu dot org  2008-04-20 14:26 
---
Testing a patch.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |reichelt at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-20 14:26:13
   date||


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

[Bug c++/35985] [4.1/4.2/4.3/4.4 regression] ICE with pointer to member function as base

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug c++/35986] New: [4.1/4.2/4.3/4.4 regression] ICE with ambiguous template functions

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 4.0.1:


namespace
{
  template void foo(...);
}

template void foo(...);

void bar()
{
  foo<0>(0);
}


bug.cc: In function 'void bar()':
bug.cc:10: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]

In GCC 4.0.0 and earlier we got a correct error message:
bug.cc: In function 'void bar()':
bug.cc:10: error: call of overloaded 'foo(int)' is ambiguous
bug.cc:6: note: candidates are: void foo(...) [with int  = 0]
bug.cc:3: note: void::foo(...) [with int  =
0]


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] ICE with ambiguous template
functions
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/35986] [4.1/4.2/4.3/4.4 regression] ICE with ambiguous template functions

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug c++/35987] New: [4.1/4.2/4.3/4.4 regression] ICE with invalid if-condition

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since GCC 3.0:


void foo(char* p)
{
  if (++p = true);
}


bug.cc: In function 'void foo(char*)':
bug.cc:3: error: cannot convert 'bool' to 'char*' in assignment
bug.cc:3: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in fold_comparison, at fold-const.c:8730
Please submit a full bug report, [etc.]


-- 
   Summary: [4.1/4.2/4.3/4.4 regression] ICE with invalid if-
condition
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/35987] [4.1/4.2/4.3/4.4 regression] ICE with invalid if-condition

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


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

[Bug fortran/35988] New: run-time abort for MATMUL of run-time zero sized array

[dick dot hendrickson at gmail dot com]

Two of the following three subroutines abort at run time.
They have run time zero sized arrays that have "different"
zero sizes as arguments to matmul.  If the zeroness is visible
at compile time or if the zeroness has the same "size", the
similar subroutines do not abort

Dick Hendrickson



   program try_gf1003

! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139]

  call   gf1003a(  9,  8,  6)   
  call   gf1003b(  9,  8,  6)   
  call   gf1003c(  9,  8,  6)   !fails
  call   gf1003d(  9,  8,  6)   !fails
  end program


  SUBROUTINE GF1003a(nf9,nf8,nf6)
  REAL RDA(3,2)
  REAL RDA1(3,5)
  REAL RDA2(5,2)
  print *, 'gf1003a started'
  RDA = MATMUL(RDA1(:, 9:8),RDA2( 8:6,:))
  print *, 'gf1003a finished'
  END SUBROUTINE

  SUBROUTINE GF1003b(nf9,nf8,nf6)
  REAL RDA(3,2)
  REAL RDA1(3,0)
  REAL RDA2(0,2)
  print *, 'gf1003b started'
  RDA = MATMUL(RDA1(:,NF9:NF8),RDA2(NF9:NF8,:))
  print *, 'gf1003b finished'
  END SUBROUTINE

  SUBROUTINE GF1003c(nf9,nf8,nf6)
  REAL RDA(3,2)
  REAL RDA1(3,0)
  REAL RDA2(0,2)
  print *, 'gf1003c started'
  RDA = MATMUL(RDA1(:,NF9:NF8),RDA2(NF8:NF6,:))
  print *, 'gf1003c finished'
  END SUBROUTINE

  SUBROUTINE GF1003d(nf9,nf8,nf6)
  REAL RDA(3,2)
  REAL RDA1(3,5)
  REAL RDA2(5,2)
  print *, 'gf1003d started'
  RDA = MATMUL(RDA1(:,NF9:NF8),RDA2(NF8:NF6,:))
  print *, 'gf1003d finished'
  END SUBROUTINE

C:\gfortran:gfortran gf1003.f

C:\gfortran:a
 gf1003a started
 gf1003a finished
 gf1003b started
 gf1003b finished
 gf1003c started
Fortran runtime error: dimension of array B incorrect in MATMUL intrinsic


-- 
   Summary: run-time abort for MATMUL of run-time zero sized array
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dick dot hendrickson at gmail dot com


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

[Bug c++/35989] New: code rejected in template specialization (4.2 did accept)

[debian-gcc at lists dot debian dot org]

[forwarded from http://bugs.debian.org/470850]

code is rejected by 4.3.1 20080420, accepted by 4.2.3

  The following code has three specializations of a template.
The third one compiles with g++-4.2 but gives an error with g++-4.3 :

[EMAIL PROTECTED]:/tmp/toto$ g++-4.3 -Wall -c test.cpp 
test.cpp:30: error: template parameters not used in partial specialization:
test.cpp:30: error: ‘T’
test.cpp:30: error: ‘A’
[EMAIL PROTECTED]:/tmp/toto$

It seems to me that my code is correct and g++-4.3 wrong: I really use T
and A in the partial specialization.


-- 
   Summary: code rejected in template specialization (4.2 did
accept)
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org


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

[Bug c++/35989] code rejected in template specialization (4.2 did accept)

[debian-gcc at lists dot debian dot org]

--- Comment #1 from debian-gcc at lists dot debian dot org  2008-04-20 
16:36 ---
Created an attachment (id=15500)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15500&action=view)
test case


-- 


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

[Bug target/35982] [4.3 regression] ICE while building mplayer on ppc with -O3 -ffast-math -mcpu=970

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |4.3.1


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

[Bug libstdc++/35968] nth_element fails to meet its complexity requirements

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2008-04-20 17:30 ---
Roger, can you have a look? Thanks in advance.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||roger at eyesopen dot com


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

[Bug c++/35989] code rejected in template specialization (4.2 did accept)

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-04-20 17:31 ---
EDG agrees with gcc:

/tmp/test.cpp(29): warning #885: template parameter "T" is not used in or
cannot be deduced from the template argument list of class template
"remote_trait::iterator>"
  template
 ^

/tmp/test.cpp(29): warning #885: template parameter "A" is not used in or
cannot be deduced from the template argument list of class template
"remote_trait::iterator>"
  template
  ^

which means that from an std::vector::iterator type T and A cannot
be deduced.  Which in the end means that this specialization is never
going to be selected.  Whether this is rightfully diagnosed as error by
gcc I don't know.


-- 


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

[Bug fortran/35988] run-time abort for MATMUL of run-time zero sized array

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-04-20 18:55:16
   date||


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

[Bug pch/14933] missing pre-compiled header depends with -MD

[tromey at gcc dot gnu dot org]

--- Comment #10 from tromey at gcc dot gnu dot org  2008-04-20 18:59 ---
FYI -- when I tried this on the compile farm tester, it caused a couple
regressions.  I'll redo it at some point and post the results here.


-- 


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

[Bug fortran/35990] New: run-time abort for MATMUL of run-time zero sized array

[dick dot hendrickson at gmail dot com]

Two of the following 4 subroutines abort at run time.  They
have a zero sized array argument to PACK.  If the left and
right hand zero sizes are "the same", it works.  Also works if
the zero size is a compile time thing.

Dick Hendrickson

  program try_gf1048

! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139]

  call   gf1048a(  10,  8,  7,  1,  0,  .true.)
  call   gf1048b(  10,  8,  7,  1,  0,  .true.)
  call   gf1048c(  10,  8,  7,  1,  0,  .true.)!fails
  call   gf1048d(  10,  8,  7,  1,  0,  .true.)!fails
  end program

  SUBROUTINE GF1048a(nf10,nf8,nf7,nf1,nf0,nf_true)
  logical nf_true
  CHARACTER(9) BDA(10)
  CHARACTER(9) BDA1(10)
  print *, 'gf1048a started'
  BDA(  8:7) = PACK(BDA1( 10:  1), NF_TRUE)
  print *, 'gf1048a finished'
  END SUBROUTINE

  SUBROUTINE GF1048b(nf10,nf8,nf7,nf1,nf0,nf_true)
  logical nf_true
  CHARACTER(9) BDA(10)
  CHARACTER(9) BDA1(nf10)
  print *, 'gf1048b started'
  BDA(NF8:NF7) = PACK(BDA1(NF8:NF7), NF_TRUE)
  print *, 'gf1048b finished'
  END SUBROUTINE

  SUBROUTINE GF1048c(nf10,nf8,nf7,nf1,nf0,nf_true)
!  on windows XP, natters to itself a while and then goes
!  back to command line prompt with no obvious message
  logical nf_true
  CHARACTER(9) BDA(10)
  CHARACTER(9) BDA1(10)
  print *, 'gf1048c started'
  BDA(NF8:NF7) = PACK(BDA1(NF10:NF1), NF_TRUE)
  print *, 'gf1048c finished'
  END SUBROUTINE

  SUBROUTINE GF1048d(nf10,nf8,nf7,nf1,nf0,nf_true)
!  on windows XP, natters to itself a while and then opens
!  a run time error box and offers to send report to MS
  logical nf_true
  CHARACTER(9) BDA(10)
  CHARACTER(9) BDA1(nf10)
  print *, 'gf1048d started'
  BDA(NF8:NF7) = PACK(BDA1(NF10:NF1), NF_TRUE)
  print *, 'gf1048d finished'
  END SUBROUTINE

C:\gfortran:gfortran gf1048.f

C:\gfortran:a
 gf1048a started
 gf1048a finished
 gf1048b started
 gf1048b finished
 gf1048c started

C:\gfortran:gfortran gf1048.f

!  call gf1048c commented out
C:\gfortran:a
 gf1048a started
 gf1048a finished
 gf1048b started
 gf1048b finished
 gf1048d started

C:\gfortran:


-- 
   Summary: run-time abort for MATMUL of run-time zero sized array
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dick dot hendrickson at gmail dot com


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

[Bug fortran/35990] run-time abort for PACK of run-time zero sized array

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-04-20 19:39 ---
Confirm. Valgrind shows:

 gf1048c started
==9694==
==9694== Invalid write of size 1
==9694==at 0x4C26264: memcpy (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==9694==by 0x4EEA167: pack_s_internal (pack_generic.c:521)
==9694==by 0x400F9D: gf1048c_ (agf.f90:37)
==9694==  Address 0x7ff001001 is not stack'd, malloc'd or (recently) free'd


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-04-20 19:39:48
   date||
Summary|run-time abort for MATMUL of|run-time abort for PACK of
   |run-time zero sized array   |run-time zero sized array


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

[Bug fortran/35991] New: run-time abort for CSHIFT of zero sized array

[dick dot hendrickson at gmail dot com]

The following program aborts at run-time.  On windows XP it
opens an error box saying a.exe has encountered a problem
and offers to send a problem report to MS.

Dick Hendrickson

  program try_gf0045

! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139]

  call   gf0045(  9,  8)
  end

  subroutine GF0045(nf9,nf8)
  REAL RDA(10)
  REAL RDA1(0)

  RDA(NF9:NF8) = CSHIFT ( RDA1 ,1)

  END SUBROUTINE


-- 
   Summary: run-time abort for CSHIFT of zero sized array
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dick dot hendrickson at gmail dot com


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

[Bug c++/35813] ICE with partial specialization of variadic templates

[reichelt at gcc dot gnu dot org]

--- Comment #1 from reichelt at gcc dot gnu dot org  2008-04-20 19:42 
---
Slightly simpler testcase:


template struct A {};

template struct B;

template struct B > {};

template struct B > {};

B > b;


This has been fixed on mainline by

2008-03-27  Douglas Gregor  <[EMAIL PROTECTED]>

* pt.c (tsubst_copy) : Cope with
tsubst_pack_expansion returning a pack expansion, or a TREE_VEC
ending in a pack expansion, both of which can occur when
substituting into a nested template.
(tsubst_copy_and_build) : When we're
instantiating the sizeof...(X) form, make tsubst_copy do the work.
* parser.c (cp_parser_template_parameter): Deal with unnamed
non-type template parameter packs identified by pack expansions in
the parameter type.

Doug, are you going to backport the patch to the 4.3 branch?


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||doug dot gregor at gmail dot
   ||com, reichelt at gcc dot gnu
   ||dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
   Last reconfirmed|-00-00 00:00:00 |2008-04-20 19:42:14
   date||
   Target Milestone|--- |4.3.1


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

[Bug c/35992] New: Linux kernel code fails to compile with -Os

[dcb314 at hotmail dot com]

I just tried to compile the new Linux kernel 2.6.25
with the new GNU C compiler version 4.4 snapshot 20080418

The GNU C compiler said

drivers/char/cyclades.c: In function 'cyz_load_fw':
drivers/char/cyclades.c:5421: error: invalid use of void expression
drivers/char/cyclades.c:5421: error: invalid use of void expression
drivers/char/cyclades.c:5421: error: invalid use of void expression
drivers/char/cyclades.c:5421: error: invalid use of void expression

Preprocessed source code attached. Flag -Os required


-- 
   Summary: Linux kernel code fails to compile with -Os
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: suse-linux-x86_64


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

[Bug c++/35813] [4.3 regression] ICE with partial specialization of variadic templates

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |minor
   Keywords||error-recovery


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

[Bug c/35992] Linux kernel code fails to compile with -Os

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2008-04-20 19:46 ---
Created an attachment (id=15501)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15501&action=view)
C source code


-- 


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

[Bug middle-end/35992] [4.4 Regression] Linux kernel code fails to compile with -Os

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ian at gcc dot gnu dot org
   Severity|normal  |blocker
  Component|c   |middle-end
   Keywords||rejects-valid
Summary|Linux kernel code fails to  |[4.4 Regression] Linux
   |compile with -Os|kernel code fails to compile
   ||with -Os
   Target Milestone|--- |4.4.0


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

[Bug fortran/35991] run-time abort for CSHIFT of zero sized array

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2008-04-20 19:47 
---
Confirmed, I get a Floating Point Exception


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-20 19:47:42
   date||


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

[Bug middle-end/35992] [4.4 Regression] Linux kernel code fails to compile with -Os

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-04-20 19:50 ---
Caused by:
  size = size_in_bytes (TREE_TYPE (TREE_TYPE (base)));
  if (size == NULL_TREE || TREE_CODE (size) != INTEGER_CST)
return true;

in pointer_may_wrap_p.

a simple s/size_in_bytes/TYPE_SIZE_UNIT/ should fix the problem.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-20 19:50:29
   date||


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

[Bug fortran/35960] run time abort with assignment of RESHAPEd zero sized array

[tkoenig at gcc dot gnu dot org]

--- Comment #4 from tkoenig at gcc dot gnu dot org  2008-04-20 19:56 ---
Subject: Bug 35960

Author: tkoenig
Date: Sun Apr 20 19:56:07 2008
New Revision: 134490

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134490
Log:
2008-04-20  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/35960
* intrinsics/reshape_generic.c (reshape_internal): If the size
of the resized array is zero, as determined by the SHAPE
argument, return early.
* m4/reshape.m4:  Likewise.
* generated/reshape_i4.c:  Regererated.
* generated/reshape_i8.c:  Regenerated.
* generated/reshape_i16.c:  Regenerated.
* generated/reshape_r4.c:  Regenerated.
* generated/reshape_r8.c:  Regenerated.
* generated/reshape_r10.c:  Regenerated.
* generated/reshape_r16.c:  Regenerated.
* generated/reshape_c4.c:  Regenerated.
* generated/reshape_c8.c:  Regenerated.
* generated/reshape_c10.c:  Regenerated.
* generated/reshape_c16.c:  Regenerated.

2008-04-20  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/35960
* gfortran.dg/reshape_zerosize_1.f90:  New file.


Added:
trunk/gcc/testsuite/gfortran.dg/reshape_zerosize_1.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/reshape_c10.c
trunk/libgfortran/generated/reshape_c16.c
trunk/libgfortran/generated/reshape_c4.c
trunk/libgfortran/generated/reshape_c8.c
trunk/libgfortran/generated/reshape_i16.c
trunk/libgfortran/generated/reshape_i4.c
trunk/libgfortran/generated/reshape_i8.c
trunk/libgfortran/generated/reshape_r10.c
trunk/libgfortran/generated/reshape_r16.c
trunk/libgfortran/generated/reshape_r4.c
trunk/libgfortran/generated/reshape_r8.c
trunk/libgfortran/intrinsics/reshape_generic.c
trunk/libgfortran/m4/reshape.m4


-- 


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

[Bug fortran/35960] run time abort with assignment of RESHAPEd zero sized array

[tkoenig at gcc dot gnu dot org]

--- Comment #5 from tkoenig at gcc dot gnu dot org  2008-04-20 20:07 ---
Fixed on trunk (no need to backport this to 4.3).

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

[Bug fortran/35993] New: wrong answer for PRODUCT with scalar mask

[dick dot hendrickson at gmail dot com]

The PRODUCT intrinsic gives the wrong answer when the mask argument is
a scalar expression which evaluates to FALSE.  It's OK with
an array expression that evaluates to all FALSE.

Dick Hendrickson 

  program try ga3019

! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139]

  call   ga3019(  1,  2,  3,  4)
  end program

  SUBROUTINE GA3019(nf1,nf2,nf3,nf4)
  INTEGER IDA(NF2,NF3)
  INTEGER IDA1(NF2,NF4,NF3)

  ida1 = 3

  ida = -3
  IDA(NF1:NF2,NF1:NF3) = PRODUCT(IDA1,NF2, NF1 .LT. 0)  !fails
  print '(6I3)', ida

  ida = -3
  IDA(NF1:NF2,NF1:NF3) = PRODUCT(IDA1,NF2, .false. )!fails
  print '(6I3)', ida

  ida = -3
  IDA(NF1:NF2,NF1:NF3) = PRODUCT(IDA1,NF2, ida1 .eq. 137 )!works
  print '(6I3)', ida

  END SUBROUTINE

C:\gfortran:gfortran ga3019.f

C:\gfortran:a
  1  1  1 -3 -3 -3
  1  1  1 -3 -3 -3
  1  1  1  1  1  1


-- 
   Summary: wrong answer for PRODUCT with scalar mask
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dick dot hendrickson at gmail dot com


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

[Bug fortran/35991] run-time abort for CSHIFT of zero sized array

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2008-04-20 20:16 
---
This obvious patch fixes it.

Index: cshift0.c
===
--- cshift0.c   (revision 134473)
+++ cshift0.c   (working copy)
@@ -202,7 +202,7 @@ cshift0 (gfc_array_char * ret, const gfc
   rptr = ret->data;
   sptr = array->data;

-  shift = shift % (ssize_t)len;
+  shift = len == 0 ? 0 : shift % (ssize_t)len;
   if (shift < 0)
 shift += len;



-- 


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

[Bug fortran/35994] New: MAXLOC and MINLOC off by one with mask

[dick dot hendrickson at gmail dot com]

The MAXLOC and MINLOC functions give an off by one wrong
answer when there is a mask argument.

Dick Hendrickson

  program GA4076

! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139]

  REAL DDA(100)
  dda = (/(J1,J1=1,100)/)

  IDS = MAXLOC(DDA,1)
  print *, 1, ids, ids.eq.100 !expect 100

  IDS = MAXLOC(DDA,1, (/(J1,J1=1,100)/) > 50)
  print *, 2, ids, ids.eq.100 !expect 100

  IDS = minLOC(DDA,1)
  print *, 3, ids, ids.eq.1   !expect 1

  IDS = MinLOC(DDA,1, (/(J1,J1=1,100)/) > 50)
  print *, 4, ids, ids.eq.51  !expect 51

  END 

C:\gfortran:gfortran ga4076.f

C:\gfortran:a
   1 100 T
   2 101 F
   3   1 T
   4  52 F


-- 
   Summary: MAXLOC and MINLOC off by one with mask
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dick dot hendrickson at gmail dot com


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

[Bug middle-end/35992] [4.4 Regression] Linux kernel code fails to compile with -Os

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-04-20 20:34 ---
Isn't pointer_may_wrap_p just get_ref_base_and_extent () and checking for
max_size != -1?


-- 


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

[Bug target/35460] [4.4 Regression] undefined reference to `__builtin_stdarg_start' when compiling 2/29 snapshot on OpenBSD

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug tree-optimization/35629] [4.4 Regression] gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile fails

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug tree-optimization/35642] [4.4 Regression] heisenbug in tree vectorizer

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-04-20 20:39 
---
What is this bug?  A missed-optimization?  wrong-code? ...


-- 


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

[Bug ada/35687] [4.4 Regression] gnatmake: "/test/gnu/gcc/gcc-svn/gcc/ada/gnatchop.adb" compilation error

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-04-20 20:40 ---
Any updates?  Is the classification as Ada bug correct?


-- 


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

[Bug middle-end/35736] [4.4 regression] ICE with continue and -Wall

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-04-20 20:41 ---
Honza?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
  Component|c   |middle-end
   Priority|P3  |P1


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

[Bug libmudflap/35755] [4.4 Regression]: libmudflap.cth/pass39-frag.c

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-04-20 20:42 ---
Whatever.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/35760] [4.4 Regression] ICE with complex types and -static on PPC darwin

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug target/35839] [4.4 Regression] Altivec with the vectorizer causes an ICE in rs6000_check_sdmode

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-04-20 20:43 
---
I supposed this is fixed?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal
 Status|ASSIGNED|WAITING


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

[Bug testsuite/35843] [4.4 Regression]: -fdump-rtl-expand does not exist anymore

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2008-04-20 20:44 ---
Honza?  Can we please have -fdump-rtl-expand back?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Priority|P3  |P1


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

[Bug middle-end/35853] [4.4 Regression] -d is still referenced in some cases (documentation)

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-04-20 20:44 ---
Honza?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2008-04-20 20:44:58
   date||


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

[Bug debug/35896] [4.4 Regression] gfortran TLS symbols broken with debug info

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P1


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

[Bug c++/35909] [4.3/4.4 Regression] ICE with bit-field and const references

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-04-20 20:48 ---
This also fails on the 4.3 branch now which makes it a regression against
4.3.0.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
   Severity|normal  |blocker
  Known to fail|4.4.0   |4.4.0 4.3.1
  Known to work||4.3.0
   Priority|P3  |P1
Summary|[4.4 Regression] ICE with   |[4.3/4.4 Regression] ICE
   |bit-field and const |with bit-field and const
   |references  |references
   Target Milestone|4.4.0   |4.3.1


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

[Bug tree-optimization/35972] [4.4 Regression] load-PRE missed opportunities without SFTs

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/35992] [4.4 Regression] Linux kernel code fails to compile with -Os

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug fortran/35994] MAXLOC and MINLOC off by one with mask

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2008-04-20 20:50 ---
Confirmed.  Ouch.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org
   Severity|normal  |major
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-04-20 20:50:27
   date||


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

[Bug fortran/35995] New: ANY, ALL, and COUNT errors for zero sized sections

[dick dot hendrickson at gmail dot com]

The ANY, ALL, and COUNT intrinsics do not return the correct
answer when the MASK array is a zero sized section of an
array.  The whole array reduction versions give the correct
answer for the zero sized whole array argument.  It appears
as if nothing is being stored on the left hand side.

Dick Hendrickson

  program try_gf0026_etc

! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139]

  call   gf0026(  0,  1)
  end program

  SUBROUTINE GF0026(nf0,nf1)
  LOGICAL LDA(9)
  INTEGER IDA(NF0,9), iii(9)

  lda = (/ (i/2*2 .eq. I, i=1,9) /)
  LDA = ALL ( IDA .NE. -1000,  1)
  print *, lda  !expect TRUE
  print *, all(ida .ne. -1000)   !expect TRUE

  lda = (/ (i/2*2 .eq. I, i=1,9) /)
  LDA = any ( IDA .NE. -1000,  1)
  print *, lda  !expect FALSE
  print *, any(ida .ne. -1000)   !expect FALSE

  iii = 137
  iii = count ( IDA .NE. -1000,  1)
  print '(9i4)', iii !expect 0
  print *, count(ida .ne. -1000)   !expect COUNT

  END SUBROUTINE

C:\gfortran:gfortran gf0026.f

C:\gfortran:a
 F T F T F T F T F
 T
 F T F T F T F T F
 F
 137 137 137 137 137 137 137 137 137
   0


-- 
   Summary: ANY, ALL, and COUNT errors for zero sized sections
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dick dot hendrickson at gmail dot com


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

[Bug libstdc++/35915] [4.4 Regression] atomic.cc:31:20: error: stdint.h: No such file

[andreast at gcc dot gnu dot org]

--- Comment #11 from andreast at gcc dot gnu dot org  2008-04-20 21:00 
---
Compilation issues fixed. Both, on sparc and hpux. Confirmed myself.
We need to investigate the results of the atomic tests under HPUX. But if not
satisfying, we will open a new PR. 


-- 

andreast at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/35993] wrong answer for PRODUCT with scalar mask

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2008-04-20 21:02 ---
Confirmed.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-04-20 21:02:20
   date||


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

[Bug fortran/35991] run-time abort for CSHIFT of zero sized array

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2008-04-20 21:07 
---
Subject: Bug 35991

Author: jvdelisle
Date: Sun Apr 20 21:06:16 2008
New Revision: 134491

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134491
Log:
2008-04-20  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/35991
* intrinsics/cshift0.c (cshift0): Avoid divide by zero.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/cshift0.c


-- 


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

[Bug fortran/35995] ANY, ALL, and COUNT errors for zero sized sections

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2008-04-20 21:08 ---
Confirmed.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-04-20 21:08:11
   date||


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

[Bug fortran/35882] Miscounted continuation lines when interspersed with data

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2008-04-20 21:12 
---
Subject: Bug 35882

Author: jvdelisle
Date: Sun Apr 20 21:11:22 2008
New Revision: 134493

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134493
Log:
2008-04-20  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/35882
* scanner.c (skip_fixed_comments): Update continue_line when comment is
detected. (gfc_next_char_literal): Likewise.

PR fortran/35882
* gfortran.dg/continuation_5.f: Add some comment lines.
* gfortran.dg/continuation_3.f90: Add some comment lines.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/scanner.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/continuation_3.f90
trunk/gcc/testsuite/gfortran.dg/continuation_5.f


-- 


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

[Bug target/35839] [4.4 Regression] Altivec with the vectorizer causes an ICE in rs6000_check_sdmode

[dominiq at lps dot ens dot fr]

--- Comment #11 from dominiq at lps dot ens dot fr  2008-04-20 21:13 ---
> I supposed this is fixed?

I think so.


-- 


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

[Bug libstdc++/35954] [4.3/4.4 Regression] cannot build from read-only source tree

[rwild at gcc dot gnu dot org]

--- Comment #2 from rwild at gcc dot gnu dot org  2008-04-20 21:15 ---
Subject: Bug 35954

Author: rwild
Date: Sun Apr 20 21:14:32 2008
New Revision: 134494

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134494
Log:
libstdc++-v3/
PR libstdc++/35954
* include/Makefile.am (pch*_output): Do not touch pch*_output_anchor.
Call 'mkdir -p' unconditionally, but ignore its return value.
* include/Makefile.in: Regenerate.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/Makefile.am
trunk/libstdc++-v3/include/Makefile.in


-- 


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

[Bug fortran/35991] run-time abort for CSHIFT of zero sized array

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2008-04-20 21:18 
---
Subject: Bug 35991

Author: jvdelisle
Date: Sun Apr 20 21:17:42 2008
New Revision: 134495

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134495
Log:
2008-04-20  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/35991
gfortran.dg/zero-sized_4.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/zero_sized_4.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/35991] run-time abort for CSHIFT of zero sized array

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-04-20 21:19 
---
Fixed on trunk.  I will follow up with a check of eoshift.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/35971] ICE on valid code

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2008-04-20 21:19 ---
Confirmed.

Reduced testcase:

module other_fun
   use ISO_C_BINDING
   implicit none
   private
! Message to be returned by procedure pointed to
! by the C_FUNPTR
   character, allocatable, save :: my_message(:)
! Interface block for the procedure pointed to
! by the C_FUNPTR
   public abstract_fun
   abstract interface
  function abstract_fun(x)
 use ISO_C_BINDING
 import my_message
 implicit none
 integer(C_INT) x(:)
 character(size(my_message),C_CHAR) abstract_fun(size(x))
  end function abstract_fun
   end interface
   contains

! Intermediate procedure to pass the function and get
! back the C_FUNPTR
  function get_funloc(x,y)
 procedure(abstract_fun) x
 type(C_FUNPTR) y
 external y
 type(C_FUNPTR) get_funloc

 get_funloc = y(x)
  end function get_funloc
end module other_fun


-- 

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 |2008-04-20 21:19:39
   date||


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

[Bug tree-optimization/35642] [4.4 Regression] heisenbug in tree vectorizer

[zadeck at naturalbridge dot com]

--- Comment #11 from zadeck at naturalbridge dot com  2008-04-20 21:21 
---
Subject: Re:  [4.4 Regression] heisenbug in tree
 vectorizer

rguenth at gcc dot gnu dot org wrote:
> --- Comment #10 from rguenth at gcc dot gnu dot org  2008-04-20 20:39 
> ---
> What is this bug?  A missed-optimization?  wrong-code? ...
>
>
>   
the testcases that randomly pass or fail check the dump files to make 
sure that specific transformations have been performed.  So i guess you 
could say that it is a missed optimization but given that this is most 
likely caused by either storage being overwritten or an uninitialized 
variable, it is hard to assure that this does not effect correctness.

kenny


-- 


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

[Bug middle-end/35687] [4.4 Regression] gnatmake: "/test/gnu/gcc/gcc-svn/gcc/ada/gnatchop.adb" compilation error

[danglin at gcc dot gnu dot org]

--- Comment #5 from danglin at gcc dot gnu dot org  2008-04-20 21:47 ---
This bug was fixed by the following change:
http://gcc.gnu.org/viewcvs?view=rev&revision=134411


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|ada |middle-end
 Resolution||FIXED


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

[Bug tree-optimization/35642] [4.4 Regression] heisenbug in tree vectorizer

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2008-04-20 21:54 
---
P1 until this is properly analyzed then.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||missed-optimization
   Priority|P3  |P1


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

[Bug tree-optimization/33705] restrict doesn't improve char * aliasing

[astrange at ithinksw dot com]

--- Comment #4 from astrange at ithinksw dot com  2008-04-20 23:48 ---
Created an attachment (id=15502)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15502&action=view)
source with __restrict (no change)


-- 


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

[Bug pch/14933] missing pre-compiled header depends with -MD

[pedz at easesoftware dot com]

--- Comment #11 from pedz at easesoftware dot com  2008-04-20 23:56 ---
Subject: Re:  missing pre-compiled header depends with -MD

This message has been marked as "junk" or "spam".  There is a very  
good chance that I will not read it.  So, please send this message  
again but add the word "magic special code" without the spaces (all  
one word) in the message and it is suppose to slip through and get to  
me.


On Apr 20, 2008, at 1:59 PM, "tromey at gcc dot gnu dot org"
<[EMAIL PROTECTED] 
 > wrote:

>
>
> --- Comment #10 from tromey at gcc dot gnu dot org  2008-04-20  
> 18:59 ---
> FYI -- when I tried this on the compile farm tester, it caused a  
> couple
> regressions.  I'll redo it at some point and post the results here.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14933
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>
This message has been marked as "junk" or "spam".  There is a very
good chance that I will not read it.  So, please send this message
again but add the word "magic special code" without the spaces (all
one word) in the message and it is suppose to slip through and get to
me.



On Apr 20, 2008, at 1:59 PM, "tromey at gcc dot gnu dot org"
<<[EMAIL PROTECTED]> wrote:


Times


--- Comment #10 from tromey at gcc dot gnu dot org  2008-04-20
18:59 ---

FYI -- when I tried this on the compile farm tester, it caused a couple

regressions.  I'll redo it at some point and post the results here.



-- 



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


--- You are receiving this mail because: ---

You are on the CC list for the bug, or are watching someone who is.





-- 


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

[Bug libstdc++/35969] GLIBCXX_DEBUG: list::merge triggers bad assert

[pcarlini at suse dot de]

--- Comment #6 from pcarlini at suse dot de  2008-04-21 00:46 ---
According to the resolution of DR 250,

  http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#250

indeed splicing doesn't really invalidate iterators. Therefore, the debug-mode
merge should be consistent with that behavior. The fix seems easy...


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-21 00:46:07
   date||


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

[Bug target/35802] MIPS64: Unable to find a register to spill in class ‘V1_REG’

[kumba at gentoo dot org]

--- Comment #4 from kumba at gentoo dot org  2008-04-21 02:13 ---
Just ran into this myself, with the following error on glibc-2.7, building with
gcc-4.3.0, but on a different file:

plural-exp.c: In function '__gettext_extract_plural':
plural-exp.c:157: error: unable to find a register to spill in class 'V1_REG'
plural-exp.c:157: error: this is the insn:
(insn 80 151 161 6 ../include/ctype.h:33 (set (reg:SI 5 $5 [272])
(unspec:SI [
(const_int 0 [0x0])
] 28)) 460 {tls_get_tp_si} (expr_list:REG_EQUIV (unspec:SI [
(const_int 0 [0x0])
] 28)
(nil)))
plural-exp.c:157: confused by earlier errors, bailing out
make[2]: ***
[/usr/obj/portage/sys-libs/glibc-2.7-r2/work/build-default-mips-unknown-linux-gnu-nptl/intl/plural-exp.o]
Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory
`/usr/obj/portage/sys-libs/glibc-2.7-r2/work/glibc-2.7/intl'
make[1]: *** [intl/subdir_lib] Error 2
make[1]: Leaving directory
`/usr/obj/portage/sys-libs/glibc-2.7-r2/work/glibc-2.7'
make: *** [all] Error 2

Ideas to try?  Maybe a patch already in trunk to test?


-- 

kumba at gentoo dot org changed:

   What|Removed |Added

 CC||kumba at gentoo dot org


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

[Bug libstdc++/35968] nth_element fails to meet its complexity requirements

[roger at eyesopen dot com]

--- Comment #2 from roger at eyesopen dot com  2008-04-21 03:22 ---
Yep, now that we're back in stage1, it's about time I got around to submitting
the O(n) worst case nth_element implementation that I mentioned last year.  For
Steven's benefit, the implementation I've already coded up uses the
median-of-medians in groups of five strategy as a fallback to a modified
quickselect.
[Though I'll need to quickly read the paper you cite]

The trick for libstdc++ is to attempt to make the typical case as fast or
faster than the existing implementation.  Whilst the standards now require
O(n) worst case, the perceived performance of g++'s users is the average
case and changing to an O(n) implementation that has a large co-efficient
constant may upset some folks.


-- 

roger at eyesopen dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |roger at eyesopen dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-04-21 03:22:22
   date||


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