date:20080120

[Bug fortran/34868] ICE with -ff2c for function returning a complex number

2008-01-20 Thread burnus at gcc dot gnu dot org



--- Comment #5 from burnus at gcc dot gnu dot org  2008-01-21 07:41 ---
> Then the resultant C source is
>VOID f_(doublecomplex * ret_val, doublereal *a)

Indeed this is f2c (and g77 -ff2c) syntax.

> So it seems to me that the current functionality of the gfortran is different
> from that of f2c, isn't it?

The functionality is not really different (except that gfortran supports much
more), but the calling is indeed different. All (most) modern compilers,
including gfortran, generate such a prototype:
  complex double f_ (double *a)

> And, I'm wondering why changing the pseudo-size array "a(:)" to the
> variable "a"

This rings a bell. And indeed the patch for PR 34848 [attachment 14978] fixes
this problem (but it causes some other regressions, see PR 34848).

(Note that "a(:)" and "a(*)" make a huge difference: For "a(*)" the size/upper
bound of the array "a" is unknown and the array is contiguous, while for "a(:)"
the bounds and sizes are known and the array might be not contiguous in memory
(strides); additionally the interface of the procedure "f" needs then to be
known to the caller of "f".)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||34848


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

[Bug ada/34898] Excessive memory consumption during compilation

2008-01-20 Thread oliver dot kellogg at eads dot com



--- Comment #1 from oliver dot kellogg at eads dot com  2008-01-21 07:30 
---
Created an attachment (id=14985)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14985&action=view)
source code for producing the bug

I tried this with gcc-4.1, 4.2, and 4.3.

If I remove the aggregate assignments such as

   Fumessage.O000X := (Pkg000W.E08EY, Aktergsatz);

from pkg001u.adb then compilation proceeds at normal memory consumption.


-- 


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

[Bug ada/34898] New: Excessive memory consumption during compilation

2008-01-20 Thread oliver dot kellogg at eads dot com

For reference, here's a compile with gcc-3.3.5:

$ gcc -c -v pkg001u.adb
Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.5/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada
--disable-checking --libdir=/usr/lib --enable-libgcj --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux
Thread model: posix
gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)
 /usr/lib/gcc-lib/i586-suse-linux/3.3.5/gnat1 -quiet -dumpbase pkg001u.adb
pkg001u.adb -o /tmp/cckqHQka.s

The file compiles successfully and 'top' shows a peak RES requirement of 77 Meg
using no VIRT.
Thus let's limit the VIRT to a half gig,

$ ulimit -v 512000

and compile with a newer gcc:

$ gcc -c -v -gnat95 pkg001u.adb
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../SOURCES/gcc/configure --prefix=/opt/gccsnap
--enable-debug --enable-languages=c,ada,c++
Thread model: posix
gcc version 4.3.0 20080114 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-v' '-gnat95' '-mtune=generic'
 /opt/gccsnap/libexec/gcc/i686-pc-linux-gnu/4.3.0/gnat1 -quiet -dumpbase
pkg001u.adb -gnat95 -mtune=generic pkg001u.adb -o /tmp/ccmBlEVU.s
+===GNAT BUG DETECTED==+
| 4.3.0 20080114 (experimental) (i686-pc-linux-gnu) Storage_Error heap
exhausted|
| Error detected at pkg001u.adb:296:35 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.

pkg001u.adb
pkg001u.ads
p_portable.ads
corba.ads
pkg001z.ads
pkg0013.ads
pkg000x.ads
pkg001o.ads
pkg000q.ads
pkg000v.ads
pkg000y.ads
pkg001l.ads
pkg0025.ads
pkg001e.ads
pkg000w.ads
pkg001r.ads
pkg000u.ads
pkg002n.ads
pkg002f.ads
pkg0020.ads
pkg0019.ads
pkg001w.ads
pkg000t.ads
pkg001v.ads
pkg001m.ads
pkg000a.ads
pkg000d.ads
pkg000c.ads
pkg0007.ads
pkg0009.ads
pkg000k.ads
pkg0001.ads
pkg000g.ads
pkg000b.ads
pkg000l.ads
pkg000f.ads
pkg002g.ads
pkg0006.ads
pkg001k.ads
pkg.ads
pkg0005.ads
pkg002o.ads
pkg0028.ads
pkg0029.ads
pkg000h.ads
pkg002p.ads
pkg000j.ads
pkg000i.ads
pkg0027.ads
pkg0002.ads
pkg0022.ads
pkg0023.ads
pkg0012.ads
pkg0026.ads
pkg000r.ads
pkg000s.ads
c_types.ads
pkg000m.ads
pkg001a.ads
pkg0003.ads
pkg001n.ads
pkg0021.ads
pkg001t.ads
pkg001p.ads
pkg001c.ads
pkg0004.ads
pkg0016.ads
pkg001s.ads
pkg001x.ads
pkg001z-o_protokoll.ads
pkg0018.ads
pkg000z.ads
pkg001j.ads
pkg0011.ads
pkg001d.ads
pkg002m.ads
pkg002e.ads
pkg002d.ads
pkg000o.ads
pkg001b.ads
pkg000p.ads
pkg001f.ads
pkg0015.ads
pkg000n.ads
pkg0014.ads
pkg0017.ads
pkg0024.ads

compilation abandoned

(Tried limiting the VIRT to 1.5 gig, same result.)


-- 
   Summary: Excessive memory consumption during compilation
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oliver dot kellogg at eads dot com
  GCC host triplet: i686-pc-linux-gnu


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

[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one

2008-01-20 Thread manu at gcc dot gnu dot org



--- Comment #24 from manu at gcc dot gnu dot org  2008-01-21 06:55 ---
(In reply to comment #23)
> It's too bad the bug is closed just as a duplicate of another bug.

I am sorry that you feel disappointed. I believed that the rationale behind
closing this was fairly clear. I tried to answer your concerns without getting
into a debate.

Point 1), 2) and 3) are about the meaning of undefined behaviour and this have
been lengthy discussed in the mailing list. 

Probably the latest discussion here:
http://gcc.gnu.org/ml/gcc/2007-01/msg00881.html

More to be found in the archives:
http://gcc.gnu.org/ml/gcc/

About points 4) and 5), gcc-3.4.6 and gcc-4.1.2 are only consistent in the
examples you have tried but, as discussed in comment 14, optimization changes
code and different code has different behaviour. We strive to give consistent
results for defined behavior. And we strive to give the best optimized code
without breaking the standards. Again, this has been discussed thoroughly in
the mailing list in the context of signed overflow and also strict aliasing
(Wstrict-aliasing).

It is unlikely that whatever point you made hasn't been covered in a discussion
already, this is why gcc developers generally avoid any discussion about
undefined behaviour. This is nothing new.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2008-01-19 00:22:14 |2008-01-21 06:55:57
   date||


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

[Bug fortran/34897] New: Invalid array bound in specification block causes ICE

2008-01-20 Thread pault at gcc dot gnu dot org

>From the old version of gfortran.dg/mapping_2.f90

  function my_string(x)
 integer i
 real, intent(in) :: x(:)
 character(0) h4(1:minval([(1,i=1,0)],1)) ! If range is 1,0 bombs out.
 character(0) sv1(size(x,1):size(h4))
 character(0) sv2(2*lbound(sv1,1):size(h4))
 character(lbound(sv2,1)-3) my_string
  end function my_string


causes

mapping_2.f90: In function my_string:
mapping_2.f90:1: warning: Function does not return a value
mapping_2.f90:4: internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:842
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: Invalid array bound in specification block causes ICE
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pault at gcc dot gnu dot org


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

[Bug fortran/34896] [4.3 Regression] libgomp.fortran/reduction5.f90

2008-01-20 Thread pault at gcc dot gnu dot org



--- Comment #2 from pault at gcc dot gnu dot org  2008-01-21 05:40 ---
Confirmed

This is the reduced version

! { dg-do run }

module reduction5
  intrinsic min, max
end module reduction5

program reduction_5_regression
  call test2
contains
  subroutine test2
use reduction5, min => max, max => min
integer a, b
a = max (1,5)
b = min (1,5)
if (a .ne. 1) call abort ()
if (b .ne. 5) call abort ()
  end subroutine test2
end

! { dg-final { cleanup-modules "reduction5" } }

I'll fix it by tonight.  Thanks HJ - libgomp is an area that I do not test and
should.

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|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-01-21 05:40:36
   date||


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

[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one

2008-01-20 Thread sergstesh at yahoo dot com



--- Comment #23 from sergstesh at yahoo dot com  2008-01-21 05:07 ---
It's too bad the bug is closed just as a duplicate of another bug.

The main points of this bug are:

1) the code triggering the bug uses undefined in "C" standards language
features - behavior in case of integer overflow + signed <-> unsigned
comparison;

2) "C" standard is not the only standard having some cases undefined - whenever
compiler developers face an undefined case they should somehow define the case
themselves and publish their definition/decision;

3) it's very desirable for the compiler developers to be consistent, i.e.
whenever the undefined by standard case is encountered, the compiler behaves
the same way, i.e. produces code implementing the same algorithm;

4) I do see consistency in gcc-3.4.6, gcc-4.1.2 - regardless of -O1 vs -O2
generated by gcc code functionally behaves the same way;

5) gcc-4.2.x shows lack of consistency - -O1 code behaves differently compared
to -O2 one. It's a pity that newer gcc versions are less consistent than the 
old ones. As I suggested earlier, the cleanest solution would be _not_ to
perform optimization on unclean code, thus ensuring consistency.


-- 


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

[Bug fortran/34896] [4.3 Regression] libgomp.fortran/reduction5.f90

2008-01-20 Thread hjl dot tools at gmail dot com



--- Comment #1 from hjl dot tools at gmail dot com  2008-01-21 04:26 ---
Revision 131678 seems OK:

http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00926.html

It looks like revision 131679

http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00925.html

is the cause.


-- 


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

[Bug fortran/34896] New: [4.3 Regression] libgomp.fortran/reduction5.f90

2008-01-20 Thread hjl dot tools at gmail dot com

On Linux/Intel64 and Linux/ia32, revision 131679 gives

FAIL: libgomp.fortran/reduction5.f90  -O0  execution test
FAIL: libgomp.fortran/reduction5.f90  -O1  execution test
FAIL: libgomp.fortran/reduction5.f90  -O2  execution test
FAIL: libgomp.fortran/reduction5.f90  -O3 -fomit-frame-pointer  execution test
FAIL: libgomp.fortran/reduction5.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: libgomp.fortran/reduction5.f90  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: libgomp.fortran/reduction5.f90  -O3 -g  execution test
FAIL: libgomp.fortran/reduction5.f90  -Os  execution test

Revision 131671 is OK.


-- 
   Summary: [4.3 Regression] libgomp.fortran/reduction5.f90
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c++/34895] ICE at dwarf2out.c:13742

2008-01-20 Thread theodore dot papadopoulo at sophia dot inria dot fr



--- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr  
2008-01-21 03:15 ---
Created an attachment (id=14984)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14984&action=view)
The code that triggers the ICE

Just compile with -g -O2 to see the problem.


-- 


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

[Bug c++/34895] New: ICE at dwarf2out.c:13742

2008-01-20 Thread theodore dot papadopoulo at sophia dot inria dot fr

The (soon to be attached) code ICEs when compiled with options -g -O2.
This is still true as of gcc version 4.3.0 20080118 (x86_64-unknown-linux-gnu),
it used to pass but I do not know if this was due to the use of a previous
version of the compiler (3.4) or the use of a i386 target (this is most
probable, I will check).


-- 
   Summary: ICE at dwarf2out.c:13742
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: theodore dot papadopoulo at sophia dot inria dot fr
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


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

[Bug middle-end/34852] [4.3 Regression] Revision 131576 miscompiled 178.galgel

2008-01-20 Thread hjl dot tools at gmail dot com



--- Comment #8 from hjl dot tools at gmail dot com  2008-01-21 03:09 ---
Add -ffloat-store seems to fix the problem. I will verify it.


-- 


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

[Bug fortran/34868] ICE with -ff2c for function returning a complex number

2008-01-20 Thread yamagen at coral dot t dot u-tokyo dot ac dot jp



--- Comment #4 from yamagen at coral dot t dot u-tokyo dot ac dot jp  
2008-01-21 02:57 ---
Thank you very much for your comments.

First I answer to you why I would like to use -ff2c option.
The reason is that I would like to use "-framework vecLib".
In the URL
   
http://developer.apple.com/hardwaredrivers/ve/errata.html#fortran_conventions ,
Apple said
"The FORTRAN entry points in Mac OS X's vecLib adhere to the call/return
conventions of g77."
When I tried compile & linking vecLib without "-ff2c" option,
the double complex function "zdotu" does not work correctly.
Then I tried "-ff2c" option and found this issue.

Honestly saying, I don't know well about the calling convention ( nor "C"
langueage ),
but, I have tried "f2c test2.f"

test2.f
  function f(a)
  implicit none
  complex*16 f
  real*8 a(*)
  f=(0d0,0d0)
  end
--

Then the resultant C source is
/* Double Complex */ VOID f_(doublecomplex * ret_val, doublereal *a)
{
/* Parameter adjustments */
--a;

/* Function Body */
 ret_val->r = 0.,  ret_val->i = 0.;
} /* f_ */

So it seems to me that the current functionality of the gfortran is different
from that of f2c, isn't it?

And, I'm wondering why changing the pseudo-size array "a(:)" to the variable
"a"
makes "test.f" to be compiled with "-ff2c" option without internal error.

# Anyway, I just want to use vecLib without degrading the portability of my
fortran fource code.
# (I know a work-around, calling zdotu as subroutine with one extra argument
receiving the result.
# But this work-around degrades the portability. )
# Does anyone know the tips for this issue?


-- 


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

[Bug c++/34891] [4.1/4.2 regression] Broken diagnostic: 'view_convert_expr' not supported by dump_expr

2008-01-20 Thread pcarlini at suse dot de



--- Comment #2 from pcarlini at suse dot de  2008-01-21 02:31 ---
Fixed for 4.3.0.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW
Summary|[4.1/4.2/4.3 regression]|[4.1/4.2 regression] Broken
   |Broken diagnostic:  |diagnostic:
   |'view_convert_expr' not |'view_convert_expr' not
   |supported by dump_expr  |supported by dump_expr


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

[Bug c++/34891] [4.1/4.2/4.3 regression] Broken diagnostic: 'view_convert_expr' not supported by dump_expr

2008-01-20 Thread paolo at gcc dot gnu dot org



--- Comment #1 from paolo at gcc dot gnu dot org  2008-01-21 02:31 ---
Subject: Bug 34891

Author: paolo
Date: Mon Jan 21 02:30:31 2008
New Revision: 131687

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131687
Log:
/cp
2008-01-20  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/34891
* error.c (dump_expr): Deal with VIEW_CONVERT_EXPR.

/testsuite
2008-01-20  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/34891
* g++.dg/ext/vector9.C: New.

Added:
trunk/gcc/testsuite/g++.dg/ext/vector9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/error.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug testsuite/34894] Some compile tests require trampolines even when the target sets no_trampolines

2008-01-20 Thread pmarques at grupopie dot com



--- Comment #1 from pmarques at grupopie dot com  2008-01-21 02:23 ---
Created an attachment (id=14983)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14983&action=view)
patch with possible fix


This patch fixes the test cases, by #ifndef'ing the relevant code when
NO_TRAMPOLINES is defined


-- 


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

[Bug testsuite/34894] New: Some compile tests require trampolines even when the target sets no_trampolines

2008-01-20 Thread pmarques at grupopie dot com

When trying to run the testsuite for the avr target I get these failures from
gcc.c-torture/compile:

gcc.c-torture/compile/20010226-1.c:6: internal compiler error: trampolines not
supported
gcc.c-torture/compile/20050122-2.c:7: internal compiler error: trampolines not
supported
gcc.c-torture/compile/nested-1.c:9: internal compiler error: trampolines not
supported
gcc.c-torture/compile/pr27889.c:3: internal compiler error: trampolines not
supported

All except 20050122-2.c seem to be clear cases where trampolines are needed.
20050122-2.c might be able to work without requiring trampolines, but the
address of a nested function is taken, nonetheless, so I guess we can not
consider it a bug for gcc to use trampolines to compile it.


-- 
   Summary: Some compile tests require trampolines even when the
target sets no_trampolines
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pmarques at grupopie dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: avr-*-*


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

[Bug c++/34891] [4.1/4.2/4.3 regression] Broken diagnostic: 'view_convert_expr' not supported by dump_expr

2008-01-20 Thread pcarlini at suse dot de



-- 

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-01-21 02:06:44
   date||


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

[Bug c++/34050] [4.3 regression] ICE derived classes and variadic templates

2008-01-20 Thread mmitchel at gcc dot gnu dot org



--- Comment #7 from mmitchel at gcc dot gnu dot org  2008-01-21 02:03 
---
I agree that this should be a P2.  I had misunderstood Andrew's earlier comment
to mean that we always got a valid error message before the ICE.


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P4  |P2


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

[Bug c++/27177] [4.1/4.2/4.3 Regression] ICE in build_simple_base_path, at cp/class.c:474

2008-01-20 Thread mmitchel at gcc dot gnu dot org



--- Comment #19 from mmitchel at gcc dot gnu dot org  2008-01-21 02:00 
---
Lawrence, thanks for looking into this.  

Was there any consensus on whether or not these are static_casts in this
context?

I'm guessing that the eventual resolution is going to be something like saying
that a cast is a static_cast even if the class is incomplete, so long as the
bases are known, but that such a static_cast can only be used in an
un-evaluated context.  Is that correct?


-- 


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

[Bug c++/34776] [4.1/4.2 regression] ICE with invalid member declaration in template class

2008-01-20 Thread pcarlini at suse dot de



--- Comment #4 from pcarlini at suse dot de  2008-01-21 01:52 ---
Fixed for 4.3.0.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW
Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE
   |with invalid member |with invalid member
   |declaration in template |declaration in template
   |class   |class


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

[Bug c++/34486] [4.1/4.2 regression] ICE invalid using declaration

2008-01-20 Thread pcarlini at suse dot de



--- Comment #5 from pcarlini at suse dot de  2008-01-21 01:52 ---
Fixed for 4.3.0.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW
Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE
   |invalid using declaration   |invalid using declaration


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

[Bug c++/34486] [4.1/4.2/4.3 regression] ICE invalid using declaration

2008-01-20 Thread paolo at gcc dot gnu dot org



--- Comment #4 from paolo at gcc dot gnu dot org  2008-01-21 01:50 ---
Subject: Bug 34486

Author: paolo
Date: Mon Jan 21 01:49:29 2008
New Revision: 131686

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131686
Log:
/cp
2008-01-20  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/34776
PR c++/34486
* name-lookup.c (do_class_using_decl): Do not call constructor_name_p
on non-IS_AGGR_TYPE type scope.
(constructor_name_p): Assert IS_AGGR_TYPE.

/testsuite
2008-01-20  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/34776
PR c++/34486
* g++.dg/template/crash75.C: New.
* g++.dg/template/crash76.C: Likewise.  

Added:
trunk/gcc/testsuite/g++.dg/template/crash75.C
trunk/gcc/testsuite/g++.dg/template/crash76.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/34776] [4.1/4.2/4.3 regression] ICE with invalid member declaration in template class

2008-01-20 Thread paolo at gcc dot gnu dot org



--- Comment #3 from paolo at gcc dot gnu dot org  2008-01-21 01:50 ---
Subject: Bug 34776

Author: paolo
Date: Mon Jan 21 01:49:29 2008
New Revision: 131686

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131686
Log:
/cp
2008-01-20  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/34776
PR c++/34486
* name-lookup.c (do_class_using_decl): Do not call constructor_name_p
on non-IS_AGGR_TYPE type scope.
(constructor_name_p): Assert IS_AGGR_TYPE.

/testsuite
2008-01-20  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/34776
PR c++/34486
* g++.dg/template/crash75.C: New.
* g++.dg/template/crash76.C: Likewise.  

Added:
trunk/gcc/testsuite/g++.dg/template/crash75.C
trunk/gcc/testsuite/g++.dg/template/crash76.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one

2008-01-20 Thread manu at gcc dot gnu dot org



--- Comment #22 from manu at gcc dot gnu dot org  2008-01-21 01:10 ---
"make check" failing is expected since there is undefined behaviour in the
program and we warn about it with -Wstrict-overflow=5 (I guess that we warn
with lower values as well, probably simply with -Wstrict-overflow). So this is
a duplicate of PR 32102.

About the signed/unsigned warnings, it seems a minor issue. But if you still
want us to investigate it, please open a new PR (this one got a bit messy). If
you include just the relevant floating_point_test.c file and the headers to
make it compile (or better, use -save-temps and attach floating_point_test.i),
then we can easily reproduce the bug at will and investigate it. Thanks.

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


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/32102] -Wall stomps on -Wstrict-overflow

2008-01-20 Thread manu at gcc dot gnu dot org



--- Comment #9 from manu at gcc dot gnu dot org  2008-01-21 01:10 ---
*** Bug 34841 has been marked as a duplicate of this bug. ***


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||sergstesh at yahoo dot com


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

[Bug middle-end/34150] ICE: output_operand: invalid expression as operand on hppa

2008-01-20 Thread dave at hiauly1 dot hia dot nrc dot ca



--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca  2008-01-21 
00:27 ---
Subject: Re:  ICE: output_operand: invalid expression
as operand on hppa

> (gdb) p debug_rtx (insn)
> (code_label/s 1897 4221 1898 13722 ("*.LJpc=819954") [0 uses])

We are losing usage counts in reload.  I'm testing the attached
fix.

Dave


--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca  2008-01-21 
00:27 ---
Created an attachment (id=14982)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14982&action=view)


-- 


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

[Bug rtl-optimization/34808] [4.3 Regression] ICE in prescan_insns_for_dce

2008-01-20 Thread kkojima at gcc dot gnu dot org



--- Comment #10 from kkojima at gcc dot gnu dot org  2008-01-21 00:12 
---
Fixed.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/34808] [4.3 Regression] ICE in prescan_insns_for_dce

2008-01-20 Thread kkojima at gcc dot gnu dot org

--- Comment #9 from kkojima at gcc dot gnu dot org  2008-01-21 00:05 ---
Subject: Bug 34808

Author: kkojima
Date: Mon Jan 21 00:04:23 2008
New Revision: 131680

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131680
Log:
PR rtl-optimization/34808
* emit-rtl.c (try_split): Handle REG_RETVAL notes.
* gcc.c-torture/compile/pr34808.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr34808.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/emit-rtl.c
trunk/gcc/testsuite/ChangeLog

-- 

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

[Bug target/33034] FAIL: gcc.c-torture/unsorted/DFcmp.c & SFset.c: internal compiler error: in extract_insn, at recog.c:2077

2008-01-20 Thread debian-gcc at lists dot debian dot org



--- Comment #4 from debian-gcc at lists dot debian dot org  2008-01-20 
23:57 ---
seen as well with a sparc-linux-gnu compiler with -m64 (patched for a biarch
build ) with trunk 20080116

  Matthias


-- 


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

[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90

2008-01-20 Thread zadeck at naturalbridge dot com



--- Comment #17 from zadeck at naturalbridge dot com  2008-01-20 23:27 
---
Subject: Re:  [4.3 Regression] gfortran.dg/array_constructor_9.f90

steven at gcc dot gnu dot org wrote:
> --- Comment #16 from steven at gcc dot gnu dot org  2008-01-20 23:22 
> ---
> I favor blowing away the RD patch.
>
> Having the LR problem (and probably the LIVE problem too?) always propagate 
> the
> REG_EQ* notes as if they were real uses sounds like a terrible idea to me. 
> They are not real uses and should not be treated as such.
>
>
>   
Unless the powers that be need this fixed asap, i want to wait til i get
a consensus from the other df maintainers.   but i do see blowing it
away as a reasonable answer.  it is a shame, it actually does provide a
good speedup.

Kenny


-- 


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

[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90

2008-01-20 Thread steven at gcc dot gnu dot org



--- Comment #16 from steven at gcc dot gnu dot org  2008-01-20 23:22 ---
I favor blowing away the RD patch.

Having the LR problem (and probably the LIVE problem too?) always propagate the
REG_EQ* notes as if they were real uses sounds like a terrible idea to me. 
They are not real uses and should not be treated as such.


-- 


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

[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90

2008-01-20 Thread zadeck at naturalbridge dot com



--- Comment #15 from zadeck at naturalbridge dot com  2008-01-20 23:15 
---
There appears to be an design inconsistency in the way that we have specified
the various dataflow problems with respect to the eq notes.  

I hate eq notes.

In the rd patch that just went in where we trim the solution based on the lr
info, it seems to also trim the bits associated with the eq notes because these
are not carried around in the lr problem.  

This screws ups the use-def chains that are used in fwprop, see and web (in
this particular case, the problem is in web, but that is only a matter of bad
luck).

I can either blow away the rd patch for 34400, or we can teach lr to respect
the  DF_EQ_NOTES patch or just have lr always propagate the eq notes as if they
were real uses.  

The latter actually sounds like the only correct solution but at this late
point of stage 3, we may need to sacrifice correctness for stability.

Kenny


-- 


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

[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one

2008-01-20 Thread sergstesh at yahoo dot com



--- Comment #21 from sergstesh at yahoo dot com  2008-01-20 22:30 ---
Now that the flags are in this order: -Wall -Wstrict-overflow=5 :

a) the warnings during compilation:

"
[EMAIL 
PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17>
grep warn make.log
lpc.c:220: warning: assuming signed overflow does not occur when simplifying
conditional to constant
g72x.c:249: warning: assuming signed overflow does not occur when simplifying
conditional to constant
sndfile.c:491: warning: the address of 'sf_error' will never be NULL
aiff.c:557: warning: assuming signed overflow does not occur when changing X +-
C1 cmp C2 to X cmp C1 +- C2
sd2.c:540: warning: assuming signed overflow does not occur when changing X +-
C1 cmp C2 to X cmp C1 +- C2
sd2.c:558: warning: assuming signed overflow does not occur when changing X +-
C1 cmp C2 to X cmp C1 +- C2
sndfile-play.c:292: warning: the address of ‘status’ will always
evaluate as ‘true’
lossy_comp_test.c:1342: warning: assuming signed overflow does not occur when
simplifying abs (X) to X or -X
lossy_comp_test.c:1527: warning: assuming signed overflow does not occur when
simplifying abs (X) to X or -X
lossy_comp_test.c:761: warning: assuming signed overflow does not occur when
simplifying abs (X) to X or -X
lossy_comp_test.c:573: warning: assuming signed overflow does not occur when
simplifying abs (X) to X or -X
peak_chunk_test.c:127: warning: assuming signed overflow does not occur when
simplifying division
peak_chunk_test.c:194: warning: assuming signed overflow does not occur when
simplifying division
fix_this.c:155: warning: assuming signed overflow does not occur when
simplifying abs (X) to X or -X
[EMAIL 
PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17>
";

b) 'make check' still fails with the same

"
Line 765: Signal is all zeros (-27260928, 0xFE600800).
"

message.


-- 


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

[Bug c++/34893] Strangeness of name lookup in template function

2008-01-20 Thread pinskia at gcc dot gnu dot org



--- Comment #1 from pinskia at gcc dot gnu dot org  2008-01-20 22:30 ---


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


-- 

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

[Bug c++/34886] Strangeness of name lookup in template function

2008-01-20 Thread pinskia at gcc dot gnu dot org



--- Comment #2 from pinskia at gcc dot gnu dot org  2008-01-20 22:30 ---
*** Bug 34893 has been marked as a duplicate of this bug. ***


-- 


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

[Bug preprocessor/34695] Preprocessor warning->error conversion from -Werror is silent

2008-01-20 Thread ed at catmur dot co dot uk



--- Comment #5 from ed at catmur dot co dot uk  2008-01-20 22:28 ---
Created an attachment (id=14981)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14981&action=view)
gcc-cpp-Werror-message.patch


-- 

ed at catmur dot co dot uk changed:

   What|Removed |Added

  Attachment #14980|0   |1
is obsolete||


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

[Bug preprocessor/34695] Preprocessor warning->error conversion from -Werror is silent

2008-01-20 Thread ed at catmur dot co dot uk



--- Comment #4 from ed at catmur dot co dot uk  2008-01-20 22:20 ---
Created an attachment (id=14980)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14980&action=view)
gcc-cpp-Werror-message.patch

Also when preprocessing-only.


-- 

ed at catmur dot co dot uk changed:

   What|Removed |Added

  Attachment #14977|0   |1
is obsolete||


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

[Bug libfortran/34887] reverse tabbing before slash descriptor (regression vs. g77)

2008-01-20 Thread tkoenig at gcc dot gnu dot org



--- Comment #4 from tkoenig at gcc dot gnu dot org  2008-01-20 22:19 ---

> - next_record (dtp, 0);
> + next_record (dtp, 1);

This causes a regression in x_slash_1.f .  I'll dig around
some more.


-- 


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

[Bug c++/34893] New: Strangeness of name lookup in template function

2008-01-20 Thread rvovsd at mail dot ru

On compiling that code:

--- begin code ---
class Y {};

void f(Y*) { } // line 3. If comment - all ok

template < typename T>
void sel(T* a) { f(a); } //line 6

void f(void*) {}

int main(int argc, char **argv)
{
sel((void*)0); //line 12
}
--- end code ---

Àppears error:
../main.cpp: In function void sel(T*) [with T = void]:
../main.cpp:12:   instantiated from here
../main.cpp:6: error: invalid conversion from void* to Y*
../main.cpp:6: error:   initializing argument 1 of void f(Y*)

If comment line 3, then work.
Also work, if line 3 move after line 6.

If functions f(Y*), f(void*) and sel(T*) placed in different header files, then
arise dependency on order including headers.


-- 
   Summary: Strangeness of name lookup in template function
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rvovsd at mail dot ru
  GCC host triplet: openSuse 10.3


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

[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90

2008-01-20 Thread pinskia at gcc dot gnu dot org



-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|fortran |middle-end
   Target Milestone|--- |4.3.0


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

[Bug c++/34886] Strangeness of name lookup in template function

2008-01-20 Thread pinskia at gcc dot gnu dot org



--- Comment #1 from pinskia at gcc dot gnu dot org  2008-01-20 21:55 ---
GCC is correct here.  Well partly.  It should reject it no matter what.


-- 


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

[Bug libfortran/34887] reverse tabbing before slash descriptor (regression vs. g77)

2008-01-20 Thread tkoenig at gcc dot gnu dot org



--- Comment #3 from tkoenig at gcc dot gnu dot org  2008-01-20 21:40 ---
(currently regtesting)


-- 


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

[Bug c++/34892] [4.3 regression] ICE with ellipsis in default template argument

2008-01-20 Thread reichelt at gcc dot gnu dot org



-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.0


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

[Bug c++/34892] New: [4.3 regression] ICE with ellipsis in default template argument

2008-01-20 Thread reichelt at gcc dot gnu dot org

The following invalid testcase triggers an ICE on mainline:

==
template struct A {};

A<0> a;
==

bug.cc:1: error: expected primary-expression before '...' token
bug.cc:3: internal compiler error: tree check: accessed elt 3 of tree_vec with
2 elts in coerce_template_parms, at cp/pt.c:5312
Please submit a full bug report, [etc.]


-- 
   Summary: [4.3 regression] ICE with ellipsis in default template
argument
   Product: gcc
   Version: 4.3.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=34892

[Bug libfortran/34887] reverse tabbing before slash descriptor (regression vs. g77)

2008-01-20 Thread tkoenig at gcc dot gnu dot org



--- Comment #2 from tkoenig at gcc dot gnu dot org  2008-01-20 21:39 ---
What about this one-character patch?

Index: transfer.c
===
--- transfer.c  (revision 131679)
+++ transfer.c  (working copy)
@@ -1308,7 +1308,7 @@ formatted_transfer_scalar (st_parameter_
case FMT_SLASH:
  consume_data_flag = 0 ;
  dtp->u.p.skips = dtp->u.p.pending_spaces = 0;
- next_record (dtp, 0);
+ next_record (dtp, 1);
  break;

case FMT_COLON:


-- 


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

[Bug c++/34891] [4.1/4.2/4.3 regression] Broken diagnostic: 'view_convert_expr' not supported by dump_expr

2008-01-20 Thread 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=34891

[Bug c++/34891] New: [4.1/4.2/4.3 regression] Broken diagnostic: 'view_convert_expr' not supported by dump_expr

2008-01-20 Thread reichelt at gcc dot gnu dot org

A broken diagnostic ('view_convert_expr' not supported by dump_expr)
is issued for the following testcase since GCC 4.0.2:

==
typedef float v4f __attribute__((vector_size(8)));
typedef int   v4i __attribute__((vector_size(8)));

void foo()
{
  v4f v;
  !(v4i)v;
}
==

bug.cc: In function 'void foo()':
bug.cc:7: error: could not convert '#'view_convert_expr' not supported by
dump_expr#' to 'bool'
bug.cc:7: error: in argument to unary !


-- 
   Summary: [4.1/4.2/4.3 regression] Broken diagnostic:
'view_convert_expr' not supported by dump_expr
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: diagnostic, 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=34891

[Bug c/34890] Error compiling global.c in 01/18/08 snapshot under Debian Linux 4.0 for mips

2008-01-20 Thread tbm at gcc dot gnu dot org



--- Comment #2 from tbm at gcc dot gnu dot org  2008-01-20 21:21 ---
Fixed in SVN by Richard.


-- 

tbm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/34890] Error compiling global.c in 01/18/08 snapshot under Debian Linux 4.0 for mips

2008-01-20 Thread tbm at cyrius dot com



--- Comment #1 from tbm at cyrius dot com  2008-01-20 21:20 ---
This was fixed in SVN today, see
http://gcc.gnu.org/ml/gcc/2008-01/msg00308.html


-- 

tbm at cyrius dot com changed:

   What|Removed |Added

 CC||tbm at cyrius dot com


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

[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605

2008-01-20 Thread dominiq at lps dot ens dot fr



--- Comment #38 from dominiq at lps dot ens dot fr  2008-01-20 20:47 ---
With patch form comments #11 and #31, the executable for
gcc.dg/struct/wo_prof_mult_field_peeling.c segfault with -m64. I have used the
32 bit mode for -fprofile-generate, run the executable, and use -m64 for
-fprofile-use. wo_prof_mult_field_peeling_db.c is the code from comment #34.
The assembly follows with the options I have used:

[ibook-dhum] bug/tmp_dir% /opt/gcc/gcc4.3w/bin/gcc -S -m64 -O3 -fdump-ipa-all
-fwhole-program -combine -fipa-type-escape wo_prof_mult_field_peeling_db.c
[ibook-dhum] bug/tmp_dir% cat wo_prof_mult_field_peeling_db.s
.text
.align 4,0x90
.globl _main
_main:
LFB6:
pushq   %rbp
LCFI0:
movl$400, %edi
movq%rsp, %rbp
LCFI1:
pushq   %rbx
LCFI2:
subq$8, %rsp
LCFI3:
call_malloc
movl$400, %edi
movq%rax, %rbx
call_malloc
movl$400, %edi
call_malloc
movl$400, %edi
call_malloc
xorl%eax, %eax
.align 4,0x90
L2:
movl$5, (%rbx,%rax,4)
addq$1, %rax
cmpq$100, %rax
jne L2
xorb%al, %al
jmp L4
.align 4,0x90
L3:
addq$1, %rax
cmpq$100, %rax
je  L9
L4:
cmpl$5, (%rbx,%rax,4)
je  L3
call_abort
L9:
addq$8, %rsp
xorb%al, %al
popq%rbx
leave
ret
LFE6:
.section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame1:
.set L$set$0,LECIE1-LSCIE1
.long L$set$0
LSCIE1:
.long   0x0
.byte   0x1
.ascii "zR\0"
.byte   0x1
.byte   0x78
.byte   0x10
.byte   0x1
.byte   0x10
.byte   0xc
.byte   0x7
.byte   0x8
.byte   0x90
.byte   0x1
.align 3
LECIE1:
.globl _main.eh
_main.eh:
LSFDE1:
.set L$set$1,LEFDE1-LASFDE1
.long L$set$1
LASFDE1:
.long   LASFDE1-EH_frame1
.quad   LFB6-.
.set L$set$2,LFE6-LFB6
.quad L$set$2
.byte   0x0
.byte   0x4
.set L$set$3,LCFI0-LFB6
.long L$set$3
.byte   0xe
.byte   0x10
.byte   0x86
.byte   0x2
.byte   0x4
.set L$set$4,LCFI1-LCFI0
.long L$set$4
.byte   0xd
.byte   0x6
.byte   0x4
.set L$set$5,LCFI3-LCFI1
.long L$set$5
.byte   0x83
.byte   0x3
.align 3
LEFDE1:
.subsections_via_symbols

[ibook-dhum] bug/tmp_dir% /opt/gcc/gcc4.3w/bin/gcc -S -m64
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/struct/wo_prof_mult_field_peeling.c
-O3 -fwhole-program -combine -fipa-type-escape -fprofile-use -fipa-struct-reorg
-fdump-ipa-all
[ibook-dhum] bug/tmp_dir% cat wo_prof_mult_field_peeling.s
.section __TEXT,__text,regular,pure_instructions
.align 4
.globl _main
_main:
LFB5:
pushq   %rbp
LCFI0:
movl$1600, %edi
movq%rsp, %rbp
LCFI1:
call_malloc
movl$400, %edi
call_malloc
movl$400, %edi
call_malloc
movl$400, %edi
call_malloc
movl$400, %edi
call_malloc
xorl%edx, %edx
cltq
.align 4
L2:
movl$5, (%rax,%rdx,4)
movl$5, 4(%rax,%rdx,4)
movl$5, 8(%rax,%rdx,4)
movl$5, 12(%rax,%rdx,4)
movl$5, 16(%rax,%rdx,4)
movl$5, 20(%rax,%rdx,4)
movl$5, 24(%rax,%rdx,4)
movl$5, 28(%rax,%rdx,4)
movl$5, 32(%rax,%rdx,4)
movl$5, 36(%rax,%rdx,4)
addq$10, %rdx
cmpq$100, %rdx
jne L2
xorb%dl, %dl
.align 4
L4:
cmpl$5, (%rax,%rdx,4)
jne L35
leaq1(%rdx), %rcx
cmpl$5, (%rax,%rcx,4)
jne L35
cmpl$5, 8(%rax,%rdx,4)
jne L35
cmpl$5, 12(%rax,%rdx,4)
jne L35
cmpl$5, 16(%rax,%rdx,4)
jne L35
cmpl$5, 20(%rax,%rdx,4)
jne L35
cmpl$5, 24(%rax,%rdx,4)
jne L35
cmpl$5, 28(%rax,%rdx,4)
jne L35
cmpl$5, 32(%rax,%rdx,4)
jne L35
cmpl$5, 36(%rax,%rdx,4)
jne L35
leaq9(%rcx), %rdx
cmpq$100, %rdx
jne L4
xorl%eax, %eax
leave
ret
L35:
call_abort
LFE5:
.section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame1:
.set L$set$0,LECIE1-LSCIE1
.long L$set$0
LSCIE1:
.long   0x0
.byte   0x1
.ascii "zR\0"
.byte   0x1
.byte   0x78
.byte   0x10
.byte   0x1
.byte   0x10
.byte   0xc

[Bug c/34890] New: Error compiling global.c in 01/18/08 snapshot under Debian Linux 4.0 for mips

2008-01-20 Thread michael dot a dot richmond at nasa dot gov

When I attempt to compile the 01/18/08 snapshot under Debian Linux 4.0 for mips
I get the following message:

/home/mrichmon/gcc-4.3-20080118/g95/./prev-gcc/xgcc
-B/home/mrichmon/gcc-4.3-20080118/g95/./prev-gcc/
-B/home/mrichmon/irun/mips-unknown-linux-gnu/bin/ -c   -g -O2 -DIN_GCC   -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros
-Wno-overlength-strings -Werror-DHAVE_CONFIG_H -I. -I.
-I/home/mrichmon/gcc-4.3-20080118/gcc -I/home/mrichmon/gcc-4.3-20080118/gcc/.
-I/home/mrichmon/gcc-4.3-20080118/gcc/../include
-I/home/mrichmon/gcc-4.3-20080118/gcc/../libcpp/include
-I/home/mrichmon/mpfr-2.3.0
-I/home/mrichmon/gcc-4.3-20080118/gcc/../libdecnumber
-I/home/mrichmon/gcc-4.3-20080118/gcc/../libdecnumber/dpd -I../libdecnumber   
/home/mrichmon/gcc-4.3-20080118/gcc/global.c -o global.o
cc1: warnings being treated as errors
/home/mrichmon/gcc-4.3-20080118/gcc/global.c: In function 'find_reg':
/home/mrichmon/gcc-4.3-20080118/gcc/global.c:1020: error: array subscript is
above array bounds
make[3]: *** [global.o] Error 1


-- 
   Summary: Error compiling global.c in 01/18/08 snapshot under
Debian Linux 4.0 for mips
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov


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

[Bug c++/33984] [4.2/4.3 Regression] bit-fields, references and overloads

2008-01-20 Thread mark at codesourcery dot com



--- Comment #6 from mark at codesourcery dot com  2008-01-20 20:28 ---
Subject: Re:  [4.2/4.3 Regression] bit-fields, references and
 overloads

aoliva at gcc dot gnu dot org wrote:
> --- Comment #5 from aoliva at gcc dot gnu dot org  2008-01-17 18:01 
> ---
> Created an attachment (id=14959)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14959&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14959&action=view)
> Slight revision of Jakub's patch that fixes the regression
> 
> Getting built-in candidate functions not to use the bit-field types fixed the
> regression Jakub noticed in his patch, and keeps the progression in place.  
> I'm
> almost done testing this, and I'll post it to gcc-patches then.

Thank you for working on this.  I think this is the right idea, but I
have two comments:

* In add_builtin_candidates, I think you can just do:

  argtypes[i] = unlowered_expr_type (lvalue_type (args[i]));

* In layout_class_type, I understand that you're trying to preserve
cv-qualification.  I don't see a test case for that, though.  If there's
a bug you're fixing here, let's have a test case for it.

Thanks,


-- 


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

[Bug libfortran/34887] reverse tabbing before slash descriptor (regression vs. g77)

2008-01-20 Thread tkoenig at gcc dot gnu dot org



--- Comment #1 from tkoenig at gcc dot gnu dot org  2008-01-20 20:18 ---
Reduced test case:

$ cat bug-4.f
  program main
  write (*,'(3X A, T1, A,/)') 'aa', 'bb'
  end
$ gfortran bug-4.f && ./a.out
bb

$ g77 bug-4.f && ./a.out
bb aa


-- 

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-01-20 20:18:11
   date||
Summary|NIST FM903.f anomaly|reverse tabbing before slash
   ||descriptor (regression vs.
   ||g77)


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

[Bug c++/23257] Incorrect exception-handling behavior with references

2008-01-20 Thread mmitchel at gcc dot gnu dot org



--- Comment #5 from mmitchel at gcc dot gnu dot org  2008-01-20 20:13 
---
This is a known bug in the Itanium C++ ABI.  ARM noticed this; there variant of
the C++ ABI has the additional is_reference parameter precisely to correctly
handle this case.

I looked at this in some detail at one point and concluded that the only ways
we could fix it would require a binary-compatibility break with previous
releases.  Perhaps the next major libstdc++ upgrade would be a good opportunity
for that.


-- 


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

[Bug testsuite/34889] gcc.c-torture/execute/builtins/pr23484-chk.c fails on 16 bit integer platforms

2008-01-20 Thread pmarques at grupopie dot com



--- Comment #1 from pmarques at grupopie dot com  2008-01-20 19:39 ---
Created an attachment (id=14979)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14979&action=view)
the attached patch implements the proposed change


-- 


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

[Bug testsuite/34889] New: gcc.c-torture/execute/builtins/pr23484-chk.c fails on 16 bit integer platforms

2008-01-20 Thread pmarques at grupopie dot com

gcc.c-torture/execute/builtins/pr23484-chk.c has on line 44:

  if (snprintf (buf, l1 ? sizeof (buf) : 4, "%d", l1 + 65536) != 5
  || memcmp (buf, "655\0", 8))

but on a 16 bit platform like the avr, the "l1 + 65536" overflows and gives the
wrong result. Changing that to:

  if (snprintf (buf, l1 ? sizeof (buf) : 4, "%d", l1 + 32760) != 5
  || memcmp (buf, "327\0", 8))

fixes the problem.


-- 
   Summary: gcc.c-torture/execute/builtins/pr23484-chk.c fails on 16
bit integer platforms
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pmarques at grupopie dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: avr-*-*


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

[Bug target/27192] call through function pointer goes to wrong address

2008-01-20 Thread wvangulik at xs4all dot nl



--- Comment #6 from wvangulik at xs4all dot nl  2008-01-20 19:30 ---
Bug is still present in 4.2.2.

Some more info:

I rewrote the example to (atleast for me) little more clear example.

struct fseqp_void
{
void (*p) (void);
char *e;
};

struct fseqp_void c;

void bar (void){}

int main (void)
{
c.e = (char *)bar + 2;
c.p = bar;
c.p();
return 0;
}

The problem is the re-use after loading bar into the struct:

ldi r24,lo8(bar+2)

[Bug middle-end/34725] [4.3 regression] gcc 4.3-rev 131213 miscompiles libgcrypt 1.4.0 at -O2 -mtune=i686 -fomit-frame-pointer

2008-01-20 Thread jakub at gcc dot gnu dot org



--- Comment #4 from jakub at gcc dot gnu dot org  2008-01-20 19:26 ---
It fails even with gcc 4.1.2 and the same CFLAGS, and the problem is just buggy
inline assembly.
Following patch cures this for me:
--- hwfeatures.c.xx 2007-12-05 12:03:33.0 +0100
+++ hwfeatures.c2008-01-20 19:54:54.0 +0100
@@ -79,13 +79,12 @@ detect_ia32_gnuc (void)
 ("pushl %%ebx\n\t"   /* Save GOT register.  */
  "xorl  %%eax, %%eax\n\t"/* 0 -> EAX.  */
  "cpuid\n\t" /* Get vendor ID.  */
- "leal  %0, %%eax\n\t"   /* EBX,EDX,ECX -> VENDOR_ID.  */
- "movl  %%ebx, (%%eax)\n\t"
- "movl  %%edx, 4(%%eax)\n\t"
- "movl  %%ecx, 8(%%eax)\n\t"
+ "movl  %%ebx, (%1)\n\t"/* EBX,EDX,ECX -> VENDOR_ID.  */
+ "movl  %%edx, 4(%1)\n\t"
+ "movl  %%ecx, 8(%1)\n\t"
  "popl  %%ebx\n"
  : "=m" (vendor_id)
- :
+ : "S" (&vendor_id[0])
  : "%eax", "%ecx", "%edx", "cc"
  );
   vendor_id[12] = 0;

The problem is that %0 corresponding to "=m" is expanded when %esp is different
from what it has been originally on inline asm entry (and exit).  Without
-fomit-frame-pointer GCC will usually use (%ebp+N) for %0, but with
-fomit-frame-pointer it uses (%esp+M), but as there is pushl %ebx before this,
it means the inline asm stores to a different location than expected.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug target/34888] New: Stack patterns for AVR not optimal

2008-01-20 Thread hutchinsonandy at aim dot com

There are several instruction patterns related to stack pointer operations.
These are not quite right:

1) popqi and poph1 patterns use post_inc codes - when in fact there are pre_inc
 - this could fail if gcc ever used them outside prolog/epilog

2) Stack moves such as push/pop should be placed before mov patterns, to
provide best matching.

3)Stack adjustment (SP=SP+c) is matching with *addhi pattern, which causes
reloads of output and input. We really want it to match "*addhi3_sp_R_pc2" when
offset is small so *addhi3_sp_R_pc2 needs to be placed before *addhi

4)"*addhi3_sp_R_pc2" does not provide full range of optimal adjustment. For
example, SP=SP+8 takes 4 instructions using rcall but around 8 using addition
through register. This functionality needs extending accordingly as SP=SP+8 is
very common.


-- 
   Summary: Stack patterns for AVR not optimal
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hutchinsonandy at aim dot com
GCC target triplet: avr-*-*


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

[Bug fortran/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90

2008-01-20 Thread zadeck at naturalbridge dot com



--- Comment #14 from zadeck at naturalbridge dot com  2008-01-20 18:30 
---
confirmed on my machine,
i will have my best people work on it.

kenny


-- 

zadeck at naturalbridge dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |zadeck at naturalbridge dot
   |dot org |com


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

[Bug fortran/34876] can't read zero length array sections

2008-01-20 Thread jvdelisle at gcc dot gnu dot org



--- Comment #3 from jvdelisle at gcc dot gnu dot org  2008-01-20 18:10 
---
In the failing case, we have no stride:

Breakpoint 1, gfc_walk_subexpr (ss=0xfc2de0, expr=0x106f6b0)
at ../../gcc43/gcc/fortran/trans-array.c:5609
(gdb) p *expr->ref

snip
>  stride = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, dimen_type = 

And in the passing case we do:

Breakpoint 1, gfc_walk_subexpr (ss=0xfc2de0, expr=0x106f6b0)
at ../../gcc43/gcc/fortran/trans-array.c:5609
snip
>  stride = {0x106fb70, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
(gdb) 


-- 


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

[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605

2008-01-20 Thread dominiq at lps dot ens dot fr



--- Comment #37 from dominiq at lps dot ens dot fr  2008-01-20 18:09 ---
(In reply to comment #36)
> ... And, if I understand correctly the comment #32, with 64 bits mode it does
> fails with wo_prof_mult_fields_peeling.c. Please fix me if I am wrong.

Yes, you are right. I did not look carefully enough to my display. What's
happen is that the executable with -profile-generate segfault.

I am not sure to be in a position to reapply the patches in the coming hours.
I'll do my best.


-- 


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

[Bug libfortran/34887] New: NIST FM903.f anomaly

2008-01-20 Thread jvdelisle at gcc dot gnu dot org

We are computing the correct result for test 8 of FM903.f, but one of the
"Correct" answers is truncated.  Both are truncated in 4.2 and my last patch
gives this.

With FM903.f

gfortran: 
 COMPUTED= 
  12.34506.78 120.34 506.78 123.40 567.80
 CORRECT:2 CORRECT ANSWERS POSSIBLE
  12.34506.78 120.34 506.78

 +12.34506.78 120.34 506.78 123.40 567.80


g77, sun, intel
 COMPUTED= 
  12.34506.78 120.34 506.78 123.40 567.80
 CORRECT:2 CORRECT ANSWERS POSSIBLE
  12.34506.78 120.34 506.78 123.40 567.80

 +12.34506.78 120.34 506.78 123.40 567.80


-- 
   Summary: NIST FM903.f anomaly
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jvdelisle at gcc dot gnu dot org


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

[Bug fortran/34854] Valid USE statement is rejected

2008-01-20 Thread pault at gcc dot gnu dot org



--- Comment #2 from pault at gcc dot gnu dot org  2008-01-20 17:07 ---
Fixed on trunk - thanks for the report.

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

[Bug fortran/34861] ICE in function with entry (and result?)

2008-01-20 Thread pault at gcc dot gnu dot org



--- Comment #6 from pault at gcc dot gnu dot org  2008-01-20 17:07 ---
Fixed on trunk - thanks for the report.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605

2008-01-20 Thread olga at gcc dot gnu dot org



--- Comment #36 from olga at gcc dot gnu dot org  2008-01-20 17:03 ---
(In reply to comment #35)
> Note that the test gcc.dg/struct/wo_prof_mult_field_peeling.c pass for 32 and
> 64 bit modes on i686-apple-darwin9, so I am not sure that what follows will
> help.

Sorry, I meant compiling with two patches: from comment #11 and from comment
#31. And, if I understand correctly the comment #32, with 64 bits mode it does
fails with wo_prof_mult_fields_peeling.c. Please fix me if I am wrong.

Thank you a lot,
Olga


-- 


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

[Bug fortran/34872] [4.3 Regression] Spurious error in snapshot of 01/18/08: Statement at (1) is not a valid branch target statement for the branch statement at (2)

2008-01-20 Thread jakub at gcc dot gnu dot org



-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug fortran/34858] [4.3 Regression] ICE on invalid depending of the length of the source name

2008-01-20 Thread jakub at gcc dot gnu dot org



-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug fortran/34848] [4.3 Regression] internal compiler error with optional argument of character type and array return type

2008-01-20 Thread jakub at gcc dot gnu dot org



-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug fortran/34784] [4.2/4.3 Regression] implicit character(s) hides type of selected_int_kind intrinsic

2008-01-20 Thread pault at gcc dot gnu dot org

--- Comment #7 from pault at gcc dot gnu dot org  2008-01-20 16:59 ---
Subject: Bug 34784

Author: pault
Date: Sun Jan 20 16:58:15 2008
New Revision: 131679

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

PR fortran/34861
* resolve.c (resolve_entries): Do not do an array bounds check
if the result symbols are the same.

PR fortran/34854
* module.c (read_module) : Hide the symtree of the previous
version of the symbol if this symbol is renamed.

2008-01-20  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/34784
* gfortran.dg/mapping_2.f90: Correct ubound expression for h4.

PR fortran/34861
* gfortran.dg/entry_array_specs_3.f90: New test.

PR fortran/34854
* gfortran.dg/use_rename_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/entry_array_specs_3.f90
trunk/gcc/testsuite/gfortran.dg/use_rename_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/mapping_2.f90

-- 

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

[Bug fortran/34854] Valid USE statement is rejected

2008-01-20 Thread pault at gcc dot gnu dot org

--- Comment #1 from pault at gcc dot gnu dot org  2008-01-20 16:59 ---
Subject: Bug 34854

Author: pault
Date: Sun Jan 20 16:58:15 2008
New Revision: 131679

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

PR fortran/34861
* resolve.c (resolve_entries): Do not do an array bounds check
if the result symbols are the same.

PR fortran/34854
* module.c (read_module) : Hide the symtree of the previous
version of the symbol if this symbol is renamed.

2008-01-20  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/34784
* gfortran.dg/mapping_2.f90: Correct ubound expression for h4.

PR fortran/34861
* gfortran.dg/entry_array_specs_3.f90: New test.

PR fortran/34854
* gfortran.dg/use_rename_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/entry_array_specs_3.f90
trunk/gcc/testsuite/gfortran.dg/use_rename_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/mapping_2.f90

-- 

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

[Bug fortran/34861] ICE in function with entry (and result?)

2008-01-20 Thread pault at gcc dot gnu dot org

--- Comment #5 from pault at gcc dot gnu dot org  2008-01-20 16:59 ---
Subject: Bug 34861

Author: pault
Date: Sun Jan 20 16:58:15 2008
New Revision: 131679

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

PR fortran/34861
* resolve.c (resolve_entries): Do not do an array bounds check
if the result symbols are the same.

PR fortran/34854
* module.c (read_module) : Hide the symtree of the previous
version of the symbol if this symbol is renamed.

2008-01-20  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/34784
* gfortran.dg/mapping_2.f90: Correct ubound expression for h4.

PR fortran/34861
* gfortran.dg/entry_array_specs_3.f90: New test.

PR fortran/34854
* gfortran.dg/use_rename_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/entry_array_specs_3.f90
trunk/gcc/testsuite/gfortran.dg/use_rename_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/mapping_2.f90

-- 

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

[Bug middle-end/34852] [4.3 Regression] Revision 131576 miscompiled 178.galgel

2008-01-20 Thread hjl dot tools at gmail dot com



--- Comment #7 from hjl dot tools at gmail dot com  2008-01-20 16:43 ---
Oops. This one

--- regmove.c.freq  2008-01-17 07:31:56.0 -0800
+++ regmove.c   2008-01-20 08:42:42.0 -0800
@@ -1695,7 +1695,7 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
   rtx p;
   rtx post_inc = 0, post_inc_set = 0, search_end = 0;
   int success = 0;
-  int num_calls = 0, s_num_calls = 0;
+  int num_calls = 0, freq_calls = 0, s_num_calls = 0, s_freq_calls = 0;
   enum rtx_code code = NOTE;
   HOST_WIDE_INT insn_const = 0, newconst = 0;
   rtx overlap = 0; /* need to move insn ? */
@@ -1887,10 +1887,13 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
break;

  num_calls++;
+ freq_calls += REG_FREQ_FROM_BB  (BLOCK_FOR_INSN (p));

  if (src_note)
-   s_num_calls++;
-
+   {
+ s_num_calls++;
+ s_freq_calls += REG_FREQ_FROM_BB  (BLOCK_FOR_INSN (p));
+   }
}
 }

@@ -1939,7 +1942,7 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
 {
   rtx note = find_reg_note (insn, REG_EQUAL, NULL_RTX);
   rtx q, set2 = NULL_RTX;
-  int num_calls2 = 0, s_length2 = 0;
+  int num_calls2 = 0, s_length2 = 0, freq_calls2 = 0;

   if (note && CONSTANT_P (XEXP (note, 0)))
{
@@ -1968,7 +1971,10 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
  break;
}
  if (CALL_P (p))
-   num_calls2++;
+   {
+ num_calls2++;
+ freq_calls2 += REG_FREQ_FROM_BB  (BLOCK_FOR_INSN (p));
+   }
}
  if (q && set2 && SET_DEST (set2) == src && CONSTANT_P (SET_SRC
(set2))
  && validate_change (insn, &SET_SRC (set), XEXP (note, 0), 0))
@@ -1976,6 +1982,7 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
  delete_insn (q);
  INC_REG_N_SETS (REGNO (src), -1);
  REG_N_CALLS_CROSSED (REGNO (src)) -= num_calls2;
+ REG_FREQ_CALLS_CROSSED (REGNO (src)) -= freq_calls2;
  REG_LIVE_LENGTH (REGNO (src)) -= s_length2;
  insn_const = 0;
}
@@ -2044,12 +2051,14 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
   REG_NOTES (p) = src_note;

   REG_N_CALLS_CROSSED (REGNO (src)) += s_num_calls;
+  REG_FREQ_CALLS_CROSSED (REGNO (src)) += s_freq_calls;
 }

   INC_REG_N_SETS (REGNO (src), 1);
   INC_REG_N_SETS (REGNO (dst), -1);

   REG_N_CALLS_CROSSED (REGNO (dst)) -= num_calls;
+  REG_FREQ_CALLS_CROSSED (REGNO (dst)) -= freq_calls;

   REG_LIVE_LENGTH (REGNO (src)) += s_length;
   if (REG_LIVE_LENGTH (REGNO (dst)) >= 0)


-- 


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

[Bug middle-end/34852] [4.3 Regression] Revision 131576 miscompiled 178.galgel

2008-01-20 Thread hjl dot tools at gmail dot com



--- Comment #6 from hjl dot tools at gmail dot com  2008-01-20 16:42 ---
Does this patch make any senses?

--- regmove.c.freq  2008-01-17 07:31:56.0 -0800
+++ regmove.c   2008-01-20 08:40:34.0 -0800
@@ -1695,7 +1695,7 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
   rtx p;
   rtx post_inc = 0, post_inc_set = 0, search_end = 0;
   int success = 0;
-  int num_calls = 0, s_num_calls = 0;
+  int num_calls = 0, freq_calls = 0, s_num_calls = 0, s_freq_calls = 0;
   enum rtx_code code = NOTE;
   HOST_WIDE_INT insn_const = 0, newconst = 0;
   rtx overlap = 0; /* need to move insn ? */
@@ -1887,10 +1887,13 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
break;

  num_calls++;
+ freq_calls += REG_FREQ_FROM_BB  (BLOCK_FOR_INSN (p));

  if (src_note)
-   s_num_calls++;
-
+   {
+ s_num_calls++;
+ s_freq_calls += REG_FREQ_FROM_BB  (BLOCK_FOR_INSN (p));
+   }
}
 }

@@ -1939,7 +1942,7 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
 {
   rtx note = find_reg_note (insn, REG_EQUAL, NULL_RTX);
   rtx q, set2 = NULL_RTX;
-  int num_calls2 = 0, s_length2 = 0;
+  int num_calls2 = 0, s_length2 = 0, freq_calls2 = 0;

   if (note && CONSTANT_P (XEXP (note, 0)))
{
@@ -1968,7 +1971,10 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
  break;
}
  if (CALL_P (p))
-   num_calls2++;
+   {
+ num_calls2++;
+ freq_calls2 += REG_FREQ_FROM_BB  (BLOCK_FOR_INSN (p));
+   }
}
  if (q && set2 && SET_DEST (set2) == src && CONSTANT_P (SET_SRC
(set2))
  && validate_change (insn, &SET_SRC (set), XEXP (note, 0), 0))
@@ -1976,6 +1982,7 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
  delete_insn (q);
  INC_REG_N_SETS (REGNO (src), -1);
  REG_N_CALLS_CROSSED (REGNO (src)) -= num_calls2;
+ REG_FREQ_CALLS_CROSSED (REGNO (src)) -= freq_calls2;
  REG_LIVE_LENGTH (REGNO (src)) -= s_length2;
  insn_const = 0;
}
@@ -2044,12 +2051,14 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
   REG_NOTES (p) = src_note;

   REG_N_CALLS_CROSSED (REGNO (src)) += s_num_calls;
+  REG_FREQ_CALLS_CROSSED (REGNO (src)) += s_freq_calls;
 }

   INC_REG_N_SETS (REGNO (src), 1);
   INC_REG_N_SETS (REGNO (dst), -1);

   REG_N_CALLS_CROSSED (REGNO (dst)) -= num_calls;
+  REG_FREQ_CALLS_CROSSED (REGNO (dst)) -= num_calls;

   REG_LIVE_LENGTH (REGNO (src)) += s_length;
   if (REG_LIVE_LENGTH (REGNO (dst)) >= 0)


-- 


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

[Bug middle-end/34852] [4.3 Regression] Revision 131576 miscompiled 178.galgel

2008-01-20 Thread hjl dot tools at gmail dot com



--- Comment #5 from hjl dot tools at gmail dot com  2008-01-20 16:34 ---
Should we also update REG_FREQ_CALLS_CROSSED whenever REG_N_CALLS_CROSSED
is updated? In regmove.c, there are

  delete_insn (q);
  INC_REG_N_SETS (REGNO (src), -1);
  REG_N_CALLS_CROSSED (REGNO (src)) -= num_calls2;
  REG_LIVE_LENGTH (REGNO (src)) -= s_length2;
  insn_const = 0;
...
  if (src_note)
{
  /* Move the death note for SRC from INSN to P.  */
  if (! overlap)
remove_note (insn, src_note);
  XEXP (src_note, 1) = REG_NOTES (p);
  REG_NOTES (p) = src_note;

  REG_N_CALLS_CROSSED (REGNO (src)) += s_num_calls;
}

  INC_REG_N_SETS (REGNO (src), 1);
  INC_REG_N_SETS (REGNO (dst), -1);

  REG_N_CALLS_CROSSED (REGNO (dst)) -= num_calls;

There is we only update REG_N_CALLS_CROSSED, not REG_FREQ_CALLS_CROSSED.


-- 


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

[Bug tree-optimization/34472] [4.3 Regression] gcc.dg/struct/wo_prof_malloc_size_var.c doesn't work

2008-01-20 Thread zadeck at naturalbridge dot com



--- Comment #11 from zadeck at naturalbridge dot com  2008-01-20 16:34 
---
Subject: Re:  [4.3 Regression] gcc.dg/struct/wo_prof_malloc_size_var.c
 doesn't work

olga at gcc dot gnu dot org wrote:
> --- Comment #10 from olga at gcc dot gnu dot org  2008-01-20 16:28 ---
> (In reply to comment #9)
>   
>> olga, 
>> even if the test case does not normally ice on your system, you be able to 
>> see
>> the bug if you run the test with valgrind.
>> 
>
> Kenny,
>
> Thank you a lot for information. I was not aware about valgrid. Does it help
> also with segfaults?
>
> The patch in comment #4 solves the ICE, but on some system it generates the
> execution failures (PR 34534 and PR 34483). Can you see what it makes on your
> system?
>
> Thank you a lot,
> Olga
>
>
>
>   
generally it does. it is not perfect.   it is very good at finding
faults with malloc'ed memory.
did you actually try valgrind with this bug?  if you need some help, hop
on irc and i will talk you thru it.

kenny


-- 


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

[Bug c++/34886] New: Strangeness of name lookup in template function

2008-01-20 Thread rvovsd at mail dot ru

On compiling that code:

--- begin code ---
class Y {};

void f(Y*) { } // line 3. If comment - all ok

template < typename T>
void sel(T* a) { f(a); } //line 6

void f(void*) {}

int main(int argc, char **argv)
{
sel((void*)0); //line 12
}
--- end code ---

Àppears error:
../main.cpp: In function void sel(T*) [with T = void]:
../main.cpp:12:   instantiated from here
../main.cpp:6: error: invalid conversion from void* to Y*
../main.cpp:6: error:   initializing argument 1 of void f(Y*)

If comment line 3, then work.
Also work, if line 3 move after line 6.

If functions f(Y*), f(void*) and sel(T*) placed in different header files, then
arise dependency on order including headers.


-- 
   Summary: Strangeness of name lookup in template function
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rvovsd at mail dot ru
  GCC host triplet: openSuse 10.3


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

[Bug tree-optimization/34472] [4.3 Regression] gcc.dg/struct/wo_prof_malloc_size_var.c doesn't work

2008-01-20 Thread olga at gcc dot gnu dot org



--- Comment #10 from olga at gcc dot gnu dot org  2008-01-20 16:28 ---
(In reply to comment #9)
> olga, 
> even if the test case does not normally ice on your system, you be able to see
> the bug if you run the test with valgrind.

Kenny,

Thank you a lot for information. I was not aware about valgrid. Does it help
also with segfaults?

The patch in comment #4 solves the ICE, but on some system it generates the
execution failures (PR 34534 and PR 34483). Can you see what it makes on your
system?

Thank you a lot,
Olga



-- 


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

[Bug middle-end/34793] warning: 'areg' may be used uninitialized in this function

2008-01-20 Thread manu at gcc dot gnu dot org



--- Comment #8 from manu at gcc dot gnu dot org  2008-01-20 16:06 ---
(In reply to comment #7)
> (In reply to comment #6)
> 
> > Sorry, I don't have any of those trees left.  But if I ever come to
> > revisit those two bugs I'll make sure it fixes this bogus warning.
> 
> If you can give me some hints about where to start, I do have the
> patched tree around on one of my machines, so I might make a stab at
> fixing this.  I'm not a seasoned GCC hacker but willing to learn. ;-)

If you have questions about GCC development they will be more visible on
[EMAIL PROTECTED] than in this bug report.

A "may be" uninitialized warning is given when execute_late_warn_uninitialized
finds an input to a PHI node that is SSA_NAME with an empty definition. This is
marked as in the output of -fdump-tree-* as, for example, 

  # BLOCK 14 freq:596
  # PRED: 7 [14.3%]  (exec) 8 [100.0%]  (fallthru,exec) 9 [100.0%] 
(fallthru,exec) 10 [100.0%]  (fallthru,exec) 11 [100.0%]  (fallthru,exec) 12
[100.0%]  (fallthru,exe\
c) 13 [100.0%]  (fallthru,exec)
  # aregD.1596_1 = PHI 
:;

The aregD.1596_26(D)(7) means that if we entered this BB from BB 7, then the
value of the variable is uninitialized.

In BB 7 we have:

  # BLOCK 7 freq:596
  # PRED: 6 [50.0%]  (true,exec)
  switch (val.0D.1608_22)
{
  case 26: goto ;
  case 27: goto ;
  case 28: goto ;
  case 29: goto ;
  case 30: goto ;
  case 31: goto ;
  default : goto ;
}
  # SUCC: 8 [14.3%]  (exec) 9 [14.3%]  (exec) 10 [14.3%]  (exec) 11 [14.3%] 
(exec) 12 [14.3%]  (exec) 13 [14.3%]  (exec) 14 [14.3%]  (exec)

The 'default' case jumps directly into BB 14 above and thus creates the extra
input to the PHI node which is detected by the execute_late_warn_uninitialized
pass.

If you can manage to convince GCC to not create that default case, then I think
the PHI node won't contain any input with (D) and the warning won't be emitted.
Now, if I understood Richard correctly, PR14495 is about not creating the
default case in general by using VRP information. However, even if you fix
that, there is another bug in VRP (PR30317) that doesn't handle the kind of
comparisons that appear in this testcase.

I don't think those are trivial bugs, but if you still want to give it a try,
to test that you fixed PR14495 you can modify your testcase to use "if" instead
of a switch:

  if ((val >= 26)) && (val <= 31))
{
  unsigned int areg;
  if (val == 26)
  areg = xreg = (xreg & 0xff00) | (bval & 0xff);
  else if (val == 27)
areg = xreg =
  (xreg & 0xff) | ((bval << 8) & 0xff00);
  else if (val == 28)
  areg = yreg = (yreg & 0xff00) | (bval & 0xff);
  else if (val == 29)
areg = yreg =
  (yreg & 0xff) | ((bval << 8) & 0xff00);
  else if (val == 30)
  areg = zreg = (zreg & 0xff00) | (bval & 0xff);
  else if (val == 31)
areg = zreg =
  (zreg & 0xff) | ((bval << 8) & 0xff00);
  disp_print_addr_reg (val, areg);
}

But this still gets a warning because you need to fix PR30317 first. If you
modify the above slightly, VRP works and you don't get the warning:

  if ((val >= 26))
if ((val <= 31))
{
  unsigned int areg;
  if (val == 26)
  areg = xreg = (xreg & 0xff00) | (bval & 0xff);
  else if (val == 27)
areg = xreg =
  (xreg & 0xff) | ((bval << 8) & 0xff00);
  else if (val == 28)
  areg = yreg = (yreg & 0xff00) | (bval & 0xff);
  else if (val == 29)
areg = yreg =
  (yreg & 0xff) | ((bval << 8) & 0xff00);
  else if (val == 30)
  areg = zreg = (zreg & 0xff00) | (bval & 0xff);
  else if (val == 31)
areg = zreg =
  (zreg & 0xff) | ((bval << 8) & 0xff00);
  disp_print_addr_reg (val, areg);
}

Good luck!


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2008-01-15 10:49:47 |2008-01-20 16:06:48
   date||


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

[Bug fortran/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90

2008-01-20 Thread hjl dot tools at gmail dot com



--- Comment #13 from hjl dot tools at gmail dot com  2008-01-20 15:57 
---
It happens for me on Linux/Intel64 with -m32:

http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00907.html

My configuration is

configure flags: --enable-clocale=gnu --with-system-zlib
--enable-decimal-float=bid --with-demangler-in-ld --enable-shared
--enable-threads=posix --enable-haifa --enable-checking=assert
--prefix=/usr/gcc-4.3 --with-local-prefix=/usr/local


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Component|middle-end  |fortran
   Target Milestone|4.3.0   |---


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

[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90

2008-01-20 Thread zadeck at naturalbridge dot com



--- Comment #12 from zadeck at naturalbridge dot com  2008-01-20 15:52 
---
Subject: Re:  [4.3 Regression] gfortran.dg/array_constructor_9.f90

dominiq at lps dot ens dot fr wrote:
> --- Comment #11 from dominiq at lps dot ens dot fr  2008-01-20 15:47 
> ---
> I have put the results of the compilation with -da with the patch at
>
> http://www.lps.ens.fr/~dominiq/gcc/tmp_fresh.tar.bz2
>
> All the files will be in a directory tmp_fresh.  Do you still need the same
> without the patch? It will take some time to reverse the patch and to do the
> rebuilding.
>
>
>   
let me try to build a 32 bit compiler.  that appears to be the problem.
it will be easier if i can get it on my machine. 

kenny


-- 


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

[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90

2008-01-20 Thread dominiq at lps dot ens dot fr



--- Comment #11 from dominiq at lps dot ens dot fr  2008-01-20 15:47 ---
I have put the results of the compilation with -da with the patch at

http://www.lps.ens.fr/~dominiq/gcc/tmp_fresh.tar.bz2

All the files will be in a directory tmp_fresh.  Do you still need the same
without the patch? It will take some time to reverse the patch and to do the
rebuilding.


-- 


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

[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90

2008-01-20 Thread zadeck at naturalbridge dot com



--- Comment #10 from zadeck at naturalbridge dot com  2008-01-20 15:39 
---
Subject: Re:  [4.3 Regression] gfortran.dg/array_constructor_9.f90

dominiq at lps dot ens dot fr wrote:
> --- Comment #9 from dominiq at lps dot ens dot fr  2008-01-20 15:30 
> ---
>   
>> you are building on a mac "darwin" box
>> 
>
> Yes indeed, but the bug is also present for i686-pc-linux-gnu, see for
> instance:
>
> http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00914.html
>
>
>   
i will build this on a 32 bit box.  that is my problem. sorry, thanks.

kenny


-- 


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

[Bug fortran/34848] [4.3 Regression] internal compiler error with optional argument of character type and array return type

2008-01-20 Thread burnus at gcc dot gnu dot org



--- Comment #6 from burnus at gcc dot gnu dot org  2008-01-20 15:36 ---
Created an attachment (id=14978)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14978&action=view)
First draft of the patch

The patch works for the test case, but it fails for auto_char_dummy_array_1.f90
(ICE) and for bind_c_usage_13.f03 (string length is passed, but should not for
Bind(C)).


-- 


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

[Bug middle-end/34852] [4.3 Regression] Revision 131576 miscompiled 178.galgel

2008-01-20 Thread ubizjak at gmail dot com



--- Comment #4 from ubizjak at gmail dot com  2008-01-20 15:34 ---
(In reply to comment #3)
> Double checking patch, I don't see obvious mistakes.  Since the patch should
> only affect register allocation decisions, either we see a latent bug, or
> another example of x86 extra precision causing FP program to misbehave.  I 
> used
> to have LD_PRELOAD library to set 64bit precision that often helped, I will

You can add -mpc=64 to your compile flags instead of LD_PRELOAD trick.


-- 


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

[Bug testsuite/34878] fast-math-pr33299.f90 failure with illegal instruction due to -ffast-math.

2008-01-20 Thread ubizjak at gmail dot com



--- Comment #4 from ubizjak at gmail dot com  2008-01-20 15:34 ---
(In reply to comment #3)
> There is the issue, the testcase should be not run on your computer as it is
> using SSE2.  So this is a testsuite issue.

Please look at gcc.dg/vect/ how this should be done. There is a check_vect ()
call before each runtime test (check_vect is in tree-vect.h). I think that
fortran vectorizer tests should call this test too - perhaps via C bindings?


-- 


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

[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90

2008-01-20 Thread dominiq at lps dot ens dot fr



--- Comment #9 from dominiq at lps dot ens dot fr  2008-01-20 15:30 ---
> you are building on a mac "darwin" box

Yes indeed, but the bug is also present for i686-pc-linux-gnu, see for
instance:

http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00914.html


-- 


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

[Bug tree-optimization/34472] [4.3 Regression] gcc.dg/struct/wo_prof_malloc_size_var.c doesn't work

2008-01-20 Thread zadeck at naturalbridge dot com



--- Comment #9 from zadeck at naturalbridge dot com  2008-01-20 15:29 
---
olga, 

even if the test case does not normally ice on your system, you be able to see
the bug if you run the test with valgrind.


-- 


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

[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90

2008-01-20 Thread zadeck at naturalbridge dot com



--- Comment #8 from zadeck at naturalbridge dot com  2008-01-20 15:24 
---
Subject: Re:  [4.3 Regression] gfortran.dg/array_constructor_9.f90

dominiq at lps dot ens dot fr wrote:
> --- Comment #7 from dominiq at lps dot ens dot fr  2008-01-20 14:39 
> ---
>   
>> I need a more info to reproduce this bug.
>> 
>
> I have tried to give all the info I have been able to gather on my own. My
> config is:
>
> Configured with: ../gcc-4.3-work/configure --prefix=/opt/gcc/gcc4.3w
> --mandir=/opt/gcc/gcc4.3w/share/man --infodir=/opt/gcc/gcc4.3w/share/info
> --build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java
> --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib
> --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
>
> As far as I can tell, the bug appears after the tree optimization, but at this
> point I don't know what I should dump. Having looked at the test-suite 
> results,
> the problem appears on 32 bit x86 platforms. From
>
>   
>> --disable-multilib
>> 
>
> I infer that you cannot try with -m32, isn't it?
>
>
>   
the first comment of the bug says linux/intel64. 

your config string looks like you are building on a mac "darwin" box. 
That would be the difference. I build on a real linux box that cannot
run darwin. 

could you please send me two tar files:
one tar file from the release with out this patch containing the test
case case with the "-da" option and one from the release with the patch
with the same option.  This option will produce a large number of dump
files and from those dumps i will fix the bug. 

Thanks in advance.

kenny


-- 


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

[Bug tree-optimization/34472] [4.3 Regression] gcc.dg/struct/wo_prof_malloc_size_var.c doesn't work

2008-01-20 Thread ubizjak at gmail dot com



--- Comment #8 from ubizjak at gmail dot com  2008-01-20 15:21 ---
(In reply to comment #6)
> Confirmed on x86_64-unknown-linux-gnu.

It fails only with --enable-checkgin=assert, as is the case in
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00695.html


-- 


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

[Bug middle-end/34793] warning: 'areg' may be used uninitialized in this function

2008-01-20 Thread j at uriah dot heep dot sax dot de



--- Comment #7 from j at uriah dot heep dot sax dot de  2008-01-20 15:21 
---
(In reply to comment #6)

> Sorry, I don't have any of those trees left.  But if I ever come to
> revisit those two bugs I'll make sure it fixes this bogus warning.

If you can give me some hints about where to start, I do have the
patched tree around on one of my machines, so I might make a stab at
fixing this.  I'm not a seasoned GCC hacker but willing to learn. ;-)


-- 


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

[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605

2008-01-20 Thread dominiq at lps dot ens dot fr



--- Comment #35 from dominiq at lps dot ens dot fr  2008-01-20 15:16 ---
Note that the test gcc.dg/struct/wo_prof_mult_field_peeling.c pass for 32 and
64 bit modes on i686-apple-darwin9, so I am not sure that what follows will
help.

For the code in comment #34 the assembly code is:

[ibook-dhum] bug/tmp_dir% /opt/gcc/gcc4.3w/bin/gcc -S -O3 -fdump-ipa-all
-fwhole-program -combine -fipa-type-escape wo_prof_mult_field_peeling_db.c
[ibook-dhum] bug/tmp_dir% cat wo_prof_mult_field_peeling_db.s
.text
.align 4,0x90
.globl _main
_main:
pushl   %ebp
movl%esp, %ebp
pushl   %esi
subl$20, %esp
movl$400, (%esp)
callL_malloc$stub
movl$400, (%esp)
movl%eax, %esi
callL_malloc$stub
movl$400, (%esp)
callL_malloc$stub
movl$400, (%esp)
callL_malloc$stub
xorl%eax, %eax
.align 4,0x90
L2:
movl$5, (%esi,%eax,4)
addl$1, %eax
cmpl$100, %eax
jne L2
xorb%al, %al
jmp L4
.align 4,0x90
L3:
addl$1, %eax
cmpl$100, %eax
je  L9
L4:
cmpl$5, (%esi,%eax,4)
je  L3
callL_abort$stub
L9:
addl$20, %esp
xorb%al, %al
popl%esi
popl%ebp
ret
.picsymbol_stub
L_malloc$stub:
.indirect_symbol _malloc
callLPC$1
LPC$1:  popl%eax
movlL1$lz-LPC$1(%eax),%edx
jmp *%edx
L_malloc$stub_binder:
lea L1$lz-LPC$1(%eax),%eax
pushl   %eax
jmp dyld_stub_binding_helper
.lazy_symbol_pointer
L1$lz:
.indirect_symbol _malloc
.long L_malloc$stub_binder
.picsymbol_stub
L_abort$stub:
.indirect_symbol _abort
callLPC$2
LPC$2:  popl%eax
movlL2$lz-LPC$2(%eax),%edx
jmp *%edx
L_abort$stub_binder:
lea L2$lz-LPC$2(%eax),%eax
pushl   %eax
jmp dyld_stub_binding_helper
.lazy_symbol_pointer
L2$lz:
.indirect_symbol _abort
.long L_abort$stub_binder
.subsections_via_symbols

[ibook-dhum] bug/tmp_dir% /opt/gcc/gcc4.3w/bin/gcc -S -O3 -fdump-ipa-all
-fwhole-program -combine -fipa-type-escape -fipa-struct-reorg
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/struct/wo_prof_mult_field_peeling.c
[ibook-dhum] bug/tmp_dir% cat wo_prof_mult_field_peeling.s 
.text
.align 4,0x90
.globl _main
_main:
pushl   %ebp
movl%esp, %ebp
subl$24, %esp
movl$1600, (%esp)
callL_malloc$stub
movl$400, (%esp)
callL_malloc$stub
movl$400, (%esp)
callL_malloc$stub
movl$400, (%esp)
callL_malloc$stub
movl$400, (%esp)
callL_malloc$stub
xorl%edx, %edx
.align 4,0x90
L2:
movl$5, (%eax,%edx,4)
addl$1, %edx
cmpl$100, %edx
jne L2
xorb%dl, %dl
jmp L4
.align 4,0x90
L3:
addl$1, %edx
cmpl$100, %edx
je  L9
L4:
cmpl$5, (%eax,%edx,4)
je  L3
callL_abort$stub
L9:
xorl%eax, %eax
leave
ret
.picsymbol_stub
L_malloc$stub:
.indirect_symbol _malloc
callLPC$1
LPC$1:  popl%eax
movlL1$lz-LPC$1(%eax),%edx
jmp *%edx
L_malloc$stub_binder:
lea L1$lz-LPC$1(%eax),%eax
pushl   %eax
jmp dyld_stub_binding_helper
.lazy_symbol_pointer
L1$lz:
.indirect_symbol _malloc
.long L_malloc$stub_binder
.picsymbol_stub
L_abort$stub:
.indirect_symbol _abort
callLPC$2
LPC$2:  popl%eax
movlL2$lz-LPC$2(%eax),%edx
jmp *%edx
L_abort$stub_binder:
lea L2$lz-LPC$2(%eax),%eax
pushl   %eax
jmp dyld_stub_binding_helper
.lazy_symbol_pointer
L2$lz:
.indirect_symbol _abort
.long L_abort$stub_binder
.subsections_via_symbols

[ibook-dhum] bug/tmp_dir% diff wo_prof_mult_field_peeling.s
wo_prof_mult_field_peeling_db.s
7,9c7,8
<   subl$24, %esp
<   movl$1600, (%esp)
<   callL_malloc$stub
---
>   pushl   %esi
>   subl$20, %esp
12a12
>   movl%eax, %esi
18c18
<   xorl%edx, %edx
---
>   xorl%eax, %eax
21,23c21,23
<   movl$5, (%eax,%edx,4)
<   addl$1, %edx
<   cmpl$100, %edx
---
>   movl$5, (%esi,%eax,4)
>   addl$1, %eax
>   cmpl$100, %eax
25c25
<   xorb%dl, %dl
---
>   xorb%al, %al
29,30c29,30
<   addl$1, %edx
<   cmpl$100, %edx
--

[Bug fortran/34858] [4.3 Regression] ICE on invalid depending of the length of the source name

2008-01-20 Thread dominiq at lps dot ens dot fr



--- Comment #5 from dominiq at lps dot ens dot fr  2008-01-20 14:56 ---
I am trying to proceed backward.  I have reached the following point:

Breakpoint 8, gfc_parse_file () at ../../gcc-4.3-work/gcc/fortran/parse.c:3460
3460{
(gdb) s
gfc_parse_file () at ../../gcc-4.3-work/gcc/fortran/parse.c:3466
3466  gfc_start_source_files ();
(gdb) print gfc_current_ns->common_root->n.common->head->common_next
Cannot access memory at address 0x8
(gdb) print gfc_current_ns->common_root 
Cannot access memory at address 0x8
(gdb) print gfc_current_ns 
$13 = (gfc_namespace *) 0x0
(gdb) s
gfc_start_source_files () at ../../gcc-4.3-work/gcc/fortran/scanner.c:348
348 {
(gdb) s
warning: Got an error handling event: "Cannot access memory at address 0x7".
(gdb) s
warning: Got an error handling event: "Cannot access memory at address 0x7".
(gdb) s
warning: Got an error handling event: "Cannot access memory at address 0x7".
(gdb) s
gfc_start_source_files () at ../../gcc-4.3-work/gcc/fortran/scanner.c:355
355   report_file_change (gfc_current_locus.lb);
(gdb) print gfc_current_locus.lb
$14 = (gfc_linebuf *) 0x40d06700
(gdb) print debug_hooks->start_end_main_source_file
$15 = 0
(gdb) print gfc_source_file
$16 = 0xbfffeec7 "1234567.f90"
(gdb) print file_changes_cur
$17 = 0
(gdb) print *debug_hooks->start_source_file
$18 = {void (unsigned int, const char *)} 0x339b70 

The "warning: Got an error handling event: "Cannot access memory at address
0x7" look bad, but I do not see where they come from.


-- 


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

[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90

2008-01-20 Thread dominiq at lps dot ens dot fr



--- Comment #7 from dominiq at lps dot ens dot fr  2008-01-20 14:39 ---
> I need a more info to reproduce this bug.

I have tried to give all the info I have been able to gather on my own. My
config is:

Configured with: ../gcc-4.3-work/configure --prefix=/opt/gcc/gcc4.3w
--mandir=/opt/gcc/gcc4.3w/share/man --infodir=/opt/gcc/gcc4.3w/share/info
--build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java
--with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib

As far as I can tell, the bug appears after the tree optimization, but at this
point I don't know what I should dump. Having looked at the test-suite results,
the problem appears on 32 bit x86 platforms. From

> --disable-multilib

I infer that you cannot try with -m32, isn't it?


-- 


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

[Bug fortran/34848] [4.3 Regression] internal compiler error with optional argument of character type and array return type

2008-01-20 Thread burnus at gcc dot gnu dot org



--- Comment #5 from burnus at gcc dot gnu dot org  2008-01-20 14:34 ---
I have a patch. Actually, I do not understand why it worked before.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-01-18 11:48:37 |2008-01-20 14:34:44
   date||


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

[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90

2008-01-20 Thread zadeck at naturalbridge dot com



--- Comment #6 from zadeck at naturalbridge dot com  2008-01-20 13:53 
---
I need a more info to reproduce this bug.  I bootstrapped and regression tested
on x86_64-unknown-linux-gnu with suse 10.3 and using
--enable-languages=c,c++,fortran  --disable-multilib before committing the
patch and got 


=== gfortran Summary ===

# of expected passes23538
# of expected failures  4
# of unsupported tests  18

i am not doubting that the failure is related to this patch.  Given all of rest
of the info, it smells like this patch is responsible, but i do not get the
failure on my config.


-- 


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

[Bug fortran/34848] [4.3 Regression] internal compiler error with optional argument of character type and array return type

2008-01-20 Thread krefson at googlemail dot com



--- Comment #4 from krefson at googlemail dot com  2008-01-20 13:53 ---
(In reply to comment #3)
> (In reply to comment #2)
> > It's a regression - and I might be guilty of it with my Bind(C) patches...
> 
> Well, if it's a regression, there's a bigger chance for it to
> be fixed before 4.3 comes out :-)
> 

It would be a milestone if this was fixed, as this would be the first version
of gfortran I will be able to recommend to our users for compiling the CASTEP
electronic structure code. No previous release version has worked - 4.2.3
and earlier all fail to compile CASTEP due to bug # 30095, but snapshots of
4.3.0 from late Nov 2007 appear to work very well indeed.


-- 


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

[Bug c/32102] -Wall stomps on -Wstrict-overflow

2008-01-20 Thread manu at gcc dot gnu dot org



--- Comment #8 from manu at gcc dot gnu dot org  2008-01-20 13:38 ---
(In reply to comment #2)
> I think that having -Wall clobber -Wstrict-overflow in this way is confusing. 
> This isn't reversing the setting of the option, it's changing its level.
> 

Ian, should the above testcase actually give a warning? I am testing revision
131656 and I cannot get a warning no matter what value of -Wstrict-overflow or
optimisation level I try.


-- 


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

[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605

2008-01-20 Thread olga at gcc dot gnu dot org



--- Comment #34 from olga at gcc dot gnu dot org  2008-01-20 13:28 ---
Dave, Dominique,

As I have no such execution failures on any one of machines, would you please
help me debugging the execution failures?

I am actually need the place where it fails and assembly files. The most
convenient file is wo_prof_mult_fields_peeling.c . Can you please produce an
assembly for it? For this file I also generated the artificial result of
struct-reorg optimization (below), to be compiled without -fipa-struct-reorg,
but with all other flags (-O3 -fdump-ipa-all -fwhole-program -combine
-fipa-type-escape). The idea is to compare two assembly files, from original
wo_prof_mult_fields_peeling.c and from faked one:

#include 
#include 
typedef struct
{
  int a;
}str_t0;

typedef struct
{
  float b;
}str_t1;

typedef struct
{
  int c;
}str_t2;

typedef struct
{
  float d;
}str_t3;

#define N 100

int 
main ()
{
  int i;
  str_t0 *p0 = malloc (N * sizeof (str_t0));
  str_t1 *p1 = malloc (N * sizeof (str_t1));
  str_t0 *p2 = malloc (N * sizeof (str_t2));
  str_t0 *p3 = malloc (N * sizeof (str_t3));

  for (i = 0; i < N; i++)
p0[i].a = 5;

  for (i = 0; i < N; i++)
if (p0[i].a != 5)  
  abort ();

  return 0;
}

Thank you,
Olga


-- 


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

1 2 >

1 - 100 of 125 matches

Mail list logo