[Bug c++/21907] New: poor diagnostic

[igodard at pacbell dot net]

struct  virt { virt() : i(2) {} virt(int i) : i(i){} int i;  };
struct der1 : public virtual virt { der1(int i) : virt(i) {} }
struct der2 : public virtual virt { der2(int i) : virt(i) {} }
struct top : public der1, public der2 {
top () : der1(0), der2(1) {} };


gets you:

~/ootbc/members/src$ g++ foo.cc
foo.cc:5: error: multiple types in one declaration

(actual error is code is trying to construct a virtual base class)

-- 
   Summary: poor diagnostic
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/21908] New: Even poorer diagnostic

[igodard at pacbell dot net]

struct  virt { virt() : i(2) {} virt(int i) : i(i){} int i;  };
struct der1 : public virtual virt { der1(int i) : virt(i) {} }
struct der2 : public virtual virt { der2(int i) : virt(i) {} }
struct top : public der1, public der2 {
top () : der1(0) {} };


gets you:

~/ootbc/members/src$ g++ foo.cc
foo.cc: In constructor `top::top()':
foo.cc:5: error: no matching function for call to `der2::der2(const void**)'
foo.cc:3: note: candidates are: der2::der2(const der2&)
foo.cc:3: note: der2::der2(int)
foo.cc: At global scope:
foo.cc:5: error: multiple types in one declaration

-- 
   Summary: Even poorer diagnostic
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/21909] New: Mis-identifies template

[igodard at pacbell dot net]

A function declared: "template void operator<<(const T&)"
when called with an l-value of type "invoke*" is invoked with T bound to
"invoke" (missing the "*"), as shown by the diagnostic in the example
attached. The diagnostic itself is not the problem, it just shows the incorrect
binding; the function body was expecting the pointer and didn't get it. Code
compiles fine if changed to expect a non-pointer and one is passed.

-- 
   Summary: Mis-identifies template
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/21909] Mis-identifies template

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-06-04 10:32 
---
Created an attachment (id=9027)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9027&action=view)
compiler output


-- 


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

[Bug c++/21909] Mis-identifies template

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-06-04 10:32 
---
Created an attachment (id=9028)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9028&action=view)
source code (compressed)


-- 


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

[Bug c++/21909] Mis-identifies template

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-06-04 10:37 
---
Sorry, my bad

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/21909] Mis-identifies template

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-06-04 10:42 
---
Sorry, not my bad after all :-(  I need some sleep.

Ivan

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

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

[e9925248 at stud4 dot tuwien dot ac dot at]

If old dump files for a testcase are left, if the name of the dump file has
changed, errors like the following occur:

ERROR: gcc.dg/tree-ssa/structopt-1.c: error executing dg-final: couldn't open
"structopt-1.c.t50.lim structopt-1.c.t53.lim": no such file or directory
UNRESOLVED: gcc.dg/tree-ssa/structopt-1.c: error executing dg-final: couldn't
open "structopt-1.c.t50.lim structopt-1.c.t53.lim": no such file or directory

Deleting all generated *.c.t* files in the testsuite directory, solves this 
problem.

I use dejagnu from the src-tree of sourceware.org.

-- 
   Summary: Files from previous runs can make some testcases fail
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: e9925248 at stud4 dot tuwien dot ac dot at
CC: gcc-bugs at gcc dot gnu dot org


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

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

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-06-04 
10:46 ---
I can't find anything in the standard which says that this should be an error, 
regardless of what Comeau does. This looks like a genuine bug in the parser, 
see parser.c:cp_parser_class_specifier: the parsing of the body of the in-
classe defined functions and default arguments is delayed until the whole class 
definition is parsed (this allows, eg., the body of in-class member functions 
to refer to other member functions which appear later within the struct 
definition).

There is some code which also delays inner functions until the outer function 
is finished:


  /* If this class is not itself within the scope of another class,
 then we need to parse the bodies of all of the queued function
 definitions.  Note that the queued functions defined in a class
 are not always processed immediately following the
 class-specifier for that class.  Consider:

   struct A {
 struct B { void f() { sizeof (A); } };
   };

 If `f' were processed before the processing of `A' were
 completed, there would be no way to compute the size of `A'.
 Note that the nesting we are interested in here is lexical --
 not the semantic nesting given by TYPE_CONTEXT.  In particular,
 for:

   struct A { struct B; };
   struct A::B { void f() { } };

 there is no need to delay the parsing of `A::B::f'.  */


I think this logic breaks down with instantiations: probably the DEFAULT_ARG 
nodes (representing an unparsed default argument) are copied from B (generic 
template) into B (implicit specialization created by instantiation), and 
never reparsed after that (in fact, I can't see how they could be put within 
parser->unparser_function_queue, which is private of the parser).

I did not check whether this is a regression or not.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-04 10:46:16
   date||


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

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

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-06-04 
10:48 ---
(In reply to comment #7)

> There is some code which also delays inner functions until the outer function 
> is finished:

Of course I meant "classes": "There is some code which also delays inner 
classes until the outer class is finished".

-- 


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

[Bug libstdc++/21796] (v7-branch) std::search not using std::find

[chris at bubblescope dot net]

--- Additional Comments From chris at bubblescope dot net  2005-06-04 12:07 
---
This is being held up by PR20408, Unnecessary code generated for empty structs, 
as we'd have to pass 
both the item to find and the comparitor (which is often an empty class) to 
std::find_if

-- 
   What|Removed |Added

  BugsThisDependsOn||20408


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

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

[ghazi at gcc dot gnu dot org]

GCC mistakenly identifies a named parameter as a sentinel.  Given the following 
program, compiling with -Wformat GCC should warn about a missing sentinel on 
the line indicated:

#include 

extern void foo (const char *, ...) __attribute__ ((__sentinel__));

void bar (void)
{
  foo (NULL); /* missing warning!! */
  foo ("hello", NULL); /* clean */
}

When looking for the sentinel, GCC should skip over the named arguments first 
before attempting to locate the NULL pointer.

-- 
   Summary: named parameter mistakenly identified as sentinel
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

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

[ghazi at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ghazi at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

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

[ghazi at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0


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

[Bug fortran/21912] New: Wrong implied do-loop

[tkoenig at gcc dot gnu dot org]

$ cat imploop.f90
program main
  call foo(5)
end program main

subroutine foo(n)
  implicit none
  integer :: n, i
  real, dimension(5) :: a,b
  print *,n
  a = (/(i,i=n,1,-1)/)
  print *,a
  b = (/(i,i=5,1,-1)/)
  print *,b
end subroutine foo
$ gfortran imploop.f90
$ ./a.out
   5
   1.00 -1.0737444E+09   4.00   0.00  1.0741898E+09
   5.00   4.00   3.00   2.00   1.00
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1/configure --prefix=/home/ig25 
--enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050523 (experimental)
$

-- 
   Summary: Wrong implied do-loop
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/21907] poor diagnostic

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
14:59 ---
Huh, you missed the semi-colon which is what it is complaining about.

-- 


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

[Bug c++/21908] Even poorer diagnostic

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
14:59 ---
Again you missed the semi-colon.

-- 


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
15:11 ---
We have "/* { dg-final { cleanup-tree-dump "lim" } } */" in the testcase so it 
should have cleaned up, 
when did you get the version of HEAD?

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug libstdc++/21796] (v7-branch) std::search not using std::find

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
15:16 ---
(In reply to comment #1)
> This is being held up by PR20408, Unnecessary code generated for empty 
> structs, as we'd have to 
> pass both the item to find and the comparitor (which is often an empty class) 
> to std::find_if
Why do you care about one instruction, only on stack argument passing targets?
Really there is no good reason to block one improvement for another which is 
most likely not going to 
be fixed in a long time.

-- 
   What|Removed |Added

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


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

[Bug c/21873] [3.4 Regression] infinite warning loop on bad array initializer

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|[3.4/4.0/4.1 Regression]|[3.4 Regression] infinite
   |infinite warning loop on bad|warning loop on bad array
   |array initializer   |initializer
   Target Milestone|4.0.1   |3.4.5


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

[Bug c++/21909] Mis-identifies template

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Attachment #9027|application/octet-stream|text/plain
  mime type||


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

[Bug target/20227] [m68k] long double -> double cast fails with -0.0

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-04 16:40:18
   date||


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

[Bug middle-end/20283] optimising muldiv() type operations

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/20580] Using ASSERT_EXPR to improve constant propagation of conditional constants

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2005-06-04 
16:47 ---

Fixed with http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00127.html

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.1.0


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

[Bug treelang/13042] Invalid lex option and lex error building treelang under hpux11

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
16:53 ---
Fixed for 4.0.0..

-- 
   What|Removed |Added

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


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

[Bug libf2c/20320] GCC 3.3.2 on AMD opetron 64 bits Linux machine

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
16:56 ---
No feedback in 3 months.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug debug/21913] New: REG_EXPR wrong for parameters passed by invisible reference

[jakub at gcc dot gnu dot org]

/* { dg-do compile } */
/* { dg-options "-O2 -g -m32" } */
union U { unsigned long u; unsigned long long v; };
struct S { long s; long t; };

extern unsigned int foo (unsigned long long *, unsigned int);

void bar (int x, union U y, struct S *z)
{
  if ((x & 3) == 2)
{
  unsigned long long r = y.v;
  unsigned int b = 10L;
  unsigned int m;
  if ((r >> 32) == 0)
{
  m = (unsigned int)r % b;
  r = (unsigned int)r / b;
}
  else
m = foo (&r, b);
  z->t = m;
  z->s = r;
}
}

creates following bogus location description for y (which is passed by
invisible reference on this arch).
.byte   0x54 # DW_OP_reg4
.byte   0x93 # DW_OP_piece
.byte   0x4  # uleb128 0x4
.byte   0x74 # DW_OP_breg4
.byte   0x4  # sleb128 4
.byte   0x93 # DW_OP_piece
.byte   0x4  # uleb128 0x4
The 64-bit union is certainly not located partly in reg4 and partly in what
reg4+4 points to, at least not in this case.

The problem seems to be that GCC uses REG_EXPR y for the register that
contains the address of the union:
(reg:SI 4 4 [ y ])
and also (MEM_EXPR) for the MEM that actually contains it, e.g.:
(mem/s:SI (reg:SI 4 4 [ y ]) [6 y+0 S4 A64])
(mem/s:SI (plus:SI (reg:SI 4 4 [ y ]) (const_int 4 [0x4])) [6 y+4 S4 A32])
The REG_EXPR on the register sounds wrong, if we allow REG_EXPR to not contain
only decls, then it could be ADDR_EXPR , otherwise perhaps nothing would
be better than lying about where the argument is.

-- 
   Summary: REG_EXPR wrong for parameters passed by invisible
reference
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,roland at redhat dot com
GCC target triplet: ppc-linux


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

[Bug tree-optimization/18178] Missed opportunity for removing bounds checking

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2005-06-04 
17:00 ---

21855 has some analysis.  Better use that one.

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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/21855] array bounds checking elimination

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2005-06-04 
17:00 ---
*** Bug 18178 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/19659] GCC does not remove an "if" statement that never triggers.

[dnovillo at gcc dot gnu dot org]

-- 
Bug 19659 depends on bug 18178, which changed state.

Bug 18178 Summary: Missed opportunity for removing bounds checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18178

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

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

[Bug c++/21901] Nested class has access to Nestee's private member functions

[mhcox at bluezoosoftware dot com]

--- Additional Comments From mhcox at bluezoosoftware dot com  2005-06-04 
17:17 ---
Subject: RE:  Nested class has access to Nestee's private member functions

>From my copy of the C++ standard (ISO/IEC 14882:1998(E)) [class.access.net]
11.8.1:

The members of a nested class have no special access to members of
an enclosing class, nor to classes or
Functions that have granted friendship to an enclosing class; the
usual access ruls (clause 11) shal be
Obeyed.  The members of an enclosing class have no special access to
members of a nested class; the usual
Access rules (clause 11) shall be obeyed.

I read suggestions that this should be changed in the next standard, but I
don't think it's changed yet.  Therefore, the resolution shouldn't be
INVALID.  It either needs to fixed or documented as a non-standard extension
(in anticipation of the next standard's changes).

Mike





 

-Original Message-
From: bangerth at dealii dot org [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 03, 2005 11:46 AM
To: [EMAIL PROTECTED]
Subject: [Bug c++/21901] Nested class has access to Nestee's private member
functions


--- Additional Comments From bangerth at dealii dot org  2005-06-03
17:46 --- Nested class, like all other members of a class, have access
to private and protected members. That's what the standard says. 
 
W. 

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

--- You are receiving this mail because: --- You reported the bug,
or are watching the reporter.



-- 


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

[Bug c++/21901] Nested class has access to Nestee's private member functions

[mhcox at bluezoosoftware dot com]

--- Additional Comments From mhcox at bluezoosoftware dot com  2005-06-04 
17:20 ---
>From my copy of the C++ standard (ISO/IEC 14882:1998(E)) [class.access.net] 
11.8.1:

The members of a nested class have no special access to members of an 
enclosing class, nor to classes or
functions that have granted friendship to an enclosing class; the 
usual access rules (clause 11) shall be
Obeyed.  The members of an enclosing class have no special access to 
members of a nested class; the usual
Access rules (clause 11) shall be obeyed.


-- 


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

[Bug c++/6850] private nested classes can be accessed by outside code

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |3.1.x/3.2.x


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

[Bug c++/21901] Nested class has access to Nestee's private member functions

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
17:37 ---
Reopening for a second to ...


-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/21901] Nested class has access to Nestee's private member functions

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
17:38 ---
Mark as a dup of bug 359.

This was DR 45.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/359] g++ incorrectly grants access to private members to nested classes

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
17:38 ---
*** Bug 21901 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||mhcox at bluezoosoftware dot
   ||com


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

[Bug fortran/21375] Rising run-time errors at DEALLOCATE with STAT clause

[kargl at gcc dot gnu dot org]

--- Additional Comments From kargl at gcc dot gnu dot org  2005-06-04 17:39 
---
Patch is give here

http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00334.html

-- 


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

[Bug c++/359] g++ incorrectly grants access to private members to nested classes

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
17:40 ---
Reopening for a second to ...

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug c++/359] g++ incorrectly grants access to private members to nested classes

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
17:40 ---
Mark as invalid.

-- 
   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID


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

[Bug c++/359] [DR 45] g++ incorrectly grants access to private members to nested classes

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
17:41 ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#45

-- 
   What|Removed |Added

Summary|g++ incorrectly grants  |[DR 45] g++ incorrectly
   |access to private members to|grants access to private
   |nested classes  |members to nested classes


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

[Bug target/21914] New: [4.1 regression] mmix-knuth-mmixware testsuite failure: compile/20030703-1.c

[hp at gcc dot gnu dot org]

With LAST_UPDATED: "Thu Jun  2 10:12:34 UTC 2005" and ever since,
I get:

Running
/home/hp/combined/combined/gcc/testsuite/gcc.c-torture/compile/compile.exp ...
FAIL: gcc.c-torture/compile/20030703-1.c  -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/20030703-1.c  -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: gcc.c-torture/compile/20030703-1.c  -O3 -g  (test for excess errors)

With the message in the .log being:
Executing on host: /home/hp/combined/mmixware-sim/gcc/xgcc
-B/home/hp/combined/mmixware-sim/gcc/   -O2  -w -fno-show-column -c  -\
isystem /home/hp/combined/mmixware-sim/mmix-knuth-mmixware/./newlib/targ-include
-isystem /home/hp/combined/combined/newlib/libc/\
include  -o 20030703-1.o
/home/hp/combined/combined/gcc/testsuite/gcc.c-torture/compile/20030703-1.c   
(timeout = 300)
/home/hp/combined/combined/gcc/testsuite/gcc.c-torture/compile/20030703-1.c: In
function 'MBMotionEstimation':^M
/home/hp/combined/combined/gcc/testsuite/gcc.c-torture/compile/20030703-1.c:9:
error: MMIX Internal: What is the CC of this?^M
(ne:DI (reg:SI 0 $0 [orig:269 D.1164 ] [269])^M
(const_int 0 [0x0]))^M
/home/hp/combined/combined/gcc/testsuite/gcc.c-torture/compile/20030703-1.c:9:
internal compiler error: in mmix_output_condition,\
 at config/mmix/mmix.c:2661^M

Last known to work on: "Thu Jun  2 00:27:52 UTC 2005".

-- 
   Summary: [4.1 regression] mmix-knuth-mmixware testsuite failure:
compile/20030703-1.c
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mmix-knuth-mmixware


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

[Bug target/21914] [4.1 regression] mmix-knuth-mmixware testsuite failure: compile/20030703-1.c

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.1.0


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

[Bug target/21914] [4.1 regression] mmix-knuth-mmixware testsuite failure: compile/20030703-1.c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
17:49 ---
I want to say this was exposed by:
-2005-06-01  Diego Novillo  <[EMAIL PROTECTED]>
-
-   PR 14341, PR 21332, PR 20701, PR 21029, PR 21086, PR 21090
-   PR 21289, PR 21348, PR 21367, PR 21368, PR 21458.


-- 


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

[Bug libfortran/16339] Unformatted i/o on large arrays inefficient

[jblomqvi at cc dot hut dot fi]

--- Additional Comments From jblomqvi at cc dot hut dot fi  2005-06-04 
17:50 ---
It seems that with current mainline, while gfortran still loses to g77 and
ifort, the difference isn't that large. Executing via strace shows that writes
are nowadays done in 8k blocks, which probably explains the change. Here are the
total times (removing the output file between each invocation):

ifort 8.0: 0,109

g77 3.3: 1,349

gfortran 4.1 20050604: 1,458

Blocksizes in bytes are:

ifort 8.0: 262144

g77 3.3: 4096

gfortran 4.1 20050604: 8192 

Gfortran is the only one which uses mmap. Also, we can see that ifort uses a
_huge_ blocksize, which probably explains why it's over 10 times faster. 

-- 


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

[Bug libstdc++/21796] (v7-branch) std::search not using std::find

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-06-04 18:00 
---
There is some truth in what Andrew and Chris are saying, and myself ;) : we
have quite a few improvements to merge to mainline and other in progress in
v7. Maybe, as an intermediate step, we will end up taking care of this
issue separately from 20408.

-- 


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

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

[SSacek at appsecinc dot com]

--- Additional Comments From SSacek at appsecinc dot com  2005-06-04 18:28 
---

I would like to thank you folks at gcc.gnu.org for taking a serious look at 
this issue.

I wanted to write here a little bit about what I do and how this matter came 
to light. It is my occupation to write cross-platform applications that run on 
Linux, Solaris, and Windows operating systems. When I was developing my code, 
I started coding and compiling it on the Microsoft compiler first. I did not 
get any compiler errors from my code and was happy that it was correct. Then 
when I tried compiling it using GCC, I started getting the compile-time 
errors. My first instinct was to go back to my code and fix it. I usually do 
that because the Microsoft compiler isn’t as strict about the C++ language as 
GCC is. But I stared at the code for about an hour and couldn’t figure out 
what I was doing wrong.

Based on the error message that GCC gave me, "the default argument for 
parameter 1 has not yet been parsed", I concluded that this might be a rare 
case in which the GCC compiler got it wrong. I base that conclusion on the 
fact that the error message from GCC implies a sense of incompleteness in the 
class definition, and hence cannot generate object code. But the fact that the 
Microsoft compiler can begin generating code indicates that there is enough 
information there to begin instantiating the objects. I figured GCC should 
also be able to do the same with what was given.

Here at AppSecInc, where I work, we also tried the same tests with the ICC 
compiler and got the same results that Andrew Pinski mentioned. That actually 
surprised me at first, but then I couldn’t help but draw some conclusions 
about it. Intel is a hardware manufacturer, and not a compiler developer. I 
can’t help but believe that Intel didn’t want to re-invent the whole wheel, 
and therefore borrowed the open-source parser that the folks at GCC created.

These opinions are solely my own.

Thank you,
-Sid Sacek



-- 


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

[Bug libfortran/20278] Performance regression in formatted output vs. g77

[aa056 at chebucto dot ns dot ca]

--- Additional Comments From aa056 at chebucto dot ns dot ca  2005-06-04 
18:44 ---
For Red Hat Fedora Core 3, gfortran 4.0.0 doesn't lose output records:

$ ./chk-write-many
uname -a
Linux cerberus.cwmannwn.nowhere 2.6.11-1.14_FC3.stk16 #1 Tue Apr 12 14:39:51 EDT
2005 i686 i686 i386 GNU/Linux
cat -  wm-gfortran.out

real0m22.993s
user0m11.641s
sys 0m0.062s

g77 write-many.f
time ./a.out > wm-g77.out

real0m7.477s
user0m4.036s
sys 0m0.045s
cmp wm-*.out
wm-g77.out wm-gfortran.out differ: byte 134818, line 10371

I think the differences are rounding errors. 

$ wc -l wm*.out
 100 wm-g77.out
 100 wm-gfortran.out
 200 total


-- 


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

[Bug c++/21901] Nested class has access to Nestee's private member functions

[bangerth at ices dot utexas dot edu]

--- Additional Comments From bangerth at ices dot utexas dot edu  
2005-06-04 18:48 ---
Subject: RE:  Nested class has access to Nestee's private
 member functions


> I read suggestions that this should be changed in the next standard, but I
> don't think it's changed yet.  Therefore, the resolution shouldn't be
> INVALID.  It either needs to fixed or documented as a non-standard extension
> (in anticipation of the next standard's changes).

It is part of the Technical Corrigendum TC1 of the standard, however, and 
therefore (retroactively) considered part of C++98.

W.

-
Wolfgang Bangerth  email:[EMAIL PROTECTED]
www: http://www.ices.utexas.edu/~bangerth/



-- 


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

[Bug c++/21908] Even poorer diagnostic

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-06-04 18:55 
---
So I did :-)  So where does the `der2::der2(const void**)' come from?

-- 


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

[Bug fortran/19195] gfortran: ICE in final_scan_insn, at final.c:1843

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-06-04 19:04 
---
It looks like I made a mistake there, the original code had a +1 in
gfc_set_backend_locus, as can be seeing by diffing rev 1.4 against rev 1.5.  I
can't remember what all this was about at the moment, so I don't know what's 
right.

Index: trans.c
===
RCS file: /cvs/gcc/gcc/gcc/fortran/trans.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- trans.c 14 May 2004 13:00:04 -  1.4
+++ trans.c 15 May 2004 17:31:32 -  1.5
@@ -414,8 +414,9 @@ gfc_add_block_to_block (stmtblock_t * bl
 void
 gfc_get_backend_locus (locus * loc)
 {
-  loc->line = input_line - 1;
-  loc->file = gfc_current_backend_file;
+  loc->lb = gfc_getmem (sizeof (gfc_linebuf));
+  loc->lb->linenum = input_line - 1;
+  loc->lb->file = gfc_current_backend_file;
 }


@@ -424,9 +425,9 @@ gfc_get_backend_locus (locus * loc)
 void
 gfc_set_backend_locus (locus * loc)
 {
-  input_line = loc->line + 1;
-  gfc_current_backend_file = loc->file;
-  input_filename = loc->file->filename;
+  input_line = loc->lb->linenum;
+  gfc_current_backend_file = loc->lb->file;
+  input_filename = loc->lb->file->filename;
 }

-- 
   What|Removed |Added

 CC||tobi at gcc dot gnu dot org


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

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

[SSacek at appsecinc dot com]

--- Additional Comments From SSacek at appsecinc dot com  2005-06-04 19:17 
---

Dear Giovanni Bajo,

Thank you for that detailed explanation. Based on what you said, it sounds 
like a complex problem to solve; however, it may not be as difficult as it 
first appears. Take the example below, which was already shown to us by 
Wolfgang Bangerth. Compile it, and GCC is happy. Then remove the comment from 
line 5, and GCC becomes unhappy. Mysterious! With line 5 commented out, GCC 
believes that everything is complete. But add line 5 back into the equation, 
and GCC believes that things are now incomplete. The Derived structure is in 
itself complete too, and judging by this behavior of GCC, my approach to 
solving the mystery would be to find out why a class like ‘struct Base’, which 
was once complete, changes its status to incomplete by merely adding 
the ‘Derived’ struct. Of course, I’m assuming that the Base struct is being 
parsed before the Derived struct.

Understanding the reason why the status change occurs should help in knowing 
whether this is an easy or difficult thing to change.

Regards,
-Sid Sacek


struct O { 
template struct Base { 
void set (T, bool=true); 
}; 
//  struct Derived : public Base {}; 
}; 
 
void x () 
{ 
  O::Base b; 
  b.set(1); 
} 



-- 


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

[Bug fortran/21915] New: Would like atanh etc. as intrinsics

[schnetter at aei dot mpg dot de]

I would be nice if the functions atanh etc. (acosh, asinh, atanh, cosh, sinh, 
tanh) were available as intrinsics.  These functions are not part of the 
Fortran 2003 standard.  But they are defined e.g. in C's  or 
, and other Fortran compilers provide these as well.

-- 
   Summary: Would like atanh etc. as intrinsics
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schnetter at aei dot mpg dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/21888] bootstrap failure with linker relaxation enabled

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-04 
19:23 ---
Subject: Bug 21888

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-06-04 19:23:54

Modified files:
gcc: ChangeLog 
gcc/config/alpha: alpha.c 

Log message:
PR target/21888
* config/alpha/alpha.c (alpha_align_insns): Don't insert nops
until we've passed initial ldgp.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9037&r2=2.9038
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/alpha/alpha.c.diff?cvsroot=gcc&r1=1.426&r2=1.427



-- 


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

[Bug middle-end/21886] [4.1 Regression] bootstrap fails on hppa2.0w-hpux

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-06-04 19:25 
---
On 20050604 it's back to the first failure reported in this PR.

-- 


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

[Bug target/21888] bootstrap failure with linker relaxation enabled

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-04 
19:25 ---
Subject: Bug 21888

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-06-04 19:25:48

Modified files:
gcc: ChangeLog 
gcc/config/alpha: alpha.c 

Log message:
PR target/21888
* config/alpha/alpha.c (alpha_align_insns): Don't insert nops
until we've passed initial ldgp.

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.278&r2=2.7592.2.279
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/alpha/alpha.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.408.8.3&r2=1.408.8.4



-- 


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

[Bug target/21914] [4.1 regression] mmix-knuth-mmixware testsuite failure: compile/20030703-1.c

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-06-04 19:26 
---
It's mine, don't bother Diego.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hp at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-04 19:26:00
   date||


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

[Bug target/21888] bootstrap failure with linker relaxation enabled

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-04 
19:27 ---
Subject: Bug 21888

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2005-06-04 19:27:34

Modified files:
gcc: ChangeLog 
gcc/config/alpha: alpha.c 

Log message:
PR target/21888
* config/alpha/alpha.c (alpha_align_insns): Don't insert nops
until we've passed initial ldgp.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.875&r2=2.2326.2.876
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/alpha/alpha.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.342.4.14&r2=1.342.4.15



-- 


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

[Bug target/21888] bootstrap failure with linker relaxation enabled

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-06-04 19:28 
---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug c++/21908] [3.4/4.0/4.1 Regression] poor diagnostic with vitrual base classes

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
19:30 ---
(In reply to comment #2)
> So I did :-)  So where does the `der2::der2(const void**)' come from?

It is a bug and a regression.
Reduced testcase for that bug:
struct  virt { virt(){} virt(int i){}  };
struct der: public virtual virt { der(int i):virt(i) {} };
struct top : public der {
top () {} };

3.2.3 gave:
t.cc: In constructor `top::top()':
t.cc:4: no matching function for call to `der::der()'
t.cc:2: candidates are: der::der(const der&)
t.cc:2: der::der(int)

which is the correct diagnostic.

3.3.3 gave something just as weird as 3.4.0 (and above):
t.cc: In constructor `top::top()':
t.cc:4: error: no matching function for call to `der::der(const **)'
t.cc:2: error: candidates are: der::der(const der&)
t.cc:2: error: der::der(int)

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic
  Known to fail||3.3.3 3.4.0 4.0.0 4.1.0
  Known to work||3.2.3
   Last reconfirmed|-00-00 00:00:00 |2005-06-04 19:30:11
   date||
Summary|Even poorer diagnostic  |[3.4/4.0/4.1 Regression]
   ||poor diagnostic with vitrual
   ||base classes
   Target Milestone|--- |3.4.5


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

[Bug c++/21907] poor diagnostic

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
19:32 ---
The error message is clear what the problem is, so closing as invalid.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/13867] constant variable of value zero not converted to (null) pointer

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
19:35 ---
(In reply to comment #7)
> FWIW, WG21 thinks this is a bug:
> http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_closed.html#456

And is fixed in 4.0.0 and above already.


-- 


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

[Bug testsuite/21292] gen-vect-11b.c and gen-vect-11c.c fail

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-06-04 19:36 
---
Failures no longer appear on ia64-hpux on mainline on 20050604.


-- 


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

[Bug testsuite/21292] gen-vect-11b.c and gen-vect-11c.c fail

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
19:38 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/19195] gfortran: ICE in final_scan_insn, at final.c:1843

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-06-04 19:51 
---
Hm, lb->linenum should start counting from line 1, so I've no idea what the
original code was trying to do.

-- 


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

[Bug c/21916] New: [4.1 Regression] ICE: segmentation fault in stage3

[danglin at gcc dot gnu dot org]

./xgcc -B./ -B/home/dave/opt/gnu/gcc/gcc-4.1.0/hppa-linux/bin/ -isystem /home/da
ve/opt/gnu/gcc/gcc-4.1.0/hppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-
4.1.0/hppa-linux/sys-include -L/home/dave/gnu/gcc-4.0/objdir/gcc/../ld -O2 -DIN_
GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-s
tyle-definition  -isystem ./include  -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -
I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include   -g0 -finhibit-size
-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -f
no-unit-at-a-time  \
   -c ../../gcc/gcc/crtstuff.c -DCRT_BEGIN \
  -o crtbegin.o
In file included from /usr/include/stdio.h:828,
 from ../../gcc/gcc/tsystem.h:90,
 from ../../gcc/gcc/crtstuff.c:62:
/usr/include/bits/stdio.h: In function 'vprintf':
/usr/include/bits/stdio.h:36: internal compiler error: Segmentation fault

(gdb) p (char *)$r26
$5 = 0x24 
(gdb) p (char *)$r25
$6 = 0x5155f0 "/usr/include/bits/stdio.h"
(gdb) bt
#0  0x4093008c in strcmp () from /lib/libc.so.6
#1  0x002f6044 in annotate_with_file_line (node=0x400094e0,
file=0x5155f0 "/usr/include/bits/stdio.h", line=36)
at ../../gcc/gcc/tree.c:2896
#2  0x002f622c in annotate_with_locus (node=Variable "node" is not available.
) at ../../gcc/gcc/tree.c:2927
#3  0x000749fc in c_parser_statement_after_labels (parser=0x40010078)
at ../../gcc/gcc/c-parser.c:3565
#4  0x00075bc0 in c_parser_compound_statement_nostart (parser=0x40010078)
at ../../gcc/gcc/c-parser.c:3299
#5  0x0007bd5c in c_parser_compound_statement (parser=0x40010078)
at ../../gcc/gcc/c-parser.c:3174
#6  0x00074748 in c_parser_declaration_or_fndef (parser=0x40010078,
fndef_ok=1 '\001', empty_ok=Variable "empty_ok" is not available.
) at ../../gcc/gcc/c-parser.c:1294
#7  0x0007c90c in c_parser_external_declaration (parser=0x40010078)
at ../../gcc/gcc/c-parser.c:1070
#8  0x0007d904 in c_parse_file () at ../../gcc/gcc/c-parser.c:976
#9  0x0006827c in c_common_parse_file (set_yydebug=Variable "set_yydebug" is 
not 
available.
)
at ../../gcc/gcc/c-opts.c:1118
#10 0x002f3c4c in toplev_main (argc=Variable "argc" is not available.
) at ../../gcc/gcc/toplev.c:966
#11 0x408ca51c in __libc_start_main () from /lib/libc.so.6
#12 0x0001a848 in _start () at ../sysdeps/hppa/elf/start.S:67
(gdb)

  if (EXPR_LOCUS (node)
  && (EXPR_FILENAME (node) == file
  || ! strcmp (EXPR_FILENAME (node), file))
  && EXPR_LINENO (node) == line)

EXPR_FILENAME (node) is garbage (i.e., the $r26 argument register
points to page 0 in the call to strcmp).

I get a similar error when I try to dump the tree:


Breakpoint 3, annotate_with_file_line (node=0x400094e0,
file=0x5155f0 "/usr/include/bits/stdio.h", line=36)
at ../../gcc/gcc/tree.c:2896
2896  if (EXPR_LOCUS (node)
(gdb) p debug_tree (node)
 >
side-effects
arg 0 
unit size 
align 32 symtab 0 alias set -1 precision 32 min  max 
pointer_to_this >
side-effects
arg 0 
ignored in_system_header SI file /usr/include/bits/stdio.h line 35 
size  unit size 
align 32>
arg 1 
side-effects
arg 0 
constant invariant arg 0 >
arg 1 
arg 0 >
chain 
chain >

Program received signal SIGSEGV, Segmentation fault.
0x40931668 in strlen () from /lib/libc.so.6
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (debug_tree) will be 
abandoned.

Last successful build was updated at Wed Jun 1 22:33:22 UTC 2005.

-- 
   Summary: [4.1 Regression] ICE: segmentation fault in stage3
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
20:29 ---
Very related to PR 21886.

-- 
   What|Removed |Added

  BugsThisDependsOn||21886
  Component|c   |middle-end
   Keywords||build, ice-on-valid-code,
   ||wrong-code
   Target Milestone|--- |4.1.0


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

[Bug middle-end/21886] [4.1 Regression] bootstrap fails on hppa2.0w-hpux

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||21916
  nThis||


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

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

[dave at hiauly1 dot hia dot nrc dot ca]

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

> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-04 
> 20:29 ---
> Very related to PR 21886.

More than related, they are the same:

(gdb) r `cat xx.sh`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /test/gnu/gcc-3.3/objdir/gcc/cc1 `cat xx.sh`
Breakpoint 3 at 0x42b5d4
Breakpoint 4 at 0x40e83c
Breakpoint 3 at 0x7af87744
Breakpoint 4 at 0x7afeb230
GNU C version 4.1.0 20050604 (experimental) (hppa2.0w-hp-hpux11.11)
compiled by GNU C version 4.1.0 20050604 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
options passed:  -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
 -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
 -I/opt/gnu/include -iprefix -isystem -DIN_GCC -DHAVE_GTHR_DEFAULT
 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DL_muldi3 -isystem -isystem
 -isystem -auxbase-strip -g -O2 -W -Wall -Wwrite-strings
 -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fPIC
options enabled:  -fPIC -falign-loops -fargument-alias -fbranch-count-reg
 -fcaller-saves -fcommon -fcprop-registers -fcrossjumping
 -fcse-follow-jumps -fcse-skip-blocks -fdefer-pop -fdelayed-branch
 -fdelete-null-pointer-checks -feliminate-unused-debug-types
 -fexpensive-optimizations -fforce-mem -ffunction-cse -fgcse -fgcse-lm
 -fguess-branch-probability -fident -fif-conversion -fif-conversion2
 -fivopts -fkeep-static-consts -fleading-underscore -floop-optimize
 -floop-optimize2 -fmath-errno -fmerge-constants -fomit-frame-pointer
 -foptimize-register-move -foptimize-sibling-calls -fpeephole -fpeephole2
 -freg-struct-return -fregmove -freorder-blocks -freorder-functions
 -frerun-cse-after-loop -frerun-loop-opt -fsched-interblock -fsched-spec
 -fsched-stalled-insns-dep -fschedule-insns -fschedule-insns2 -fshow-column
 -fsplit-ivs-in-unroller -fstrength-reduce -fstrict-aliasing -fthread-jumps
 -ftrapping-math -ftree-ccp -ftree-ch -ftree-copy-prop -ftree-copyrename
 -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im
 -ftree-loop-ivcanon -ftree-loop-optimize -ftree-lrs -ftree-pre
 -ftree-salias -ftree-sink -ftree-sra -ftree-store-ccp
 -ftree-store-copy-prop -ftree-ter -ftree-vrp -funit-at-a-time
 -fvar-tracking -fzero-initialized-in-bss -mbig-switch -mgas -mspace-regs
Compiler executable checksum: a84585677dfebb3db993ca6fba1108aa
 _muldi3

Program received signal SIGSEGV, Segmentation fault.
0x7af72538 in strcmp () from /usr/lib/libc.2
(gdb) bt
#0  0x7af72538 in strcmp () from /usr/lib/libc.2
#1  0x001e8a38 in annotate_with_file_line ()
#2  0x001e8b5c in annotate_with_locus ()
#3  0x000786cc in build_stmt ()
#4  0x0002ed9c in finish_decl ()
#5  0x00080bb4 in c_parser_declaration_or_fndef ()
#6  0x00082698 in c_parser_compound_statement_nostart ()
#7  0x0008887c in c_parser_compound_statement ()
#8  0x00080eac in c_parser_declaration_or_fndef ()
#9  0x0008960c in c_parser_external_declaration ()
#10 0x0008a584 in c_parse_file ()
#11 0x00073d3c in c_common_parse_file ()
#12 0x001e64f0 in toplev_main ()
#13 0x00094464 in main ()

Dave


-- 


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

[Bug fortran/16898] Aliasing problem with array descriptors

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-04 
21:00 ---
Subject: Bug 16898

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-06-04 20:59:51

Modified files:
gcc/fortran: ChangeLog trans-types.c 
gcc/testsuite  : ChangeLog 
gcc/testsuite/gfortran.dg: ret_pointer_1.f90 

Log message:
fortran/
2005-06-04  Zdenek Dvorak  <[EMAIL PROTECTED]>

PR fortran/16898
* trans-types.c (gfc_array_range_type): New variable.
(gfc_init_types): Initialize gfc_array_range_type.
(gfc_get_array_type_bounds): Use gfc_array_range_type.

testsuite/
2005-06-04  Tobias Schl"uter  <[EMAIL PROTECTED]>

PR fortran/16898
* gfortran.dg/ret_pointer_1.f90: Un-XFAIL.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.64&r2=1.335.2.65
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-types.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.37.10.5&r2=1.37.10.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.226&r2=1.5084.2.227
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/ret_pointer_1.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1&r2=1.1.48.1



-- 


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

[Bug fortran/16898] Aliasing problem with array descriptors

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-06-04 21:00 
---
Fixed.

-- 
   What|Removed |Added

 CC||tobi at gcc dot gnu dot org
 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.1


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

[Bug fortran/20538] compiling -finline-functions -O2 and we crash at runtime

[tobi at gcc dot gnu dot org]

-- 
Bug 20538 depends on bug 16898, which changed state.

Bug 16898 Summary: Aliasing problem with array descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16898

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug fortran/16898] Aliasing problem with array descriptors

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-06-04 21:01 
---
The patch has been on mainline since May 18th.

-- 


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

[Bug fortran/19195] gfortran: ICE in final_scan_insn, at final.c:1843

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-06-04 21:56 
---
I think this is the right thing to do, but I'm not sure it's the only bug.  The
line number given in the ICE is minus two, but this patch only fixes an 
off-by-one.

2005-06-04  Tobias Schl"uter  <[EMAIL PROTECTED]>
Erik Schnetter  <[EMAIL PROTECTED]>

Index: trans.c
===
RCS file: /cvs/gcc/gcc/gcc/fortran/trans.c,v
retrieving revision 1.24
diff -u -p -r1.24 trans.c
--- trans.c 26 May 2005 18:36:10 -  1.24
+++ trans.c 4 Jun 2005 21:53:50 -
@@ -437,9 +437,9 @@ gfc_get_backend_locus (locus * loc)
 {
   loc->lb = gfc_getmem (sizeof (gfc_linebuf));
 #ifdef USE_MAPPED_LOCATION
-  loc->lb->location = input_location; /* FIXME adjust?? */
+  loc->lb->location = input_location;
 #else
-  loc->lb->linenum = input_line - 1;
+  loc->lb->linenum = input_line;
 #endif
   loc->lb->file = gfc_current_backend_file;
 }

(I've also added Erik to the CC list, as he showed some interest in this bug)

-- 
   What|Removed |Added

 CC||schnetter at aei dot mpg dot
   ||de


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

[Bug fortran/20829] Internal compiler error with valid code

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-06-04 22:03 
---
Hm, I couldn't reproduce the failure, but maybe I got some subtlety wrong which
is needed for this bug to trigger.  I'd suggest we try this again once a fix for
pr19195 is in, for I think they're the same bug.

-- 
   What|Removed |Added

 CC||tobi at gcc dot gnu dot org


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

[Bug fortran/19195] gfortran: ICE in final_scan_insn, at final.c:1843

[schnetter at aei dot mpg dot de]

--- Additional Comments From schnetter at aei dot mpg dot de  2005-06-04 
22:05 ---
I had a case where the line number was set to -123 in the end.  With this 
patch this works now. 
 
I assumed that the get/set routines would be called repeatedly, and the line 
number is reduced by one each time. 
 

-- 


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

[Bug fortran/20829] Internal compiler error with valid code

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-06-04 22:06 
---
Silly me, I could reproduce it now.  With the patch I appended to PR 19195 this
is fixed.

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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/19195] gfortran: ICE in final_scan_insn, at final.c:1843

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-06-04 22:06 
---
*** Bug 20829 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||federico dot carminati at
   ||cern dot ch


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

[Bug fortran/19195] gfortran: ICE in final_scan_insn, at final.c:1843

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-06-04 22:08 
---
There's definitely something wrong if we call this pair of functions 123 times
on the same function :-)  The patch also fixes PR 20829, so I think I'll post it
to the list and commit it, either as obvious or as approved version of your
patch :-)

-- 


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

[Bug c++/21917] New: Missing warning? (or error?)

[igodard at pacbell dot net]

struct  virt { virt() : i(2) {} virt(int i) : i(i){} int i;  };
struct der1 : public virtual virt { der1(int i) : virt(i) {} };
struct der2 : public virtual virt { der2(int i) : virt(i) {} };
struct top : public der1, public der2 {
top () : der1(0), der2(1) {} };
int main() { top t; }


Compiles without comment. However, the null constructor for "virt" is called
rather than the explicit constructor that is indicated by the constructor chain
from top. In fact, the der* constructors say " : virt(i)" but that
sub-constructor will never be called because virt is a virtual base class.

I don't know if it is actually an error to try to explicitly construct a virtual
base, but is sure is misleading and I think deserves at least a warning.

-- 
   Summary: Missing warning? (or error?)
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/19195] gfortran: ICE in final_scan_insn, at final.c:1843

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-04 
22:21 ---
Subject: Bug 19195

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-06-04 22:20:58

Modified files:
gcc/fortran: ChangeLog trans.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gfortran.dg: debug_1.f90 

Log message:
fortran/
2005-06-04  Tobias Schl"uter  <[EMAIL PROTECTED]>
Erik Schnetter  <[EMAIL PROTECTED]>

PR fortran/19195
* trans.c (gfc_get_backend_locus): Remove unnecessary adjustment,
remove FIXME comment.

testsuite/
2005-06-04  Tobias Schl"uter  <[EMAIL PROTECTED]>

PR fortran/19195
* gfortran.dg/debug_1.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.453&r2=1.454
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans.c.diff?cvsroot=gcc&r1=1.24&r2=1.25
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5593&r2=1.5594
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/debug_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c++/21917] Missing warning? (or error?)

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-06-04 22:22 
---
p.s. I suppose that if there is only a single path to the virtual base then
explicit construction is meaningful and the explicit construction in the der*
classes is not wrong. But in the constructor for "top" the compiler knows that
there are multiple derivations from virt (it has to or it couldn't know to call
the null constructor), so the warning could be issued in "top". Something like
"base constructor virt(int) in der1(int) bypassed, virt() used instead"?

Ivan

-- 


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

[Bug fortran/20829] Internal compiler error with valid code

[tobi at gcc dot gnu dot org]

-- 
Bug 20829 depends on bug 19195, which changed state.

Bug 19195 Summary: gfortran: ICE in final_scan_insn, at final.c:1843
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19195

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug fortran/19195] gfortran: ICE in final_scan_insn, at final.c:1843

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-06-04 22:23 
---
Fixed. Thanks, Erik.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/19195] gfortran: ICE in final_scan_insn, at final.c:1843

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-04 
22:43 ---
Subject: Bug 19195

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-06-04 22:43:17

Modified files:
gcc/fortran: ChangeLog trans.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gfortran.dg: debug_1.f90 

Log message:
fortran/
2005-06-04  Tobias Schl"uter  <[EMAIL PROTECTED]>
Erik Schnetter  <[EMAIL PROTECTED]>

PR fortran/19195
* trans.c (gfc_get_backend_locus): Remove unnecessary adjustment,
remove FIXME comment.
testsuite/
2005-06-04  Tobias Schl"uter  <[EMAIL PROTECTED]>

PR fortran/19195
* gfortran.dg/debug_1.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.65&r2=1.335.2.66
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.21&r2=1.21.10.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.227&r2=1.5084.2.228
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/debug_1.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug fortran/19195] gfortran: ICE in final_scan_insn, at final.c:1843

[tobi at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.1


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

[Bug fortran/21918] New: Warnings about unused variables should point to the declaration

[schnetter at aei dot mpg dot de]

Warnings about unused variables should point to the declaration of the 
variable.  Currently the warning points to the first line of the procedure 
where the variable is declared: 
 
subroutine a (x, y) 
  implicit none 
  integer x 
  integer y 
  x = 1 
end subroutine a 
 
$ ~/gcc/bin/gfortran -c -Wall unused.f90  
unused.f90: In function 'a': 
unused.f90:1: warning: unused variable 'y'

-- 
   Summary: Warnings about unused variables should point to the
declaration
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schnetter at aei dot mpg dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/21902] ICE in build_array_type, at tree.c:4581

[schnetter at aei dot mpg dot de]

--- Additional Comments From schnetter at aei dot mpg dot de  2005-06-04 
23:15 ---
I tried to reduce the failing source code, but failed to achieve much.  
Depending on what lines I remove, the error changes, sometimes turning into a 
bare "segmentation fault".  Even renaming the source file can make the error 
go away. 
 
With a different source file (much smaller; attached) and such a bare 
segmentation fault, I get the following stack backtrace from valgrind: 
 
$ valgrind --log-file=gfortran --trace-children=yes ~/gcc/bin/gfortran -c 
transform_global.f90  
/home/eschnett/Calpha/Cactus/arrangements/LSUDevelopment/HyperGR_MoL/src/transform_global.F90:
 
In function 'local2global': 
/home/eschnett/Calpha/Cactus/arrangements/LSUDevelopment/HyperGR_MoL/src/transform_global.F90:112:
 
internal compiler error: Segmentation fault 
 
==28630== My PID = 28630, parent PID = 28629.  Prog and args are: 
==28630==/home/eschnett/gcc/libexec/gcc/i686-pc-linux-gnu/4.1.0/f951 
==28630==transform_global.f90 
==28630==-quiet 
==28630==-dumpbase 
==28630==transform_global.f90 
==28630==-mtune=pentiumpro 
==28630==-auxbase 
==28630==transform_global 
==28630==-o 
==28630==/tmp/ccT8xxXE.s 
==28630== For more details, rerun with: -v 
==28630==  
==28630== Invalid read of size 4 
==28630==at 0x8099EDE: gfc_conv_scalarized_array_ref (trans-array.c:1578) 
==28630==by 0x8099F9F: gfc_conv_array_ref (trans-array.c:1622) 
==28630==by 0x80A6912: gfc_conv_variable (trans-expr.c:420) 
==28630==by 0x80B20DC: set_string (trans-io.c:403) 
==28630==by 0x80B38E2: build_dt (trans-io.c:1066) 
==28630==by 0x80B3A22: gfc_trans_write (trans-io.c:1188) 
==28630==by 0x80970E4: gfc_trans_code (trans.c:595) 
==28630==by 0x80B4B43: gfc_trans_if_1 (trans-stmt.c:423) 
==28630==by 0x809702E: gfc_trans_code (trans.c:547) 
==28630==by 0x80B4B03: gfc_trans_if_1 (trans-stmt.c:413) 
==28630==by 0x80B4B54: gfc_trans_if_1 (trans-stmt.c:427) 
==28630==by 0x809702E: gfc_trans_code (trans.c:547) 
==28630==  Address 0xC4 is not stack'd, malloc'd or (recently) free'd 
 

-- 


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

[Bug fortran/21915] Would like atanh etc. as intrinsics

[schnetter at aei dot mpg dot de]

--- Additional Comments From schnetter at aei dot mpg dot de  2005-06-04 
23:16 ---
Created an attachment (id=9030)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9030&action=view)
Failing source code


-- 


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

[Bug bootstrap/21919] New: make bootstrap-lean gets stuck after between-stages crash.

[bmoses-nospam at cits1 dot stanford dot edu]

System: 200MHz Pentium Pro PC, Windows 2k, Cygwin.
GCC Version: 4.1.0, from cvs 2005-06-02.

Before the bug appeared: I had downloaded a fresh copy of the CVS tree, and was 
attempting to build a copy of gfortran using the following commands (yes, I now 
know that trying to build _in_ the source directory was a bad idea, but that 
doesn't affect this bug).

  setenv CFLAGS '-O2 -g'
  setenv BOOT_CFLAGS '-O2'
  cd gcc/gcc

  ../configure  --enable-threads=posix --enable-sjlj-exceptions \
  --disable-libmudflap --enable-languages=f95

I then ran "make bootstrap-lean", and waited.  After some time (about 26 
hours), 
the compilation crashed, due to what we think is bug 21766 (compiler ICE on 
valid code).  This is not the bug that I am reporting.  :)

The bug that I am reporting is what happened when I immediately re-ran "make-
bootstrap-lean" to see if this was repeatable.  What happened instead was a 
string of "tail: cannot open" errors, followed by make exiting with errors.  
Apparently, the make process has gotten wedged into a state from which it can't 
recover.

Some detailed output, to help track down what's happening.  First, the output 
of 
make bootstrap-lean:

make[1]: Entering directory `/cygdrive/e/gfortran/gcc/gcc/build-i686-pc-cygwin/
libiberty'
make[2]: Entering directory `/cygdrive/e/gfortran/gcc/gcc/build-i686-pc-cygwin/
libiberty/testsuite'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/cygdrive/e/gfortran/gcc/gcc/build-i686-pc-cygwin/
libiberty/testsuite'
make[1]: Leaving directory `/cygdrive/e/gfortran/gcc/gcc/build-i686-pc-cygwin/
libiberty'
make[1]: Entering directory `/cygdrive/e/gfortran/gcc/gcc/build-i686-pc-cygwin/
fixincludes'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/cygdrive/e/gfortran/gcc/gcc/build-i686-pc-cygwin/
fixincludes'
make[1]: Entering directory `/cygdrive/e/gfortran/gcc/gcc/intl'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/cygdrive/e/gfortran/gcc/gcc/intl'
make[1]: Entering directory `/cygdrive/e/gfortran/gcc/gcc/libiberty'
make[2]: Entering directory `/cygdrive/e/gfortran/gcc/gcc/libiberty/testsuite'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/cygdrive/e/gfortran/gcc/gcc/libiberty/testsuite'
make[1]: Leaving directory `/cygdrive/e/gfortran/gcc/gcc/libiberty'
make[1]: Entering directory `/cygdrive/e/gfortran/gcc/gcc/libcpp'
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
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
: --statistics -o po/nl.gmo ../../libcpp/po/nl.po
test -d po || mkdir po
: --statistics -o po/rw.gmo ../../libcpp/po/rw.po
test -d po || mkdir po
: --statistics -o po/sv.gmo ../../libcpp/po/sv.po
test -d po || mkdir po
: --statistics -o po/tr.gmo ../../libcpp/po/tr.po
test -d po || mkdir po
: --statistics -o po/vi.gmo ../../libcpp/po/vi.po
make[1]: Leaving directory `/cygdrive/e/gfortran/gcc/gcc/libcpp'
Bootstrapping the compiler
make[1]: Entering directory `/cygdrive/e/gfortran/gcc/gcc/gcc'

Bootstrap complete - make "quickstrap" to redo last build,
or "cleanstrap" to redo the bootstrap from scratch.
make[1]: Leaving directory `/cygdrive/e/gfortran/gcc/gcc/gcc'
Comparing stage2 and stage3 of the compiler
make[1]: Entering directory `/cygdrive/e/gfortran/gcc/gcc/gcc'
rm -f .bad_compare
case "gnucompare-lean" in *compare | *compare-lean ) stage=2 ;; * ) stage=`echo 
gnucompare-lean | sed -e 's,^[a-z]*compare\([0-9][0-9]*\).*,\1,'` ;; esac; \
for dir in . fortran build libgcc; do \
  if [ "`echo $dir/*.o`" != "$dir/*.o" ] ; then \
for file in $dir/*.o; do \
  case $file in \
./cc*-checksum.o | libgcc/* ) \
tail +16c ./$file > tmp-foo1 \
&& tail +16c stage$stage/$file > tmp-foo2 \
&& ( cmp tmp-foo1 tmp-foo2 > /dev/null 2>&1 \
 || echo warning: $file differs || true ) \
  ;; \
*)  case "gnucompare-lean" in \
  slowcompare* ) \
tail +16c ./$file > tmp-foo1; \
tail +16c stage$stage/$file > tmp-foo2 \
  && (cmp tmp-foo1 tmp-foo2 > /dev/null 2>&1 \
  || echo $file differs >> .bad_compare) || true; \
;; \
  fastcompare* ) \
cmp $file stage$stage/$file 16 16 > /dev/null 2>&1; \
test $? -eq 1 && echo $file differs >> .bad_compare || true; \
;; \
  gnucompare* ) \
cmp --ignore-initial=16 $file stage

[Bug c++/21917] Missing warning? (or error?)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-05 
03:02 ---
This is how C++ is done, maybe a warning can be emitted but it seems like it 
will emitt too much for 
valid C++ code.

-- 


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

[Bug bootstrap/21878] Mingw32 target doesn't compile because of an internal compiler error

[sherpya at netfarm dot it]

--- Additional Comments From sherpya at netfarm dot it  2005-06-05 03:59 
---
the problematic dirs are target-libiberty target-libstdc++-v3
since adding this to target:
skipdirs="target-libiberty target-libstdc++-v3"
compiles fine (cross compiling with linux), anyway I suppose this cannot work on
native mingw32 build, but I'll test it anyway

-- 


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

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

[sherpya at netfarm dot it]

--- Additional Comments From sherpya at netfarm dot it  2005-06-05 05:15 
---
as I posted in the duplicated bug thread, the problematic directories are:
target-libiberty target-libstdc++-v3
also I had a working build on cvs snapshot of 20050522,
btw in that build ATTRIBUTE_SENTINEL was not defined when building libiberty on
mingw, and also gcov has to be fixed since it has a mkdir with 2 params, on
win32 it has only one param, but I've easy solved these problems.
I'll spend some time to check when exactly the build was broken

-- 


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

[Bug bootstrap/21878] Mingw32 target doesn't compile because of an internal compiler error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-05 
06:30 ---
(In reply to comment #4)
> the problematic dirs are target-libiberty target-libstdc++-v3
> since adding this to target:
> skipdirs="target-libiberty target-libstdc++-v3"
> compiles fine (cross compiling with linux), anyway I suppose this cannot work 
> on
> native mingw32 build, but I'll test it anyway

but skipping those will cause you not have the standard C++ library (STL).

-- 


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

[Bug fortran/21918] Warnings about unused variables should point to the declaration

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-05 
06:39 ---
Confirmed, all variables have the same location for some reason, even 
parameters.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2005-06-05 06:39:21
   date||


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

[Bug bootstrap/21878] Mingw32 target doesn't compile because of an internal compiler error

[sherpya at netfarm dot it]

--- Additional Comments From sherpya at netfarm dot it  2005-06-05 06:48 
---
yes it's true, but it's not a solution I'm trying to isolate to problem :)

-- 


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

[Bug fortran/21902] ICE in build_array_type, at tree.c:4581

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-05 
06:48 ---
Note I started to reduce this and removed a whole function or two and was able 
to reduce further but I 
stoped because I ran out of time.

-- 
   What|Removed |Added

   Keywords||ice-on-valid-code


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

[Bug bootstrap/21878] Mingw32 target doesn't compile because of an internal compiler error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-05 
06:50 ---
(In reply to comment #6)
> yes it's true, but it's not a solution I'm trying to isolate to problem :)

I already did in PR 21766.  See comment #4.

-- 


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-05 
06:51 ---
Patch posted here: .

-- 
   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2005-
   ||05/msg02945.html
   Keywords||patch


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

[Bug tree-optimization/21081] [4.0/4.1 Regression] internal compiler error: verify_stmts failed.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-05 
06:51 ---
Newer patch posted here: 
.

-- 
   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
   |patches/2005-   |patches/2005-
   |05/msg9.html|05/msg02945.html


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

[Bug middle-end/21275] [4.0/4.1 Regression] gcc 4.0.0 crash with mingw when using stdout in global var

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-05 
06:52 ---
New patch here: .

-- 
   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
   |patches/2005-   |patches/2005-
   |05/msg9.html|05/msg02945.html


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