[Bug c++/29020] [4.0/4.1/4.2 regression] ICE using A::A instead of A in friend declaration

[mmitchel at gcc dot gnu dot org]

--- Comment #3 from mmitchel at gcc dot gnu dot org  2006-10-04 06:54 
---
Subject: Bug 29020

Author: mmitchel
Date: Wed Oct  4 06:53:55 2006
New Revision: 117425

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117425
Log:
PR c++/29020
* friend.c (do_friend): Improve comments; add assertion.
* parser.c (cp_parser_nested_name_specifier_opt): Resolve
typenames for qualified names used in declarations, even when
caching qualified name lookup.
PR c++/29020
* g++.dg/template/friend48.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/template/friend48.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/friend.c
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/29337] -mfpmath=387 doesn't use fistp for double-to-integer conversion

[uros at kss-loka dot si]

--- Comment #3 from uros at kss-loka dot si  2006-10-04 06:46 ---

> I'm afraid you're missing my point.
> The problem is that for 64-bit and 32-bit floating-point to integer 
> conversion,
> x86 (32bit) target uses fistp* whereas x86_64 (64-bit) target uses cvt* WHEN
> -mfpmath=387.
> This defeats the purpose of the option -mfpmath=387 which is supposed to make
> floating-point computations to use 387, instead of SSE2.

If SSE is available, then SSE cvt* is used in order to avoid long control-word
setting sequences. This is cheaper even if we have to move value from x87
register, as cvt* can handle mem->reg transformations.

If you really need fistp* sequence, you can try with -mno-sse2 (you can't just
disable sse on x86_64 target) or perhaps use -msse3, where fisttp insn will be
generated.

Saying that, I wonder where excess precision effects come into play here. We
are talking about truncate-to-integer instruction, so I would really like to
see an example of this effect.
> 


-- 


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

[Bug fortran/29277] Formated stream output: Translate "\n" / achar(10) into "\r\n" on some platforms

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2006-10-04 06:28 
---
Oops.  This is F2003 issue and therfore an enhancement relative to F95.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should

[mark at codesourcery dot com]

--- Comment #22 from mark at codesourcery dot com  2006-10-04 05:39 ---
Subject: Re:  [4.0/4.1/4.2 Regression] placement new
 does not change the dynamic type as it should

ian at airs dot com wrote:
> --- Comment #21 from ian at airs dot com  2006-10-03 23:44 ---
> In C a general allocation function should work with a char array.  A specific
> allocation function should use a union.  I don't think there are many existing
> exceptions to these guidelines.

> So I don't see a serious problem in C either.  Am I missing something/

I think there are two remaining issues:

   int i;
   *(float*)(&i) = 7.0;

IIUC, Mike's position is that this is valid -- and that, in fact, after 
this point "i" can no longer be accessed as an int.  Do you agree?  Or 
do you think that this is (should be?) undefined behavior?

I think you are saying that:

   int i;
   new (&i) float;

is valid, and that after this point accessing "i" as an int is invalid. 
  Is that correct?  If so, I assume that you conider the following C 
code valid as well:

   int i;
   float f;
   memcpy (&i, &f, sizeof (i));

?

Also, in C++, given:

   extern void f(int *);
   void g() {
 int i;
 f(&i);
 /* HERE */
   }

do you believe that at the point marked HERE the dynamic type of "i" is 
indeterminate?  I think that if we allow the examples above, we have to 
assume that something may have reset the dynamic type of "i" here, 
meaning that we cannot assume that future stores through "float *" in 
the function do not alias "i".


-- 


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

[Bug fortran/29277] Formated stream output: Translate "\n" / achar(10) into "\r\n" on some platforms

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2006-10-04 05:28 
---
OK, I confess I sen a note to Richard Maine to doble check on this.  Brooks has
it absolutely right.  So, I will see what I can come up with for you.  If its a
requirement of the standard, it is not an enhancement.


-- 

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
   Severity|enhancement |normal
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-10-04 05:28:37
   date||
   Target Milestone|--- |4.2.0


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

[Bug fortran/29098] allocation of a pointer to a derived type crashes

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2006-10-04 04:49 ---
Fixed on trunk

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/29098] allocation of a pointer to a derived type crashes

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2006-10-04 04:48 ---
Subject: Bug 29098

Author: pault
Date: Wed Oct  4 04:48:35 2006
New Revision: 117424

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117424
Log:
2006-10-04  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/29098
* resolve.c (resolve_structure_cons): Do not return FAILURE if
component expression is NULL.

2006-10-04  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/29098
* gfortran.dg/default_initialization_2.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/default_initialization_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/29339] New: TImode ICE with -m32 -msse -mtune=i386

[jsm28 at gcc dot gnu dot org]

Compile the following (derived from gcc.dg/format/unnamed-1.c) on
x86_64-unknown-linux-gnu with -m32 -msse -mtune=i386.

extern void g (const char *, ...);

void
f (void)
{
  g ("", 0x);
}

You get an ICE (with both mainline as of 20061003 and older compilers):

u.c:6:10: warning: integer constant is too large for its type
u.c: In function 'f':
u.c:6: warning: integer constant is too large for 'long' type
u.c:7: error: unrecognizable insn:
(insn 8 7 9 3 (set (mem/i:TI (pre_dec:SI (reg/f:SI 7 sp)) [0 S16 A128])
(reg:TI 58)) -1 (nil)
(nil))
u.c:7: internal compiler error: in extract_insn, at recog.c:2077
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

(The choice of x86_64 -m32 is because this ICE requires 64-bit HOST_WIDE_INT;
32-bit i?86 configurations that use 64-bit HOST_WIDE_INT should show this as
well.)


-- 
   Summary: TImode ICE with -m32 -msse -mtune=i386
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
GCC target triplet: x86_64-*-*


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

[Bug target/28617] ___divti3 and ___umodti3 undefined for -m64 on powerpc-apple-darwin8

[howarth at nitro dot med dot uc dot edu]

--- Comment #6 from howarth at nitro dot med dot uc dot edu  2006-10-04 
00:12 ---
Yes, this is fixed in gcc trunk.


-- 


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

[Bug target/29338] [4.1 regression] ICE on valid C++ code

[debian-gcc at lists dot debian dot org]

--- Comment #2 from debian-gcc at lists dot debian dot org  2006-10-04 
00:06 ---
the file compiles when omitting -finline-limit=1200

  Matthias


-- 


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

[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should

[ian at airs dot com]

--- Comment #21 from ian at airs dot com  2006-10-03 23:44 ---
In C a general allocation function should work with a char array.  A specific
allocation function should use a union.  I don't think there are many existing
exceptions to these guidelines.

I think that code like that in PR 29272, which casts Node* to void* to Foo*, is
an unusual case.  And I believe we can handle that code correctly because of
the use of memcpy.  And if the code didn't use memcpy it would be clearly
noncomformant--which isn't to say that we should deliberately break it, but we
don't need to try extra hard to make it work.

So I don't see a serious problem in C either.  Am I missing something/


-- 


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

[Bug target/29337] -mfpmath=387 doesn't use fistp for double-to-integer conversion

[seongbae dot park at gmail dot com]

--- Comment #2 from seongbae dot park at gmail dot com  2006-10-03 23:37 
---
(In reply to comment #1)
> (In reply to comment #0)
> 
> > This makes a difference if/when the extra precision of 387 makes difference 
> 
> for an extra prescision try to use a `long double'.

I'm afraid you're missing my point.
The problem is that for 64-bit and 32-bit floating-point to integer conversion,
x86 (32bit) target uses fistp* whereas x86_64 (64-bit) target uses cvt* WHEN
-mfpmath=387.
This defeats the purpose of the option -mfpmath=387 which is supposed to make
floating-point computations to use 387, instead of SSE2.


-- 


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

[Bug target/29338] [4.1 regression] ICE on valid C++ code

[debian-gcc at lists dot debian dot org]

--- Comment #1 from debian-gcc at lists dot debian dot org  2006-10-03 
23:36 ---
Created an attachment (id=12381)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12381&action=view)
preprocessed source


-- 


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

[Bug target/29338] New: [4.1 regression] ICE on valid C++ code

[debian-gcc at lists dot debian dot org]

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

arm-linux-gnu, works with 4.0.4, fails with 4.1.2 20060928.


  Matthias


g++ -DHAVE_CONFIG_H -I. -I. -I.. -g -Wall -O2 -finline-limit=1200 -c
symmetry.cpp  -fPIC -DPIC -o .libs/symmetry.o  
basic.h:85: warning: 'struct GiNaC::map_function' has virtual functions but
non-virtual destructor   
basic.h:104: warning: 'class GiNaC::basic::visitor' has virtual functions but
non-virtual destructor 
ex.h:879: warning: 'class GiNaC::pointer_to_map_function' has virtual functions
but non-virtual destructor   
symmetry.h:44: warning: 'class GiNaC::symmetry::visitor' has virtual functions
but non-virtual destructor
numeric.h:80: warning: 'class GiNaC::numeric::visitor' has virtual functions
but non-virtual destructor  
container.h: In instantiation of 'GiNaC::container::visitor':
container.h:130:   instantiated from 'void GiNaC::container<
 >::accept(GiNaC::visitor&) cons
t [with C = std::list]' 
symmetry.cpp:497:   instantiated from here  
container.h:130: warning: 'class GiNaC::container::visitor' has
virtual functions but non-virtual destruct
or  
symmetry.cpp: In function 'GiNaC::ex GiNaC::symm(const GiNaC::ex&,
__gnu_cxx::__normal_iterator > >,
__gnu_cxx::__normal_iterator > >, bool)':  
symmetry.cpp:442: 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: [4.1 regression] ICE on valid C++ code
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: arm-linux-gnu


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

[Bug fortran/27900] ICE using intrinsics as arguments

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2006-10-03 22:37 ---
FX,

> When the len in "call sub(len)" is resolved, it is never given its correct
> return type, which leads to the ICE. I still don't understand why the implicit
> none is doing this on us... Paul, any idea?
> 
..bother, yes I was onto this a while back.  I will consult my notes and
come back to you.  I got severely stuck for some reason that I do not recall.

Paul


-- 


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

[Bug target/29337] -mfpmath=387 doesn't use fistp for double-to-integer conversion

[pluto at agmk dot net]

--- Comment #1 from pluto at agmk dot net  2006-10-03 21:57 ---
(In reply to comment #0)

> This makes a difference if/when the extra precision of 387 makes difference 

for an extra prescision try to use a `long double'.

$ cat fp.cpp
int convert( long double x ) { return (int)x; }
int convert( double x ) { return (int)x; }

convert(long double):
fldt8(%rsp)
fnstcw  -10(%rsp)
movzwl  -10(%rsp), %eax
orb $12, %ah
movw%ax, -12(%rsp)
fldcw   -12(%rsp)
fistpl  -16(%rsp)
fldcw   -10(%rsp)
movl-16(%rsp), %eax
ret

convert(double):
cvttsd2si   %xmm0, %eax
ret


-- 

pluto at agmk dot net changed:

   What|Removed |Added

 CC||pluto at agmk dot net


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

[Bug fortran/20891] allocation depends on other object in same allocation

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2006-10-03 21:41 ---
Fixed on trunk

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/20779] ALLOCATEing the STAT variable not detected

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2006-10-03 21:41 ---
Fixed on trunk

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/20779] ALLOCATEing the STAT variable not detected

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2006-10-03 21:40 ---
Subject: Bug 20779

Author: pault
Date: Tue Oct  3 21:40:24 2006
New Revision: 117415

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117415
Log:
2006-10-03  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/20779
PR fortran/20891
* resolve.c (find_sym_in_expr): New function that returns true
if a symbol is found in an expression.
(resolve_allocate_expr): Check whether the STAT variable is
itself allocated in the same statement.  Use the call above to
check whether any of the allocated arrays are used in array
specifications in the same statement.

2006-10-03  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/20779
PR fortran/20891
* gfortran.dg/alloc_alloc_expr_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/alloc_alloc_expr_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/20891] allocation depends on other object in same allocation

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2006-10-03 21:40 ---
Subject: Bug 20891

Author: pault
Date: Tue Oct  3 21:40:24 2006
New Revision: 117415

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117415
Log:
2006-10-03  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/20779
PR fortran/20891
* resolve.c (find_sym_in_expr): New function that returns true
if a symbol is found in an expression.
(resolve_allocate_expr): Check whether the STAT variable is
itself allocated in the same statement.  Use the call above to
check whether any of the allocated arrays are used in array
specifications in the same statement.

2006-10-03  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/20779
PR fortran/20891
* gfortran.dg/alloc_alloc_expr_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/alloc_alloc_expr_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/29337] New: -mfpmath=387 doesn't use fistp for double-to-integer conversion

[seongbae dot park at gmail dot com]

-mfpmath=387 used on x86_64 is supposed to force gcc to use 387 for floating
point{math. However, even with the option, gcc generates cvtts{s,d}2* instead
of fistp* for floating-point to integer conversion. 

This makes a difference if/when the extra precision of 387 makes difference to
the conversion - which -mfpmath=387 is supposed to prevent.


-- 
   Summary: -mfpmath=387 doesn't use fistp for double-to-integer
conversion
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: seongbae dot park at gmail dot com
  GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug target/29032] gcc.dg/cleanup-10.c execution test times out on powerpc-apple-darwin8 at -m64

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2006-10-03 20:53 ---
(In reply to comment #6)
> I don't believe this has yet been made to work on Darwin.

The only thing this testcase depends on is the undwinder which means this is a
normal bug and not an enhancement.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|enhancement |normal
   Keywords||wrong-code


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

[Bug target/29032] gcc.dg/cleanup-10.c execution test times out on powerpc-apple-darwin8 at -m64

[geoffk at gcc dot gnu dot org]

--- Comment #6 from geoffk at gcc dot gnu dot org  2006-10-03 20:51 ---
I don't believe this has yet been made to work on Darwin.


-- 

geoffk at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug testsuite/28837] need to prune "can't find atom for N_GSYM stabs" warnings on Darwin for -m64

[geoffk at gcc dot gnu dot org]

--- Comment #1 from geoffk at gcc dot gnu dot org  2006-10-03 20:50 ---
The patch here is clearly wrong.  If you don't like the warnings, you should
work out why they are being output and fix the underlying bug, rather than
ignoring them in the testsuite.


-- 


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

[Bug target/28617] ___divti3 and ___umodti3 undefined for -m64 on powerpc-apple-darwin8

[geoffk at gcc dot gnu dot org]

--- Comment #5 from geoffk at gcc dot gnu dot org  2006-10-03 20:48 ---
This should be fixed, right?


-- 

geoffk at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/28026] Cross compiles involving Darwin fail

[geoffk at gcc dot gnu dot org]

--- Comment #6 from geoffk at gcc dot gnu dot org  2006-10-03 20:47 ---
In

I report that cross-compiling from powerpc-darwin to i386-darwin succeeds.


-- 

geoffk at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug target/22118] dwarf-2 is not support with -m64 on ppc-dariwn

[geoffk at gcc dot gnu dot org]

--- Comment #2 from geoffk at gcc dot gnu dot org  2006-10-03 20:35 ---
This is fixed in later versions of the darwin developer tools.


-- 

geoffk at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME


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

[Bug rtl-optimization/29336] shorten_branchen and machine-dependent constant pool placement should be integrated

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-10-03 20:30 ---
Looks related to PR 9702 and maybe PR 9703


-- 


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

[Bug target/15834] NO_IMPLICIT_EXTERN_C should be gotten rid of

[geoffk at gcc dot gnu dot org]

--- Comment #8 from geoffk at gcc dot gnu dot org  2006-10-03 20:27 ---
Fixed with , queued
for 4.3.


-- 

geoffk at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |geoffk at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-12-10 05:32:28 |2006-10-03 20:27:42
   date||


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

[Bug fortran/25092] Result lengths different at different entries

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2006-10-03 20:17 ---
Fixed on trunk

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/25091] Results do not conform at different entries

[pault at gcc dot gnu dot org]

--- Comment #5 from pault at gcc dot gnu dot org  2006-10-03 20:16 ---
Fixed on trunk

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/29284] [4.1/4.2 Regression] ICE for optional subroutine argument

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2006-10-03 20:16 ---
Fixed on trunk

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/29322] [4.1/4.2 Regression] ICE with character optional arg

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2006-10-03 20:15 ---
Fixed on trunk

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/29321] [4.1/4.2 Regression] optional arguments+derived types = segmentation fault

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2006-10-03 20:15 ---
Fixed on trunk

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/25092] Result lengths different at different entries

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2006-10-03 20:13 ---
Subject: Bug 25092

Author: pault
Date: Tue Oct  3 20:13:03 2006
New Revision: 117413

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117413
Log:
2006-10-03  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/29284
PR fortran/29321
PR fortran/29322
* trans-expr.c (gfc_conv_function_call): Check the expression
and the formal symbol are present when testing the actual
argument.

PR fortran/25091
PR fortran/25092
* resolve.c (resolve_entries): It is an error if the entries
of an array-valued function do not have the same shape.

2006-10-03  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/29284
* gfortran.dg/optional_assumed_charlen_1.f90: New test.

PR fortran/29321
PR fortran/29322
* gfortran.dg/missing_optional_dummy_2.f90: New test.

PR fortran/25091
PR fortran/25092
* gfortran.dg/entry_array_specs_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/entry_array_specs_1.f90
trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_2.f90
trunk/gcc/testsuite/gfortran.dg/optional_assumed_charlen_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/29321] [4.1/4.2 Regression] optional arguments+derived types = segmentation fault

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2006-10-03 20:13 ---
Subject: Bug 29321

Author: pault
Date: Tue Oct  3 20:13:03 2006
New Revision: 117413

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117413
Log:
2006-10-03  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/29284
PR fortran/29321
PR fortran/29322
* trans-expr.c (gfc_conv_function_call): Check the expression
and the formal symbol are present when testing the actual
argument.

PR fortran/25091
PR fortran/25092
* resolve.c (resolve_entries): It is an error if the entries
of an array-valued function do not have the same shape.

2006-10-03  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/29284
* gfortran.dg/optional_assumed_charlen_1.f90: New test.

PR fortran/29321
PR fortran/29322
* gfortran.dg/missing_optional_dummy_2.f90: New test.

PR fortran/25091
PR fortran/25092
* gfortran.dg/entry_array_specs_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/entry_array_specs_1.f90
trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_2.f90
trunk/gcc/testsuite/gfortran.dg/optional_assumed_charlen_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/25091] Results do not conform at different entries

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2006-10-03 20:13 ---
Subject: Bug 25091

Author: pault
Date: Tue Oct  3 20:13:03 2006
New Revision: 117413

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117413
Log:
2006-10-03  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/29284
PR fortran/29321
PR fortran/29322
* trans-expr.c (gfc_conv_function_call): Check the expression
and the formal symbol are present when testing the actual
argument.

PR fortran/25091
PR fortran/25092
* resolve.c (resolve_entries): It is an error if the entries
of an array-valued function do not have the same shape.

2006-10-03  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/29284
* gfortran.dg/optional_assumed_charlen_1.f90: New test.

PR fortran/29321
PR fortran/29322
* gfortran.dg/missing_optional_dummy_2.f90: New test.

PR fortran/25091
PR fortran/25092
* gfortran.dg/entry_array_specs_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/entry_array_specs_1.f90
trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_2.f90
trunk/gcc/testsuite/gfortran.dg/optional_assumed_charlen_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/29322] [4.1/4.2 Regression] ICE with character optional arg

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2006-10-03 20:13 ---
Subject: Bug 29322

Author: pault
Date: Tue Oct  3 20:13:03 2006
New Revision: 117413

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117413
Log:
2006-10-03  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/29284
PR fortran/29321
PR fortran/29322
* trans-expr.c (gfc_conv_function_call): Check the expression
and the formal symbol are present when testing the actual
argument.

PR fortran/25091
PR fortran/25092
* resolve.c (resolve_entries): It is an error if the entries
of an array-valued function do not have the same shape.

2006-10-03  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/29284
* gfortran.dg/optional_assumed_charlen_1.f90: New test.

PR fortran/29321
PR fortran/29322
* gfortran.dg/missing_optional_dummy_2.f90: New test.

PR fortran/25091
PR fortran/25092
* gfortran.dg/entry_array_specs_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/entry_array_specs_1.f90
trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_2.f90
trunk/gcc/testsuite/gfortran.dg/optional_assumed_charlen_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/29284] [4.1/4.2 Regression] ICE for optional subroutine argument

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2006-10-03 20:13 ---
Subject: Bug 29284

Author: pault
Date: Tue Oct  3 20:13:03 2006
New Revision: 117413

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117413
Log:
2006-10-03  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/29284
PR fortran/29321
PR fortran/29322
* trans-expr.c (gfc_conv_function_call): Check the expression
and the formal symbol are present when testing the actual
argument.

PR fortran/25091
PR fortran/25092
* resolve.c (resolve_entries): It is an error if the entries
of an array-valued function do not have the same shape.

2006-10-03  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/29284
* gfortran.dg/optional_assumed_charlen_1.f90: New test.

PR fortran/29321
PR fortran/29322
* gfortran.dg/missing_optional_dummy_2.f90: New test.

PR fortran/25091
PR fortran/25092
* gfortran.dg/entry_array_specs_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/entry_array_specs_1.f90
trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_2.f90
trunk/gcc/testsuite/gfortran.dg/optional_assumed_charlen_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/29336] New: shorten_branchen and machine-dependent constant pool placement should be integrated

[amylaar at gcc dot gnu dot org]

See also the thread started with:
http://gcc.gnu.org/ml/gcc/2006-05/msg00304.html

shorten_branches and, where applicable branch splitting (like in the sh_reorg),
should be combined with machine-dependent constant pool placement
and small-scale hot/cold partitioning.  constant pool placement should take
account of branch probabilities.

I'll use neg_pool_range / pool_range in the following to describe the
ranges for constants as they are used in the arm machine description.

Place taken up by constants falls into two categories:
- per-constant space, which is easily calculable from each individual
  constant.  That space is known to be needed at most once per constant
  reference (it might be less if constants are shared)
- per-pool space.  Some constants need alignments, but the worst cost in any
  one pool from this requirement should be the maximum alignment minus the
  minimum size alignment.
  If a pool can't be placed after an existing barrier, a new one has to be
  artifically created, i.e. a jump around the pool needs to be insterted.
  If pools are placed such as to have the minimum number of pools,
  they must be spaced by at least the sum of the minumum neg_pool_range
  and the minimum pool_range of constants inside.
  If other considerations are used for constant pool placement, e.g.
  cost lengthened branches and their execution frequency, more, smaller,
  pools can result.  The worst case would be to have one pool for every
  constant reference, but no more than one per basic block plus number
  of ranges crossed.
  Some simple rules for minimum pool size can also help to put a more
  sensible upper bound for pool overhead.  I.e. you could say to put
  additional constants within range into a pool till the overhead is
  at most, say, 25%, or no more constants are in range.

While some improvements to the estimates can be made by observing when the
same constant loaded several times in short sucession, I wouldn't expect
this to be a significant factor, since cse would reduce the amount of such
loads.  Thus, for size estimates, we can pretend constants can't be commoned.

After doing one insn address calculating pass with optimistic assumptions,
i.e. assume all branches are short and no constant pools need to be placed,
for each constant, we can specify a maximum range of instructions within which
it has to be placed, starting at the address of the reference minus
neg_pool_range, and extending up to the address of the reference plus
pool_range.
Thus, to calculate an upper bound of the size of constant pools within
an offset range (e.g. branch site to branch destination), we take the
size of all constants that might have been placed up to the larger address,
subtract the size of all the constants that are known to have been placed
up to the lower address, and add the pool overhead.
Assuming we have adopted the 25% rule above, there is no need to keep track
of details of alignments and individual constant sizes; all we need is a
tally of the constant sizes.  We calculate the difference of the tallies,
add a quarter (truncated), and calculate a preliminary range; then we take
this range, divide it by the pool spacing PS (1) (rounded up), and multiply
it by the maximum pool overhead (alignment plus jump); this product is then
added to the preliminary range to get the actual upper bound for the range.
This calculation can be integrated into the align_fuzz comuptation.

 (1) PS is calculated here as minimum neg_pool_range plus minimum pool_range
 minus maximum pool overhead.

In order to integrate constants used for branches, each insn has to keep
three addresses: the overly optimistic one calculated at the start, which is
used to get bounds for the range in which a constant might be placed, the
one from the last relaxation pass, which is used for branch offset
calculations, and the one that is comupted at some time during the current
relaxation pass.  The latter two can be kept in arrays that are swapped
around to avoid unnecessary copying.  Or there might be an array of structs
describing each insn, and the struct contains an array with the addresses,
and which to use as current and previous changes with each pass.
A branch is considered needing a constant according to the offset calculation
using the addresses from the previous relaxation pass (that is no constant
if the offset can be encoded into the instruction).

For the previous relaxation pass (if any), there are two tally entries for
each insn: the total constant size known to have been placed so, and the
total constant size that might have been placed so far.
For the current relaxation pass, there are corresponding entries, but
they give the differential (first derivative) of these values; they area
zero-initialized at the start of the pass, and at the end consecutevely
summed up to give the total tallies which are referenced in the next pass
as the two tallies described before.
When an insn is encountered that references a constant (that m

[Bug target/17174] Fortran nearest broken on AIX

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2006-10-03 19:14 ---
(In reply to comment #1)
> I think ia64-hp-hpux11.23 is having a problem here too.  I get a failure with
> the test gfortran.dg/large_real_kind_form_io_2.f90, which uses the nearest
> intrinsic.  I use mpfr 2.2 to build.  I think the bug may be with mpfr 2.2
> only.  gfc_simplify_nearest is ifdef'ed to do something different when using
> mpfr 2.2 than with older mpfr's.
> 

The ifdef appeared long after David's initial bug report, which suggests
the problem is with AIX's libm's nextafter routine.


-- 


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

[Bug c++/29138] [4.0 Regression] access declarations don't work for classes

[mmitchel at gcc dot gnu dot org]

--- Comment #5 from mmitchel at gcc dot gnu dot org  2006-10-03 18:39 
---
Subject: Bug 29138

Author: mmitchel
Date: Tue Oct  3 18:39:32 2006
New Revision: 117411

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117411
Log:
PR c++/29138
* decl2.c (grokfield): Don't handle access declarations here.
* parser.c (cp_parser_using_declaration): Handle access
declarations too.
(cp_parser_block_declaration): Adjust calls to
cp_parser_using_declaration.
(cp_parser_member_declaration): Likewise.  Use
cp_parser_using_declaration to look for access_declarations.
PR c++/29138
* g++.dg/inherit/access8.C: New test.
* g++.dg/template/dtor4.C: Tweak error messages.

Modified:
trunk/gcc/cp/parser.c


-- 


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

[Bug c++/29020] [4.0/4.1/4.2 regression] ICE using A::A instead of A in friend declaration

[mmitchel at gcc dot gnu dot org]

--- Comment #2 from mmitchel at gcc dot gnu dot org  2006-10-03 18:35 
---
The bug here is that the parser is not resolving A::A to A; instead it is
treating that as a typename type.  Since the qualified name is appearing in a
declaration, and since the containing class is a not a class template, we
should resolve the qualified name at this point.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mark at codesourcery dot com
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug tree-optimization/29290] [4.1 Regression] SPEC CPU2000 178.galgel ICE using -O3 -ftree-loop-linear

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2006-10-03 18:20 ---
A regression hunt of the 4.1 branch on powerpc-linux identified the following
patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=116223

r116223 | spop | 2006-08-17 13:14:26 + (Thu, 17 Aug 2006)


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||spop at gcc dot gnu dot org


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

[Bug tree-optimization/29330] -O -ftree-loop-linear --> virtual memory exhausted

[pluto at agmk dot net]

--- Comment #3 from pluto at agmk dot net  2006-10-03 18:19 ---
works fine with 4.1.2svn.

$ g++ gcc-pr29330.c -Wall -c -O -ftree-loop-linear -m32 -fmem-report

Memory still allocated at the end of the compilation process
Size   AllocatedUsedOverhead
8   4096  56 120
1616k 12k352
64   124k119k   1984
128 81926528 112
256  424k421k   5936
512   12k   9216 168
1024 112k112k   1568
2048  16k 12k224
4096  80k 80k   1120
8192  48k 48k336
16384 16k 16k 56
32768 32k 32k 56
65536576k576k504
524288512k  0  56
112  216k207k   3024
208   16k 12k224
192   12k 11k168
160 81925440 112
176  152k149k   2128
48   228k225k   3648
3244k 43k792
8080k 79k   1120
Total   2736k   2180k 23k


-- 


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

[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc

[bonzini at gnu dot org]

--- Comment #21 from bonzini at gnu dot org  2006-10-03 18:07 ---
Note that I don't oppose at all fixing the problem in
swap_commutative_operands_p.  At the very least, you have to change at the very
least simplify-rtx.c's uses of commutative_operand_precedence to use s_c_o_p
instead, but that's a minor problem.

I'm also worried of the interaction between this change to
swap_commutative_operands_p and swap_commutative_operands_with_target which
(even though I refactored it quite recently to happen very early, in expand) is
an optimization that CSE has performed for years and has big impact on x86, for
example on crafty.


-- 


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

[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc

[dje at watson dot ibm dot com]

--- Comment #22 from dje at watson dot ibm dot com  2006-10-03 18:09 ---
Subject: Re:  [4.2 Regression] Performace problem with indexed load/stores on
powerpc 

I am not suggesting that the problem has to be solved in
swap_commutative_operands, etc.  I would think that GCC should be able to
create commutative addresses where they are formed.


-- 


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

[Bug c++/29138] [4.0 Regression] access declarations don't work for classes

[mmitchel at gcc dot gnu dot org]

--- Comment #4 from mmitchel at gcc dot gnu dot org  2006-10-03 18:09 
---
Fixed in 4.1.2, 4.2.0.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW
Summary|[4.0/4.1/4.2 Regression]|[4.0 Regression] access
   |access declarations don't   |declarations don't work for
   |work for classes|classes


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

[Bug c++/29138] [4.0/4.1/4.2 Regression] access declarations don't work for classes

[mmitchel at gcc dot gnu dot org]

--- Comment #3 from mmitchel at gcc dot gnu dot org  2006-10-03 18:06 
---
Subject: Bug 29138

Author: mmitchel
Date: Tue Oct  3 18:06:00 2006
New Revision: 117410

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117410
Log:
PR c++/29138
* decl2.c (grokfield): Don't handle access declarations here.
* parser.c (cp_parser_using_declaration): Handle access
declarations too.
(cp_parser_block_declaration): Adjust calls to
cp_parser_using_declaration.
(cp_parser_member_declaration): Likewise.  Use
cp_parser_using_declaration to look for access_declarations.
PR c++/29138
* g++.dg/inherit/access8.C: New test.
* g++.dg/template/dtor4.C: Tweak error messages.

Added:
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/inherit/access8.C
Modified:
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/decl2.c
branches/gcc-4_1-branch/gcc/cp/parser.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/dtor4.C


-- 


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

[Bug c++/29138] [4.0/4.1/4.2 Regression] access declarations don't work for classes

[mmitchel at gcc dot gnu dot org]

--- Comment #2 from mmitchel at gcc dot gnu dot org  2006-10-03 18:04 
---
Subject: Bug 29138

Author: mmitchel
Date: Tue Oct  3 18:04:10 2006
New Revision: 117409

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117409
Log:
PR c++/29138
* decl2.c (grokfield): Don't handle access declarations here.
* parser.c (cp_parser_using_declaration): Handle access
declarations too.
(cp_parser_block_declaration): Adjust calls to
cp_parser_using_declaration.
(cp_parser_member_declaration): Likewise.  Use
cp_parser_using_declaration to look for access_declarations.
PR c++/29138
* g++.dg/inherit/access8.C: New test.
* g++.dg/template/dtor4.C: Tweak error messages.

Added:
trunk/gcc/testsuite/g++.dg/inherit/access8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/template/dtor4.C


-- 


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

[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc

[dje at gcc dot gnu dot org]

--- Comment #20 from dje at gcc dot gnu dot org  2006-10-03 17:58 ---
Paolo, forcing all addresses through legitimize_address should not be the goal.
 The wrong ordering has performance effects, but is not an invalid address. 
While the performance effects on POWER-specific, canonicalizing addresses is a
general GCC issue.  GCC appears to want REG_POINTER first, but does not enforce
it.

I am willing to consider target-specific fixes as a last resort, but I do not
see any reason that GCC should not create and maintain a canonical address
ordering of REG_POINTER first.  Trying to correct this in the rs6000 backend is
a kludge.


-- 


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

[Bug target/17174] Fortran nearest broken on AIX

[sje at cup dot hp dot com]

--- Comment #1 from sje at cup dot hp dot com  2006-10-03 17:55 ---
I think ia64-hp-hpux11.23 is having a problem here too.  I get a failure with
the test gfortran.dg/large_real_kind_form_io_2.f90, which uses the nearest
intrinsic.  I use mpfr 2.2 to build.  I think the bug may be with mpfr 2.2
only.  gfc_simplify_nearest is ifdef'ed to do something different when using
mpfr 2.2 than with older mpfr's.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com


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

[Bug target/28604] [4.1/4.2 Regression] gcc.c-torture/execute/20050604-1.c fails on IA64 at -O3

[sje at cup dot hp dot com]

--- Comment #9 from sje at cup dot hp dot com  2006-10-03 17:42 ---
I submitted a patch for this defect,
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01108.html
however the failure seems to have gone away even without applying this patch.
I think (but did not verify) that this patch went away due to this fix by
Roger Sayle:
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00456.html

Since the failure no longer happens I am closing the defect as fixed.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/29332] default argument access checking is not done at the point where the default argument expression are appears

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2006-10-03 17:00 ---
Confirmed, not a regression.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||2.95 3.2.3 3.4.0 4.0.0 4.2.0
   ||4.1.2
   Last reconfirmed|-00-00 00:00:00 |2006-10-03 17:00:00
   date||


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

[Bug c++/29332] default argument access checking is not done at the point where the default argument expression are appears

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2006-10-03 16:58 ---
Actually I take back comment #3.  This code is invalid as it violates 8.3.6/5:
"The names in the expressions are bound, and the semantics constraints are
checked, at the point where the default argument expression appears.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||accepts-invalid
Summary|No error given for derived- |default argument access
   |to-inaccessible-base|checking is not done at the
   |conversion in default arg.  |point where the default
   ||argument expression are
   ||appears


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

[Bug c++/29332] No error given for derived-to-inaccessible-base conversion in default arg.

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2006-10-03 16:51 ---
Reopening for a second.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug middle-end/29335] New: transcendental functions with constant arguments should be resolved at compile-time

[ghazi at gcc dot gnu dot org]

We should use GMP/MPFR from inside builtins.c to resolve things like e.g.
cos(0.12345) at compile-time.

Need to figure out:

1.  Whether a certain minimum version of GMP/MPFR is required to avoid known
bugs, etc.

2.  Whether we should include GMP/MPFR in the svn archive like we do for intl
and zlib.

3.  Whether GMP/MPFR works on all the platforms/configurations that GCC
supports.  Are we ready to require a GMP/MPFR port for every port of GCC?

4.  If we don't do #2 and there is no system GMP/MPFR or the system lib is too
old, or if we trip over #3 and can't have GMP/MPFR, then what?  Do we require
the user to go get/port it, or silently eliminate this optimization during the
build process?


-- 
   Summary: transcendental functions with constant arguments should
be resolved at compile-time
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org


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

[Bug c++/29332] No error given for derived-to-inaccessible-base conversion in default arg.

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-10-03 16:45 ---
(In reply to comment #2)
> Ok, here's something that's a little closer to the original example: 
I get an error with that example:
t.cc:8: error: default argument for parameter of type ‘A&’ has type ‘B’

In fact the following is valid code which is why we cannot error until you
actually call f:
// line 1
class A {};
class B : private A { friend void g(void);};

extern B b;

void f( A & = b); // ERROR

void g(void)
{
  f();
}


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/29332] No error given for derived-to-inaccessible-base conversion in default arg.

[widman at gimpel dot com]

--- Comment #2 from widman at gimpel dot com  2006-10-03 16:38 ---
Ok, here's something that's a little closer to the original example: 

class A; 
class B;

extern B b; 

struct C  { 
static int f( A& = b); // ERROR
};

class A{};
class B : public A {};

int n = C::f();

Failing to report this error doesn't appear to lead to a "real" bug, but it's
still ill-formed, so when you try to port your code to a compiler with the EDG
front end, you'll get:

error: a reference of type "A &" (not const-qualified) cannot
  be initialized with a value of type "B"
  static int f( A& = b); // ERROR
 ^


-- 


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

[Bug target/28568] compiler generates incorrect ARM instructions when using long bitfields

[rearnsha at gcc dot gnu dot org]

--- Comment #11 from rearnsha at gcc dot gnu dot org  2006-10-03 16:25 
---
(In reply to comment #7)
> Subject: RE:  compiler generates incorrect ARM instructions when using long
> bitfields
> 
> Why not? What are the criteria?  

Because it isn't a regression.

A regression is when all of the following are satisfied:

a) It's a bug
b) A previous release of the compiler supported the compiler configuration
c) That previous release produced correct code
d) This release produces the wrong code

In this case b) does not hold and hence c) can't either.


-- 


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

[Bug objc/29195] [4.1 Regression] ICE in expand_expr_real_1, at expr.c:6932

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2006-10-03 16:24 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug objc/29195] [4.1 Regression] ICE in expand_expr_real_1, at expr.c:6932

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2006-10-03 16:23 ---
Subject: Bug 29195

Author: pinskia
Date: Tue Oct  3 16:23:48 2006
New Revision: 117402

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117402
Log:
2006-09-26  Andrew Pinski  <[EMAIL PROTECTED]>

PR objc/29195
* objc-act.c (objc_push_parm): If we change the type of the
decl, relayout the decl.
2006-09-26  Andrew Pinski  <[EMAIL PROTECTED]>

PR objc/29195
* objc/compile/method-1.m: New test.






Added:
branches/gcc-4_1-branch/gcc/testsuite/objc/compile/method-1.m
  - copied unchanged from r117229,
trunk/gcc/testsuite/objc/compile/method-1.m
Modified:
branches/gcc-4_1-branch/gcc/objc/ChangeLog
branches/gcc-4_1-branch/gcc/objc/objc-act.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/29330] -O -ftree-loop-linear --> virtual memory exhausted

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-10-03 16:21 ---
Confirmed.


-- 

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 |2006-10-03 16:21:27
   date||


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

[Bug tree-optimization/29330] -O -ftree-loop-linear --> virtual memory exhausted

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-10-03 16:17 ---
We are trying to allocate 3.65 GB.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||memory-hog


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

[Bug fortran/29317] gfortran.dg/exponent_1.f90 failure

[fxcoudert at gcc dot gnu dot org]

--- Comment #8 from fxcoudert at gcc dot gnu dot org  2006-10-03 16:17 
---
(In reply to comment #5)
> The gfortran.dg/exponent_1.f90 and gfortran.dg/nearest_1.f90 are falling
> on hppa2.0w-hp-hpux11.11.  I updated to mpfr 2.2.0 and the tests are still
> failing.  Possibly, I need a complete rebuild.

I though I had done a complete rebuild, but I didn't. Rebuilding everything
from scratch makes it work again. Sorry.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should

[mark at codesourcery dot com]

--- Comment #20 from mark at codesourcery dot com  2006-10-03 16:13 ---
Subject: Re:  [4.0/4.1/4.2 Regression] placement new
 does not change the dynamic type as it should

ian at airs dot com wrote:

> Fortunately I believe that in a correct program we only have a problem when we
> can actually see the placement new (can any disprove that)?  I personally 
> don't
> have a problem with saying that placement new is special.  When placement new
> is used, it has to move the pointer into alias set 0.

What about in C, as opposed to C++?

I agree that the obvious special cases are access through char*, arrays 
of characters, and placement new.  But, I'm afraid that there are lots 
of other allocation functions out there that are not spelled "operator 
new", and requiring decoration for them isn't something that (as far as 
I know) other compilers require.


-- 


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

[Bug ada/27936] [4.2 Regression] gnatbind fails to link on Tru64 UNIX

[ebotcazou at gcc dot gnu dot org]

--- Comment #10 from ebotcazou at gcc dot gnu dot org  2006-10-03 16:13 
---
Investigating.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|ebotcazou at gcc dot gnu dot|
   |org |
 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-06-09 09:06:05 |2006-10-03 16:13:15
   date||
Version|unknown |4.2.0


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

[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-10-03 16:11 ---
Actually this is a case where jump threading gets in the way of PHI-OPT. 
Really PHI-OPT should be put before VRP and DOM, I don't know why it was not.


-- 

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 |2006-10-03 16:11:22
   date||
Summary|Generation of MAX_EXPRs and |Jump threading getting in
   |MIN_EXPRs missed by phiopt  |the way of PHI-OPT


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

[Bug bootstrap/26764] [4.0/4.1 only] sed command garbled when generating macro_list

[ghazi at gcc dot gnu dot org]

--- Comment #4 from ghazi at gcc dot gnu dot org  2006-10-03 16:10 ---
Seems to have been fixed on trunk in April and on 4.0/4.1 branches in
September.

http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01260.html
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01157.html
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00186.html

I verified that e.g. sun gets replaced by __sun__ on solaris10 and solaris7.


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.0.4 4.1.2 4.2.0
 Resolution||FIXED
   Target Milestone|--- |4.0.4


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

[Bug tree-optimization/29333] Generation of MAX_EXPRs and MIN_EXPRs missed by phiopt

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization


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

[Bug c++/29332] No error given for derived-to-inaccessible-base conversion in default arg.

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-10-03 16:05 ---
We just don't error until you use the function, in that the following errors:
// line 1
class A {};
class B : private A { };

extern B b;

int f( A & = b); // ERROR

A & a = b; // ERROR

int x = f(); // ERROR


-- 


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

[Bug tree-optimization/29333] Generation of MAX_EXPRs and MIN_EXPRs missed by phiopt

[roberto dot costa at st dot com]

--- Comment #1 from roberto dot costa at st dot com  2006-10-03 16:05 
---
Created an attachment (id=12378)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12378&action=view)
Source code of the example


-- 


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

[Bug tree-optimization/29333] New: Generation of MAX_EXPRs and MIN_EXPRs missed by phiopt

[roberto dot costa at st dot com]

There are cases in which phiopt doesn't recognize MAX_EXPRs or MIN_EXPRs
patterns.
In particular, source codes that look very similar at first sight may induce
phiopt to behave differently.

Let's consider the following two functions:

-
int minmax_correct(int a)
{
if (a > 32767) a = 32767;
else if (a < -32768) a = -32768;

return a;
}

int minmax_wrong(int a)
{
if (a > 32767) a = 32767;
if (a < -32768) a = -32768;

return a;
}
-

MIN_EXPRs and MAX_EXPRs are generated for the first function, but not for the
second.

Here is the contents of trace file minmax.c.042t.phicprop1:

-
;; Function minmax_correct (minmax_correct)

minmax_correct (a)
{
:
  if (a_2 > 32767) goto ; else goto ;

:;
  if (a_2 < -32768) goto ; else goto ;

:;

  # a_1 = PHI <32767(2), a_2(3), -32768(4)>;
:;
   = a_1;
  return ;

}

;; Function minmax_wrong (minmax_wrong)

Removing basic block 6
minmax_wrong (a)
{
:
  if (a_3 > 32767) goto ; else goto ;

:;
  if (a_3 < -32768) goto ; else goto ;

  # a_9 = PHI ;
:;

  # a_2 = PHI ;
:;
   = a_2;
  return ;

}
-

And here is minmax.c.043t.phiopt1:

-
;; Function minmax_correct (minmax_correct)

Removing basic block 4
Removing basic block 3
Merging blocks 2 and 5
minmax_correct (a)
{
:
  a_7 = MAX_EXPR <-32768, a_2>;
  a_8 = MIN_EXPR ;
   = a_8;
  return ;

}

;; Function minmax_wrong (minmax_wrong)

minmax_wrong (a)
{
:
  if (a_3 > 32767) goto ; else goto ;

:;
  if (a_3 < -32768) goto ; else goto ;

  # a_9 = PHI ;
:;

  # a_2 = PHI ;
:;
   = a_2;
  return ;

}
-


-- 
   Summary: Generation of MAX_EXPRs and MIN_EXPRs missed by phiopt
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roberto dot costa at st dot com


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

[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should

[ian at airs dot com]

--- Comment #19 from ian at airs dot com  2006-10-03 16:03 ---
Mike suggests: "it would appear that it is unsafe to reorder writes of
otherwise non-conflicting types past each other as type based analysis alone
isn't enough to ensure they don't conflict."

That would be bad in the general case.  It would not be as bad as prohibiting
the reorder of reads and writes, but it would be bad.  Let's find a way such
that we do not have to do that.

Fortunately I believe that in a correct program we only have a problem when we
can actually see the placement new (can any disprove that)?  I personally don't
have a problem with saying that placement new is special.  When placement new
is used, it has to move the pointer into alias set 0.

With regard to Mark's comment #15, the problem here is not heap allocation, as
I see it.  The C standard explains how to use heap allocation: use a char*
pointer.  The problem is doing something akin to heap allocation without using
a char* pointer.


-- 

ian at airs dot com changed:

   What|Removed |Added

 CC||ian at airs dot com


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

[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2006-10-03 15:56 ---
Confirmed via the dup bug.


-- 

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 |2006-10-03 15:56:21
   date||


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

[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-10-03 15:55 ---
*** Bug 29331 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||gcc-bklyn at sneakemail dot
   ||com


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

[Bug c++/29331] Missing header files only generate warning with -MMD

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-10-03 15:55 ---


*** This bug has been marked as a duplicate of 28435 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc

[bergner at vnet dot ibm dot com]

--- Comment #19 from bergner at vnet dot ibm dot com  2006-10-03 15:51 
---
David has already said offline that he would reject any patch that would cause
us to view a non-REG_POINTER + REG_POINTER expression an not legitimate.  I
agree with that.

Sorry, but I'm slowly learning the machine description format.  How exactly
would adding a splitter help us?


-- 


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

[Bug fortran/20541] TR 15581: ALLOCATABLE components

[sfilippone at uniroma2 dot it]

--- Comment #33 from sfilippone at uniroma2 dot it  2006-10-03 15:48 ---
The latest patch alloc_comp1002.diff has survived everything I could throw at
it in the last few hours. Go for it. 


-- 


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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[pault at gcc dot gnu dot org]

--- Comment #6 from pault at gcc dot gnu dot org  2006-10-03 15:06 ---
(In reply to comment #5)

> The problem lies in the absence of global actual/formal argument checking;
> where there is an explicit interface, all works correctly.

Actually, it is not as bad as I thought:
(i)'p' being a non-sequence type dummy in a non-contained procedure should
generate an error because there is no way in which type association can occur
between the caller and 'a'.
(ii) The same is true of the actual argument in the call to 'a' from 'b'; since
'a' is external, a sequence type is required.

Paul 


-- 


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

[Bug fortran/29232] No warning/error for duplicate construct name

[pault at gcc dot gnu dot org]

--- Comment #1 from pault at gcc dot gnu dot org  2006-10-03 14:38 ---
Created an attachment (id=12377)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12377&action=view)
This fixes the bug.

This has to be sorted out at resolution time because it is the label 'vortex'
that blocks the host association of the derived type 'vortex'.  Thus we wit
until resolving the symbols in a namespace and use the logic:

if variable is of host associated derived type
  {
 if a symbol is present in the variable's namespace that is 
  not a derived type or is not an identical derived type
   {
  error ("the symbol blocks the derived type")
  return FAILURE
   }
}
As soon as the allocatable components are out of the door, I will submit this
with a test case.

Paul




-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug tree-optimization/25737] ACATS c974001 c974013 hang with struct aliasing

[ebotcazou at gcc dot gnu dot org]

--- Comment #40 from ebotcazou at gcc dot gnu dot org  2006-10-03 14:13 
---
> Agreed.  The Ada FE should either change or prove that there is a
> design/implementation flaw in the aliasing machinery.

I think we can prove that there is a discrepancy between the Tree type-based
aliasing analysis and the RTL type-based aliasing analysis when these flags
are set, i.e. they don't agree on the alias set used to access some objects.

Where they should meet is unclear for the time being...


-- 


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

[Bug c++/29332] New: No error given for derived-to-private-base conversion in default arg.

[widman at gimpel dot com]

For the following case: 

// line 1
class A {};
class B : private A { };

extern B b;

void f( A & = b); // ERROR

A & a = b; // ERROR

... g++ issues only one error:

t.cpp:9: error: 'A' is an inaccessible base of 'B'

... but it should also complain about the default arg.

Incidentally, this example was boiled down from code in a real project.


-- 
   Summary: No error given for derived-to-private-base conversion in
default arg.
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: widman at gimpel dot com


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

[Bug middle-end/27478] entry and addressable and value-expr: and the gimplifier

[fxcoudert at gcc dot gnu dot org]

--- Comment #10 from fxcoudert at gcc dot gnu dot org  2006-10-03 13:44 
---
Subject: Bug 27478

Author: fxcoudert
Date: Tue Oct  3 13:44:09 2006
New Revision: 117396

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117396
Log:
PR middle-end/27478

* trans-decl.c (gfc_get_fake_result_decl): Mark var as
TREE_ADDRESSABLE.

* gfortran.dg/entry_8.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/entry_8.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/21203] gfortran doesn't work on targets/variants without two floating point types

[fxcoudert at gcc dot gnu dot org]

--- Comment #30 from fxcoudert at gcc dot gnu dot org  2006-10-03 13:10 
---
Changing the summary of this bug to reflect the actual problem. Downgrading to
enhancement because it would be a weird GNU extension.

And unless someone show real interest in gfortran working on these platforms
and provides access to a test system, I don't think we'd implement a graceful
degradation soon.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords|build, ice-on-valid-code|
  Known to fail||4.1.2 4.2.0
   Last reconfirmed|-00-00 00:00:00 |2006-10-03 13:10:10
   date||
Summary|Segfault while compiling|gfortran doesn't work on
   |libgfortran/intrinsics/selec|targets/variants without two
   |ted_int_kind.f90|floating point types


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

[Bug target/29300] FAIL: gcc.dg/pthread-init-[12].c (test for excess errors)

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca  2006-10-03 
13:01 ---
Subject: Re:  FAIL: gcc.dg/pthread-init-[12].c (test for excess errors)

> --- Comment #1 from uros at kss-loka dot si  2006-10-03 07:04 ---
> Similar problems were recently fixed for solaris and glibc-2.3.5. It looks 
> that
> hpux needs a fixinclude hack that would cure these errors/warnings, somehing
> like:

I have a patch.  I've tested it on 11.11 but 11.00 and 11.23 still need
testing.  There are two issues.  pthread_kill and pthread_sigmask need
wrappers as these are being declared with -ansi (they are POSIX.1c).
There are lots of missing braces in the initializers.  I'd hoped to
avoid fixing this warning ;(

Dave


-- 


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

[Bug tree-optimization/25737] ACATS c974001 c974013 hang with struct aliasing

[dnovillo at gcc dot gnu dot org]

--- Comment #39 from dnovillo at gcc dot gnu dot org  2006-10-03 12:54 
---
(In reply to comment #38)

> The name, and all the documentation, which say they cannot be
> addressed, which means they cannot be pointed to by any pointer, which
> means they are unaliased.
> 
Absolutely.  If the Ada FE somehow wants these two predicates to generate
*more* VDEF/VUSE chains, then there is something fundamentally wrong with it. 
The meaning of these two predicates is the exact opposite, they will lead to
*fewer* VDEF/VUSE chains.


> > I'm not saying that this is a sane design or that we should try to replicate
> > it in GCC 4, I'm just saying that for the time being struct aliasing totally
> > overlooks this mechanism and doesn't work for Ada because of that.
> Okay, and i'm saying i don't plan on accepting fixes that appear to
> hack around well accepted infrastructure to try to fix symptoms.
> Really. That's all.  I'm not going to approve patches that randomly
> skip fields because it seems to get the right result sometimes.  If
> you want to try to explain what all this is actually trying to do, i'm
> happy to work with you to come up with a sane solution.
> 
Agreed.  The Ada FE should either change or prove that there is a
design/implementation flaw in the aliasing machinery.


-- 


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

[Bug c++/29331] New: Missing header files only generate warning with -MMD

[gcc-bklyn at sneakemail dot com]

This program:

#include 

Generates only a warning with gcc 4.1.1 and the -MMD flag.  With #include
"idonotexist", an error is generated.  Errors are generated correctly in both
cases with -MD.


-- 
   Summary: Missing header files only generate warning with -MMD
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bklyn at sneakemail dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug middle-end/28684] Imprecise -funsafe-math-optimizations definition

[patchapp at dberlin dot org]

--- Comment #7 from patchapp at dberlin dot org  2006-10-03 12:11 ---
Subject: Bug number PR 28684

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00110.html


-- 


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

[Bug c++/29330] New: -O -ftree-loop-linear --> virtual memory exhausted

[wouter dot vermaelen at pi dot be]

> g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../configure -v --enable-languages=c,c++
--prefix=/home/wouter/gcc/local --enable-shared --with-system-zlib --enable-nls
--enable-threads=posix --without-included-gettext --disable-werror
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug i486-linux-gnu --enable-libmudflap
--enable-checking=release
Thread model: posix
gcc version 4.2.0 20061003 (experimental)


> g++ -O -ftree-loop-linear foo.cpp
virtual memory exhausted: Cannot allocate memory


> cat foo.cpp
int buf[2][2][2][2];

void f()
{
for (int a = 0; a < 2; ++a) {
for (int b = 0; b < 2; ++b) {
for (int c = 0; c < 2; ++c) {
for (int d = 0; d < 2; ++d) {
buf[a][b][c][d] = 0;
}
}
}
}
}


-- 
   Summary:  -O -ftree-loop-linear   -->  virtual memory exhausted
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at pi dot be


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

[Bug fortran/29321] [4.1/4.2 Regression] optional arguments+derived types = segmentation fault

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2006-10-03 11:11 ---
I submitted a fix for this today.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-10-02 17:04:39 |2006-10-03 11:11:39
   date||


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

[Bug fortran/29322] [4.1/4.2 Regression] ICE with character optional arg

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2006-10-03 11:11 ---
I submitted a fix for this today.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-10-02 17:50:29 |2006-10-03 11:11:09
   date||


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

[Bug fortran/27701] Two routines with the same name cause an interna; error in gfortran

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2006-10-03 11:10 ---
I intend to submit the patch in #2, just as soon as the allocatable components
patch is out of the way.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-05-21 16:03:38 |2006-10-03 11:10:18
   date||


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

[Bug fortran/29327] FAIL: gfortran.dg/specifics_1.f90

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2006-10-03 10:32 
---
This should be fixed. I forgot to commit some part of my patch. Sorry for the
inconvenience.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c++/29291] [4.2 regression] ICE on invalid use of new

[reichelt at gcc dot gnu dot org]

--- Comment #3 from reichelt at gcc dot gnu dot org  2006-10-03 10:11 
---
Fixed on mainline.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/29291] [4.2 regression] ICE on invalid use of new

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2006-10-03 10:08 
---
Subject: Bug 29291

Author: reichelt
Date: Tue Oct  3 10:08:22 2006
New Revision: 117393

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117393
Log:
PR c++/29291
* init.c (build_new): Check for invalid init.

* g++.dg/parse/new4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/parse/new4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/29329] [4.1 regression] internal consistency failure at -O2

[debian-gcc at lists dot debian dot org]

--- Comment #1 from debian-gcc at lists dot debian dot org  2006-10-03 
09:46 ---
Created an attachment (id=12376)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12376&action=view)
preprocessed source


-- 


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

[Bug target/29329] New: [4.1 regression] internal consistency failure at -O2

[debian-gcc at lists dot debian dot org]

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

4.1 SVN 20060920, works with 4.2 and 4.0.4

$ gcc -c -fPIC -g -O2 -g tree234.i
tree234.c: In function 'delpos234_internal':
tree234.c:927: fatal error: internal consistency failure
compilation terminated.

compilation works with -O1

compilation with -O0:

$ gcc -c -fPIC -g -O0 -g tree234.i
/tmp/cco6vA7j.s: Assembler messages:
/tmp/cco6vA7j.s:172: Error: Rn must not overlap other operands -- `swpb
r3,r2,[r3]'


  Matthias


-- 
   Summary: [4.1 regression] internal consistency failure at -O2
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: arm-linux-gnu


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

[Bug c++/29328] New: CC attributes not encoded in member function pointer

[tschwinger at neoscientists dot org]

// Tested with 4.1.1 and 4.2.0-alpha20060520

//--
// Simple compile time assertion facility to check the identity of two types
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

template struct same  { enum { n = -1 }; };
template struct same { enum { n = 1 }; };
#define ASSERT_DIFFERENT_TYPE(x,y) ASSERT_DIFFERENT_TYPE_IMPL_I(__LINE__,x,y)
#define ASSERT_DIFFERENT_TYPE_IMPL_I(i,x,y)
ASSERT_DIFFERENT_TYPE_IMPL_II(i,x,y)
#define ASSERT_DIFFERENT_TYPE_IMPL_II(i,x,y) \
bool ASSERTION_FAILED_IN_LINE_ ## i  [ - ::same::n ]


//--
// The problem
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

ASSERT_DIFFERENT_TYPE(void(*)(),void(__attribute((stdcall)) *)()); // OK

class X;
ASSERT_DIFFERENT_TYPE(void(X::*)(),void(__attribute((stdcall)) X::*)()); //
FAIL


-- 
   Summary: CC attributes not encoded in member function pointer
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tschwinger at neoscientists dot org


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

[Bug target/29300] FAIL: gcc.dg/pthread-init-[12].c (test for excess errors)

[uros at kss-loka dot si]

--- Comment #1 from uros at kss-loka dot si  2006-10-03 07:04 ---
Similar problems were recently fixed for solaris and glibc-2.3.5. It looks that
hpux needs a fixinclude hack that would cure these errors/warnings, somehing
like:

http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01317.html
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg9.html

and perhaps

http://gcc.gnu.org/ml/gcc-patches/2006-10/msg9.html

Confirmed, as gcc.dg/pthread-* tests were introduced in order to catch problems
as described in the bug description.


-- 

uros at kss-loka dot si changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-10-03 07:04:17
   date||


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