[Bug c++/33467] Compilation error while compiling DynCommon.cpp

[pinakee dot b at xius dot com]

--- Comment #2 from pinakee dot b at xius dot com  2007-09-18 07:05 ---
Created an attachment (id=14218)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14218&action=view)
The attachment is the zip of preprocessed file of the source file.

Since the file size was more than that allowed, it has been zipped.


-- 


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

[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.

[rask at gcc dot gnu dot org]

--- Comment #23 from rask at gcc dot gnu dot org  2007-09-18 07:14 ---
> configure:10398: error: unrecognizable insn:
> (insn 105 104 106 2 (set (subreg:QI (reg/f:HI 52) 0)
> (subreg:QI (label_ref:HI 57) 0)) -1 (nil))
> configure:10398: internal compiler error: in extract_insn, at recog.c:1990

In define_insn_and_split "*movhi", add the line

   && LABEL_REF != GET_CODE (operands[1])

where it already says

   && SYMBOL_REF != GET_CODE (operands[1])

and the error should go away.


-- 


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

[Bug fortran/33221] Cannot declare variables of TYPE without components

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-09-18 07:32:37
   date||


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

[Bug fortran/33221] Cannot declare variables of TYPE without components

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2007-09-18 08:26 
---
This is because, in gfc_use_derived (symbol.c), when checking whether a derived
type is in the current unit or a parent unit, we check (sym->components !=
NULL) and if it's true, we take it to mean that the derived type was in a
parent unit (while, in fact, it's simply NULL because there *is* no component).
We need either a better test for the derived type being in the current scoping
unit, or a way to indicate a derived type without components other than setting
components to NULL.

One thing that comes to mind is the following patch. It allows derived types
with zero components to be accepted, but I fear that it might make us accept
invalid code with empty derived types outside the current scoping unit.



Index: symbol.c
===
--- symbol.c(revision 128540)
+++ symbol.c(working copy)
@@ -1703,7 +1703,7 @@ gfc_use_derived (gfc_symbol *sym)
   gfc_symtree *st;
   int i;

-  if (sym->components != NULL)
+  if (sym->components != NULL || sym->attr.zero_comp)
 return sym;   /* Already defined.  */

   if (sym->ns->parent == NULL)
Index: decl.c
===
--- decl.c  (revision 128540)
+++ decl.c  (working copy)
@@ -3414,7 +3414,8 @@ gfc_match_data_decl (void)
   goto cleanup;
 }

-  if (current_ts.type == BT_DERIVED && current_ts.derived->components == NULL)
+  if (current_ts.type == BT_DERIVED && current_ts.derived->components == NULL
+  && !current_ts.derived->attr.zero_comp)
 {

   if (current_attr.pointer && gfc_current_state () == COMP_DERIVED)
Index: gfortran.h
===
--- gfortran.h  (revision 128540)
+++ gfortran.h  (working copy)
@@ -650,8 +650,9 @@ typedef struct
   unsigned cray_pointer:1, cray_pointee:1;

   /* The symbol is a derived type with allocatable components, pointer 
- components or private components, possibly nested.  */
-  unsigned alloc_comp:1, pointer_comp:1, private_comp:1;
+ components or private components, possibly nested.  zer_comp
+ is true if the derived type has no component at all.  */
+  unsigned alloc_comp:1, pointer_comp:1, private_comp:1, zero_comp:1;

   /* The namespace where the VOLATILE attribute has been set.  */
   struct gfc_namespace *volatile_ns;
Index: resolve.c
===
--- resolve.c   (revision 128540)
+++ resolve.c   (working copy)
@@ -7567,7 +7567,8 @@ resolve_symbol (gfc_symbol *sym)
  the type is not declared in the scope of the implicit
  statement. Change the type to BT_UNKNOWN, both because it is so
  and to prevent an ICE.  */
-  if (sym->ts.type == BT_DERIVED && sym->ts.derived->components == NULL)
+  if (sym->ts.type == BT_DERIVED && sym->ts.derived->components == NULL
+  && !sym->ts.derived->attr.zero_comp)
 {
   gfc_error ("The derived type '%s' at %L is of type '%s', "
 "which has not been defined", sym->name,
Index: parse.c
===
--- parse.c (revision 128540)
+++ parse.c (working copy)
@@ -1651,6 +1651,9 @@ parse_derived (void)
}
 }

+  if (!seen_component)
+sym->attr.zero_comp = 1;
+
   pop_state ();
 }



-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org


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

[Bug c++/31863] [4.1/4.2/4.3 Regression] g++-4.1: out of memory with -O1/-O2

[rguenther at suse dot de]

--- Comment #11 from rguenther at suse dot de  2007-09-18 08:44 ---
Subject: Re:  [4.1/4.2/4.3 Regression] g++-4.1: out of memory
 with -O1/-O2

On Tue, 18 Sep 2007, alexander at kogan dot nnov dot ru wrote:
> --- Comment #10 from alexander at kogan dot nnov dot ru  2007-09-18 04:58 
> ---
> Hi!
> 
> Is there any progress with this bug?
> We are waiting impatiently for fix!

I have one fix in this are in the queue, but it does unfortunately
not completely solve this problem.


-- 


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

[Bug tree-optimization/33340] [4.3 Regression] ICE: SSA corruption with -O (FRE)

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-09-18 08:46 ---
Subject: Bug 33340

Author: rguenth
Date: Tue Sep 18 08:46:23 2007
New Revision: 128571

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128571
Log:
2007-09-18  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/33340
* tree-ssa-sccvn.c (set_ssa_val_to): Do not set values to
SSA_NAMEs that occur in abnormal PHI nodes.

* g++.dg/torture/pr33340.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr33340.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c


-- 


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

[Bug tree-optimization/31863] [4.1/4.2/4.3 Regression] g++-4.1: out of memory with -O1/-O2

[alexander at kogan dot nnov dot ru]

--- Comment #12 from alexander at kogan dot nnov dot ru  2007-09-18 09:07 
---
What do u mean 'not completely'?
Can I try this fix?


-- 


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

[Bug tree-optimization/31863] [4.1/4.2/4.3 Regression] g++-4.1: out of memory with -O1/-O2

[rguenther at suse dot de]

--- Comment #13 from rguenther at suse dot de  2007-09-18 09:11 ---
Subject: Re:  [4.1/4.2/4.3 Regression] g++-4.1:
 out of memory with -O1/-O2

On Tue, 18 Sep 2007, alexander at kogan dot nnov dot ru wrote:

> --- Comment #12 from alexander at kogan dot nnov dot ru  2007-09-18 09:07 
> ---
> What do u mean 'not completely'?
> Can I try this fix?

I mean there is a memleak that I plugged, but memory usage is still
exponential in the number of template parameters.


-- 


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

[Bug tree-optimization/33340] [4.3 Regression] ICE: SSA corruption with -O (FRE)

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2007-09-18 09:19 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/33468] New: C++: Invalid interpretation of friendness with nested classes

[gcc-bugzilla at gcc dot gnu dot org]

Gcc's friend-mechanism seems to expand to nested classes as well, although
the C++ standard explicitly tells differently.

The following example is almost straight from the C++ standard (11.4/2). The
only change is that inheritance is commented out for class X (in order to
remove the first error in the example). Gcc compiles this with no error
messages, even with -Wall -pedantic

// test.cc
class A {
  class B { };
  friend class X;
};

// INHERITANCE BELOW COMMENTED OUT BY ME
class X /* : A::B */ { // ill-formed: A::B cannot be accessed
  // in the base-clause for X
  A::B mx; // OK: A::B used to declare member of X
  class Y : A::B { // OK: A::B used to declare member of X
// !!! The illegal line below compiles fine !!
A::B my; // ill-formed: A::B cannot be accessed
// to declare members of nested class of X
  };
};

Environment:
System: Linux mustikkakukko 2.6.18.8-0.3-default #1 SMP Tue Apr 17 08:42:35 UTC
2007 x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64


host: x86_64-suse-linux-gnu
build: x86_64-suse-linux-gnu
target: x86_64-suse-linux-gnu
configured with: ../gcc-4.2.1/configure --prefix=/usr/local/gcc-4.2.1
--bindir=/usr/local/gcc-4.2.1/bin64 --enable-languages=c,c++
--enable-__cxa_atexit --host=x86_64-suse-linux --with-arch=nocona
--with-tune=nocona

How-To-Repeat:
  g++ -W -Wall -pedantic -c test.cc
  (No errors result in compilation.)


-- 
   Summary: C++: Invalid interpretation of friendness with nested
classes
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bitti at iki dot fi
 GCC build triplet: x86_64-suse-linux-gnu
  GCC host triplet: x86_64-suse-linux-gnu
GCC target triplet: x86_64-suse-linux-gnu


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

[Bug fortran/33469] New: Add one digit to the default formatted output

[dominiq at lps dot ens dot fr]

Following a discussion on IRC with FX Coudert, I think the number of digits
printed by default in formatted output should be increased by one. Otherwise
the logic of the test case large_real_kind_form_io_2.f90 is flawed as shown by
the attached code. Its output on AMD64 is

 real(4)
 default 808
 1PG20.61881
 1PG20.7 808
 1PG20.8   0

 real(8)
 default 1778
 1PG30.141978
 1PG30.151778
 1PG30.16   0

 real(10)
 default  916
 1PG60.181892
 1PG60.19 916
 1PG60.20   0

where the integers are the number of failures to read back a number. g95 gives:

 real(4)
 default 0
 1PG20.6 1881
 1PG20.7 808
 1PG20.8 0

 real(8)
 default  0
 1PG30.14 1978
 1PG30.15 1778
 1PG30.16 0

 real(10)
 default  0
 1PG60.18 1892
 1PG60.19 916
 1PG60.20 0


-- 
   Summary: Add one digit to the default formatted output
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr


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

[Bug tree-optimization/31863] [4.1/4.2/4.3 Regression] g++-4.1: out of memory with -O1/-O2

[alexander at kogan dot nnov dot ru]

--- Comment #14 from alexander at kogan dot nnov dot ru  2007-09-18 09:55 
---
Ok. Do you mean the attached test doesn't work even with this fix? But are
there plans to eliminate this problem completely?


-- 


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

[Bug fortran/33469] Add one digit to the default formatted output

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2007-09-18 09:47 ---
Created an attachment (id=14219)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14219&action=view)
test case


-- 


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

[Bug c++/33470] New: Reassignment of a reference to a polymorphic class fails at runtime

[photon at seznam dot cz]

The following code compiles cleanly with 4.2.1. The expected output is "C" but
the executable outputs "B".


#include 
using namespace std;

struct A
{
virtual ~A() { }
virtual void f() { cout << "A"; }
};

struct B : public A
{
virtual void f() { cout << "B"; }
};

struct C : public A
{
virtual void f() { cout << "C"; }
};

int main(int argc, char **argv)
{
B Binst;
C Cinst;

A &Aref = Binst;
Aref = Cinst;

Aref.f();
return 0;
}


-- 
   Summary: Reassignment of a reference to a polymorphic class fails
at runtime
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: photon at seznam dot cz


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

[Bug c++/33459] [4.2/4.3 regression] ICE on reference member in union

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2007-09-18 10:55 ---
Janis, is it possible to have a regression hunt? Thanks in advance.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot
   ||org, pcarlini at suse dot de


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

[Bug tree-optimization/31863] [4.1/4.2/4.3 Regression] g++-4.1: out of memory with -O1/-O2

[rguenther at suse dot de]

--- Comment #15 from rguenther at suse dot de  2007-09-18 10:58 ---
Subject: Re:  [4.1/4.2/4.3 Regression] g++-4.1:
 out of memory with -O1/-O2

On Tue, 18 Sep 2007, alexander at kogan dot nnov dot ru wrote:

> --- Comment #14 from alexander at kogan dot nnov dot ru  2007-09-18 09:55 
> ---
> Ok. Do you mean the attached test doesn't work even with this fix? But are
> there plans to eliminate this problem completely?

The testcase doesn't work with the fix.


-- 


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

[Bug tree-optimization/31863] [4.1/4.2/4.3 Regression] g++-4.1: out of memory with -O1/-O2

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2007-09-18 11:22 
---
Subject: Bug 31863

Author: rguenth
Date: Tue Sep 18 11:22:47 2007
New Revision: 128573

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128573
Log:
2007-09-18  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/31863
* tree-ssa-structalias.c (create_variable_info_for): Always
free the fieldstack.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-structalias.c


-- 


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

[Bug fortran/33221] Cannot declare variables of TYPE without components

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-09-18 11:31 
---
(In reply to comment #2)
> One thing that comes to mind is the following patch. It allows derived types
> with zero components to be accepted, but I fear that it might make us accept
> invalid code with empty derived types outside the current scoping unit.

After thinking some more, I think that fear is not justified. There are a few
other places that need adjusting, but I'll submit a complete patch shortly.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-09-18 07:32:37 |2007-09-18 11:31:46
   date||
   Target Milestone|--- |4.3.0


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

[Bug c++/33470] Reassignment of a reference to a polymorphic class fails at runtime

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-09-18 11:00 ---
No, "B" is correct.


A &Aref = Binst;
Aref = Cinst;

is the same as:
Binst = (A)Cinst;


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/31863] [4.1/4.2/4.3 Regression] g++-4.1: out of memory with -O1/-O2

[rguenth at gcc dot gnu dot org]

--- Comment #17 from rguenth at gcc dot gnu dot org  2007-09-18 11:58 
---
Note that the double virtual inheritance in the Serializer template creates the
exponential behavior.  You can fix this at the source level by instead
doing

template 
class Serializer >:
public virtual Serializer
{
};

template 
class Serializer >:
public virtual Serializer,
public Serializer
{
};

template 
class Serializer : public virtual Factory
{
};

which also makes more sense(?).  Back to marking this as possibly a C++
frontend bug - though I'm inclined to close this bug as INVALID.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|tree-optimization   |c++


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

[Bug c++/33470] Reassignment of a reference to a polymorphic class fails at runtime

[photon at seznam dot cz]

--- Comment #2 from photon at seznam dot cz  2007-09-18 12:01 ---
(In reply to comment #1)
> No, "B" is correct.
> 
> 
> A &Aref = Binst;
> Aref = Cinst;
> 
> is the same as:
> Binst = (A)Cinst;
> 

"Binst = (A)Cinst" would not compile (C is not derived from B).


-- 

photon at seznam dot cz changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug middle-end/33471] [4.3 regression] internal compiler error: in extract_insn, at recog.c:1990

[bero at arklinux dot org]

--- Comment #1 from bero at arklinux dot org  2007-09-18 12:26 ---
Created an attachment (id=14220)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14220&action=view)
bzip2-ed preprocessed source


-- 


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

[Bug middle-end/33471] New: [4.3 regression] internal compiler error: in extract_insn, at recog.c:1990

[bero at arklinux dot org]

Granted, the compiler flags I've used for testing are asking for trouble...

$ gcc -march=pentium4 -mfpmath=sse,387 -o mplayer.o mplayer.i
mplayer.c: In function 'main':
mplayer.c:3750: error: unrecognizable insn:
(insn 5170 5169 5171 674 mplayer.c:3552 (set (reg:SF 258 [ D.19380 ])
(float:SF (reg:DI 259 [ step_sec.1242 ]))) -1 (nil))
mplayer.c:3750: internal compiler error: in extract_insn, at recog.c:1990
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: [4.3 regression] internal compiler error: in
extract_insn, at recog.c:1990
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org
 GCC build triplet: i586-pc-linux-gnu
  GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu


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

[Bug middle-end/33472] New: ICE and invalid rtl sharing on x86_64-mingw cross-compiler

[fxcoudert at gcc dot gnu dot org]

This bug happens on a cross-compiler targetting x86_64-pc-mingw32, but not on a
native x86_64-linux compiler. Both compilers are built with SVN trunk from the
same revision (128540).

Witn -m64, it doesn't error out at -O0, there is an ICE at -O1 and a different
error at -O2. With -m32, compilation seems fine in all cases.


$ cat foo.c
_Complex float
product_c4 (_Complex float *src)
{
  _Complex float res;
  int n;

  res = 1;
  for (n = 0; n < 10; n++)
res *= src[n];
  return res;
}
$ ./gcc/cc1 -O0 -std=c99 -quiet foo.c -m64
$ ./gcc/cc1 -O1 -std=c99 -quiet foo.c -m64
foo.c: In function ‘product_c4’:
foo.c:11: internal compiler error: in reg_overlap_mentioned_p, at
rtlanal.c:1398
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$ ./gcc/cc1 -O2 -std=c99 -quiet foo.c -m64
foo.c: In function ‘product_c4’:
foo.c:11: error: invalid rtl sharing found in the insn
(insn 114 113 115 2 foo.c:9 (set (subreg:DI (reg:SC 92) 0)
(reg:DI 133)) -1 (nil))
foo.c:11: error: shared rtx
(subreg:DI (reg:SC 92) 0)
foo.c:11: internal compiler error: internal consistency failure
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


My cross-compiler is:

$ ./gcc/xgcc -v
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with: /home/fxcoudert/devel/trunk/configure
--prefix=/home/fxcoudert/mingw64-cross/install --target=x86_64-pc-mingw32
--enable-languages=c,fortran --disable-werror --with-gmp=/home/fxcoudert/local
Thread model: win32
gcc version 4.3.0 20070917 (experimental) [trunk revision 128540] (GCC)


The backtrace for the ICE at -O1 is:

#0  fancy_abort (file=0xb7d6e0 "/home/fxcoudert/devel/trunk/gcc/rtlanal.c",
line=1398, function=0xb7d670 "reg_overlap_mentioned_p")
at /home/fxcoudert/devel/trunk/gcc/diagnostic.c:654
#1  0x0067a8e9 in reg_overlap_mentioned_p (x=0x2b4d7a1fd180,
in=0x2b4d7a1fa740) at /home/fxcoudert/devel/trunk/gcc/rtlanal.c:1398
#2  0x0067ac70 in reg_used_between_p (reg=0x2b4d7a1fd180,
from_insn=, to_insn=0xb7d670)
at /home/fxcoudert/devel/trunk/gcc/rtlanal.c:721
#3  0x00a0ec1e in can_combine_p (insn=0x2b4d7a1fe050,
i3=0x2b4d7a1f29b0, pred=, succ=0x2b4d7a1f2f50,
pdest=0x7fff30e85460, psrc=0x7fff30e85458)
at /home/fxcoudert/devel/trunk/gcc/combine.c:1605
#4  0x00a15d18 in try_combine (i3=0x2b4d7a1f29b0,
i2=, i1=0x2b4d7a1fe050,
new_direct_jump_p=0x7fff30e854f4)
at /home/fxcoudert/devel/trunk/gcc/combine.c:2481
#5  0x00a1a09d in rest_of_handle_combine ()
at /home/fxcoudert/devel/trunk/gcc/combine.c:1152


I can investigate further if need be, tell me what to do. If you have access to
the GCC compiler farm, my build is available in
/home/fxcoudert/mingw64-cross/ibin


PS: the reason I found this bug is that it shows up while building libgfortran
for this cross-compiler :(


-- 
   Summary: ICE and invalid rtl sharing on x86_64-mingw cross-
compiler
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-pc-mingw32


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

[Bug tree-optimization/33458] [4.3 regression] ICE "PHI def is not a GIMPLE value"

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2007-09-18 12:56 ---
We substitute into the invariant address &.a[0] *this, which results
in a non-invariant address.


-- 


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

[Bug tree-optimization/24309] [4.1/4.2/4.3 Regression] ICE with -O3 -ftree-loop-linear

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2007-09-18 13:16 
---
I can still see the ICE with -O2 -ftree-loop-linear and the testcase from
comment
2 on trunk (x86_64):

t.i: In function 'lsp_weight_quant':
t.i:3: internal compiler error: in lambda_loopnest_to_gcc_loopnest, at
lambda-code.c:1839

  gcc_assert (TREE_CODE (stmt) != PHI_NODE);

but

(gdb) call debug_generic_expr (stmt)
best_id_6 = PHI 


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2007-08-06 14:56:17 |2007-09-18 13:16:26
   date||


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

[Bug target/33397] fr30: ICE: in dwarf2out_frame_debug_expr, at dwarf2out.c:1667

[rask at gcc dot gnu dot org]

--- Comment #2 from rask at gcc dot gnu dot org  2007-09-18 13:26 ---
Fixed as of revision 128577.


-- 

rask at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords|ice-checking|
 Resolution||FIXED


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

[Bug tree-optimization/33319] [4.2/4.3 regression] g++.dg/tree-ssa/pr27549.C ICE with vectorization

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2007-09-18 13:02 ---
Still fails.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2007-09-16 13:28:35 |2007-09-18 13:02:40
   date||


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

[Bug tree-optimization/24309] [4.1/4.2/4.3 Regression] ICE with -O3 -ftree-loop-linear

[rguenth at gcc dot gnu dot org]

--- Comment #17 from rguenth at gcc dot gnu dot org  2007-09-18 13:17 
---
Sebastian, can you have a look at this?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||spop at gcc dot gnu dot org


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

[Bug target/33388] fr30: ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:983

[rask at gcc dot gnu dot org]

--- Comment #3 from rask at gcc dot gnu dot org  2007-09-18 13:25 ---
Subject: Bug 33388

Author: rask
Date: Tue Sep 18 13:24:44 2007
New Revision: 128577

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128577
Log:
PR target/33388
PR target/33397
* config/fr30/fr30.md (addsi3): Check REG_P() before calling REGNO().
(addsi_small_int): Likewise.
(addsi_big_int): Use rtx_equal_p() instead of REGNO() comparison.
(one_cmplsi2): Likewise.
(negsi2): Delete.
(enter_func): Expand insn using hard_frame_pointer_rtx and
stack_pointer_rtx.
(*enter_func): New.
* config/fr30/fr30.c (fr30_expand_prologue): Check for
hard_frame_pointer_rtx instead of using REGNO() check.
Properly sign extend GEN_INT() argument.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/fr30/fr30.c
trunk/gcc/config/fr30/fr30.md


-- 


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

[Bug target/33397] fr30: ICE: in dwarf2out_frame_debug_expr, at dwarf2out.c:1667

[rask at gcc dot gnu dot org]

--- Comment #1 from rask at gcc dot gnu dot org  2007-09-18 13:25 ---
Subject: Bug 33397

Author: rask
Date: Tue Sep 18 13:24:44 2007
New Revision: 128577

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128577
Log:
PR target/33388
PR target/33397
* config/fr30/fr30.md (addsi3): Check REG_P() before calling REGNO().
(addsi_small_int): Likewise.
(addsi_big_int): Use rtx_equal_p() instead of REGNO() comparison.
(one_cmplsi2): Likewise.
(negsi2): Delete.
(enter_func): Expand insn using hard_frame_pointer_rtx and
stack_pointer_rtx.
(*enter_func): New.
* config/fr30/fr30.c (fr30_expand_prologue): Check for
hard_frame_pointer_rtx instead of using REGNO() check.
Properly sign extend GEN_INT() argument.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/fr30/fr30.c
trunk/gcc/config/fr30/fr30.md


-- 


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

[Bug target/33388] fr30: ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:983

[rask at gcc dot gnu dot org]

--- Comment #4 from rask at gcc dot gnu dot org  2007-09-18 13:28 ---
Fixed with revision 128577.


-- 

rask at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/12019] check for working C compiler on newlib targets fails due to missing crt0.o

[rask at gcc dot gnu dot org]

--- Comment #3 from rask at gcc dot gnu dot org  2007-09-18 13:34 ---
With bug 33388 and bug 33397 fixed, the fix for bug 32154 fixes this one as
well (as of revision 128577).


-- 

rask at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug preprocessor/33473] GCC does not correctly generate dependencies correctly for precompiled headers

[rswan at signetic dot ca]

--- Comment #1 from rswan at signetic dot ca  2007-09-18 13:38 ---
Created an attachment (id=14221)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14221&action=view)
testcase archive

Extract archive. Invoke make within gch_bug directory. Bug seen in generated
main.d dependency output. Optionally edit Makefile (see comments within) to
demonstrate correct behaviour when not using precompiled headers.


-- 


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

[Bug target/33471] [4.3 regression] internal compiler error: in extract_insn, at recog.c:1990

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2007-09-18 13:48 ---
Insn constraint for following insn should be fixed:

(define_insn "*floatdi2_i387"
  [(set (match_operand:MODEF 0 "register_operand" "=f,f")
(float:MODEF
  (match_operand:DI 1 "nonimmediate_operand" "m,?r")))]
  "TARGET_80387
   && (!TARGET_SSE_MATH || !TARGET_64BIT
   || !SSE_FLOAT_MODE_P (GET_MODE (operands[0])))"
  "@
   fild%z1\t%1
   #"
  [(set_attr "type" "fmov,multi")
   (set_attr "mode" "")
   (set_attr "unit" "*,i387")
   (set_attr "fp_int_src" "true")])

Jan, could you take a look?


-- 


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

[Bug preprocessor/33473] New: GCC does not correctly generate dependencies correctly for precompiled headers

[rswan at signetic dot ca]

Hello;

GCC does not correctly generate dependencies correctly with g++ -MD when
precompiled headers are used. I've attached an example which generates main.d
while compiling main.cpp. main.cpp includes include/bink.h. When the include
path contains the precompiled bink.h.gch (only), main.d does not contain any
dependency on bink.h.gch.

When the compiler includes bink.h, main.d includes the dependency.

I get the same behavior with version 3.4.6 and 4.1.2

> gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)


-- 
   Summary: GCC does not correctly generate dependencies correctly
for precompiled headers
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rswan at signetic dot ca


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

[Bug target/33471] [4.3 regression] internal compiler error: in extract_insn, at recog.c:1990

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2007-09-18 13:40 ---
Caused by X86_USE_VECTOR_CONVERTS or X86_TUNE_INTER_UNIT_CONVERSIONS patch.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
  Component|middle-end  |target
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-09-18 13:40:16
   date||
   Target Milestone|--- |4.3.0


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

[Bug target/33471] [4.3 regression] internal compiler error: in extract_insn, at recog.c:1990

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2007-09-18 14:03 ---
Sorry, this is already fixed in latest SVN.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/33464] [4.3 regression] Broken diagnostic: 'trait_expr' not supported by dump_expr

[paolo at gcc dot gnu dot org]

--- Comment #1 from paolo at gcc dot gnu dot org  2007-09-18 14:35 ---
Subject: Bug 33464

Author: paolo
Date: Tue Sep 18 14:35:42 2007
New Revision: 128578

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128578
Log:
/cp
2007-09-18  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/33464
* cxx-pretty-print.c (pp_cxx_trait_expression): Add.
(pp_cxx_primary_expression): Use it.
* cxx-pretty-print.h (pp_cxx_trait_expression): Declare.
* error.c (dump_expr): Use it.

/testsuite
2007-09-18  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/33464
* g++.dg/ext/is_class_error.C: Rename to is_class_error1.C.
* g++.dg/ext/is_class_error2.C: New.

Added:
trunk/gcc/testsuite/g++.dg/ext/is_class_error1.C
  - copied unchanged from r128570,
trunk/gcc/testsuite/g++.dg/ext/is_class_error.C
trunk/gcc/testsuite/g++.dg/ext/is_class_error2.C
Removed:
trunk/gcc/testsuite/g++.dg/ext/is_class_error.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cxx-pretty-print.c
trunk/gcc/cp/cxx-pretty-print.h
trunk/gcc/cp/error.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/33464] [4.3 regression] Broken diagnostic: 'trait_expr' not supported by dump_expr

[pcarlini at suse dot de]

--- Comment #2 from pcarlini at suse dot de  2007-09-18 14:36 ---
Fixed.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

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

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-09-18 14:44:59
   date||


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

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

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-09-18 15:23:52
   date||


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

[Bug c++/33470] Reassignment of a reference to a polymorphic class fails at runtime

[photon at seznam dot cz]

--- Comment #3 from photon at seznam dot cz  2007-09-18 15:12 ---
(In reply to comment #1)
> No, "B" is correct.
> 
> 
> A &Aref = Binst;
> Aref = Cinst;
> 
> is the same as:
> Binst = (A)Cinst;
> 

The compiler treats this case as Ainst = (A) Cinst.


-- 

photon at seznam dot cz changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

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

[paolo at gcc dot gnu dot org]

--- Comment #1 from paolo at gcc dot gnu dot org  2007-09-18 15:38 ---
Subject: Bug 33463

Author: paolo
Date: Tue Sep 18 15:38:02 2007
New Revision: 128582

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128582
Log:
/cp
2007-09-18  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/33463
* cxx-pretty-print.c (pp_cxx_postfix_expression): Split
out case TYPEID_EXPR to...
(pp_cxx_typeid_expression): ... here; use pp_cxx_left_paren
and pp_cxx_right_paren.
* cxx-pretty-print.h (pp_cxx_typeid_expression): Declare.
* error.c (dump_expr): Use it.

/testsuite
2007-09-18  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/33463
* g++.dg/rtti/typeid6.C: New.

Added:
trunk/gcc/testsuite/g++.dg/rtti/typeid6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cxx-pretty-print.c
trunk/gcc/cp/cxx-pretty-print.h
trunk/gcc/cp/error.c
trunk/gcc/testsuite/ChangeLog


-- 


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

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

[pcarlini at suse dot de]

--- Comment #2 from pcarlini at suse dot de  2007-09-18 15:40 ---
Fixed in mainline.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

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


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

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

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2007-09-18 15:34 ---
--- gcc/cp/error.c.jj   2007-09-11 12:43:28.0 +0200
+++ gcc/cp/error.c  2007-09-18 17:25:14.0 +0200
@@ -2054,6 +2054,15 @@ dump_expr (tree t, int flags)
   dump_type (t, flags);
   break;

+case VA_ARG_EXPR:
+  pp_cxx_identifier (cxx_pp, "__builtin_va_arg");
+  pp_cxx_left_paren (cxx_pp);
+  dump_expr (TREE_OPERAND (t, 0), flags);
+  pp_separate_with_comma (cxx_pp);
+  dump_type (TREE_TYPE (t), flags);
+  pp_cxx_right_paren (cxx_pp);
+  break;
+
   /*  This list is incomplete, but should suffice for now.
  It is very important that `sorry' does not call
  `report_error_function'.  That could cause an infinite loop.  */


-- 


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

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

[pcarlini at suse dot de]

--- Comment #2 from pcarlini at suse dot de  2007-09-18 15:39 ---
Thanks a lot Jakub, I'm going to do exactly that but as part of
cxx_pretty_print.c


-- 


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

[Bug rtl-optimization/33410] [4.2/4.3 regression] ICE in iv_analyze_expr, at loop-iv.c:934

[belyshev at depni dot sinp dot msu dot ru]

--- Comment #2 from belyshev at depni dot sinp dot msu dot ru  2007-09-18 
15:59 ---
Confirmed.
Also breaks bootstrap if CFLAGS is set to -O3.
I couldn't reproduce this with 4.1 so "reported against = 4.1.0" is probably
typo.
Can be reproduced in a cross compiler.


-- 

belyshev at depni dot sinp dot msu dot ru changed:

   What|Removed |Added

 CC||belyshev at depni dot sinp
   ||dot msu dot ru
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|alpha-linux-gnu |
   GCC host triplet|alpha-linux-gnu |
   Keywords||build
  Known to work||4.1.2
   Last reconfirmed|-00-00 00:00:00 |2007-09-18 15:59:38
   date||
Summary|ICE in iv_analyze_expr, at  |[4.2/4.3 regression] ICE in
   |loop-iv.c:934   |iv_analyze_expr, at loop-
   ||iv.c:934
Version|4.1.0   |4.2.0


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

[Bug target/33474] New: bfin: ICE: RTL check: expected code 'set' or 'clobber', have 'parallel' in bfin_adjust_cost, at config/bfin/bfin.c:3120

[rask at gcc dot gnu dot org]

Build failure in target libiberty:

/home/rask/build/gcc-bfin-unknown-elf/./gcc/xgcc
-B/home/rask/build/gcc-bfin-unknown-elf/./gcc/ -nostdinc
-B/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/newlib/ -isystem
/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/newlib/targ-include
-isystem /n/12/rask/src/all/newlib/libc/include
-B/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libgloss/bfin
-L/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libgloss/libnosys
-L/n/12/rask/src/all/libgloss/bfin -B/usr/local/bfin-unknown-elf/bin/
-B/usr/local/bfin-unknown-elf/lib/ -isystem /usr/local/bfin-unknown-elf/include
-isystem /usr/local/bfin-unknown-elf/sys-include
-L/home/rask/build/gcc-bfin-unknown-elf/./ld -c -DHAVE_CONFIG_H -O2 -g -O2  
-I. -I/n/12/rask/src/all/libiberty/../include  -W -Wall -Wwrite-strings
-Wc++-compat -Wstrict-prototypes -pedantic 
/n/12/rask/src/all/libiberty/hashtab.c -o hashtab.o
/n/12/rask/src/all/libiberty/hashtab.c: In function 'iterative_hash':
/n/12/rask/src/all/libiberty/hashtab.c:955: internal compiler error: RTL check:
expected code 'set' or 'clobber', have 'parallel' in bfin_adjust_cost, at
config/bfin/bfin.c:3120

Configure flags:
--target bfin-unknown-elf --enable-checking=yes,rtl --with-newlib --enable-sim
--disable-gdb --disable-nls


-- 
   Summary: bfin: ICE: RTL check: expected code 'set' or 'clobber',
have 'parallel' in bfin_adjust_cost, at
config/bfin/bfin.c:3120
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, build, ice-checking
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at gcc dot gnu dot org
GCC target triplet: bfin-unknown-elf


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

Re: [Bug c++/33462] [4.1/4.2/4.3 regression] Broken diagnostic: 'va_arg_expr' not supported by dump_expr

[Andrew Pinski]

On 18 Sep 2007 15:34:16 -, jakub at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> +case VA_ARG_EXPR:
> +  pp_cxx_identifier (cxx_pp, "__builtin_va_arg");


I would not use __builtin_va_arg here since this diagnostic, I would
just use va_arg.

Thanks,
Andrew Pinski

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

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-09-18 16:40 ---
Subject: Re:  [4.1/4.2/4.3 regression] Broken diagnostic: 'va_arg_expr' not
supported by dump_expr

On 18 Sep 2007 15:34:16 -, jakub at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
> +case VA_ARG_EXPR:
> +  pp_cxx_identifier (cxx_pp, "__builtin_va_arg");


I would not use __builtin_va_arg here since this diagnostic, I would
just use va_arg.

Thanks,
Andrew Pinski


-- 


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

[Bug bootstrap/32272] make exit because build/genmodes.exe doesn't exist

[william dot adams at dot dot state dot fl dot us]

--- Comment #3 from william dot adams at dot dot state dot fl dot us  
2007-09-18 17:24 ---
4.2.1 had other build problems.
but this particular one appeared after i upgraded binutils to 2.18.


-- 


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

[Bug fortran/31244] data initialization with more than 2**32 elements

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2007-09-18 17:56 ---
confirmed.

The problem is found in decl.c(top_val_list) at lines 404-411, which
are 

  signed int tmp;
  msg = gfc_extract_int (expr, &tmp);
  gfc_free_expr (expr);
  if (msg != NULL)
{
  gfc_error (msg);
  return MATCH_ERROR;
}

gfc_extract_int is trying to put 4294967296_8 into a signed int.
This probably needs to be changed to accommodate the type of
an array index.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu dot org


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

[Bug fortran/33469] Add one digit to the default formatted output

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2007-09-18 17:56 ---
A compiler comparison:

 real(4)  gfortran g95 NAGf95 ifort sunf95 openf95
 default   808   0808   808 0   0
 1PG20.6  18811881   1881  1881  18811881
 1PG20.7   808 808808   808   808 808
 1PG20.8 0   0  0 0 0   0

 real(8)
 default  1778   0  0  1778 0   0
 1PG30.14 19781978   1978  1978  19781978
 1PG30.15 17781778   1778  1778  17781778
 1PG30.160   0  0 0   890   0
  ^^^ ?


-- 


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

[Bug c++/33475] New: New warning suggestion: virtual functions called from constructors/destructors

[yuri at tsoft dot com]

I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.

During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived classes.


-- 
   Summary: New warning suggestion: virtual functions called from
constructors/destructors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com


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

[Bug c++/33476] New: New warning suggestion: virtual functions called from constructors/destructors

[yuri at tsoft dot com]

I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.

During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived classes.


-- 
   Summary: New warning suggestion: virtual functions called from
constructors/destructors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com


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

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

[paolo at gcc dot gnu dot org]

--- Comment #4 from paolo at gcc dot gnu dot org  2007-09-18 18:05 ---
Subject: Bug 33462

Author: paolo
Date: Tue Sep 18 18:05:40 2007
New Revision: 128584

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128584
Log:
/cp
2007-09-18  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/33462
* cxx-pretty-print.c (pp_cxx_va_arg_expression): Add.
(pp_cxx_primary_expression): Use it.
* cxx-pretty-print.h (pp_cxx_va_arg_expression): Declare.
* error.c (dump_expr): Use it.

/testsuite
2007-09-18  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/33462
* g++.dg/ext/va-arg1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/ext/va-arg1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cxx-pretty-print.c
trunk/gcc/cp/cxx-pretty-print.h
trunk/gcc/cp/error.c
trunk/gcc/testsuite/ChangeLog


-- 


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

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

[pcarlini at suse dot de]

--- Comment #5 from pcarlini at suse dot de  2007-09-18 18:06 ---
Fixed in mainline.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

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


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

[Bug c++/33477] New: New warning suggestion: virtual functions called from constructors/destructors

[yuri at tsoft dot com]

I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.

During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived classes.


-- 
   Summary: New warning suggestion: virtual functions called from
constructors/destructors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com


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

[Bug c++/33478] New: New warning suggestion: virtual functions called from constructors/destructors

[yuri at tsoft dot com]

I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.

During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived classes.


-- 
   Summary: New warning suggestion: virtual functions called from
constructors/destructors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com


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

[Bug c++/33478] New warning suggestion: virtual functions called from constructors/destructors

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2007-09-18 18:29 ---


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


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/33477] New warning suggestion: virtual functions called from constructors/destructors

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2007-09-18 18:29 ---
*** Bug 33478 has been marked as a duplicate of this bug. ***


-- 


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

[Bug fortran/31244] data initialization with more than 2**32 elements

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #2 from sgk at troutmask dot apl dot washington dot edu  
2007-09-18 18:02 ---
Subject: Re:  data initialization with more than 2**32 elements

On Tue, Sep 18, 2007 at 05:56:36PM -, kargl at gcc dot gnu dot org wrote:
> 
> The problem is found in decl.c(top_val_list) at lines 404-411, which
> are 
> 
>   signed int tmp;
>   msg = gfc_extract_int (expr, &tmp);
>   gfc_free_expr (expr);
>   if (msg != NULL)
> {
>   gfc_error (msg);
>   return MATCH_ERROR;
> }
> 
> gfc_extract_int is trying to put 4294967296_8 into a signed int.
> This probably needs to be changed to accommodate the type of
> an array index.

For completeness, the line 412 is 'tail->repeat = tmp'
where tail->repeat is an unsigned int.


-- 


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

[Bug libgcj/33479] New: SyncTest Intermittent failing on MIPS

[daney at gcc dot gnu dot org]

As noted in:
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00818.html

With this configuration:

../trunk/configure --prefix=/home/ddaney/gccsvn/trunk-install
--target=mipsel-linux --build=mipsel-linux --host=mipsel-linux
--with-gmp=/home/ddaney/mp --with-mpfr=/home/ddaney/mp --with-arch=sb1
--disable-java-awt --without-x --enable-__cxa_atexit --disable-jvmpi
--disable-static

The SyncTest test fails sometimes.


-- 
   Summary: SyncTest Intermittent failing on MIPS
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: daney at gcc dot gnu dot org
ReportedBy: daney at gcc dot gnu dot org
 GCC build triplet: mipsel-linux-gnu
  GCC host triplet: mipsel-linux-gnu
GCC target triplet: mipsel-linux-gnu


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

[Bug c++/33476] New warning suggestion: virtual functions called from constructors/destructors

[bangerth at dealii dot org]

--- Comment #1 from bangerth at dealii dot org  2007-09-18 18:41 ---


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


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/33475] New warning suggestion: virtual functions called from constructors/destructors

[bangerth at dealii dot org]

--- Comment #1 from bangerth at dealii dot org  2007-09-18 18:41 ---
*** Bug 33476 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/33468] C++: Invalid interpretation of friendness with nested classes

[bangerth at dealii dot org]

--- Comment #1 from bangerth at dealii dot org  2007-09-18 18:59 ---
Confirmed.

A simpler to understand testcase is this one (all crud removed):
-
class A {
class B { };
friend class X;
};
class X {
A::B mx;
class Y : A::B {
A::B my;
};
};

It shouldn't compile because X::Y is not a friend and therefore can't
access A::B in the declaration of 'my', as noted in 11.4/2.

This is a regression introduced in gcc 4.0.x. We get the correct error
in everything leading up to 4.0.3, but not any more in 4.0.4. This
may help figure out which patch is at fault...

W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||accepts-invalid
  Known to fail||4.0.4 4.1.0 4.2.0
  Known to work||3.3.5 3.4.6 4.0.0 4.0.2
   ||4.0.3
   Last reconfirmed|-00-00 00:00:00 |2007-09-18 18:59:43
   date||


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

[Bug c++/33481] New: New warning suggestion: virtual functions called from constructors/destructors

[yuri at tsoft dot com]

I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.

During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived classes.


-- 
   Summary: New warning suggestion: virtual functions called from
constructors/destructors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com


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

[Bug c++/33470] Reassignment of a reference to a polymorphic class fails at runtime

[bangerth at dealii dot org]

--- Comment #4 from bangerth at dealii dot org  2007-09-18 18:48 ---
To be quite clear: you can re-associate references (unlike pointers), so
when you do Ainst = Cinst, you copy the A-part of Cinst, but you still have
a 'B' whose 'A' component has just been overwritten.

W.


-- 


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

[Bug c++/33477] New warning suggestion: virtual functions called from constructors/destructors

[bangerth at dealii dot org]

--- Comment #2 from bangerth at dealii dot org  2007-09-18 18:41 ---


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


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

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

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2007-09-18 18:47 ---
No this is not fixed.  The error message is incorrect.  Most users will not use
__builtin_va_arg directly, they will be using va_arg.  So when they see
__builtin_va_arg, it will confuse them.  Can you please change it to be va_arg
instead of __builtin_va_arg.  


-- 


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

[Bug c++/33460] [4.1/4.2/4.3 regression] ICE with static member in anonymous union

[pcarlini at suse dot de]

-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-09-18 18:33:39
   date||


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

[Bug c++/33480] New: New warning suggestion: virtual functions called from constructors/destructors

[yuri at tsoft dot com]

I would like to suggest that gcc issues a warning (with -Wall) when any virtual
functions are called from constructors and destructors of these objects.

During construtors and destructors derived objects aren't complete and almost
always virtual functions would be called on undefined derived classes.


-- 
   Summary: New warning suggestion: virtual functions called from
constructors/destructors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com


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

[Bug c++/33475] New warning suggestion: virtual functions called from constructors/destructors

[bangerth at dealii dot org]

--- Comment #2 from bangerth at dealii dot org  2007-09-18 18:41 ---
*** Bug 33477 has been marked as a duplicate of this bug. ***


-- 


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

[Bug libgcj/33479] SyncTest Intermittent failing on MIPS

[daney at gcc dot gnu dot org]

--- Comment #1 from daney at gcc dot gnu dot org  2007-09-18 18:48 ---
SyncTest never completes.  When it gets into this state the threads are in the
followin state:

(gdb) thread 6
[Switching to thread 6 (Thread 758265024 (LWP 29566))]#0  0x2ce68fac in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
(gdb) bt
#0  0x2ce68fac in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1  0x2b7190fc in _Jv_CondWait (cv=0x2cd84e00, mu=0x2cd84de0, 
millis=, nanos=0)
at ../../../trunk/libjava/posix-threads.cc:212
#2  0x2b6f37c8 in gnu::gcj::runtime::FinalizerThread::run (
this=)
at ../../../trunk/libjava/gnu/gcj/runtime/natFinalizerThread.cc:57
#3  0x2b70cb78 in _Jv_ThreadRun (thread=0x2d086f50)
at ../../../trunk/libjava/java/lang/natThread.cc:335
#4  0x2b718838 in really_start (x=0x2d04bb68)
at ../../../trunk/libjava/posix-threads.cc:616
#5  0x2c389e18 in GC_start_routine (arg=)
at ../../../trunk/boehm-gc/pthread_support.c:1301
#6  0x2ce62130 in start_thread () from /lib/libpthread.so.0
#7  0x2cf9ef48 in ?? () from /lib/libc.so.6
(gdb) thread 5
[Switching to thread 5 (Thread 760362176 (LWP 29567))]#0  0x2cf5d820 in
nanosleep () from /lib/libc.so.6
(gdb) bt
#0  0x2cf5d820 in nanosleep () from /lib/libc.so.6
#1  0x2cf9678c in usleep () from /lib/libc.so.6
#2  0x2b706d28 in wait_unlocked (he=0x2cd861d0)
at ../../../trunk/libjava/java/lang/natObject.cc:634
#3  0x2b7079a0 in _Jv_MonitorEnter (obj=0x411870)
at ../../../trunk/libjava/java/lang/natObject.cc:966
#4  0x00401070 in SyncTest.run()void (this=)
at SyncTest.java:10
#5  0x2bc40420 in java.lang.Thread.run()void (this=)
at /home/ddaney/gccsvn/trunk/libjava/java/lang/Thread.java:755
#6  0x2b70cb78 in _Jv_ThreadRun (thread=0x2d086f00)
at ../../../trunk/libjava/java/lang/natThread.cc:335
#7  0x2b718838 in really_start (x=0x2d04bb40)
at ../../../trunk/libjava/posix-threads.cc:616
#8  0x2c389e18 in GC_start_routine (arg=)
at ../../../trunk/boehm-gc/pthread_support.c:1301
#9  0x2ce62130 in start_thread () from /lib/libpthread.so.0

(gdb) thread 4
[Switching to thread 4 (Thread 762459328 (LWP 29568))]#0  0x2cf5d820 in
nanosleep () from /lib/libc.so.6
(gdb) bt
#0  0x2cf5d820 in nanosleep () from /lib/libc.so.6
#1  0x2cf9678c in usleep () from /lib/libc.so.6
#2  0x2b706d28 in wait_unlocked (he=0x2cd861d0)
at ../../../trunk/libjava/java/lang/natObject.cc:634
#3  0x2b7079a0 in _Jv_MonitorEnter (obj=0x411870)
at ../../../trunk/libjava/java/lang/natObject.cc:966
#4  0x00401070 in SyncTest.run()void (this=)
at SyncTest.java:10
#5  0x2bc40420 in java.lang.Thread.run()void (this=)
at /home/ddaney/gccsvn/trunk/libjava/java/lang/Thread.java:755
#6  0x2b70cb78 in _Jv_ThreadRun (thread=0x2d086eb0)
at ../../../trunk/libjava/java/lang/natThread.cc:335
#7  0x2b718838 in really_start (x=0x2d04bb38)
at ../../../trunk/libjava/posix-threads.cc:616
#8  0x2c389e18 in GC_start_routine (arg=)
at ../../../trunk/boehm-gc/pthread_support.c:1301
#9  0x2ce62130 in start_thread () from /lib/libpthread.so.0

(gdb) thread 3
[Switching to thread 3 (Thread 764556480 (LWP 29569))]#0  0x2cf5d820 in
nanosleep () from /lib/libc.so.6
(gdb) bt
#0  0x2cf5d820 in nanosleep () from /lib/libc.so.6
#1  0x2cf9678c in usleep () from /lib/libc.so.6
#2  0x2b706d28 in wait_unlocked (he=0x2cd861d0)
at ../../../trunk/libjava/java/lang/natObject.cc:634
#3  0x2b7079a0 in _Jv_MonitorEnter (obj=0x411870)
at ../../../trunk/libjava/java/lang/natObject.cc:966
#4  0x00401070 in SyncTest.run()void (this=)
at SyncTest.java:10
#5  0x2bc40420 in java.lang.Thread.run()void (this=)
at /home/ddaney/gccsvn/trunk/libjava/java/lang/Thread.java:755
#6  0x2b70cb78 in _Jv_ThreadRun (thread=0x2d086e60)
at ../../../trunk/libjava/java/lang/natThread.cc:335
#7  0x2b718838 in really_start (x=0x2d04bb30)
at ../../../trunk/libjava/posix-threads.cc:616
#8  0x2c389e18 in GC_start_routine (arg=)
at ../../../trunk/boehm-gc/pthread_support.c:1301
#9  0x2ce62130 in start_thread () from /lib/libpthread.so.0

(gdb) thread 2
[Switching to thread 2 (Thread 766653632 (LWP 29570))]#0  0x2cf5d820 in
nanosleep () from /lib/libc.so.6
(gdb) bt
#0  0x2cf5d820 in nanosleep () from /lib/libc.so.6
#1  0x2cf9678c in usleep () from /lib/libc.so.6
#2  0x2b706d28 in wait_unlocked (he=0x2cd861d0)
at ../../../trunk/libjava/java/lang/natObject.cc:634
#3  0x2b7079a0 in _Jv_MonitorEnter (obj=0x411870)
at ../../../trunk/libjava/java/lang/natObject.cc:966
#4  0x00401070 in SyncTest.run()void (this=)
at SyncTest.java:10
#5  0x2bc40420 in java.lang.Thread.run()void (this=)
at /home/ddaney/gccsvn/trunk/libjava/java/lang/Thread.java:755
#6  0x2b70cb78 in _Jv_ThreadRun (thread=0x2d086e10)
at ../../../trunk/libjava/java/lang/natThread.cc:335
#7  0x2b718838 in really_start (x=0x2d04bb28)
at ../../../trunk/libjava/posix-threads.cc:616
#8  0x2c389e18 in GC_start_routine (arg=)
at ../../../trunk/boehm-gc/pthread_support.c:13

[Bug c++/33481] New warning suggestion: virtual functions called from constructors/destructors

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2007-09-18 19:04 ---


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


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/33475] New warning suggestion: virtual functions called from constructors/destructors

[pcarlini at suse dot de]

--- Comment #3 from pcarlini at suse dot de  2007-09-18 19:04 ---
*** Bug 33481 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/32756] [4.3 Regression] wrong ambiguous overload error?

[bangerth at dealii dot org]

--- Comment #8 from bangerth at dealii dot org  2007-09-18 19:13 ---
This works with a snapshot from yesterday.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/33435] internal compiler error with templates and openmp

[bangerth at dealii dot org]

--- Comment #1 from bangerth at dealii dot org  2007-09-18 19:16 ---
Can you try to come up with an example that is self-contained,
i.e. only contains those parts of the Tiny Vector Matrix library
that are really used (or none at all)?

W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org
Summary|internal compiler error with|internal compiler error with
   |templates and openmp|templates and openmp


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

[Bug fortran/31244] data initialization with more than 2**32 elements

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #3 from sgk at troutmask dot apl dot washington dot edu  
2007-09-18 19:16 ---
Subject: Re:  data initialization with more than 2**32 elements

On Tue, Sep 18, 2007 at 06:02:03PM -, sgk at troutmask dot apl dot
washington dot edu wrote:
> > 
> > The problem is found in decl.c(top_val_list) at lines 404-411, which
> > are 
> > 
> >   signed int tmp;
> >   msg = gfc_extract_int (expr, &tmp);
> >   gfc_free_expr (expr);
> >   if (msg != NULL)
> > {
> >   gfc_error (msg);
> >   return MATCH_ERROR;
> > }
> > 
> > gfc_extract_int is trying to put 4294967296_8 into a signed int.
> > This probably needs to be changed to accommodate the type of
> > an array index.
> 

Ugh.  I have a patch that would allow a repeat count of
2**32-1.  For this program:

  program main
  integer(kind=1), dimension(4294967294_8) :: i
  data i /4294967294_8 * 1_1/
  print *,i(1)
  end program main

and 'gfc4x -o z -O p.f90', I see 

51879 sgk   1 1210   554M   554M RUN1   5:48 92.24% as

in top(1).  Do we really want to support this large of a repeat count?


-- 


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

[Bug fortran/31244] data initialization with more than 2**32 elements

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #4 from sgk at troutmask dot apl dot washington dot edu  
2007-09-18 19:26 ---
Subject: Re:  data initialization with more than 2**32 elements

On Tue, Sep 18, 2007 at 07:16:42PM -, sgk at troutmask dot apl dot
washington dot edu wrote:
> 
> Ugh.  I have a patch that would allow a repeat count of
> 2**32-1.  For this program:
> 
>   program main
>   integer(kind=1), dimension(4294967294_8) :: i
>   data i /4294967294_8 * 1_1/
>   print *,i(1)
>   end program main
> 
> and 'gfc4x -o z -O p.f90', I see 
> 
> 51879 sgk   1 1210   554M   554M RUN1   5:48 92.24% as
> 
> in top(1).  Do we really want to support this large of a repeat count?
> 

Ugh**2.

If I'm not mistaken, this will create an executable with
4 GB of static data in it.  I think we should but a sane
limit on the value.  Btw,  I'm sitting at

51879 sgk   1 1220  1302M  1304M CPU1   1  14:17 93.41% as
51878 sgk   1  -80 17684K 12924K pipewr 0   7:58 48.78% f951

in top(1).  So, it memory grows to rough 4GB, then it will take
about an hour to compile this program.


-- 


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

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

[pcarlini at suse dot de]

--- Comment #7 from pcarlini at suse dot de  2007-09-18 19:06 ---
If Gaby agree with that change, I'm ok with it.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||gdr at cs dot tamu dot edu


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

[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.

[eweddington at cso dot atmel dot com]

--- Comment #24 from eweddington at cso dot atmel dot com  2007-09-18 19:06 
---
Subject: RE:  [avr-gcc] Optimization decrease performance of
 struct assignment.



> --- Comment #23 from rask at gcc dot gnu dot org
>
> In define_insn_and_split "*movhi", add the line
>
>&& LABEL_REF != GET_CODE (operands[1])
>
> where it already says
>
>&& SYMBOL_REF != GET_CODE (operands[1])
>
> and the error should go away.

I *added* the line (not replace) as you suggested, and now it generates a
new error during build:

c:/avrdev/gcc/gcc-4.3-20070914/libobjc/Object.m:66: error: unrecognizable
insn:
(insn 54 4 55 2 c:/avrdev/gcc/gcc-4.3-20070914/libobjc/Object.m:65 (set
(reg:QI 22 r22 [ D.2345 ])
(subreg:QI (const:HI (plus:HI (symbol_ref:HI
("_OBJC_SELECTOR_TABLE") [flags 0x2] )
(const_int 8 [0x8]))) 0)) -1 (nil))


-- 


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

[Bug c++/33475] New warning suggestion: virtual functions called from constructors/destructors

[pcarlini at suse dot de]

--- Comment #4 from pcarlini at suse dot de  2007-09-18 19:04 ---
*** Bug 33480 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/33468] [4.1/4.2/4.3 Regression] C++: Invalid interpretation of friendness with nested classes

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|x86_64-suse-linux-gnu   |
   GCC host triplet|x86_64-suse-linux-gnu   |
 GCC target triplet|x86_64-suse-linux-gnu   |
Summary|C++: Invalid interpretation |[4.1/4.2/4.3 Regression]
   |of friendness with nested   |C++: Invalid interpretation
   |classes |of friendness with nested
   ||classes
   Target Milestone|--- |4.1.3


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

[Bug c++/33480] New warning suggestion: virtual functions called from constructors/destructors

[pcarlini at suse dot de]

--- Comment #1 from pcarlini at suse dot de  2007-09-18 19:04 ---


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


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

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

[paolo at gcc dot gnu dot org]

--- Comment #8 from paolo at gcc dot gnu dot org  2007-09-18 19:42 ---
Subject: Bug 33462

Author: paolo
Date: Tue Sep 18 19:42:42 2007
New Revision: 128585

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128585
Log:
cp/
2007-09-18  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/33462 (again)
* cxx-pretty-print.c (pp_cxx_va_arg_expression): Print
va_arg instead of __builtin_va_arg.

testsuite/
2007-09-18  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/33462 (again)
* g++.dg/ext/va-arg1.C: Adjust.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cxx-pretty-print.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/va-arg1.C


-- 


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

[Bug target/11180] [avr-gcc] Optimization decrease performance of struct assignment.

[rask at gcc dot gnu dot org]

--- Comment #25 from rask at gcc dot gnu dot org  2007-09-18 19:49 ---
> c:/avrdev/gcc/gcc-4.3-20070914/libobjc/Object.m:66: error: unrecognizable
> insn:
> (insn 54 4 55 2 c:/avrdev/gcc/gcc-4.3-20070914/libobjc/Object.m:65 (set
> (reg:QI 22 r22 [ D.2345 ])
> (subreg:QI (const:HI (plus:HI (symbol_ref:HI
> ("_OBJC_SELECTOR_TABLE") [flags 0x2]  _OBJC_SELECTOR_TABLE>)
> (const_int 8 [0x8]))) 0)) -1 (nil))

That's a similar story: Add a line with
&& CONST != GET_CODE (operands[1])


-- 


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

[Bug fortran/31244] data initialization with more than 2**32 elements

[sgk at troutmask dot apl dot washington dot edu]

--- Comment #5 from sgk at troutmask dot apl dot washington dot edu  
2007-09-18 20:07 ---
Subject: Re:  data initialization with more than 2**32 elements

On Tue, Sep 18, 2007 at 07:26:22PM -, sgk at troutmask dot apl dot
washington dot edu wrote:
> 
> If I'm not mistaken, this will create an executable with
> 4 GB of static data in it.  I think we should but a sane
> limit on the value.  Btw,  I'm sitting at
> 
> 51879 sgk   1 1220  1302M  1304M CPU1   1  14:17 93.41% as
> 51878 sgk   1  -80 17684K 12924K pipewr 0   7:58 48.78% f951
> 
> in top(1).  So, it memory grows to rough 4GB, then it will take
> about an hour to compile this program.
> 

:)

Mem: 5365M Active, 1779M Inact, 222M Wired, 341M Cache, 214M Buf, 10M Free
Swap: 17G Total, 17G Free

  PID USERNAMETHR PRI NICE   SIZERES STATE  C   TIME   WCPU COMMAND
51879 sgk   1 1170  4254M  4261M CPU1   1  53:25 96.53% as
51878 sgk   1 1040 17684K 12860K RUN1  26:01 39.45% f951

troutmask:sgk[312] gfc4x -o z -pipe -O p.f90

/tmp: write failed, filesystem is full
/tmp/ccdu52FQ.o: No space left on device
{standard input}: Assembler messages:
{standard input}:87: FATAL: Can't write /tmp/ccdu52FQ.o: No space left on
device


-- 


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

[Bug rtl-optimization/33482] New: Invalid operands for pshifts with -O1

[dwarak dot rajagopal at amd dot com]

Testcase (test1.c):

#include 
__m128i test_fn1(__m128i x)
{
  __m128i y;
  return _mm_srl_epi64(x,_mm_set_epi32(0,0,31,31));
}

gcc -O1 -c test1.c
/tmp/ccBc8BO7.s: Assembler messages:
/tmp/ccBc8BO7.s:7: Error: suffix or operands invalid for `psrlq'

gcc -O1 -S test1.s

test_fn1:
.LFB501:
psrlq   $133143986207, %xmm0
ret

As we can see that the operands are invalid for psrlq. Similar errors occur for
other pshifts instructions such as psra*, psrl*, and psll*.

A patch to fix this issue is as follows, basically having the right output
modifier for these insns in sse.md.

diff -purwN gcc-4.2.2-RC-20070909/gcc/config/i386/sse.md
gcc-4.2.2-RC-20070909-fix/gcc/config/i386/sse.md
--- gcc-4.2.2-RC-20070909/gcc/config/i386/sse.md2007-09-01
10:28:30.0 -0500
+++ gcc-4.2.2-RC-20070909-fix/gcc/config/i386/sse.md2007-09-17
16:33:26.790117000 -0500
@@ -2724,7 +2724,7 @@
   [(set (match_operand:SSEMODE24 0 "register_operand" "=x")
(ashiftrt:SSEMODE24
  (match_operand:SSEMODE24 1 "register_operand" "0")
- (match_operand:TI 2 "nonmemory_operand" "xn")))]
+ (match_operand:TI 2 "nonmemory_operand" "xN")))]
   "TARGET_SSE2"
   "psra\t{%2, %0|%0, %2}"
   [(set_attr "type" "sseishft")
@@ -2734,7 +2734,7 @@
   [(set (match_operand:SSEMODE248 0 "register_operand" "=x")
(lshiftrt:SSEMODE248
  (match_operand:SSEMODE248 1 "register_operand" "0")
- (match_operand:TI 2 "nonmemory_operand" "xn")))]
+ (match_operand:TI 2 "nonmemory_operand" "xN")))]
   "TARGET_SSE2"
   "psrl\t{%2, %0|%0, %2}"
   [(set_attr "type" "sseishft")
@@ -2744,7 +2744,7 @@
   [(set (match_operand:SSEMODE248 0 "register_operand" "=x")
(ashift:SSEMODE248
  (match_operand:SSEMODE248 1 "register_operand" "0")
- (match_operand:TI 2 "nonmemory_operand" "xn")))]
+ (match_operand:TI 2 "nonmemory_operand" "xN")))]
   "TARGET_SSE2"
   "psll\t{%2, %0|%0, %2}"
   [(set_attr "type" "sseishft")

Is this ok?

- Dwarak


-- 
   Summary: Invalid operands for pshifts with -O1
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwarak dot rajagopal at amd dot com
 GCC build triplet: i686-unknown-linux-gnu
  GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu


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

[Bug fortran/33408] ICE: tree check: expected type_decl, have in debug_flush_symbol_queue, at final.c:3986

[fxcoudert at gcc dot gnu dot org]

--- Comment #7 from fxcoudert at gcc dot gnu dot org  2007-09-18 21:03 
---
(In reply to comment #6)
> FX, which version of gfortran are you using? I cannot reproduce it (with
> valgrind) under x86_64-openSUSE-10.3b3 with today's gfortran 4.3 (Rev. 128538)
> - neither for -m32 nor -m64.

Hum, I have updated my tree since, and I'm not seeing the failure any more.
Dale, if you ever have time to try and reconfirm this on a newer revision,
maybe it's gone. Apart from that, it's gonna be rather hard to debug :(


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org


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

[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2007-09-18 21:25 
---
Subject: Bug 31119

Author: fxcoudert
Date: Tue Sep 18 21:25:40 2007
New Revision: 128587

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128587
Log:
PR fortran/31119

* trans-array.c (gfc_conv_ss_startstride): Only perform bounds
checking for optional args when they are present.

* gfortran.dg/bounds_check_9.f90: New test.
* gfortran.dg/bounds_check_fail_2.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/bounds_check_9.f90
trunk/gcc/testsuite/gfortran.dg/bounds_check_fail_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/31119] -fbounds-check: Check for presence of optional arguments before bound checking

[fxcoudert at gcc dot gnu dot org]

--- Comment #6 from fxcoudert at gcc dot gnu dot org  2007-09-18 21:34 
---
Fixed.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug libstdc++/32666] FAIL: abi_check

[bkoz at gcc dot gnu dot org]

--- Comment #3 from bkoz at gcc dot gnu dot org  2007-09-18 21:54 ---
These all appear to be fails from missing C99 math functionality: tanl, etc.

So, maybe something with libmath config, config for C99 functions?

-benjamin


-- 


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

[Bug libstdc++/32666] FAIL: abi_check

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2007-09-18 
22:24 ---
Subject: Re:  FAIL: abi_check

> So, maybe something with libmath config, config for C99 functions?

Think so,  I see asinf isn't found, yet it's there.  I'm going
to remove "-j 2" from my make script.  That should make it easier to see
what's happening.

Dave


-- 


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

[Bug libgcj/33479] SyncTest Intermittent failing on MIPS

[Hans dot Boehm at hp dot com]

--- Comment #2 from Hans dot Boehm at hp dot com  2007-09-18 22:26 ---
I assume the LOCKED bit in *he is actually set when gdb looks at it?  What does
the rest of the hash entry look like?  That might give you a hint as to the
culprit.

Clearly someone sets the LOCKED bit on a hash entry and neglects to clear it. 
If a compare_and_swap succeeded but returned failure anyway, that might explain
it.  A misimplementation of release_set might also cause the problem.  I don't
immediately see how this can be explained by a memory ordering issue.


-- 

Hans dot Boehm at hp dot com changed:

   What|Removed |Added

 CC||Hans dot Boehm at hp dot com


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

[Bug libstdc++/32822] More pb_ds/hash_based_containers.html errors

[bkoz at gcc dot gnu dot org]

--- Comment #1 from bkoz at gcc dot gnu dot org  2007-09-18 22:49 ---
Subject: Bug 32822

Author: bkoz
Date: Tue Sep 18 22:49:24 2007
New Revision: 128589

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128589
Log:
2007-09-17  Benjamin Kosnik  <[EMAIL PROTECTED]>
Chalathip Thumkanon  <[EMAIL PROTECTED]>

PR libstdc++/32819
PR libstdc++/32822
* docs/html/ext/pb_ds/hash_based_containers.html: Correct.


Modified:
trunk/libstdc++-v3/ChangeLog


-- 


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

[Bug libstdc++/32819] pb_ds/hash_based_containers.html errors

[bkoz at gcc dot gnu dot org]

--- Comment #1 from bkoz at gcc dot gnu dot org  2007-09-18 22:49 ---
Subject: Bug 32819

Author: bkoz
Date: Tue Sep 18 22:49:24 2007
New Revision: 128589

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128589
Log:
2007-09-17  Benjamin Kosnik  <[EMAIL PROTECTED]>
Chalathip Thumkanon  <[EMAIL PROTECTED]>

PR libstdc++/32819
PR libstdc++/32822
* docs/html/ext/pb_ds/hash_based_containers.html: Correct.


Modified:
trunk/libstdc++-v3/ChangeLog


-- 


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

[Bug c++/33483] New: New warning suggestion (for -Wall): sizeof() with non-lvalue has side effects that will not execute at runtime

[yuri at tsoft dot com]

#include 
using namespace std;
Here is a very dangerous situation that compiler can catch illustrated by the
following example: when sizeof has non-lvalue argument.

--- example ---

int f() {
  cout << "I am f" << endl;
  return 5;
}

int main() {
  cout << "sizeof=" << sizeof(f()) << endl; // HERE THE WARNING SHOULD BE
ISSUED
  return (0);
}


-- 
   Summary: New warning suggestion (for -Wall): sizeof() with non-
lvalue has side effects that will not execute at runtime
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com


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

[Bug libstdc++/32819] pb_ds/hash_based_containers.html errors

[bkoz at gcc dot gnu dot org]

-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-09-18 22:50:23
   date||


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