[Bug c++/18920] New: internal compiler error: Segmentation fault

2004-12-10 Thread kornel at gazeta dot pl
Here's the output:
 /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/cc1plus -E -D__GNUG__=3 -quiet -v -
D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=4 -D_GNU_SOURCE new.cpp new
.ii
ignoring nonexistent directory "/usr/i486-slackware-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/qt/include
 /usr/include/c++/3.3.4
 /usr/include/c++/3.3.4/i486-slackware-linux
 /usr/include/c++/3.3.4/backward
 /usr/local/include
 /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/include
 /usr/include
End of search list.
 /usr/lib/gcc-lib/i486-slackware-linux/3.3.4/cc1plus -fpreprocessed new.ii -quie
t -dumpbase new.cpp -auxbase new -version -o new.s
GNU C++ version 3.3.4 (i486-slackware-linux)
compiled by GNU C version 3.3.4.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64393
new.cpp:16: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

And here the source:

#include 
#include 

using namespace std;

template 
struct print_matrix : public unary_function{

ostream &os;

print_matrix( ostream &out ) : os( out ){
}
};

template >
struct print_matrix : public unary_function >, void>{

void operator()( T x ){
}
};

int main( int argc, char **argv  ){

return 0;

}

-- 
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 3.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kornel at gazeta dot pl
CC: gcc-bugs at gcc dot gnu dot org


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


[Bug fortran/15966] ICE and segmentation fault on internal write

2004-12-10 Thread paulthomas2 at wanadoo dot fr

--- Additional Comments From paulthomas2 at wanadoo dot fr  2004-12-10 
10:50 ---
Note that this compiles and runs OK

   subroutine a()
   implicit none
   integer :: i
   character(100)  :: r  !! eliminate dimension => works
   write(r,*) I
   end subroutine a



-- 


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


[Bug middle-end/18596] [4.0 regression] ICE in make_decl_rtl

2004-12-10 Thread steven at gcc dot gnu dot org

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 
11:09 ---
Ehm, maybe this is a stupid question - but why are we generating a DECL_RTL
to begin with, given that we have errors?


-- 


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


[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

2004-12-10 Thread steven at gcc dot gnu dot org

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 
11:52 ---
The fail dates from comment #3 probably refer to this change

2004-10-17  Andrew Pinski  <[EMAIL PROTECTED]>

* c-typeck.c (default_function_array_conversion): Always create
&a[0] for array types.
(build_unary_op): Do not fold &a[x] into a + x.

which was reverted again on the same day.  Can someone try with the reghunter
to see if it failed before October 17 also?



-- 
   What|Removed |Added

  Known to fail||4.0.0
  Known to work||3.3.4


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


[Bug tree-optimization/18921] [4.0 Regression] wrong code with operator "?"

2004-12-10 Thread steven at gcc dot gnu dot org


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-10 11:55:30
   date||


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


[Bug fortran/16898] Aliasing problem with array descriptors

2004-12-10 Thread paulthomas2 at wanadoo dot fr

--- Additional Comments From paulthomas2 at wanadoo dot fr  2004-12-10 
13:02 ---
Andrew,

This one is fixed now, isn't it?  It runs fine with the CVS of 20041205


-- 


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


[Bug middle-end/18921] [4.0 Regression] wrong code with operator "?"

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
13:35 ---
We are getting rid of "  (k ? 0 : j++) == -1;" for some reason even though it 
has side effects.

-- 
   What|Removed |Added

  Component|tree-optimization   |middle-end


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


[Bug fortran/17175] set_exponent breaks with integer*8 exponent

2004-12-10 Thread paulthomas2 at wanadoo dot fr

--- Additional Comments From paulthomas2 at wanadoo dot fr  2004-12-10 
13:35 ---
You have fixed this one, haven't you? cvs 20041205 runs it fine.

However, in testing, I found another nasty:

y = 1/2 + 1/8
!y= 0.125 + 0.5 !!works OK
x = set_exponent (y, 5_4)
print *,x
x = set_exponent (y, 5_8)
print *,x
end

gives 

$ ./a
   0.00
   0.00

instead of 

   20.0
   20.0


-- 


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


[Bug c++/17395] Incorrect lookup for parameters

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
13:37 ---
(In reply to comment #5)
> Subject: Re:  Incorrect lookup for parameters
> 
> "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> 
> | --- Additional Comments From bangerth at dealii dot org  2004-09-10 
> 14:40 ---
> | > No, GCC is wrong :-) 
> | > We had a thread on this issue on the Core reflector, no later than two 
> | > days ago. 
> |  
> | Ah, I should have guessed :-) 
> |  
> | In that case, I think I should confirm the bug. 
> | W. 
> 
> Is it normal that I get a mail from "pinskia" and signed "W."?

What most likely happened is that bugzilla did not sent message before, so when 
I reconfirmed the 
bug, bugzilla sent out all of the pending messages for this bug.

-- 


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


[Bug target/18925] Invalid gprel relocation in PIC

2004-12-10 Thread schwab at suse dot de


-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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


[Bug target/18925] Invalid gprel relocation in PIC

2004-12-10 Thread schwab at suse dot de


-- 
   What|Removed |Added

   Keywords||wrong-code


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


[Bug middle-end/18596] [4.0 regression] ICE in make_decl_rtl

2004-12-10 Thread phython at gcc dot gnu dot org

--- Additional Comments From phython at gcc dot gnu dot org  2004-12-10 
14:23 ---
 The problem occurs in no-unit-at-a-time mode, so the nested functions are
expanded, and that is where the problems start.

-- 


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


[Bug fortran/18827] ICE on assign to common variable

2004-12-10 Thread wf_cs at yahoo dot com

--- Additional Comments From wf_cs at yahoo dot com  2004-12-10 14:58 
---
I've fixed the first and am looking into the second. I think the second 
(variable with equivalence)is an invalid code. ifort also gives an error.

-- 


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


[Bug fortran/17175] set_exponent breaks with integer*8 exponent

2004-12-10 Thread tobi at gcc dot gnu dot org

--- Additional Comments From tobi at gcc dot gnu dot org  2004-12-10 15:32 
---
Patch here: http://gcc.gnu.org/ml/fortran/2004-12/msg00099.html

-- 
   What|Removed |Added

   Keywords||patch, wrong-code


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


[Bug rtl-optimization/16536] [3.3 regression] Incorrect __restrict__ optimization in -O2

2004-12-10 Thread reichelt at gcc dot gnu dot org


-- 
   What|Removed |Added

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


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


[Bug middle-end/18927] O(n^2) compile time with -O0 (n= number of basic blocks) in global alloc

2004-12-10 Thread pinskia at gcc dot gnu dot org


-- 
   What|Removed |Added

  Component|target  |middle-end
   Keywords||compile-time-hog


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


[Bug c++/18731] [3.3/3.4/4.0 regression] ICE on invalid template declaration

2004-12-10 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-10 
16:13 ---
Subject: Bug 18731

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2004-12-10 16:13:47

Modified files:
gcc/cp : ChangeLog parser.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/parse: struct-1.C struct-2.C struct-3.C 

Log message:
PR c++/18731
* parser.c (cp_parser_class_head): Reject typedef-name in class head.

* g++.dg/parser/struct-1.C: New test.
* g++.dg/parser/struct-2.C: New test.
* g++.dg/parser/struct-3.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.184&r2=1.3892.2.185
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.157.2.46&r2=1.157.2.47
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.321&r2=1.3389.2.322
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/struct-1.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/struct-2.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/struct-3.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1



-- 


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


[Bug c++/18731] [3.3 regression] ICE on invalid template declaration

2004-12-10 Thread reichelt at gcc dot gnu dot org

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-12-10 
16:15 ---
Fixed on mainline and for 3.4.4

-- 
   What|Removed |Added

Summary|[3.3/3.4/4.0 regression] ICE|[3.3 regression] ICE on
   |on invalid template |invalid template declaration
   |declaration |
   Target Milestone|3.4.4   |3.3.6


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


[Bug other/18928] New: ice on valid code.

2004-12-10 Thread pluto at pld-linux dot org
ICE # g++ qpsprinter.ii -c -O2 -fPIC 
g++: Internal error: Segmentation fault (program cc1plus) 
 
WORK # g++ qpsprinter.ii -c -O2 
WORK # g++ qpsprinter.ii -c -O -fPIC

-- 
   Summary: ice on valid code.
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at pld-linux dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: pentium3-pld-linux
  GCC host triplet: pentium3-pld-linux
GCC target triplet: pentium3-pld-linux


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


[Bug other/18928] ice on valid code.

2004-12-10 Thread pluto at pld-linux dot org

--- Additional Comments From pluto at pld-linux dot org  2004-12-10 16:48 
---
Created an attachment (id=7719)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7719&action=view)
testcase


-- 


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


[Bug tree-optimization/18040] [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:178

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
16:54 ---
Newest patch here: .

-- 
   What|Removed |Added

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


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


[Bug c++/17868] [3.3 regression] RDIV_EXPR not supported by dump_expr

2004-12-10 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-10 
17:02 ---
Subject: Bug 17868

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_3-branch
Changes by: [EMAIL PROTECTED]   2004-12-10 17:02:32

Modified files:
gcc/cp : ChangeLog error.c 

Log message:
PR c++/17868
* error.c (dump_expr): Add missing case for RDIV_EXPR.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.3076.2.278&r2=1.3076.2.279
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/error.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.192.2.9&r2=1.192.2.10



-- 


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


[Bug c++/17868] [3.3 regression] RDIV_EXPR not supported by dump_expr

2004-12-10 Thread reichelt at gcc dot gnu dot org

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-12-10 
17:03 ---
Now also fixed on the 3.3 branch.


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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


[Bug rtl-optimization/16536] [3.3 regression] Incorrect __restrict__ optimization in -O2

2004-12-10 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-10 
17:25 ---
Subject: Bug 16536

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_3-branch
Changes by: [EMAIL PROTECTED]   2004-12-10 17:25:07

Modified files:
gcc: ChangeLog alias.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/execute: restrict-1.c 

Log message:
PR rtl-optimization/16536
Backport from mainline:
2004-06-25  Mark Mitchell  <[EMAIL PROTECTED]>
* alias.c (get_alias_set): Adjust setting of
DECL_POINTER_ALIAS_SET for pointers to aggregates.

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

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.1036&r2=1.16114.2.1037
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/alias.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.181.2.6&r2=1.181.2.7
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.2261.2.388&r2=1.2261.2.389
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/restrict-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=NONE&r2=1.2.44.1



-- 


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


[Bug c/18930] name clash in C?

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
18:33 ---
Not a bug:

typedef int i;
typedef char c;

i main (i c, c ** v)
{

}

c is injected right away after "i c".


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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


[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

2004-12-10 Thread kazu at cs dot umass dot edu

--- Additional Comments From kazu at cs dot umass dot edu  2004-12-10 19:08 
---
Subject: Re:  [4.0 regression] loop
 miscompilation at -O1 (-ftree-ch)

Hi Jeff,

> Note that recording tmp_1 = next_2 isn't particularly good either since 
> tmp_1 really isn't equivalent to next_2.  It's equivalent to the
> previous valueof n next_2, which was next_3.  ugh.  Anyway, I'll verify
> that Kazu's patch handles this correctly.

I think so. :-)

What thread_across_edge is really trying to do is "What would these
statements in E->dest look like if they appeared at the end of
E->src?"  Then the question is reduced to whether each statement in
E->dest is translated correctly.  To do the translation, we use
SSA_NAME_VALUE, but note that we don't use it iteratively.  In other
words, given a SSA_NAME variable VAR, we don't do this

  while (TREE_CODE (var) == SSA_NAME
 && SSA_NAME_VALUE (var) != NULL_TREE)
var = SSA_NAME_VALUE (var);

because SSA_NAME_VALUE is supposed to be closed so that you won't need
to iterate.  So when we follow "copy-of" relation from tmp_1 to next_2
using SSA_NAME_VALUE, we don't follow next_2 to something else.

Note also that lookup_avail_expr does not translate the expression in
hash table using SSA_NAME_VALUE.  What we translate is the expression
that we look up.

p.s.
By the way, I am now wondering how many times we succeed in threading
a back edge.

Kazu Hirata


-- 


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


[Bug java/18931] New: jar -> .so optimization problem

2004-12-10 Thread overholt at redhat dot com
When natively compiling Eclipse jars with -O2, I get a compiler error:

$ gcj -fnew-verifier -fPIC -fjni -findirect-dispatch -shared -O2 -o
eclipse/startup.jar.so eclipse/startup.jar
org/eclipse/core/launcher/Main.java: In class 'org.eclipse.core.launcher.Main':
org/eclipse/core/launcher/Main.java: In method
'org.eclipse.core.launcher.Main.adjustTrailingSlash(java.net.URL,boolean)':
org/eclipse/core/launcher/Main.java:0: internal compiler error: in
copy_to_mode_reg, at explow.c:635

Compiling without -O2 (exact same other arguments) gives no errors.

startup.jar can be found here: 
http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/org.eclipse.releng.basebuilder/

$ gcj --version
gcj (GCC) 4.0.0 20041130 (experimental)

-- 
   Summary: jar -> .so optimization problem
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: overholt at redhat dot com
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=18931


[Bug middle-end/18903] [4.0 Regression] ice in bsi_after_labels

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-10 
19:32 ---
Subject: Bug 18903

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-10 19:32:14

Modified files:
gcc: ChangeLog tree-cfg.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/compile: pr18903.c 

Log message:
2004-12-10  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/18903
* gcc.c-torture/compile/pr18903.c: New test.

2004-12-10  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/18903
* tree-cfg.c (remove_bb): Put the moved label at the beginning
of the basic block.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6773&r2=2.6774
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&r1=2.133&r2=2.134
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4736&r2=1.4737
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr18903.c.diff?cvsroot=gcc&r1=NONE&r2=1.1


--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
19:32 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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


[Bug other/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic

2004-12-10 Thread rth at gcc dot gnu dot org

--- Additional Comments From rth at gcc dot gnu dot org  2004-12-10 19:40 
---
If addvsi3 actually performs addvdi3, that will be most surprising to
everyone.  I think that's a very bad idea.  Since we are not invoking
addvsi3, and I suspect it's impossible to convince the compiler to do
so, I think there's no reason to provide the backward compatibility
function at all; the symbol was unused and unusable.

-- 


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


[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

2004-12-10 Thread kazu at cs dot umass dot edu

--- Additional Comments From kazu at cs dot umass dot edu  2004-12-10 19:57 
---
Subject: Re:  [4.0 regression] loop
 miscompilation at -O1 (-ftree-ch)

Hi Jeff,

> > I think so. :-)
> I don't.  :(  I think it'll record tmp_1 = next_2, which is actually
> wrong, even though it doesn't actually cause problems with this
> testcase.

IMHO, you should really think of it as tmp_1 -> next_2 or "tmp_1 is a
copy-of next_2".  It is a one-way relation, not an equivalence because
it is not symmetric.

In other words, tmp_1 -> next_2 (or SSA_NAME_VALUE (tmp_1) == next_2)
means that tmp_1 should be replaced with next_2 if you were moving a
statement in E->dest to E->src.  The other direction does not hold
because next_2 should *not* be replaced with tmp_1.  It should be
replaced with 0 instead.

Let me also think hard to see if I can prove my patch is correct or
come up with a counterexample.  I certainly don't intend to push my
patch blindly.

Oh, by the way, let's wait on putting the testcase.  I am pretty sure
people will complain about a "regression" in their test results.

Kazu Hirata


-- 


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


[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

2004-12-10 Thread kazu at cs dot umass dot edu

--- Additional Comments From kazu at cs dot umass dot edu  2004-12-10 20:14 
---
Subject: Re:  [4.0 regression] loop
 miscompilation at -O1 (-ftree-ch)

Hi Jeff,

> BTW, I may have a nice clean way to deal with this problem which doesn't
> depend on us not walking the SSA_NAME_VALUE chain.
> 
> I'm looking into it now...

That would be great.

FYI, the only reason I am sticking to correct maintanance of
SSA_NAME_VALUE is that thread_across_edge is not the only function
that translates PHI results to PHI arguments on edge E.
lookup_avail_expr, for example, also uses SSA_NAME_VALUE, and we do
call lookup_avail_expr at tree-ssa-dom.c:582 without translating PHI
arguments on our own.

Kazu Hirata


-- 


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


[Bug tree-optimization/18694] [4.0 regression] loop miscompilation at -O1 (-ftree-ch)

2004-12-10 Thread law at redhat dot com

--- Additional Comments From law at redhat dot com  2004-12-10 20:52 ---
Subject: Re:  [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)

On Fri, 2004-12-10 at 19:08 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu  2004-12-10 
> 19:08 ---
> Subject: Re:  [4.0 regression] loop
>  miscompilation at -O1 (-ftree-ch)
> 
> Hi Jeff,
> 
> > Note that recording tmp_1 = next_2 isn't particularly good either since 
> > tmp_1 really isn't equivalent to next_2.  It's equivalent to the
> > previous valueof n next_2, which was next_3.  ugh.  Anyway, I'll verify
> > that Kazu's patch handles this correctly.
> 
> I think so. :-)


So as I mentioned in a message a short while ago, there are some very
simple solutions to this problem.

  1. The simplest would be to disable jump threading on for backedges in
  loops.  Based on some simple instrumentation, that would be bad as
  it would inhibit a large number of threading opportunities (at least
  two hundred within GCC's cc1 .i files).

  2. Disable threading only if we find a PHI argument which was set
  by a PHI the same block.  This still disables a lot of threading
  opportunities. However, we can do much better with a trivial 
  improvement

  3. Given a PHI node like x_2 = (..., x_2, ...); if we want the x_2
  alternative, then there's no need to inhibit jump threading since
  x_2 is always trivially equivalent to itself.

Option #3 only prevents two valid jump threading opportunities in the
tests I ran.  And it's implementation is pretty trivial:  


  /* Each PHI creates a temporary equivalence, record them.  */
  for (phi = phi_nodes (e->dest); phi; phi = PHI_CHAIN (phi))
{
  tree src = PHI_ARG_DEF_FROM_EDGE (phi, e);
  tree dst = PHI_RESULT (phi);

  /* If the desired argument is not the same as this PHI's result
 and it is set by a PHI in this block, then we can not thread
 through this block.  */
  if (src != dst
  && TREE_CODE (src) == SSA_NAME
  && TREE_CODE (SSA_NAME_DEF_STMT (src)) == PHI_NODE
  && bb_for_stmt (SSA_NAME_DEF_STMT (src)) == e->dest)
return;

  record_const_or_copy (dst, src);
  register_new_def (dst, &block_defs_stack);
}


A final approach would be to turn that code into something like this:

  /* Each PHI creates a temporary equivalence, record them.  */
  for (phi = phi_nodes (e->dest); phi; phi = PHI_CHAIN (phi))
{
  tree src = PHI_ARG_DEF_FROM_EDGE (phi, e);
  tree dst = PHI_RESULT (phi);

  /* If the desired argument is not the same as this PHI's result
 and it is set by a PHI in this block, then we can not thread
 through this block.  */
  if (src != dst
  && TREE_CODE (src) == SSA_NAME
  && TREE_CODE (SSA_NAME_DEF_STMT (src)) == PHI_NODE
  && bb_for_stmt (SSA_NAME_DEF_STMT (src)) == e->dest)
{
  src = make_ssa_name (SSA_NAME_VAR (dst), build_empty_stmt());
}

  record_const_or_copy (dst, src);
  register_new_def (dst, &block_defs_stack);
}

Which would allow us to do full jump threading.  What I don't like about
this approach is we have to add some code to track the SSA_NAMEs we
generate in that loop so that we can release them.  Ugh.  It doesn't 
seem worth the headache.

Jeff



-- 


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


[Bug middle-end/16417] [4.0 Regression] crappy code (gcc.c-torture/compile/20020210-1.c) in arguments causes ICE

2004-12-10 Thread echristo at redhat dot com

--- Additional Comments From echristo at redhat dot com  2004-12-10 20:55 
---
I just retried the attached patch and get a different failure in:

#1  0x080f188d in gimple_add_tmp_var (tmp=0xf6d5cba0)
at /lyorn/sourceware/combined/gcc/gimplify.c:531
531   gcc_assert (!TREE_CHAIN (tmp) && !DECL_SEEN_IN_BIND_EXPR_P (tmp));
(gdb) list
526 }
527
528 void
529 gimple_add_tmp_var (tree tmp)
530 {
531   gcc_assert (!TREE_CHAIN (tmp) && !DECL_SEEN_IN_BIND_EXPR_P (tmp));
532
533   DECL_CONTEXT (tmp) = current_function_decl;
534   DECL_SEEN_IN_BIND_EXPR_P (tmp) = 1;
535

backtrace:

(gdb) bt
#0  fancy_abort (file=0x84fa090 "/lyorn/sourceware/combined/gcc/gimplify.c",
line=531, function=0x84fa1e5 "gimple_add_tmp_var")
at /lyorn/sourceware/combined/gcc/diagnostic.c:556
#1  0x080f188d in gimple_add_tmp_var (tmp=0xf6d5cba0)
at /lyorn/sourceware/combined/gcc/gimplify.c:531
#2  0x080f3889 in gimplify_decl_expr (stmt_p=0xf6d56458)
at /lyorn/sourceware/combined/gcc/gimplify.c:1046
#3  0x080ff432 in gimplify_expr (expr_p=0xf6d56458, pre_p=0xfee46310,
post_p=0xfee4630c, gimple_test_f=0x80ef92a ,
fallback=fb_none) at /lyorn/sourceware/combined/gcc/gimplify.c:3671
#4  0x080fea2f in gimplify_stmt (stmt_p=0xf6d56458)
at /lyorn/sourceware/combined/gcc/gimplify.c:3430

And I'll attach the preprocessed file for 20020210-1.c for mipsisa64-elf.

-- 


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


[Bug target/18932] [3.4 regression] -march=pentium4 -O2 causes ICE

2004-12-10 Thread belyshev at lubercy dot com

--- Additional Comments From belyshev at lubercy dot com  2004-12-10 21:06 
---
// small testcase:

int bar (int p, char c)
{
 foo (p, c);
 if (c & 0xF0)
  return p;
}


-- 
   What|Removed |Added

  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |
  Known to fail||3.4.4
  Known to work||3.4.3
   Last reconfirmed|-00-00 00:00:00 |2004-12-10 21:06:02
   date||
   Target Milestone|--- |3.4.4


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


[Bug c++/15684] Pointer to member function called on incomplete type should diag

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
21:09 ---
*** Bug 18933 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||efrias at syncad dot com


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


[Bug target/18932] [3.4 regression] -march=pentium4 -O2 causes ICE

2004-12-10 Thread hjl at lucon dot org

--- Additional Comments From hjl at lucon dot org  2004-12-10 20:23 ---
Created an attachment (id=7721)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7721&action=view)
A testcase

I got

[EMAIL PROTECTED] tmp]$ /usr/gcc-3.4/bin/gcc -O2 -march=pentium4  -S ~/foo.c
/export/home/hjl/foo.c: In function `amd74xx_ide_dma_check':
/export/home/hjl/foo.c:16297: error: insn does not satisfy its constraints:
(insn 106 48 50 1 (parallel [
(set (reg:CCNO 17 flags)
(compare:CCNO (and:QI (reg/v:QI 4 si [orig:66 speed ] [66])
(const_int -16 [0xfff0]))
(const_int 0 [0x0])))
(set (reg/v:QI 4 si [orig:66 speed ] [66])
(and:QI (reg/v:QI 4 si [orig:66 speed ] [66])
(const_int -16 [0xfff0])))
]) 205 {*andqi_2} (nil)
(expr_list:REG_UNUSED (reg/v:QI 4 si [orig:66 speed ] [66])
(nil)))
/export/home/hjl/foo.c:16297: internal compiler error: in
copyprop_hardreg_forward_1, at regrename.c:1549
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=18932


[Bug c++/15684] Pointer to member function called on incomplete type should diag

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
21:41 ---
Ok, now we produce an error_mark_node which seems wrong if we don't produce an 
error.

-- 


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


[Bug c++/18934] New: Spurious Uninitialized Variable Warning

2004-12-10 Thread llewins at raytheon dot com
// Spurious Uninitialized Variable Warning (gcc 3.4.3)
// Lloyd Lewins
// Raytheon Co
// [EMAIL PROTECTED]
//
// Using gcc 3.4.3, the following spurious warning regarding rFileName is 
generated:
/*
> g++-343 -v -c -Wno-deprecated -Wall -O2 test1.cc
Reading specs from /usr/local/lib/gcc/i686-pc-cygwin/3.4.3/specs
Configured with: /usr/local/src/gcc-3.4.3/configure --prefix=/usr/local --progra
m-suffix=-343 --enable-languages=c,c++ --with-gcc --with-gnu-ld --with-gnu-as --
enable-threads=posix --enable-nls --enable-shared
Thread model: posix
gcc version 3.4.3
 /usr/local/libexec/gcc/i686-pc-cygwin/3.4.3/cc1plus.exe -quiet -v -D__CYGWIN32_
_ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/../include/w32api
-idirafter /usr/local/lib/gcc/i686-pc-cygwin/3.4.3/../../../../../include/w32api
 test1.cc -quiet -dumpbase test1.cc -mtune=pentiumpro -auxbase test1 -O2 -Wno-de
precated -Wall -version -o /tmp/ccJ5ooP1.s
ignoring nonexistent directory "/usr/local/lib/gcc/i686-pc-cygwin/3.4.3/../../..
/../i686-pc-cygwin/include"
ignoring duplicate directory "/usr/local/lib/gcc/i686-pc-cygwin/3.4.3/../../../.
./../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/i686-pc-cygwin/3.4.3/../../../../include/c++/3.4.3
 /usr/local/lib/gcc/i686-pc-cygwin/3.4.3/../../../../include/c++/3.4.3/i686-pc-c
ygwin
 /usr/local/lib/gcc/i686-pc-cygwin/3.4.3/../../../../include/c++/3.4.3/backward
 /usr/local/include
 /usr/local/lib/gcc/i686-pc-cygwin/3.4.3/include
 /usr/include
 /usr/lib/../include/w32api
End of search list.
GNU C++ version 3.4.3 (i686-pc-cygwin)
compiled by GNU C version 3.4.3.
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=130998
test1.cc: In function `int main()':
test1.cc:56: warning: unused variable 'c'
test1.cc:59: warning: 'rFileName' might be used uninitialized in this function
 as -o test1.o /tmp/ccJ5ooP1.s
*/

// Since rFileName is initialized at definition, it is hard to see how it is 
ever
// uninitialized!!

extern void foo();
extern void bar(char* );
extern char* foobar();

class C {public: ~C() {foo();}};

int main()
{
C c;

// Try to open the reserve file -- check for error
char* rFileName = foobar();

// Read the reserve file -- catch exceptions
try {
foo();
}
catch (...) {
bar(rFileName);
}

foo();

}

-- 
   Summary: Spurious Uninitialized Variable Warning
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: llewins at raytheon dot com
CC: gcc-bugs at gcc dot gnu dot org,llewins at raytheon dot
com


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


[Bug c/18930] name clash in C?

2004-12-10 Thread jacob at engelbrecht dot dk

--- Additional Comments From jacob at engelbrecht dot dk  2004-12-10 23:30 
---
Then I do not understand why the second program is legal?
(After a bit of experimentation I found out that if the type name is used as
variable name then it can not be used as a typename again). I would
Think that either type names are in the same name space as variable names, and
then both programs should be erronous (This I think is correct after rereading K
& R), or they are in different namespaces and then both programs should be
correct (although it might be difficult or impossible to implement). 

The following piece of code does not bark when compiled unless JE is defined

typedef int i;
i main()
{
  i i;
#ifdef JE
  i p;
#endif
  return i = 1;
}

regards

Jacob

-- 


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


Compiler gives internal error and uses all system ram (over 256 megs)

2004-12-10 Thread belgarath

>Submitter-Id:  net
>Originator:BelGarath of The Vale
>Organization:  
>Confidential:  no
>Synopsis:  GCC gives internal error and uses all sytem ram before doing so.
>Severity:  critical

Priority:   medium
>Category: c
>Class: sw-bug 
>Release:   3.4.1
>Environment:
System: Linux rowan 2.4.19 #1 Fri Oct 4 18:36:11 EDT 2002 sparc64 unknown
Architecture: sparc64


host: sparc64-unknown-linux-gnu
build: sparc64-unknown-linux-gnu
target: sparc64-unknown-linux-gnu
configured with: ./configure --with-cpu=ultrasparc 
--enable-languages=c,c++,objc,obj-c++ : (reconfigured) ./configure 
--with-cpu=ultrasparc --enable-languages=c,c++,objc
>Description:
Compilation of flite fails and gives internal compiler error after 
using alll available system ram. Problem files
are the language files most noteably 'cmu_us_kal16_diphone.c' of all 
versions tested.

Flite code available at 

http://www.speech.cs.cmu.edu/flite/packed/flite-1.2/flite-1.2-release.tar.gz 

http://www.speech.cs.cmu.edu/flite/packed/flite-1.1/flite-1.1-release.tar.gz
>How-To-Repeat:
Simply download source and compile it using standard ./configure && make dance.
>Fix:
Fix gcc so it doesnt use all 256 megs of memory and fail due to what I 
think is a malloc() failing.
Getting rid of code bloat would work too ;)


[Bug rtl-optimization/16613] [3.4 Regression] compile time regression, when adding cerr usage

2004-12-10 Thread andre dot maute at gmx dot de

--- Additional Comments From andre dot maute at gmx dot de  2004-12-11 
03:28 ---
now with --disable-checking in the configure parameters for gcc-4.0 
 
> g++-4.0-20041205-1-dc -v 
Reading specs 
from /opt/gcc-4.0-20041205-1-dc/lib/gcc/i686-pc-linux-gnu/4.0.0/specs 
Configured with: ../gcc-4.0-20041205/configure 
--prefix=/opt/gcc-4.0-20041205-1-dc --enable-shared --enable-languages=c,c++ 
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu 
--disable-nls --program-suffix=-4.0-20041205-1-dc --with-arch=pentium3 
--disable-checking 
Thread model: posix 
gcc version 4.0.0 20041205 (experimental) 
 
> time g++-4.0-20041205-1-dc -c -O3 -D __NDEBUG__ compiletimetest2.cc 
real0m18.300suser0m18.050ssys  0m0.250s 
> time g++-4.0-20041205-1-dc -c -O3 -D __DEBUG__ compiletimetest2.cc 
real0m21.368suser0m20.960ssys  0m0.440s 
 
this looks much better but not as good as with g++-3.3.5 

-- 


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


[Bug target/18002] [3.4 Regression] 'while' loop performace regression on avr target

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-11 
07:41 ---
Fixed on the mainline at least.

-- 
   What|Removed |Added

Summary|[3.4/4.0 Regression] 'while'|[3.4 Regression] 'while'
   |loop performace regression  |loop performace regression
   |on avr target   |on avr target


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


RE: bug in /usr/include/c++/3.4/bits/fstream.tcc

2004-12-10 Thread Jacob Schmidt Madsen
please ignore the previous message. i was my mistake, since i had
include some work from another guy, who had "using namespace std" and
also defined a "min" and "max" - it causes a conflict.

sorry about the trouble!

-Oprindelig meddelelse-
Fra: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sendt: 9. december 2004 22:21
Til: Jacob Schmidt Madsen
Cc: [EMAIL PROTECTED]
Emne: Re: bug in /usr/include/c++/3.4/bits/fstream.tcc


"Jacob Schmidt Madsen" <[EMAIL PROTECTED]> writes:

| error:
| /usr/include/c++/3.4/bits/fstream.tcc: In member function `virtual
| typename std::basic_filebuf<_CharT, _Traits>::int_type
| std::basic_filebuf<_CharT, _Traits>::underflow()':
| /usr/include/c++/3.4/bits/fstream.tcc:277: error: expected
| unqualified-id before '(' token
| /usr/include/c++/3.4/bits/fstream.tcc: In member function `virtual
| std::streamsize std::basic_filebuf<_CharT, _Traits>::xsputn(const
| _CharT*, std::streamsize)':
| /usr/include/c++/3.4/bits/fstream.tcc:518: error: expected
| unqualified-id before '(' token
| 
| solution found at:
| http://gcc.gnu.org/ml/gcc-bugs/2004-07/msg02128.html
| 
| fix:
| change line 277 in /usr/include/c++/3.4/bits/fstream.tcc
| from: __ilen = std::min(__avail, __buflen);
| to: __ilen = min(__avail, __buflen);

I cannot see any reason why that would be a fix.

-- Gaby


[Bug bootstrap/18125] bootstrap fails in libstdc++'s configure script, ICE on every C++ conftest.

2004-12-10 Thread debian-gcc at lists dot debian dot org

--- Additional Comments From debian-gcc at lists dot debian dot org  
2004-12-10 08:27 ---
not reproducible anymore with 2004-12-04

  Matthias

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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


[Bug fortran/16511] Test 19990905-0.f fails with gfortran

2004-12-10 Thread paulthomas2 at wanadoo dot fr

--- Additional Comments From paulthomas2 at wanadoo dot fr  2004-12-10 
08:56 ---
(In reply to comment #7)

The COMMON block has nothing to do with the problem:

subroutine sub(a)
  integer :: m=2,n=2
  real a(m,n)
end subroutine sub

Fails to compile too, with the same message.

-- 


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


[Bug c/18919] New: print_address_operand produces segmentation fault

2004-12-10 Thread bastian42 at monlynx dot de
The fprintf() on mingw gets to many parameters and thus produces a segmentation 
fault.
config/rs6000/rs6000.c:9595
Original line:
   fprintf (file, HOST_WIDE_INT_PRINT_DEC "(%s)",
   INTVAL (XEXP (x, 1)), reg_names[ REGNO (XEXP (x, 0)) ]);
The compiled code passes an additional parameter between INTVAL and reg_names.

workaround, splitting into separate fprintfS:
  fprintf(file,HOST_WIDE_INT_PRINT_DEC,INTVAL (XEXP (x,1)));
fprintf(file,"(%s)",reg_names[ REGNO (XEXP (x,0)) ]);

Note: It is very likely a bug in the mingw32 implementation.

-- 
   Summary: print_address_operand produces segmentation fault
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bastian42 at monlynx dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: mingw32
GCC target triplet: powerpc-elf


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


[Bug target/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic

2004-12-10 Thread ebotcazou at gcc dot gnu dot org

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-10 
09:53 ---
This fails on all 64-bit targets.


-- 
   What|Removed |Added

  GCC build triplet|x86_64-unknown-linux-gnu|*-*-*
   GCC host triplet|x86_64-unknown-linux-gnu|*-*-*
 GCC target triplet|x86_64-unknown-linux-gnu|*-*-*
  Known to fail|4.0.0   |3.4.3 4.0.0


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


[Bug fortran/12366] array assignment fails

2004-12-10 Thread paulthomas2 at wanadoo dot fr

--- Additional Comments From paulthomas2 at wanadoo dot fr  2004-12-10 
09:54 ---
For what it is worth:

program testg
real, dimension(5) :: a=(/ 1.5,2.1,3.2,4.6,5.3 /)
integer,dimension(3) :: i
i=(/ 2,3,1 /)
print *, a((/ 2,3,1 /))   ! ICEs
! print *, a(i)   !works fine
end

-- 


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


[Bug target/18459] [4.0 Regression] gcj no longer works on win32

2004-12-10 Thread dannysmith at users dot sourceforge dot net

--- Additional Comments From dannysmith at users dot sourceforge dot net  
2004-12-10 10:09 ---
Rutger,
Did you do a clean rebuild of libgcj.a after applying these patches?
Either works for me after native bootstrap on mingw32 host.  The second patch, 
however, does require CVS bunutils to get weak linkage to work correctly.

Danny



-- 


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


[Bug target/18665] [3.4/4.0 Regression] -ftrapv borks up simple integer arithmetic

2004-12-10 Thread ebotcazou at gcc dot gnu dot org

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-10 
10:11 ---
OK, I understand what happens: the 5 symbols __absvdi2, __addvdi3, __subvdi3,
__mulvdi3 and __negvdi2 are not #defined in libgcc2.h, hence not tweaked based
on the word size.  They are, therefore, double-word symbols everywhere, which
doesn't work on 64-bit targets.

The fix is straightforward, however there is a hitch: on 64-bit targets, libgcc
will contain 5 new symbols (__absvti2, __addvti3, __mulvti3, __negvti2,
__subvti3)  and will not contain (__absvsi2, __addvsi3, __mulvsi3, __negvsi2,
__subvsi3) anymore.  While the former is OK, the latter is probably not so we
might need to provide stubs that will redirect them to the equivalent mode-sized
routines for backwards compatibility.

Richard, does that sound plausible?


-- 


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


[Bug rtl-optimization/16968] [3.4 Regression] loop optimizer miscompilation

2004-12-10 Thread ebotcazou at gcc dot gnu dot org

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-10 
10:29 ---
Investigating, RTX_UNCHANGING_P was my preferred RTL flag. ;-)


-- 
   What|Removed |Added

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


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


[Bug libfortran/18879] ? not supported in namelist input

2004-12-10 Thread Thomas dot Koenig at online dot de


-- 
   What|Removed |Added

   Severity|normal  |enhancement
 Status|WAITING |NEW
 Ever Confirmed||1
   Priority|P2  |P3


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


[Bug tree-optimization/18888] [4.0 regression] loops miscompiled

2004-12-10 Thread steven at gcc dot gnu dot org

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 
11:05 ---
The patch identified in comment #7 really can't have caused this,
at worst it uncovered a latent bug because the order of edges is
changed after this patch - but no pass should depend on the edges
being in any specific order so the bug is elsewhere.


-- 


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


[Bug tree-optimization/18921] New: [4.0 Regression] wrong code with operator "?"

2004-12-10 Thread belyshev at lubercy dot com
this program aborts if compiled with any options:

extern void abort (void);

int foo (int k)
{
  unsigned char j = 0;
  (k ? 0 : j++) == -1;
  return j;
}

int main ()
{
  if (!foo (0))
abort ();
  return 0;
}


-- 
   Summary: [4.0 Regression] wrong code with operator "?"
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: critical
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: belyshev at lubercy dot com
CC: gcc-bugs at gcc dot gnu dot org


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


[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

2004-12-10 Thread steven at gcc dot gnu dot org

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 
11:18 ---
Backtrace from amd64 (Prescott) at -O0

#0  fancy_abort (file=0x95711e "../../mainline/gcc/recog.c", line=2020,
function=0x957139 "extract_insn") at diagnostic.c:556
#1  0x00766d08 in _fatal_insn (msgid=0x95e5fb "unrecognizable insn:",
insn=0x2a95895cd0, file=0x95711e "../../mainline/gcc/recog.c", line=2020,
function=0x957139 "extract_insn") at rtl-error.c:120
#2  0x00766d45 in _fatal_insn_not_found (insn=0x2a95895cd0,
file=0x95711e "../../mainline/gcc/recog.c", line=2020,
function=0x957139 "extract_insn") at rtl-error.c:128
#3  0x0072d290 in extract_insn (insn=0x2a95895cd0) at recog.c:2020
#4  0x00737b58 in scan_one_insn (insn=0x2a95895cd0, pass=0) at
regclass.c:1048
#5  0x00738225 in regclass (f=0x2a959ee3c0, nregs=66, dump=0x0)
at regclass.c:1253
#6  0x0079ef0c in rest_of_handle_old_regalloc () at passes.c:491
#7  0x007a0dc6 in rest_of_compilation () at passes.c:1718

t.c: In function 'test1':
t.c:11: error: unrecognizable insn:
(insn 21 19 22 2 (set (reg/f:DI 58 [ D.1469 ])
(const:DI (plus:DI (symbol_ref:DI ("foo") [flags 0x22] )
(const_int 16 [0x10] -1 (nil)
(nil))


-- 
   What|Removed |Added

  GCC build triplet|pentium3-pld-linux  |
   GCC host triplet|pentium3-pld-linux  |
 GCC target triplet|pentium3-pld-linux  |
Summary|[4.0 Regression] ice with - |[4.0 Regression]
   |O2 / works fine with -O0.   |unrecognisable insn in
   ||regclass on x86/amd64


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


[Bug tree-optimization/18921] [4.0 Regression] wrong code with operator "?"

2004-12-10 Thread belyshev at lubercy dot com


-- 
   What|Removed |Added

  Known to fail||4.0.0
  Known to work||3.3.5 3.4.4
   Target Milestone|--- |4.0.0


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


[Bug c++/18922] New: ICE in tree_low_cst, at tree.c:3315

2004-12-10 Thread a dot kral at sh dot cvut dot cz
I get ICE when trying to compile wmkbd, it works with gcc 3.2 but not with 3.3.5
nor 3.4.4

Reading specs from /usr/lib/gcc/i486-linux/3.4.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
--enable-shared --with-system-zlib --enable-nls --without-included-gettext
--program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk --disable-werror i486-linux
Thread model: posix
gcc version 3.4.4 20041128 (prerelease) (Debian 3.4.3-3)

g++-3.4 -Wall -g -DXLIB_ILLEGAL_ACCESS -O2 -save-temps -I/usr/openwin/include
-I/usr/local/include `glib-config --cflags` `gnome-config gnomeui --cflags`
`gtk-config --cflags` app.c -c -o app.o
In file included from app.c:76:
keysyms.c:921: internal compiler error: in tree_low_cst, at tree.c:3315
Please submit a full bug report,
with preprocessed source if appropriate.

-- 
   Summary: ICE  in tree_low_cst, at tree.c:3315
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: a dot kral at sh dot cvut dot cz
CC: gcc-bugs at gcc dot gnu dot org


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


[Bug c++/18922] ICE in tree_low_cst, at tree.c:3315

2004-12-10 Thread a dot kral at sh dot cvut dot cz

--- Additional Comments From a dot kral at sh dot cvut dot cz  2004-12-10 
11:25 ---
Created an attachment (id=7718)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7718&action=view)
Preprocessed source


-- 


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


[Bug c++/18922] [3.4/4.0 Regression] ICE in tree_low_cst, at tree.c:3315

2004-12-10 Thread belyshev at lubercy dot com

--- Additional Comments From belyshev at lubercy dot com  2004-12-10 11:35 
---
// "minimized" testcase:

char *hebrewdb[0][2] = {};


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||3.3.5 3.4.4
  Known to work||4.0.0
   Last reconfirmed|-00-00 00:00:00 |2004-12-10 11:35:02
   date||
Summary|ICE  in tree_low_cst, at|[3.4/4.0 Regression] ICE  in
   |tree.c:3315 |tree_low_cst, at tree.c:3315
   Target Milestone|--- |3.4.4


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


[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

2004-12-10 Thread steven at gcc dot gnu dot org

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 
11:35 ---
Not the same but maybe related:

1   static __thread void *foo [2];
2  
   
3   test1 ()
4   {
5 void **D, **ivtmp12;
6   L0:;
7 D = &foo[2];
8 if (D != ivtmp12) goto L0;
9   }

$ ./cc1 f.c
 test1
 
f.c: In function 'test1':
f.c:9: error: impossible constraint in 'asm'

What asm...?


-- 


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


[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

2004-12-10 Thread steven at gcc dot gnu dot org

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 
11:44 ---
Minimal test case:
$ cat t.c
static __thread void *foo[2];
test1 ()
{
  void **ivtmp12;
  while (&foo[1] != ivtmp12);
}

$ ../cc1 t.c -fdump-rtl-expand-details
 test1
 
t.c: In function 'test1':
t.c:6: error: unrecognizable insn:
(insn 9 7 10 1 (set (reg/f:DI 58 [ D.1471 ])
(const:DI (plus:DI (symbol_ref:DI ("foo") [flags 0x22] )
(const_int 8 [0x8] -1 (nil)
(nil))
t.c:6: internal compiler error: in extract_insn, at recog.c:2020


Removing __thread makes the ICE go away.  It definitely looks related to
the error from comment #6, the insn that causes the ICE is precisely the
statement that is rejected when I feed the gimplified test case to the
compiler:

;; D.1471 = &foo[1]
(insn 9 7 0 (set (reg:DI 58 [ D.1471 ])
(const:DI (plus:DI (symbol_ref:DI ("foo") [flags 0x22] )
(const_int 8 [0x8] -1 (nil)
(nil))


-- 


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


[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

2004-12-10 Thread steven at gcc dot gnu dot org

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 
11:47 ---
Without __thread, insn 9 is almost identical except for the flags (this is
with -m32 fwiw):

 ;; D.1123 = &foo[1]
 (insn 9 7 0 (set (reg:SI 58 [ D.1123 ])
-(const:SI (plus:SI (symbol_ref:SI ("foo") [flags 0x2] )
+(const:SI (plus:SI (symbol_ref:SI ("foo") [flags 0x22] )
 (const_int 4 [0x4] -1 (nil)
 (nil))


-- 


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


[Bug tree-optimization/18888] [4.0 regression] loops miscompiled

2004-12-10 Thread schwab at suse dot de

--- Additional Comments From schwab at suse dot de  2004-12-10 12:00 ---
The patch did not help. -fno-tree-dominator-opts is a workaround. 

-- 


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


[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

2004-12-10 Thread steven at gcc dot gnu dot org

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-10 
12:04 ---
GCC 3.3.5 (SUSE 9.2) produces this RTL for the ICEing statement:

(insn 11 10 12 (nil) (set (reg:DI 61)
(symbol_ref:DI ("foo"))) -1 (nil)
(nil))
   
  
(insn 12 11 13 (nil) (parallel [
(set (reg:DI 60)
(plus:DI (reg:DI 61)
(const_int 8 [0x8])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))



-- 


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


[Bug fortran/18923] New: segfault after subroutine name confusion

2004-12-10 Thread Thomas dot Koenig at online dot de
The code below is invalid, but it's not that
bad that a segfault is called for :-)

$ cat sel_int_kind.f90
program foo
contains
  subroutine foo(i)
integer :: i
character(len=selected_int_kind(i)) :: c
  end subroutine bar
end program foo
$ gfortran sel_int_kind.f90
 In file sel_int_kind.f90:3

  subroutine foo(i)
   1
Error: PROGRAM attribute conflicts with PROCEDURE attribute at (1)
 In file sel_int_kind.f90:4

integer :: i
   1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file sel_int_kind.f90:5

character(len=selected_int_kind(i)) :: c
   1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file sel_int_kind.f90:6

  end subroutine bar
1
Error: Expecting END PROGRAM statement at (1)
sel_int_kind.f90:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$ gfortran -v
Reading specs from /home/zfkts/lib/gcc/ia64-unknown-linux-gnu/4.0.0/specs
Configured with: ../gcc-4.0-20041205/configure --prefix=/home/zfkts
--enable-languages=c,c++,f95 --disable-shared
Thread model: posix
gcc version 4.0.0 20041205 (experimental)

Here's a backtrace:

$ gdb ~/libexec/gcc/ia64-unknown-linux-gnu/4.0.0/f951
GNU gdb Red Hat Linux (6.1post-1.20040607.17rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "ia64-redhat-linux-gnu"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

(gdb) r sel_int_kind.f90
Starting program: /home/zfkts/libexec/gcc/ia64-unknown-linux-gnu/4.0.0/f951
sel_int_kind.f90
 In file sel_int_kind.f90:3

  subroutine foo(i)
   1
Error: PROGRAM attribute conflicts with PROCEDURE attribute at (1)
 In file sel_int_kind.f90:4

integer :: i
   1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file sel_int_kind.f90:5

character(len=selected_int_kind(i)) :: c
   1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file sel_int_kind.f90:6

  end subroutine bar
1
Error: Expecting END PROGRAM statement at (1)

Program received signal SIGSEGV, Segmentation fault.
gfc_resolve_expr (e=0x600e7200)
at ../../gcc-4.0-20041205/gcc/fortran/resolve.c:2084
2084  if (sym->attr.flavor == FL_PROCEDURE && !sym->attr.function)
(gdb) bt
#0  gfc_resolve_expr (e=0x600e7200)
at ../../gcc-4.0-20041205/gcc/fortran/resolve.c:2084
#1  0x40085fb0 in resolve_actual_arglist (arg=0x600e6f10)
at ../../gcc-4.0-20041205/gcc/fortran/resolve.c:604
#2  0x40083f60 in gfc_resolve_expr (e=0x600e6de0)
at ../../gcc-4.0-20041205/gcc/fortran/resolve.c:942
#3  0x4008e090 in gfc_resolve (ns=0x600e67f0)
at ../../gcc-4.0-20041205/gcc/fortran/resolve.c:4666
#4  0x4008dff0 in gfc_resolve (ns=0x600e5bd0)
at ../../gcc-4.0-20041205/gcc/fortran/resolve.c:4658
#5  0x4007a520 in gfc_parse_file ()
at ../../gcc-4.0-20041205/gcc/fortran/parse.c:2612
#6  0x400adcb0 in gfc_be_parse_file (set_yydebug=-19536)
at ../../gcc-4.0-20041205/gcc/fortran/f95-lang.c:266
#7  0x4063d760 in toplev_main (argc=Variable "argc" is not available.
)
at ../../gcc-4.0-20041205/gcc/toplev.c:992
#8  0x40106220 in main (argc=2, argv=0x6fffb838)
at ../../gcc-4.0-20041205/gcc/main.c:35

-- 
   Summary: segfault after subroutine name confusion
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org


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


[Bug fortran/16898] Aliasing problem with array descriptors

2004-12-10 Thread pbrook at gcc dot gnu dot org

--- Additional Comments From pbrook at gcc dot gnu dot org  2004-12-10 
13:21 ---
This is not fixed. 
It still fails for me at -O2 in i686-linux. 

-- 


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


[Bug c++/18922] [3.3/3.4 Regression] ICE in tree_low_cst, at tree.c:3315

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
13:27 ---


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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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


[Bug c++/18384] [3.3/3.4/4.0 Regression] ICE on zero-length array with empty initializer...

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
13:27 ---
*** Bug 18922 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||a dot kral at sh dot cvut
   ||dot cz


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


[Bug target/16932] Compilation error for sh-coff-gcc little endian target

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
13:39 ---
So lets close it as fixed for 4.0.0 then.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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


[Bug target/18919] print_address_operand produces segmentation fault

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
13:44 ---
Fixed in 4.0.0 by changing the definition of HOST_LONG_LONG_FORMAT to be 
correct for mingw32.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |target
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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


[Bug libfortran/18924] New: segfault in dot_product with missing interface information

2004-12-10 Thread Thomas dot Koenig at online dot de
This one is a bit tricky.  It passes two arrays
to a subroutine, where they are passed on to the
intrinsic function dot_product.  However, they
are passed old-style, without interface information.
dot_product expects to receive only new-style arrays,
and generates a segfault in the executed program.

This one can't be caught at compile time (at least not
without inter-procedural analysis) because it's
the caller who determines wether to pass an old-style
or a new-style array.

$ cat dot_product.f90
program main
  implicit none
  real, dimension(2) :: a, b
  real :: c
  a = 1.
  b = -2.3
  call foo(a,b,c)
  print *,c
end program main

subroutine foo(a,b,c)
  real, dimension(:), intent(in) :: a, b
  real, intent(out) :: c
  c = dot_product(a,b)
end subroutine foo
$ gfortran dot_product.f90 && ./a.out
Segmentation fault
$ gfortran -v
Reading specs from /home/zfkts/lib/gcc/ia64-unknown-linux-gnu/4.0.0/specs
Configured with: ../gcc-4.0-20041205/configure --prefix=/home/zfkts
--enable-languages=c,c++,f95 --disable-shared
Thread model: posix
gcc version 4.0.0 20041205 (experimental)

-- 
   Summary: segfault in dot_product with missing interface
information
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org


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


[Bug c++/18920] internal compiler error: Segmentation fault

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
13:47 ---
Fixed in 3.4.0 and later:
pr18920.cc:16: error: template argument required for 'struct print_matrix'
pr18920.cc:16: error: types may not be defined in parameter types
pr18920.cc:20: error: two or more data types in declaration of 'parameter'
pr18920.cc:20: error: 'class std::vector >, std::
allocator > > >' is not a valid type 
for a template constant 
parameter
pr18920.cc:20: error: expected `>' before ';' token
pr18920.cc:26: error: expected unqualified-id at end of input

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||ice-on-invalid-code
 Resolution||FIXED
   Target Milestone|--- |3.4.0


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


[Bug fortran/17175] set_exponent breaks with integer*8 exponent

2004-12-10 Thread Tobias dot Schlueter at physik dot uni-muenchen dot de

--- Additional Comments From Tobias dot Schlueter at physik dot 
uni-muenchen dot de  2004-12-10 13:48 ---
Subject: Re:  set_exponent breaks with integer*8 exponent

paulthomas2 at wanadoo dot fr wrote:
> --- Additional Comments From paulthomas2 at wanadoo dot fr  2004-12-10 
> 13:35 ---
> You have fixed this one, haven't you? cvs 20041205 runs it fine.

I don't think so, maybe it's got hidden by another change.

> However, in testing, I found another nasty:
> 
> y = 1/2 + 1/8
> !y= 0.125 + 0.5 !!works OK

1/2 .EQ. 0 in Fortran, same for 1/8, this is integer division :-)

- Tobi


-- 


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


[Bug c++/18731] [3.3/3.4/4.0 regression] ICE on invalid template declaration

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
13:50 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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


[Bug target/18925] New: Invalid gprel relocation in PIC

2004-12-10 Thread schwab at suse dot de
$ cat gprel.cc 
class __attribute__ ((visibility("default"))) Type 
{ 
 private: 
  static long _staticTypeCount; 
 public: 
  Type() { _staticTypeCount++; } 
  ~Type(); 
}; 
 
long Type::_staticTypeCount = 0; 
 
Type::~Type() 
{ 
 _staticTypeCount--; 
} 
$ gcc -fPIC -fvisibility=hidden -S gprel.cc 
$ grep _staticTypeCount gprel.s 
.global _ZN4Type16_staticTypeCountE# 
.type   _ZN4Type16_staticTypeCountE#, @object 
.size   _ZN4Type16_staticTypeCountE#, 8 
_ZN4Type16_staticTypeCountE: 
addl r14 = @gprel(_ZN4Type16_staticTypeCountE#), gp 
addl r14 = @gprel(_ZN4Type16_staticTypeCountE#), gp 
addl r14 = @gprel(_ZN4Type16_staticTypeCountE#), gp 
addl r14 = @gprel(_ZN4Type16_staticTypeCountE#), gp

-- 
   Summary: Invalid gprel relocation in PIC
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-*-linux


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


[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
14:14 ---
Note the date for C++ is different:
: Search converges between 2004-08-30-trunk (#529) and 2004-08-31-trunk (#530).

-- 


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


[Bug target/18896] addressing split complex parm

2004-12-10 Thread amodra at bigpond dot net dot au

--- Additional Comments From amodra at bigpond dot net dot au  2004-12-10 
14:14 ---
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00682.html

-- 
   What|Removed |Added

   Keywords||ABI, ice-on-valid-code,
   ||patch, wrong-code


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


[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
14:18 ---
(In reply to comment #9)
> The fail dates from comment #3 probably refer to this change
> 
> 2004-10-17  Andrew Pinski  <[EMAIL PROTECTED]>
>   
>   
> * c-typeck.c (default_function_array_conversion): Always create
> &a[0] for array types.
> (build_unary_op): Do not fold &a[x] into a + x.
> 
> which was reverted again on the same day.  Can someone try with the reghunter
> to see if it failed before October 17 also?

What this tells me it is a latent bug in x86/x86_64 back-end as my change 
should not change what RTL 
is produced as it is the back-end's job to reject addressing modes.

-- 


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


[Bug libfortran/17597] list directed read has error

2004-12-10 Thread paulthomas2 at wanadoo dot fr

--- Additional Comments From paulthomas2 at wanadoo dot fr  2004-12-10 
14:24 ---
This runs correctly when read(10,*)I,X,P,Z,G is broken up into
read(10,*)I,X
read(10,*)P,Z,G



(In reply to comment #0)
> here is the list directed read example from the F2003 draft standard:
> $ cat a.f
> ! taken from F2003 standard
>integer I
>real X(8)
>data X / 8*0.0/
>character*20 P
>complex z
>logical g
>open(UNIT=10)
>write(10,'(A)') '12345,12345,,2*1.5,4*'
>write(10,'(A)') "ISN'T_BOB'S,(123,0),.TEXAS$"
>rewind(10)
>read(10,*)I,X,P,Z,G
>print*,I,X,P,Z,G
>end
>  
> $ gfc a.f
> $ ./a.out
> At line 12 of file a.f
> Fortran runtime error: Bad complex value in item 11 of list input
> $ g77 a.f
> $ ./a.out
>  12345  12345.  0.  1.5  1.5  0.  0.  0.  0.ISN'T_BOB'S  (123.,0.) T



-- 


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


[Bug fortran/17175] set_exponent breaks with integer*8 exponent

2004-12-10 Thread tobi at gcc dot gnu dot org

--- Additional Comments From tobi at gcc dot gnu dot org  2004-12-10 14:53 
---
BTW Paul, this depends on the endianess of your target, the error won't show up
on i686.  I'm currently testing a patch which should really fix this.

-- 


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


[Bug target/18925] [4.0 regression] Invalid gprel relocation in PIC

2004-12-10 Thread schwab at suse dot de


-- 
   What|Removed |Added

Summary|Invalid gprel relocation in |[4.0 regression] Invalid
   |PIC |gprel relocation in PIC


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


[Bug target/17767] [4.0 Regression] MMX intrinsics cause internal compiler error

2004-12-10 Thread uros at kss-loka dot si

--- Additional Comments From uros at kss-loka dot si  2004-12-10 15:34 
---
This patch will fix the mainline, but more investigation is needed.

Index: cse.c
===
RCS file: /cvs/gcc/gcc/gcc/cse.c,v
retrieving revision 1.327
diff -u -r1.327 cse.c
--- cse.c   26 Nov 2004 15:42:36 - 1.327
+++ cse.c   10 Dec 2004 15:30:34 -
@@ -3860,6 +3860,9 @@
 
 case RTX_COMPARE:
 case RTX_COMM_COMPARE:
+  if (VECTOR_MODE_P (mode))
+   break;
+
   /* See what items are actually being compared and set FOLDED_ARG[01]
 to those values and CODE to the actual comparison code.  If any are
 constant, set CONST_ARG0 and CONST_ARG1 appropriately.  We needn't

Uros.

-- 


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


[Bug c++/18926] New: internal compiler error: in tree_low_cst, at tree.c:3255

2004-12-10 Thread gcc-bugzilla at gcc dot gnu dot org


[EMAIL PROTECTED]:/tmp/s$ g++ -c foo.c
foo.c:16: internal compiler error: in tree_low_cst, at tree.c:3255
when compiling following code:

 8< [cut here] ---
typedef struct {
char *str;
int n;
char *(f[]);
char *(l[]);
int *a;
} t_moja;


t_moja x={
"foobar",
4,
{"imie","nazwisko","telefon","email"},
{"Imiê","Nazwisko","Telefon","E-mail"},
{0,1,2,3},
};


t_moja y={
"baz",
2,
{"dupa","blada"},
{"Pan","Kowalski"},
{8,9}
};

 8< [cut here] ---

Environment:
System: Linux blabluga.hell.pl 2.6.7bl #1 Sun Jul 4 17:47:48 CEST 2004 i686 
GNU/Linux
Architecture: i686


host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v 
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr 
--mandir=/usr/share/man --infodir=/usr/share/info 
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib 
--enable-nls --without-included-gettext --enable-__cxa_atexit 
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm 
--enable-java-awt=xlib --enable-objc-gc i486-linux

How-To-Repeat:
Save above snippet into file and run:
g++ -c filename

-- 
   Summary: internal compiler error: in tree_low_cst, at tree.c:3255
   Product: gcc
   Version: 3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arturcz at blabluga dot hell dot pl
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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


[Bug target/18927] New: O(n^2) compile time with -O0 (n= number of basic blocks) in global alloc

2004-12-10 Thread heinrich dot brand at fujitsu-siemens dot com
Some C-Code is (with Option -O0) processed by an algorithm with O(n^2) time.
This simple code scheme shows that the compile time grows fast with
the number of basic blocks in a function. If the number of 
basic blocks is doubled the compile time is almost quadrupled.
The output of -ftime-report shows that global alloc uses most of the time.  
But C-Code with a small difference has roughly O(n) compile time.
expensive code:
  if(*i0){int a; a=(*i1);*i2=(a/3+a/7);} : roughly O(n*n) compile time
  if(*i0){int a; a=(*i1);*i2=(a/3+(*i2)/7);} : roughly O(n*n) compile time
cheap code:
  if(*i0){int a; a=(*i1);*i2=(a*3+a*7);} : roughly  O(n)  compile time
  if(*i0){int a; a=(*i1);*i2=(a*3+(*i2)*7);} : roughly  O(n)  compile time

Used Code Scheme:

void test(int *i0,int *i1,int *i2){
  if(*i0){int a; a=(*i1);*i2=(a/3+a/7);}
  ... copies of the last statement
return;}

The body of the test function consists of a number of copies of 
the following Statement:
if(*i0){int a; a=(*i1);*i2=(a/3+a/7);}
Each statement produces 2 basic blocks.

Content of the following table:

BBs : number of basic blocks in if-statements
user: user time from /usr/bin/time gcc 
global_alloc : from output of -ftime-report 
lines of assembler code : lines of gcc output
(Intel Pentium 700Mhz or an old SPARC-Computer)

Table relating number of basic block to compile time for gcc 3.4.3 intel

BBs  user   global_alloclines of assembler code
---
100  0.22   0.12(55%)   1468
200  0.54   0.30(56%)   2918
400  1.36   0.91(67%)   5818
800  4.09   3.15(77%)   11618
1600 15.52  13.67   (88%)   23218
3200 76.63  72.87   (95%)   46418
6400 277.25 269.49  (97%)   92818
128001072.581057.20 (99%)   185618


Table relating number of basic block to compile time for gcc 3.2 intel
==
BBs  user   global_alloclines of assembler code
---
100  0.170.07(41%)   1369
200  0.370.15(42%)   2719
400  0.760.36(48%)   5419
800  1.530.76(50%)   10819
1600 3.501.80(52%)   21619
3200 8.134.59(56%)   43219
6400 21.59   14.33   (66%)   86419
1280062.03   45.75   (74%)   172819




Table relating number of basic block to compile time for gcc 3.4.3 sparc
=
BBs  user   global_alloclines of assembler code
---
100  0.320.05(16%)   1218
200  0.490.07(15%)   2418
400  0.870.16(19%)   4818
800  1.490.30(20%)   9618
1600 3.100.67(22%)   19218
3200 6.721.51(23%)   38418
6400 14.95   4.45(30%)   76818
1280054.73   32.43   (59%)   153618

Table relating number of basic block to compile time for gcc 2.95.2 sparc
=
BBs  user   global_alloclines of assembler code
---
100  0.111173
200  0.172323
400  0.304623
800  0.629223
1600 1.3518423
3200 2.9036823
6400 6.1973623
1280014.97   147223


Table relating number of basic block to compile time for gcc 3.4.3 intel
for this Code: if(*i0){int a; a=(*i1);*i2=(a*3+a*7);}
=
BBs  user   global_alloclines of assembler code
---
100  0.110.01(10%)   713
200  0.160.03(20%)   1413
400  0.350.07(21%)   2813
800  0.650.14(22%)   5613
1600 1.330.28(21%)   11213
3200 2.930.58(20%)   22413
6400 5.801.15(20%)   44813
1280012.09   2.68(22%)   89613


Shellscripts:
---
for x in  50 100 200 400 800 1600 3200 6400 
do
echo " $x"
run $x
done


---
[[ -z $1 ]] && exit 1
N=$1

echo 'void test(int *i0,int *i1,int *i2){' >z.c

IF="if(*i0){int a; a=(*i1);*i2=(a/3+(*i2)/7);}"

((i=$N))
while((i>0))
do
echo "  $IF" >>z.c
((i=i-1))
done
echo 'return;}' >>z.c

wc z.c
echo "$IF"
/usr/bin/time -p gcc -S -O0 -ftime-report z.c
((BB=N+N))
echo "### BB $BB"
wc z.s

-
gawk '
  $1=="g

[Bug c++/17868] [3.3 regression] RDIV_EXPR not supported by dump_expr

2004-12-10 Thread reichelt at gcc dot gnu dot org

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-12-10 
15:48 ---
Gaby, is this trivial patch OK for the 3.3 branch?


-- 


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


[Bug c++/18731] [3.3/3.4/4.0 regression] ICE on invalid template declaration

2004-12-10 Thread cvs-commit at gcc dot gnu dot org

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-10 
16:04 ---
Subject: Bug 18731

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-10 16:04:22

Modified files:
gcc/cp : ChangeLog parser.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/parse: struct-1.C struct-2.C struct-3.C 

Log message:
PR c++/18731
* parser.c (cp_parser_class_head): Reject typedef-name in class head.

* g++.dg/parser/struct-1.C: New test.
* g++.dg/parser/struct-2.C: New test.
* g++.dg/parser/struct-3.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4527&r2=1.4528
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.292&r2=1.293
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4734&r2=1.4735
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/struct-1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/struct-2.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/struct-3.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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


[Bug c++/18926] internal compiler error: in tree_low_cst, at tree.c:3255

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
16:08 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE
Version|3.3 |3.3.5


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


[Bug c++/18327] [3.3/3.4/4.0 Regression] ICE while compiling valid c code with g++

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
16:08 ---
*** Bug 18926 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||arturcz at hell dot pl


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


[Bug target/18925] [4.0 regression] Invalid gprel relocation in PIC

2004-12-10 Thread schwab at suse dot de

--- Additional Comments From schwab at suse dot de  2004-12-10 16:23 ---
Broken by 
 
2004-08-03  Mark Mitchell  <[EMAIL PROTECTED]> 
 
* class.c (build_vtable): Do not set DECL_VISIBILITY here. 
(check_field_decls): Or here. 
(check_methods): Or here. 
(initialize_array): Don't mess with DECL_CONTEXT. 
* cp-tree.h (start_decl): Adjust prototype. 
(determine_visibility): New function. 
* decl.c (duplicate_decls): Remove checks for hidden "operator 
new". 
(build_library_fn_1): Give all library functions default 
visibility. 
(start_decl): Add pop_scope_p parameter.  Tidy. 
(cp_finish_decl): Do not pop scopes here.  Call 
determine_visibility for variable definitions. 
(start_preparsed_function): Call determine_visibility. 
* decl2.c (determine_visibility): New function. 
* method.c (use_thunk): Fix formatting. 
* parser.c (cp_parser_condition): Adjust calls to start_decl. 
(cp_parser_init_declarator): Likewise. 
* pt.c (instantiate_decl): Always call pop_nested_class. 
* rtti.c (get_tinfo_decl): Do not set DECL_VISIBILITY. 
(tinfo_base_init): Likewise. 
 

-- 
   What|Removed |Added

 CC||mark at codesourcery dot com


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


[Bug target/18459] [4.0 Regression] gcj no longer works on win32

2004-12-10 Thread ovidr at users dot sourceforge dot net

--- Additional Comments From ovidr at users dot sourceforge dot net  
2004-12-10 16:35 ---
It was a completely fresh checkout to an empty dir (both times). I build a
linux->win32 cross. (building on win32 takes way too long due to fork()).

For the dwarf2 patch, I had used the one line patch from:
"http://sources.redhat.com/ml/binutils/2004-11/msg00249.html";
on the binutils-2.15.91-20040904-1-src.tar.gz from mingw.org.  If I don't need
any further patches(?), I will try to use binutils directly from cvs and build
it again.







-- 


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


[Bug c++/17868] [3.3 regression] RDIV_EXPR not supported by dump_expr

2004-12-10 Thread gdr at integrable-solutions dot net

--- Additional Comments From gdr at integrable-solutions dot net  
2004-12-10 16:53 ---
Subject: Re:  [3.3 regression] RDIV_EXPR not supported by dump_expr

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

| Gaby, is this trivial patch OK for the 3.3 branch?

Yes, thanks.

-- Gaby


-- 


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


[Bug middle-end/18928] ice on valid code with -O2 -fPIC

2004-12-10 Thread pinskia at gcc dot gnu dot org


-- 
   What|Removed |Added

  Component|other   |middle-end
   Keywords||ice-on-valid-code
Summary|ice on valid code.  |ice on valid code with -O2 -
   ||fPIC


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


[Bug bootstrap/15212] [3.4/4.0 Regression] bootstrap fails on interix3

2004-12-10 Thread neroden at gcc dot gnu dot org


-- 
   What|Removed |Added

 Status|WAITING |ASSIGNED
   Last reconfirmed|2004-04-29 21:27:43 |2004-12-10 16:59:27
   date||


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


[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch

2004-12-10 Thread neroden at gcc dot gnu dot org

--- Additional Comments From neroden at gcc dot gnu dot org  2004-12-10 
17:09 ---
Oh, cool.  :-)  Did you get the patch linked up? 

-- 


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


[Bug target/18153] [3.4/4.0 Regression] -static-libgcc links in libunwind.so.7

2004-12-10 Thread hjl at lucon dot org

--- Additional Comments From hjl at lucon dot org  2004-12-10 17:11 ---
An updated patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00757.html

-- 


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


[Bug rtl-optimization/16536] [3.3 regression] Incorrect __restrict__ optimization in -O2

2004-12-10 Thread reichelt at gcc dot gnu dot org

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-12-10 
17:26 ---
Fixed.


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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


[Bug libfortran/18891] write with no open causes core dump

2004-12-10 Thread pinskia at gcc dot gnu dot org

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-10 
17:44 ---
Patch here: .

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||patch
   Last reconfirmed|-00-00 00:00:00 |2004-12-10 17:44:02
   date||


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


[Bug middle-end/18928] ice on valid code with -O2 -fPIC

2004-12-10 Thread bangerth at dealii dot org

--- Additional Comments From bangerth at dealii dot org  2004-12-10 18:01 
---
This used to work with my somewhat outdated version 20041015; it must 
be a regression since then. 
 
W. 

-- 


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


[Bug libfortran/17597] list directed read has error

2004-12-10 Thread sgk at troutmask dot apl dot washington dot edu

--- Additional Comments From sgk at troutmask dot apl dot washington dot 
edu  2004-12-10 18:03 ---
The patch included here

http://gcc.gnu.org/ml/fortran/2004-12/msg00088.html

fixes this problem.

-- 
steve

-- 


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


[Bug middle-end/18928] [4.0 regression] ice on valid code with -O2 -fPIC

2004-12-10 Thread bangerth at dealii dot org

--- Additional Comments From bangerth at dealii dot org  2004-12-10 18:04 
---
I can, however, confirm the segfault on top-of-mainline. No reduced 
testcase, however. 
 
W. 

-- 
   What|Removed |Added

  Known to fail||4.0.0
Summary|ice on valid code with -O2 -|[4.0 regression] ice on
   |fPIC|valid code with -O2 -fPIC
   Target Milestone|--- |4.0.0


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


  1   2   >