[Bug tree-optimization/21921] [4.1 Regression] internal compiler error: in tsi_link_before, at tree-iterator.c:113

2005-06-06 Thread bonzini at gcc dot gnu dot org


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-06-05 15:39:26 |2005-06-06 07:03:52
   date||


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


[Bug target/19923] openssl is slower when compiled with gcc 4.0 than 3.3

2005-06-06 Thread steven at gcc dot gnu dot org

--- Additional Comments From steven at gcc dot gnu dot org  2005-06-06 
07:16 ---
Could L1 icache blow-out be the reason? 

-- 


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


[Bug target/21329] [4.0 Regression] optimize i386 block copy

2005-06-06 Thread steven at gcc dot gnu dot org

--- Additional Comments From steven at gcc dot gnu dot org  2005-06-06 
07:22 ---
. 

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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


[Bug target/19923] openssl is slower when compiled with gcc 4.0 than 3.3

2005-06-06 Thread rakdver at atrey dot karlin dot mff dot cuni dot cz

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2005-06-06 07:30 ---
Subject: Re:  openssl is slower when compiled with gcc 4.0 than 3.3

> Could L1 icache blow-out be the reason? 

This is not likely with the minimized example.


-- 


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


[Bug middle-end/20297] #pragma GCC visibility isn't properly handled for builtin functions

2005-06-06 Thread matz at suse dot de

--- Additional Comments From matz at suse dot de  2005-06-06 07:48 ---
Created an attachment (id=9035)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9035&action=view)
New patch

This fixes a problem in HJs patch (which doesn't look at the fndecl
of the builtin, but at the call_expr).

-- 


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


[Bug testsuite/21910] Files from previous runs can make some testcases fail

2005-06-06 Thread e9925248 at stud4 dot tuwien dot ac dot at

--- Additional Comments From e9925248 at stud4 dot tuwien dot ac dot at  
2005-06-06 07:51 ---
In the normal case (no error happens), cleanup-tree-dump will delete such files,
as a more verbose run of the testsuite shows:
Testing tree-ssa/ssa-sink-2.c
doing compile
Invoking the compiler as /tmp/gcc/host-i686-pc-linux-gnu/gcc/xgcc
-B/tmp/gcc/host-i686-pc-linux-gnu/gcc/
/tmp/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-2.c   -O2 -fdump-tree-sink-stats
-fno-show-column -S  -o ssa-sink-2.s
Executing on host: /tmp/gcc/host-i686-pc-linux-gnu/gcc/xgcc
-B/tmp/gcc/host-i686-pc-linux-gnu/gcc/
/tmp/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-2.c   -O2 -fdump-tree-sink-stats
-fno-show-column -S  -o ssa-sink-2.s(timeout = 300)
pid is 14380 -14380
waitres is 14380 exp6 0 0
output is
Checking pattern "sparc-*-sunos*" with i686-pc-linux-gnu
Checking pattern "alpha*-*-*" with i686-pc-linux-gnu
Checking pattern "hppa*-*-hpux*" with i686-pc-linux-gnu
Checking pattern "sparc-*-sunos*" with i686-pc-linux-gnu
Checking pattern "alpha*-*-*" with i686-pc-linux-gnu
Checking pattern "hppa*-*-hpux*" with i686-pc-linux-gnu
remove-build-file `ssa-sink-2.c.t??.sink'
remove-build-file `ssa-sink-2.c.t52.sink'

In my case, cleanup-tree-dump is not executed, as scan-tree-dump-times fails
before, because of the additonal file:
Testing tree-ssa/ssa-sink-1.c
doing compile
Invoking the compiler as /tmp/gcc/host-i686-pc-linux-gnu/gcc/xgcc
-B/tmp/gcc/host-i686-pc-linux-gnu/gcc/
/tmp/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-1.c   -O2 -fdump-tree-sink-stats
-fno-show-column -S  -o ssa-sink-1.s
Executing on host: /tmp/gcc/host-i686-pc-linux-gnu/gcc/xgcc
-B/tmp/gcc/host-i686-pc-linux-gnu/gcc/
/tmp/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-1.c   -O2 -fdump-tree-sink-stats
-fno-show-column -S  -o ssa-sink-1.s(timeout = 300)
pid is 14375 -14375
waitres is 14375 exp6 0 0
output is
Checking pattern "sparc-*-sunos*" with i686-pc-linux-gnu
Checking pattern "alpha*-*-*" with i686-pc-linux-gnu
Checking pattern "hppa*-*-hpux*" with i686-pc-linux-gnu
Checking pattern "sparc-*-sunos*" with i686-pc-linux-gnu
Checking pattern "alpha*-*-*" with i686-pc-linux-gnu
Checking pattern "hppa*-*-hpux*" with i686-pc-linux-gnu
ERROR: gcc.dg/tree-ssa/ssa-sink-1.c: error executing dg-final: couldn't open
"ssa-sink-1.c.t46.sink ssa-sink-1.c.t52.sink": no such file or directory
Error/Warning threshold exceeded:  1 0 (max. 1 3)

To solve this problem, the scan-tree-* functions need to check for this case and
remove the old files, so that at least future runs will not suffer from this
problem, eg:
Index: scantree.exp
===
RCS file: /cvs/gcc/gcc/gcc/testsuite/lib/scantree.exp,v
retrieving revision 1.3
diff -u -r1.3 scantree.exp
--- scantree.exp31 Mar 2005 00:28:49 -  1.3
+++ scantree.exp6 Jun 2005 07:44:44 -
@@ -95,6 +95,12 @@
 set src [file tail [lindex $testcase 0]]
 set output_file "[glob $src.t??.[lindex $args 2]]"

+if { [llength $output_file] > 1 } {
+remove-build-file "$src.t??.[lindex $args 2]"
+error "More than one dump file found: $output_file"
+return
+}
+
 set fd [open $output_file r]
 set text [read $fd]
 close $fd


-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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


[Bug fortran/18923] segfault after subroutine name confusion

2005-06-06 Thread reichelt at gcc dot gnu dot org

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-06-06 
07:59 ---
With the following testcase I still get a segfault:

=
module FOO
contains
subroutine FOO
integer :: I
character(len=selected_int_kind(I)) :: C
end subroutine
end
=


-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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


[Bug tree-optimization/21921] [4.1 Regression] internal compiler error: in tsi_link_before, at tree-iterator.c:113

2005-06-06 Thread bonzini at gcc dot gnu dot org

--- Additional Comments From bonzini at gcc dot gnu dot org  2005-06-06 
09:10 ---
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00446.html

-- 
   What|Removed |Added

   Keywords||patch


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


[Bug tree-optimization/21923] [4.1 Regression] Ada compiler fails to build on gcc 4.1

2005-06-06 Thread pluto at agmk dot net

--- Additional Comments From pluto at agmk dot net  2005-06-06 09:25 ---
at this moment build hangs at:

(...)
stage2/xgcc -Bstage2/ -B/usr/i686-pld-linux/bin/ -c -O2 -march=i686
-mtune=pentium4  -pipe  -gnatpg -gnata -I- -I. -Iada -I../../gcc/ada
../../gcc/ada/ada.ads -o ada/ada.o

(gdb) attach 27402
Attaching to process 27402
Reading symbols from
/home/users/pluto/rpm/BUILD/gcc-4.1-20050605_2025/obj-i686-pld-linux/
 gcc/stage2/gnat1...done.

(gdb) bt
#0  0x080b3c9a in csets___elabb ()
#1  0x0804ac75 in adainit ()
#2  0x08063f62 in gnat_parse_file ()
#3  0x0856e4e8 in toplev_main ()
#4  0x40045ff6 in __libc_start_main () from /lib/libc.so.6
#5  0x0804a131 in _start ()


-- 


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


[Bug c++/21903] Default argument of template function causes a compile-time error

2005-06-06 Thread nathan at gcc dot gnu dot org

--- Additional Comments From nathan at gcc dot gnu dot org  2005-06-06 
09:34 ---
ug. This looks like a defect in the std.  As has been pointed out, we cannot
parse the default argument until the outer class is complete -- because the
default argument of the nested class can legitimately call or access a static
member of the outer class that happens to be declared after the nested class. 
However after the definition of the nested class, that template is complete
according to the language, and should therefore be instantiable.  When
instantiating it, we have to instantiate the declarations of all its member
functions [14.7.1]. Aha! 'but not ... the default arguments'.  Default arguments
are implicitly instantiated 'when the function is called in a context that
requires the value of that default argument'.

So, we need to remember we're instantiating a function declaration containing an
unparsed default arg -- and then DTRT when the arg gets parsed.

This isn't a regression (is it?), so won't be fixed until 4.1 is released.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |nathan at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-06-04 10:46:16 |2005-06-06 09:34:54
   date||


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


[Bug c++/21903] Default argument of template function causes a compile-time error

2005-06-06 Thread giovannibajo at libero dot it

--- Additional Comments From giovannibajo at libero dot it  2005-06-06 
09:45 ---
Not a regression.

-- 
   What|Removed |Added

  Known to fail||2.95 3.4.3 4.1.0


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


[Bug fortran/21877] internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:165

2005-06-06 Thread fxcoudert at gcc dot gnu dot org

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-06-06 
10:20 ---
Philippe sent me his code. Proper reduction showed that his initial bug is PR
17911. I leave this PR open for the following bug:

$ cat a-stripped.f90 
  module foo
  character(len=l) :: s
  contains
  end module foo
$ gfortran a-stripped.f90 
a-stripped.f90:0: internal compiler error: in lhd_set_decl_assembler_name, at
langhooks.c:165

-- 
   What|Removed |Added

   Last reconfirmed|2005-06-02 11:41:45 |2005-06-06 10:20:28
   date||


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


[Bug fortran/21877] internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:165

2005-06-06 Thread fxcoudert at gcc dot gnu dot org

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-06-06 
10:21 ---
I messed up comment #4: the PR for the original bug is PR 19546.

-- 


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


[Bug fortran/19546] Internal subroutine setting function return value gives internal compiler error

2005-06-06 Thread fxcoudert at gcc dot gnu dot org

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-06-06 
10:22 ---
Shorter testcase:

function f
  integer :: f
  contains
subroutine sub
  f = 1
end subroutine sub
end function f

-- 
   What|Removed |Added

 CC||P dot Schaffnit at access
   ||dot rwth-aachen dot de
   Last reconfirmed|2005-04-22 05:11:52 |2005-06-06 10:22:21
   date||


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


[Bug c++/21928] New: double declaration not recognized

2005-06-06 Thread wolfgang dot roehrl at de dot gi-de dot com
Dear all,

I would like to post a bug report for the GNU C/C++ compiler 3.3-e500.

We use the compiler to generate code for a PowerPC processor.

Used invokation line for the GNU C++ compiler:

ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
  -fmerge-templates -mmultiple -mno-string -mstrict-align -O3
  -fno-exceptions -fno-rtti -fno-builtin-printf
  -I
  -D
  X.CPP -oX.O


// file X.CPP

namespace N1
{
extern int i;
}

namespace N2
{
extern int i;
}

using N1::i;
using N2::i;

int f () { return i; }


The code above compiles fine with GNU. But I think that the compiler should
flag the second using declaration ("using N2::i;") since variable i is already
declared in the current scope (cf. 7.3.3/10).
(By the way this is the diagnostic given by Comeau online.)


Kind regards
W. Roehrl

-- 
   Summary: double declaration not recognized
   Product: gcc
   Version: 3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wolfgang dot roehrl at de dot gi-de dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc-sun-solaris2.5.1
  GCC host triplet: i386-pc-mingw32
GCC target triplet: powerpc-wrs-vxworks


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


[Bug c++/21928] double declaration not recognized

2005-06-06 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
10:42 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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


[Bug c++/20240] [3.3 Regression] invalid using-redeclaration accepted

2005-06-06 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
10:43 ---
*** Bug 21928 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||wolfgang dot roehrl at de
   ||dot gi-de dot com


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


[Bug tree-optimization/21847] [4.0/4.1 Regression] misscompiling of the following java code

2005-06-06 Thread aph at redhat dot com

--- Additional Comments From aph at redhat dot com  2005-06-06 10:44 ---
OK, I'm looking at it.


-- 


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


[Bug fortran/13257] [4.0 only] Error instead of warning for missing comma in format string

2005-06-06 Thread giovannibajo at libero dot it

--- Additional Comments From giovannibajo at libero dot it  2005-06-06 
10:45 ---
ping this, it looks like Andrew just missed 4.0.1 too for this bug :)

-- 


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


[Bug tree-optimization/19768] [4.0 Regression] ICE: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set

2005-06-06 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
10:51 ---
(In reply to comment #13)
> I know.  Andrew: when you backported this patch: 
>PR tree-optimization/21085 
> * fold-const (fold): Don't change X % -C to X % C if C has 
> overflowed. 
> you accidentally also checked in a change to tree-ssa-dse.c (rev 2.17.4.1) 
> which backs out your fix for this problem.  This happened between 
>   -D "2005-05-11 14:00" and -D "2005-05-11 15:00" . 
> (Of course the ChangeLog didn't tell this accident, so I was puzzled 
> first ;) ) 

Michael could you revert it, I have no time to do so today, I have exams to 
work on all day today.

-- 
   What|Removed |Added

 CC||matz at suse dot de


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


[Bug tree-optimization/21847] [4.0/4.1 Regression] misscompiling of the following java code

2005-06-06 Thread aph at redhat dot com

--- Additional Comments From aph at redhat dot com  2005-06-06 11:09 ---
Failure during bootstrap:

./xgcc -B./ -B/home/aph/gcc4/install/i686-pc-linux-gnu/bin/ -isystem
/home/aph/gcc4/install/i686-pc-linux-gnu/include -isystem
/home/aph/gcc4/install/i686-pc-linux-gnu/sys-include
-L/home/aph/gcc4/build/gcc/../ld -O2  -DIN_GCC-W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED 
-I. -I. -I/home/aph/gcc4/gcc/gcc -I/home/aph/gcc4/gcc/gcc/.
-I/home/aph/gcc4/gcc/gcc/../include -I/home/aph/gcc4/gcc/gcc/../libcpp/include 
-DL_moddi3 -fvisibility=hidden -DHIDE_EXPORTS -fexceptions -fnon-call-exceptions
-c /home/aph/gcc4/gcc/gcc/libgcc2.c -o libgcc/./_moddi3.o
/home/aph/gcc4/gcc/gcc/libgcc2.c: In function '__divdi3':
/home/aph/gcc4/gcc/gcc/libgcc2.c:1056: error: Type mismatch between an SSA_NAME
and its symbol.
/home/aph/gcc4/gcc/gcc/libgcc2.c:1056: error: Missing definition
for SSA_NAME: D.4215_136in statement:
#   TMT.31_158 = V_MAY_DEF ;
*rp_35 = D.4215_136;
/home/aph/gcc4/gcc/gcc/libgcc2.c:1056: internal compiler error: verify_ssa 
failed.
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


-- 


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


[Bug tree-optimization/21847] [4.0/4.1 Regression] misscompiling of the following java code

2005-06-06 Thread aph at redhat dot com

--- Additional Comments From aph at redhat dot com  2005-06-06 11:34 ---
I think you want mark_stmt_necessary (stmt, true)


-- 


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


[Bug c++/15674] [DR214] template argument binding differs between member and static fumctions

2005-06-06 Thread nathan at gcc dot gnu dot org

--- Additional Comments From nathan at gcc dot gnu dot org  2005-06-06 
11:44 ---
Not a regression, but still a bug.  We should reject the static member case too.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |nathan at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
  Known to fail|2.95.3 3.0.4 3.2.3 3.3.3|2.95.3 3.0.4 3.2.3 3.3.3
   |3.4.0 4.0.0 |3.4.0 4.0.0 4.1.0
   Last reconfirmed|2005-03-20 14:57:34 |2005-06-06 11:44:53
   date||
Summary|[4.0 only] [DR214] template |[DR214] template argument
   |argument binding differs|binding differs between
   |between member and static   |member and static fumctions
   |fumctions   |
   Target Milestone|4.0.1   |4.1.0


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


[Bug tree-optimization/21847] [4.0/4.1 Regression] misscompiling of the following java code

2005-06-06 Thread amacleod at redhat dot com

--- Additional Comments From amacleod at redhat dot com  2005-06-06 12:07 
---
I agree, you should need 'mark_stmt_necessary (stmt, true)'

Presuming that it bootstraps and passes tests, its approved.

Andrew

-- 


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


[Bug tree-optimization/20742] [4.0 Regression] Hang in tree_ssa_iv_optimize_loop

2005-06-06 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-06 
12:13 ---
Subject: Bug 20742

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-06-06 12:12:53

Modified files:
gcc: ChangeLog params.def tree-chrec.c tree-chrec.h 
 tree-scalar-evolution.c 
gcc/doc: invoke.texi 

Log message:
PR tree-optimization/20742
* params.def (PARAM_SCEV_MAX_EXPR_SIZE): New parameter with
default value 20.
* tree-chrec.c: Depend on params.h.  Replace build with buildN,
and fold build with fold_buildN.
(chrec_fold_plus_1): Fail with a chrec_don_know when the size of
the expression exceeds PARAM_SCEV_MAX_EXPR_SIZE.
(tree_contains_chrecs): Compute an estimation of the size of the
given expression.
* tree-chrec.h (tree_contains_chrecs): Modify its declaration.
(tree_does_not_contain_chrecs): Update the use of tree_contains_chrecs.
* tree-scalar-evolution.c (simple_iv): Ditto.
* doc/invoke.texi (scev-max-expr-size): Documented.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.279&r2=2.7592.2.280
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/params.def.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.54.6.1&r2=1.54.6.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-chrec.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.12.12.2&r2=2.12.12.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-chrec.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.6&r2=2.6.14.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-scalar-evolution.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.17.4.1&r2=2.17.4.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.583.2.18&r2=1.583.2.19



-- 


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


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

2005-06-06 Thread joerg dot richter at pdv-fs dot de

--- Additional Comments From joerg dot richter at pdv-fs dot de  2005-06-06 
12:33 ---
Whoever has the same problem: -fno-working-directory solves it


-- 


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


[Bug c++/15674] [DR214] template argument binding differs between member and static fumctions

2005-06-06 Thread nathan at gcc dot gnu dot org

--- Additional Comments From nathan at gcc dot gnu dot org  2005-06-06 
12:35 ---
Closing this, it is not a bug.  What special cases the structure member example
is that one of the function is a template and the other is not.  Thus overload
resolution picks the non-template (all other things being equal).  Template
specialization ordering never gets a look in.

If you try a completely non-templated example of
  void Foo (int *);
  void Foo (int (&)[5]);
you'll discover overload resolution considers this ambiguous.  The lvalue
array->pointer transform being ignored in ranking the conversion sequences
(13.3.3.2]/3.

The case with both being template instantiations is the same wrt ranking the
conversion sequences, and template partial specialization does not get to
overrule that.

This leaves the members of S, the pointer version
   void S(T *);
although it uses a template parameter, is not a template function in its own
right (it has no template header), so in the context of an instantiation of S,
it is not a template.  The other template
  template  void S(T (&)[n])
though, is a template in its own right, and will defer to the other function in
overload resolution.

If you want to distinguish these functions, make the pointer one a reference to
pointer in both the non-template and template cases,


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||INVALID


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


[Bug libstdc++/21530] libstdc++ not supported on this target

2005-06-06 Thread gcc at mailinator dot com

--- Additional Comments From gcc at mailinator dot com  2005-06-06 12:57 
---
Same problem in 3.4.4

-- 
   What|Removed |Added

Version|3.4.3   |3.4.4


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


[Bug tree-optimization/20742] [4.0 Regression] Hang in tree_ssa_iv_optimize_loop

2005-06-06 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
12:59 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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


[Bug tree-optimization/20803] Pseudo-infinite recursion in ivopts

2005-06-06 Thread pinskia at gcc dot gnu dot org


-- 
Bug 20803 depends on bug 20742, which changed state.

Bug 20742 Summary: [4.0 Regression] Hang in tree_ssa_iv_optimize_loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20742

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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


[Bug tree-optimization/21847] [4.0/4.1 Regression] misscompiling of the following java code

2005-06-06 Thread aph at redhat dot com

--- Additional Comments From aph at redhat dot com  2005-06-06 13:15 ---
With that change, passes bootstrap with c/c++/java, perfect i686-pc-linux-gnu
libgcj test result.

-- 


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


[Bug c++/20637] [3.4/4.0/4.1 regression] Confusing message with different using declarations

2005-06-06 Thread nathan at gcc dot gnu dot org


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |nathan at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-03-25 17:13:29 |2005-06-06 13:22:21
   date||


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


[Bug target/19923] openssl is slower when compiled with gcc 4.0 than 3.3

2005-06-06 Thread giovannibajo at libero dot it

--- Additional Comments From giovannibajo at libero dot it  2005-06-06 
13:33 ---
Uhm, at this point, I don't believe anymore that the loop I posted is the cause 
of the regression. Maybe the regression is somewhere else. I'll investigate.

-- 


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


[Bug c++/21929] New: [4.0/4.1 regression] ICE on invalid template parameter

2005-06-06 Thread reichelt at gcc dot gnu dot org
For the following invalid code snippet I get an ICE since gcc 4.0.0:


template struct A
{
struct B;
};

template<> struct A::B {};


bug.cc:6: error: type/value mismatch at argument 1 in template parameter list
for 'template > struct A'
bug.cc:6: error:   expected a constant of type 'int', got 'void'
bug.cc:6: internal compiler error: in cp_parser_diagnose_invalid_type_name, at
cp/parser.c:2103
Please submit a full bug report, [etc.]

-- 
   Summary: [4.0/4.1 regression] ICE on invalid template parameter
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, monitored
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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


[Bug c++/20637] [3.4/4.0/4.1 regression] Confusing message with different using declarations

2005-06-06 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-06 
14:18 ---
Subject: Bug 20637

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-06-06 14:18:22

Modified files:
gcc/cp : ChangeLog class.c cp-tree.h decl2.c method.c 
 semantics.c 
gcc/testsuite  : ChangeLog 
gcc/testsuite/g++.dg/overload: error1.C 
gcc/testsuite/g++.old-deja/g++.benjamin: warn02.C 
gcc/testsuite/g++.old-deja/g++.brendan: arm2.C 
gcc/testsuite/g++.old-deja/g++.other: redecl2.C redecl4.C 
gcc/testsuite/g++.old-deja/g++.pt: memtemp78.C 
Added files:
gcc/testsuite/g++.dg/inherit: using4.C 

Log message:
cp:
PR c++/20637
* cp-tree.h (add_method): Add using_decl parameter.
* class.c (add_method): Add using_decl parameter.  Adjust error
messages.
(handle_using_decl): Pass the using decl to add_method.
(clone_function_decl): Adjust add_member calls.
* decl2.c (check_classfn): Likewise.
* method.c (lazily_declare_fn): Likewise.
* semantics.c (finish_member_declaration): Likewise.

* method.c (synthesize_method): Use inform, not warning.
testsuite:
PR c++/20637
* g++.dg/inherit/using4.C: New.
* g++.dg/overload/error1.C: Adjust expected errors.
* g++.old-deja/g++.benjamin/warn02.C: Likewise.
* g++.old-deja/g++.brendan/arm2.C: Likewise.
* g++.old-deja/g++.other/redecl2.C: Likewise.
* g++.old-deja/g++.other/redecl4.C: Likewise.
* g++.old-deja/g++.pt/memtemp78.C: Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4776&r2=1.4777
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gcc&r1=1.718&r2=1.719
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.1141&r2=1.1142
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.784&r2=1.785
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/method.c.diff?cvsroot=gcc&r1=1.332&r2=1.333
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcc&r1=1.473&r2=1.474
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5601&r2=1.5602
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/using4.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/overload/error1.C.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.benjamin/warn02.C.diff?cvsroot=gcc&r1=1.4&r2=1.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.brendan/arm2.C.diff?cvsroot=gcc&r1=1.3&r2=1.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.other/redecl2.C.diff?cvsroot=gcc&r1=1.3&r2=1.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.other/redecl4.C.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.pt/memtemp78.C.diff?cvsroot=gcc&r1=1.3&r2=1.4



-- 


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


[Bug c++/21929] [4.0/4.1 regression] ICE on invalid template parameter

2005-06-06 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
14:20 ---
Confirmed, started to fail between "3.5.0 20040909" and "4.0.0 20050225".

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-06 14:20:38
   date||
   Target Milestone|--- |4.0.1


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


[Bug c++/21903] [3.4/4.0/4.1 regression] Default argument of template function causes a compile-time error

2005-06-06 Thread bangerth at dealii dot org

--- Additional Comments From bangerth at dealii dot org  2005-06-06 14:27 
---
Sure it is a regression: gcc3.3.x compiles it just fine, and so does 3.2.x. 
gcc2.95 ICES, and from 3.4 onward we have the present error. 
 
W. 

-- 
   What|Removed |Added

 CC||bangerth at dealii dot org
   Keywords||rejects-valid
  Known to work||3.2.3 3.3.5
Summary|Default argument of template|[3.4/4.0/4.1 regression]
   |function causes a compile-  |Default argument of template
   |time error  |function causes a compile-
   ||time error
   Target Milestone|--- |3.4.5


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


[Bug c++/21903] [3.4/4.0/4.1 regression] Default argument of template function causes a compile-time error

2005-06-06 Thread bangerth at dealii dot org

--- Additional Comments From bangerth at dealii dot org  2005-06-06 14:28 
---
My last message refers to the code snippet in comment #4. 
 
W. 

-- 


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


[Bug c++/21930] New: [4.1 regression] pretty printer confusion

2005-06-06 Thread reichelt at gcc dot gnu dot org
On mainline I get a hosed error message for the following invalid code
snippet:


template struct A {};

template void foo(const A &a) { -A(a); }

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


The error message reads:

  bug.cc: In function 'void foo(const A&) [with int N = 0]':
  bug.cc:7:   instantiated from here
  bug.cc:3: error: no match for 'operator-' in '-((const A<0>&)#'convert_expr'
not supported by dump_expr#)'

With gcc 4.0.0 I get the following message instead:

  bug.cc: In function 'void foo(const A&) [with int N = 0]':
  bug.cc:7:   instantiated from here
  bug.cc:3: error: no match for 'operator-' in '-((const A<0>&)(+ a))'

I don't know why the plus sign appears before "a", but this suggests that
the regression is related to the recent introduction of UNARY_PLUS_EXPR:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02580.html

-- 
   Summary: [4.1 regression] pretty printer confusion
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: diagnostic, monitored
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,giovannibajo at gcc dot
gnu dot org,roger at eyesopen dot com


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


[Bug c++/21930] [4.1 regression] pretty printer confusion

2005-06-06 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
14:37 ---
Confirmed, 

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-06 14:37:10
   date||
   Target Milestone|--- |4.1.0


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


[Bug target/19923] openssl is slower when compiled with gcc 4.0 than 3.3

2005-06-06 Thread giovannibajo at libero dot it

--- Additional Comments From giovannibajo at libero dot it  2005-06-06 
14:40 ---
Looks like the culrpit is this:

=
static unsigned int S[256];
unsigned
md2_block (unsigned int *sp1, unsigned int *sp2, const unsigned char *d)
{
register unsigned int t;
register int i, j;
static unsigned int state[48];

j = sp2[16 - 1];
for (i = 0; i < 16; i++)
{
state[i] = sp1[i];
state[i + 16] = t = d[i];
state[i + 32] = (t ^ sp1[i]);
j = sp2[i] ^= S[t ^ j];
}
}
=


gcc 3.4.3 -fPIC -O2:
===
.L5:
movl8(%ebp), %esi
movl(%esi,%ecx,4), %eax
movl%eax, [EMAIL PROTECTED](%ebx,%ecx,4)
movl16(%ebp), %edx
movzbl  (%edx,%ecx), %eax
movl%eax, [EMAIL PROTECTED](%ebx,%ecx,4)
movl(%esi,%ecx,4), %edx
xorl%eax, %edx
movl-16(%ebp), %esi
xorl-20(%ebp), %eax
movl%edx, [EMAIL PROTECTED](%ebx,%ecx,4)
movl(%esi,%eax,4), %eax
xorl(%edi,%ecx,4), %eax
movl%eax, (%edi,%ecx,4)
incl%ecx
cmpl$15, %ecx
movl%eax, -20(%ebp)
jle .L5
===



gcc 4.1.0 20050529 -fPIC -O2:
===
.L2:
movl8(%ebp), %eax
leal0(,%edi,4), %ecx
movl%ecx, -28(%ebp)
addl%ecx, %eax
movl16(%ebp), %ecx
movl%eax, %edx
movl%eax, -24(%ebp)
movl-4(%eax), %eax
movl%eax, (%esi)
movzbl  -1(%ecx,%edi), %eax
incl%edi
movl%eax, 64(%esi)
movl-4(%edx), %ecx
movl12(%ebp), %edx
xorl%eax, %ecx
movl%ecx, 128(%esi)
movl-28(%ebp), %ecx
addl$4, %esi
addl%edx, %ecx
movl-16(%ebp), %edx
xorl%edx, %eax
movl-20(%ebp), %edx
movl(%edx,%eax,4), %eax
movl-4(%ecx), %edx
xorl%edx, %eax
cmpl$17, %edi
movl%eax, -4(%ecx)
movl%eax, -16(%ebp)
jne .L2
===


-- 


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


[Bug c++/21930] [4.1 regression] pretty printer confusion

2005-06-06 Thread giovannibajo at libero dot it

--- Additional Comments From giovannibajo at libero dot it  2005-06-06 
14:47 ---
Ot looks like dump_expr must support CONVERT_EXPRs, and just strip them. 
Before, there was no way to discern between unary plus and a real conversion, 
but now they are different codes. Not all occurrences of CONVERT_EXPRs in 
dump_expr where unary pluses, even if we were treating them so.

-- 


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


Re: [Bug c++/21930] New: [4.1 regression] pretty printer confusion

2005-06-06 Thread Gabriel Dos Reis
"reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| The error message reads:
| 
|   bug.cc: In function 'void foo(const A&) [with int N = 0]':
|   bug.cc:7:   instantiated from here
|   bug.cc:3: error: no match for 'operator-' in '-((const A<0>&)#'convert_expr'
| not supported by dump_expr#)'
| 
| With gcc 4.0.0 I get the following message instead:
| 
|   bug.cc: In function 'void foo(const A&) [with int N = 0]':
|   bug.cc:7:   instantiated from here
|   bug.cc:3: error: no match for 'operator-' in '-((const A<0>&)(+ a))'
| 
| I don't know why the plus sign appears before "a", 

The plus sign is a bogosity in the tree representation, not correctly
understaood by the pretty-printer, which cannot differentiate between
conversion from reference to pointer, lvalue->rvalue conversion and
real unary plus. They usually appear under the cover of CONVERT_EXPR.

| but this suggests that
| the regression is related to the recent introduction of UNARY_PLUS_EXPR:
| http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02580.html

Indeed.

-- Gaby


[Bug c++/21930] [4.1 regression] pretty printer confusion

2005-06-06 Thread gdr at integrable-solutions dot net

--- Additional Comments From gdr at integrable-solutions dot net  
2005-06-06 14:50 ---
Subject: Re:  New: [4.1 regression] pretty printer confusion

"reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| The error message reads:
| 
|   bug.cc: In function 'void foo(const A&) [with int N = 0]':
|   bug.cc:7:   instantiated from here
|   bug.cc:3: error: no match for 'operator-' in '-((const A<0>&)#'convert_expr'
| not supported by dump_expr#)'
| 
| With gcc 4.0.0 I get the following message instead:
| 
|   bug.cc: In function 'void foo(const A&) [with int N = 0]':
|   bug.cc:7:   instantiated from here
|   bug.cc:3: error: no match for 'operator-' in '-((const A<0>&)(+ a))'
| 
| I don't know why the plus sign appears before "a", 

The plus sign is a bogosity in the tree representation, not correctly
understaood by the pretty-printer, which cannot differentiate between
conversion from reference to pointer, lvalue->rvalue conversion and
real unary plus. They usually appear under the cover of CONVERT_EXPR.

| but this suggests that
| the regression is related to the recent introduction of UNARY_PLUS_EXPR:
| http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02580.html

Indeed.

-- Gaby


-- 


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


[Bug middle-end/21916] [4.1 Regression] ICE: segmentation fault in stage3

2005-06-06 Thread dave at hiauly1 dot hia dot nrc dot ca

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2005-06-06 14:51 ---
Subject: Re:  [4.1 Regression] ICE: segmentation fault in stage3

> I will need someone with accesss to hppa to binary search the miscompiled file
> from stage2 and send me a .i file.
> 
> Either that or give me access to an hppa machine.  There is nothing in the PR
> log that gives any clue at what may be going on.

On hppa-unknown-linux-gnu, there are about a dozen files which differ
between stage2 and stage3.  I've enclosed the .i for tree-sra.c since
it's relatively small.  I have also attatched a diff of the assembler
output from stages 2 and 3.

Dave

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2005-06-06 14:51 ---
Created an attachment (id=9036)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9036&action=view)

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2005-06-06 14:51 ---
Created an attachment (id=9037)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9037&action=view)


-- 


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


[Bug target/19923] openssl is slower when compiled with gcc 4.0 than 3.3

2005-06-06 Thread rakdver at atrey dot karlin dot mff dot cuni dot cz

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2005-06-06 15:00 ---
Subject: Re:  openssl is slower when compiled with gcc 4.0 than 3.3

> Looks like the culrpit is this:
> 
> =
> static unsigned int S[256];
> unsigned
> md2_block (unsigned int *sp1, unsigned int *sp2, const unsigned char *d)
> {
>   register unsigned int t;
>   register int i, j;
>   static unsigned int state[48];
> 
>   j = sp2[16 - 1];
>   for (i = 0; i < 16; i++)
>   {
>   state[i] = sp1[i];
>   state[i + 16] = t = d[i];
>   state[i + 32] = (t ^ sp1[i]);
>   j = sp2[i] ^= S[t ^ j];
>   }
> }
> =

with the TARGET_MEM_REFs patch the result is much better.  At
least we avoid the multiplication by 4

>   leal0(,%edi,4), %ecx

and other results of the DOM missoptimization of addressing modes, that was
one of the main motivations for TARGET_MEM_REFs.

We still use one more iv than in the 3.4 case, and in result we need one
more register.

.L2:
movl8(%ebp), %edi
movl-4(%edi,%ecx,4), %eax
movl%eax, (%esi)
movl16(%ebp), %edx
movzbl  -1(%ecx,%edx), %eax
movl%eax, 64(%esi)
movl-4(%edi,%ecx,4), %edx
xorl%eax, %edx
movl%edx, 128(%esi)
xorl-20(%ebp), %eax
movl-16(%ebp), %edi
movl(%edi,%eax,4), %eax
movl12(%ebp), %edx
xorl-4(%edx,%ecx,4), %eax
movl%eax, -4(%edx,%ecx,4)
movl%eax, -20(%ebp)
incl%ecx
addl$4, %esi
cmpl$17, %ecx
jne .L2


-- 


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


[Bug middle-end/21916] [4.1 Regression] ICE: segmentation fault in stage3

2005-06-06 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
15:00 ---
Can you try -fdump-tree-all and see if any of the dumps there differ?

-- 


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


[Bug middle-end/7776] const char* p = "foo"; if (p == "foo") ... is compiled without warning!

2005-06-06 Thread roger at eyesopen dot com

--- Additional Comments From roger at eyesopen dot com  2005-06-06 15:06 
---
C front-end patch here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00369.html


-- 
   What|Removed |Added

   Keywords||patch


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


[Bug tree-optimization/21921] [4.1 Regression] internal compiler error: in tsi_link_before, at tree-iterator.c:113

2005-06-06 Thread bonzini at gcc dot gnu dot org

--- Additional Comments From bonzini at gcc dot gnu dot org  2005-06-06 
15:08 ---
The patch fixes the bug because in the poster's test case we have to insert a
reciprocal computation in an empty basic block.

-- 


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


[Bug target/21642] wrong code with -O2

2005-06-06 Thread dje at gcc dot gnu dot org

--- Additional Comments From dje at gcc dot gnu dot org  2005-06-06 15:17 
---
This appears to be related to strength reduction.

-O2 -fno-strength-reduce succeeds
-O1 -fstrength-reduce fails.

The bug is not present in GCC 4.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||wrong-code
  Known to fail||3.4.3 3.4.4
  Known to work||4.0.0 4.0.1 4.1.0
   Last reconfirmed|-00-00 00:00:00 |2005-06-06 15:17:14
   date||


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


[Bug target/21642] [3.4 Regression] wrong code with -O2

2005-06-06 Thread pinskia at gcc dot gnu dot org


-- 
   What|Removed |Added

Summary|wrong code with -O2 |[3.4 Regression] wrong code
   ||with -O2
   Target Milestone|--- |3.4.5


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


[Bug middle-end/19699] [4.0/4.1 Regression] warning about not returning from end of a non-void function because of dead code

2005-06-06 Thread veksler at il dot ibm dot com

--- Additional Comments From veksler at il dot ibm dot com  2005-06-06 
15:20 ---
(In reply to comment #13)
> (In reply to comment #12)
> > Will the patch be applied to 4.0 branch too? 
> No because it is too big in that it also changes the inliner to be a CFG aware
inliner.

In that case, it should not be marked "RESOLVED" for gcc-4.0 until:
  1.  either it is marked WONTFIX for gcc-4.0
  2.  or a new patch is written specifically for the gcc-4.0 branch.

>From comment #2 I understand that option 2 is out of the question.
Does it mean that "gcc-4.0 is dead, long live gcc-4.1" ?

This is how I came to this "conclusion":
There are new (not very rare) regressions in gcc-4.0 that will never
be fixed. These regressions will be fixed only in gcc-4.1.
As a result, it sounds like gcc-4.0 is much less maintained than
any other (active) branch (or trunk) at the moment. This is
very different from any of the previous releases of GCC (up to
gcc-2.95)

If this is true, then gcc-4.1 schedule should be changed
to reflect that.

-- 


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


[Bug tree-optimization/21923] [4.1 Regression] Ada compiler fails to build on gcc 4.1

2005-06-06 Thread schwab at suse dot de

--- Additional Comments From schwab at suse dot de  2005-06-06 15:44 ---
Testresults with the patch from comment #10: 
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00361.html 

-- 
   What|Removed |Added

 CC||schwab at suse dot de


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


[Bug fortran/21931] New: problem with fugly-logint flag and evaluating if statements

2005-06-06 Thread mark_l_hansen at yahoo dot com
The -fugly-logint flag allows FORTRAN to treat integers as logicals and vice 
versa.  The following example program shows some inconsistencies in how the if 
statements evaluate.  If you change VAR1 to 3,2,1,0,-1 and view the results you 
will see some interesting things.  The best way to see the problem is to view 
the output.  Thanks.  I would appreciate an email if anyone has a solution/fix 
for the problem.  Thanks.

Below is the code

Makefile:
all:
g77 -c -g -ff90 -ff90-intrinsics-delete -fugly-logint -fno-automatic 
function.for
g++ -c -g main.cpp
g++  -o program main.o function.o -lg2c 

main.cpp:
#include 
#include 
using namespace std;

extern "C" {
void func_();
}

int main()
{
func_();
return 0;
}
function.for:
  SUBROUTINE FUNC
  
  IMPLICIT NONE
*
*  LOCAL DECLARATIONS
*
  INTEGER VAR1, VAR2

  LOGICAL LVAR1, LVAR2, LOG1, LOG2

  EQUIVALENCE
 .  (VAR1, LVAR1)
 ., (VAR2, LVAR2)

*C change VAR1 to 2,-1,0,3 and view results 
  VAR1 =  3;
  VAR2 =  -1;
  LOG1 = .true.
  LOG2 = .true.
  
  WRITE (*,*) "LOG1  = ", LOG1
  WRITE (*,*) "LOG2  = ", LOG2
  WRITE (*,*) "VAR1  = ", VAR1
  WRITE (*,*) "VAR2  = ", VAR2
  WRITE (*,*) "LVAR1 = ", LVAR1
  WRITE (*,*) "LVAR2 = ", LVAR2

  IF(.NOT.((LVAR1 .AND. LVAR2) .AND. (LOG1 .AND. LOG2))) THEN
WRITE (*,*) "LOGICAL TRUE with LOG2" 
  ELSE
WRITE (*,*) "LOGICAL FALSE with LOG2" 
  ENDIF
  IF(.NOT.(LVAR1 .AND. LVAR2 .AND. LOG1)) THEN
WRITE (*,*) "LOGICAL TRUE with LOG1" 
  ELSE
WRITE (*,*) "LOGICAL FALSE with LOG1" 
  ENDIF
  IF(.NOT.(LVAR1 .AND. LVAR2)) THEN
WRITE (*,*) "LOGICAL TRUE" 
  ELSE
WRITE (*,*) "LOGICAL FALSE" 
  ENDIF
*--  
  IF(.NOT.(VAR1 .AND. VAR2 .AND. LOG1)) THEN
WRITE (*,*) "BYTE TRUE with LOG1" 
  ELSE
WRITE (*,*) "BYTE FALSE with LOG1" 
  ENDIF
  IF(.NOT.(VAR1 .AND. VAR2)) THEN
WRITE (*,*) "BYTE TRUE" 
  ELSE
WRITE (*,*) "BYTE FALSE" 
  ENDIF
 
  END

-- 
   Summary: problem with fugly-logint flag and evaluating if
statements
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark_l_hansen at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org


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


[Bug middle-end/7776] const char* p = "foo"; if (p == "foo") ... is compiled without warning!

2005-06-06 Thread trt at acm dot org

--- Additional Comments From trt at acm dot org  2005-06-06 15:48 ---
I recommend a version with fewer false positives.
I've been using a warning like this for years, with zero false positives.
The current gcc-4-ified version is:

-   /* check for comparing string constant with anything besides simple zero */
-   if (TREE_CODE_CLASS (code) == tcc_comparison && extra_warnings
-   && (code1 == STRING_CST) != (code2 == STRING_CST)
-   && !integer_zerop (arg1.value) && !integer_zerop (arg2.value))
- warning (0, "comparison of pointer with string literal");

An older suggestion is http://gcc.gnu.org/ml/gcc-patches/1999-10n/msg00548.html

-- 


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


[Bug c++/21932] New: -fno-unit-at-a-time causes ICE in gcc-3.4.4 on solaris2.8

2005-06-06 Thread magerman at rentec dot com
The following sequence produces an ICE in gcc-3.4.4:

$ cat > foo.C < search starts here:
 
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../include/c++/3.4.4
 
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../include/c++/3.4.4/sparc-sun-solaris2.8
 
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../include/c++/3.4.4/backward
 /usr/local/include
 /work/external/wwc/prgcc/include
 /work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/include
 /usr/include
End of search list.
 /work/external/wwc/prgcc/libexec/gcc/sparc-sun-solaris2.8/3.4.4/cc1plus
-fpreprocessed foo.ii -quiet -dumpbase foo.C -mcpu=v7 -auxbase foo -g -O3
-version -fno-unit-at-a-time -o foo.s
GNU C++ version 3.4.4 (sparc-sun-solaris2.8)
compiled by GNU C version 3.4.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
foo.C: In function `void N::a()':
foo.C:5: internal compiler error: in gen_subprogram_die, at dwarf2out.c:10854
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$ cat foo.s
.file   "foo.C"
.section".debug_abbrev"
.LLdebug_abbrev0:
.section".debug_info"
.LLdebug_info0:
.section".debug_line"
.LLdebug_line0:
.section".text"
.LLtext0:
.align 4
.global _ZN1N1aEv
.type   _ZN1N1aEv, #function
.proc   020
_ZN1N1aEv:
.LLFB2:
.LLM1:
!#PROLOGUE# 0
!#PROLOGUE# 1
.LLBB2:
.LLBB3:
or  %o7, %g0, %g1
call_ZN1N1bEv, 0
 or %g1, %g0, %o7
.LLBE3:
.LLBE2:
nop
.LLFE2:
.size   _ZN1N1aEv, .-_ZN1N1aEv

Let me know if you need more information.

-- David Magerman
[EMAIL PROTECTED]

-- 
   Summary: -fno-unit-at-a-time causes ICE in gcc-3.4.4 on
solaris2.8
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: magerman at rentec dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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


[Bug fortran/21931] problem with fugly-logint flag and evaluating if statements

2005-06-06 Thread mark_l_hansen at yahoo dot com

--- Additional Comments From mark_l_hansen at yahoo dot com  2005-06-06 
15:51 ---
Created an attachment (id=9038)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9038&action=view)
Test program


-- 


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


[Bug target/21041] [4.0 Regression] ICE: output_operand: Cannot decompose address

2005-06-06 Thread uweigand at gcc dot gnu dot org

--- Additional Comments From uweigand at gcc dot gnu dot org  2005-06-06 
15:57 ---
Here's another reduced test case, this time without
uninitialized variables:

// ICEs with -O2 -fPIC

struct args
{
  short int matrix[8][8];
  char **current;
};

int test (struct args *args, char *init, int a, int b)
{
  int i, j, k;

  if (!args || a > b || a < 0)
return -1;

  for (i = 0; i < 2; i++)
{
  char *dest = *args->current;
  char *p = dest;

  for (j = 0; j < 8; j++)
*p++ = *init++;

  for (k = 0; k < 8; k++)
{
  short int *blockvals = &args->matrix[k][0];
  dest[0] += blockvals[0];
  dest[1] += blockvals[1];
  dest[2] += blockvals[2];
  dest[3] += blockvals[3];
  dest[4] += blockvals[4];
  dest[5] += blockvals[5];
  dest[6] += blockvals[6];
  dest[7] += blockvals[7];
   }
}

  return 1;
}

-- 


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


[Bug debug/21932] [3.4 Regression] -fno-unit-at-a-time causes ICE in gcc-3.4.4 on solaris2.8

2005-06-06 Thread pinskia at gcc dot gnu dot org


-- 
   What|Removed |Added

  Component|c++ |debug
   Keywords||ice-on-valid-code
Summary|-fno-unit-at-a-time causes  |[3.4 Regression] -fno-unit-
   |ICE in gcc-3.4.4 on |at-a-time causes ICE in gcc-
   |solaris2.8  |3.4.4 on solaris2.8


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


[Bug debug/21932] [3.4 Regression] -fno-unit-at-a-time causes ICE in gcc-3.4.4 on solaris2.8

2005-06-06 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
16:03 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|sparc-sun-solaris2.8|
   GCC host triplet|sparc-sun-solaris2.8|
 GCC target triplet|sparc-sun-solaris2.8|dwarf2
  Known to fail||3.4.0
  Known to work||3.3.3 4.0.0 4.1.0
   Last reconfirmed|-00-00 00:00:00 |2005-06-06 16:03:37
   date||
   Target Milestone|--- |3.4.5


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


[Bug middle-end/19699] [4.0/4.1 Regression] warning about not returning from end of a non-void function because of dead code

2005-06-06 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
16:07 ---
(In reply to comment #14)
> This is how I came to this "conclusion":
> There are new (not very rare) regressions in gcc-4.0 that will never
> be fixed. These regressions will be fixed only in gcc-4.1.
> As a result, it sounds like gcc-4.0 is much less maintained than
> any other (active) branch (or trunk) at the moment. This is
> very different from any of the previous releases of GCC (up to
> gcc-2.95)

This is only a diagnostic regression.  In fact before this patch which added 
the warning in the inliner, 
we had a diagnostic regression.  So it is either false postive or false 
negatives.  Take your pick, I rather 
have the false postives as it means you have to look at your code to double 
check, if we don't get a 
diagnostic at all, the person will complain when we get it right again the next 
major release.  Again take 
your pick.

-- 


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


[Bug c++/21903] [3.4/4.0/4.1 regression] Default argument of template function causes a compile-time error

2005-06-06 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-06 
17:29 ---
Subject: Bug 21903

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-06-06 17:29:41

Modified files:
gcc/cp : ChangeLog cp-tree.def parser.c pt.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/parse: defarg9.C 

Log message:
cp:
PR 21903
* cp-tree.def (DEFAULT_ARG): Document TREE_CHAIN use.
* parser.c (cp_parser_late_parsing_default_args): Propagate parsed
argument to any early instantiations.
* pt.c (tsubst_arg_types): Chain early instantiation of default arg.
testsuite:
PR 21903
* g++.dg/parse/defarg9.C: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4777&r2=1.4778
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.def.diff?cvsroot=gcc&r1=1.102&r2=1.103
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.336&r2=1.337
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.1001&r2=1.1002
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5602&r2=1.5603
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/defarg9.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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


[Bug c++/21903] [3.4/4.0/4.1 regression] Default argument of template function causes a compile-time error

2005-06-06 Thread nathan at gcc dot gnu dot org

--- Additional Comments From nathan at gcc dot gnu dot org  2005-06-06 
17:30 ---
Fixed mainline
2005-06-06  Nathan Sidwell  <[EMAIL PROTECTED]>

PR 21903
* cp-tree.def (DEFAULT_ARG): Document TREE_CHAIN use.
* parser.c (cp_parser_late_parsing_default_args): Propagate parsed
argument to any early instantiations.
* pt.c (tsubst_arg_types): Chain early instantiation of default arg.

2005-06-06  Nathan Sidwell  <[EMAIL PROTECTED]>

PR 21903
* g++.dg/parse/defarg9.C: New.


-- 


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


[Bug middle-end/21916] [4.1 Regression] ICE: segmentation fault in stage3

2005-06-06 Thread pluto at agmk dot net

--- Additional Comments From pluto at agmk dot net  2005-06-06 17:53 ---
(In reply to comment #7)  
 
> On hppa-unknown-linux-gnu, there are about a dozen files which differ  
> between stage2 and stage3. (...) 
  
Could You also check the testcase from PR20586? (-funroll-loops issue) 
 

-- 


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


[Bug c/21911] named parameter mistakenly identified as sentinel

2005-06-06 Thread ghazi at gcc dot gnu dot org

--- Additional Comments From ghazi at gcc dot gnu dot org  2005-06-06 18:41 
---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00507.html


-- 


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


[Bug debug/21932] [3.4 Regression] -O3 -fno-unit-at-a-time causes ICE

2005-06-06 Thread ebotcazou at gcc dot gnu dot org

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-06-06 
18:47 ---
To be more explicit: it ICEs on x86-64 too.


-- 
   What|Removed |Added

  Known to fail|3.4.0   |3.4.0 3.4.4
   Last reconfirmed|2005-06-06 16:03:37 |2005-06-06 18:47:45
   date||
Summary|[3.4 Regression] -fno-unit- |[3.4 Regression] -O3 -fno-
   |at-a-time causes ICE in gcc-|unit-at-a-time causes ICE
   |3.4.4 on solaris2.8 |


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


[Bug libfortran/21926] matmul does not deal with non-packed result

2005-06-06 Thread tkoenig at gcc dot gnu dot org


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-06 19:13:59
   date||


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


[Bug tree-optimization/21933] New: [4.1 regression] ICE with -ftree-vectorize

2005-06-06 Thread reichelt at gcc dot gnu dot org
Compiling the following code snippet with today's mainline
(g++ -O -march=pentium4 -ftree-vectorize) I get an ICE:

==
struct A
{
int a[4];
A& foo() { for (int i=0; i<4; ++i) a[i]=0; return *this; }
int bar();
};

struct B
{
A* p;
~B() { ++p; }
};

struct C : B {};

struct X { int i; };

struct Y : virtual X
{
Y& operator<<(X) { ++i; return *this; }
};

void baz()
{
C c0, c1, c2, c3;
A(*c0.p).foo().bar();

X x;
Y() << x << x << x << x;
}
==

bug.cc: In function 'void baz()':
bug.cc:23: internal compiler error: tree check: expected ssa_name, have var_decl
in verify_ssa, at tree-ssa.c:750
Please submit a full bug report, [etc.]

-- 
   Summary: [4.1 regression] ICE with -ftree-vectorize
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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


[Bug middle-end/21916] [4.1 Regression] ICE: segmentation fault in stage3

2005-06-06 Thread dave at hiauly1 dot hia dot nrc dot ca

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2005-06-06 19:24 ---
Subject: Re:  [4.1 Regression] ICE: segmentation fault in stage3

On Mon, Jun 06, 2005 at 03:00:57PM -, pinskia at gcc dot gnu dot org wrote:
> 
> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
> 15:00 ---
> Can you try -fdump-tree-all and see if any of the dumps there differ?

tree-sra.c.t08.expand differs.  I enclosed the stage2 output and the diff.

Dave

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2005-06-06 19:24 ---
Created an attachment (id=9039)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9039&action=view)

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2005-06-06 19:24 ---
Created an attachment (id=9040)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9040&action=view)


-- 


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


[Bug middle-end/21897] [4.1 Regression] Segementation fault in fold_ternary

2005-06-06 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-06 
19:26 ---
Subject: Bug 21897

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-06-06 19:26:10

Modified files:
gcc: ChangeLog fold-const.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/execute: 20050604-1.c 

Log message:
* fold-const.c (operand_equal_p): Don't return 1, if element
chains for 2 VECTOR_CSTs are not the same length.

PR regression/21897
* fold-const.c (fold_ternary) : Don't crash if
not all VECTOR_CST elements are given.

* gcc.c-torture/execute/20050604-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9055&r2=2.9056
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.591&r2=1.592
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5603&r2=1.5604
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050604-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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


[Bug middle-end/21916] [4.1 Regression] ICE: segmentation fault in stage3

2005-06-06 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
19:31 ---
I think this is the same as:
.

-- 
   What|Removed |Added

 CC||ebotcazou at libertysurf dot
   ||fr


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


[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails

2005-06-06 Thread grondin at fr dot fm

--- Additional Comments From grondin at fr dot fm  2005-06-06 19:35 ---
I'm used ./configure --prefix=/usr

I've the make error :
(...)
updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
config.status: executing default-1 commands
./config.status: line 910: ./../../config-ml.in: No such file or directory
make: *** [configure-zlib] Erreur 1




-- 
   What|Removed |Added

 CC||grondin at fr dot fm


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


[Bug fortran/21184] fortran built and tested despite target-libgfortran disabled

2005-06-06 Thread hp at gcc dot gnu dot org

--- Additional Comments From hp at gcc dot gnu dot org  2005-06-06 20:00 
---
Patch rejected, immediate interest lost.

-- 
   What|Removed |Added

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


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


[Bug c++/21934] New: Bison files are missing or misnamed under MINGW

2005-06-06 Thread dcorbit at connx dot com
The product area is a wild guess.  Probably, you should pay no attention to it.

Here is the output of make, after the failure has occurred (to shorten the 
output size):
==
$ make
make[1]: Entering directory `/mingw/gcc-4.1-20050604/host-i686-pc-mingw32/zlib'
true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2" "CXXFLAGS=-g -
O2" "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=-O2 -g -O2" "INSTALL=/bin/install -
c" "INSTALL_DATA=/bin/install -c -m 644" "INSTALL_PROGRAM=/bin/install -
c" "INSTALL_SCRIPT=/bin/install -c" "LDFLAGS=" "LIBCFLAGS=-g -
O2" "LIBCFLAGS_FOR_TARGET=-O2 -g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-
size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" 
"RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/usr/local" "infodir=/usr/local/i
nfo" "libdir=/usr/local/lib" "prefix=/usr/local" "tooldir=/usr/local/i686-pc-
mingw32" "AR=ar" "AS=as" "CC=gcc" "CXX=c++" "LD=ld" "LIBCFLAGS=-g -
O2" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all multi-do # make
make[1]: Leaving directory `/mingw/gcc-4.1-20050604/host-i686-pc-mingw32/zlib'
make[1]: Entering directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/libiberty'
make[2]: Entering directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/libiberty/testsuite'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/libiberty/testsuite'
make[1]: Leaving directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/libiberty'
make[1]: Entering directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/fastjar'
make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2" "CXXFLAGS=-g -
O2" "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=-O2 -g -O2" "INSTALL=/bin/install -
c" "INSTALL_DATA=/bin/install -c -m 644" "INSTALL_PROGRAM=/bin/install -
c" "INSTALL_SCRIPT=/bin/install -c" "JC1FLAGS=" "LDFLAGS=" "LIBCFLAGS=-g -
O2" "LIBCFLAGS_FOR_TARGET=-O2 -g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-
size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "exec_prefix=/us
r/local" "infodir=/usr/local/info" "libdir=/usr/local/lib" "prefix=/usr/local" "
AR=ar" "AS=as" "CC=gcc" "CXX=c++" "LD=ld" "LIBCFLAGS=-g -
O2" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" all-am
make[2]: Entering directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/fastjar'
perl ../.././fastjar/../contrib/texi2pod.pl -D 
fastjar ../.././fastjar/fastjar.texi > fastjar.pod
(pod2man --center="GNU" --release="gcc-4.1.0" --section=1 fastjar.pod > 
fastjar.1.T$$ && \
mv -f fastjar.1.T$$ fastjar.1) || \
(rm -f fastjar.1.T$$ && exit 1)
/bin/sh: pod2man: command not found
make[2]: [fastjar.1] Error 1 (ignored)
perl ../.././fastjar/../contrib/texi2pod.pl -D 
grepjar ../.././fastjar/fastjar.texi > grepjar.pod
(pod2man --center="GNU" --release="gcc-4.1.0" --section=1 grepjar.pod > 
grepjar.1.T$$ && \
mv -f grepjar.1.T$$ grepjar.1) || \
(rm -f grepjar.1.T$$ && exit 1)
/bin/sh: pod2man: command not found
make[2]: [grepjar.1] Error 1 (ignored)
rm fastjar.pod grepjar.pod
make[2]: Leaving directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/fastjar'
make[1]: Leaving directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/fastjar'
make[1]: Entering directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/fixincludes'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/fixincludes'
make[1]: Entering directory `/mingw/gcc-4.1-20050604/host-i686-pc-mingw32/intl'
rm -f stamp-h1
/bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[1]: Leaving directory `/mingw/gcc-4.1-20050604/host-i686-pc-mingw32/intl'
make[1]: Entering directory `/mingw/gcc-4.1-20050604/build-i686-pc-
mingw32/libiberty'
make[2]: Entering directory `/mingw/gcc-4.1-20050604/build-i686-pc-
mingw32/libiberty/testsuite'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/mingw/gcc-4.1-20050604/build-i686-pc-
mingw32/libiberty/testsuite'
make[1]: Leaving directory `/mingw/gcc-4.1-20050604/build-i686-pc-
mingw32/libiberty'
make[1]: Entering directory `/mingw/gcc-4.1-20050604/build-i686-pc-
mingw32/fixincludes'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/mingw/gcc-4.1-20050604/build-i686-pc-
mingw32/fixincludes'
make[1]: Entering directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/libcpp'
test -d po || mkdir po
: --statistics -o po/be.gmo ../.././libcpp/po/be.po
test -d po || mkdir po
: --statistics -o po/ca.gmo ../.././libcpp/po/ca.po
test -d po || mkdir po
: --statistics -o po/da.gmo ../.././libcpp/po/da.po
test -d po || mkdir po
: --statistics -o po/de.gmo ../.././libcpp/po/de.po
test -d po || mkdir po
: --statistics -o po/el.gmo ../.././libcpp/po/el.po
test -d po || mkdir po
: --statistics -o po/es.gmo ../.././libcpp/po/es.po
test -d po || mkdir po
: --s

[Bug bootstrap/21934] Bison files are missing or misnamed under MINGW

2005-06-06 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
20:08 ---
Do you have bison installed, if not you need it to compile a snapshot?

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING
  Component|c++ |bootstrap


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


[Bug bootstrap/21934] Bison files are missing or misnamed under MINGW

2005-06-06 Thread dcorbit at connx dot com

--- Additional Comments From dcorbit at connx dot com  2005-06-06 20:09 
---
Subject: RE:  Bison files are missing or misnamed under MINGW

Perhaps this version is not new enough:

[EMAIL PROTECTED] /mingw/gcc-4.1-20050604
$ bison --version
bison++ Version 1.21-7, adapted from GNU bison by [EMAIL PROTECTED]

[EMAIL PROTECTED] /mingw/gcc-4.1-20050604

> -Original Message-
> From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 06, 2005 1:08 PM
> To: Dann Corbit
> Subject: [Bug bootstrap/21934] Bison files are missing or misnamed
under
> MINGW
> 
> 
> --- Additional Comments From pinskia at gcc dot gnu dot org
2005-06-
> 06 20:08 ---
> Do you have bison installed, if not you need it to compile a snapshot?
> 
> --
>What|Removed |Added
>

--
> --
>  Status|UNCONFIRMED |WAITING
>   Component|c++ |bootstrap
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21934
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.


-- 


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


[Bug bootstrap/21934] Bison files are missing or misnamed under MINGW

2005-06-06 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
20:13 ---
Yep that is it:
:
GNU Bison version 1.28 (or later)
Berkeley yacc (byacc) is also reported to work other than for java.

Necessary when modifying *.y files.

Necessary to build GCC during development because the generated output files 
are not included in the 
CVS repository. They are included in releases. 


Not a bug.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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


[Bug libgcj/21935] New: All libjava execution tests fail on IRIX 6

2005-06-06 Thread gcc-bugzilla at gcc dot gnu dot org

All libjava execution tests fail on IRIX 6 like this:

% LD_LIBRARYN32_PATH=../../../gcc:../.libs ./PR9577
3709255:./PR9577: rld: Error: unresolvable symbol in ../.libs/libgcj.so.7: 
pthread_kill
3709255:./PR9577: rld: Error: unresolvable symbol in ../.libs/libgcj.so.7: 
pthread_sigmask
3709255:./PR9577: rld: Fatal Error: this executable has unresolvable symbols

Those two functions are only present in libpthread, but the IRIX 6
configuration still uses THREADS=single.

There seem to be two references to those function:

* pthread_kill used in java/lang/natPosixProcess.cc
  (java::lang::ConcreteProcess$ProcessManager::signalReaper)

* pthread_sigmask used in java/lang/natPosixProcess.cc
  (java::lang::ConcreteProcess$ProcessManager::waitForSignal)

Environment:
System: IRIX sculptor 6.5 10060437 IP32



host: mips-sgi-irix6.5
build: mips-sgi-irix6.5
target: mips-sgi-irix6.5
configured with: /vol/gnu/src/gcc/gcc-dist/configure --prefix=/vol/gcc 
--with-local-prefix=/vol/gcc --disable-nls --with-gnu-as 
--with-as=/vol/gcc/lib/gas-2.15 --enable-libgcj --disable-multilib 
--with-gmp-dir=/vol/gnu/obj/gmp-4.1.3 --with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3 
--enable-languages=c,c++,f95,java,objc,ada --disable-libmudflap

How-To-Repeat:
Bootstrap as described above and run test libjava testsuite.

-- 
   Summary: All libjava execution tests fail on IRIX 6
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: mips-sgi-irix6.5
  GCC host triplet: mips-sgi-irix6.5
GCC target triplet: mips-sgi-irix6.5


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


[Bug fortran/19015] shape / rank mismatch in maxloc / minloc could be caught at compile time

2005-06-06 Thread tkoenig at gcc dot gnu dot org

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-06-06 
20:22 ---
This is also a runtime error in 4.0 now.

I am changing the subject to reflect my preference that this
should be caught at compile time.

Thomas

-- 
   What|Removed |Added

Summary|shape / rank mismatch in|shape / rank mismatch in
   |maxloc / minloc leads to|maxloc / minloc could be
   |assertion failure at runtime|caught at compile time


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


[Bug bootstrap/21936] New: Ada bootstrap failure on Solaris 10/x86 with native as

2005-06-06 Thread gcc-bugzilla at gcc dot gnu dot org

Bootstrapping mainline on i386-pc-solaris2.10 with the native as fails in
stage2:

stage1/xgcc -Bstage1/ -B/vol/gcc/share/i386-pc-solaris2.10/bin/ -c -g -O2  
-gnatpg -gnata -I- -I. -Iada -I/vol/gnu/src/gcc/gcc-dist/gcc/ada 
/vol/gnu/src/gcc/gcc-dist/gcc/ada/exp_ch3.adb -o ada/exp_ch3.o
Assembler: exp_ch3.adb
"/var/tmp//ccnaZBVf.s", line 12908 : Value out of range
make[2]: *** [ada/exp_ch3.o] Error 1

The line in question is

movw-4294967296(%ecx), %dx

Even gas warns about this, but this is not a fatal error:

/var/tmp//ccDV2bTU.s: Assembler messages:
/var/tmp//ccDV2bTU.s:12910: Warning:  shortened to 


This started on 20050509 at the latest.

Environment:
System: SunOS erebus 5.10 Generic i86pc i386 i86pc
Architecture: i86pc


host: i386-pc-solaris2.10
build: i386-pc-solaris2.10
target: i386-pc-solaris2.10
configured with: /vol/gnu/src/gcc/gcc-dist/configure --prefix=/vol/gcc 
--with-local-prefix=/vol/gcc --disable-nls --disable-multilib 
--with-gmp-dir=/vol/gnu/obj/gmp-4.1.3 
--with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr 
--enable-languages=c,c++,f95,java,objc,ada --disable-libmudflap

How-To-Repeat:
Bootstrap mainline as above.

-- 
   Summary: Ada bootstrap failure on Solaris 10/x86 with native as
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-pc-solaris2.10
  GCC host triplet: i386-pc-solaris2.10
GCC target triplet: i386-pc-solaris2.10


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


[Bug ada/21937] New: Member record alignment triggering an ICE

2005-06-06 Thread macro at linux-mips dot org
This problem happens for platforms that set STRICT_ALIGNMENT.  For them it is
possible for a given record type to be expressed using an integer mode if used
as a member record, and the BLK mode if used standalone.  As a result an
assignment where lhs is BLKmode and rhs is *Imode may be generated and this
triggers an ICE.

 I've been able to trigger it for 4.0.0 using alpha-linux-gnu,
mipsel-linux-gnu and mips64el-linux cross-compilers run on i386-linux-gnu
as well as a native mipsel-linux-gnu one.  The compiler was configured as
follows:

$ CC=i386-linux-gcc \
CXX=i386-linux-g++ \
F77=i386-linux-gfortran \
CFLAGS='-pipe -O2 -fomit-frame-pointer -mtune=i486' \
CXXFLAGS='-pipe -O2 -fomit-frame-pointer -mtune=i486' \
FCFLAGS='-pipe -O2 -fomit-frame-pointer -mtune=i486' \
CC_FOR_BUILD=i386-linux-gcc \
CFLAGS_FOR_BUILD='-pipe -O2 -fomit-frame-pointer -mtune=i486' \
CFLAGS_FOR_TARGET='-mcpu=ev4 -pipe -O2 -fomit-frame-pointer' \
CXXFLAGS_FOR_TARGET='-mcpu=ev4 -pipe -O2 -fomit-frame-pointer' \
FCFLAGS_FOR_TARGET='-mcpu=ev4 -pipe -O2 -fomit-frame-pointer' \
INSTALL_PROGRAM='${INSTALL} -s' \
../configure --prefix=/usr '--mandir=${datadir}/man' \
'--with-local-prefix=${prefix}/alpha-linux/local' \
--disable-multilib \
--enable-shared \
--enable-static \
--with-system-zlib \
--enable-threads \
--cache-file=config.cache \
--build=i386-linux --host=i386-linux --target=alpha-linux

then built as follows:

$ make 'BOOT_CFLAGS=-pipe -O2 -fomit-frame-pointer -mtune=i486' \
'GCJFLAGS=-mcpu=ev4 -pipe -O2 -fomit-frame-pointer' \
CXX_FOR_BUILD=i386-linux-g++ \
'CXXFLAGS_FOR_BUILD=-pipe -O2 -fomit-frame-pointer -mtune=i486' all

(this is for alpha-linux-gnu -- the others were built similarly; I can supply
details if needed).

 I'm sending a set of sources that trigger the problem for me.  They are
actually a part of the Ada binding of ncurses 5.4.  To reproduce, build as
follows:

$ alpha-linux-gcc -c -gnatpn -pipe -O2 -fomit-frame-pointer \
terminal_interface-curses.adb

 I've been able to track the problem down to the alignment of member records
being increased implicitly in an attempt to fit them into an integer mode.
I believe it is incorrect as it changes the alignment of the containing
record as well and therefore it changes the ABI.  That would be true e.g. for
the MIPS ABI as far as C is concerned, but I don't know if Ada follows the
same rules, so my opinion is not definite.  Anyway I've prepared a patch 
proposal that fixes the problem for me.

 Please consider.

-- 
   Summary: Member record alignment triggering an ICE
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: macro at linux-mips dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-linux-gnu
  GCC host triplet: i386-linux-gnu
GCC target triplet: alpha-linux-gnu


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


[Bug ada/21937] Member record alignment triggering an ICE

2005-06-06 Thread macro at linux-mips dot org

--- Additional Comments From macro at linux-mips dot org  2005-06-06 20:43 
---
Created an attachment (id=9041)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9041&action=view)
This is the set of the sources


-- 


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



[Bug ada/21937] Member record alignment triggering an ICE

2005-06-06 Thread macro at linux-mips dot org

--- Additional Comments From macro at linux-mips dot org  2005-06-06 20:45 
---
Created an attachment (id=9042)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9042&action=view)
gcc-4.0.0-ada-record-pack-align.patch


-- 


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


[Bug c/21938] New: ../.././gcc/libgcc2.c:1803: internal compiler error: verify_stmts failed.

2005-06-06 Thread dcorbit at connx dot com
Environment is Mingw.
Bison version used is 1.29

[EMAIL PROTECTED] /mingw/gcc-4.1-20050604
$ make
make[1]: Entering directory `/mingw/gcc-4.1-20050604/host-i686-pc-mingw32/zlib'
true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2" "CXXFLAGS=-g -
O2" "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=-O2 -g -O2" "INSTALL=/bin/install -
c" "INSTALL_DATA=/bin/install -c -m 644" "INSTALL_PROGRAM=/bin/install -
c" "INSTALL_SCRIPT=/bin/install -c" "LDFLAGS=" "LIBCFLAGS=-g -
O2" "LIBCFLAGS_FOR_TARGET=-O2 -g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-
size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" 
"RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/usr/local" "infodir=/usr/local/i
nfo" "libdir=/usr/local/lib" "prefix=/usr/local" "tooldir=/usr/local/i686-pc-
mingw32" "AR=ar" "AS=as" "CC=gcc" "CXX=c++" "LD=ld" "LIBCFLAGS=-g -
O2" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all multi-do # make
make[1]: Leaving directory `/mingw/gcc-4.1-20050604/host-i686-pc-mingw32/zlib'
make[1]: Entering directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/libiberty'
make[2]: Entering directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/libiberty/testsuite'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/libiberty/testsuite'
make[1]: Leaving directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/libiberty'
make[1]: Entering directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/fastjar'
make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2" "CXXFLAGS=-g -
O2" "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=-O2 -g -O2" "INSTALL=/bin/install -
c" "INSTALL_DATA=/bin/install -c -m 644" "INSTALL_PROGRAM=/bin/install -
c" "INSTALL_SCRIPT=/bin/install -c" "JC1FLAGS=" "LDFLAGS=" "LIBCFLAGS=-g -
O2" "LIBCFLAGS_FOR_TARGET=-O2 -g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-
size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "exec_prefix=/us
r/local" "infodir=/usr/local/info" "libdir=/usr/local/lib" "prefix=/usr/local" "
AR=ar" "AS=as" "CC=gcc" "CXX=c++" "LD=ld" "LIBCFLAGS=-g -
O2" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" all-am
make[2]: Entering directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/fastjar'
perl ../.././fastjar/../contrib/texi2pod.pl -D 
fastjar ../.././fastjar/fastjar.texi > fastjar.pod
(pod2man --center="GNU" --release="gcc-4.1.0" --section=1 fastjar.pod > 
fastjar.1.T$$ && \
mv -f fastjar.1.T$$ fastjar.1) || \
(rm -f fastjar.1.T$$ && exit 1)
/bin/sh: pod2man: command not found
make[2]: [fastjar.1] Error 1 (ignored)
perl ../.././fastjar/../contrib/texi2pod.pl -D 
grepjar ../.././fastjar/fastjar.texi > grepjar.pod
(pod2man --center="GNU" --release="gcc-4.1.0" --section=1 grepjar.pod > 
grepjar.1.T$$ && \
mv -f grepjar.1.T$$ grepjar.1) || \
(rm -f grepjar.1.T$$ && exit 1)
/bin/sh: pod2man: command not found
make[2]: [grepjar.1] Error 1 (ignored)
rm fastjar.pod grepjar.pod
make[2]: Leaving directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/fastjar'
make[1]: Leaving directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/fastjar'
make[1]: Entering directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/fixincludes'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/fixincludes'
make[1]: Entering directory `/mingw/gcc-4.1-20050604/host-i686-pc-mingw32/intl'
rm -f stamp-h1
/bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is unchanged
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[1]: Leaving directory `/mingw/gcc-4.1-20050604/host-i686-pc-mingw32/intl'
make[1]: Entering directory `/mingw/gcc-4.1-20050604/build-i686-pc-
mingw32/libiberty'
make[2]: Entering directory `/mingw/gcc-4.1-20050604/build-i686-pc-
mingw32/libiberty/testsuite'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/mingw/gcc-4.1-20050604/build-i686-pc-
mingw32/libiberty/testsuite'
make[1]: Leaving directory `/mingw/gcc-4.1-20050604/build-i686-pc-
mingw32/libiberty'
make[1]: Entering directory `/mingw/gcc-4.1-20050604/build-i686-pc-
mingw32/fixincludes'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/mingw/gcc-4.1-20050604/build-i686-pc-
mingw32/fixincludes'
make[1]: Entering directory `/mingw/gcc-4.1-20050604/host-i686-pc-
mingw32/libcpp'
test -d po || mkdir po
: --statistics -o po/be.gmo ../.././libcpp/po/be.po
test -d po || mkdir po
: --statistics -o po/ca.gmo ../.././libcpp/po/ca.po
test -d po || mkdir po
: --statistics -o po/da.gmo ../.././libcpp/po/da.po
test -d po || mkdir po
: --statistics -o po/de.gmo ../.././libcpp/po/de.po
test -d po || mkdir po
: --statistics -o po/el.gmo ../.././libcpp/po/el.po
test -d po || mkdir po
: --statistics -o po/es.gmo ../.././libcpp/po/es.po
test -d po || mkdir po
: --statistics -o po/fr.gmo ../.././libcpp/po/fr.po
test -d po || mkdir po
: --statistics -o po/ja.gmo ../.././libcpp/po/ja.po
test -d po || mkdir po
: --statistic

[Bug c/21938] ../.././gcc/libgcc2.c:1803: internal compiler error: verify_stmts failed.

2005-06-06 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
20:59 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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


[Bug middle-end/21766] [4.1 Regression] Bootstrap failure on i686-pc-cygwin

2005-06-06 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
20:59 ---
*** Bug 21938 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||dcorbit at connx dot com


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


[Bug ada/21937] Member record alignment triggering an ICE

2005-06-06 Thread pluto at agmk dot net


-- 
   What|Removed |Added

 CC||pluto at agmk dot net


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


[Bug middle-end/21430] Quadratic behavior with constant initializers

2005-06-06 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
21:16 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-06 21:16:03
   date||


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


[Bug ada/21937] Member record alignment triggering an ICE

2005-06-06 Thread pinskia at gcc dot gnu dot org


-- 
   What|Removed |Added

   Keywords||ice-on-valid-code


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


[Bug c++/21939] New: Corrupted memory with deque of >63 items under gcc-3.4.4

2005-06-06 Thread magerman at rentec dot com
It took me a long time to whittle this down to a small example, but here it is:

#include 
#include 
#include 

using std::deque;
using std::auto_ptr;

struct A { long x; char y; A() : x(0) {} };

auto_ptr > foo(int l){
  auto_ptr > d(new deque);
  A a, b, c;
  for (int i=0; ipush_back(a);
  return d;
}

int main(int argc, char **argv) 
{
  auto_ptr > d = foo(atoi(argv[1]));
  A a, b, c;
  for (deque::iterator i = d->begin(); i != d->end(); i++) {
std::cerr << (*i).x << std::endl;
  }
  return 0;
}

$ /work/external/wwc/bin/g++-3.4.4 -v -save-temps -Wall -fno-strict-aliasing -O2
/work/nova/6067/src/foo.C
Reading specs from 
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/specs
Configured with: ../gcc-3.4.4/configure --prefix=/work/external/wwc/prgcc
--program-suffix=-3.4.4 --enable-threads --with-included-gettext
--enable-languages=c,c++,f77 --with-gnu-as
--with-as=/work/external/wwc/prodbinu216/bin/as --with-gnu-ld
--with-ld=/work/external/wwc/prodbinu216/bin/ld : (reconfigured)
../gcc-3.4.4/configure --prefix=/work/external/wwc/prgcc --program-suffix=-3.4.4
--enable-threads --with-included-gettext --enable-languages=c,c++,f77
--with-gnu-as --with-as=/work/external/wwc/prodbinu216/bin/as --with-gnu-ld
--with-ld=/work/external/wwc/prodbinu216/bin/ld
Thread model: posix
gcc version 3.4.4
 /work/external/wwc/prgcc/libexec/gcc/sparc-sun-solaris2.8/3.4.4/cc1plus -E
-quiet -v /work/nova/6067/src/foo.C -mcpu=v7 -Wall -fno-strict-aliasing -O2 -o
foo.ii
ignoring nonexistent directory
"/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../sparc-sun-solaris2.8/include"
#include "..." search starts here:
#include <...> search starts here:
 
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../include/c++/3.4.4
 
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../include/c++/3.4.4/sparc-sun-solaris2.8
 
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../include/c++/3.4.4/backward
 /usr/local/include
 /work/external/wwc/prgcc/include
 /work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/include
 /usr/include
End of search list.
 /work/external/wwc/prgcc/libexec/gcc/sparc-sun-solaris2.8/3.4.4/cc1plus
-fpreprocessed foo.ii -quiet -dumpbase foo.C -mcpu=v7 -auxbase foo -O2 -Wall
-version -fno-strict-aliasing -o foo.s
GNU C++ version 3.4.4 (sparc-sun-solaris2.8)
compiled by GNU C version 3.4.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 /work/external/wwc/prodbinu216/bin/as --traditional-format -V -Qy -s -xarch=v8
-o foo.o foo.s
GNU assembler version 2.16 (sparc-sun-solaris2.8) using BFD version 2.16
 /work/external/wwc/prgcc/libexec/gcc/sparc-sun-solaris2.8/3.4.4/collect2 -V -Y
P,/usr/ccs/lib:/usr/lib -rpath-link /usr/lib -Qy
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/crt1.o
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/crti.o
/usr/ccs/lib/values-Xa.o
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/crtbegin.o
-L/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4 -L/usr/ccs/bin
-L/usr/ccs/lib
-L/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../.. foo.o
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc -lc
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/crtend.o
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/crtn.o
GNU ld version 2.16
  Supported emulations:
   elf32_sparc
   elf64_sparc

$

If I run this program with the argument greater than 64, it prints out 63 zeros,
followed by the number 513, followed by more zeros.  If I run it with the
argument 64, it does the same and then SEGVs.

This is as simple an example as I can produce.  The following simplifications
cause the program to behave properly:
1. removing the auto_ptr
2. removing the -fno-strict-aliasing
3. removing any of the unused local variables
4. moving the code from foo() into main
5. making the iterator a const_iterator
6. using -fno-unit-at-a-time
7. replacing -O2 with -O1

Please let me know if you need any more information.

-- David Magerman
[EMAIL PROTECTED]

-- 
   Summary: Corrupted memory with deque of >63 items under gcc-3.4.4
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: magerman at rentec dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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


[Bug c++/21939] Corrupted memory with deque of >63 items under gcc-3.4.4

2005-06-06 Thread magerman at rentec dot com

--- Additional Comments From magerman at rentec dot com  2005-06-06 21:25 
---
Created an attachment (id=9043)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9043&action=view)
the preprocessed file that triggers the bug


-- 


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


[Bug middle-end/21939] Corrupted memory with deque of >63 items under gcc-3.4.4

2005-06-06 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 
21:27 ---
The last time I saw a bug like this, it was actually a bug in the person's code.

-- 
   What|Removed |Added

  Component|c++ |middle-end
   Keywords||wrong-code


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


[Bug libgcj/21940] New: boehm-gc gctest fails on Solaris 10/x86

2005-06-06 Thread gcc-bugzilla at gcc dot gnu dot org

During a make check on Solaris 10/x86, make check in boehm-gc fails (which
unfortunately goes almost unnoticed since the failure is not included in
mail-report.log, cf. PR libgcj/11412):

/bin/ksh: 2246 Segmentation Fault
FAIL: gctest
===
1 of 1 tests failed
===
make[3]: *** [check-TESTS] Error 1

Running the test manually with LD_LIBRARY_PATH set so libgcc_s.so.1 is
found, one gets one of several possible results:

% LD_LIBRARY_PATH=../../gcc ./gctest 
Apparently failed to mark form some function arguments.
Perhaps GC_push_regs was configured incorrectly?
Test failed
Segmentation Fault
% LD_LIBRARY_PATH=../../gcc ./gctest 
Segmentation Fault
% LD_LIBRARY_PATH=../../gcc ./gctest 
Apparently failed to mark form some function arguments.
Perhaps GC_push_regs was configured incorrectly?
Test failed
Abort

pstack core reveals e.g. (for a run with a plain SEGV):

core 'core' of 10995:   gctest
-  lwp# 1 / thread# 1  
 bff0d20b __lwp_park (bfe52000, 0, 806ca38, 0) + b
 bff06b5e slow_lock (bfe52000, 806ca38, 0) + 3d
 bff06c54 mutex_lock_impl (806ca38, 0) + ec
 bff06d60 mutex_lock (806ca38, 1, bffbc7b8, bff9e2a6, 806ca38, 806cbac) + 1a
 bff9e2ee GC_malloc (c, 0, 8047628, 80531b6, 0, 8051624) + 56
 080531de run_one_test (8047650, 8051c29, 8064378, 8064904, 0, 805387e) + 382
 08053733 main (1, 8047688, 8047690) + 83
 08051b04 _start   (1, 80477a0, 0, 80477a7, 804781c, 8047909) + 80
-  lwp# 2 / thread# 2  
 bff0df17 __lwp_wait (0, bfe29f78) + 7
 bff0a180 _thrp_join (0, bfe29fc4, bfe29fc8, 1) + 5a
 bff0a2c2 thr_join (0, bfe29fc4, bfe29fc8, 806ca38, 0, bfe29fc8) + 20
 bffa600b GC_thr_daemon (0) + 33
 bff0cebf _thr_setup (bfe52400) + 4e
 bff0d1b0 _lwp_start (bfe52400, 0, 0, bfe29ff8, bff0d1b0, bfe52400)
-  lwp# 3 / thread# 3  
 bffa5d58 GC_my_stack_limits (0, bffbc904, 0, 0, 0, 0) + 2c
 bffa5e7d GC_old_stacks_are_fresh (bffb92b8, bffa545c, bfffe000, 806ca58, 
bffc8eb8, bffb9adc) + c1
 bffa35ed GC_read_dirty (40, bffb92b8, 81cded8, bff99084, 809b000, 0) + 16d
 bff9f435 GC_initiate_gc (809b000, 0, 81cdee8, bff9dae2, 8303000, 8313000) + 79
 bff99084 GC_stopped_mark (bff98de4, bffb92b8, 81cdf18, bff998df) + 64
 bff998f4 GC_try_to_collect_inner (bff98de4, 0, 81cdf48, bff99a91, bff99b3a, 
bff073ab) + 9c
 bff99ace GC_try_to_collect (bff98de4, bff073ab, bff0d23b, 0) + 6a
 bff99b3a GC_gcollect (0, 0, 0, 0, 0, 0) + 1e
 08053174 run_one_test (bff0b838, bff35000, 81cdfec, bff0cebf, 0, 0) + 318
 080536ab thr_run_one_test (0) + b
 bff0cebf _thr_setup (bfd1) + 4e
 bff0d1b0 _lwp_start (0, 0, 0, 0, 0, 0)
-  lwp# 4 / thread# 4  
 bff0d20b __lwp_park (bfd10400, 0, 806ca38, 0) + b
 bff06b5e slow_lock (bfd10400, 806ca38, 0) + 3d
 bff06c54 mutex_lock_impl (806ca38, 0) + ec
 bff06d60 mutex_lock (806ca38, bffb92b8, 82f0f48, bff99a91) + 1a
 bff99aa0 GC_try_to_collect (bff98de4, 8052d84, 82f0fc8, 805316c) + 3c
 bff99b3a GC_gcollect (0, 0, 0, 0, 0, 0) + 1e
 08053174 run_one_test (bff0b838, bff35000, 82f0fec, bff0cebf, 0, 0) + 318
 080536ab thr_run_one_test (0) + b
 bff0cebf _thr_setup (bfd10400) + 4e
 bff0d1b0 _lwp_start (0, 0, 0, 0, 0, 0)

Some info on this failure can also be found in

http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2005-March/000767.html

and a couple of other postings on the [EMAIL PROTECTED] list.

To further investigate this, I've tried a couple of experiments with the
gc6.5 release.  Here's what I've found:

* With Sun cc 5.7, gctest fails like this:

Switched to incremental mode
Reading dirty bits from /proc
List reversal produced incorrect list - collector is broken
Test failed
Abort

  The same binary works without problems on s10_63 (an old beta of Solaris
  10, before amd64 integration), but fails on s10_70 (the first beta to
  integrate amd64 support) and on Solaris 10 FCS.

  Definining USE_GENERIC_PUSH_REGS in gcconfig.h doesn't change this.

* With Sun cc 5.7 and configuring with --enable-full-debug, gctest passes
  on all releases.  With the calls to GC_enable_incremental commented out
  in tests/test.c, gctest even passes without --enable-full-debug; setting
  GC_ENABLE_INCREMENTAL=1 in the environment causes it to fail again.

* With Sun cc 5.7 and configuring with --enable-full-debug
  --enable-threads=posix, gctest fails again, now with the same error as
  gcc (which has pthread support enabled by default).

* With gcc 3.4.3 and configuring with --disable-threads, I get the same
  failure as with cc (which defaults to --disable-threads).

* With gcc 3.4.3 and configuring with --disable-threads
  --enable-full-debug, gctest works.

Environment:
System: SunOS cumaru 5.10 Generic_Patch i86pc i386 i86pc
Architecture: i86pc


host: i386-pc-solaris2.10
build: i386-pc-solaris2.10
target: i386-pc-solaris2.10
configured with: /vol/gnu/src/gcc/gcc-dist/configure --prefix=/vol/gcc 
--with-local-prefix=/vol/gcc --disable-nls --w

[Bug middle-end/21939] Corrupted memory with deque of >63 items under gcc-3.4.4

2005-06-06 Thread magerman at rentec dot com

--- Additional Comments From magerman at rentec dot com  2005-06-06 22:46 
---
(In reply to comment #2)
> The last time I saw a bug like this, it was actually a bug in the person's 
> code.

I wish it were true.  We've got this code (well, a more complicated version of
it) working optimized (-O3) and unoptimized under two different compilers
(gcc-2.9.5.2 and gcc-3.2) on two different OSes (Linux and Solaris).  The
example is pretty simple and straight-forward.  It's hard to see where there can
be a bug in the code.


-- 


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


[Bug libgcj/21941] New: NPE in Socket.connect()

2005-06-06 Thread tromey at gcc dot gnu dot org
I get a NullPointerException in Socket.connect().
This seems to happen when the nameserver is not available.
My current test case is with gcjappletviewer; I can reproduce it
by stopping my VPN but leaving my /etc/resolv.conf untouched
(so it tries to contact a DNS server which is not available)

(I also remember seeing NPEs from PlainSocketImpl::connect,
but I can't reproduce that presently.  These occurred when
"tmp" was NULL...)

opsy. ./gcjappletviewer http://www.chessgames.com/perl/chessgame?gid=1067300
raw arguments:
 http://www.chessgames.com/perl/chessgame?gid=1067300
java.lang.NullPointerException
   at java.net.Socket.connect(java.net.SocketAddress, int)
(/home/tromey/gnu/4.0/install/lib/libgcj.so.6.0.0)
   at java.net.Socket.connect(java.net.SocketAddress)
(/home/tromey/gnu/4.0/install/lib/libgcj.so.6.0.0)
   at gnu.java.net.protocol.http.HTTPConnection.getSocket()
(/home/tromey/gnu/4.0/install/lib/libgcj.so.6.0.0)
   at gnu.java.net.protocol.http.HTTPConnection.getOutputStream()
(/home/tromey/gnu/4.0/install/lib/libgcj.so.6.0.0)
   at gnu.java.net.protocol.http.Request.dispatch()
(/home/tromey/gnu/4.0/install/lib/libgcj.so.6.0.0)
   at gnu.java.net.protocol.http.HTTPURLConnection.connect()
(/home/tromey/gnu/4.0/install/lib/libgcj.so.6.0.0)
   at gnu.java.net.protocol.http.HTTPURLConnection.getInputStream()
(/home/tromey/gnu/4.0/install/lib/libgcj.so.6.0.0)
   at java.net.URL.openStream() 
(/home/tromey/gnu/4.0/install/lib/libgcj.so.6.0.0)
   at gnu.gcjwebplugin.AppletTag.parseAppletTags(java.lang.String,
java.lang.String) (Unknown Source)
   at
gnu.gcjwebplugin.StandaloneAppletViewer.StandaloneAppletViewer(java.lang.String,
java.lang.String, java.lang.String, java.util.List, java.awt.Dimension, boolean,
boolean, boolean, java.lang.String[], gnu.getopt.Getopt, int, java.lang.String)
(Unknown Source)
   at gnu.gcjwebplugin.AppletViewer.main(java.lang.String[]) (Unknown Source)
   at .main (/home/tromey/gnu/mozilla/gcjwebplugin/src/gcjappletviewer.c:189)
   at .__libc_start_main (/lib/tls/libc-2.3.3.so)

-- 
   Summary: NPE in Socket.connect()
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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


[Bug libgcj/21942] New: boehm-gc doesn't compile on Solaris 10/amd64

2005-06-06 Thread gcc-bugzilla at gcc dot gnu dot org

The amd64 multilib of boehm-gc doesn't build on i386-pc-solaris2.10: the
compilation fails with

/vol/gnu/src/gcc/gcc-dist/boehm-gc/include/private/gcconfig.h:435: error: parse 
error before '--' token

Environment:
System: SunOS cumaru 5.10 Generic_Patch i86pc i386 i86pc
Architecture: i86pc


host: i386-pc-solaris2.10
build: i386-pc-solaris2.10
target: i386-pc-solaris2.10
configured with: /vol/gnu/src/gcc/gcc-dist/configure --prefix=/vol/gcc 
--with-local-prefix=/vol/gcc --disable-nls --with-gnu-as 
--with-as=/usr/sfw/bin/gas --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3 
--with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3 
--enable-languages=c,c++,f95,java,objc,ada --disable-libmudflap

How-To-Repeat:
Bootstrap mainline as described above.
--- Additional Comments From ro at techfak dot uni-bielefeld dot de  
2005-06-06 22:56 ---
Fix:
I've added a clause to boehm-gc/include/private/gcconfig.h for
X86_64/SUNOS5 to allow boehm-gc to compile, but gctest doesn't fully work
yet (but at least as well as the 32-bit version).  Cf. PR libgcj/21940 for
32-bit gctest failures on this platform.

Index: boehm-gc/include/private/gcconfig.h
===
RCS file: /cvs/gcc/gcc/boehm-gc/include/private/gcconfig.h,v
retrieving revision 1.44
diff -u -p -r1.44 gcconfig.h
--- boehm-gc/include/private/gcconfig.h 25 May 2005 13:10:00 -  1.44
+++ boehm-gc/include/private/gcconfig.h 6 Jun 2005 22:54:37 -
@@ -146,6 +146,11 @@
 #define SUNOS5
 #define mach_type_known
 # endif
+# if defined(sun) && defined(__amd64)
+#define X86_64
+#define SUNOS5
+#define mach_type_known
+# endif
 # if (defined(__OS2__) || defined(__EMX__)) && defined(__32BIT__)
 #define I386
 #define OS2
@@ -1912,6 +1917,36 @@
extern char etext[];
 #  define SEARCH_FOR_DATA_START
 #   endif
+#   ifdef SUNOS5
+#  define ELF_CLASS ELFCLASS64
+#  define OS_TYPE "SUNOS5"
+extern int _etext[], _end[];
+   extern ptr_t GC_SysVGetDataStart();
+#   define DATASTART GC_SysVGetDataStart(0x1000, _etext)
+#  define DATAEND (_end)
+/* # define STACKBOTTOM ((ptr_t)(_start)) worked through 2.7,  */
+/*  but reportedly breaks under 2.8.  It appears that the stack*/
+/* base is a property of the executable, so this should not break  */
+/* old executables.*/
+/* HEURISTIC2 probably works, but this appears to be preferable.   */
+/* #   include  */
+/* #   define STACKBOTTOM USRSTACK */
+#  define HEURISTIC2
+#  define PROC_VDB
+#  define DYNAMIC_LOADING
+#  if !defined(USE_MMAP) && defined(REDIRECT_MALLOC)
+#  define USE_MMAP
+   /* Otherwise we now use calloc.  Mmap may result in the */
+   /* heap interleaved with thread stacks, which can result in */
+   /* excessive blacklisting.  Sbrk is unusable since it   */
+   /* doesn't interact correctly with the system malloc.   */
+#  endif
+#   ifdef USE_MMAP
+# define HEAP_START (ptr_t)0x4000
+#   else
+#define HEAP_START DATAEND
+#   endif
+#   endif
 # endif
 
 #if defined(LINUX) && defined(USE_MMAP)

-- 
   Summary: boehm-gc doesn't compile on Solaris 10/amd64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-pc-solaris2.10
  GCC host triplet: i386-pc-solaris2.10
GCC target triplet: i386-pc-solaris2.10


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


[Bug middle-end/21939] Corrupted memory with deque of >63 items under gcc-3.4.4

2005-06-06 Thread pcarlini at suse dot de

--- Additional Comments From pcarlini at suse dot de  2005-06-06 23:01 
---
Maybe (a wild guess) Andrew refers to apparently similar problems that may occur
with std::sort, when the comparison doesn't fulfil the strict weak ordering 
reqs,
like libstdc++/18640. Those are user errors, definitely.

-- 


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


[Bug libgcj/21943] New: O32 libffi.so fails to link on IRIX 6

2005-06-06 Thread gcc-bugzilla at gcc dot gnu dot org

Building the O32 libffi on IRIX 6.5 fails, thus we get a bootstrap failure
with --enable-libgcj:

/bin/ksh ./libtool --mode=link 
/.vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc-java/gcc/xgcc 
-B/.vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc-java/gcc/ 
-B/.vol/gcc/share/mips-sgi-irix6.5/bin/ -B/.vol/gcc/share/mips-sgi-irix6.5/lib/ 
-isystem /.vol/gcc/share/mips-sgi-irix6.5/include -isystem 
/.vol/gcc/share/mips-sgi-irix6.5/sys-include  -mabi=32 -Wall -g -fexceptions 
-O2 -g -O2  -mabi=32  -mabi=32 -o libffi.la -rpath /.vol/gcc/lib/../lib 
-version-info `grep -v '^#' 
/.vol/gcc/src/gcc-4.0-branch-dist/libffi/libtool-version` src/debug.lo 
src/prep_cif.lo src/types.lo src/raw_api.lo src/java_raw_api.lo src/mips/ffi.lo 
src/mips/o32.lo src/mips/n32.lo
/.vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc-java/gcc/xgcc 
-B/.vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc-java/gcc/ 
-B/.vol/gcc/share/mips-sgi-irix6.5/bin/ -B/.vol/gcc/share/mips-sgi-irix6.5/lib/ 
-isystem /.vol/gcc/share/mips-sgi-irix6.5/include -isystem 
/.vol/gcc/share/mips-sgi-irix6.5/sys-include  -mabi=32 -shared  
src/.libs/debug.o src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o 
src/.libs/java_raw_api.o src/mips/.libs/ffi.o src/mips/.libs/o32.o 
src/mips/.libs/n32.o  -lc  -Wl,-soname -Wl,libffi.so.5 `test -n "sgi5.0:sgi5.1" 
&& echo -Wl,-set_version -Wl,sgi5.0:sgi5.1` -Wl,-update_registry 
-Wl,.libs/so_locations -o .libs/libffi.so.5.1
ld: FATAL   45 : Non-PIC (src/mips/.libs/o32.o) used in shared/call_shared link.
collect2: ld returned 4 exit status
make[8]: *** [libffi.la] Error 1

Obviously the new O32 closure support isn't PIC code, causing the link
failure above.

This is a regression from 3.4.

Environment:
System: IRIX64 columba 6.5 10120104 IP27



host: mips-sgi-irix6.5
build: mips-sgi-irix6.5
target: mips-sgi-irix6.5
configured with: /.vol/gcc/src/gcc-4.0-branch-dist/configure --prefix=/.vol/gcc 
--with-local-prefix=/.vol/gcc --disable-nls --enable-libgcj 
--with-gmp-dir=/.vol/gcc/obj/gmp-4.1.3 --with-mpfr-dir=/.vol/gcc/obj/gmp-4.1.3 
--with-gnu-as --with-as=/homes/ro/bin/gas-2.15

How-To-Repeat:
Bootstrap on mips-sgi-irix6.5 with --enable-libgcj.
--- Additional Comments From ro at techfak dot uni-bielefeld dot de  
2005-06-06 23:04 ---
Fix:
Omit --enable-libgcj for now.

-- 
   Summary: O32 libffi.so fails to link on IRIX 6
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: mips-sgi-irix6.5
  GCC host triplet: mips-sgi-irix6.5
GCC target triplet: mips-sgi-irix6.5


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


[Bug libgcj/21944] New: libgcj.so fails to link on IRIX 6: GOT overflow

2005-06-06 Thread gcc-bugzilla at gcc dot gnu dot org

libgcj.so doesn't link on IRIX 6:

/vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc/gcc/xgcc -shared-libgcc 
-B/vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc/gcc/ -nostdinc++ 
-L/vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc/mips-sgi-irix6.5/libstdc++-v3/src 
-L/vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc/mips-sgi-irix6.5/libstdc++-v3/src/.libs
 -B/vol/gcc/share/mips-sgi-irix6.5/bin/ -B/vol/gcc/share/mips-sgi-irix6.5/lib/ 
-isystem /vol/gcc/share/mips-sgi-irix6.5/include -isystem 
/vol/gcc/share/mips-sgi-irix6.5/sys-include -shared -nostdlib 
/vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc/gcc/irix-crti.o 
/vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc/gcc/crtbegin.o .libs/libgcj.la-2.o  
-L/vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc/mips-sgi-irix6.5/libstdc++-v3/src 
-L/vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc/mips-sgi-irix6.5/libstdc++-v3/src/.libs
 -L/vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc/mips-sgi-irix6.5/libjava 
./.libs/libgcj0_convenience.a ../libffi/.libs/libffi_convenience.a 
../zlib/.libs/libzgcj_convenience.a ../boehm-gc/.libs/libgcjgc_convenience.a 
./libltdl!
 /.libs/libltdlc.a -ldl -L/vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc/gcc 
-L/vol/gcc/lib -L/lib/../lib32 -L/usr/lib/../lib32 -lgcc_s -L/usr/lib32/mips3 
-L/usr/lib32 -lgcc_s  -lc 
/vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc/gcc/crtend.o 
/vol/gcc/obj/gcc-4.0.0-20050414/6.5-gcc/gcc/irix-crtn.o  -Wl,-soname 
-Wl,libgcj.so.7 `test -n "sgi7.0" && echo -Wl,-set_version -Wl,sgi7.0` 
-Wl,-update_registry -Wl,.libs/so_locations -o .libs/libgcj.so.7.0
ld32: WARNING 84 : ./.libs/libgcj0_convenience.a is not used for resolving any 
symbol.
ld32: WARNING 84 : ../libffi/.libs/libffi_convenience.a is not used for 
resolving any symbol.
ld32: WARNING 84 : ../zlib/.libs/libzgcj_convenience.a is not used for 
resolving any symbol.
ld32: WARNING 84 : ../boehm-gc/.libs/libgcjgc_convenience.a is not used for 
resolving any symbol.
ld32: WARNING 84 : ./libltdl/.libs/libltdlc.a is not used for resolving any 
symbol.
ld32: WARNING 84 : /usr/lib/../lib32/libdl.so is not used for resolving any 
symbol.
ld32: WARNING 47 : This module (.libs/libgcj.la-2.o .text) contains branch 
instruction(s)
   that might degrade performance on an older version (rev. 
2.2) R4000 processor.
ld32: INFO171: Multigot invoked. Gp relative region broken up into 3 
separate regions.
ld32: ERROR   97 : GOT overflow in .libs/libgcj.la-2.o. 
See the dso(5) manpage.
ld32: Relocation 293309 in section .rela.text in file .libs/libgcj.la-2.o.
ld32: ERROR   104: GOT page/offset relocation out of range: relocation offset: 
0x49ecfc.
   Please use -LD_LAYOUT:lgot_buffer=50.
   If that doesn't work see the dso(5) manpage.
[many more elided...]
ld32: INFO152: Output file removed because of error.
collect2: ld returned 2 exit status
make[3]: *** [libgcj.la] Error 1

Using -LD_LAYOUT:lgot_buffer=50 doesn't help either.  This is a regression
from 3.4.x.

Environment:
System: IRIX sculptor 6.5 10060437 IP32



host: mips-sgi-irix6.5
build: mips-sgi-irix6.5
target: mips-sgi-irix6.5
configured with: /vol/gnu/src/gcc/gcc-4.0-branch-dist/configure 
--prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --enable-libgcj 
--disable-multilib --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3 
--with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3 --with-gnu-as 
--with-as=/vol/gcc/lib/gas-2.15

How-To-Repeat:
Bootstrap the 4.0 branch as described above.
--- Additional Comments From ro at techfak dot uni-bielefeld dot de  
2005-06-06 23:17 ---
Fix:
The problem doesn't occur on mainline due to this patch

http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01552.html

which also fixes bootstrap/20155.  So this should be backported to the 4.0
branch.

-- 
   Summary: libgcj.so fails to link on IRIX 6: GOT overflow
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: mips-sgi-irix6.5
  GCC host triplet: mips-sgi-irix6.5
GCC target triplet: mips-sgi-irix6.5


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


[Bug bootstrap/20155] [4.0/4.1 Regression] libgcj build fails with "execvp: /bin/sh: Argument list too long"

2005-06-06 Thread ro at gcc dot gnu dot org

--- Additional Comments From ro at gcc dot gnu dot org  2005-06-06 23:21 
---
At least on Tru64 UNIX (which is affected as mentioned in Comment #12), this is
fixed on mainline by this patch:

  http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01552.html

So it should probably be backported to the 4.0 branch.

-- 


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


  1   2   >